论坛以及支持工单等多种资料并作为检索上下文提供给 AI 助手。这个工作流程是Retriever检索系统先从知识库中检索出候选 chunkReranker 会根据问题相关性对检索到的候选 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 在执行单次任务时要调用多个工具每次工具调用的结果都会持续累加到上下文中。如果检索返回的内容更短、更干净就能为后续的工具输出、推理步骤和中间状态留出更多的上下文空间。