GraphRAG

Overview

GraphRAG is a retrieval-augmented generation method that first turns a corpus into a knowledge graph, then answers questions by walking that graph instead of only looking up similar text chunks. The graph holds entities (people, organizations, products, places, concepts) and the relations between them. Related entities are grouped into communities, and each community gets a written summary. At question time the system can follow links between entities for specific questions, or read community summaries for broad questions about the whole corpus.

The reason GraphRAG exists is that plain vector retrieval is good at finding a few passages that look like the question, but weak at questions such as "What are the main themes across all these documents?" or "How is A connected to C through B?". Those questions need connected, corpus-wide reasoning. GraphRAG pays a high indexing cost up front, mostly in language model calls, to make those questions answerable. This page explains the idea step by step, shows a worked example, compares it with naive RAG, hybrid search and agentic RAG, and connects it to tabular foundation models, where graphs of rows, columns and entities are a natural fit.

What it is

GraphRAG is a family of retrieval patterns built on a graph index. The common parts are:

• Entity and relation extraction. A language model reads each text chunk and lists the entities and the relations between them, often with a short description of each.
• A graph. Entities are nodes. Relations are edges. Repeated mentions of the same entity across chunks are merged into one node.
• Communities. A community detection algorithm splits the graph into clusters of densely connected nodes. Clusters can be nested, giving several levels from fine to coarse.
• Community summaries. A language model writes a report for each community that describes its entities, their relations and the key claims.
• Query modes. Local queries start from entities named in the question and gather their neighborhood. Global queries read community summaries and combine them into an answer.

The word "GraphRAG" is also used loosely for any retrieval method that stores knowledge in a graph database and queries it with graph traversal, with or without community summaries. This page covers both the specific summary-based design and the general idea.

An everyday analogy

Think of a detective's wall. Instead of a pile of witness statements, the detective pins photos of people and places to a board and connects them with string. Questions like "Who knows both the shop owner and the driver?" are answered by following strings, not by rereading every statement. Then the detective groups the board into clusters, such as "the warehouse crew" and "the family", and writes one card per cluster. Asked "What is going on overall?", the detective reads the cluster cards. GraphRAG builds that board automatically.

Where it came from

Knowledge graphs are older than modern language models. Semantic web work in the 2000s defined triples of subject, predicate and object. Large public and private knowledge graphs powered search boxes and assistants for years. Graph databases and query languages such as Cypher and SPARQL made it possible to store and ask questions of such graphs.

Retrieval-augmented generation was introduced in a 2020 paper that combined a retriever with a text generator. Through 2023 most RAG systems used vector search over text chunks. Practitioners noticed that this failed on "global" questions that need a summary of the entire dataset, because the answer is spread over many chunks and no single chunk is similar to the question.

In 2024 a research paper titled "From Local to Global: A Graph RAG Approach to Query-Focused Summarization" described the entity graph plus community summary design and tested it on large text collections, showing gains on comprehensiveness and diversity of answers to broad questions. After that, many open source projects and database vendors added graph-based retrieval features, and several variants appeared that trade indexing cost for speed or accuracy. The exact feature sets differ by project, so check the documentation of the one you use.

How it works

The pipeline has an indexing phase and a query phase.

Phase 1: Indexing

Step 1: Split the source into chunks

Documents are cut into passages, typically a few hundred to a couple of thousand tokens. Chunks that are too small lose context. Chunks that are too large make extraction less reliable. Some overlap between chunks helps keep entities that sit on a boundary.

Step 2: Extract entities and relations

A language model is prompted with each chunk and asked to return structured output, for example a list of entities with a type and description, and a list of relations with source, target and description. Many pipelines run a second "gleaning" pass that asks the model whether it missed anything.

Everyday analogy: a careful reader going through a pile of reports with a highlighter, marking every name and every "X works with Y" statement on index cards.

Step 3: Resolve and merge

The same entity appears under different names: "the Bank", "First Bank", "FB". A merge step unifies them using string rules, embeddings or another language model call. Descriptions from several chunks are combined into one longer description. Poor merging is a common source of errors, so it deserves attention.

Step 4: Build the graph

Nodes and edges are stored in a graph database, a property graph library or even plain tables. Each edge can keep a weight, such as how many chunks mention it, and pointers back to the source chunks for citation.

Step 5: Detect communities

