ollama rerank model api

RAG 做到一半常卡在这：向量召回把一堆相似段落捞回来了，但排在前面的不是最该用的那几段，答出来就跑偏。想加重排，一搜全是云端接口，本地这边 Ollama 到底能不能干、该拉什么模型、调哪个接口、返回结构跟向量模型是不是一回事，没人一次说清。这篇按「能不能用—怎么调—怎么选」走一遍，给可以直接照做的排查顺序。

向量召回把一堆意思相近的段落捞回来，但排在前面的往往不是最该用的那几段，模型就顺着错的上下文答偏。想补一层重排，一搜全是云端接口，本地这边 Ollama 到底能不能干、拉什么模型、调哪个接口、返回结构跟嵌入模型是不是一回事，很少有人一次讲清。这篇按「能不能用—怎么选—怎么接—怎么排错」走一遍，给能直接照做的动作。

先把预期放正：Ollama 的定位是本地跑模型和提供统一推理端点，重排不是它的原生一等公民。所以问题要拆成两层——模型侧能不能拉到重排权重，接口侧用什么方式让它吐出一个可排序的分数。这两层任何一层没落实，后面接 RAG 都是白搭。

先分清：Ollama 里的重排和向量模型不是一回事

嵌入模型一次编码一条文本，输出向量，靠余弦距离比远近；重排是把 query 和候选文档拼成对送进去，输出一个相关度分数。分数不是向量，别指望拿重排模型的输出直接入库建索引——它只负责给已有候选排序，不负责召回。

嵌入模型

单条文本进，出向量，用来建索引和粗召回

重排模型

query 加文档成对进，出一个相关度分数，用来精排

生成模型兼职打分

用提示词让对话模型判断相关度并只回分数，模型现成但慢

打分端点

兼容风格的接口，把重排模型当打分器调用

Ollama 的对外接口主要围绕生成和嵌入两类走，重排不在标准接口清单里。所以「有没有 rerank API」这句话本身要拆开看：你手上那版支持哪些端点，先到 /official-api 这类接口资料页对一遍再动手，别照几年前的博客抄命令，端点名字和返回结构都可能已经变了。

• 口径一：通用生成模型按提示词硬打分，门槛最低，稳定性最差
• 口径二：走兼容风格的嵌入或打分端点，把重排模型当打分器接，速度和稳定都更好
• 口径三：自己拉重排权重起个独立服务，Ollama 只管生成，重排单独部署
• 选哪种取决于候选池大小和对延迟的容忍度，不是取决于哪个听起来更高级

选型：先按「要不要成对打分」分叉，再按硬件收口

选型第一步不是看模型多大，而是看候选池有多少条。候选只有几十条、对延迟不敏感，用通用生成模型兼职打分也能用，好处是模型本来就拉好了；坏处是每条候选都要过一次前向，几十条就明显拖慢，上百条时这条路基本不成立。

候选池大、要的是排序质量，就优先找专门的重排模型权重。这类模型通常体积比对话模型小得多，成对打分的吞吐高一个量级，是 RAG 里更常见的选择。显存先看基线：重排模型一般比同档对话模型省，但成对打分意味着 N 条候选就要 N 次推理，峰值显存和延迟都要按候选条数乘一遍。具体能跑多大、能扛多少条候选，到 /models/deploy 按你的卡和量化档位算一遍再定，别凭感觉。

别的模型横向对比别在这篇里找结论，口径和清单会变，去 /embeddings 看当时列了哪些、怎么测的。选型这事没有一劳永逸的答案，你的候选分布变了，合适的选择也会变。

接进 RAG 链路：召回—重排—截断的三步动作

1. 粗召回放宽向量检索先取回比最终要用的条数多几倍的候选。取多少条要跟重排的打分成本一起定，因为重排耗时基本和候选条数成正比，取太宽等于给自己加延迟
2. 成对打分重排把 query 和每条候选拼成对送进打分接口，拿回分数后按分数重排。注意分词和截断策略要统一，否则同一条内容在召回和重排里被切成两段，分数会失真
3. 按阈值截断设一个分数下限，低于它的直接丢掉，宁可少给上下文也别塞噪声。上下文里多塞两条不相关段落，效果比少给两条更差
4. 上线前做 A/B同一批问题跑「只召回」和「召回加重排」两版，重点看答案里引用错的段落有没有变少。没有这个对照，你无法判断加的那段延迟值不值

这三步里最容易做错的是第三步。很多人习惯只取前 K 条，不管分数高低，结果 K 填大了就塞噪声、填小了就漏掉关键段落。阈值截断能让条数随问题难度浮动，简单问题少给、复杂问题多给，比固定 K 稳。

本地跑的常见坑与排查顺序

排查顺序别乱：先单独测重排接口的返回结构对不对，再测单条候选打分是否随相关性单调变化，再压候选条数看延迟曲线，最后才接回完整链路。跳步排查最常见的后果，是把接口问题误判成提示词问题，然后花一整天改提示词。

• 返回结构对不上：先看字段名和数值类型，别急着调模型
• 分数不单调：同一对文本换个顺序再打一次，看是否稳定
• 延迟突然变差：先看候选条数是不是涨了，再看模型有没有被换掉或退回 CPU 跑
• 分数忽高忽低：多半是提示词没约束输出格式，或温度没关
• 阈值不敢设：先把历史 query 的分数分布拉出来看，再定下限

# 思路示例，端点名以站内接口页为准；先确认服务在监听
curl -s http://localhost:11434/api/tags
# 再用单条候选做打分自测，确认返回里有可解析的数值字段

延迟变差时，别凭感觉猜。到 /tools/speed-test 量一遍当前基线，有数才好对比是模型变了、候选变多了，还是机器被别的进程占了。同一个问题两次测得差很多，说明机器本身不稳定，先解决这个再看模型。

还有一个常见错判：把重排当召回用。重排只对已有候选排序，候选池里没有的内容它救不回来。如果你发现正确答案根本没进候选池，问题在召回那层，加重排没用，得回头调索引或改切分策略。这种情况不适用本条排查顺序，直接从召回侧查起。

重排能改的是顺序，改不了有没有——答案不在候选池里，再多算力也排不出来。