ollama rerank 模型 推荐

RAG 检索效果差，很多时候不是向量模型不行，而是缺了重排这一步。想加 rerank 又会卡在几个地方：ollama 里到底能拉哪些重排模型、跑得动吗、中英文混排效果够不够、许可证能不能商用。这篇不评比谁第一，只给一套可执行的挑法：先算显存、再定档位、最后用小样本验收。

先搞清 rerank 在链路里干什么，别跟嵌入模型搞混

很多人一听 rerank 就想到「换个更强的模型来搜」，其实它跟嵌入模型是两回事。嵌入模型做的是把 query 和每篇文档各自变成一个向量，提前建好索引，搜索时比一比距离，速度快、能覆盖几百万条，但精度只能到「大致相关」；rerank 是等粗排把候选捞回来之后，再逐条跟 query 放一起算一次分。一个是海选，一个是复试，接力关系，不是谁替代谁。

嵌入模型（embedding）

query 和文档分开编码成向量，靠距离算相似度，能离线建索引、扛住海量文档

重排模型（rerank）

query 和文档拼在一起送进交叉编码器，逐条算相关性，准但慢，只能处理小批量候选

粗排 / 召回

先用向量或关键词从全量库里捞出一小撮候选，通常几十到一两百条，交给重排

因为重排是逐条现算，候选越多越慢，所以它天生只适合几十到一两百条这个量级。你要是把召回开到几千条再全丢给重排，延迟会直接失控，收益也未必比多召回一点更好。判断该不该加重排，拿几条真实 query 各跑一遍：看召回回来的前 N 条里，有没有「答案确实在，但排在很后面」的情况。有，就值得加重排把它提上来；如果前 N 条里压根没有正确答案，那问题出在召回和切块，加重排也是白搭。

• 候选集合本来就很准：关键词精确匹配、结构化字段过滤、文档量本来就少，前几条已经够用，加重排是徒增延迟
• 文档总数只有几十上百条：粗排本身就把大部分相关文档捞回来了，重排的排序收益很有限
• 延迟卡到毫秒级：重排要现算 query 和候选的交互，毫秒预算下基本没空间，此时优先砍候选数或直接跳过
• 查询本身是精确 ID、编号、错误码这类：匹配确定，不需要语义重排
• 冷启动阶段先验证召回质量：召回都没调好就上重排，方向反了，先把切块和嵌入修明白

1. 先量召回质量挑 20 到 50 条真实 query，人工标出正确答案在第几位。答案普遍在前几条，说明召回够用，重排收益小。
2. 找出「答案在但排太后」的样本专门统计答案落在召回中后段的 query 占比。这类样本多，才说明排序是瓶颈，重排值得上。
3. 区分「没召回」和「排太后」如果答案压根不在候选里，先回去改切块粒度、嵌入模型和召回条数，别急着加重排。
4. 小批量试重排再决定只对召回 top 几十条跑重排，观察排序变化和延迟增量，看这两项是否都符合你的预期。

按显存和延迟定档：多大模型、什么量化才跑得动

很多人一上来就问「哪个重排模型最好」，其实顺序反了。先算你这条链路要花多少时间，再决定模型多大、量化多狠。重排的开销跟候选条数近似线性：50 条和 200 条不是一个量级，把候选压到 30-50 条，往往比换个小模型省得更多，而且几乎不掉效果——前提是你的召回本身没漏掉正确结果。

1. 先压候选数把检索阶段的 topK 从 200 往 50、30 试。看最终答案有没有变差，很多场景根本不用重排那么宽。压不下去再考虑换模型档位。
2. 再选模型规模参数量跨度很大的重排模型之间，往上一档延迟翻倍很常见。先用最小档把链路跑通，量出延迟和效果基线，效果不够再换大一档，一次只动一个变量。
3. 最后调量化档位显存还有余量就优先保精度，显存紧才压量化。重排对量化的敏感度通常低于生成，但中文长句和边界样本上仍会掉分，得拿你自己的 badcase 验。
4. 量整条链路基线到 站内测速页 记录检索、重排、生成三段各自的耗时。只盯重排单点没意义，用户感受到的是三段相加。

延迟预算要整条链路一起算。检索 + 重排 + 生成三段加起来才是用户看到的等待时间，单纯把重排优化到极致，如果它只占很小比例，收益也有限；反过来，如果重排占了大头，就该优先压候选数或降量化档位。判断标准是看比例，不是看单点数值，具体数字到 站内测速页 拿你自己的机器跑出来。

候选条数

送进重排的文档数量，重排耗时跟它近似线性，压它通常比换模型更划算

量化档位

同一模型的不同压缩程度，压缩越狠显存越省但精度可能下降

量化口径