A community detection algorithm clusters the graph. A widely used choice is the Leiden algorithm, which finds groups of nodes that connect more to each other than to the rest. It can be run hierarchically, so large communities contain smaller ones.

Everyday analogy: sorting guests at a big party into friend circles by who talks to whom.

Step 6: Summarize communities

For each community, a language model receives the entities, relations and claims inside it and writes a report. Higher-level communities are summarized from the summaries of their children when they are too large to fit in a prompt. These reports are the key new artifact. They let the system answer broad questions without scanning every chunk.

Step 7: Embed and index

Chunks, entity descriptions and community reports are embedded and stored in a vector index so that questions can find entry points into the graph. Many systems also keep a keyword index. See hybrid search and HNSW for how such indexes work.

Phase 2: Querying

Local search

Used for questions about specific things, such as "What contracts does Supplier X have and who signed them?".

1. Find entities in the question, by name match or by vector similarity to entity descriptions.
2. Expand to neighbors: connected entities, relations, and the text chunks tied to them.
3. Rank and trim this context to fit the prompt.
4. Ask the language model to answer using that context, with citations.

Global search

Used for questions about the whole corpus, such as "What are the main risks mentioned across these reports?".

1. Pick a community level. Higher levels are cheaper but coarser.
2. Send batches of community reports to the model, and ask for partial answers with a usefulness score (the map step).
3. Collect the most useful partial answers and ask the model to merge them into one final answer (the reduce step).

This is similar to how a team might write a company-wide summary: each department writes a note, a manager combines the notes.

Drift and mixed modes

Some implementations add a mode that starts from community summaries to form follow-up questions, then runs local searches for detail. Others combine graph traversal with vector retrieval in one ranked context. The names and details vary by project.

The pipeline as a diagram

documents
   |-- chunk --> LLM extraction --> entities + relations
   |                                    |
   |                              merge / resolve
   |                                    |
   |                               knowledge graph
   |                                    |
   |                       community detection (hierarchical)
   |                                    |
   |                        LLM community summaries
   |
question --> local mode:  entities -> neighbors -> chunks -> answer
         --> global mode: community reports -> map -> reduce -> answer

Key concepts and terms

A worked example

Take a tiny corpus of five sentences.

1. "Acme Corp supplies steel to Borealis Motors."
2. "Borealis Motors builds the Lynx truck at its Ohio plant."
3. "The Ohio plant was closed for two weeks after a flood."
4. "Acme Corp also supplies steel to Cedar Rail."
5. "Cedar Rail postponed its new train order after a supplier delay."

Extraction result

A multi-hop question

"Which companies might be affected if Acme Corp has a problem?"

A plain vector search for this question may return sentence 1 and sentence 4, since both mention Acme Corp. It may miss sentence 2 and sentence 5, which describe downstream effects. In the graph, the system starts at Acme Corp, follows two supplier edges to Borealis Motors and Cedar Rail, then follows their edges to the Lynx truck and the postponed train order. The answer lists both customers and the downstream items, with sources.

A global question

"What are the main themes?" A community detection step would likely put Acme Corp, Borealis Motors, the Ohio plant and the flood in one cluster (steel supply and truck production), and Cedar Rail with the supplier delay in another, or merge them under one steel supply chain community at a higher level. The community reports would read like: "Steel supply chain: Acme Corp supplies two manufacturers, one of which had a plant outage." The global search combines such reports to answer the question.

Code: a minimal graph build

The sketch below shows the idea with a placeholder extraction function. It uses the networkx library for the graph and a community method that ships with it. A real system would call a language model for extraction and summaries.

import networkx as nx
from networkx.algorithms.community import louvain_communities

triples = [
    ("Acme Corp", "supplies steel to", "Borealis Motors"),
    ("Borealis Motors", "builds Lynx truck at", "Ohio plant"),
    ("Ohio plant", "closed after", "flood"),
    ("Acme Corp", "supplies steel to", "Cedar Rail"),
    ("Cedar Rail", "postponed order after", "supplier delay"),
]

g = nx.Graph()
for s, r, t in triples:
    g.add_edge(s, t, relation=r)

communities = louvain_communities(g, seed=7)
for i, c in enumerate(communities):
    print(i, sorted(c))

def neighborhood(graph, start, hops=2):
    seen, frontier = {start}, {start}
    for _ in range(hops):
        frontier = {n for f in frontier for n in graph.neighbors(f)} - seen
        seen |= frontier
    return seen

print(neighborhood(g, "Acme Corp", hops=2))

