# kapa.ai 用一个小模型砍掉了 68% 的 RAG 上下文，召回率还保住 96%

> 原标题：Pruning RAG context down to what the answer actually needs

- 来源：Hacker News 首页
- 发布时间：2026-07-06T19:28:24.000Z
- AX AI 日报：https://ai-daily.ax0x.ai/items/42774
- 原文：https://www.kapa.ai/blog/how-we-prune-rag-context

## 摘要

kapa.ai 在检索器和生成器之间塞了一个便宜的小模型做“剪枝器”。它把问题和所有检索到的资料块一起读，按五级标准打分，直接扔掉 68% 的上下文，让后面那个贵的大模型少看很多无用信息。单次查询成本因此降了三分之一，同时答案所需资料的召回率维持在 96%。之前试过用重排序分数来砍，但分数在不同查询间没法对齐，也看不出资料块之间的关联，所以失败了。现在...

## 推荐理由

kapa.ai 这篇工程实践文章给了真实数字和与失败方案的对比，不是公关稿。我会先打个折：它只是一家公司的实践报告，不是协议更新或模型发布，所以传播面有限，但内容本身对从业者很实在。

## 锐评

这条新闻值得点开看，因为它解决了一个很实际的工程痛点：RAG（外挂资料库）检索出来的资料块，大部分其实用不上，但大模型读它们都得算钱。kapa.ai 的做法是在检索器和生成器之间加一个便宜的小模型，让它把问题和所有资料块一起读，按五级标准打分，然后扔掉 68% 的无关内容。结果单次查询成本降了三分之一，而答案所需资料的召回率维持在 96%，相当于省钱但没怎么牺牲答案质量。

他们之前试过用重排序分数来砍，但发现分数在不同查询间没法对齐，也看不出资料块之间的关联——比如一个块单独看像噪音，但和另一个块拼起来才是完整答案。这个失败经验是全文最有价值的部分，直接说明了为什么必须让模型“看全集”而不是“看单篇”。

不过文章没披露这个小模型具体是什么、有多大、推理延迟增加了多少。如果剪枝本身耗时太长，省下的钱可能被延迟吃掉。另外，96% 的召回率意味着仍有 4% 的情况会丢掉关键信息，在技术文档这类高精度场景下，这个错误率是否可接受，正文也没展开讨论。