ollama 嵌入模型推荐

用 Ollama 搭 RAG，最容易卡在选嵌入模型这一步：库里能拉的名字一大堆，体积、维度、语种、量化档位各不相同，随手挑一个跑起来，检索效果差还不知道差在哪。这篇不讲空概念，直接给一套按语种、维度、显存和量化档位筛选的动作顺序，以及拉下来之后怎么自测、怎么换、怎么回退。

用 Ollama 搭 RAG，最容易卡在选嵌入模型这一步：库里能拉的名字一大堆，体积、维度、语种、量化档位各不相同，随手挑一个跑起来，检索效果差还不知道差在哪。这篇不讲空概念，直接给一套按语种、维度、显存和量化档位筛选的动作顺序，以及拉下来之后怎么自测、怎么换、怎么回退。

先说一个前提：嵌入模型没有「通用最好」这一说，只有「跟你这份语料和这台机器合不合」。所以下面所有判断标准都是相对的，凡是涉及具体数字（体积、维度、成绩）的，本文一律不写死，请到站内对应页面核对当时的数值。判断方法本身是稳定的，数字是变动的。

先定四个筛选维度，别一上来就翻列表

打开 Ollama 的模型列表直接从头拉到尾，是最容易浪费半天的做法。正确顺序是先把自己的需求变成四个约束条件，再用它们去过滤列表。这四个维度是：语种覆盖、向量维度与模型体积、单段输入长度上限、要不要配重排。前三个是硬约束，第四个是效果调优项。

语种覆盖

中文知识库优先选中文或多语训练过的模型；纯英文模型拿来检索中文文档，召回会明显掉，双语混排文档里这个坑更明显

向量维度与体积

维度高不等于效果好，但存储和检索开销一定更高；小团队文档量不大时，低维模型往往更划算

上下文长度限制

嵌入模型对单段输入有上限，长文档要先切块，切块粒度按模型上限反推，而不是先切完再硬塞

要不要配重排

只靠向量召回时前几条混进无关内容是常态，是否叠加重排模型取决于你对首条命中率的要求

这里特别说一句「什么情况下不适用」：如果你的语料是纯英文技术文档、且团队对检索精度要求不高，那多语模型带来的额外体积可能并不划算，直接用英文向的轻量模型反而更省资源。反过来，只要文档里夹杂中文，就别指望纯英文模型能兜住。

按场景拉短名单，别按名气

短名单的正确拉法是从场景出发，而不是从别人推荐出发。同样一个模型，在你同事的英文问答场景里表现不错，搬到你的中文合同检索里可能完全不行。下面按四类常见场景给筛选方向，具体候选型号到站内 /embeddings 的资料入口对照当时的版本与参数。

• 先把业务语种列成一张清单，逐项标注文档占比，占比低的语种可以不进短名单
• 把文档量级估出来（大概多少段、多少条向量），据此判断能否接受高维模型
• 确认单机可用显存，把对话模型和嵌入模型放在一起算总量
• 短名单控制在三到四个，太多测不完，测不完就等于没测

显存这块别自己拍脑袋，按模型规模和并发量做测算更稳，站内 /compute/sizing 有对应的测算思路可以套。短名单定完再动手拉，比边拉边试省事得多。

拉下来怎么验：三步自测法

模型拉下来不代表选对了。嵌入模型的评测必须用你自己的语料，公开榜单只能帮你排除明显不合适的选项，不能替你下结论。下面三步是能直接照做的验证流程，建议每个候选模型都跑一遍。

1. 建小测试集从真实文档里挑二十到五十条问答对，问题和答案都必须来自你的业务语料，不要用公开数据集代替；每条的正确答案在原文里的位置也要记下来，方便判断召回是否命中
2. 固定变量对比同一个切块大小、同一个 top-k、同一批查询问句，只换嵌入模型；记录首条命中和前三条命中情况，两个模型之间至少留一份对照记录
3. 存旧索引再换换模型前把旧索引快照留好；嵌入模型一换，向量库基本要全量重建，重建耗时和存储成本提前算进去，回退方案就是恢复旧快照

验证通过再上生产。只测三五个问题就下结论，很容易被个例带偏——尤其是那种恰好命中的样例，会让你高估模型。如果三四个候选跑完差异不大，就选体积更小、灌库更快的那一个，把余量留给后面的重排环节。

嵌入模型换得快，索引重建就慢；把回退方案先想好，比把模型选到最优更重要。

量化档位和体积怎么取舍

量化能省显存和存储，但嵌入模型对量化的敏感度和对话模型不完全一样：检索任务的容错通常更低，几维的偏差可能就让正确段落掉出前三。所以量化的正确做法是「先基线、后压缩、再复测」，而不是直接上最省的档位。

• 先跑未量化版本作为基线，把首条命中和前三条命中记下来
• 再试量化版本，用同一套测试集对比，命中率掉得厉害就别用这一档
• 如果量化后掉得厉害，优先降维度或换更小的模型，而不是继续压量化档位
• 灌库阶段和在线查询阶段负载差别大，灌库可以慢，查询不能慢，必要时把嵌入服务和生成服务分到不同机器

还有一点容易忽略：嵌入式部署的显存要和对话模型一起算总量，别只算一个。具体到某台机器能跑什么档位，到站内 /compute/sizing 按你的实际配置核对当时的测算结果，比凭感觉稳。

几个反复踩的坑

最后收几个高频错误。这些坑的共同点是：出问题时现象很怪（检索结果莫名其妙），但根因往往在选型或流程上，不在代码里。提前避开比事后排查便宜得多。

另外提醒一句适用边界：上面这套流程是为「单机自建、语料规模中等」的团队写的。如果你的向量量级已经到了需要专门向量数据库和分布式灌库的程度，选型逻辑要加上运维成本这一项，不能只看单机跑分。