In graph RAG, when do you route a query to community summaries instead of entity traversal?

## Two questions that look alike and are not Consider a decade of an NGO's field reports. "What did the water programme in the eastern districts report about borehole maintenance?" and "What themes recur across all regions over the decade?" are both retrieval questions over the same corpus, but they need structurally different retrieval. The first has an **anchor**: named entities that exist as nodes. The second does not. It is a question about the corpus in aggregate, and there is no chunk, and no small set of chunks, that represents an aggregate. This is the local/global split, and it is the main architectural idea a graph index buys you beyond multi-hop traversal. ## Local queries: anchor, expand, answer A local query is answered by resolving the entities in the question to nodes — usually via similarity search over node names and their generated descriptions, since users rarely type canonical names — then expanding into the neighbourhood. You collect the neighbouring entities, the relations connecting them, and the source text snippets each relation was extracted from, and hand that bundle to the model. The knobs are hop depth, how many neighbours to keep per hop, and whether to filter by relation type. Two hops is generally as far as you go before the neighbourhood grows faster than the context budget. Local retrieval is cheap: it touches a small part of the index and reads a bounded amount of text. ## Global queries: cluster, summarise, map-reduce A global query cannot be answered by reading a neighbourhood, and reading the whole corpus per query is unaffordable. The standard construction moves the work to build time. After entities and relations are extracted, the graph is partitioned into **communities** — densely interconnected groups of entities — using a modularity-based clustering algorithm, most commonly Leiden. Because these algorithms produce a hierarchy, you get communities at several granularities: fine-grained clusters at the leaves, broad thematic groupings near the root. An LLM then writes a summary of each community from its member entities, relations and source snippets, and higher-level summaries are composed from the level below. At query time, a global question is answered map-reduce style: the question is applied against each community summary at the chosen level, producing partial answers with a self-reported usefulness score; low-value partials are discarded and the rest are reduced into a final answer. The corpus is therefore covered in aggregate — every region's reports contributed to some community summary — without reading it all per query. **Choosing the hierarchy level is the cost dial.** A high level means a handful of very broad summaries: cheap, fast, but coarse. A low level means many detailed summaries: better coverage and specificity, and many more LLM calls per question. This is a per-query-class decision, not a global constant. ## Routing between the two Routing is typically done by a small classifier, a prompt asking whether the question names specific entities and expects a specific fact, or by exposing both as tools to an agent and letting the model choose. Signals that a query is global: superlatives and aggregates ("most common", "overall", "recurring", "across"), an absence of resolvable entity mentions, and a request for themes rather than facts. Get routing wrong and the failure mode is characteristic and hard to spot. A **global query answered locally** returns a confident, well-sourced answer drawn from one anchor's neighbourhood — one region, one programme — presented as if it characterised the corpus. Nothing looks broken; the answer is simply unrepresentative. That is the more dangerous direction, because the output is fluent and cited. A **local query answered globally** fans out over community summaries, costs many times more, and returns generalities where the user wanted a specific fact, because summarisation has already discarded the detail. Because misrouting is silent, evaluation should include a labelled routing set and should score global answers on coverage — did the answer draw on multiple regions or only one — not just on fluency. ## Practical notes Hybrid routing is common: run local retrieval and, if the anchor resolution is weak or the answer is unsupported, fall back to global. Global answering is expensive enough that many systems cache answers per question class, or restrict global mode to an explicit "analyse the corpus" surface rather than the default chat path. And global mode is only as good as the community summaries, which are built once — if the corpus has grown substantially since the last clustering pass, global answers quietly reflect the older corpus.