A user asks a RAG system: 'Which of the supplier contracts signed before 2022 contain force majeure clauses that explicitly exclude pandemics?' This requires the system to identify relevant contracts, locate force majeure language, and verify the pandemic exclusion. Standard single-hop RAG returns contract titles but misses the clause-level detail. What retrieval architecture addresses this multi-hop requirement?

The two-stage retrieval architecture is correct because multi-hop questions require decomposed retrieval. The query cannot be satisfied in a single retrieval pass because finding the answer requires two distinct information-seeking steps: identifying the relevant set of contracts and locating and evaluating specific clause language within those contracts. A two-stage architecture — first filtering to relevant contracts using the pre-2022 date constraint and force majeure keyword, then issuing targeted sub-queries against only those contracts to retrieve and evaluate the pandemic exclusion language — mirrors the logical structure of the query. Increasing the retrieval k to 50 is wrong because it floods the context with irrelevant passages; for a corpus of thousands of contracts, k=50 does not guarantee the specific pandemic exclusion clauses are retrieved, and the large context degrades answer quality. Using full-text search instead of vector search is wrong because full-text search would help with keyword matching but cannot handle the logical multi-hop dependency between finding contracts and evaluating their specific clauses. Fine-tuning the embedding model on legal contract data is wrong because fine-tuned embeddings improve semantic matching within a single retrieval hop but do not add the logical multi-hop reasoning capability the query requires.