When questions need a graph

A chunk store finds passages that look like the question. It does not know that Brightwater Lines runs the Rotterdam–Santos lane, that its 2026 contract supersedes the 2024 one, or that three other carriers also serve Santos. Ask "which carriers into Santos have a late-delivery cap below 10%?" and it returns the most similar-looking clauses, often from the wrong carrier, and the model writes a confident answer. A knowledge graph stores entities and typed relationships explicitly, so the question becomes a traversal with a correct, complete, citable answer. The cost is real: you design a schema, extract and resolve entities (often with LLMs), keep the graph in sync, and own its quality. GraphRAG (Microsoft, Edge et al. 2024) goes further, clustering the extracted graph into communities and pre-summarising them to answer corpus-wide "what are the themes?" questions. Build a graph when relationships drive the questions and someone will own the schema; otherwise, use SQL or plain RAG.

Key takeaways:

• Graphs win on multi-hop, aggregation, completeness ("all carriers that…") and relationship questions. Chunk stores win on "what does the document say about…".
• The schema is the product. Design node labels and relationship types from the questions users ask, not from what an LLM happens to extract.
• Entity resolution decides whether the graph is usable. "Brightwater Lines B.V.", "BRIGHTWATER LINES" and "Brightwater" must be one node.
• Hybrid retrieval is the common production pattern: vector search to find entry points, graph traversal to expand and constrain.
• GraphRAG-style indexing is expensive (LLM calls over the whole corpus, plus community summaries). Pilot on a slice and measure before committing.