GraphRAG vs Vector RAG vs Hybrid: 2026 Multi-Hop Retrieval Architecture

Q: When should I add a knowledge graph to my RAG system, and when should I not?

The trigger is a stable false-negative rate on a properly stratified eval set, specifically on the multi-hop and global-query subsets, after you have tuned hybrid search (BM25 plus dense plus reciprocal rank fusion) and calibrated a cross-encoder re-ranker. If single-hop accuracy is above 85 percent on the dominant slice and the misses are not concentrated in multi-hop, the graph will not move the metric and the indexing cost is wasted. If multi-hop misses are 15 to 40 percent of the failure mode, vector-first with graph expansion using existing structured side-data is the cheapest intervention. If multi-hop misses are above 40 percent or if global or holistic queries are a meaningful share of the workload, LightRAG or full GraphRAG indexing is justified. The mistake most teams make is adopting GraphRAG to solve complaints that hybrid search and re-ranking have not yet been tried on; 70 percent of "RAG is not accurate" complaints are solvable by the cheaper stack first. The architectural rule is workload-driven: measure the eval, stratify by query type, and let the data decide whether to spend the 300 to 1000x indexing cost premium that graph indexing represents.

Q: What is the practical difference between Microsoft GraphRAG and LightRAG, and which should I pick?

Microsoft GraphRAG runs a five-stage indexing pipeline: chunk and clean, entity and relationship extraction with one LLM call per chunk, graph construction with entity deduplication, hierarchical community detection using Leiden or Louvain algorithms, and community summarisation with one LLM call per community at each hierarchy level. The query side exposes local search for entity-centric questions and global search for holistic queries via map-reduce over community summaries. The cost at 2026 prices is roughly 80 to 200 dollars per million source tokens of indexing, with the community-summarisation stage as the expensive line item and full re-indexing required when community boundaries shift. LightRAG keeps the entity-and-relationship extraction stage but drops hierarchical community detection and summarisation entirely, replacing them with a dual-level retrieval scheme: low-level retrieval over entities and relationships themselves and high-level retrieval over relationship-context summaries generated at extraction time. The cost is roughly 30 to 80 dollars per million source tokens, incremental updates are local rather than global, and accuracy on local and multi-hop queries is comparable to GraphRAG; the trade-off is on global queries where LightRAG produces lower-quality holistic summaries. Pick LightRAG when the workload is dominated by multi-hop entity-centric questions, the corpus changes weekly or faster, and global summarisation queries are rare. Pick full GraphRAG when global queries are a meaningful share of the workload and the corpus is stable enough to absorb periodic full re-indexing. For most B2B workloads LightRAG is the better starting point; teams adopt full GraphRAG only when the global-query share justifies the indexing premium.

Q: How much does GraphRAG actually cost to index, and what drives the cost?

At 2026 prices using a gpt-4o-mini-class extraction model at roughly 0.15 dollars per million input tokens and 0.60 dollars per million output tokens, full GraphRAG indexing runs at approximately 80 to 200 dollars per million source tokens; for a 10-million-token corpus the initial index is 800 to 2,000 dollars. Three line items dominate. Entity and relationship extraction is one LLM call per chunk with prompt verbosity multiplied by extraction output verbosity; the per-chunk cost is small but the chunk count scales linearly with corpus size. Community summarisation is one LLM call per community at each hierarchy level kept; for a meaningfully-sized corpus this is the single largest line item because community count grows with corpus size and the summarisation prompts are verbose. Re-indexing is the operational cost that is easy to under-budget: corpus drift that shifts community boundaries invalidates the summaries and triggers re-runs at the chosen cadence. The 2024 baseline with gpt-4-turbo at the original release pricing was approximately 1,500 to 3,000 dollars per million source tokens which made the architecture financially difficult for any corpus above tens of millions of tokens; the 2026 pricing on smaller-model extraction has compressed the per-token cost by roughly 20x and made the architecture practical for low-tens-of-millions-of-tokens corpora. The decision input is not the absolute dollar number but the cost-per-served-query: if 5 percent of queries are global queries that require GraphRAG and the other 95 percent are well-served by vector RAG, the cost-per-served-global-query is the entire GraphRAG bill divided by the small fraction, which is a hard ROI conversation. The router-based dispatch pattern addresses this by paying the GraphRAG cost only on the queries that genuinely need it.

Q: What is the vector-first plus graph expansion pattern, and why is it the recommended entry point?