Code: a query in a graph database

If the graph is stored in a property graph database, the local search step can be a graph query. The example uses Cypher-style syntax with placeholder labels.

MATCH (a:Entity {name: "Acme Corp"})-[:REL*1..2]-(b:Entity)
RETURN DISTINCT b.name AS affected, b.description AS notes
LIMIT 25;

Code: configuration sketch

graph_index:
  chunk_size: 800
  chunk_overlap: 100
  extraction:
    model: llm-placeholder
    gleaning_passes: 1
    entity_types: [organization, person, product, place, event]
  communities:
    algorithm: leiden
    max_levels: 3
  summaries:
    model: llm-placeholder
    max_report_tokens: 1500
query:
  local:
    top_entities: 10
    neighbor_hops: 2
    max_context_tokens: 8000
  global:
    level: 1
    map_batch_tokens: 8000

Strengths and limitations

Strengths

• Answers broad questions. Community reports give a path to corpus-wide summaries that chunk retrieval cannot provide.
• Multi-hop reasoning. Following edges finds linked facts that no single chunk contains.
• Explainability. A path through the graph is easy to show and to audit.
• Citations. Each node and edge can link to source passages.
• Reuse. Once built, the graph supports many questions, and the reports can be read by people too.

Limitations

• High indexing cost. Extraction and summarization call a language model over the whole corpus. Large corpora can be expensive and slow to index.
• Extraction errors. Missed entities, wrong relations and bad merges flow into every answer.
• Staleness. When documents change, parts of the graph and some community reports must be rebuilt. Incremental updates are harder than adding a vector.
• Schema and prompt sensitivity. Entity types and extraction prompts affect quality, and need tuning per domain.
• Overkill for simple lookups. If questions are mostly "find the passage that says X", a simpler retriever is cheaper and as accurate.
• Evaluation difficulty. Judging answers to broad questions is harder than judging factual lookups. Many studies use a language model as a judge, which has its own biases.
• Privacy surface. The graph and the reports are new derived copies of sensitive text. Treat them with the same access controls as the sources.

How it compares with alternatives

GraphRAG and agentic RAG attack multi-hop questions from different sides. Agentic RAG pays at query time by searching several times. GraphRAG pays at index time by precomputing links and summaries. A system can use both: an agent can choose between a vector tool, a graph tool and a SQL tool. See modular RAG for the idea of swappable components.

Role in tabular foundation models

Tabular foundation models learn from raw tables: rows and columns, mixed numeric and categorical types, missing values, and often headers that are missing or unhelpful. They are usually pre-trained on large numbers of synthetic or real tables and then use in-context learning, so a new table can be handled without training from scratch. GraphRAG is not one of these models. It is a way to organize and retrieve knowledge that sits around them. See /model/architecture and /model/research for the model side.

Tables are already graphs in disguise

A relational database is a graph waiting to be drawn. Rows are nodes. Foreign keys are edges. A customer table, an order table and a product table form a small graph. GraphRAG-style thinking applies directly: instead of extracting entities from text with a language model, you can build the graph from keys and joins, which is cheaper and exact. Graph neural networks such as GCN, GAT and GraphSAGE learn on such structures, and a tabular model can use their outputs or neighbor aggregates as features.

Schema and metadata graphs

Columns, tables, descriptions, units, lineage and business terms form a metadata graph. A question such as "Which columns hold revenue in any currency?" is a graph question. Linking data catalog entries and data lineage edges into a retrieval graph helps a system choose the right tables before a tabular model runs. With no column names, value patterns and co-occurrence edges can stand in for labels.

Context selection for in-context learning

In-context learning models receive labeled rows as context. For a large table, the choice of which rows to include matters. A graph of rows linked by shared keys, shared categories or similarity can drive that choice: start from the query row and take its neighbors, then widen. This is the same local-search idea applied to rows. Details vary and are an active research area.

Imputation

Missing values are easier to fill when related rows are known. In a graph of entities, the neighbors of a row with a missing field often hold the answer, such as other orders from the same customer or other products from the same supplier. Neighbor-based donors feed an imputation model, in the spirit of imputation networks and masked cell modeling.

Anomaly detection

Anomalies often show up as unusual relationships: an account connected to many unrelated accounts, a transaction path that loops, a supplier tied to an unexpected region. Graph structure exposes these patterns, and a tabular model can score rows with graph-derived features. See anomaly detection and isolation forest for row-level methods that these features can feed.

