主题颜色
RAG 上下文剪枝
RAG 上下文剪枝是在检索之后、生成之前，删除回答不需要的证据。它让检索阶段优先保证召回率，同时避免低价值候选占用昂贵的生成 token 和有限的智能体上下文。
在流水线中的位置
它为常见检索流水线增加第三个阶段：
检索与重排 → 按证据集合剪枝 → 生成
剪枝器同时接收问题和全部重排后的文本块，由小模型判断每个文本块对完整答案的贡献：
| 等级 | 含义 |
|---|---|
| 必要 | 没有该文本块就无法回答。 |
| 有贡献 | 提供需与其他文本块组合的定义、前提或部分事实。 |
| 支持 | 有帮助，但没有它通常也能形成完整答案。 |
| 旁支 | 主题或术语相近，但没有提供具体回答证据。 |
| 无关 | 与答案没有实质联系。 |
系统按可配置阈值删除较低等级，并可用 keep-top-k 保护重排结果中最强的若干文本块，降低评分错误造成的召回损失。
为什么重排分数阈值不够
重排分数主要表示同一次查询内的相对顺序，并不是可以跨查询统一解释的概率，因此固定阈值通常不可靠。固定 top-N 也有相同问题：它因为预算已满而丢弃后续文本块，而不是因为该文本块没有必要。
更深层的问题是逐点判断。单独看似无用的文本块，与其他证据组合后可能是定义、前提或多部分问题的必要组成。列表式剪枝判断的是一个文本块是否属于共同有用的证据集合，而不仅是孤立相似度。
评估契约
剪枝质量是一组权衡，而不是单一压缩率：
- 保留召回： 每个必要文本块都在剪枝后保留下来的问题占比。
- 压缩率： 被删除的检索文本块比例。
- 净成本： 生成模型节省的成本减去剪枝模型本身的成本。
- 新增延迟： 剪枝位于关键路径，生成加速未必能抵消它。
Kapa 公布的一个运行点删除了约 68% 的检索文本块，在约 96% 的标注问题上保留全部必要证据，净查询成本下降约 34%，同时增加约 0.7 秒延迟。这只是一个生产系统的测量结果，不是通用常数；实际阈值必须通过本地标注问题和生产回放确定。
适用位置
这是动态的上下文工程机制。渐进式披露从架构层控制何时加载知识，RAG 剪枝则控制某次查询检索出的哪些证据继续保持活跃。
它直接缓解长上下文失效模式中的混淆和分心。在智能体 Harness 工程中，它可以成为工具输出中间件：以一次小模型调用换取更低 token 成本和更多工作上下文。智能体尤其适合使用这一机制，因为它们会积累大量工具输出，也可以在证据不足时重新检索。
失效模式
- 只优化压缩率，不追踪必要证据是否全部保留。
- 把重排分数当作跨查询校准后的概率。
- 使用固定证据预算，静默丢弃排位靠后的必要文本块。
- 剪枝模型太贵，消耗掉它带来的成本节省。
- 在延迟敏感路径使用剪枝，却不测量端到端延迟。
- 未经本地评估，直接照搬公开阈值。