Kapa实战：RAG上下文修剪，只留真正有用的那部分

Kapa 把 RAG 的上下文砍到只剩骨头，效果反而更好

7月初，Kapa.ai 在官方博客上放出了一篇实战复盘，讲他们怎么把 RAG 系统里的上下文修剪（Context Pruning）从一个"锦上添花的优化项"做成了流水线里的必备环节。对做 RAG 的团队来说，这篇东西比大部分学术论文更值得读一遍——它讲的不是"我们试了个新想法"，而是"我们在生产环境里踩了什么坑，最后是怎么解决的"。

先说结论：Kapa 的方案把送进 LLM 的 token 数量平均砍掉了 50% 以上，同时答案的事实准确率还提升了。这不是那种"我们优化了 3%"的边际改进，是能直接影响成本账和用户体验的量级。

问题的起点：Rerank 之后为什么还不够

做过 RAG 的人都知道那个经典流水线——向量检索召回 Top 50，rerank 模型再排一遍留 Top 5 到 Top 10，然后一股脑塞进 prompt。这套东西在 demo 里效果都不错，但一上生产就露馅：

• 用户问的是"怎么配置 webhook 的重试策略"，检索回来的 5 篇文档每篇 2000 token，里面真正回答这个问题的可能就 3 句话；
• 剩下的全是背景介绍、无关的 API 说明、甚至和问题冲突的旧版本内容；
• 模型被这堆噪声一干扰，要么抓不到重点，要么把冲突信息拼在一起产生幻觉。

Kapa 团队的观察是：rerank 解决的是"哪个文档更相关"，但没解决"文档里哪些句子真的有用"。这两个粒度不是一回事。一个高度相关的文档里可能 80% 的内容对当前问题都是噪声，rerank 分数再高也没用。

这也是为什么现在越来越多团队开始把 pruning 单独拎出来做——它跟 rerank 是互补关系，不是替代关系。

Kapa 的做法：句子级别的相关性判断

Kapa 的核心思路其实不复杂：把 rerank 之后的文档拆成句子，让一个轻量模型逐句判断"这句话对回答当前问题有没有贡献"，保留有贡献的，丢掉没贡献的。

但真正做起来有几个关键的工程决策：

第一，粒度选择在"句子"而不是"段落"或"token"。 段落太粗，一段里往往混着有用和无用的信息；token 级别（比如 LLMLingua 那种）压缩率高但可解释性差，出了问题很难 debug。句子是可读性和粒度的一个平衡点，Kapa 明确说这是他们在多个方案里对比后选的。

第二，用小模型做判断，不用 LLM。 如果每个句子都调一次 GPT-4 判断相关性，成本立刻爆炸。Kapa 用的是一个专门微调过的小型分类模型，输入是"问题 + 候选句子"，输出一个 0-1 的相关性分数。延迟能控制在几十毫秒，成本几乎可以忽略。

第三，训练数据的构造很有意思。 他们用现有的问答对反向构造训练样本——已知答案的问题，把答案涉及的原文句子标为"应保留"，其他句子标为"应丢弃"。这种自监督式的数据构造能规模化，不用人工标注。

第四，保留一定的冗余缓冲。 他们没有做成"卡死一个阈值"，而是保留了一个动态的容忍区间——对高分句子直接保留，对低分句子直接丢弃，中间地带的句子根据当前上下文总长度动态决定。这是个很实用的工程 trick，避免了"差 0.01 分被误杀"的边界问题。

长上下文的四种失败模式

Kapa 的博客里还顺带梳理了长上下文场景下 LLM 常见的四种失败模式，这部分值得单独摘出来：

1. Lost in the Middle：这个是老问题了，模型对上下文中间部分的信息注意力显著低于开头和结尾。上下文越长，中间被"淹没"的信息越多。
2. Distraction：无关内容会主动干扰模型的推理路径。哪怕相关信息在，只要旁边有语义相近但答案不同的噪声，模型就容易被带偏。
3. Confusion from Contradictions：文档库里经常有版本迭代留下的过时内容，新旧文档并存时，模型可能把两个版本的信息混在一起输出。
4. Cost Blowup：这个不是质量问题是成本问题——32k 上下文和 4k 上下文的价格差好几倍，如果 80% 的 token 都是噪声，那就是在给云厂商烧钱。

