RAG上下文剪枝：只保留答案所需信息

背景

Kapa 是一家构建 AI 助手的公司，专注于为大型产品知识库（包括技术文档、API 参考、PDF、论坛、支持线程等）回答复杂问题。开发者使用他们的检索 API 为智能体提供产品上下文，该检索层也支持其端到端助手。

在 2026 年关于智能体是否仍需 RAG 的争论中，当知识库规模大且复杂时，RAG 仍是最有效的方案。Kapa 的检索有多种形式，有些是智能体式的，有些是单次通过的，但所有形式都共享相同的结构：一个检索器（retriever）找到与问题相关的文档块，一个生成器（generator，即 LLM）根据这些块写出答案。

然而，检索器返回的 chunks 中，大部分对于生成答案来说是不必要的。生成器需要为每一个它忽略的 chunk 付费——在 Kapa 的助手中，检索到的 chunks 占一个查询成本的三分之二，超过答案本身、对话历史和系统提示的总和。每减少一个 chunk，查询成本降低约 4%。在智能体中，每次工具调用都会将其输出倒入同一上下文，上下文增长很快；更紧凑的检索结果为智能体必须容纳的其他内容腾出空间，并减少无用上下文。

核心内容

Kapa 在检索器和生成器之间添加了一个第三步：一个小的、便宜的 LLM（称为“剪枝器”pruner）同时读取问题和所有检索到的 chunks，在昂贵的模型看到它们之前，丢弃答案不需要的 chunks。该方法丢弃了约 68% 的上下文，保留了约 96% 的召回，在扣除自身成本后，查询成本降低了约三分之一。

为何简单方案失败

1. 基于重排序分数的截断：有人建议直接暴露重排序（rerank）分数，例如保留分数高于 0.7 的 chunk，丢弃其余。这有两个原因失败：

• 重排序分数是排序而非度量。它仅说明 chunk A 比 chunk B 更相关，分数在不同查询间未经校准，Cohere 也如此声明。因此无法设定固定截断阈值。唯一支持的截断是位置截断（top-N），但这会丢弃最后一个 chunk，无论它是噪声还是答案。
• 相关性不是单个 chunk 的属性。大多数流水线中的重排序器是 pointwise cross-encoders，它们独立评分每个 query-chunk 对，从不考虑一起检索到的其他 chunks。例如一个生产案例：第二个 chunk 从未提及审计日志，作为噪声被评分，但它却是答案的一半——这些块只有放在一起才相关。多部分问题也会被拆分成多个 chunks，每个单独看都无用。真正的问题不是 chunk 本身是否相关，而是它是否属于一个能共同回答问题的集合。

2. Anchor 文档方法：尝试使用锚点文档（anchor documents）——将已知相关性的合成 chunks 植入排序中，每个等级（从 Essential 到 Unrelated）写一个，然后丢弃排名低于你希望保留的最低等级锚点的所有真实 chunks。该方法优雅且只需一次额外的 LLM 调用。但同样失败：锚点修复了校准，但无法修复分数，重排序器仍然将部分相关和间接相关的 chunks 放在明显不相关的 chunks 下方。为了保留它们，锚点必须设得很低，导致几乎没有东西能被剪枝。

最终方案：用 LLM 分级

成功的设计是一次 listwise LLM 调用，位于重排序器和生成器之间。它获得问题和所有 chunks，并按照提示中编写的五级量表对每个 chunk 进行评分：

• 5: 必需（Essential）——答案需要该 chunk
• 4: 重要（Important）
• 3: 有用（Helpful）
• 2: 间接相关（Indirectly relevant）
• 1: 无关（Irrelevant）

阈值以上的 chunk 被保留。该设计解决了之前两个失败：每个等级用文字定义，因此 4 级在每个查询上含义相同，固定截断终于可行；模型同时看到问题和所有 chunks，可以判断集合，因此部分相关和间接相关终于有了归宿。

三个关键旋钮：

