dify 配置 ollama rerank

你在 Dify 里搭知识库，向量召回出来的段落总是答非所问，想加一层重排把最相关的顶到前面，但发现 Ollama 的接口跟 Dify 里填的字段对不上，保存后测试也没反应。这篇按顺序把判断标准和操作步骤拆开讲：先确认你的 Ollama 版本有没有重排能力，再决定走原生接口还是 OpenAI 兼容层，最后给一份联调排查顺序。

你在 Dify 里搭知识库，向量召回出来的段落总是答非所问，想加一层重排把最相关的顶到前面，结果发现 Ollama 的接口跟 Dify 里填的字段对不上，保存后测试也没反应。这篇按顺序把判断标准和操作步骤拆开讲：先确认你的 Ollama 版本有没有重排能力，再决定走原生接口还是 OpenAI 兼容层，最后给一份联调排查顺序。整篇不讲原理堆砌，只讲你下一步该动手做什么。

开始之前先准备一个东西：同一批测试问题。没有它，加重排前后你根本分不清是变好了还是错觉。准备三五个你业务里的真实问题，记下当前召回的前几条长什么样，这是后面所有判断的基线。

先想清楚：这一步到底解决什么问题

向量召回看的是语义距离，重排看的是问题与段落的直接相关性，两者叠加才把「像」变成「对」。段落多、问题短、专业术语密集的场景收益最明显。但要说清楚不适用的边界：语料只有几十条、召回结果本来就稳定，加重排只会拖慢响应，还可能因为重排模型判断失误把正确段落压下去。

• 重排模型只输出相关性分数、不做生成，别把它当成第二个对话模型去配，Dify 里对应的是 Rerank 位置而不是 LLM 位置；
• 先量基线：用准备好的那批问题跑一遍不加重的召回，把命中情况记下来，加重排之后再对一次，否则你没法判断这一步值不值；
• 如果你只是想让回答更通顺，重排帮不上忙，那是模型和提示词的事，别在这里绕；
• 重排会增加一次额外推理，响应时间大概率上升，能不能接受要在动手前定下来。

你的 Ollama 到底能不能跑重排

这一步别急着改 Dify，先确认本地服务本身有没有这个能力。Ollama 原生并不一定暴露重排端点，你要先用命令行或直接发 HTTP 请求打一次，看返回结构里有没有分数字段。拿不到分数，后面所有配置都是白搭，那就得考虑走兼容层或换部署方式。

显存这块也要提前算。重排模型通常比对话模型小，但依然要占显存，和对话模型抢卡是小机器上最常见的坑。具体多大的模型装得下、当前卡能跑到什么程度，到 部署测算（/models/deploy） 按你手上的硬件核对当时的数字，别照着别人的配置抄。

重排模型的选择思路和对话模型不一样，看的是中文语料表现、最大输入长度和打分稳定性，不看参数规模。具体挑哪一类，到 嵌入模型（/embeddings） 页面按当时的型号清单核对，那里会随实际情况更新。

在 Dify 里把这条路接起来

先明确 Dify 认的是哪一类接口：Rerank 位置通常要求返回带相关性分数的列表。你本地接口的字段名和它期望的不一致时，不要硬填原始地址，在中间做一次格式转换更省事。这一步是整个配置里最容易卡住的地方，卡住时先别怀疑模型。

1. 确认期望格式在 Dify 的重排配置界面看它要求什么字段、分数是越大越好还是越小越好，把这个格式记下来。
2. 搭一层薄转发写个小服务：接收 Dify 传来的查询和候选段落，转成你本地模型能吃的请求，再把分数映射回期望字段。不用复杂，能转发加映射就够。
3. 改地址Dify 如果跑在容器里，localhost 指向容器自己，要换成宿主机可达的地址；端口、路径前缀、末尾斜杠按你实际服务改，别照抄示例。
4. 联调验证回到知识库的召回测试，用同一组问题对比加重排前后的命中位置。命中位置变了，说明链路通了；没变或者变差，先查中间层映射，不是模型不行。

这里有个细节值得单独提：转发服务里要做超时处理。重排请求比普通请求慢，Dify 侧超时设太短会直接判失败，表现就是「测试没反应」，其实请求发出去了只是没等到结果。

顺序排查：保存不了、没反应、变慢了

接完之后出问题，按下面的顺序查，别东一榔头西一棒子。这三类症状的成因不一样，查的顺序也不一样。

测试通过但线上问答没变化，是出现频率最高的一类。很多人的配置确实存下来了，但没有真正启用，配置存在不等于生效，先去召回设置里点一遍确认。判断不了是模型问题还是链路问题时，用 接口测速（/tools/speed-test） 量一下本地重排接口的延迟基线，有了这个数才能区分是链路慢还是模型慢。

重排解决的是排序问题，不是召回问题；先把候选段落捞对，再谈谁排前面。