Opening — Why this matters now
Enterprise teams didn’t adopt RAG to win leaderboard benchmarks. They adopted it to answer boring, expensive questions buried inside spreadsheets, PDFs, and contracts—accurly, repeatably, and with citations they can defend.
That’s where things quietly break. Top‑K retrieval looks competent in demos, then collapses in production. The model sees plenty of text, yet still misses conditional clauses, material constraints, or secondary scope definitions. The failure mode isn’t hallucination in the usual sense. It’s something more procedural: the right information exists, but it never makes it into the context window in the first place.
This paper argues—correctly—that retrieval isn’t the problem anymore. Context construction is.
Background — What existed before (and why it plateaus)
Modern RAG pipelines inherit a simple assumption from classical IR: rank passages by relevance, take the top‑K, and let the model sort it out. BM25, dense embeddings, hybrid retrievers—pick your weapon. They all end the same way: a flat list of chunks.
That approach works when:
- Documents are short.
- Information is localized.
- Redundancy is cheap.
Enterprise documents violate all three.
Scope definitions span multiple sheets. Conditions hide in annexes. Material constraints live far from headline sections. Top‑K retrieval keeps pulling near‑duplicates from the same region because relevance scores reward lexical proximity, not semantic complementarity.
Diversity methods like MMR or DPPs try to patch this, but they operate at a single granularity and bury decisions inside probabilistic machinery. You get less duplication, not better structure. And you certainly don’t get auditability.
Analysis — What the paper actually does
The central move here is reframing context selection as a constrained optimization problem, not a ranking problem.
Instead of asking “Which chunks are most relevant?”, the system asks:
- Which chunks add new information?
- Which sections must be represented?
- How much budget should each structural unit consume?
- Why was each chunk accepted or rejected?
The answer is the Context Bubble.
The Context Bubble in plain terms
A context bubble is a compact, structured bundle of evidence assembled under explicit rules:
-
Structure‑aware scoring Chunks carry metadata: section, sheet, role. Sections like Scope of Works or Products receive deterministic priors. Relevance isn’t purely lexical anymore—it’s contextual.
-
Strict token budgeting There is a global budget and per‑section budgets. No single section is allowed to dominate the context window by brute relevance.
-
Deterministic diversity control Redundancy is measured directly via lexical overlap thresholds. If a chunk mostly repeats what’s already selected, it’s rejected. No sampling. No black boxes.
-
Greedy but auditable selection Every candidate passes through the same gates. Each decision is logged: relevance score, structural boost, overlap, budget failure.
What emerges is not “the top passages,” but a coherent evidence pack that mirrors how a human expert would assemble supporting material.
Findings — Results that actually matter
Under a fixed 800‑token budget, the differences are stark:
| Method | Tokens Used | Sections Covered | Avg Overlap |
|---|---|---|---|
| Flat Top‑K | 780 | 1 | 0.53 |
| + Structure | 610 | 2 | 0.42 |
| + Diversity | 430 | 3 | 0.35 |
| Context Bubble | 214 | 3 | 0.19 |
Even when all methods are forced to use the same 214 tokens, the Context Bubble still covers more sections with far less redundancy.
The implication is uncomfortable for traditional RAG design: better answers came from using less text, not more.
Qualitatively, the selected context looks like this:
| Section | Purpose | Tokens |
|---|---|---|
| Scope of Works | Primary definition | 150 |
| Below Grade | Conditional constraints | 52 |
| Products | Material limits | 12 |
This is exactly how domain experts reason—primary scope, then conditions, then materials. Flat retrieval almost never produces this distribution by accident.
Implications — Why this changes how RAG should be built
Three implications stand out.
First, auditability is no longer optional. Enterprise users don’t just want answers. They want to know why a passage was included and why another was excluded. Context bubbles make retrieval decisions inspectable objects, not hidden side‑effects.
Second, token efficiency is a governance issue. Costs, latency, and failure rates scale with context size. Systems that treat the context window as an unpriced dumping ground will age poorly.
Third, structure beats scale. Throwing bigger models or longer contexts at poorly assembled evidence does not fix fragmentation. It amplifies it.
This work quietly suggests a future where RAG pipelines resemble policy engines more than search engines.
Conclusion — Retrieval grew up
This paper doesn’t introduce a flashy model or a clever embedding trick. It does something more disruptive: it declares that context is a first‑class artifact.
By treating context construction as a constrained, auditable selection problem, Context Bubbles outperform flat retrieval while using a fraction of the tokens. More importantly, they restore a missing property in enterprise AI systems: explainable information flow.
If RAG is going to survive contact with real organizations, this is the direction it will move—whether vendors admit it or not.
Cognaptus: Automate the Present, Incubate the Future.