A worked retrieval design shows query planning, follow-up searches, source checks, stopping decisions, and what to write back into memory.
Multi-round retrieval: break down the question, fill evidence gaps, and stop when enough evidence is available.
Agentic retrieval lets an agent choose its next search based on current results. It can revise a query, switch sources, and check whether the evidence answers the question. This control pattern can be used within RAG; RAG itself does not require a single retrieval step.
Each follow-up needs a purpose. More rounds can produce more similar material while still missing the fact that determines the answer.
Identify the facts needed for the decision
Suppose the question is: “Why was the report cache disabled, and can we turn it back on?”
The decision needs the original reason, the current implementation, and validation covering the original failure. These come from project history, current code, and test results. A shutdown notice alone answers only the first part.
Use each round to resolve a specific gap
| Round | Search and inspection | Illustrative finding | Next action |
|---|---|---|---|
| 1 | Find the shutdown decision and linked issue | The cache key omitted tenant identity | Inspect current key generation |
| 2 | Follow the issue to the change and current code | Tenant identity is now included | Inspect cross-tenant validation |
| 3 | Read relevant tests and their results | Existing tests cover only single-tenant hits and invalidation | Specify the isolation tests needed before re-enabling |
The answer is now clear: the cache key has been fixed, but cross-tenant isolation tests are still needed before re-enabling the cache. The next step is to run those tests. More general reading about caching cannot replace them.
Iter-RetGen investigates using earlier generation to improve later retrieval. In this example, each follow-up likewise addresses a gap found in the previous round.
Keep an inspectable evidence record
For each item, record its origin, project and version, the claim it supports, and what it does not cover. “The issue explains the shutdown” and “current code includes tenant identity” should remain distinct observations.
Several retellings of one event are not independent confirmations. Use current code and execution results to establish current behavior, and original decisions or discussions to establish historical intent. When sources differ, check time and scope first. An old document saying the cache is disabled and a new implementation containing a revised key may both be accurate: deploying a fix and enabling a feature can happen separately.
When to stop searching and start testing
A workflow needs distinct endings. Stop when the question has a supported answer. Move to testing or human confirmation when the remaining gap requires that work. If the search budget is exhausted, retain the established facts and identify what remains unresolved.
Several rounds with no new results show that the current search path has stalled. The conclusion still needs support from the evidence already found. A stopping decision should also consider question coverage, unresolved conflicts, and remaining resources.
Choose what becomes long-term memory
Save the verified shutdown reason with its source. Attach a version to implementation state and test results, so later tasks can check them again. A hypothesis generated to plan a search should not enter memory as a confirmed fact.
“The report cache was disabled after a tenant-isolation failure” can become traceable project history. “It is now safe to enable” requires validation. Recording the historical cause and current validation status separately lets later tasks judge whether the experience applies.
References https://aclanthology.org/2023.findings-emnlp.620/
