Use entities and relationships when chunk search is not enough.
Graph RAG is for connected evidence, not for every knowledge base.
Learners distinguish lookup questions from relationship questions.
Why this matters: This prevents overbuilding graph pipelines for simple factual search.
Problem anchor: an operations lead asks which product features depend on a vendor whose contract is expiring. No single policy page says the full answer. The evidence is spread across architecture notes, vendor docs, feature ownership pages, and incident records.
Classic vector search can retrieve related chunks, but it may not connect vendor, service, feature, team, and incident into a defensible chain. Graph RAG makes those connections retrievable.
The corpus contains docs for AuthFlow, Billing, VendorX, and incident postmortems. A graph extracts nodes for services, vendors, teams, and incidents, with edges such as DEPENDS_ON, OWNS, and MENTIONED_IN.
A query for “What breaks if VendorX sunsets the embeddings endpoint?” seeds VendorX, expands to dependent services, then retrieves source chunks for each edge. The final answer cites paths, not only passages.
Graph structure is useful only when every important edge can be audited.
Learners add provenance to graph nodes and edges.
Why this matters: Without provenance, graph summaries become another source of ungrounded claims.
An LLM-extracted edge like “Billing DEPENDS_ON VendorX” is a claim, not a fact by itself. It needs source chunk IDs, extraction date, confidence, and ideally the exact sentence or table row that supported it.
Entity resolution is a major failure point. “OpenAI,” “Open AI,” and “the model vendor” may refer to the same entity in one corpus and different entities in another. Bad merges poison graph traversal.
A source chunk says “Billing uses VendorX embeddings to classify invoice disputes.” The graph stores Service:Billing, Vendor:VendorX, Capability:invoice dispute classification, and an edge Billing USES VendorX with the source chunk ID.
At answer time, the generated explanation cites the source chunk behind the edge, not the graph database alone. If the source changes, the edge can be re-extracted or retired.
The query should decide how much graph expansion is warranted.
Learners design query plans for graph-backed retrieval.
Why this matters: Using graph traversal for every query increases cost and can pull weak context.
A graph query usually needs seed entities. Seeds can come from entity linking in the user question, vector retrieval over entity descriptions, or classic retrieval over chunks that mention candidate entities.
Expansion should be bounded: max hops, allowed edge types, freshness filters, and source permissions. Otherwise the graph can wander into weakly related neighborhoods and flood the prompt.
| Option | Path | Best for | Risk | When to choose | Cost | Complexity |
|---|---|---|---|---|---|---|
| Vector only | Retrieve chunks directly by semantic similarity. | Single-source lookup or ordinary Q&A. | Misses relationship chains. | Use for simple factual questions. | Low | Low |
| Graph seeded by entities | Link entities, expand edges, retrieve provenance. | Ownership, dependency, compatibility, influence. | Alias errors and over-expansion. | Use for relationship questions. | Medium | High |
| Vector seeds plus graph expansion | Use retrieved chunks to find seed entities, then expand. | Messy natural-language questions. | Bad first-stage retrieval biases the graph walk. | Use when entity names are implicit. | Medium | High |
Graph RAG needs explicit limits that traces can show.
Learners implement a minimal graph neighborhood expansion.
Why this matters: Bounded traversal prevents weakly connected nodes from flooding context.
Max hops, edge types, confidence thresholds, and provenance filters are as important as vector top-k. They decide what the generator can see.
Spaced recall: from chunking, source chunk IDs still matter. Graph expansion should bring back the text behind edges, not just node names.
edges = {
"VendorX": [("used_by", "Billing", "chunk_vendor_billing")],
"Billing": [("owned_by", "PaymentsTeam", "chunk_billing_owner"), ("powers", "InvoiceDisputes", "chunk_invoice")],
}
def expand(seed, max_hops=2, allowed={"used_by", "owned_by", "powers"}):
frontier = [(seed, [])]
seen = {seed}
evidence = []
for _ in range(max_hops):
new_frontier = []
for node, path in frontier:
for rel, target, source in edges.get(node, []):
if rel not in allowed or target in seen:
continue
seen.add(target)
next_path = path + [(node, rel, target)]
evidence.append({"target": target, "path": next_path, "source": source})
new_frontier.append((target, next_path))
frontier = new_frontier
return evidence
print(expand("VendorX"))InvoiceDisputes appears through VendorX -> Billing -> InvoiceDisputes, and the trace keeps the source chunk behind each edge.
Graph RAG quality depends on extraction, resolution, traversal, and synthesis.
Learners evaluate Graph RAG with path-level faithfulness.
Why this matters: A fluent answer can hide a wrong edge or overextended traversal.
Graph RAG adds new failure modes: false extracted edges, duplicate entity merges, stale relationships, over-broad community summaries, and path expansion that looks connected but does not answer the question.
Evaluation should ask: Did the system choose the right seed? Were the traversed edges correct? Did the answer cite the source behind each relationship? Did the model overstate a weak path?
Inspect both graph evidence and final language.
Retrieval prompt: rebuild Graph RAG by naming entities, edges, provenance, seed retrieval, path expansion, community summaries, and the failure mode each step introduces.
Choose a corpus where answers depend on relationships, such as vendor dependencies or research-paper claims. Sketch entities, edge types, provenance fields, seed retrieval, max-hop expansion, and three questions classic RAG misses. Next rung: evaluate graph answers for faithfulness.
A user asks: 'Which executives at Acme Corp have worked with suppliers flagged for compliance issues?' Why does classic RAG struggle with this question?
Classic RAG retrieves chunks similar to the query but cannot follow multi-hop entity relationships (executive → company → supplier → compliance flag) that span separate documents.
During graph construction, two documents mention 'J. Smith, CTO' and 'Jane Smith, Chief Technology Officer' separately. What problem does this illustrate, and what must the pipeline do?
Entity resolution is the task of determining whether different surface forms refer to the same entity; failing to resolve them correctly creates duplicate or split nodes that corrupt graph traversal.
You are planning a Graph RAG query for: 'What regulations affect the subsidiaries of GlobalBank?' Describe, in 2–3 sentences, how you would seed the graph traversal and what constraints you would apply to keep the retrieved context focused.
Effective query planning seeds traversal from query entities, restricts hop count, and filters by relevant relationship types so the retrieved subgraph stays focused and fits in context.
In a bounded graph expansion, you start from a seed node and allow a maximum of 2 hops. Which set of nodes is guaranteed to be included in the expanded subgraph?
A bounded expansion with max_hops=2 includes the seed, its 1-hop neighbors, and their 1-hop neighbors (2 hops total), subject to any relationship-type filters — no more, no less.
A Graph RAG system confidently states that Person A reported to Person B, but the only supporting edge was extracted from a document that actually described a different organizational period. Which failure mode does this represent, and what is the appropriate mitigation?
False edges — edges that exist in the graph but are unsupported or contradicted by current source documents — are a Graph RAG-specific failure mode; tracing claims back to source-backed paths and adding a human review gate for high-stakes answers are the correct mitigations.