Skip to main content
This guide shows you what changes in recall()’s output when include_global_context_index=True is set — both in the retrieved context and in the final generated answer.

Before You Start

Code in Action

What Just Happened

Step 1: Ingest a Multi-Hobby Dataset

Ten facts, two per hobby across five hobbies (hiking, sailing, baking, watercolor painting, German lessons) shared between Alice and Bob, each with a winter and a summer update. This is enough that a single retrieval pass can’t hold every hobby’s triplets at once — exactly the condition where the global context index has real work to do.

Step 2: Build the Index

Same mechanism as Building the Global Context Index — see that guide for how the bucket/root hierarchy actually forms. This guide only needs the finished index.

Step 3: Compare the Retrieved Context

top_k=4 deliberately restricts local retrieval to fewer triplets than the dataset has hobbies — low enough to make the effect in Step 4 obvious. Both calls retrieve the exact same Nodes: / Connections: block: include_global_context_index never changes which local triplets get selected, only what gets prepended before them. The only difference here is that World summary: and Relevant areas: appear only in the second call. As Global Context Index explains, this feature is meant for datasets large enough that local retrieval genuinely can’t hold everything relevant — long documents, project memory spanning many updates, policy corpora with many sections. Ten facts across five hobbies is nowhere near that scale on its own; the only reason it behaves like a large dataset here is that we’ve deliberately shrunk top_k to 4, well below what a real deployment would use. That’s an artificial constraint chosen to make the effect visible in a guide-sized example, not a recommendation to run production workloads with top_k this low. The root itself isn’t a way around this at any scale, either: World summary is capped at a fixed token budget (the prompt that generates it caps output at 500 tokens), so on a genuinely large dataset it can’t just list every fact losslessly — it has to compress. At real scale, expect the root to reliably preserve which hobbies and topics exist (cheap to list) while individual details, like a specific summer milestone, are more likely to survive in Relevant areas instead — the vector-matched, topic-specific bucket summaries have their own budget per bucket, so they carry more per-topic detail than one root summary stretched across everything.

Step 4: Compare the Generated Answers

This is where the difference stops being cosmetic. With top_k=4, the local retrieval in Step 3 can only surface a fraction of the dataset’s triplets — and since that local set is identical either way, the generated answer without the index inherits that gap directly: The answer without the index only mentions hiking and watercolor painting — it never mentions Alice’s German lessons, never mentions her sourdough baking, and never mentions Bob’s sailing, three of the five hobbies vanish. The answer with the index names all five and still tracks each one’s winter-to-summer progression, because World summary is built once over every TextSummary in the dataset — it doesn’t compete for a spot in top_k the way local triplets do.
This is real output from one run against an LLM, so if you run it yourself, expect the wording and the exact count of missing hobbies to differ — LLM generation isn’t deterministic, and top_k=4 is a hard cutoff on vector similarity scores, so a hobby hovering right at that boundary can land on either side of it from one call to the next. The pattern is what’s stable and worth taking away: some hobbies reliably vanish without the index, and none do with it — not the specific count above. Raising top_k high enough eventually closes this particular gap on its own; the index is what keeps working when you can’t or don’t want to raise it that far.

Under the Hood

  • The root is loaded, never searched: a dataset has at most one root GlobalContextSummary, and recall() loads it straight from the graph — filtering the dataset’s GlobalContextSummary nodes for the one flagged is_root — instead of running a vector search for it. This becomes the World summary: line.
  • “Relevant areas” comes from one flat vector search: every non-root bucket lives in the same vector collection, embedded when it was created. Finding the global_context_index_top_k “Relevant areas” is a single vector search across that whole collection, comparing every bucket directly against the query — not a walk down from the root through parent-child links.
  • Why top_k doesn’t affect the index: top_k only bounds the local triplet search (Step 3). The root load and the bucket vector search are separate lookups that always run in full, regardless of how restrictive top_k is — that decoupling is exactly why the index keeps covering every hobby in Step 4 even as local retrieval covers fewer and fewer.
  • HYBRID_COMPLETION honors this too: the same include_global_context_index flag works with SearchType.HYBRID_COMPLETION, which places the same prelude under a ## Global context heading at the top of its context block instead of a World summary: line.

Global Context Index

The full concept, configuration options, and when to use it

Building the Global Context Index

Build the index and see it update incrementally

Recall

Understand recall()‘s full parameter surface and auto-routing behavior