你在本地用 Ollama 搭 RAG，模型拉下来了、接口也通了，但一换嵌入模型召回结果就变了，或者中文问句老是答偏，却说不清到底是模型不行还是切片和检索的问题。这篇不讲协议怎么配、客户端怎么写，只给你挑嵌入模型的判断维度、场景对照和一套可执行的评测动作，让换模型这件事有据可依。
你在本地用 Ollama 搭 RAG，模型拉下来了、接口也通了，但一换嵌入模型召回结果就变了，或者中文问句老是答偏，却说不清到底是模型不行还是切片和检索的问题。这篇不讲协议怎么配、客户端怎么写，只给你挑嵌入模型的判断维度、场景对照和一套可执行的评测动作，让换模型这件事有据可依。
先说清楚一件事：嵌入模型没有「最好」，只有「对你的语料和切片最合适」。所以下面所有建议都带前提，脱离前提去抄选型结论，大概率白折腾一轮。想先看当前可选型号和大致资源占用，可以到 /embeddings 对照着看，但别把清单当答案。
先定清楚你要索引什么，再谈模型
很多人是先去翻模型清单，再回头看自己的数据，这个顺序反了。嵌入模型的作用是把文本压成向量，文本长什么样、以什么语言为主、切成多长一段，直接决定了哪一类模型合适。先做这三件事，比看十篇推荐都值。
- 把资料分成三堆：中文为主的业务文档、中英混杂的技术资料、纯代码或结构化字段。三堆对模型的语言偏好不一样，混在一起索引往往谁都照顾不好
- 明确单条切片的大致长度区间。短问答和长段落对上下文长度的要求差一个档，长度不够会静默截断，截断之后召回必然变差，而且不报错
- 确认是纯文本还是要兼容表格、代码块。含大量符号和缩进的内容对分词方式更敏感，同一模型在不同内容形态上表现可能差很远
挑模型只看这五个维度
维度不要贪多，真正影响你日常的是下面五个。每个维度都要能换算成你能承受的代价，比如内存、延迟、维护成本，而不是停留在「看起来更强」。
| 维度 | 看什么 | 常见误判 |
|---|---|---|
| 向量维度 | 直接决定索引体积和内存占用，维度高不等于检索质量高 | 以为维度越高越好，结果索引撑爆显存 |
| 语言覆盖 | 中文或多语支持是否在模型说明里明确写了 | 拿英文优先的模型硬跑中文语料 |
| 上下文长度 | 按切片后实际长度留余量，不按标称最大值切 | 切得比模型能吃下的还长，被静默截断 |
| 显存与速度 | 同一模型不同量化规格占用差很多，CPU 与 GPU 是两种体验 | 只看质量不看延迟，上线后才发现跑不动 |
| 授权与可替代性 | 许可证能不能商用，有没有同类可随时切换的备选 | 被单一模型锁死，出问题没有退路 |
这五个维度里，前三个决定「能不能用」，后两个决定「敢不敢长期用」。如果你的项目是内部工具、数据不出内网，显存和速度的权重可以往前提；如果是准备对外服务，授权和可替代性要优先确认。
按场景对照：什么情况选哪一类
下面这张对照表是给做决策用的，不是模型排行榜。每一行的意思是「这类需求下，优先看模型说明里的哪个特征」，而不是点名某个具体型号。
| 场景 | 优先特征 | 可以妥协的地方 |
|---|---|---|
| 个人本地知识库、数据不出内网 | 体积小、能全放显存或内存、中文过得去 | 维度可以低一点，召回率稍差能接受 |
| 中文为主的客服或制度问答 | 中文语料训练充分、对短问句友好 | 把预算留给更好的切片和重排，而不是堆维度 |
| 中英混排的技术文档库 | 多语模型更稳，两种语言都不能太塌 | 接受单一模型在两种语言上都只是七十分 |
| 多语言或小语种 | 确认目标语种在模型说明里有覆盖 | 没有覆盖的语种，调参数补不回来 |
| 代码或结构化字段为主 | 对符号和标识符的分词表现别太差 | 自然语言能力可以少考虑 |
换模型的动作顺序，别一把梭
换嵌入模型最容易出事的地方不是选错，而是换的过程不干净：新旧向量混在同一个集合里，或者同时改了切片，最后连问题出在哪都说不清。下面这套顺序照着走，能把变量控制住。
- 固定切片和测试集先把切片策略定死，准备一批测试问题。这一步做完之前不要动模型，否则后面所有对比都失去参照。
- 小样本双跑写个脚本，把同一批问题分别打到新旧模型上，比召回结果而不是比生成结果。生成结果受提示词影响太大，看不出嵌入模型的差别。
- 确认维度变化后重建索引维度变了就必须重建索引，不能新旧向量混在同一个集合里。这是最常见也最低级的翻车方式。
- 观察耗时与显存本地跑的时候，调用耗时和显存占用往往比质量更早成为瓶颈。换模型前后各测一次，用 /tools/speed-test 先量出延迟基线。
- 记录结论与前提把每次对比的结论连同当时的切片长度、语料范围一起记下来。脱离前提的结论，下次换项目就不成立了。
一套能坚持下来的本地评测
本地做 RAG 没人给你现成的评测集，但你可以自己攒一套小而真的。重点不是规模，是这些问题得是你业务里真出现过的问法，而不是从文档里抄的句子。
- 准备二三十条真实问题，每条标注应该命中哪几个切片。数量不大，但覆盖要贴合你的实际问法
- 只看三个指标：目标切片有没有进前几名、正确切片排在第几位、无关结果有没有挤进来
- 把结果记成表，每换一次模型或切片策略就重跑一遍，看的是趋势不是单次数值
- 评测口径可以到 /benchmarks 和 /benchmarks/registry 对照，避免自己定的标准太随意，换个人接手就看不懂
这里有个必须写清的前提：测试集只有你自己的语料，所以结论只对这个语料和这套切片成立。换个领域、换批文档，就得重测。任何人给你一个「通用最优」的说法，都要打个问号。
效果差的时候，怎么判断是不是模型的锅
效果差先别急着换模型。很多症状看起来像模型问题，实际是切片或检索参数的问题。按下面的顺序排查，能省下大量试错时间。
| 症状 | 先怀疑什么 | 再怀疑什么 |
|---|---|---|
| 问题原词在文档里出现过却召不回 | 切片把关键词切断了 | 嵌入模型的语言覆盖 |
| 语义相近的问法能召回、字面问法召不回 | 分词或归一化处理有问题 | 嵌入模型对字面匹配的能力 |
| 召回结果高度雷同、翻来覆去几条 | 切片太碎或去重没做 | 向量维度是否太低 |
| 换模型明显变好、换回去又变差 | 确认差异可复现 | 单次波动不算模型问题 |
| 加长切片后反而更差 | 上下文长度超了被截断 | 距离度量是否匹配 |
排查顺序固定成：数据与切片 → 检索参数 → 嵌入模型 → 生成模型。从前往后查，别跳着来。
上线前的一张清单
选型定了不代表结束，配置和运维没跟上，过两周又会回到「说不清哪里不对」的状态。下面这几条是上线前值得花半小时过一遍的。
- 把模型名、维度、切片长度、距离度量写进配置文件并入库，不要散落在代码里
- 索引集合命名带上模型标识，方便日后并行对比和灰度切换
- 评估重建索引的耗时。本地模型升级或量化格式变化时，你需不需要停服
- 记录每次检索的耗时与命中情况，出问题时能回看是哪一环变慢
- 数据敏感度高的场景，确认模型文件来源可信，别从不明渠道拉权重
几个反复踩的坑
最后列几个在本地 RAG 项目里高频出现的坑。它们不是模型本身的问题，但造成的后果经常被记到模型头上。
- 拿生成模型的能力去推断嵌入模型好坏，两者评测标准完全不同
- 在只有中文语料的项目里为了「通用」选了英文优先的模型，结果中文问句集体失效
- 维度改小后忘了重建索引，检索结果错乱却一直找不到原因
- 只测了十几条问题就下结论，样本太小，换一批问题结论可能反转
- 把模型清单当成一次性决定，语料和业务变了之后选型也应该重看
常见问题
Ollama 上嵌入模型这么多，有没有一个通用的首选？
没有。选型取决于你的语料语言、切片长度和能承受的显存，中文语料和中英混排的最优解通常不是同一个。建议先按本文的五个维度给自己的项目打分，再拿二三十条真实问题做小样本对比，用召回结果说话，而不是看别人推荐什么就用什么。
中文问句召回效果很差，是换模型还是改切片？
先查切片。问题里的关键词如果被切断、切片太碎或太长，换再好的嵌入模型也救不回来。确认切片合理后，再看模型说明里对中文的覆盖情况，只有英文语料训练的模型在中文问句上通常表现明显偏弱。排查顺序固定：数据 → 切片 → 检索参数 → 模型。
换嵌入模型之后一定要重建整个索引吗？
只要向量维度或模型本身变了，就必须重建。不同模型产生的向量不在同一个语义空间里，混在一个集合中检索出来的相似度没有意义，结果会错乱且很难排查。工程上建议索引集合名带上模型标识，新旧并存一段时间，方便对比和回滚。
本地跑嵌入模型，速度慢到什么程度该考虑换小模型？
没有统一阈值，取决于你的入库频率和检索并发。个人知识库一次性入库后再慢慢查，慢一点无所谓；如果是每天增量更新、线上要实时检索，就要先把延迟基线量出来。可以到站内 /tools/speed-test 测一次，再用同样的方法测换模型后的表现，对比的是差值不是绝对值。
怎么确认自己的评测结论不是碰运气？
把测试问题和期望命中的切片固定下来，每换一次模型或切片策略就重跑同一批，看的是多次结果之间的趋势。样本太少（比如十几条）时结论容易反转，测出来的名次也没意义。需要参照测评口径的话，可以看站内 /benchmarks 与 /benchmarks/registry 对评测方法的说明，再定自己的标准。
