\n\n文章指出生产级 RAG 系统的瓶颈在于检索而非模型。大规模数据下，传统检索架构因召回率不足导致模型获取错误上下文，从而产生自信的错误答案。解决之道在于构建包含混合搜索、多级重排的统一检索服务系统。
译自：Why production RAG systems give confident, wrong answers at scale
作者：Jenny Morris
在生产级 RAG 系统中，最大的瓶颈通常不是大语言模型（LLM），而是检索。
大多数团队从一个简单的模式开始：对查询进行编码，从向量数据库检索少量文档，将它们传递给模型，然后生成答案。对于小型、组织良好的数据集，这感觉就像魔法一样。正确的文档通常就在排名靠前的结果中。上下文很干净。系统看起来快速、准确且可靠。
但这种成功是一种幻觉。
随着数据的增长，几百个文档变成了数百万个，伴随着混乱的元数据、重复的版本、访问控制和模棱两可的语言，且所有这些都处于真实的延迟限制之下。正确文档出现在顶部结果中的概率急剧下降。检索质量在任何人察觉之前就已经悄然下降。
系统仍然会产生答案。但现在模型处理的是不完整或不相关的上下文。它通过填补空白来进行补偿。回答依然流畅且自信，但错误却越来越多。曾经看起来像智能的东西开始变得不可靠。
“RAG 系统很少因为模型太弱而崩溃。它们崩溃是因为为整洁的 Demo 设计的检索架构在生产规模下瓦解了。”
此时，团队通常会归咎于嵌入（embeddings）、提示词（prompts）或模型大小。但失败发生得更早。RAG 系统很少因为模型太弱而崩溃。它们崩溃是因为为整洁的 Demo 设计的检索架构在生产规模下瓦解了。
问题不在于智能，而在于召回率（recall）。
检索差距
想象一家公司为一万名员工构建内部知识助手。该系统必须搜索一千万个文档：财务备忘录、技术规范、项目计划和会议记录。回答必须在 2 秒内返回。财务相关的答案必须准确。
一位工程师问道：
“在忽略草案的情况下，Helios 项目第四季度预算的最终决定是什么？”
系统检索了十个文档。没有一个包含批准的预算备忘录。其中几个包含早期的讨论。语言模型生成了一个自信但错误的答案。
没有任何东西损坏。模型的表现完全符合设计要求。它总结了接收到的上下文。失败的原因不是“LLM 幻觉”。正确的证据根本没有进入上下文。
这并非极端情况。这就是为小型数据集构建的检索系统遇到生产规模时的必然结果。
为什么检索在大规模下会失效
大规模语料库的行为与小规模语料库不同。相关文档被埋在排名分布的更深处。元数据变得更重要。精确术语变得更重要。权限和过滤变得必不可少。延迟预算变得严格。
仅检索少数候选文档在统计上变得不可靠。最好的文档在语义相似度上可能排在第 300 位，但在精确关键词匹配上却排在第一位。或者被元数据过滤掉了。或者被草案掩盖了。
“一旦检索错过目标，管道的其余部分就无法恢复。没有任何提示词可以修复缺失的上下文。”
一旦检索错过目标，管道的其余部分就无法恢复。没有任何提示词可以修复缺失的上下文。没有更大的模型可以推断出从未被检索到的信息。
能够真正扩展的架构
生产级 RAG 不仅仅是更智能的提示词或更大的模型。它是一种不同的检索架构。
可扩展的系统不再是抓取几个候选文档并寄希望于其中一个是正确的，而是撒下一张大网，在检索过程中应用过滤，并通过多个排名阶段逐步精炼结果。检索变成了一个统一的服务管道，而不是一连串互不相连的服务。
系统快速检索许多候选文档，尽早过滤，以低成本排名，有选择性地重排，并仅将最佳证据发送给模型。
深度检索与递进式排名
可扩展检索的工作方式类似于漏斗。首先，使用快速近似方法收集大量的候选池。然后使用低成本信号（如词法相关性和嵌入相似度）对所有候选文档进行评分。最后，仅对最有希望的子集应用高成本的神经重排器（rerankers）。
这种结构兼顾了质量和成本。昂贵的计算集中在最关键的地方。
顶部是广阔的召回。底部是精准度。如果没有这个漏斗，系统将面临准确性与延迟之间的权衡。有了它，两者兼得。
四个扩展悬崖
从这个角度看，故障模式变得清晰：
悬崖 #1： 候选生成太浅。正确的文档从未进入排名管道。
悬崖 #2： 检索碎片化分布在多个服务中。每次网络调用都会增加延迟并引入数据不一致性。来自不同系统的评分无法直接比较。
悬崖 #3： 昂贵的重排应用得太广泛。神经模型在数百或数千个候选文档上运行，推高了成本和响应时间。
悬崖 #4： 将提示词工程作为检索质量的替代品。当上下文错误时，输出始终是错误的。
这些不是模型问题。它们是服务架构问题。
构建真正可扩展的 RAG
生产级 RAG 需要不同的检索架构。
在小规模下，检索可以表现为互不相连组件的松散管道。在生产规模下，这种方法会失效。检索必须作为一个统一的服务系统运行，以最大化召回率、控制延迟并逐步精炼结果。
以下四个原则定义了可扩展检索系统的正确做法。
原则 #1：将检索视为服务系统
第一个转变是观念上的：检索不是一个工作流，它是一个服务问题。
停止以断开的步骤思考：
嵌入服务 → 向量数据库 → 过滤脚本 → 重排器 → LLM
开始以统一的系统思考：
检索引擎（混合搜索 + 过滤 + 排名）→ LLM
在生产环境中，这些组件不能孤立运行。混合搜索、元数据过滤和排名必须在单一查询路径中，在相同的数据上共同执行。
仅靠向量相似度是不够的。真实的查询依赖于语义理解、精确关键词匹配、结构化过滤器（如时间、实体和权限）以及习得的排名信号。这些信号需要直接交互，而不是跨多个服务拼接在一起。
像 Vespa 这样的系统就是围绕这个想法设计的，在单个服务层内执行混合检索和多级排名。这避免了同步问题并消除了不必要的网络跳跃。
具体的平台并不如架构重要。重要的是检索是集成的而非碎片化的，是低延迟的而非分布在多个执行路径上的，并且是逐步筛选的，从广阔的召回转向精准的排名。一旦将检索视为一个系统，下一个问题就变成了：如何确保它真正找到了正确的信息？
原则 #2：混合检索 + 大候选集
通过将混合检索与足够大的 top-K 相结合，在候选生成阶段实现召回率最大化。
语义搜索捕获概念相似性，而关键词搜索捕获精确匹配。现实世界的查询依赖于这两者。例如，一份财务批准备忘录在语义上可能与“预算决策”并不接近，但它会包含精确的项目名称、日期和批准用语。纯语义检索可能会漏掉它，而纯关键词搜索可能会漏掉相关的上下文。混合检索结合了这两种信号，显著提高了覆盖范围。
但仅有检索方法是不够的。候选生成本质上是一个召回率问题，而不是精准率问题。如果相关文档从未进入候选集，下游的任何排名模型都无法挽救它。这就是为什么 top-K 应该设定得足够大，特别是随着语料库规模和查询歧义的增加。混合检索扩展了跨语义和词法信号的覆盖范围，而更大的候选集则增加了正确文档存活到后续排名阶段的概率。在这个阶段，召回率比精准率更重要。
高召回率为有效的排名创造了条件。没有它，系统就是在不完整的候选名单上运行。
有了强大的候选集，接下来的挑战就是效率。
原则 #3：多级排名至关重要
神经重排器功能强大，但对于大型候选集来说成本太高。
解决方案是多级排名管道。早期阶段使用快速、轻量级的方法来消除明显的不匹配，而后期阶段则仅对更小且质量更高的子集应用更昂贵的模型（如交叉编码器或基于 LLM 的重排器）。
这种结构平衡了相关性、延迟和成本。早期过滤减少了不必要的计算，而昂贵的排名模型则只专注于有希望的候选对象。
如果没有分级，系统将面临艰难的权衡：要么对所有内容运行昂贵的模型并牺牲延迟，要么过早限制候选集并牺牲召回率。多级排名消除了这种权衡，允许系统在保持效率的同时维持大型候选池。
至此，我们已经掌握了机制。最后一个原则解释了为什么这一切都很重要。
原则 #4：检索质量决定系统质量
语言模型不会验证事实。它们根据给定的证据合成回答。
如果检索到的上下文是精准的，回答就是精准的。如果上下文充满噪声，回答就会变得不确定。如果上下文是错误的，回答就是错误的。
这使得检索成为系统性能的决定性因素。重要的是，检索质量不是单一决定的结果，而是整个管道的结果：候选如何生成、检索了多少文档、排名如何分级，以及最终有多少无关上下文到达模型。孤立地关注任何一个组件都会偏离重点，因为这些决策是相互影响的。
这就是为什么要将检索作为一个系统来评估。衡量候选生成期间的召回率，跟踪召回率在排名阶段的变化，检查有多少无关上下文到达提示词，并了解整个管道中延迟产生的位置。
当系统中任何地方的召回率较低时，下游没有任何环节可以补救。不改进检索而改进提示词只是表面优化。改进检索才能改变结果。
“不改进检索而改进提示词只是表面优化。改进检索才能改变结果。”
RAG 的失败并不是因为语言模型能力有限，而是因为检索管道设定不足。
小型系统可以容忍浅层检索、碎片化组件和暴力重排。大型系统则需要深度候选生成、统一服务和分级计算。规模迫使纪律。
当检索被视为一个端到端的服务问题，并围绕深度候选生成、混合搜索、早期过滤、递进式排名和精准上下文选择构建时，生产系统才能取得成功。
当正确的证据到达模型时，正确的答案自然会随之而来。
原型 Demo 与可靠生产系统之间的差距并不神秘。它是架构上的差距。端 工智能
