做 RAG 的人常在这卡住：文档已经向量化进库了，检索出来的东西还是不对味，这时候到底该换嵌入模型，还是再加一个重排模型？也有人反过来，一上来就叠重排，结果延迟涨了效果没怎么动。这篇不堆原理，只讲两者的分工、在链路上各站在哪一步、什么情况下加哪个才有意义，以及怎么用站内资源做初步判断。
做 RAG 最常卡在两个地方：一种是文档早就切好向量化进库了，检索出来还是不对味；另一种是一上来就叠了重排，结果延迟涨了一截、效果没怎么动。这俩问题看着像，其实指向的是两个不同的零件：嵌入模型和重排模型。它们不是替代关系，也不是多多益善，各自站在链路的不同位置干不同的活。
这篇不堆原理，只讲清楚它们的分工、先后顺序，以及什么情况下加哪一个才有意义。看完你至少能做两件事：判断眼前的问题是出在召回还是排序，以及用一组固定样本自己验证加不加重的到底值不值。
两者的分工到底差在哪
嵌入模型干的事是把一段文本压成一个向量，让语义相近的内容在向量空间里靠得近。它的主场是「从一堆内容里快速圈出一个候选集」，追求覆盖率和速度，宁可多圈一点也不能漏。重排模型干的是给一批已经圈出来的候选重新打分排序，它看的是「查询和这条候选到底有多相关」，追求精度。
- 嵌入模型
- 单条文本进、单条向量出，离线批量算好存库，主打快和广
- 重排模型
- 一条查询加一条候选成对进、一个分数出，查询时实时算，主打准但慢
- 一句话记法
- 嵌入决定「能不能捞到」，重排决定「捞到的排得对不对」
- 捞不到的东西，重排再强也救不回来，因为候选集里根本没有它
- 重排的输入天然比嵌入贵：嵌入一次算完能反复用，重排每次查询都得重算一遍
- 判断问题出在哪：翻一翻最终拼进提示词的那几条，是压根没出现正确答案，还是出现了但排在后面
- 前者去调切块和嵌入，后者才轮到加或换重排，顺序反了就是在做无用功
在链路里它们各站哪一步
典型链路是：切块 → 嵌入 → 向量库召回（取一个远大于最终要用的条数）→ 重排 → 取最终几条拼进提示词。重排站在召回之后、拼提示词之前，属于精排环节。如果中间还有关键词检索、元数据过滤，一般也放在重排之前，让重排看到的是已经收窄过的候选集，别让它对着一堆明显不相关的文本空转。
- 先定候选数量召回阶段取的条数要比最终喂给模型的多不少，多出来的这部分就是留给重排做取舍的空间。取太少，重排没得挑；取太多，重排的耗时和成本会直接顶上来。
- 把过滤放在重排前时间、权限、类型这类元数据过滤能用就用，先把候选集缩小，再进重排。重排处理的是成对文本，候选越多越慢。
- 确认因果顺序先重排再召回是没有意义的，重排不负责从全库找，只负责给已有候选打分。链路图画出来如果顺序反了，先改回来再谈效果。
- 多轮检索怎么放如果链路里有类似 Agent 的多轮检索，重排可以每轮都跑，也可以只在最终汇总前跑一次。前者更准但更慢，后者省延迟，取决于你的预算。
召回负责别漏，重排负责别乱，两件事分开看，调参才不会瞎撞。
什么时候该加重排，什么时候不用
加不加重排，本质是算一笔账：重排帮你把真正相关的候选排到前面，代价是每次查询都多一段实时计算。当候选集明显偏大、最终又只喂几条给模型时，这笔账通常划算，因为你是在替模型做取舍。反过来，候选本来就少、文档库小且集中，重排带来的排序改善可能被它增加的延迟吃掉。
| 场景特征 | 建议 | 原因 |
|---|---|---|
| 候选几十上百条，最终只喂几条 | 优先加重排 | 排序收益最大，取舍空间足 |
| 候选本来就少，库小且集中 | 先别加 | 改善有限，延迟却实实在在 |
| 查询是编号、错误码、专有名词 | 可能不需要 | 向量召回本来就够准，重排收益低 |
| 对首字延迟极敏感的实时问答 | 谨慎加 | 重排会拖慢首包，需要单独测 |
| 答案出现在候选里但排在后面 | 加重排 | 典型的重排适用场景 |
- 先分清是「没捞到」还是「捞到了没排前面」，前者调切块和嵌入，后者才轮得到重排
- 加重排前先测一遍只召回的结果，留个基线，不然加了之后你分不清是重排的功劳还是别的改动
- 重排不是一次加就一劳永逸，换了嵌入模型、改了切块策略，排序表现都可能变，要重新看
选型和验证的落地做法
选嵌入模型，先看它支不支持你的语种和文档形态，长文档、代码、表格这些的处理差异不小，维度高低不是唯一指标。选重排模型，重点看它对长候选文本的处理能力和推理速度，因为它是查询时实时跑的，速度直接决定用户体验。
别只看模型介绍页的结论，自己准备一组固定的查询和标准答案，把「只召回」和「召回加重的」结果并排比，看最终答案有没有变好，而不是只看排序分数。模型规格和当前可选项可以到 /embeddings 和 /models 对着看当时的清单，具体型号和数字别凭记忆。
成本要分开算：嵌入基本是一次性入库成本，重排是按查询次数持续产生的成本，调用量一大差距就明显。估算方式可以到 /tools/model-cost-calculator 照自己的调用量套一遍，再看 /price-watch 核对当时的报价变化。
- 准备固定测试集：查询、标准答案、期望命中的文档，这三样缺一不可
- 对照组只留一个变量：要么只改重排，要么只改嵌入，别同时动
- 重点看最终答案质量，排序分数只是中间指标，不是目标
- 记录每次改动前后的延迟，重排的代价主要体现在这里
- 换模型前后都去站内页面核对当时的规格和价格，别用记忆里的数字做决策
常见问题
只用一个嵌入模型，不加任何重排，RAG 能跑吗？
能跑，很多小规模知识库就是这么做的。前提是你的文档量不大、查询意图比较集中，召回前几条基本够用。一旦发现答案错在「正确文档在候选集里但排在后面」，就说明排序成了瓶颈，这时候再考虑加重排，而不是一开始就叠上去。
换了更好的嵌入模型，还需要重排吗？
两件事不冲突。换嵌入模型改善的是召回质量，让正确内容更容易被捞进候选集；重排改善的是候选集内部的排序。如果问题出在召回阶段，换嵌入有用；如果正确内容已经进候选集但排不上去，换嵌入帮助有限，重排才是对症的。先定位问题在哪一步再动手。
重排会不会明显拖慢响应？
会，因为它是查询时实时计算，每个候选都要过一遍模型。候选条数、候选文本长度、重排模型规模都会影响耗时。常见做法是把召回的候选数控制住，只在必要时跑重排，并单独测一下加了重排前后的端到端延迟，确认在可接受范围内再用。
