将RAG上下文修剪到答案实际所需的内容

# 我们如何教会一个小型LLM丢掉68%的RAG上下文 - kapa.ai - 技术问题的即时AI答案 来源：https://www.kapa.ai/blog/how-we-prune-rag-context Kapa 构建的 AI 助手能够回答关于大型产品知识库的复杂问题。这些知识库包括技术文档、API 参考、PDF、论坛和支持帖子。开发者使用我们的检索 API 为他们的智能体提供产品上下文，而同样的检索层也驱动着我们的端到端助手。 尽管 2026 年关于智能体是否还需要 RAG 的争论很多，但在我们的领域，当知识库变得庞大而复杂时，没有其他方法能与之媲美。我们的检索有多种形式，有些是智能体式的，有些是单次传递的，但它们的核心结构都一样：一个检索器，负责找到与问题相关的文档块；以及一个生成器，即根据这些文档块撰写答案的 LLM。 本文的简短版本：我们在两者之间增加了第三步。一个小型、廉价的 LLM 一起阅读问题和所有检索到的文档块，并在昂贵模型看到它们之前丢弃答案不需要的那些。它丢弃了大约 68% 的上下文，保留了约 96% 的召回率，并且在扣除自身成本后，将每次查询的成本降低了三分之一。本文解释了我们如何做到这一点。 ## **被忽略的文档块仍然需要花钱** 检索器就像一个漏斗。嵌入和关键词搜索将数十万个文档块的知识库缩减为几百个候选，重排序器对它们进行排序，排名前 15 左右的块到达生成器——这是链条中最大、最昂贵的模型。即便如此，生成器读到的大部分内容对于问题来说并非必需。这是故意的：检索器追求最大召回率，并相信生成器能够忽略噪声。 但是生成器为其忽略的每个块都要付费。在我们的助手中，检索到的块约占查询成本的三分之二，超过了答案、对话历史记录和系统提示的总和。每减少一个块，查询成本就降低约 4%。而在智能体中，每次工具调用都会将其输出倾入同一上下文，因此上下文增长迅速；更紧凑的检索结果为智能体必须持有的其他内容留出了空间，并减少了被浪费的上下文。 麻烦在于召回率。丢掉一个答案需要的块，就相当于用几美分换来了一个错误答案。修剪器的优劣完全取决于这个权衡：每损失一个百分点的召回率所换来的压缩率。 ## **显而易见的修复方法行不通** 我们已经在返回 top K 之前进行了重排序，因此有时有人建议我们直接暴露重排序分数，让调用者根据分数进行裁剪：保留所有高于 0.7 的块，丢弃其余的。这行不通，原因有两个，而第二个原因塑造了我们构建的一切。 首先，重排序分数是一种排序，而不是一种度量。它只说明对于这个查询，块 A 优于块 B，仅此而已。这些分数在跨查询间并未校准，Cohere 也（https://docs.cohere.com/docs/reranking-best-practices#interpreting-results）证实了这一点，因此没有固定的截断阈值有效。排序只支持位置性的截断，即 top-N，而这种方式会丢弃最后一个块，无论它是噪声还是答案。 其次，即使有完美的校准，也存在另一个问题：相关性不是单个块的属性。大多数流水线中的重排序器是点式交叉编码器。它们独立地评估每个查询-块对，从不与一起检索到的其他块进行比较。以下是一个匿名的生产示例： 第二个块从未提及审计日志，因此它被评分为噪声，然而它却是答案的一半，没有任何点式分数能看出这一点，因为该块只有与第一个块相邻时才相关。块还会将多部分问题拆分开来，每个块单独来看毫无用处。真正的问题从来不是一个块本身是否相关，而是它是否属于一起回答问题的集合。 ## **一个同样以相同方式失败的巧妙修复** 在放弃重排序器之前，我们尝试了锚点文档（Sinhababu 等人（https://arxiv.org/abs/2604.09492））：通过将已知相关性的合成块植入排序中，使重排序器的尺度变得绝对，每个级别从“必要”到“无关”各写一个，然后丢弃所有排名低于你想保留的最低级别锚点的真实块。这在你已经运行的重排序之上增加了一次 LLM 调用，而且确实很优雅。 但这种方法并没有奏效，原因与之前相同。锚点解决了校准问题，但无法解决分数问题，而重排序器仍然会将部分相关和间接相关的块排在明显无关的块之下。为了保留它们，锚点必须设置得非常低，以至于几乎没有什么能被剪掉。 那次失败得出了一个有用的结果：无论使用什么修剪方法，都必须同时看到问题和所有块，因为被判断的是集合本身。 ## **所以我们让一个 LLM 给块打分** 我们实际部署的是在重排序器和生成器之间进行一次列表式的 LLM 调用。它接收问题和所有块，并按照提示中编写的五级评分标准给每个块打分： **LLM 分数** **级别** **含义** 5 必要（ESSENTIAL） 没有这个块就无法生成答案，无论是它直接回答，还是它是另一个块所依赖的定义或先决条件。 4 贡献（CONTRIBUTING） 本身不能回答问题，但与其他块结合时提供了完整答案所需的内容。 3 支持（SUPPORTING） 主题相关且可能有用，但即使没有它，答案也可能已经完整。 2 边缘（TANGENTIAL） 属于同一领域或共享术语，但没有具体贡献。 1 无关（UNRELATED） 没有有意义的联系。 达到或超过阈值（threshold）的块被保留。这个设计解决了前面提到的两个失败点。由于每个级别都用文字定义，因此 4 分在每个查询上的含义相同，固定的截断终于可以工作了。而且，由于模型同时看到问题和所有块，它可以判断集合，因此部分相关和间接相关终于有了落脚点。 三个关键旋钮： - **模型**：修剪器的成本由它节省的费用支付，因此旗舰模型从一开始就被排除了；所有小型快速层级评估结果相似，因此我们选择了在低推理努力下最快、最便宜的。 - **阈值**：在压缩率和召回率之间的主要调节旋钮。 - **keep-top-k**：排名靠前的几个重排序块无论分数如何都会通过，保护最强的块免受评分错误的影响。 我们还运行了两个更简单的设计来保持诚实。预算选择：保留最上面的几个，让 LLM 最多再添加 N 个；大小可预测，但一旦预算用尽，每个后续块无论多相关都会被丢弃。最最简单的修剪器：直接问 LLM 应该保留哪些块，没有评分尺度。如果一个方案连直接询问都比不过，那就不值得构建。 ## **结果** 我们在一组标记过的真实问题上测量了召回率，这些问题的答案明确需要哪些块；然后通过回放随机一个月的生产对话（使用每个查询实际发送给生成器的确切块），验证了压缩率、成本和延迟。 每个点代表一种配置，根据两个关键指标绘制。x 轴是压缩率，即修剪器丢弃的检索块的比例。y 轴是保留的召回率，即在修剪后仍然拥有答案所需的所有块的查询比例：100% 表示没有查询丢失需要的块，90% 表示十分之一的查询丢失了。越向右上越好。线条连接每种策略的最佳配置，虚线灰色线是任何修剪器都必须击败的基线：简单的 top-N 截断，即只从重排序器返回更少的块。 一切方法都大幅超越了基线。将召回率保持在 98% 时：截断只能丢弃一个块，约 7% 的压缩率。所有 LLM 策略都能达到 30% 或更高，而相关性评分策略丢弃了近一半的块。评分线在每个压缩级别上都优于其他两种策略，因此唯一剩下的决定就是在这条线上选择哪个点。 我们选择了一个接近激进端的点：约 96% 的召回率保留，约 68% 的块被丢弃。每 25 个查询中大约有 1 个丢失了所需的块；作为交换，三分之二的上下文被移除，每次查询的账单（扣除修剪器自身成本后）下降了约 34%。 ## **延迟成本** 修剪器运行在检索和生成之间，处于关键路径上，因此它的模型调用会添加到每次查询中，其速度决定了增加的成本。在生产集上，我们选择的配置每次查询大约运行 0.7 秒。更重的设置会迅速攀升，因此使用低推理努力的小模型是保持增加时间低于一秒的关键。 生成过程几乎没有因此加快：更少的块意味着生成器的输入令牌更少，因此它开始响应的时间稍早一些，但只有零点几秒，远不足以抵消修剪器自身的调用。 因此，修剪通过牺牲少量固定的延迟来换取压缩率，在我们实际部署的配置上，延迟远低于一秒。对于延迟敏感的单次查询路径，这是一个需要权衡的实际成本。而在智能体内部（每次交互已经进行多次模型调用），多一次轻量级调用几乎是微不足道的。 ## **我们在哪里启用了它** 我们首先在检索作为众多工具之一的地方推出：客户基于我们的检索构建智能体。一个智能体携带数十种工具，每次调用都会将输出倾入同一上下文，而一次返回内容减少三分之二的文档搜索为其他所有内容腾出了空间。丢失的召回率在那里也不那么危险：一个注意到缺少某些内容的智能体可以再次搜索。 修剪在产品 Agent SDK（https://docs.kapa.ai/dev/agent/）的知识库搜索中默认启用，并且在检索 API 和 MCP 服务器（https://docs.kapa.ai/dev/）中是可选的。