Sector and semantic classification

Assigning an organization to a sector, or a column to a semantic type, benefits from neighbors. A company linked to suppliers, customers and products in one industry is likely in a related sector. A taxonomy is itself a graph, and linking entities to taxonomy nodes is a retrieval-and-classification task. Semantic classification heads on tabular models can use retrieved neighbors and taxonomy paths as extra evidence. See semantic sector heads and /model/benchmarks.

Continual learning

New facts arrive over time. A graph can be extended with new nodes and edges without retraining a model, which complements weight-update methods such as experience replay. The cost is rebuilding affected community reports, which is why incremental community maintenance is an important engineering topic.

Honest limits

GraphRAG does not do numeric prediction. It retrieves and summarizes. When a question needs a forecast, a regression or a classification over table columns, a tabular model or a classical method such as XGBoost does the computing, and GraphRAG supplies the surrounding knowledge.

Practical guidance and best practices

1. Start by asking whether you need it. Collect twenty real questions. If most are lookups, begin with hybrid search. Add a graph when you see global or multi-hop questions failing.
2. Define entity types. A short list of types that match your domain gives cleaner graphs than open-ended extraction.
3. Use structure you already have. If your data has keys, tables or a taxonomy, build those edges directly and use the language model only for the text parts.
4. Test extraction on a sample. Read fifty extracted triples by hand before you index everything.
5. Control cost. Use a smaller model for extraction if quality allows, cache results by chunk hash, and index in batches.
6. Keep provenance. Store chunk identifiers on every node and edge so answers can cite sources.
7. Pick the community level for the question. Coarse levels for themes, fine levels for details. Expose the level as a setting.
8. Combine retrieval styles. Use vector or hybrid retrieval to find entry points, then graph traversal to expand context.
9. Plan updates. Decide how often to rebuild, and which parts can be updated incrementally.
10. Evaluate on your own questions. Use RAGAS, DeepEval or TruLens for faithfulness and relevance, and add human review for broad questions.
11. Secure the derived data. Apply the same access rules to graph and reports as to source documents.
12. Use a framework when it helps. LlamaIndex and other frameworks include graph-based retrieval components, which saves glue code.

A simple routing rule

def route(question):
    q = question.lower()
    broad = any(w in q for w in ["overall", "main themes", "summarize", "across"])
    linked = any(w in q for w in ["connected", "depends on", "affected by", "related to"])
    if broad:
        return "global_graph"
    if linked:
        return "local_graph"
    return "hybrid_search"

Real routers are better built as a small classifier or a language model call, but the idea is the same: use the graph where it pays off.

Checking graph quality

def graph_report(g):
    n, m = g.number_of_nodes(), g.number_of_edges()
    isolated = [x for x in g.nodes if g.degree(x) == 0]
    top = sorted(g.degree, key=lambda x: x[1], reverse=True)[:10]
    return {"nodes": n, "edges": m, "isolated": len(isolated), "top_degree": top}

Very large hub nodes often signal over-merging (many things collapsed into one). Many isolated nodes often signal missed relations.

Operating a GraphRAG index over time

A graph index is a living asset, so it needs routines like any other data system. Plan these from the start.

• Versioned builds. Tag each build with the extraction prompt version, the model used, the chunk size and the date. When answers change, you can then tell whether the data or the pipeline changed.
• Incremental updates. Re-extract only documents that changed, then merge their entities and relations into the existing graph. Re-run community detection and re-summarize only the communities whose members changed.
• Entity resolution passes. Names drift. "Acme Corp", "Acme Corporation" and "ACME" may be one node or three. Schedule a resolution pass that merges aliases using string similarity, embeddings and a few hard rules.
• Deletion and retention. If a source document is removed, remove the facts that only it supports. Provenance links make this possible. Without them, stale facts live on.
• Access control. If sources have different readers, carry that label onto every node, edge and summary. A community summary that mixes restricted and open sources can leak facts.
• Monitoring. Track graph size, average node degree, share of orphan nodes, extraction failures and query latency. A sudden jump in orphans often means the extractor broke.

Think of it like a library catalog. Books arrive and leave every week. A catalog that is only built once is wrong within a month.

Cost and scaling notes

Most of the cost sits in indexing, because every chunk goes through a language model at least once, and community summaries add another pass. Query cost is smaller but not zero, since global search may read many summaries.