• 模型：剪枝器从节省的钱中支付自己，因此旗舰模型被排除在外。小型快速层级的评分相似，因此选择了推理量低、最快最便宜的模型。
• 阈值：压缩与召回之间的主要调节旋钮。
• keep-top-k：重排序后的前 k 个顶级 chunks 无论评分如何都通过，保护最强 chunks 免受评分错误的影响。

他们还运行了两个更简单的设计作为对比：

• Budget-select：保留顶级 chunks，让 LLM 最多添加 N 个；大小可预测，但一旦预算耗尽，后续任何相关 chunk 都会被丢弃。
• 最直接的剪枝：直接问 LLM 保留哪些 chunks，不使用量表。如果一个方案连直接询问都不能超过，就不值得构建。

结果

在一个标记好的真实问题集上测量召回（确切知道答案需要哪些 chunks），然后通过回放随机一个月生产对话中的每个配置（使用每个查询实际发送给生成器的 chunks）验证压缩、成本和延迟。

横轴为压缩率（被剪枝器丢弃的检索 chunks 比例），纵轴为召回保留率（剪枝后仍然拥有答案所需所有 chunks 的问题比例）。每条线连接每个策略的最佳配置。虚线灰色线是基准：简单的 top-N 截断（即从重排序器返回更少 chunks）。

所有 LLM 策略都显著优于基准。在召回率 98% 时，截断只能丢弃一个 chunk（约 7% 压缩），而每个 LLM 策略达到 30% 或更多，relevance scoring（五级量表）能丢弃近一半的 chunks。scoring 线在所有压缩水平上压倒其他两种策略。最终选择的点：召回保留约 96%，约 68% 的 chunks 被丢弃。即每 25 个问题中有一个丢失了所需的 chunk；作为交换，三分之二的上下文被移除，每个查询的成本（扣除剪枝器自身成本后）下降约 34%。

延迟成本

剪枝器运行在检索和生成之间的关键路径上，其模型调用添加到每个查询中。所选配置在生产集上每次查询约 0.7 秒。更重的设置会快速增加，因此使用推理量低的小模型将额外时间控制在一秒以内。生成器本身几乎不会加快：减少 chunks 意味着更少的输入 token，因此生成开始时间略有提前，但只提前了不到一秒。

关键要点

• 问题：RAG 流水线中，检索到的 chunks 大部分是噪声，但生成器为每个 chunk 付费。检索器追求最大召回，信任生成器忽略噪声，但成本高。
• 简单截断失败：重排序分数不是绝对度量，不能设定固定阈值；且单点相关性判断无法处理需要集合才能回答的问题（chunks 之间互补、多部分问题）。
• Anchor 文档方法失败：原因相同——无法解决分数问题，且部分相关 chunks 会被低分埋没。
• 解决方案：在检索器和生成器之间插入一个小的 LLM，进行 listwise 分级（五级量表），同时考虑所有 chunks。固定阈值（如保留 4 级及以上）有效，且能处理集合相关性。
• 三个旋钮：模型（小且快）、阈值（平衡压缩与召回）、keep-top-k（保护顶级 chunks 免受评分错误）。
• 结果：丢弃 68% chunks，保留 96% 召回，查询成本降低 34%，额外延迟约 0.7 秒。Relevance scoring 方案明显优于 budget-select 和简单询问。
• 最佳实践：保持召回率略低于 100%（如 96%）换取大幅成本节省；使用小模型、低推理量以控制延迟。

意义与影响

该工作展示了在 RAG 流水线中，引入一个轻量级智能剪枝步骤可以显著降低成本而不显著牺牲质量。关键洞察在于：剪枝器需要同时看到问题和所有 chunks 才能做出正确的集合级判断，而传统重排序器无法做到这一点。这一方法直接解决了“检索结果中大部分 chunk 无用但无法简单丢弃”的核心矛盾，为大规模知识库的 AI 助手提供了一条实用的优化路径。

从更广的角度看，它强调了在 AI 应用中“为所有输入 token 付费”的现实约束，并证明使用更小的模型