« Phase 06 README · Warmup · Hitchhiker's · Deep Dive · Principal Deep Dive · Core Contributor

Phase 06 — Staff Engineer Notes: Advanced Retrieval (GraphRAG & RAPTOR)

The other three docs are about mechanism, economics, and the real systems. This one is about judgment: what separates an engineer who can use GraphRAG/RAPTOR from the one an organization trusts to own the decision to adopt it. The difference is not knowing more algorithms. It is knowing when the answer is "no, we don't need it" and being able to defend that in a room where someone senior wants the impressive architecture.

The decision is "should we," not "how"

Anyone can wire up Microsoft GraphRAG from the docs. The skill the JD is actually naming — and the thing an architecture review is listening for — is the ability to look at a workload and say which rung of the ladder it belongs on, with the cost number attached. The ladder, and the trigger for each rung:

  • Flat hybrid RAG (Phase 05) — the default. Fact lookup, "what does this chunk say" questions, anything where the answer sits in some existing chunk. Cheap to index, cheap to query. The overwhelming majority of real workloads live here. Reaching past it should require justification.
  • RAPTOR — synthesis over a bounded set of documents. "Summarize how this evolved," "give me the arc." The answer is a fusion of chunks and RAPTOR precomputes the fusion. Moderate index cost (one summary per cluster per level), same cheap query.
  • LightRAG — local + global over a corpus that grows. The dual-level retrieval gives you most of GraphRAG's benefit, and the incremental insert is the thing that makes a daily-growing corpus viable. This is the cost-aware middle option most candidates forget exists.
  • GraphRAG — genuinely global/thematic and multi-hop questions over a large, static corpus. The heaviest index on the ladder; it earns that only when the workload is dominated by questions flat RAG structurally cannot answer and the index amortizes over many queries.

The framework in one sentence: choose by question shape, and price the index. A staff engineer does not say "GraphRAG is state of the art, let's use it." A staff engineer says "what fraction of our questions are actually global or multi-hop, how big and how fresh is the corpus, and what is the indexing bill — because for a static corpus of global questions GraphRAG earns its cost, and for a growing corpus of fact lookups it is a six-figure mistake." That reframe is the seniority signal.

The signal interviewers and reviews actually listen for

There is one sentence that instantly sorts the pool: "all three of these exist because flat vector RAG cannot answer a question when no single chunk contains the answer." Candidates who lead with the acronyms sound like they read the same job posting as everyone else. The candidate who states the why underneath — and then can name which failure shape (synthesis / global / multi-hop) maps to which fix — is demonstrating understanding, not vocabulary. Lead with the why.

The second, higher-value signal is the GraphRAG misconception, killed cleanly. Half of the people who list GraphRAG believe it means "store your vectors in Neo4j instead of Postgres." It does not, and the difference is the whole point: GraphRAG's value is the community summaries — LLM-written text, generated at index time, stating themes that appear in no source chunk — and the graph database is almost incidental. An engineer who can say "if you just put embeddings in a graph store you've built a slower vector store; the feature is the summaries" has separated themselves from the pool in one sentence. This is the moment reviewers sit up.

The third signal is volunteering LightRAG unprompted as the cost-aware option. Most people know GraphRAG and RAPTOR. Fewer can cleanly say why LightRAG exists — dual-level retrieval plus incremental updates so a new document doesn't force a full re-index — and connect it to operations and cost. Bringing that up before you're asked demonstrates you think about running the system, not just its accuracy. That is exactly the "cost, operations, and scalability" language these roles put next to the platform.

Code-review red flags

When you review a GraphRAG/RAPTOR change, these are the tells that the author is using the architecture without owning it:

  • No index-cost estimate in the design doc. If a proposal to adopt GraphRAG does not contain tokens_per_chunk × chunks × passes and a re-index cadence, it is not a proposal, it is a liability. Send it back for the number.
  • GraphRAG chosen for a fact-lookup workload. If the questions are "what port does this listen on," the graph is expensive decoration. Flat RAG is the correct, cheaper answer.
  • No entity-resolution strategy. If nobody has thought about Stripe vs stripe_gateway vs the gateway collapsing to one node, the graph will fragment and multi-hop answers will be silently wrong. This is the first question, not an afterthought.
  • Community summaries treated as free / trusted blindly. The summary is the source for a global answer; there is no chunk to fact-check it against. A review that doesn't ask about summary provenance and drift is missing the highest-blast-radius failure mode.
  • A full re-index on a growing corpus. If documents arrive daily and the plan is nightly full GraphRAG re-index, someone hasn't priced it. That is where LightRAG's incremental path belongs.
  • RAPTOR implemented as one flat layer of chunk summaries. That misses the recursion and the collapsed-tree head-to-head ranking. It's a summary index, not RAPTOR.

War stories

  • The six-figure indexing bill nobody scoped. A team pointed Microsoft GraphRAG at a ~50k-document corpus because it was "state of the art," and got a five-to-six-figure invoice — one-plus LLM call per chunk for extraction, gleanings on top, then community reports — before answering a single question. The fix was not tuning; it was scoping: RAPTOR for the synthesis subset, LightRAG for the growing part, flat RAG for the fact lookups. Same corpus, right rung per question shape, a fraction of the bill.
  • The graph nobody could refresh. A beautifully built GraphRAG system shipped against a corpus that grew daily. Full GraphRAG's Leiden + community-report pass is a global computation, so every update meant a full re-index the team could not afford to run nightly. The graph slowly went stale, answers drifted from reality, and "the system doesn't know about today's incident" became a standing complaint. The lesson: freshness is a design constraint priced at adoption time, and it is precisely what LightRAG's incremental insert is for.
  • The graph database that changed nothing. Someone "did GraphRAG" by loading embeddings into Neo4j and running the same nearest-neighbor search. No community summaries, so every global question was as broken as before — now with more infrastructure. The database was never the feature. The summaries are.
  • The subtly-wrong multi-hop answers. A demo looked flawless until the multi-hop answers were quietly incorrect. Root cause: the extractor missed a class of relations, so edges that should have existed did not, and the agent confidently walked the wrong path. Extraction quality is the ceiling of the whole system, and it is the least glamorous part — when a GraphRAG demo is subtly wrong, look at the extractor first.

Closing takeaways

  • "No single chunk has the answer" is the trigger — and saying it out loud, then naming the matching architecture, is most of the interview and most of the design review.
  • Choose by question shape, price the index. Flat RAG is the default; RAPTOR, LightRAG, and GraphRAG are three progressively more expensive rungs you climb only when the shape demands it. The cost lives at index time, and pricing it is the staff-level contribution.
  • GraphRAG's feature is community summaries, not the graph database. Miss that and you've built a slower vector store. State it and you're in the top slice of the pool.
  • LightRAG is the "do we actually need the cathedral" answer. Dual-level retrieval plus incremental updates — the cost-aware middle option that keeps a growing corpus viable.
  • Extraction quality and entity resolution are the ceiling. The unglamorous parts decide whether the graph answers multi-hop questions or quietly returns garbage. Owning them is what makes you the person handed "make this production-ready" rather than the one who built the demo.