GraphRAG Use Cases

Plain RAG is the right default. GraphRAG earns its cost only when the question shape forces you to join facts across documents. This page is a catalogue of patterns where that's true, with example questions and the kind of graph structure you'd expect to see populated for each one.

For the implementation details see GraphRAG entity model. For the decision rule of plain RAG vs GraphRAG see GraphRAG overview.

Pattern 1 — Product knowledge across docs

Where it lives: internal product docs, support articles, changelogs.

Example questions:

• "How does our PrestaShop connector relate to the v1 API?"
• "Which features depend on the wallet module?"
• "What did we ship between v2.4 and v2.6 that touched search ranking?"

What the graph captures:

GraphRAG hops from the question's anchor entity to its relations and pulls evidence chunks from each. Plain RAG would need to retrieve all relevant chunks via a single similarity score — which usually surfaces the obvious documents but misses the deprecation chain.

Pattern 2 — Support and troubleshooting

Where it lives: runbooks, post-mortems, support macros.

Example questions:

• "If the public search endpoint is returning 429s, which downstream services should I check?"
• "What's the failure mode that breaks reindex and how have we recovered from it before?"
• "Which alerts have fired for the wallet ledger in the last 6 months?"

What the graph captures:

In troubleshooting, the operator's mental model is exactly a graph: a symptom node → likely cause nodes → mitigation nodes. GraphRAG mirrors that traversal naturally. Plain RAG can get there if the post-mortem is comprehensive, but most aren't.

Pattern 3 — Compliance and audit

Where it lives: policies, DPA / SOC 2 evidence, security questionnaires.

Example questions:

• "Which controls cover personal-data processing in the wallet ledger?"
• "What evidence do we have for SOC 2 CC6.1 — logical access?"
• "Which third-party processors do we use for AI features?"

What the graph captures:

Compliance questions are unforgiving: the answer must cite the document, not just summarise it. GraphRAG's evidenceChunkId makes the path inspectable: every cited claim resolves back to a chunk and the chunk back to a document.

For SOC 2 / DPA scope and how this maps to data residency, see Security & Compliance.

Pattern 4 — Customer cases and references

Where it lives: sales decks, case studies, customer wikis.

Example questions:

• "Which customers in the retail vertical used scoped tokens?"
• "Show me cases where we hit > 100 RPS sustained on a single index."
• "Who on our side worked with Acme on the Bitrix migration?"

What the graph captures:

Sales / customer-success teams ask multi-entity questions constantly. Plain RAG works when one doc covers the whole case; GraphRAG works when the answer is spread across an account note, a case study, and a Slack archive.

Pattern 5 — Architecture and dependency tracing

Where it lives: architecture docs, ADRs, runbooks.

Example questions:

• "If we rip out the wallet module, what else breaks?"
• "Which modules import from @repo/search?"
• "Trace the auth flow from cookie to oRPC procedure."

What the graph captures:

GraphRAG plus a documentation-as-code workflow (the docs in this site, frozen into Knowledge spaces) makes "what breaks if I change X?" answerable without spelunking the code itself. Refresh the graph by re-ingesting the docs after every release.

Pattern 6 — Education and onboarding

Where it lives: onboarding docs, how-tos, glossaries.

Example questions:

• "What do I need to know about scoped tokens before I touch widget auth?"
• "Walk me through the lifecycle of a reindex."

These are sequential, "give me the path" questions. GraphRAG's path output (the (from, relation, to) chain returned by graphragExplain) doubles as a learning aid — the UI can render the chain as a guided tour rather than just an answer paragraph.

When the graph is empty

If you've enabled GraphRAG on a fresh space and the answer paths come back empty, three usual causes:

1. Ingest didn't run the graph build. Check IngestionJob.inputMeta.graphBuilt: true. If not, KnowledgeSpace.ragConfig.graphragEnabled was off when the source was ingested.
2. Too few documents. With < 20 sources, you won't have enough entity overlap to form interesting relations. Plain RAG is fine until then.
3. Heavily image-based content. OCR is roadmap; without text the entity-resolution pass has nothing to chew on.

A quick smoke test: count the rows in graph_edge for the space. Under 50 edges → not enough graph to matter.

What GraphRAG isn't good at

• Numerical aggregation. "Total revenue from cases tagged X" is a database query, not a graph query.
• Long causal chains. Multi-hop > 2 is roadmap; the current implementation will miss "A → B → C → D" answers.
• Real-time data. The graph is a snapshot at ingest. For live data, use the underlying storefront / API and not Knowledge.

Related pages

• GraphRAG overview
• GraphRAG entity model
• Knowledge RAG overview
• Knowledge evaluation — measuring whether the graph actually helps