检索膨胀：当“加个 RAG 就行”变成架构上的干扰

这种模式太熟悉了，以至于被视而不见。模型幻觉出了一个事实，于是团队增加了一个检索步骤。三周后，模型从不断增加的工具库中选错了工具，于是他们在工具目录上增加了一个检索步骤。模型的回答感觉太笼统，于是他们在过去的高质量回答上增加了一个检索步骤。一个季度过去了，系统现在变成了一堆检索器拼接在一起的提示词，而本质上，最初的问题依然存在。

改变的不是失败率 —— 而是失败模式的名称。“模型出错了”变成了“检索未命中”，这听起来更易处理，但事实并非如此。评估套件的分数更高了，因为从构造上讲，检索到的上下文对于测试集来说是分布内（in-distribution）的。生产环境的情况则截然不同，但到那时，架构已经有了三个检索层，每一层都有自己的嵌入模型、索引刷新频率和值班轮换，而且没有人想成为那个提议拆除它们的工程师。

这就是检索膨胀（retrieval sprawl）。这是一种架构上的分心：一种将难题（提示词设计、模型能力、模糊的规范）转移到更舒适的问题（信息检索工程）上，而实际上没有解决任何问题的方式。

三种看起来相同的失败类型，三种不同的修复方法

当 LLM 产生错误答案时，人们往往倾向于求助于最直接的工具。对于 2026 年的大多数团队来说，这个工具就是检索。但同样的症状 —— 错误的输出 —— 掩盖了至少三种截然不同的根本原因，而其中只有一种可以通过检索来解决。

检索问题：模型缺乏你控制的语料库中存在的特定信息。用户询问公司的第三季度退款政策，模型胡编了一个。这些信息是真实的、记录在案的、可索引的，但在模型的训练数据中缺失。在这种情况下，增加检索确实是正确的答案。

提示词问题：模型拥有这些信息，或具备通用能力，但没有很好地利用它。系统提示词含糊不清，在边缘案例中自相矛盾，或者将相关指令埋没在其他 15 条规则之下。当在隔离环境中被仔细提示时，模型可以正确回答；它在生产环境中失败是因为提示词结构在与任务对抗。检索在这里没有帮助。它只是将更多的标记（tokens）塞进一个已经无法处理现有标记的上下文窗口中。

模型能力问题：再多的上下文也产生不了答案。该任务需要基础模型无法可靠完成的多步定量推理，或者是专家级人类都无法从语料库中提取出的特定领域判断。在这里，检索不仅无用，反而有害 —— 它给了团队一些可以优化的东西，耗费了数月的工程时间，而评估指标几乎纹丝不动，因为瓶颈完全在别处。

诊断规程是在增加任何基础设施之前，花一个小时询问你面对的是这三者中的哪一个。最简单的测试：选取五个具体的失败案例，手动将理想的上下文粘贴到提示词中，看看模型是否能答对。如果可以，你面临的是检索问题（语料库中有答案；系统没有将其呈现出来）。如果模型在拥有完美上下文的情况下仍然失败，那么你面临的是提示词或能力问题，增加检索并不能解决问题。这一个测试就能阻止我在生产系统中看到的一半以上的检索层。

检索器会复合它们的失败模式

检索膨胀的一种常见辩护是，每一层都解决了一种不同的失败模式，因此每一层都是独立发挥价值的。从经验上看，这很快就会崩溃。堆叠的检索器并不能整齐地组合；它们会使彼此的失败模式成倍增加。

2024 年的研究《工程化检索增强生成系统时的七个失败点》（Seven Failure Points When Engineering a Retrieval Augmented Generation System）记录了单个检索层可能失败的不同方式：内容缺失、错失排名最高的文档、导致正确答案被舍弃的上下文窗口修剪、模型无法从技术上正确的上下文中提取答案的提取失败，以及格式不匹配。你增加的每一层都会引入这七种失败模式的自身版本。两层意味着大约有 14 个可能出现微妙问题的地方。三层，21 个。这种复合不是线性的，因为下游检索器的质量取决于上游检索器传递的内容。

论文《理解 RAG 系统中的检索准确度和提示词质量》（Towards Understanding Retrieval Accuracy and Prompt Quality in RAG Systems）发现，即使是看起来完美的检索，生成失败仍然会影响高达 12.6% 的样本。这是复合不确定性的底线：即使是最好的检索流水线仍然会失败，因为检索和生成的交互方式，消融测试（ablation testing）很少能体现出来。

捕捉这一点的规程是在评估套件中进行针对每个检索器的消融实验。对于系统中的每个检索层，运行移除该层后的评估并衡量增量。如果该层在你真正关心的指标上的贡献低于几个百分点，那么它增加的复杂性就会变成对下游一切事物的征税 —— 调试难度、成本、延迟、值班负担 —— 而计算结果几乎总是告诉我们要移除它。

大多数团队不运行这些消融实验，因为他们建立在这样一个假设之上：增加该层是有原因的，且最初的理由依然有效。这种假设会随时间失效。六个月前为修复一个特定失败模式而增加的检索层，可能正悄悄地降级系统中的其他三条路径，而没有人衡量正确的数据来发现这一点。

无人执行的复杂度预算

软件团队在其他任何事情上都有隐式的复杂度预算。没有人会在未经架构评审的情况下为一个微服务增加五个消息队列。没有人会在没被询问原因的情况下随手加上三层缓存。但在 AI 系统中，检索层的增加就像配置标志（config flags）一样随意：一次加一个，每个在局部看来都理由充分，却从未作为整体进行审查。

