RAG 工程里的上下文剪枝：如何减少 68% 的上下文

做 RAG 时，我们会关注“如何召回更多内容”。去研究怎么切 chunk、怎么做 embedding、怎么混合关键词和向量检索、怎么做 rerank，让尽可能多的相关资料塞进模型上下文，从而让 RAG 系统回答得更准。

Kapa 讨论了检索之后的下一步：当候选资料找回来后，要不要把它们原封不动地塞给大模型？

Kapa 在 Reranker 和 Generator 之间，加了一个轻量小模型（上图 Pruner）。这个小模型会先评估用户问题与候选 chunk，直接剪掉明显无用的内容，只把精简后的数据交给生成模型。

在多组实验配置中，Kapa 最终选了一个压缩率较高、召回率损失仍可接受的方案。这个配置剪掉了大约 68% 的检索 chunk，并保留了约 96% 的召回率。扣除剪枝模型自身的调用成本，整体的单次查询成本依然下降了约 34%，大约三分之一左右。

在 Kapa 的技术知识库问答场景中，他们接入了技术文档、API 参考、PDF、论坛以及支持工单等多种资料，并作为检索上下文提供给 AI 助手。

这个工作流程是：Retriever（检索系统）先从知识库中检索出候选 chunk，Reranker 会根据问题相关性，对检索到的候选 chunk 重新排序，最后将靠前的 chunk 提交给生成模型生成回答。

然而，检索系统为了避免漏掉回答所需的关键信息，返回结果会偏保守。宁愿多返回一些可能相关的 chunk，也要确保召回率。这种做法保证了准确性，但带来了直接的成本问题。生成模型是要为读到的每一个 chunk 付费的。

在助手服务中，检索到的 chunk 占了单次查询成本的 2/3，这个开销甚至超过了生成回答、对话历史和 system prompt 的成本总和。在这种场景下，每减少一个进入模型的 chunk，就能直接降低约 4% 的单次查询成本。

上下文剪枝就是用来解决上面这些问题的。在 RAG 系统检索回来的候选内容中，只有一部分会被回答真正用到，剩下的部分都只是“看起来相关”。即使生成模型忽略了这些无用内容，token 成本还是产生了。因此，上下文剪枝的目标非常明确，就是在生成模型读取资料之前，对候选 chunk 进行二次筛选，尽可能只保留回答真正需要的内容。

最简单的上下文剪枝方案是直接用 Reranker 分数来裁剪候选 chunk。

例如，设定一个分界线，分数高于 0.7 的保留，低于 0.7 的直接丢弃。这个方案看起来可行性很高，毕竟多数 RAG 系统自带 Reranker。既然 Reranker 已经对每个 chunk 打了分，直接利用现有分数进行截断，似乎可以顺理成章地省下一次额外的小模型调用成本。

但实践证明，这条路径并不可靠。

分数阈值与组合相关性

上面方案不可行的第一个原因是，Rerank 分数是一个排序信号。它能确定某个 chunk 在当前问题下的相对排序，却不能保证不同问题之间的分数具有相同的衡量标准。一个问题下的 0.7，和另一个问题下的 0.7，可能相关性并不高。

不用分数截断上下文的话，还有一种做法是位置截断。只保留前 5 个 chunk，或是把保留范围从前 15 个缩减到前 10 个。这种方式很简单、成本完全可控，但弊端也很明显：位置截断只关注“谁排在前面”，无法判断“该内容是否必要”。这种一刀切的做法在过滤掉噪声的同时，也可能会误删回答问题所需的候选内容。

这里分享一个具体案例：

用户问：“能不能只针对某一个 project 关闭 audit logforwarding？”

系统检索到了两个关键 chunk：

• 第一个 chunk 提到：audit log forwarding 是在 org 设置里切换的。

• 第二个 chunk 提到：project 不能覆盖 org 设置。

单独来看，第二个 chunk 并没有直接出现“audit log forwarding”这个词，在排序时会被当成噪声过滤掉。但如果缺少了它，系统就无法拼凑出“无法单独为某个项目关闭”这个答案。

这种情况在技术知识库问答中很常见。要解答一个技术问题，一般需要定义、约束、例外条件以及边界限制等多方面资料的配合。这些资料单独看都不像直接答案，但组合在一起能构成完整的逻辑链条。

然而，大多数 Reranker 都在逐个判断查询与单个 chunk 的关系。它在评估候选内容时，只能看到“当前问题”和“当前这一段内容”，无法同时看到其他候选 chunk，因此很难判断某段内容是否是另一段内容的必要补充。

因此，真正要评估的对象是 chunk 集合，而不是单个 chunk。Reranker 系统不仅要判断“这一段单独看相关度有多高”，更要判断“将这一段放入当前这组候选资料中，对最终回答是否有新增贡献”。

锚点文档

在转向小模型剪枝之前，Kapa 还尝试过锚点文档方案。

该方法的思路是，在候选 chunk 的排序列表中插入一些已知相关程度的“锚点文档”。这些锚点覆盖了从 Essential、Contributing、Supporting 到 Tangential、Unrelated 等不同相关性等级。Reranker 系统通过观察真实 chunk 排在这些锚点的上方还是下方，来决定其去留。

这种做法的好处是通过引入参照物，将 Reranker 的相对排序转化为更可校准的绝对指标。

