Skip to content

Chapter 2.9 — GraphRAG and Knowledge Graphs

🎯 Objective

Present GraphRAG as a complement — not a replacement — to textual RAG, with a clear criterion for when it is worth paying the cost of maintaining a graph.

🧠 When GraphRAG makes sense

  • Multi-hop questions ("who approved what that affects what").
  • Relational compliance (lineage of decisions, dependency between contracts, the impact of one clause on others).
  • Investigation (root cause, fraud, security, audit).
  • Structural explainability (showing the "path" that connected A to B).

When it does not make sense:

  • A small, relatively flat corpus.
  • Predominantly "find the passage that talks about X" questions.
  • A team without an organizational mandate to curate the ontology.

🧠 Components

  • Knowledge graph. Entities, relations, properties.
  • Property graph (Neo4j, openCypher). A pragmatic, widely used model.
  • Ontology (optional). RDF/OWL for formal semantics and inference.
  • Construction. NER + relation extraction + human curation. The automatic part is necessary; the human part is what separates a useful graph from a graph full of noise.
  • Querying. Cypher, SPARQL or Gremlin.
  • Subgraph summarization. Linearizing the relevant subgraph to send to the LLM as context.

🧠 Usage patterns

  • Hybrid RAG + Graph. Textual RAG retrieves passages; the graph retrieves relations; the prompt combines the two.
  • Graph-first for structured questions, RAG for textual questions. The router decides where it goes.
  • Graph as a filter. The graph restricts the universe (e.g., "only contracts from tenant X signed after Y"), and textual RAG delivers the content.

⚠️ Cautions

  • Maintaining the graph is expensive. Automatic extraction produces noise; curation is continuous work.
  • Quality depends on governance. Without an owner of the schema, the graph rots within months.
  • GraphRAG does not replace textual RAG for most cases; it complements it.
  • Promises of "symbolic reasoning" via graph still lack robust empirical support for most production cases; treat it as an enriched retrieval heuristic, not a solver.

📚 References