一个有用的约束是：限制单个功能可以承载的检索层数量，超过这个限制，团队就必须进行重构，而不是继续添加。具体限制多少并不重要，重要的是要有一个限制。每个功能两个检索器是慷慨的。三个就是代码异味（code smell）。四个则意味着该功能正构建在错误的抽象之上，而由于每次增加都像是取得了进展，所以没有人注意到这一点。

为什么这很难执行？因为每一个检索层在上线当天都能在评估集（eval suite）上带来可衡量的提升。评估集是根据团队已经掌握的案例构建的；从定义上讲，新的检索器就是为了解决这些案例而设计的。因此，评估结果提升了。而复杂度的代价体现在延迟、成本、调试时间以及那些不会出现在评估中的长尾生产故障上——这些成本是分散且延迟的，并且由那些在批准增加检索器时并不在场的人承担。

复杂度预算让这种权衡变得显性化。每一个新的检索器都必须让团队提前承认某些代价，且这种代价与它声称带来的收益使用相同的“货币”来衡量。不再是“这增加了 4 个百分点的召回率”，而是“这增加了 4 个百分点的召回率，增加了 80 毫秒的 P95 延迟，在值班手册中增加了两种新的故障模式，并使每条查询的成本增加了 15%”。当成本被一一列举时，第三个检索器很少能在讨论中幸存下来。

同样的纪律也适用于检索深度，而不不仅仅是数量。将单个查询扇出（fan out）为五个改写查询的多查询扩展（Multi-query expansion），每个查询都去命中索引，听起来像是质量上的飞跃。但最近的基准测试表明，在重排序（reranking）和截断之后，这些收益往往会缩减到零，而且几种配置的表现甚至不如单个表述良好的查询。复杂度是真实的，但收益并不总是存在。

什么时候检索才是真正的正确答案

重点并不是说检索不好。检索是 AI 工程工具箱中最强大的工具之一，在某些任务中它显然是正确的选择：不适合放入任何上下文窗口的大型且易变化的语料库；多租户数据隔离；排除了微调（fine-tuning）可能的实时性要求；模型确实需要支撑引用（ground citations）的多文档综合任务。

表明“检索是正确答案”的真实信号包括：

• 信息以书面形式存在于你的团队可以控制或索引的某个地方。
• 信息的变化速度快于你的模型发布周期。
• 当你手动注入正确的上下文时，模型可以给出正确的答案。
• 语料库足够大，导致长上下文方案在经济上或延迟上令人望而却步（通常超过几百万个 token，或者有严格的亚秒级延迟预算）。
• 在构建之前，你可以清晰地阐述“检索成功”作为一个独立于“生成成功”的可衡量指标意味着什么。

如果以上条件有三个不成立，那么检索可能并不是你要解决的问题。你面前的工作可能会更加令人不安：重写一个有机增长的提示词（prompt），分解一个模型无法一次完成的任务，或者承认这个特定的用例已经超出了模型的能力边界，需要完全不同的方法。

检索被当作应对机制而非工具的迹象是：团队无法用一句话说清这一层解决了什么特定的故障模式，它不能解决什么，以及如果它失效了，他们如何感知。如果“为什么要系统里加这个检索器”的答案是“因为 X 发生时我们加了它，而且看起来有帮助”，那就是无诊断工程，而这一层可能正以无人理解的方式在维持系统运作。

优秀实践的样貌

摆脱了检索蔓延（retrieval sprawl）的团队通常都有一些共同的习惯。

他们在构建之前先进行诊断。面对模型失败的第一反应不是“增加检索”，而是“对失败进行分类”。五分钟的分类工作可以防止数月误导性的基础设施工作。

他们独立测量每一层。针对单个检索器的消融实验（ablations）是标准评估集的一部分，而不是特殊的调查任务。每一层的贡献都是团队中任何人都能背出的数字，低于阈值的层会被移除，而不是出于惯性被保留。

他们将检索深度视为一种约束，而非目标。功能规范中包含了复杂度预算。增加一层意味着要提出移除什么、延迟代价是多少，以及新的值班负担是什么样的。默认选项不是“更多层”，而是“满足评估标准的最简流水线”。

他们将提示词（prompt）视为一等公民（first-class artifact）。当模型失败时，提示词是第一个要检查的地方，而不是最后一个。拥有提示词评审流程、版本历史以及专门负责“提示词质量”的人员的团队很少陷入检索蔓延，因为替代路径已经很成熟了。

他们知道何时停止。有些问题是无法通过检索、提示词或在当前模型下两者的任何组合来解决的。正确的答案有时是“发布一个范围更小的功能”或“等待下一代模型”，而不是“增加另一个检索层”。能公开说出这一点的团队，其生命力远比那些做不到的团队更持久。

架构的觉醒

检索是一项工具，与其他任何工具一样。它能极其出色地解决特定类型的问题。当它是合适的工具时，就使用它。

但如果团队在每次提示词（prompt）表现不佳时都习惯性地诉诸检索——而在缺乏诊断框架、消融测试（ablation testing）或复杂度预算的情况下——这种架构就不再是一个系统，而变成了一种堆砌。每一层看起来都像是进步，因为每一层都在你所衡量的指标上取得了微小的进展。这种复利成本是隐形的，直到有一天团队意识到，他们构建的系统复杂度增长速度超过了质量提升速度，其失效模式（failure modes）已经多到超出了任何一位工程师的大脑负载，而最初的问题——即提示词没有发挥应有的作用——实际上从未得到真正解决。

这种自律并不是要规避检索。而是要诚实面对你在诉诸检索时究竟在解决什么问题，并衡量每一层新加入的组件实际换取了什么。构建持久 AI 系统的团队会将检索视为众多工具中的一种，并像向微服务添加新数据库一样对其进行严谨的审查。而那些不这样做的团队，则是在一次次增加检索器的过程中，为未来埋下技术债。