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

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

![](https://developer.qcloudimg.com/http-save/yehe-12464096/541b74c6fef54108e4fb6fe1820283a1.png)

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

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

## 检索成本

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

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

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

![](https://developer.qcloudimg.com/http-save/yehe-12464096/c3d699806a33a835656f7e14b79506ef.png)

在助手服务中，检索到的 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 个。这种方式很简单、成本完全可控，但弊端也很明显：位置截断只关注“谁排在前面”，无法判断“该内容是否必要”。这种一刀切的做法在过滤掉噪声的同时，也可能会误删回答问题所需的候选内容。

这里分享一个具体案例：

![](https://developer.qcloudimg.com/http-save/yehe-12464096/c4cf361638ccc24f113f484dee68d923.png)

> 用户问：**“能不能只针对某一个 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 都要被强制保留。这个设计相当于为系统加了一层保险，避免最核心的检索结果因为小模型的单次误判而被意外删掉。

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

1. 模型选择：剪枝模型本身也存在运行成本和耗时，因此必须选择体积足够小、速度足够快且足够便宜的模型。
    
2. 阈值设置：阈值越高，上下文压缩率越高，越省钱；阈值越低，对召回的保留能力越强，越安全。
    

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

- 预算式选择：固定保留前几个 chunk，再让小模型最多补充 $$$$ 个。该方案能严格控制上下文长度，但缺点是预算一旦用完，后续即便有真正有用的 chunk 也会被无情丢弃。
    
- 直接二分类选择：不设五档评分，直接让小模型判断每个 chunk “保留”或“丢弃”。这是一个非常实用的对照组，用以评估多档打分是否有必要。
    

实验结果表明，五档评分方案在上下文压缩率与召回保留率之间取得了最佳的平衡。

## 研究结果

Kapa 的评估体系分为两层：

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

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

![](https://developer.qcloudimg.com/http-save/yehe-12464096/805e217577510b3631fd44e2ff17642f.png)

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

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

## 延迟与适用场景

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

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

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

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

- 单轮问答场景：如果是对首 token 延迟（TTFT）极其敏感的单轮问答，就要谨慎评估这个方案了。毕竟要额外增加一次模型调用。
    
- Agent 场景：如果是在 Agent 场景下，系统本身就会进行多轮模型调用和多次工具调用，此时额外增加一次轻量的剪枝调用，其延迟影响就会被相对稀释。
    

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

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

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

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

## 小结

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

- 检索 chunk 已经成为主要的成本来源。
    
- 检索结果中存在大量“看起来相关、实际却没用上”的冗余内容。
    
- 系统能够接受 1 秒以内的额外延迟。
    
- 业务能够容忍极少量的召回率损失，或者系统本身具备二次检索的机制（如 Agent 场景）。
    

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

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

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

Kapa提出“上下文剪枝”新范式：在Reranker与Generator间插入轻量小模型（Pruner），基于五档评分（Essential至Unrelated）全局评估候选chunk，兼顾互补性与必要性。实测剪枝68%冗余内容，保留96%关键召回，单次查询成本降34%，特别适配Agent等多步推理场景。

人工智能

算法

编程语言

Kapa在RAG系统中创新性引入轻量级剪枝模型，在保留96%召回率的同时减少68%检索内容，单次查询成本降低34%。该方案通过五档评分机制精准筛选关键chunk，特别适合Agent场景，在控制成本与保证准确性间取得平衡。

Agent

2026上云采购 | AI焕新·智启新局

lexiang

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

RAG 工程里的上下文剪枝：如何减少 68% 的上下文-腾讯云开发者社区-腾讯云

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

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

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