ollama text embedding模型推荐

多半人卡在这一步：知识库切好片了，问一句答非所问，回头查发现是嵌入模型没选对。Ollama 拉模型一条命令的事，但向量模型和对话模型挑法完全不一样——它不进对话，只负责把文本压成向量。这篇按「场景→语言→显存与速度→许可证」的顺序走一遍，帮你两小时内定下用哪个，而不是把榜上靠前的挨个下载试。

多半人卡在这一步：知识库切好片了，问一句答非所问，回头查发现是嵌入模型没选对。Ollama 拉模型一条命令的事，但向量模型和对话模型挑法完全不一样——它不进对话，只负责把文本压成向量。这篇按「场景→语言→显存与速度→许可证」的顺序走一遍，帮你两小时内定下用哪个，而不是把榜上靠前的挨个下载试。

选型顺序建议记死：先定语言和场景，再看 Ollama 上跑不跑得动、查询快不快，最后才比效果数字。反过来做——先看榜、再下载、最后发现中文召回一般或者机器带不动——是最常见的返工路径。

先搞清楚向量模型在 RAG 里干什么活

嵌入模型只负责把 chunk 和 query 映射到同一向量空间，不生成文字。所以别拿对话模型的强弱去推它，一个对话很能聊的模型，做检索未必比小模型强。判断标准很简单：输入一段文本，看它输出的向量在语义近的句子上距离是不是真的更近——这是它唯一的职责。

• 召回差有三种表现：答非所问、只召回半句、多语言串味，先分清是切片问题还是模型问题，再换模型；
• 维度不是越高越好，高维吃存储和检索延迟，单机小知识库常见做法是够用就行，具体维度去 /models 看模型卡当时的标注；
• 同一套知识库换模型等于全量重算向量，选型阶段多花半天，比上线后重建划得来；
• 如果你的召回问题出现在「回答里明明有这个词却搜不到」，八成不是嵌入模型的事，先看切片。

按语言和任务匹配，别按榜单名次匹配

纯中文知识库优先挑中文语料训练充分的模型，中英混排的文档要专门测跨语言检索，别只看单语效果。判断方法：拿你自己的文档抽二三十条真实查询，中英各来几条，看能不能召回对应的 chunk。这一步花半小时，比看任何榜单都准。

代码、表格、编号条款这类结构化文本，通用模型经常拉不开距离，值不值得专门换一个，拿实际召回率说话。效果数字去看站内 /embeddings 相关对比页当时的口径，别用别处的跑分直接下结论——口径不同，结论可能反着来。

在 Ollama 上跑得动、跑得快才是前提

向量模型参数量普遍比对话模型小得多，普通消费卡甚至纯 CPU 都能跑，但批量灌库时吞吐差距会很明显。先想清楚两件事的优先级：灌库是一次性重活，检索是天天要做的事。查询侧延迟必须可接受，灌库慢一点大多数场景能忍。

• 显存不够时优先换更小的模型或降低批量，而不是硬上量化，嵌入模型量化后的相似度漂移比对话模型更难察觉；
• 灌库阶段用你能接受的最长等待时间反推批量大小，别一次把显存打满；
• 查询侧延迟拿自己的真实 query 测，不要用「一篇文章」这种超长输入测延迟，那不代表线上；
• 拿不准自己的机器能跑多大，用 /models/deploy 的测算口径先估一遍再下载。

许可证和迁移成本，选型时一起算

权重开源不等于随便商用，许可证类型不同限制不同，交付给客户的项目尤其要先确认。术语口径对照 /ai-dict/category/safety 的术语页理解，别靠自己猜。这一条在个人项目里可以放一放，到了要交付、要部署到客户那边的阶段，它比效果更早成为卡点。

1. 确认许可证查模型卡的许可证类型，对照站内术语页确认能否用于你的交付场景，拿不准就问一次。
2. 架构上留退路切片规则、向量维度、元数据字段都要能平滑迁移，换模型时只重算向量，不动上层逻辑。
3. 迁移前后对照新旧模型各跑一遍同一批 query，看 Top-K 结果重合度，重合高说明现有切片已经被榨干，换模型收益有限。

向量库这一层怎么选去看 /stacks/vector-dbs，别在嵌入模型上纠结太久——很多时候召回问题根本不是模型决定的。

效果不够时，先加东西还是先换模型

召回不准先排查切片长度和重叠，很多问题是切出来的 chunk 语义不完整，换模型也救不回来。判断顺序建议：先看切片，再看检索方式，再看重排，最后才换嵌入模型。越靠前的改动成本越低、收益往往越大。

• 重排模型能明显改善排序，但它解决的是「召回了但排后面」，召回本身没有的东西它变不出来；
• 混合检索（关键词 + 向量）在专有名词、型号、编号多的场景通常比单换嵌入模型有效；
• 真到了换模型那一步，按「同一批 query 跑对照 → 抽样人工看前若干条 → 全量重建 → 灰度切流」的顺序来，别一把梭；
• 换完记得清理旧向量，维度不一致导致的报错经常来自没清干净的残留集合。

把嵌入模型当成检索流水线上的一颗螺丝，先确认哪个环节松了，再决定换哪一颗。