The pattern uses the vector index (with hybrid search and re-ranking) as the primary retrieval surface; when the top-k retrieved chunks contain entities, a second-stage graph expansion fetches the immediate neighbourhood of those entities from a lightweight graph index and adds the expanded context to the prompt. The graph itself does not need to be extracted from unstructured text via expensive LLM calls; it can be built from any structured side-data the organisation already has — CRM exports, ERP relationships, ITSM tickets, product catalogues, ontologies — and loaded into a small graph store with minimal pre-processing. The pattern adds multi-hop capability incrementally at near-zero marginal indexing cost over vector RAG, the per-query runtime cost is a single sub-10ms graph traversal, and the operational surface is small. The architecture is the recommended entry point for three reasons. First, it preserves the vector RAG investment; teams do not have to rip out the working stack to add graph capability. Second, it captures the largest fraction of the multi-hop accuracy lift without the GraphRAG indexing premium, particularly when the organisation already has curated structured side-data sitting in operational systems. Third, it is a stepping stone to the more expensive patterns: teams gain operational experience with graph storage and traversal before committing to the entity-extraction pipeline, and the eval data accumulated under vector-first-plus-graph-expansion directly informs whether further investment is justified. The pattern is the right answer for B2B SaaS support copilots, enterprise knowledge bases, and CRM-grounded assistants where the side-data graph already exists and the extraction step is unnecessary. The limitation is that it does not solve global or holistic queries; for workloads where those are rare, the trade-off is acceptable.

Q: What is router-based dispatch, and how does the router decide which retrieval flow to use?

Router-based dispatch puts a lightweight classifier in front of the retrieval flows: an inbound query is inspected by a small-LLM call (typically 10 to 40ms with a model like gpt-4o-mini or a fine-tuned smaller classifier) and routed to one of three retrieval flows — pure vector RAG for single-hop lookups (the cheap path), vector-first with graph expansion for multi-hop entity-centric queries (the medium path), or graph-first with global summarisation for holistic queries (the expensive path). The router applies the same calibration discipline as the Model Router pattern: label a few hundred queries with the correct flow against a gold standard, train or prompt-engineer the classifier, monitor accuracy and drift in production, and retrain on the workload distribution as it shifts. The decision rule is workload-aware: under-routing (sending too many queries to the cheap flow) shows up as accuracy regressions on multi-hop slices of the eval; over-routing (sending too many queries to the expensive flow) shows up as cost regressions without proportional accuracy gains. The architecture is the right answer for any production workload with mixed query distribution, which describes almost every real production workload; the marginal complexity of adding a classifier on top of the retrieval flows is small compared to the cost and quality gains from routing each query to the cheapest flow that can answer it. Most teams arrive at router-based dispatch after starting with one of the simpler patterns and learning empirically that no single retrieval flow handles the whole workload distribution well. The pattern lands last in the maturity ladder because it requires operational experience with each underlying flow to label the training data correctly and to interpret the routing decisions.

Q: Why does GraphRAG handle global or holistic queries that vector RAG cannot, and what does that capability cost?

Global queries are questions like "what are the dominant themes in our customer-support tickets this quarter" or "summarise the patterns across these incident reports" that require aggregation across a corpus rather than retrieval of specific chunks. Vector RAG cannot answer them because vector similarity returns the top-k chunks closest to the query phrasing, which for an aggregation query is approximately a random sample of the corpus weighted toward chunks that happen to use the aggregation vocabulary; the model receives a sample, not a summary, and produces an answer that is fluent but unfounded. GraphRAG handles these queries because the community-detection and community-summarisation stages of the indexing pipeline pre-compute aggregations at multiple hierarchy levels; the global-search query flow runs the question against the community summaries at the relevant hierarchy level (a map-reduce: the question is asked of each community summary, the partial answers are aggregated by a final LLM call), producing answers that reflect the actual distribution of the corpus rather than a random sample of it. The cost is the indexing-time community summarisation (the expensive line item in GraphRAG indexing) plus the per-query map-reduce, which for a meaningfully-sized corpus is often tens of LLM calls per global query, a 5x to 10x cost multiplier over a vector RAG query for those queries specifically. The capability is real and not replicable in vector RAG; if global queries are a meaningful workload share the cost is justified, and if they are rare the cost-per-served-global-query is the metric to track, with the router-based dispatch pattern as the obvious mitigation.

Q: How do I evaluate whether the graph is earning its cost, and what metrics matter?