不同工具对量化档位的命名不一致，对照术语到 站内术语页

链路预算

检索、重排、生成三段耗时之和，按比例决定优化哪一段

语种和领域：中文场景别照搬英文榜单

英文榜单上排前面的重排模型，搬到中文语料上经常翻车。原因很朴素：训练语料里中文占比低，模型对中文的分词边界、语序、省略主语不敏感，排序时容易把语义相近但答非所问的文档放到前面。中英混排、带代码片段、从表格里抽出来的文字，更是重排模型的高危区，这类内容往往缺少完整句子结构，模型拿到的信号本来就少。

• 先确认它能不能吃中文：拿几句纯中文 query 试，看返回的排序是不是明显乱掉
• 再试中英混排：query 里夹着英文术语、文档里中英夹杂，看模型是否只认英文部分
• 再试代码片段：文档里包含变量名、函数名、报错信息，看模型会不会把无关代码段排到前面
• 最后试表格文字：从表格里抠出的短句、带竖线和数字的行，看模型是否还认得语义

领域词是重灾区，别指望通用模型全懂

专有名词、缩写、产品型号、内部代号这类词，是通用重排模型最容易打错分的地方。模型没在训练里见过这个词，就只能靠字面相似度猜，结果常是把含相同前缀但意思完全不同的文档排上来。如果你的语料里这类词密度高、且反复出现，通用模型基本救不回来，得考虑用垂类语料做微调，或者直接换成对这块更熟的模型。

快速判断：几十条真实语料就能看出问题

1. 抽样从你真实的 query-文档对里抽 30 到 50 条，不要挑简单的，把中英混排、代码、表格文字都覆盖到
2. 人工排一遍你自己按相关性给一个大致顺序，不用精确到每一名，只要分出「明显相关」「勉强相关」「不相关」三档
3. 跑模型对照把同一批交给候选重排模型，看它返回的前几条里有没有混进明显不相关的文档
4. 看错在哪重点看前排错误：是中文理解错、还是领域词认不出、还是短文本处理不了，据此决定微调还是换模型

什么情况下别用重排模型

如果你的语料高度单一、术语固定、查询模式也基本不变，规则打分或关键词加权往往比重排模型更稳、更便宜，也更好排查问题。这种情况下硬上模型，既要维护推理服务，又要处理偶发的排序抖动，收益并不明显。判断标准很简单：当规则能把前几条排得八九不离十，就不必为了用模型而用模型。

反过来，如果语料里自然语言比例高、查询意图多变、同义表达多，规则就撑不住了，这时才轮到重排模型上场。至于具体哪些重排模型在中文上更稳、价格和延迟如何，别照搬外面的榜单，到站内模型资料库和价格追踪页看当时的数字。

许可证和运维：能不能商用、怎么升级、怎么回退

挑 rerank 模型时，很多人先看效果，许可证往往最后才瞄一眼。但重排模型基本都要进生产链路，许可证直接决定你能不能把它塞进商业产品里。判断口径可以先到 /ai-dict/category/safety 把站内关于开源许可和安全合规的术语过一遍，再看具体模型的 LICENSE 原文，别只看仓库首页写的「开源」两个字。

有一种常见误解：模型权重能下载，就等于能商用。实际上权重文件本身可能带单独的许可协议，训练数据的来源也可能带来额外约束。如果你只是内部跑个实验，宽松与否影响不大；但凡要对外提供付费服务、或者嵌进交付给客户的产品里，就得按「不可商用」的保守口径先把范围缩一遍。

别把模型锁死在业务代码里

重排模型迭代很快，今天是首选，过一阵可能就有更合适的选择。真正省事的做法是在选型阶段就留一层抽象：业务侧只调用一个本地重排接口，模型名字、路径、参数都放在配置文件里。这样换模型只改配置不改代码，回退也是一样，改回上一份配置重启即可。

• 业务代码只依赖一个统一的重排调用入口，不直接引用具体模型名
• 模型路径、超时、批量大小全部走配置文件或环境变量
• 保留上一版模型和配置，回退时切换指向即可，不用重新构建
• 升级前先在旁路环境跑通，再切主流量
• 记录每次切换的模型标识和时间，出问题能快速定位是哪一版

资源余量和降级兜底

1. 压测要压并发平时单条请求跑不爆显存，不代表上线没事。显存峰值通常出现在并发最高的时候，压测时必须按预估峰值并发去打，观察显存和响应时间的变化曲线。
2. 给重排留独立余量如果同一台机器上还跑着生成模型，两边会抢显存。要么给重排单独分配额度，要么把生成和重排分机器部署，别让它们互相拖垮。
3. 超时必须有兜底重排接口设一个合理超时，超时后直接退回粗排结果，这比整个请求失败要好得多。降级逻辑要提前写好并测过，而不是出事再补。

