Your AI assistant just answered a complex, multi-part question by pulling data from three different sources, checking its own work, and re-querying when the first results fell short. That's agentic retrieval in action.
This guide covers what agentic retrieval is, how it differs from traditional retrieval-augmented generation (RAG), the main techniques behind it, and where Redis fits as the data layer.
Agentic retrieval is an architectural pattern where an LLM-powered agent controls retrieval: deciding when to retrieve, what to query, which tools or sources to use, and whether the results are good enough. If they're not, the agent iterates, reformulates, and tries again until it has enough evidence or hits a stopping condition.
Traditional RAG, by contrast, uses a fixed pipeline that fetches documents in a single pass with static control flow that can't adapt mid-process. Agentic retrieval treats retrieval as a dynamic operation rather than a one-off preprocessing step.
In practice, this pattern shows up in assistants, copilots, and enterprise search where the system has to gather evidence across multiple steps instead of relying on one retrieval pass.
Agentic retrieval is one action inside a larger agent loop, sitting alongside tool use, memory reads and writes, planning, and response generation. The agent invokes it, skips it, or repeats it based on what the current step needs.
In a typical agent workflow, retrieved data sometimes grounds an answer, sometimes informs the next tool call, sometimes updates long-term memory, and sometimes resolves a routing decision. In a Reasoning and Acting (ReAct) loop, the agent reasons about what it needs, issues a retrieval call, observes results, then decides whether to refine the query, switch sources, call a tool, write to memory, or generate a response.
That placement also means failures compound across the loop: a flawed retrieval in step two shapes reasoning in step five, which determines the tool call in step eight. Without tracing the full reasoning chain, the bad output is visible but the originating decision is not.
Redis Iris connects memory, live data, and retrieval in one place.
Retrieval evolved in four stages, with each generation fixing a limitation of the last.
Keyword search matched surface-level tokens and missed anything phrased differently. It worked for exact-match lookups but struggled on questions that required connecting information across documents, a limitation visible in Best Match 25 (BM25) results on multi-hop benchmarks.
Dense vector retrieval added semantic similarity and let systems match meaning instead of just words. It was a clear improvement, but static pipelines still retrieved on every query whether or not it helped, and they had no way to recover when the first pass missed.
Modular RAG added query rewriting, reranking, and hybrid search to improve retrieval quality at each step. It made the pipeline smarter, but the pipeline itself stayed largely pre-planned and linear, with limited ability to adapt based on intermediate results.
Agentic retrieval hands control of the search process to the agent itself, making retrieval iterative and conditional on what it has already learned. Once the agent can decide when to keep searching, failure modes shift from "we didn't find the document" to "we found it but reasoned about it poorly," a more tractable problem.
Once retrieval becomes iterative, the next question is what infrastructure keeps the loop supplied with fresh, usable context.
A context engine is the layer beneath your RAG and agent frameworks responsible for ingesting, indexing, retrieving, governing, and caching the context your LLMs and agents need. Without one, teams cobble together a vector database, a document store, a cache layer, and possibly a time-series database. The result is multiple systems to operate, with integration seams where data goes stale.
Redis Iris is a context engine that feeds agents the right context, in the right form, at the right time, built on Redis' in-memory architecture and designed for low-latency AI workloads. The application or agent framework still orchestrates retrieval strategy; Iris makes sure the context it reaches for is navigable, fast, fresh, and backed by memory that builds over time.
Matching is how agentic retrieval finds the right information for a given question, and no single method does it well on its own.
Hybrid search combines dense vector search with sparse keyword search like BM25 so each method covers the other's blind spots. Vector search handles paraphrased queries; BM25 catches exact identifiers like SKUs and error codes. Their results are then fused with a hybrid ranking method, and combining the two has been shown to improve recall over single-method pipelines. Fusion can backfire, though, when one path is substantially weaker than the other, a weakest-link effect seen in hybrid search research.
Multi-level retrieval indexes the same content at different granularities (full documents, sections, paragraphs, sentences) and matches at the level best suited to the query. A broad question hits document-level summaries; a specific one drops straight to sentences. Hierarchical approaches where the LLM navigates a corpus's semantic tree adapt the search path to the query.
Reranking improves quality after the first retrieval pass by reordering a broad candidate set into a tighter shortlist. A cross-encoder reranker scores each candidate by attending jointly to the query and document, then selects the top few for the LLM. Adding a cross-encoder reranker on top of hybrid retrieval has been shown to raise long-document QA scores.
Metadata filtering narrows the search space by structured attributes like department, date, document type, and access level, before vector or keyword search runs. A RAG survey shows chunks enriched with metadata can be filtered by recency, source, or category, with timestamp weighting to keep knowledge fresh. The biggest gains come when filtering happens on the same layer as retrieval, so hybrid search and metadata filters share one query path.
Redis Iris gives every agent fresh context and long-term memory.
Routing is how an agent decides where a query should go: which knowledge base, tool, or modality to hit, and in what order.
LLM-based routing has the model classify intent and output a structured enum that maps to a specific data source. It's the most flexible option because the model can reason about nuance, but it adds an LLM call to every query. It works best when target sources are few and classification benefits from query context.
Semantic routing skips the LLM call by matching queries against pre-defined example utterances using embedding similarity, offering speed benefits over full LLM inference. The tradeoff is rigidity: it only handles the categories you've defined upfront. That makes it well suited to high-throughput systems with stable routing categories.
Parallel federation fans queries out to multiple specialized agents simultaneously using per-destination query reformulation, then synthesizes results into one response. It's the right choice when you don't know which source has the answer, or when the answer spans multiple sources. The classifier node can generate not just a routing decision but a targeted sub-question for each source's domain.
Routing configurations, source metadata, and access policies are themselves data agents need at query time. Keeping them on the same layer as retrieval indexes avoids extra hops to separate stores.
Query formulation is how an agent decides what to actually ask for once it's picked a source, and it can matter as much as the retrieval algorithm itself.
Query planning decomposes complex, multi-part questions into atomic sub-queries before retrieval starts. The LevelRAG architecture, for example, uses a high-level searcher that breaks complex queries into independent atomic queries, decoupled from retriever-specific optimizations.
Query rewriting rephrases queries to better align with how documents are indexed. It matters most in multi-turn conversations, where ambiguous references and colloquial omissions force the rewriter to use full dialogue history to produce a query the retriever can act on.
Query expansion enriches a query with additional terms or generated content to widen the recall net. Hypothetical Document Embeddings (HyDE), for example, generates a pseudo-answer using the LLM and then uses that hypothetical answer for similarity search rather than the original query.
Multi-turn refinement ties planning, rewriting, and expansion together across reasoning cycles, with each retrieval step's results informing the next query. Interleaving Retrieval with Chain-of-Thought (IRCoT), for instance, interleaves reasoning with retrieval, making the two co-dependent. The tradeoff is error propagation through the full chain.
Caching and memory are how an agent reuses prior work, both to cut cost and latency, and to keep continuity across steps and sessions.
Semantic caching matches incoming queries against previously answered ones by meaning rather than exact text, cutting retrieval and generation work before the rest of the pipeline runs. As a first layer before LLM invocation, it can deliver millisecond-level responses for recurrent queries, and agent-aware variants like the Agent RAG Caching (ARC) algorithm push that further by reusing retrieval work across agent steps, not just final answers.
Session and long-term memory give agents continuity across a single interaction and across sessions. Session memory holds conversation state within the LLM's active context window. Long-term memory persists distilled facts, user preferences, and behavioral patterns across sessions using vector search for conceptual retrieval, so the agent can recall both immediate context and historical knowledge when making retrieval decisions.
Agentic retrieval techniques benefit from sharing a single data layer rather than getting stitched across separate systems. Redis Iris is built for that role: a context engine that holds retrieval indexes, agent memory, and cached responses in one in-memory platform.
Underneath:
Under all four, Redis Search handles vector, structured, unstructured, and real-time retrieval in a single query path.
Redis Iris keeps agent data current so answers stay accurate.
Agentic retrieval shifts retrieval from a one-shot preprocessing step into an iterative loop the agent controls. Matching, routing, query formulation, and caching all become decisions the agent revisits as it gathers evidence. That works only if the infrastructure beneath the loop can serve fresh context at low latency, hold agent memory, and let one query path span vectors, metadata, and full text.
Redis Iris is the real-time context engine for AI: an in-memory platform that unifies retrieval, caching, and memory while leaving orchestration to the application or agent framework.
Try Redis Iris to start building, or book a meeting to talk through your agent architecture with our team.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。