GraphRAG — when relationships matter

Standard RAG returns chunks. Some questions need a graph.

GraphRAG flow (Microsoft popularised):
1. Extract entities + relationships from chunks (LLM extraction)
2. Build a knowledge graph (nodes = entities, edges = relationships)
3. Cluster the graph; summarise each cluster
4. Retrieve via the graph (entity + neighbourhood) plus chunks

Wins on: 'tell me about X and everyone connected to X', 'summarise themes across the corpus', 'who else does Y'.

Loses on: 'cost more compute upfront, often 5-10x indexing time'. Not free.

When standard RAG suffices:
- Q&A over docs without complex entity webs
- Customer support, product docs, code search
- Any 'find the right paragraph' task

When GraphRAG earns its cost:
- Investigations across many connected entities
- Research across a knowledge corpus
- 'who else, when, with whom' questions

Cost matrix: LLM tokens for extraction (one-time), graph storage, more complex retrieval. Try standard RAG + reranker first. Switch to GraphRAG when those plateau.

Ask the LLM to extract triples (subject, relation, object) from a chunk. Store as edges. Query later with neighbourhood expansion.

The full GraphRAG flow has community summaries on top of this — but the triple extraction is the foundation.

For >100k triples, in-memory dicts hurt. Production-grade graph stores:

- neo4j — most popular; cypher query language
- memgraph — Cypher compatible, faster for some workloads
- TigerGraph — scale-out

Integrations with LangChain / LlamaIndex exist for all. The smallest possible Cypher query gives you a node + neighbours faster than scanning a Python dict.

Day 69 done.

- GraphRAG = entities + relationships
- Standard RAG first; graph for hard cases
- 18-line triple extraction
- Use neo4j/memgraph at scale

Tomorrow (Day 70): the production RAG checklist + week 10 wrap.