Pruning 是同时解决这四个问题的，这也是为什么它不是"可选优化"而是"必需组件"。

一个具体的例子

Kapa 在文章里给了个真实案例：用户问"如何在 Python SDK 里设置自定义 header"。检索回来的文档包括 SDK 的完整安装指南、认证章节、请求配置章节、错误处理章节。

• Rerank 之后保留了 3 篇文档，一共约 6000 token；
• Pruning 之后只剩 4 个句子，约 200 token；
• 剩下的 4 个句子精确包含了初始化 client 时传入 headers 参数的代码片段和一段说明；
• 生成的答案更短、更准，也没有把不相关的认证流程混进来。

压缩率 30 倍，这不是特例——Kapa 说在他们的生产流量里，这种数量级的压缩比比比皆是，因为文档里的信息密度本来就低。

和 Rerank、Reranker 的组合方式

值得强调的是，Kapa 并没有用 pruning 替换 rerank。他们的流水线大致是这样：

• 向量检索：召回 Top 50 候选块
• Rerank：交叉编码器重排，保留 Top 10
• Sentence-level Pruning：句子级别判断，只保留真正相关的句子
• 组装 prompt：按原文顺序拼接保留的句子，附上必要的上下文标记
• LLM 生成

每一步都在收敛，但收敛的粒度不同。Rerank 是文档级的收敛，pruning 是句子级的收敛，两者叠加才有 30 倍的压缩效果。

几个容易忽略的实现细节

保留句子的顺序和上下文标记。Kapa 特意提到，pruning 之后不能只把句子扔进 prompt，需要保留它们在原文的相对位置和文档来源标注，否则模型会失去"这些句子在讲同一个东西"的判断依据。

指代消解问题。句子级别的裁剪最大的风险是——一个句子里有"it"、"this"这样的指代词，指向的是被裁掉的前文。Kapa 的处理方式是在裁剪时检查代词，如果句子里有未消解的指代，就把它前面的一句也一起保留下来。

冷启动的兜底策略。如果 pruning 模型对所有句子都给出低分（意味着检索本身就没找到相关内容），系统会退回到只用 rerank 结果，避免给出"空上下文"导致的强行编造。

这个方向值得关注

站在 2026 年中回头看，RAG 的优化重心已经从"怎么检索得更准"转向"怎么让上下文更干净"。这是一个必然的演化：向量数据库、embedding 模型、rerank 模型都已经卷到边际收益很低了，但上下文里的噪声问题一直没被认真处理。

Kapa 这套东西的价值在于——它是一个已经在生产环境跑了很久的方案，不是论文里的 idea。文章里给的数字（token 减半、准确率提升、成本下降）都是真实业务数据。

对开发者来说，如果你的 RAG 系统已经上线，token 消耗又居高不下，pruning 是目前性价比最高的优化方向之一。做法也不复杂：找个小模型微调一下句子级相关性判断，接在 rerank 之后，观察效果。真要自己训练也不难，用现有问答对反向生成训练数据就行。

如果懒得自己搭一整套 pipeline，直接用 OpenAI Hub 这类聚合平台调不同厂商的 rerank 和 embedding 模型做对比也是个省事的路子——一个 Key 调 GPT、Claude、Gemini、DeepSeek，兼容 OpenAI 格式，做 A/B 测试的时候不用来回换 SDK。

RAG 已经不是"能跑起来"的阶段了，是"怎么跑得又便宜又准"的阶段。Pruning 大概率会成为下一年每个严肃 RAG 系统的标配。

参考来源

• RAG效果要提升，先搞定高质量Context Pruning - 知乎专栏 — 中文视角的 Context Pruning 系统性梳理，包含训练数据构造思路