ollama 嵌入模型 中文 推荐

你在搭中文 RAG，向量库接好了、切分也调了，偏偏召回就是不准，这时候多半是嵌入模型没选对。这篇不讲榜单有多少名次，只给按场景挑模型的判断标准和可执行动作：先分清你的语料是短问句还是长文档，再看多语言、维度、显存和量化档位怎么权衡，最后给一套换模型的验证顺序。

你在搭中文 RAG，向量库接好了、切分也调了，偏偏召回就是不准，问「退货政策」却给你召回「配送时效」，这时候多半是嵌入模型没选对。嵌入模型决定的是「语义距离」这把尺子准不准，尺子歪了，后面重排、提示词怎么调都补不回来。

这篇不讲榜单排到第几，只给按场景挑模型的判断标准和能落地的动作：先分清语料是短问句还是长文档，再看多语言、维度、显存和量化档位怎么权衡，最后给一套换模型的验证顺序。数字一类的东西，我都告诉你到站内哪个页面去看当时的实际值。

先按你的中文语料场景分三类

挑嵌入模型第一步不是打开模型列表，是先看清自己喂进去的是什么。同样是中文 RAG，客服 FAQ 和合同检索对模型的要求完全不同，一个吃口语改写，一个吃长文压缩。分错类，后面的对比全白做。

• 短问句检索（客服问答、FAQ 匹配）：用户问法和库里的标准问法通常不一样，重点看模型对中文口语、同义改写、错别字的鲁棒性，查询短、片段也短，模型轻一点没关系
• 长文档切块检索（合同、技术手册、政策文件）：片段长、术语密集、上下位概念多，重点看模型在长文本上的语义压缩能力，以及你的切片长度有没有超出模型能吃的范围
• 混合语料（中英夹杂、代码与技术文档）：多语言能力是关键，纯中文调优的模型遇到英文片段和技术名词往往掉得明显，这种语料不要只拿纯中文集去测
• 不适用情形：如果你的检索目标里专有名词、编号、型号占主导，向量召回本来就弱，别指望换嵌入模型解决，先考虑叠加关键词召回做混合检索

判断一个嵌入模型值不值得上，看这四件事

模型列表里能选的东西很多，但真正影响你能不能用的就四项：中文任务上的相对表现、向量维度、上下文长度、许可证。前两项决定效果和成本，后两项决定能不能落地。

中文语义任务表现

相对参考，别把名次当结论；到 /embeddings 看当前收录的模型口径与说明，只用来缩小候选范围

向量维度

维度高不等于效果好，但存储和检索开销是实打实涨的，先用你现有向量库支持得最好的维度，别为了追高把库撑爆

上下文长度

能不能一次装下你的切片长度，装不下就被截断，截断后的向量是失真的，召回自然会飘

许可证与商用边界

内部自用和对外交付产品要求不一样，到 /safety 看合规口径再定，别上线了才发现不能用

在 Ollama 上跑起来并做一轮对照

判断标准有了，接下来是动手。核心动作是：同一份切好的语料，两个候选模型各建一个集合，用同一组真实问题打分对比。最忌讳两个模型的向量混在同一个集合里，那结果没法解释。

1. 准备对照语料取你真实语料里切好的片段，尽量覆盖典型问法；别用官方示例文档，那类文本太干净，测不出差距
2. 分别建两个向量集合两个候选模型各写一个集合，命名带模型标识；这样做的好处是迁移、回退都不互相干扰
3. 准备一小组真实问题十来条就够，要包括用户的原话问法，不要改写成书面语；每条标好正确的目标片段
4. 逐条记录命中位置看正确片段有没有出现在返回的前几条里，记录排第几；比整体感觉靠谱得多，也能看出是语义问题还是检索参数问题
5. 观察资源占用嵌入模型通常比对话模型轻得多，但批量和长文本会明显吃显存；机器够不够跑，到 /models/deploy 按模型和量化方式先算一遍再决定要不要上大维度

如果你的切片本身就切得乱、标题和正文混在一起、表格被截成半行，那换模型带来的提升会被噪声盖住。这种时候先把切分和清洗做完再比，不然你测的是切分质量，不是模型质量。

换模型前后的迁移与验证清单

选好模型只是开始，真正容易出事的是切换那一下。换嵌入模型等于换了整个向量空间，新旧向量不在一个空间里，相似度算出来完全没意义，这点比选型本身更容易踩。

• 换嵌入模型必须整库重建，旧向量不能复用，也不能新旧混用，这是最常见的踩坑点
• 重建后回放同一组问题，逐条记录命中位置，只看整体感觉容易误判成「差不多」
• 上线前留一份旧索引和旧回答做回退路径，出现召回质量下滑能快速切回去
• 把这次选型的判断依据和验证方式写进文档，下次换模型按同一套流程走，不用重新摸索
• 如果语料还在持续增长，顺手记一下重建一次索引大概要多久，这关系到你以后敢不敢换模型

嵌入模型选型的本质，是拿你自己的中文语料量一把尺子，而不是抄别人的排名。