A useful habit is to estimate cost on a small sample first. Run extraction on a hundred documents, measure tokens and time, then scale the number up. Surprises are much cheaper at that size.

Choosing entity and relation types

Open-ended extraction ("find all entities") produces noisy graphs. A short, explicit schema works better. Decide which types matter for your questions before you build.

• For a company knowledge base: person, team, product, system, policy, incident.
• For a data platform: table, column, dataset, pipeline, owner, metric, source system.
• For a research archive: method, dataset, task, result, author, venue.

Keep relation names few and meaningful, such as depends_on, owned_by, derived_from and mentions. Dozens of near-synonyms for the same relation make traversal harder and weaken community structure.

Combining graph and vector retrieval

Most strong systems do not choose between graph and vector retrieval. They use both. A typical pattern looks like this.

1. Run a vector or hybrid search to find seed chunks and seed entities.
2. Expand from the seeds by one or two hops in the graph.
3. Collect the expanded chunks, the relations along the way and any relevant community summary.
4. Rerank the pool and trim it to fit the context window.
5. Generate the answer and cite both text sources and graph paths.

This keeps the strength of text similarity for wording and the strength of the graph for links. It also limits graph traversal to a small neighborhood, which keeps latency under control.

Debugging a bad answer

When a GraphRAG answer is wrong, walk back through the pipeline in order.

1. Was the fact in the source? If not, the answer is a generation problem, not a retrieval problem.
2. Was it extracted? Search the graph for the entity and relation. If missing, fix the extraction prompt or schema.
3. Was the entity merged wrongly or split? Check aliases and duplicates.
4. Was it reachable? Check whether a path exists within the hop limit. Raise the limit or add a missing relation type.
5. Was it retrieved? Look at the context that was actually sent to the model. The right facts may exist but rank too low.
6. Was it used? If the context held the right facts and the answer ignored them, tighten the generation prompt and require citations.

Logging the retrieved subgraph with every answer makes this walk possible. Without logs, you are guessing.

Evaluation set design

A graph index needs its own test set, because the questions it targets differ from plain lookups. Build a small set with four groups.

• Single-fact questions. These should work with any retriever. They act as a regression guard.
• Multi-hop questions. Each needs two or more linked facts. Write down the expected path.
• Global questions. Each asks for themes, trends or comparisons across many documents. Write a short reference outline of the points a good answer covers.
• Unanswerable questions. The corpus does not hold the answer. A good system says so.

Score the first and second groups with exact or fuzzy answer matching, the third with a rubric or a language model judge, and the fourth by counting honest refusals. Tools such as RAGAS can help with faithfulness and context checks. Rerun the set after every change to the schema, the chunking or the models.

Security and privacy notes

Graphs make connections easy to see, which is both useful and risky. Joining facts from many documents can reveal something no single document revealed. Review what the graph can answer, not only what each source says. Strip personal data you do not need before extraction, apply the same access labels to derived summaries as to their sources, and treat retrieved text as untrusted input to the generator, since a document may contain instructions aimed at the model.

Common mistakes

• Using GraphRAG for every question. It is slower and costlier than a simple lookup and does not improve factual lookups.
• Skipping entity resolution. Duplicate nodes break paths and split communities.
• Letting the graph grow without types. Free-form entity labels produce a messy graph with hundreds of near-duplicate types.
• Ignoring provenance. Without links to source text, answers cannot be checked.
• Over-trusting summaries. Community reports are language model output and can contain errors or omissions. Spot check them.
• Choosing the wrong level. Using coarse communities for detailed questions gives vague answers. Using fine communities for themes gives noisy ones.
• Rebuilding everything on each change. Plan incremental updates early.
• Forgetting that global answers cost many calls. Map-reduce queries use many model calls, so set budgets.
• Evaluating only on easy questions. Include broad and multi-hop questions in your test set, or you will not see the benefit or the failure.
• Ignoring access control. Summaries can leak facts from documents a user is not allowed to read if communities mix permission levels.

Frequently asked questions

What is GraphRAG in simple terms?

GraphRAG is a way of helping a language model answer questions by first organizing a document collection into a graph of entities and their relationships, then using that graph to find and combine information. It is especially useful for questions that cover the whole collection or that need several connected facts. Plain retrieval looks up similar passages, while GraphRAG follows links and reads summaries of related groups.

How is GraphRAG different from normal RAG?

