RAG 里最贵的一步不是嵌入，是 rerank

一个”Claude 越来越笨”的错觉

上个月有个做法律 SaaS 的朋友来问我：他们的产品用 Claude Sonnet 4.5，上线半年用户一直反馈”有时候答得特别准，有时候完全跑题”。他们以为是模型退化了，想换 Opus。

我让他把 retrieval 的日志拉给我看。一看就笑了——每次捞 top-10 文档扔给 Claude，前 3 名里经常掺着风马牛不相及的条款。比如用户问”离婚财产分割怎么算”，第 2 个召回结果是一条商业合同违约金的判例。

Claude 不是笨，是被喂了垃圾。embedding 召回本来就这水平，尤其中文专业领域，同义词、近义词、歪打正着的语义相似——全给你召回来了。

然后我问他：你们 pipeline 里有没有 rerank 这一步。他说没有，怕贵。

我就说，你知道最贵的是什么吗？是用户看了一次歪答案就流失了。你省的那点 rerank 钱，抵不过一个月掉的 ARR。

先说清楚什么叫 rerank

你可以把 RAG 召回想象成两阶段：

第一阶段叫 retrieval，图的是召得全。 通常是向量相似度（embedding）+ BM25 关键词混合，扫整个库，捞 top-50 甚至 top-100 回来。这一步要求”宁可错召不可漏召”。

第二阶段叫 rerank，图的是排得准。 把 top-50 做精细打分，输出 top-3 或 top-5 给下游 LLM。

很多团队只做第一阶段，直接 top-10 送进 Claude。问题是 embedding 向量 768 维或 1024 维，做的是粗粒度语义匹配，query 和 chunk 的精细关系它捕捉不到。

举个最简单的例子。query 是”用户怎么取消自动续费”，embedding 会把”自动续费的收费规则””自动续费常见问题””用户注销账号流程”统统召回来，得分相差不到 0.03。这种情况你让 Claude 去文档里找答案，运气好能搞对，运气不好就搞砸。

三种 rerank 方案的成本对比

我现在做项目基本三种里选一种，看场景。

方案 1：cross-encoder 模型（bge-reranker-v2 这类）

开源，自己部署。精度很好，尤其中文。一次 rerank 50 段大概 200ms，单次成本算下来折合 0.0003 美刀（主要是 GPU 电费摊销）。适合有 infra 团队的公司。

缺点是需要维护模型服务，冷启动慢，流量高峰要加机器。小团队头疼。

方案 2：用 LLM 做 rerank（比如 Haiku 4.5）

把 query + 50 个候选 chunk 的 ID 和摘要塞进 Haiku，让它输出排序。我实测一次调用大概 3K input + 100 output token，按 Haiku 定价算下来 0.0008 美刀。

优点是精度出奇的好，而且可以通过改 prompt 让它关注特定维度——比如”优先考虑时效性””优先召回含具体金额的条款”。这种定制在 cross-encoder 里是做不到的。

缺点是延迟比 cross-encoder 大，通常 800ms-1.2s。对实时聊天场景有点压力。

方案 3：LLM rerank + Claude 主力模型

就是上面那个方案，但主力模型用 Sonnet 或 Opus。

我现在 80% 的项目用方案 2+3 的组合。理由很简单：Haiku 做 rerank 的可解释性比任何 cross-encoder 都强，遇到 bad case 你能看到它为什么这么排——让它输出 ranking 的时候顺便说一句 reason 就行。调试起来跟调试人类员工一样。

什么场景 rerank 就是浪费钱

不是所有系统都值得加 rerank。我列几个不用加的情况：

文档库特别小（< 500 个 chunk）。 直接把所有 chunk 按相关度塞进 context，用 Claude 自己的 attention 筛就行。反正也就几万 token。

query 特别结构化。 比如”查 2025 年 3 月 15 日订单号 A123”，这种直接走 SQL 或者精确匹配，向量都不用。

召回率要求极高，精度要求一般。 比如推荐场景的”相关文章”，用户点不点无所谓，没必要为精度多花一道。

响应延迟极敏感（< 500ms）。 rerank 这一步怎么也要 300ms 起，吃不消就砍掉。

除此之外我基本都会加。尤其客服、问答、法律、医疗这种答错代价高的场景。

我现在项目的三段式召回配置

贴一下我在一个教育 SaaS 项目里跑的真实配置，服务了他们 84.2 万次月活 query。

第一段：双召回

BM25 捞 top-30，向量捞 top-30，去重合并成 50 左右。这一步只管量，精度靠下一步。

第二段：Haiku 4.5 rerank

prompt 里写清楚评分维度（相关度、时效性、权威度各占几分），让 Haiku 输出 top-5。这一步关键是 prompt 里的评分标准写死，不同 query 类型用不同 prompt——基础问答一套、政策解读一套、案例咨询一套。

第三段：Sonnet 4.5 生成

拿 top-5 作为 context，配合用户 query 生成最终答案。

整条链路一次 query 的成本：向量查询 0.00002 刀 + Haiku rerank 0.0008 刀 + Sonnet 生成 0.015 刀 ≈ 0.016 刀。

对比他们之前单用 Sonnet + top-10 直召的版本（一次 0.022 刀，因为 context 更长），成本还低了 27%，准确率从 74.8% 涨到 89.3%。

两个经常被问的细节

Q：rerank 的时候 chunk 要不要截断？

要。我一般只给 rerank 模型每段前 500 token + 后 100 token，中间用 ...省略... 代替。rerank 不需要看完整文本，它判断相关性主要靠开头和结尾。省下来的 token 够你多召 20 个候选。

Q：rerank 阶段要不要告诉模型对话历史？

看场景。单轮问答不需要。多轮对话如果涉及指代（”那个方案””刚才说的那家”），必须把最近 1-2 轮对话摘要喂给 rerank 模型，否则它理解不了 query 在说什么。这个细节我踩过坑，排查了两天才定位到。

写在最后

Rerank 这一步，看着是个”锦上添花”的优化，实际上是 RAG 能不能落地商业场景的分水岭。

我见过太多团队 POC 阶段效果惊艳，上线真实流量之后口碑崩了——往往就是 retrieval 从 demo 阶段的 100 个 chunk 扩展到 10 万个 chunk，embedding 的粗粒度就遮不住了，rerank 这道防线又没有。

花那 0.0008 美刀吧，真的。