最近到处看到有人在搞 RAG 上下文压缩。核心诉求很直接：查出来一堆文档，全塞进 prompt 太贵了，得砍。但我看到好多人一拍脑门，直接拿 reranker 的分数去一刀切……等等等等，先别急，这地方坑巨深。
我第一版画 RAG 流程的时候，以为大家砍上下文的逻辑是这样：
查向量库 ──► Reranker 打分排序 ──► 按分数一刀切 ──► 丢进 LLM
一条线，挺顺。但我自己动手试过，根本跑不通。Kapa.ai 那帮人也踩了这个坑，他们直接点破了：reranker 给的分数只代表"相对顺序"，根本没法跨问题去校准。
打个比方：这玩意儿就像一个没有固定刻度的温度计。今天量出来是 0.8，明天量出来也是 0.8，但今天可能是快沸腾了，明天只是微热。你没法定死一个"0.8 分以上的都要"的铁律，因为不同问题拉回来的文档，分数尺度完全是飘的。
那强行把这温度计校准一下行不行？有人试过，想用 anchor documents 强行固定绝对尺度。结果翻车了。Reranker 经常把那些"间接相关"或者"要凑在一起才管用"的文本块，排到八竿子打不着的纯噪音下面去。
这引出了一个更要命的问题：Reranker 只能做 pointwise（单点）判断。它看每个文本块，都是孤立地打分。但 RAG 很多时候不是找到唯一正确答案就完了，它需要拼图。
[块A：定义了X是什么] ──┐
[块B：讲了X怎么运行] ──┼──► 拼起来才能完整回答
[块C：讲了X的限制条件] ──┘
单看块C，可能感觉"跟用户问题没直接关系"，Reranker 给个极低分。你一刀切下去，图就残废了。
Kapa 最后怎么干的呢？他们在 Reranker 和生成模型之间，硬生生插了一个廉价的小 LLM 进去。
Reranker ──► 廉价小 LLM 整体审视 ──► 保留精华 ──► 大模型生成
咔哒一下扣上了 💡。
这个廉价小 LLM 会同时看着用户问题和这一整批文本块，然后用一个五级量表去打分。注意，这步是 listwise（列表级）。它看的是集合层面的相关性，不是像 reranker 那样孤立地看单块。
这步加进去之后，效果特别明显。在他们的场景里，塞进 prompt 的文本块占了单次查询三分之二的成本，比生成答案本身还贵。加了这道剪枝，直接干掉了 68% 的文本块，成本降了三分之一，召回率居然还能死死咬住 96%。
代价当然有。凭空多了一次小模型调用，每次查询得多等 0.7 秒。大模型因为输入变少省下来的那点时间，根本填不平这 0.7 秒。所以他们先在 agent 场景里默认开了这个功能——agent 哪怕这次没找到，发现不对还能自己再搜一次，容错率高。但你要是拿它接那种要求低延迟的 API，就得自己掂量掂量了。
其实 RAG 难就难在"判断"这一格。我之前画 RAG 那张图漏了一笔，这次算是补上了：Reranker 的排序只是个粗筛，真正决定上下文质量的，是那个能看懂全局的"剪枝器"。
这玩意儿真的太酷了。下期想画开哪个概念？我最近在纠结 KV cache 到底是怎么省算力的，你们想看吗？
