在 Kapa 的技术知识库问答场景中，他们接入了技术文档、API 参考、PDF、
论坛以及支持工单等多种资料，并作为检索上下文提供给 AI 助手。
这个工作流程是：Retriever（检索系统）先从知识库中检索出候选 chunk，Reranker 会根据问题相关性，对检索到的候选 chunk 重新排序，最后将靠前的 chunk 提交给生成模型生成回答。
然而，检索系统为了避免漏掉回答所需的关键信息，返回结果会偏保守。宁愿多返回一些可能相关的 chunk，也要确保召回率。这种做法保证了准确性，但带来了直接的成本问题。生成模型是要为读到的每一个 chunk 付费的。
2
在助手服务中，检索到的 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 个。这种方式很简单、成本完全可控，但弊端也很明显：位置截断只关注“谁排在前面”，无法判断“该内容是否必要”。这种一刀切的做法在过滤掉噪声的同时，也可能会误删回答问题所需的候选内容。
这里分享一个具体案例：
3
用户问：“能不能只针对某一个 project 关闭 audit log forwarding****？”
系统检索到了两个关键 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 的去留。例如：
设定阈值为 4 分，系统会保留 Essential 和 Contributing。
设定阈值为 3 分，则会更保守一些，将 Supporting 也一并留下。
这与直接使用 Rerank 的浮点数分数的逻辑完全不同。五档评分的每一档都有明确的文字定义，这让阈值具有更稳定的语义含义，也就避免了浮点数分数在不同问题之间难以横向比较的问题。
同时，系统还保留了 Keep-Top-K 机制。无论剪枝小模型如何打分，Reranker 排序最靠前的几个 chunk 都要被强制保留。这个设计相当于为系统加了一层保险，避免最核心的检索结果因为小模型的单次误判而被意外删掉。
此外，该方案还有两个核心参数要权衡：
模型选择：剪枝模型本身也存在运行成本和耗时，因此必须选择体积足够小、速度足够快且足够便宜的模型。
阈值设置：阈值越高，上下文压缩率越高，越省钱；阈值越低，对召回的保留能力越强，越安全。
为了验证该方案的有效性，这里对比了两种基线方案：
预算式选择：固定保留前几个 chunk，再让小模型最多补充 $$$$ 个。该方案能严格控制上下文长度，但缺点是预算一旦用完，后续即便有真正有用的 chunk 也会被无情丢弃。
直接二分类选择：不设五档评分，直接让小模型判断每个 chunk “保留”或“丢弃”。这是一个非常实用的对照组，用以评估多档打分是否有必要。
实验结果表明，五档评分方案在上下文压缩率与召回保留率之间取得了最佳的平衡。
研究结果
Kapa 的评估体系分为两层：
第一层是在带标签的真实问题集上测试召回率。重点关注回答真正需要的关键 chunk 有没有被保留下来。剪枝最怕的是误删关键证据，如果为了降低成本而导致回答出错，这样的优化就失去了实际意义。
第二层是生产流量回放。Kapa 用一个月的真实生产对话数据来回放不同的配置组合，来观察实际的压缩率、成本和延迟变化。这种做法避免了小样本测试的局限性，还能够更真实地反映业务实际运行中的输入分布。
4
在最终选定的配置下，系统保留了约 96% 的必要 chunk 召回，同时剪掉了约 68% 的检索 chunk。
这个结果对应的是一个相对务实的取舍：大约每 25 个问题中，可能会有 1 个问题因为剪枝而丢失原本需要的 chunk；但换来的收益是进入生成模型的检索上下文减少了约三分之二。
延迟与适用场景
这套方案的成本主要体现在延迟上。
由于剪枝器运行在检索和生成之间，处于请求的关键路径上，因此每次查询都必须额外多出一次模型调用。在上面选定的配置下，平均每次查询会增加约 0.7 秒的延迟。
虽然这个方案让进入生成模型的 chunk 变少了，后续生成模型开始输出首 token 的时间会稍微缩短，但这点节省下来的时间，并不足以完全抵消剪枝器自身调用所引入的延迟。
因此，这个优化非常依赖具体的业务场景：
单轮问答场景：如果是对首 token 延迟（TTFT）极其敏感的单轮问答，就要谨慎评估这个方案了。毕竟要额外增加一次模型调用。
Agent 场景：如果是在 Agent 场景下，系统本身就会进行多轮模型调用和多次工具调用，此时额外增加一次轻量的剪枝调用，其延迟影响就会被相对稀释。
这也是 Kapa 优先选择在 Agent 场景中落地该方案的原因。
Agent 在执行单次任务时，要调用多个工具，每次工具调用的结果都会持续累加到上下文中。如果检索返回的内容更短、更干净，就能为后续的工具输出、推理步骤和中间状态留出更多的上下文空间。