Use agentic RAG when a model needs to choose or repeat searches, GraphRAG when questions depend on connected evidence or collection-wide themes, and fine-tuning when the model needs to learn a stable task or response behavior. Start with fixed retrieval for document questions, then add the mechanism that resolves a demonstrated failure. These choices can be combined: an agent can call a graph retriever, and a fine-tuned model can answer from retrieved evidence.
Search control, evidence representation and model adaptation can be selected independently.
The comparison below separates search control, evidence representation and model adaptation. It connects the AI Data Architecture talks with implementation choices for an enterprise knowledge application.
Compare the layer each approach changes
LangChain’s retrieval guide distinguishes fixed retrieval before generation from an agent deciding when and how to retrieve. AWS Prescriptive Guidance recommends beginning with RAG for custom-document question answering and describes combining it with a fine-tuned generator.
| Approach | Choose it for | Update path | Runtime work and evidence |
|---|---|---|---|
| ApproachFixed two-step RAG | Choose it for A question answerable by a known search followed by generation. | Update path Refresh source chunks, embeddings and search metadata. | Runtime work and evidence A fixed retrieval/generation path; retain the passages used for citations. |
| ApproachAgentic RAG | Choose it for Choosing sources or following an answer with another search. | Update path Maintain each source and the retrieval tools exposed to the agent. | Runtime work and evidence Variable search and model calls; retain tool traces and retrieved passages. |
| ApproachMicrosoft GraphRAG: local | Choose it for Questions about a specific entity and its connections. | Update path Refresh extracted graph data and associated text artifacts. | Runtime work and evidence Combine graph context with source text chunks. |
| ApproachMicrosoft GraphRAG: global | Choose it forThemes spanning a document collection. | Update path Maintain graph communities and generated reports. | Runtime work and evidence Map-reduce over community reports; check summary claims against source documents. |
| ApproachFine-tuning | Choose it for A repeatable task, style or format gap after the necessary evidence is supplied. | Update path Curate examples, train and evaluate a new model release. | Runtime work and evidence Run the adapted model; add retrieval for current document evidence and citations. |
A useful diagnosis starts with the failed answer. Missing source passages point to retrieval quality. Repeatedly choosing the wrong source points to routing or tool selection. Incomplete coverage of a collection points to the scope of retrieval and synthesis. A response that uses the right evidence but consistently breaks the required format points to prompting or model adaptation.
Choose GraphRAG by question scope
Separate an entity question from a collection-wide question before choosing a query mode. Microsoft’s GraphRAG query overview describes local search as combining graph data and raw text chunks, while global search works across community reports. It also offers DRIFT, which uses community context to develop follow-up questions, and basic vector search as a comparison path.
Entity questions and collection-wide themes require different evidence coverage.
For a supplier-document application, “Which contracts name this supplier?” calls for precise passage retrieval. “Which suppliers share a dependency?” calls for connected evidence. “Which risks recur across the collection?” calls for broad synthesis. Use these question types to build separate evaluation groups; the same architecture can perform differently across them.
The GraphRAG paper, From Local to Global, evaluates global sensemaking on news articles and podcast transcripts, each corpus containing roughly one million tokens. Its LLM-judged comparisons favor global methods over its vector-RAG baseline for comprehensiveness and diversity. Its claim-based experiment finds no statistically significant difference between global graph search and graph-free source-text summarization on those measures. For a buyer evaluating collection-wide synthesis, that makes graph-free map-reduce a useful comparator alongside vector retrieval and GraphRAG.
Match agentic control to the response deadline
Agentic retrieval earns its extra steps when the next search depends on what the system has learned. Start by exposing a narrow set of authorized tools, setting a maximum number of iterations and recording the stopping reason. Compare the resulting answer quality and end-to-end latency with the fixed baseline.
LangChain notes that a fixed two-step design caps model calls, improving predictability when model inference dominates. Database, network and tool latency still affect the response. In a multi-step agent, serial calls accumulate; parallel branches finish according to the slowest required branch. Measure complete request traces and tail latency under the expected concurrency.
For a serial path, use:
T_answer = T_route + sum(T_search_i + T_model_i) + T_final
Here, T_route is initial routing, T_search_i is retrieval in iteration i, T_model_i is the intermediate model work in that iteration, and T_final is final answer generation. Measure all durations in the same unit and assign each trace span to one stage.
For parallel search, replace the serial search sum with the duration of the required search stage, including its slowest branch and merge step. Include queueing and retries in the measured stage durations. This gives the architect a concrete decision: simplify or cap any path that exceeds the application’s response deadline.
Azure implementation choice. Azure AI Search’s agentic retrieval documentation distinguishes minimal retrieval, which skips LLM planning, from low and medium, which generate subqueries. Subqueries execute in parallel and results are reranked and merged. As of October 2026, the 2026-04-01 API supports generally available source types with minimal extractive retrieval; LLM planning and answer synthesis use 2026-08-01-preview. Preview capabilities fall outside the service-level agreement. Select the supported feature set before committing a production workload to it.
Plan the update path before selecting the model
Changing evidence and changing model behavior have different release paths. A corrected policy should reach the search index and any derived context used to answer it. A new response convention belongs in prompts or, when evaluation justifies it, a training-and-release cycle.
Fresh evidence and learned behavior follow separate update cycles, each with an evaluation checkpoint.
- Document retrieval: ingest the revision, update chunks and embeddings, refresh metadata and invalidate affected caches. Verify that the current passage is returned for a question that previously retrieved the old one.
- Microsoft GraphRAG: its standard indexing pipeline extracts entities and relationships, detects communities and creates reports. Claim extraction is optional and disabled by default; enable it with a prompt tuned to the claims your application needs. The CLI update command updates an existing index and defaults to an
update_outputdirectory. Evaluate the new output before directing queries to it; include graph/report regeneration in the refresh budget. - Fine-tuning: update the training examples, run training, evaluate the candidate and release the selected model. Keep document retrieval in the system when answers depend on frequently changing knowledge. AWS describes this combined architecture explicitly.
Treat freshness as elapsed time from an authoritative revision to its availability in an authorized answer. Test deletion and access revocation as well as addition. Check derived reports and cached responses for the removed material, and record source, index and model versions with each evaluation result. These acceptance checks make the update path observable.
Compare latency and cost drivers over the same workload
Use the same question mix, corpus, permission filters and evaluation period for every candidate. Separate ingestion and maintenance from serving:
C_period = C_ingestion + C_index_refresh + C_training + C_serving + C_storage + C_evaluation + C_operations
Charge each candidate for the work it actually performs. For agentic retrieval, count planner calls, tool calls, retries, reranking inputs and final-generation tokens. For GraphRAG, include extraction and report generation during indexing plus the reports processed at query time. For fine-tuning, include example curation, training and regression testing as well as inference.
Measure fan-out by summing the tokens actually passed to the reranker across all requests, subqueries and chunk occurrences. For an initial budget, reranked tokens = requests × mean subqueries per request × mean chunks per subquery × mean tokens per chunk occurrence, with each mean calculated over all corresponding requests, subqueries or processed chunk occurrences in the same workload. Count a chunk again each time it is reranked, and retain request-level distributions for capacity planning. Azure’s billing model separates search retrieval tokens from model tokens used for planning or synthesis, so reducing one stage does not eliminate the other stage’s usage. Apply current contracted rates to each meter separately.
When comparing vector stores, test exact identifiers and conceptual matches separately. Azure hybrid search combines keyword and vector queries using reciprocal rank fusion. Its documentation identifies names, product codes, dates and specialized jargon as cases that can benefit from exact keyword matching. Hold the embedding model and chunk boundaries constant while comparing filtering, update/delete behavior, ranking and citation metadata.
Run an acceptance test that identifies the next change
Use a held-out set with expected evidence and desired answers. Include exact facts, connected-entity questions, collection-wide themes, unanswerable questions and revoked-access cases. Set quality, freshness and latency requirements before comparing the candidates.
For each answer, record the permitted sources, retrieved passages, source/index versions, tool path, citations, elapsed time and failure reason. Then change one layer:
- If the supporting passage is missing, fix ingestion, chunking, filtering or retrieval.
- If the next source depends on an earlier result, evaluate an agentic step with an explicit stopping budget.
- If evidence coverage misses relationships or broad themes, compare local/global graph retrieval with the relevant baseline.
- If sufficient evidence is present but behavior remains wrong, compare improved prompts and fine-tuning on the same held-out task.
Retain the simplest candidate that meets the agreed requirements. A combined architecture is useful when separate failures justify both its retrieval and training components.
Follow the architecture questions into the talks
The Build 2026 tools and documents discussion is a next step for tool selection and document preparation. For the data platform decisions around experimentation, read the re:Invent SageMaker talk on a failed hypothesis and the cost of the next attempt. The Build HorizonDB talk adds the database team’s release and AI-development discussion.
Continue with the AI Data Architecture topic to compare the underlying talk records and their source locators.
Sources
Updated October 2026.
- LangChain: Retrieval architectures.
- AWS: Comparing RAG and fine-tuning.
- Microsoft GraphRAG: query modes, indexing, updates and the research paper.
- Azure AI Search: agentic retrieval and hybrid search.