GraphRAG — Patterns

Hierarchical region summaries read top-down

Problem. A question about an entire corpus has no passage-level answer, and assembling one from thousands of documents at query time is not affordable at interactive latency.

Approach. Detect densely connected regions of the graph, summarise each one at build time, and summarise groups of those summaries into higher levels. A corpus-wide question is answered by reading the small number of summaries at an appropriate level and combining them, with the level chosen from the breadth of the question rather than fixed.

Trade-off. Every summary is a lossy, model-written account that cannot be quoted, and the higher the level the further it is from anything a reader can verify. Keeping the hierarchy current after ingestion is the hard part: a single new document can belong to a region whose summary and whose parents are all now out of date.

Seed entities from passage retrieval, expand under a degree cap

Problem. Entering a graph requires knowing which nodes the question is about. Linking free text to entities is its own error-prone step, and a wrong seed makes every subsequent hop wrong with no recovery.

Approach. Retrieve passages conventionally first, take the entities those passages are annotated with as the seed set, and expand from there. Cap expansion by hop count and by node degree, skipping or down-weighting hubs whose neighbourhood is too large to be informative. The seeds are then grounded in material that actually matched the query, and the passages are available as evidence alongside the structure.

Trade-off. The graph can now only reach what passage retrieval found, which forfeits part of the reason for having a graph. Degree caps also discard exactly the central entities that some questions are about, and the cap has to be a tuned number rather than a principled one.

Edge-level lineage to source spans

Problem. An answer assembled from traversal or from region summaries has nothing a reader can open. Without lineage the product either shows no sources or shows the documents a summary was derived from without being able to say which sentence supported which claim.

Approach. Record, on every node, edge and summary, the identifiers and spans of the passages that asserted it, and propagate those identifiers through each summarisation level so a top-level statement resolves to a set of source spans. Answers cite the spans, not the summaries, and a claim whose lineage set is empty is treated as unsupported.

Trade-off. Lineage grows faster than the graph — a widely asserted relation accumulates thousands of supporting spans — so it needs its own storage strategy and some form of sampling or capping, which weakens the guarantee. Propagation through several summarisation levels also tends to produce large, diffuse citation sets that are technically correct and unhelpful to a reader.

Graph as a second arm, selected by question shape

Problem. Traversal is slower and more expensive than passage retrieval and is worse at the lookup questions that dominate most traffic. Running it on everything degrades the common case to improve a minority of queries.

Approach. Keep passage retrieval as the default and invoke the graph when the question has a shape it serves: aggregate or thematic phrasing, a relation between two named entities, or an explicit request for connections. Where both run, present their results as separate evidence sets rather than merging them, since a summary and a passage are different kinds of claim.

Trade-off. The shape detector is another classifier with its own errors, and a corpus-wide question misrouted to passage retrieval gets a confidently arbitrary answer. Keeping the two evidence sets separate also pushes the reconciliation problem onto the answer layer, which may simply prefer whichever is listed first.