The eval set has to be stratified by query type: single-hop, multi-hop with explicit hop count, and global or holistic. Aggregate accuracy hides everything that matters; a 90 percent aggregate that breaks down to 95 percent on the dominant single-hop slice and 40 percent on the multi-hop slice is a different decision-input than 90 percent even across both. The standard RAG eval metrics all apply: faithfulness (does the answer reflect the retrieved context without hallucination), answer relevance (does the answer address the question), context precision (are the retrieved chunks relevant), and context recall (are all the relevant chunks retrieved); frameworks like Ragas, DeepEval, LangSmith eval, and TruLens make these measurable with LLM-as-judge against gold sets. The graph-specific metrics measured at indexing time predict downstream retrieval quality and are dramatically cheaper to measure than end-to-end query evals: entity-extraction precision and recall against a gold-labelled subset of chunks, relationship-extraction precision and recall, entity-deduplication accuracy (the most common silent failure mode), community-summary quality (LLM-as-judge against gold summaries for a sampled set of communities), and graph-coverage (what fraction of important entities in the corpus appear as graph nodes). The decision to keep or remove the graph is the same shape as evaluation-driven development: define the eval, run it on every architecture change, and only ship the architecture that demonstrably moves the metric on the slice that matters. Teams that adopt GraphRAG without stratified evals lose the ability to detect whether the graph is helping; teams that measure properly can defend or retire the investment with data.

Q: How do I handle corpus drift and re-indexing in GraphRAG without rebuilding everything daily?

Vector indexes are forgiving on drift because adding or removing chunks is a chunk-local operation; graph indexes are less forgiving because entity extraction is sensitive to prompt and model drift, and community detection is a global operation where adding a high-degree entity can shift community boundaries across the graph. The operational pattern that works in production has three rules. First, pin the extraction prompt, extraction model, and community-detection parameters as part of the index configuration; version them; treat any change to them as a full re-indexing event rather than an incremental update, because changed-extraction outputs do not deduplicate cleanly against previous extractions and the graph will fragment. Second, separate the incremental update cadence from the full re-indexing cadence: entity extraction on new chunks runs incrementally at the rate of corpus drift (daily, hourly, whatever the workload requires) and adds entities to the existing graph with deduplication against the existing entity set; community detection and summarisation run on a slower cadence (weekly or fortnightly is typical) that batches accumulated drift into a single periodic recomputation. Third, measure community-summary staleness as an operational metric: track how much of the community structure has shifted since the last full re-run and trigger re-indexing when the shift exceeds a threshold rather than on a fixed schedule. Hourly-changing corpora are not a clean GraphRAG fit without significant engineering on incremental community algorithms; LightRAG handles hourly change much better because community summaries are not part of its pipeline. Quarterly or annually-changing corpora are the easiest case with full re-indexing on a calendar cadence and no incremental complexity. The freshness-versus-cost trade-off is the key tuning lever and should be made explicit at architecture-decision time rather than discovered six months into operation.

Q: What is the role of Neo4j vector index and similar unified graph-plus-vector stores in 2026?

Neo4j added a production-ready vector index in late 2023 and has deeply integrated it through 2024 and 2025; a single Neo4j store can hold both the property graph and the chunk-level vector index, and Cypher queries can express graph traversals and vector similarity in the same query. The architectural payoff is operational simplicity: one database, one backup pipeline, one access-control surface, one set of credentials, one monitoring dashboard; the query layer combines structural and semantic retrieval natively. The pattern fits the case where the organisation already has a curated knowledge graph maintained by humans or by a separate ETL pipeline — product taxonomies, organisational hierarchies, ontologies, knowledge bases curated through MDM or PIM systems — and wants vector retrieval grounded in that graph’s structure. The other graph databases have moved in the same direction at varying paces: Memgraph has vector search, Kuzu has vector search, TigerGraph has vector search, and the unified graph-plus-vector store is now the default expectation rather than the exception. The trade-off versus separate vector and graph stores is the one to think about: a unified store has operational simplicity but couples the scaling characteristics of two different workloads (graph traversals and vector ANN lookups have different memory and CPU profiles); a split-store architecture has independent scaling but adds the cross-store consistency problem. For workloads where the graph is small and curated (low millions of nodes and edges), unified stores are the simpler choice; for workloads where the chunk-level vector index is in the hundreds of millions of vectors and the graph is similarly large, the split-store architecture preserves the ability to scale each independently. The decision is operational rather than functional; both architectures can serve the same retrieval patterns.