« Phase 06 README · Warmup · Deep Dive · Principal Deep Dive · Core Contributor · Staff Notes
Phase 06 — Hitchhiker's Guide
The compressed practitioner tour. Read the WARMUP for the derivations; this is the stuff you say in the meeting.
30-second mental model
Flat vector RAG (Phase 05) can only return chunks that exist, so it dies on questions where no single chunk has the answer: synthesis, global/thematic, multi-hop. Three fixes: RAPTOR pre-computes a tree of summaries and retrieves over the "collapsed tree" (all levels at once) so a synthesis query lands on a summary node. GraphRAG extracts an entity/relation graph, detects communities, and writes community summaries that a map-reduce answers global questions from. LightRAG is cheaper GraphRAG: dual-level (local + global) retrieval and incremental graph updates. The cost is the index, not the query. Default to flat RAG; climb the ladder by question shape.
The numbers / rules to tattoo on your arm
| Rule | Why |
|---|---|
| "no single chunk has the answer" | the trigger to leave flat vector RAG |
| RAPTOR: collapsed tree > tree traversal | query picks its own abstraction level; no mis-pruning |
| summary beats leaf: dot ~ n vs 1 | query shares all n distinctive terms with the summary, 1 with a leaf |
| GraphRAG's point = community summaries | not the graph DB — themes that live in no chunk |
| LightRAG = dual-level + incremental | local neighborhood + global themes, no full re-index |
| cost is at index time | LLM summary/cluster (RAPTOR), LLM extract/chunk + Leiden (GraphRAG) |
| Leiden for communities | modularity-maximizing, hierarchical, well-connected |
| pgvector (chunks+summaries) + Neo4j (graph) | hybrid; route query to the store whose index fits |
Framework one-liners
- Microsoft GraphRAG — extract → Leiden communities → community reports → global map-reduce / local search. The reference implementation of the pattern.
- LightRAG — dual-level keys (low = entities, high = themes) + incremental graph merge; far fewer LLM calls than full GraphRAG.
- RAPTOR — recursive UMAP+GMM cluster → LLM summarize → collapsed-tree retrieval; ships as a LlamaIndex pack and a LangChain cookbook.
- Neo4j
neo4j-graphrag— wires extraction, community detection, and retrieval to an LLM over a Neo4j graph; pgvector — Postgres extension holding chunk and summary embeddings. - All of them move work from query-time to index-time so a hard question becomes one cheap lookup against pre-computed abstraction (RAPTOR) or structure (GraphRAG).
War stories
- The "summarize the whole doc" ticket that vector RAG kept flunking. Top-k returned five chunks that each said "in v2 we…"; the arc was in none of them. RAPTOR's collapsed tree surfaced the pre-built summary node and the answer went from fragments to coherent in one index change.
- The GraphRAG bill nobody scoped. A team pointed GraphRAG at a 50k-document corpus and got a five-figure indexing invoice — one-plus LLM call per chunk for extraction, plus community reports — before answering a single question. The fix was to scope it: RAPTOR for the synthesis subset, LightRAG for the growing part, flat RAG for the fact lookups.
- The graph DB that changed nothing. Someone "did GraphRAG" by loading embeddings into Neo4j and running the same nearest-neighbor search. No community summaries, so global questions were as broken as before. The database isn't the feature; the summaries are.
Vocabulary
Synthesis / global / multi-hop question (the three failure shapes) · RAPTOR (recursive
summary tree) · collapsed tree vs tree traversal · leaf vs summary node ·
GraphRAG · triple (subject, relation, object) · knowledge graph · community
detection (connected components / label propagation / Leiden) · community summary ·
global (map-reduce) vs local (neighborhood) search · LightRAG (dual-level, incremental)
· Neo4j / Cypher · pgvector · hybrid store.
Beginner mistakes
- Tuning chunk size and
kfor a question that no chunk can answer (change the architecture). - Thinking GraphRAG = "vectors in a graph database" (it's the community summaries).
- Treating RAPTOR as one flat layer of chunk summaries (it's a recursive tree + collapsed retrieval).
- Reaching for GraphRAG by default — it's the most expensive index on the ladder.
- Forgetting the cost is at index time, and not pricing it before the design review.
- Ignoring corpus freshness — a growing corpus wants LightRAG's incremental updates, not a nightly full re-index.
- Over-deepening the tree / over-splitting communities past the point of coherent themes.