但实验结果并不理想。因为锚点文档只能帮助校准分数的绝对尺度，无法改变 Reranker “逐个评估单个 chunk”的工作方式。对于那些“单独看相关度不高，但与其他 chunk 组合起来才有用”的内容，Reranker 依然会将其排在靠后的位置。为了避免误删这些关键补充信息，系统得把保留阈值设得很低，这会让最终能剪掉的上下文非常有限。

通过这次尝试，我们得到了一个明确的结论：剪枝模型必须能够同时看到用户问题以及所有的候选 chunk。

Kapa 采用了基于列表的 LLM 评分机制。在 Reranker 和 Generator 之间插入一次小模型调用。这个小模型会同时接收用户问题和所有的候选 chunk，并按照以下五档标准为每个 chunk 进行评估打分：

• 5 分：Essential。关键资料，缺它不行。

• 4 分：Contributing。单独无法回答问题，但完整答案需要它。

• 3 分：Supporting。和问题相关，且对回答问题有帮助，但没有它答案大概率也能成立。

• 2 分：Tangential。同领域或术语接近，但无具体贡献。

• 1 分：Unrelated。基本无关。

在这套评分标准中，4 分的设置很重要。它专门用来识别那些“单独看相关度不高，但组合起来对答案有价值”的补充性材料。这样，小模型就能从全局视角出发，识别出上下文之间的互补关系，而不是只看单个 chunk 是否直接命中问题的关键词。

有了这套五档评分后，系统可以通过设定阈值来决定 chunk 的去留。例如：

这与直接使用 Rerank 的浮点数分数的逻辑完全不同。五档评分的每一档都有明确的文字定义，这让阈值具有更稳定的语义含义，也就避免了浮点数分数在不同问题之间难以横向比较的问题。

同时，系统还保留了 Keep-Top-K 机制。无论剪枝小模型如何打分，Reranker 排序最靠前的几个 chunk 都要被强制保留。这个设计相当于为系统加了一层保险，避免最核心的检索结果因为小模型的单次误判而被意外删掉。

此外，该方案还有两个核心参数要权衡：

1. 模型选择：剪枝模型本身也存在运行成本和耗时，因此必须选择体积足够小、速度足够快且足够便宜的模型。

2. 阈值设置：阈值越高，上下文压缩率越高，越省钱；阈值越低，对召回的保留能力越强，越安全。

为了验证该方案的有效性，这里对比了两种基线方案：

• 预算式选择：固定保留前几个 chunk，再让小模型最多补充  个。该方案能严格控制上下文长度，但缺点是预算一旦用完，后续即便有真正有用的 chunk 也会被无情丢弃。

• 直接二分类选择：不设五档评分，直接让小模型判断每个 chunk “保留”或“丢弃”。这是一个非常实用的对照组，用以评估多档打分是否有必要。

Kapa 的评估体系分为两层：

第一层是在带标签的真实问题集上测试召回率。重点关注回答真正需要的关键 chunk 有没有被保留下来。剪枝最怕的是误删关键证据，如果为了降低成本而导致回答出错，这样的优化就失去了实际意义。

第二层是生产流量回放。Kapa 用一个月的真实生产对话数据来回放不同的配置组合，来观察实际的压缩率、成本和延迟变化。这种做法避免了小样本测试的局限性，还能够更真实地反映业务实际运行中的输入分布。

在最终选定的配置下，系统保留了约 96% 的必要 chunk 召回，同时剪掉了约 68% 的检索 chunk。

这个结果对应的是一个相对务实的取舍：大约每 25 个问题中，可能会有 1 个问题因为剪枝而丢失原本需要的 chunk；但换来的收益是进入生成模型的检索上下文减少了约三分之二。

这套方案的成本主要体现在延迟上。

由于剪枝器运行在检索和生成之间，处于请求的关键路径上，因此每次查询都必须额外多出一次模型调用。在上面选定的配置下，平均每次查询会增加约 0.7 秒的延迟。

虽然这个方案让进入生成模型的 chunk 变少了，后续生成模型开始输出首 token 的时间会稍微缩短，但这点节省下来的时间，并不足以完全抵消剪枝器自身调用所引入的延迟。

因此，这个优化非常依赖具体的业务场景：

这也是 Kapa 优先选择在 Agent 场景中落地该方案的原因。

Agent 在执行单次任务时，要调用多个工具，每次工具调用的结果都会持续累加到上下文中。如果检索返回的内容更短、更干净，就能为后续的工具输出、推理步骤和中间状态留出更多的上下文空间。

在长任务中，这个方案带来的好处就更明显了。如果前期的检索结果夹带了大量冗余 chunk，随着后续工具调用不断叠加内容，上下文很快就会变得臃肿。剪枝能确保 Agent 在一开始就拿到一个足够紧凑的资料包。

此外，Agent 场景还有一个天然的缓冲机制：如果发现信息不足，它可以再次发起搜索。这让少量的召回率损失变得更加可控。在单轮问答中，一旦关键 chunk 被误删，模型可能就直接给出了错误答案；但在 Agent 流程中，它还有机会在后续的思考与执行步骤中重新进行检索补救。

这套方法更适合以下四类系统：

• 检索 chunk 已经成为主要的成本来源。

• 检索结果中存在大量“看起来相关、实际却没用上”的冗余内容。

• 系统能够接受 1 秒以内的额外延迟。

• 业务能够容忍极少量的召回率损失，或者系统本身具备二次检索的机制（如 Agent 场景）。

如果你的系统基本符合这些条件，那么在 Reranker 和 Generator 之间加入一层轻量剪枝，就具有非常实在的工程价值。