A University of Wyoming production deployment shows RAG accuracy collapsing from 75% to under 40% as the corpus scaled past 1,000 documents — and the fix isn't a better embedding model, it's domain-scoped retrieval architecture.
Table of Contents #
Your RAG pilot hit 75% accuracy on a few dozen documents. Leadership approved the rollout. Six months later the corpus has grown tenfold, the embedding model hasn’t changed, the chunk size hasn’t changed, and accuracy on the exact same query types has fallen below 40%. Nobody touched the retriever. Nobody touched the LLM. The only thing that changed is that the index got bigger — which is supposed to be the safe direction to scale.
This is the failure mode most teams misdiagnose. They assume degradation at scale means the embedding model needs upgrading, or the chunking strategy needs rework, or the ANN index needs better recall tuning. A production case study out of the University of Wyoming’s Department of Transportation deployment, formalized in a paper on what the authors call “vector search dilution,” shows that none of those are the actual cause — and that the standard instinct for fixing it (throw a multi-agent retrieval pipeline at the problem) makes accuracy worse in a specific, measurable way before it gets better.
The Failure Nobody Names: Vector Search Dilution #
The WYDOT chatbot scaled its corpus from 54 to 1,128 documents — 88,907 chunks spanning construction specifications, design manuals, materials testing procedures, crash reports, and administrative reports. Accuracy on Standard-Specification queries dropped from 75% to below 40%. The retrieval stack used hybrid dense-plus-sparse search the whole time, and the approximate nearest neighbor index was returning its true nearest neighbors correctly. The neighbors were just wrong: semantically similar to the query, contextually irrelevant to it.
The researchers formalize this as a dilution factor, δ(q, k*) = 1 − P_global(q)/P_scoped(q), comparing how often a retrieval set actually pulls chunks from the query’s true target category when searching the whole corpus (P_global) versus when artificially restricted to just that category (P_scoped, which is ≈1 by construction). A δ near 0 means dilution isn’t happening. A δ approaching 1 means the retriever is returning almost nothing from the correct category, even though the embedder hasn’t gotten worse at its job.
The pattern that emerges is not uniform. Categories with thin chunk populations dilute hardest — Design Manual (1,405 chunks) measured δ=0.53, Standard Specs (2,519 chunks) measured δ=0.43 — while dense categories resisted it almost entirely: Construction Manual (6,641 chunks) sat at δ=0.10. The correlation between log(chunk count) and dilution ran ρ=−0.60 in the original WYDOT data and replicated at ρ=−0.68 to ρ=−0.95 across independent Caltrans and CDOT corpora. The mechanism is retrieval-time source confusion, not embedding quality: on a composite nine-domain benchmark, the probability that a retrieved chunk actually came from the query’s gold source category was only 0.59 under plain monolithic vector search — meaning four times out of ten, top-k was pulling from the wrong domain entirely, dressed up in cosine-similarity clothing that looked plausible.
This matters because it’s a semantic scaling problem, not an infrastructure one. Faster ANN indexes, bigger context windows, and better rerankers don’t touch it, because the retriever isn’t failing to find similar vectors — it’s succeeding, and similarity was never the same thing as relevance once the corpus spans heterogeneous document types. A traffic-crash-report chunk and a materials-testing-procedure chunk can sit close together in embedding space while answering completely different questions.
The Instinct to Fix It With More Agents Backfires #
The obvious enterprise architecture response to “retrieval is confused across domains” is to split the corpus by domain and hand each domain to its own retrieval agent — a multi-agent RAG pattern that’s become close to a default assumption in 2026 agent stacks. The research here is a useful check on that instinct, because it isolates exactly where multi-agent orchestration helps and where it quietly breaks something else.
Domain scoping itself works. Restricting retrieval to organizational metadata scopes — rather than filtering after the fact, or hoping the embedder sorts it out — improved P@10 from 0.77 to 0.86 (p<0.05) across 200 expert-validated queries, five LLM backbones, six corpora, and two index stacks (FAISS and Neo4j HNSW). Each domain-scoped agent cut its effective search space by 65–98%, a weighted average of 90.4%. That’s the fix that generalizes.
What doesn’t generalize cleanly is wrapping that scoping in full multi-agent orchestration — a planner dispatching to domain agents via function calling across multiple tool-call rounds. Under a commercial production stack (Gemini), multi-round orchestration dropped RAGAS faithfulness from 0.61 to 0.35 (p<0.01) even though retrieval precision was fine. The researchers call this the precision–faithfulness paradox: you can hand the model perfectly scoped, perfectly relevant chunks and still watch answer quality collapse, because the failure has moved from retrieval to synthesis. The model struggles to reconcile dense, near-duplicate passages pulled back from multiple parallel agent calls — and cross-encoder reranking, which does lift baseline faithfulness, does not recover this specific collapse, ruling out ranking noise as the cause. Critically, the paradox didn’t reproduce on an apples-to-apples open-source stack (Qwen2.5-7B, Llama-3-8B), which means this is a configuration-dependent failure mode, not an inherent property of multi-agent RAG — but it’s dependent on exactly the kind of backbone-and-orchestration combination most teams reach for by default.
The practical design principle the paper lands on: scope retrieval first, then run a single synthesis call. Reserve full multi-agent orchestration — separate planner, extractor, and synthesizer agents exchanging intermediate reasoning — for corpora that are genuinely multi-domain per query, paired with backbones that have strong native tool-calling behavior. Their own architecture, MASDR-RAG, reflects this restraint: it’s a single reasoning agent with K domain-scoped retrieval tools rather than K autonomous communicating agents, routed by a fast regex matcher with an LLM zero-shot classifier as fallback, capped at two LLM calls per query (one router, one synthesizer) instead of the up-to-five-round tool loop a full orchestrator would use.
Scope First, Orchestrate Only When You Must #
The decision that actually matters for an enterprise RAG architecture isn’t “vector database vs. graph vs. hybrid search.” It’s whether your corpus needs per-query multi-domain synthesis at all, and most enterprise corpora don’t — they need correct routing to the right domain, then one clean synthesis pass over correctly scoped evidence. Regulated, heterogeneous corpora (compliance docs, engineering specs, incident reports, financial filings) are exactly the shape where a query almost always maps to one domain, which is the shape where scope-then-synthesize wins and orchestration overhead only adds a new failure surface.
The signal to watch for is whether your synthesis failures track with agent fan-out. If accuracy drops specifically on queries that trigger multiple parallel retrieval calls — even when each call’s retrieved chunks are individually correct — you’re looking at a synthesis-stage collapse, not a retrieval-stage one, and adding a reranker or a bigger embedding model will not fix it. That diagnostic distinction is the single highest-leverage thing to check before an eval budget gets spent chasing the wrong layer.
Architecture Impact #
What changes in system design? Retrieval architecture needs an explicit domain-scoping layer sitting between the query and the vector index — a router (regex-first, LLM-fallback is cheap and effective) that restricts ANN search to a metadata-defined scope before similarity search runs, rather than searching the full corpus and filtering after. Multi-agent orchestration, if used at all, should be reserved for genuinely cross-domain queries, with a single-call scope-then-synthesize path as the default for everything else.
What new failure mode appears? Synthesis-stage faithfulness collapse under multi-round tool-calling orchestration — a drop from 0.61 to 0.35 RAGAS faithfulness in the cited case — that occurs even when retrieval precision is high, driven by the model’s inability to reconcile dense, near-duplicate passages pulled from parallel domain calls. This failure is invisible to standard retrieval-quality dashboards (P@10, recall@k) because retrieval itself looks fine; it only shows up in faithfulness or answer-correctness evals, and it’s backbone-dependent, so it can pass in staging on one model and fail in production on another.
What enterprise teams should evaluate:
- Platform/ML infra teams: instrument a per-domain dilution metric (retrieved-source-matches-gold-source rate) alongside standard retrieval metrics, since P@10 alone won’t surface source confusion.
- RAG/agent architecture owners: audit whether current multi-agent retrieval pipelines are actually necessary per query, or whether a hybrid router plus single synthesis call would match quality at lower cost and lower faithfulness risk.
- Eval/QA teams: add RAGAS faithfulness (or equivalent) as a required gate specifically for any pipeline using multi-round tool-calling retrieval, not just for single-call RAG, since faithfulness collapse is orchestration-specific and easy to miss if evals only run on the simpler path.
Cost / latency / governance / reliability implications: Domain-scoped retrieval reduced effective search space by 85–98% (weighted average 90.4%) per query, which directly cuts embedding/index compute and typically improves latency alongside precision — a rare case where the fix is cheaper, not more expensive. The Hybrid-Routed variant caps cost at two LLM calls per query versus up to five tool-call rounds for full orchestration, a meaningful inference-cost difference at enterprise query volumes. Reliability risk concentrates in the router: a misrouted query degrades gracefully in scope-then-synthesize designs (wrong-domain but still coherent answer) but can compound in multi-agent designs where a bad route feeds bad context into an already fragile synthesis step.
Implementation Guide #
Start by measuring dilution before touching architecture. Take your existing corpus, tag chunks with whatever organizational metadata already exists — document series, source system, category, business unit — and compute retrieval precision both globally and scoped-to-category on a held-out query set. This costs an afternoon and tells you immediately whether you have a dilution problem at all, and which categories are worst hit. In the cited deployment, thin categories (a few thousand chunks) diluted far harder than dense ones, so don’t assume the problem is uniform across your corpus; it’s probably concentrated in your smallest, most specialized document types, which are often the highest-stakes ones (compliance, safety, specs).
The high-leverage build is the router, not the retriever. A regex-first, LLM-fallback classifier that maps a query to one of K organizational scopes before ANN search runs is cheap to build, cheap to run, and — per this research — does most of the work: 85–98% search-space reduction per query and the bulk of the precision gain. Resist the urge to reach for a full multi-agent framework (LangGraph supervisor patterns, AutoGen-style planner/extractor/synthesizer chains) as the first move. Build the single-call scope-then-synthesize path first, measure it, and only add orchestration complexity where you can show a specific class of query genuinely needs cross-domain synthesis in one turn.
The mistake to avoid is treating this as a reranking or embedding-model problem. Cross-encoder rerankers lift baseline faithfulness in this research but do not recover the multi-agent faithfulness collapse — meaning teams that spend a quarter swapping embedding models or adding a reranking stage in response to accuracy complaints are optimizing a layer that isn’t where the failure lives. If your accuracy problem shows up specifically as the corpus grows rather than as a flat quality ceiling, and it doesn’t respond to reranking, treat that as a strong signal you’re looking at scoping, not ranking.
You’ll know it’s working when your retrieved-source-matches-gold-source rate climbs toward the 0.84–0.90 range this research reports for scoped and hybrid-routed retrieval, up from a monolithic-search baseline around 0.59 on comparable heterogeneous corpora — and when that improvement holds as you keep adding documents, rather than eroding again at the next order-of-magnitude scale-up. The maturity path for teams that get this right looks like: month one, dilution measurement and a basic router; months two to four, domain-scoped retrieval in production with single-call synthesis as default; months five to twelve, selective multi-agent orchestration added only for the specific query classes that demonstrably need it, gated behind faithfulness evals that would catch a regression before it reaches users. Teams that skip straight to multi-agent orchestration without this sequence are the ones most likely to rediscover the precision–faithfulness paradox in a production incident instead of in an eval run.
Sources #
- When More Documents Hurt RAG: Mitigating Vector Search Dilution with Domain-Scoped, Model-Agnostic Retrieval (arXiv:2606.11350) — Subedi, Abdelaty, Sheshappanavar, University of Wyoming
- RAG at Scale: How to Build Production AI Systems in 2026 (Redis)
- Why Most RAG Systems Fail in Production: The Hidden Architecture Problems Behind AI Search
Enterprise AI Architecture
Want more enterprise AI architecture breakdowns? #
Subscribe to SuperML.