In the port-operations copilot a planner asks 'What is the cut-off time for hazardous cargo there?' after three turns discussing Antwerp. Retrieval returns nothing useful because the embedded query has no port in it. Which change fixes this class of failure?
Select an answer to reveal the explanation.
Short Explanation
The retriever has no memory — it only sees the string you hand it, and 'there' is not a port. Use the model to turn the follow-up into a full question first: 'What is the hazardous cargo cut-off time at Antwerp?' Then search with that.
Full Explanation
Retrieval is stateless: whatever string you embed is the entire query. Pronouns and ellipsis that a human resolves effortlessly from context ('there', 'that berth', 'the same vessel') are semantically empty to an embedding model, so multi-turn applications need an explicit query-rewriting step that uses the conversation history to produce a standalone question, which is then embedded and searched. This is a distinct chain component placed before the retriever. Embedding the whole history is the closest-looking trap and it is a common first attempt: it does inject 'Antwerp' into the string, but it also injects every other topic discussed, and averaging several turns into one vector produces a diffuse query that matches nothing sharply. Concatenating the last assistant turn has the same dilution problem plus a worse one — it biases retrieval toward whatever the model just said, which propagates any earlier error. Raising k is a lottery ticket, not a fix; if the query vector does not point at Antwerp, more results simply means more wrong results. Exam framing: query rewriting, retrieval, prompt assembly and generation are separable chain components, and multi-turn conversation is the standard reason the first of those exists.