A user's question is rarely shaped like a document. It is short, it refers to something earlier in the conversation, and it uses the words a person uses rather than the words the manual uses. Rewriting the question into search shaped queries is the step that fixes those three, and it costs one cheap model call.
About 1 min of reading
Rewrite a follow-up.
The follow-up
Before you run it, say out loud what it will print. Then open the answer.
The rewrite
Before you run it, say out loud what it will print. Then open the answer.
Before you write anything, put these lines back in the right order. Click a line to move it up one step. This support step is easier than writing code from scratch, and it is here to make the last example stick.
Read the first example one line at a time. A line that prints shows what appears on screen; the rest set things up quietly.
The rewrite step must not answer the question. A rewrite that guesses an answer and searches for it retrieves evidence for a wrong claim, which is the failure mode that makes a system agree with itself.
Search the original question as well as the rewrites. A rewrite that changes meaning is then still answered by the original query, and the merge keeps both in the candidate set.
'And for the annual one?' only makes sense with the previous turn. Rewriting it into a standalone question using the conversation is what makes retrieval work at all, since retrieval never sees the conversation.
Ask for the words the document uses, not the words the user used. 'Is it open on Sundays?' and 'trading hours' share no tokens, so a keyword search finds nothing and an embedding search finds it weakly.
Generate two or three phrasings and run the search for each, then merge. A question whose answer sits in one phrasing's blind spot is covered by another, which is cheaper and broader than tuning one query.
Each one is defined here on this site. Open the entry for the full definition and the other words it points at.