关于升级路径和版本迁移，站内已经有一份模型换代相关的迁移清单，换重排模型时可以直接照着走相关步骤，不用每次重新摸一遍。需要提醒的是，上面这套留抽象层、压并发、超时降级的做法，更适合有一定请求量的生产场景；如果只是本地单人试用、不对外提供服务，复杂度可以适当降低。

一套能照做的落地步骤

这一节不讲选哪个模型，只讲拿到候选模型之后怎么验。顺序别乱：先攒离线样本，再比效果，再压延迟和显存，最后加兜底。跳步的代价是上线后才发现问题，那时候改起来要动整条问答链。

1. 攒一份离线样本把当前检索链路的结果整批存下来，每条至少留四样：用户 query、召回的文档原文或 id、这批里正确答案落在第几位、以及当时用的检索参数。样本量按真实流量的一小段够用就行，关键是覆盖几类高频问法，别只挑好答的。存成 jsonl 或表格都行，但要能反复跑、跑完能直接算指标。
2. 只比「正确答案进前三」的比例把两三个候选重排模型分别跑这份样本，统一输入格式和截断长度，输出每条的新排序。只看一个指标：正确答案被排进前三的比例，和原始排序对比有没有提升。别去看模型自带的打分或总分，那些数字跨模型不可比，容易把你带偏。哪个模型把这个比例抬得明显，才进入下一轮。
3. 压延迟和显存峰值用真实并发量打一遍，不要用单条请求测出来的数字。记录每条的平均和尾部延迟、显存峰值、以及重排这一段的耗时占整条链路的比例。判断标准是落在你的预算内：如果重排把整体响应拖到用户能感知，那效果再好也得退回去调 batch、截断长度或换更小的模型。
4. 加兜底逻辑重排服务要有超时和失败回落：超时或报错就返回原始召回顺序，让问答链继续走完，而不是整条断掉。同时设一个开关，出问题时能一键关掉重排。这一步不做，等于把检索的稳定性全押在一个新组件上。
5. 上线后定期抽样复盘上线不是终点。语料分布会变，新的问法、新的文档类型都会让效果漂。固定周期抽样一批线上真实 query，重新算「正确答案进前三」的比例，和上线时的基线比。掉得明显就考虑换模型、调参数或补样本，模型和参数都不是一劳永逸。

• 样本里要包含正确答案的原始位置，否则没法算提升
• 候选模型统一输入格式和截断长度，不然比出来的是格式差异不是模型差异
• 压测用真实并发量，单条请求的数字会骗人
• 兜底和开关一起做，只做超时回落还是可能被新组件拖住
• 复盘要有基线，没基线就不知道是漂了还是正常波动
• 每一步的原始数据都留档，后面换模型时能直接复用同一份样本

验收清单：上线前后各看什么

换 rerank 模型最怕两件事：一是换完心里没底，二是出问题才知道。下面这张清单分「上线前」和「上线后」两段，照着走一遍，至少能让你在出问题时说清楚是模型的问题还是链路别处的问题。判断标准不追求绝对值多好，而看它相对你现在的方案有没有稳定改善。

1. 先固定评测样本挑一批你业务里真实的 query，配好「哪几篇文档算对」的标注。样本不用多，但必须固定，每次换模型都跑同一份，否则数字没法横向比。
2. 再压并发测资源按你线上真实的目标并发去打，记录耗时、峰值显存和失败率。单条请求快不代表并发下也稳，这一步是筛掉「实验室好看、上线就崩」的模型。
3. 上线先小流量别一次全量切。留一部分流量走旧方案做对照组，观察首字延迟、点踩率和追问率的变化，确认没退化再放大。
4. 把每次对比存档哪次换了什么、样本上的表现、线上指标怎么变，都记一笔。攒几次之后，你自己的数据比任何别人的推荐都更值得参考。

什么情况下判定这次换模型不划算？两类信号最常见。第一类是提升幅度很小，但延迟和资源占用明显上来了——排序是好了那么一点，可用户等得更久、机器也吃得更满，算总账不划算。第二类是改善只集中在少数长尾 query 上，主流问题几乎没动。这两种情况都建议先别继续在 rerank 上折腾，回头去看看切块和召回环节。

• 提升幅度小、延迟和成本明显上升：优先回退，钱和延迟花得不值
• 只有少数长尾 query 变好：先优化切块粒度，很多「答不出来」是召回没捞到
• 点踩和追问没改善但排序指标变好：说明瓶颈不在重排这一层
• 并发失败率升高：可能是部署侧资源不够，不一定是模型本身不行
• 首字延迟明显变差：确认是重排引入的，还是链路里别的环节一起变了