用小 LLM 给 RAG 剪枝：丢掉 68% 上下文

为复杂产品知识库构建 AI 问答助手的 Kapa 团队近日在工程博客中分享了一项 RAG 优化实践：在检索器与生成器之间引入一个小型 LLM 作为「剪枝器」，可在保留约 96% 召回率的同时丢弃约 68% 的上下文，并将单次查询成本削减约三分之一。

为什么需要剪枝

典型 RAG 流程是一条漏斗：检索器先从数十万个文档片段中筛出几百个候选，再经重排序器挑出前 15 个左右送入生成器——也就是整条链上最贵的大模型。重排序器追求最大召回，宁可多取也不漏判，导致生成器在大量无关内容上「空转」。

Kapa 披露，其助手产品中检索片段占查询成本的约三分之二，超过回答正文、对话历史与系统提示的总和。每减少一个片段，查询成本下降约 4%。在智能体（agent）场景中，每次工具调用都会向同一上下文塞入新输出，收紧检索结果能为其他信息腾出空间，减少上下文腐烂。

代价也很直接：一旦丢掉真正需要的片段，省下的几分钱就要用错误答案来偿还。剪枝器的价值，恰好等于它在每一点召回率损失下换来的压缩率。

既有的两条路为什么走不通

第一条是直接暴露重排序分数，按阈值过滤。这一思路失败有两个原因：

• 重排序分数本质是序关系，不是可校准的度量。它只表示「A 片段比 B 片段更相关」，跨查询之间不可比。Cohere 在文档中也明确指出这一点。因此不存在普适的固定阈值，能用的只有「取前 N 个」这种位置式截断，而位置式截断会无差别砍掉末位，无法区分噪声与答案。
• 更根本的是：相关性不是单个片段的属性。大多数点对（pointwise）交叉编码器独立打分，看不到其它候选片段的存在。Kapa 给出一个生产案例：第二段文本单独看与查询词毫无关联，重排序为它打低分，但它与第一段组合后才构成完整答案。点对评分永远看不见这种集合层面的关系。多部分问题同样会被切分到不同片段中，单独看每段都没用。

第二条路是「锚点文档」（参考 Sinhababu 等人的方法）：在排序中插入已知相关性的人工片段作为标尺，按锚点级别裁剪真实片段。这一思路比简单按分数截断更精细，确实能修复校准问题，但仍无法修复打分逻辑本身——重排序器会把部分相关、间接相关的片段排在明显无关片段之下，要保留它们就只能把锚点放得极低，结果几乎剪不掉什么。

Kapa 总结：无论谁来做剪枝，都必须同时看到问题与全部片段，因为被判断的对象是「集合」而不是单个片段。

列表式 LLM 评分器

Kapa 最终上线的方案是在重排序器与生成器之间增加一次列表式（listwise）LLM 调用：模型同时拿到问题与所有候选片段，按五级量表逐段打分。

• 5 ESSENTIAL：缺少该片段则无法产出答案，包括定义、前置依赖等情形；
• 4 CONTRIBUTING：单独不构成答案，但与其它片段组合后能补全关键信息；
• 3 SUPPORTING：主题相关、可能有用，但缺少它答案大概率仍完整；
• 2 TANGENTIAL：同领域或共享术语，无具体贡献；
• 1 UNRELATED：毫无关联。

分数不低于阈值的片段进入下一阶段。这个设计同时回应了前两轮的失败：每个等级都有明确的文字定义，使 4 分在不同查询下含义一致，固定阈值终于可用；模型能看到全部片段，可以判断集合层面的相关性，部分相关、间接相关的内容也找到了归属。

实际运行中三个关键旋钮是：

• 模型选型：剪枝器必须由自身节省的费用覆盖开销，旗舰模型被天然排除；小而快的档位在低推理强度下表现接近，应选最快最便宜的；
• 阈值：压缩率与召回率的主要调节旋钮；
• keep-top-k：保留前若干个重排序片段不受评分影响，保护最强片段免受误判。

效果数据

Kapa 报告的结果是：该剪枝层丢弃约 68% 的上下文，保留约 96% 的召回率，扣除自身开销后单次查询成本净降约三分之一。对于依赖大型知识库的 RAG 产品，这是相当可观的成本与上下文双重收益。