« Track Overview · Warmup · Hitchhiker's · Deep Dive · Principal Deep Dive · Core Contributor · Staff Notes

Phase 06 — Advanced Retrieval: GraphRAG, LightRAG & RAPTOR

Answers these JD lines: Citi's Lead/Tech-Lead Agentic AI roles name this phase almost word-for-word — "Implement advanced retrieval architectures including GraphRAG, LightRAG, and RAPTOR-style hierarchical summaries" and "Integrate graph and vector databases such as Neo4j and pgvector" (jd.md). These three acronyms plus the two databases are on the keyword line of both Citi postings; this phase is where you earn the right to say them.

Why this phase exists

Phase 05 built the retrieval foundation — chunk, embed, hybrid (BM25 + dense) search, RRF fusion, rerank. That is the correct default, and it has a hard ceiling: it can only return chunks that already exist, so it fails on every question whose answer isn't sitting in a single chunk. Three question shapes break flat vector RAG, and each has a named fix:

• Synthesis over a long document — "summarize the trajectory of this 100-page report." No chunk is the summary. RAPTOR pre-computes summaries at every level of abstraction so retrieval can land on one.
• Global / thematic questions over a corpus — "what are the main themes across these 500 documents?" No chunk states the themes. GraphRAG builds a knowledge graph, detects communities of related entities, summarizes each, and map-reduces those summaries.
• Multi-hop / relational questions — "who owns the model that flags the payments that the gateway processes?" Flat search can't traverse. A graph can, and LightRAG's local retrieval walks the neighborhood cheaply.

The single sentence to carry out of this phase: "the answer isn't in any one chunk" is the signal to leave vector RAG and reach for a hierarchy (RAPTOR) or a graph (GraphRAG/LightRAG).

Concept map

• RAPTOR = recursive cluster → summarize → ascend into a tree; retrieve over the collapsed tree (all levels at once) so a query matches a leaf detail or a summary.
• GraphRAG = extract triples → build graph → detect communities (Leiden) → summarize communities → global (map-reduce over summaries) vs local (neighborhood) search.
• LightRAG = GraphRAG's cheaper cousin: dual-level local + global keys, incremental graph updates, far fewer LLM calls to index.
• The stores: pgvector holds chunk and summary embeddings (RAPTOR); Neo4j holds entities, relations, and community assignments (GraphRAG/LightRAG). Real systems use both.
• The tradeoff dial: vector RAG (cheap, local) → RAPTOR (mid, synthesis) → GraphRAG (expensive index, global). Cost lives in the indexing pass, not the query.

The lab

Integrated scenario (how this shows up at work)

An enterprise-knowledge agent must answer three questions over the same corpus: (a) "walk me through the Q3 incident retro," (b) "what are the recurring root-cause themes this year," and (c) "what does the payments-api service depend on." One retriever can't win all three. You route: (a) is synthesis over a long doc → RAPTOR collapsed-tree search surfaces the retro's summary node; (b) is global/thematic → GraphRAG map-reduces the community summaries of the incident graph; (c) is multi-hop/relational → LightRAG local query walks the service's neighborhood in the graph. Same corpus, three retrieval strategies, each chosen from the shape of the question — and you can defend the routing (and the indexing bill) with the Phase 00 cost lens. That routing judgment is the phase.

Deliverables checklist

• Lab 01 green under LAB_MODULE=solution pytest and your own lab.py.
• You can explain, from the bag-of-words math, why a RAPTOR summary node beats any single leaf on a synthesis query.
• You can explain GraphRAG's pipeline (extract → community → summarize → map-reduce) and why it answers a global question that vector RAG cannot.
• You can state what LightRAG changes vs GraphRAG (dual-level keys, incremental updates, cost) and where each maps to Neo4j / pgvector.
• You can pick the right architecture for a fresh question from its shape.

Key takeaways

• "No single chunk has the answer" is the trigger. That phrase, said out loud, is the senior move — it's when you leave flat vector RAG for a hierarchy or a graph.
• RAPTOR pre-computes abstraction; GraphRAG pre-computes structure. Both move work from query-time to index-time, which is why they're powerful and why their cost is the indexing pass, not the query.
• GraphRAG isn't "RAG plus a graph database." The point isn't storing vectors in Neo4j; it's community summaries that answer global questions. Miss that and you've built a slower vector store.
• LightRAG is the "do I really need full GraphRAG?" answer — dual-level retrieval and incremental updates at a fraction of the indexing cost.
• Choose by question shape, and price the index. Vector RAG is still the default; reach up the ladder only when the question demands it, and budget the (expensive) build.