In LangChain v1, how do you wire a retriever into a question-answering chain?

## The shape of the thing Stripped of framework vocabulary, retrieval-augmented question answering is: 1. `docs = retriever.invoke(question)` 2. `context = format(docs)` 3. `answer = model.invoke(prompt.format_messages(context=context, question=question))` Everything else is packaging. Understanding that the packaging is thin is most of what an interviewer is checking, because engineers who learned the helper first often cannot say what happens between input and output. ## What the legacy helper did `create_retrieval_chain(retriever, combine_docs_chain)` was the pre-1.0 constructor. Given a question under the `input` key it ran the retriever, put the Documents under `context`, ran a documents chain (usually built by `create_stuff_documents_chain(llm, prompt)`, which stuffs every document into one prompt) and returned a dict carrying `input`, `context` and `answer`. Its predecessor, `RetrievalQA`, returned sources under a `source_documents` key when asked to — which is why that key still shows up in old code and old answers. Two behaviours of that helper are worth stating explicitly because they are what people forget: - **It always retrieves.** There is no conditional. A greeting, a follow-up like "and the second one?", a question about the conversation itself — all of them hit the vectorstore and inject four chunks of unrelated text. Deciding *whether* to retrieve is a different control-flow problem and is not something this chain does. - **It stuffs.** The whole retrieved set goes into one prompt. That is the correct default and the reason `k` is a token-budget decision rather than a quality dial; it also means one oversized chunk can overflow the context window at request time rather than at build time. ## Why v1 pushes you to compose it yourself LangChain 1.x slimmed the top-level `langchain` package considerably, and the legacy chain constructors moved out into a separate classic compatibility package. In interviews, saying "`create_retrieval_chain` is the pre-1.0 shape, and in v1 I compose the steps" reads as current; presenting it as the recommended modern API reads as training-data-shaped. The practical argument for composing is the seams. When you write the three steps, you can: - **Format documents deliberately.** Numbering the chunks and prefixing each with its source lets the model produce inline citations you can verify: `[1] handbook.pdf p.12`. A generic join gives the model no handle to cite with. - **Budget tokens before the call.** Count the formatted context and truncate or drop the lowest-ranked documents rather than discovering the overflow as an API error. - **Short-circuit on empty retrieval.** If the retriever returns nothing — very possible with a score threshold — you can answer "I don't have anything on that" without paying for a generation that will hallucinate. - **Return the evidence.** Keeping the Documents alongside the answer is what makes citations, offline evaluation and incident debugging possible. A chain that returns only a string throws away the only artefact that explains why the answer was what it was. ## The prompt matters more than the wiring The grounding instruction is doing the real work: tell the model to answer only from the supplied context, and to say it does not know when the context does not cover the question. Without that, the model blends its parametric knowledge with the retrieved text and you lose the property that made retrieval worth building. ## Conversational queries One wrinkle appears the moment there are two turns. "How much is it?" is unretrievable on its own — the referent lives in the previous turn. The standard fix is a rewrite step that condenses the history plus the new message into a standalone search query before it reaches the retriever, so the vectorstore sees "how much does the premium support plan cost" instead of a pronoun. That is an extra model call before retrieval, and it is why conversational RAG latency is structurally higher than single-shot. ## Failure modes - Retrieved context far under the intended size because `chunk_size` was in characters, not tokens. - Confident answers to off-topic questions, because retrieval is unconditional and the prompt never told the model it may abstain. - No citations available at answer time, because the Documents were discarded after formatting. - Context-window overflow in production but not in testing, because `k` chunks of *worst-case* size were never summed.