Normal RAG embeds text chunks and fetches the ones nearest to the question. GraphRAG adds an extra indexing stage that extracts entities and relations, builds a graph, finds communities and writes summaries. At query time it can traverse the graph or read community summaries, so it can answer broad and multi-hop questions that a nearest-chunk lookup tends to miss.

Is GraphRAG better than hybrid search?

They solve different problems. Hybrid search is an excellent and inexpensive way to find passages that match both the words and the meaning of a question. GraphRAG is better for questions about relationships and themes across many documents. Many production systems use hybrid search as the base and add graph retrieval for the question types that need it.

Do I need a graph database to use GraphRAG?

Not always. A graph can be stored in a dedicated graph database, in a library in memory, or even in ordinary tables with an edge list. Small and medium projects often start with files or a relational database. A dedicated graph database becomes attractive when you need fast multi-hop queries, rich query languages or very large graphs.

Why is GraphRAG expensive to build?

Because language models read the whole corpus during indexing to extract entities and relations, and then write summaries for each community. The number of model calls grows with the size of the corpus. You can reduce cost with a smaller extraction model, caching, structured sources that skip extraction, and building the graph only for the parts of the corpus that need it.

What are community summaries and why do they matter?

Community summaries are short reports written for each cluster of closely related entities in the graph. They matter because they compress many chunks into a form that fits in a prompt, which lets the system answer questions about the entire collection without reading every chunk. They also serve as a human-readable map of the corpus.

Can GraphRAG work on tables and databases?

Yes, and it is often easier there. Rows, keys and foreign key links already form a graph, so edges can be created from the schema without a language model. Text columns can still be processed with extraction. The graph can then support navigation, neighbor lookups, imputation donors and anomaly checks, while numeric prediction remains the job of a tabular model.

How do I keep a GraphRAG index up to date?

Track which chunks changed, re-extract only those, update the affected nodes and edges, and refresh the communities and reports that touch them. Some designs rebuild communities on a schedule rather than on every change. Keeping chunk identifiers and hashes makes incremental updates much simpler.

How do I evaluate a GraphRAG system?

Build a question set with three groups: simple lookups, multi-hop questions and broad theme questions. Measure faithfulness and relevance with tools such as RAGAS, and compare against a hybrid search baseline on the same questions. For broad questions, add human review or a carefully prompted language model judge, and check comprehensiveness and diversity of the answers.

When should I not use GraphRAG?

Skip it when your questions are mostly direct lookups, when the corpus is small enough to fit in a prompt, when the data changes minute by minute, or when you cannot afford the indexing cost. In those cases a good hybrid search with reranking is usually the better choice.

Glossary

• Chunk: A passage of a document used as a unit for indexing and retrieval.
• Community: A set of nodes that are more connected to each other than to the rest of the graph.
• Community report: A written summary of a community's entities, relations and claims.
• Cypher: A declarative query language for property graph databases.
• Edge: A link between two nodes in a graph.
• Entity: A named thing such as a person, company, product or place.
• Entity resolution: Deciding that different mentions refer to the same entity.
• Gleaning: An extra pass that asks a model to find items it missed.
• Global search: Answering from community summaries to cover the whole corpus.
• Knowledge graph: A graph of entities and relations used to store facts.
• Leiden algorithm: A community detection algorithm that finds well-connected groups.
• Local search: Answering from the neighborhood of entities named in a question.
• Map-reduce: A pattern that processes parts independently and then merges results.
• Multi-hop: Needing several linked facts to reach an answer.
• Node: A point in a graph, here usually an entity.
• Provenance: The record of which source text supports a fact.
• Triple: A subject, predicate and object statement.

Summary

GraphRAG turns a text collection into a knowledge graph with community summaries, then answers questions by traversing that graph or by reading the summaries. It is strongest on multi-hop and corpus-wide questions where nearest-chunk retrieval falls short. Its main costs are heavy indexing, sensitivity to extraction quality and the work of keeping the graph fresh.

For tabular foundation models and table-centric systems, the graph view is natural: rows and keys are nodes and edges, schemas and lineage form metadata graphs, and neighbors supply context, donors for imputation and signals for anomaly detection and sector classification. GraphRAG supplies connected knowledge around such models and does not replace their numeric reasoning. Start with hybrid search, add graph retrieval where questions demand it, and read more on the model side at /model/research, /model/architecture and /model/benchmarks.

Related

It belongs to RAG in my stack, under LLMs, retrieval, and evaluation. Others in the same group: