Earlier in this series, I covered:
Retrieval and reranking produce an ordered collection of passage records. A language model does not automatically receive that collection in the same form. The application still has to decide which records fit, extract their readable text, preserve useful source information, and place everything into a structured request.
That transition is context assembly. It is the boundary between finding evidence and presenting selected evidence to the model.
Retrieval output is not model input
A retriever normally returns records rather than a finished prompt. A record may contain the passage text, a chunk identifier, source metadata, and a relevance value. A reranker may change the order or attach a new score, but the result is still application data.
The language model receives a different representation: text or messages serialized into tokens according to the model interface. The application must therefore translate selected retrieval records into that representation.
Not every stored field has to appear in the model input. A relevance score may help the application decide which passages to keep, while the model receives only the passage text and a source label. Likewise, an embedding helps retrieve a passage but is not normally included as evidence for generation.
What context assembly adds
Context assembly commonly performs three jobs.
First, it selects the retrieved records that will continue. The available input space is shared with application instructions, the user’s question, and, in a conversational system, relevant chat history. If every candidate does not fit, the application needs a selection or multi-step processing strategy.
Second, it formats each passage. Separators, identifiers, headings, or structured fields can make the boundary between passages explicit. A source label might contain a document title and section, while the passage body contains the readable evidence.
Third, it retains a mapping between the text shown to the model and the original retrieval record. That mapping can later support source links or citations. It belongs to the application: the language model does not recover provenance that was discarded earlier.
The exact representation varies. Some applications construct one text prompt; others send several messages or use a framework that formats document objects. The stable idea is that retrieved records must be deliberately converted into model-visible context.
One assembled model input
Consider a fictional leave-policy assistant. A user asks, “Can unused leave carry into next year?” Retrieval supplies two relevant records. One passage says unused leave expires at the end of the calendar year. Another says that up to five days may carry into the next calendar year.
The application could construct a request with four visible parts: an instruction to answer from the supplied policy excerpts, a labeled passage for the general rule, a labeled passage for the carryover exception, and the user’s question.
The model can then interpret the second passage as a qualification to the first. Clear labels make it possible for the application to associate an answer with the corresponding handbook sections. They do not force the model to use the passages correctly or prove that a later citation supports every generated claim.
Input limits, ordering, and a second example
A model’s context window is shared by everything in the request. Retrieved passages compete for space with instructions, the current question, conversation history, and any required output structure. When the assembled request is too large, an application may pass fewer passages, shorten material, or use more than one model call. Each choice changes what evidence the model can inspect.
Retrieval rank and model-input position are also different concepts. A system may preserve the retrieved order, group passages by source, or apply another ordering step. This article does not prescribe a universal ordering because the effect depends on the model, task, passage set, and implementation.
For a second fictional example, imagine a travel-policy assistant. The selected records contain a current employee meal policy and an older contractor addendum. Their text, source type, effective date, and section label may all matter to the question, “Can a contractor claim meals during same-day travel?”
Context assembly can expose those distinctions by labeling both passages accurately. It cannot decide by formatting alone whether the addendum remains authoritative, which policy takes precedence, or whether a newer contractor rule is missing. Those require source-governance and application logic beyond prompt construction.
Formatting does not guarantee grounding
Passage boundaries and source labels improve structure, but they do not guarantee that the language model will follow the evidence. The model may overlook a passage, combine statements incorrectly, or generate a claim that the supplied context does not support.
Context assembly also cannot repair missing evidence. If retrieval omitted the required passage, formatting the remaining records more clearly does not restore it. If parsing removed a table column or metadata linked a passage to the wrong source, the model sees the resulting error.
Citations require another layer of care. The application can retain record identifiers and display links, but the presence of a citation does not establish that the cited passage supports the adjacent claim. Traceability and claim-level support are related but separate properties.
Finally, the assembled input is only one request representation. Model behavior still depends on the model, instructions, available evidence, and generation settings. A well-structured context makes evidence available; it does not certify the answer.
Retrieval returns application records. Context assembly turns selected records into model-visible evidence by extracting readable text, adding passage boundaries and source labels, and combining that context with instructions and the user’s question.
The application may use relevance scores and metadata when deciding what to include, even when those fields are not shown to the model. It should also retain a reliable mapping from each presented passage to its source if the product will expose citations.
Context assembly determines what evidence is available in the request. It does not guarantee that the evidence is complete, authoritative, or faithfully used.
Once a RAG system retrieves and assembles evidence, the next question is how to evaluate the retrieval stage itself. The next explainer will define recall, precision, and mean reciprocal rank, and show what each metric observes without turning the article into a new evaluation framework.