Dify 知识库的 embedding 模型怎么选：中文场景下这一步比换主模型有用

知识库答不准，第一反应通常是「换个更强的模型试试」。

但这里有个常见的误会：你换的那个「更强的模型」，多半是负责生成回答的对话模型，而检索准不准，跟它几乎没关系。

决定「能不能找到正确资料」的，是 embedding 模型（嵌入模型）。

它到底在干什么

一句话：embedding 模型负责判断两段文字的意思像不像。

知识库的工作原理大致是这样：

1. 文档被切成一段一段，每段用 embedding 模型转成一串数字（向量）
2. 用户提问时，问题也被转成同样形式的向量
3. 系统找出和问题向量最接近的那些文档向量
4. 把找到的文档片段交给对话模型，让它组织答案

第 3 步的准确性完全由 embedding 模型决定。 如果它认为「怎么请年假」和「休假申请流程」不像，那正确的文档根本进不了第 4 步——这时候对话模型再强也没用，它手里的材料就是错的。

判断问题是不是出在这一步

有个很好用的自测方法：用文档里的原话去问，和用自己的话去问，结果一样吗？

• 原话能查到，换个说法查不到 → 典型的 embedding 问题。模型没建立起这两种说法的关联。
• 两种都查不到 → 先看文档解析和切块，问题可能在更前面。
• 两种都能查到，但答案不对 → 检索没问题，问题在生成环节或者材料本身。

大部分「知识库不好用」的抱怨，落到第一种。

中文场景的三个具体问题

一、专业术语和行业黑话

通用 embedding 模型是在通用语料上训练的，它不理解你行业里的特定说法。

在你看来「工单」和「报修单」是一回事，在模型看来可能是两个不相干的词。这在专业领域特别明显——制造业、医疗、法律、政务，每个行业都有一套外人看不懂的表达。

最省事的解法不是换模型，是改文档：直接把行业黑话和通用说法写在一起。「工单（也叫报修单、维修申请）」，一句话解决，比调模型见效快得多。

二、中英混杂

技术文档里常见「配置 API Key」「重启 Docker 服务」这种中英混排。有些 embedding 模型对这类混合文本的处理不理想，会丢失一部分语义。

如果你的文档大量中英混杂，选模型时要特意测一下这类查询。

三、短查询

用户实际提问往往很短——「年假几天」四个字。短文本携带的信息少，向量表示不稳定，检索容易漂。

应对办法：在文档侧下功夫，把可能的短问法直接写进文档；或者在检索前做查询扩写，把短问题补充完整再去检索。

选型时看什么

第一，中文语料是否充分。 中文场景优先选中文语料训练充分的模型，这是最基本的一条。

第二，能不能本地部署。 如果你的数据不能出网，那 embedding 模型也必须能本地跑——这一点经常被漏掉。很多人只想到对话模型要本地部署，忘了文档在建索引时也要经过 embedding 模型，那同样是数据出网。

第三，向量维度带来的成本。 维度越高通常表达能力越强，但存储和检索的开销也越大。文档量大的时候这笔账要算。

第四，实测比参数表可靠。 各种排行榜是通用场景的平均表现，跟你的文档、你的用户提问方式不一定对得上。用自己的真实数据测，方法在下一节。

怎么测

不要凭感觉，做一个小测试集：

1. 收集 20-30 个真实问题。要真实的——让业务同事写下他们平时怎么问，而不是你想象中他们会怎么问。这两者差别很大。
2. 人工标出每个问题的正确答案在哪个文档片段。
3. 换模型跑一遍，看正确片段有没有被检索出来、排在第几位。

这个测试集的价值远超一次性使用：换模型要用它、调切块要用它、做项目验收也能用它。做一次，用很久。

换模型的代价：必须重建索引

这是最容易被忽略的一条，也是很多人换到一半放弃的原因。

换了 embedding 模型，之前建好的所有向量全部作废，整个知识库要重新建索引。

因为不同模型产生的向量在不同的「空间」里，互相之间没有可比性。用新模型的问题向量去比对旧模型的文档向量，结果是随机的。

这意味着：

• 文档量大时，重建要花时间，也要花钱（如果用的是按量计费的在线 embedding 服务）
• 生产环境上换模型，要考虑重建期间的服务可用性
• 所以选型应该在项目早期做，别等知识库建了几万份文档才想起来要换

做项目时的建议：在方案阶段就用小样本测几个模型，定下来再大规模导入。这一步花半天，能省后面的大麻烦。

一个被低估的替代方案：混合检索

在纠结换哪个 embedding 模型之前，先看看有没有更省事的路。

embedding 检索有个结构性弱点：它认语义，不认字面。

你问「XX-2024 号文件的规定」，向量检索会给你一堆语义相近的文件——因为在它眼里，「XX-2024」和「XX-2023」几乎一模一样，都是「某个编号的文件」。编号、型号、人名、专有名词，这类精确匹配的需求它天生不擅长。

全文检索正好相反：认字面不认语义。你换个说法它就找不到，但你给出精确的编号它一定能命中。

两者结合通常比换模型见效更快，而且不需要重建索引。如果你的文档里有大量编号、型号、专有名词——制度文件、产品手册、技术规范都是这样——那这一步的收益会很明显。

判断方法：把你的测试集分成两类，一类是自然语言提问，一类是含精确标识的提问。如果第二类的准确率明显更低，那问题不在 embedding 模型，混合检索才是解法。

优先级排序

如果检索效果不好，按这个顺序排查，别一上来就换模型：

1. 文档解析对不对 —— 扫描件、表格丢失结构，是常见的隐形杀手
2. 切块合不合理 —— 拿几个分段自己读，读不懂就是切错了
3. 换个说法测测 —— 判断是不是 embedding 的问题
4. 文档里补同义表述 —— 成本最低、见效最快的一步
5. 最后才是换 embedding 模型 —— 因为要重建索引，代价最大

完整的排查方法见 Dify 知识库检索不准怎么排查。

如果调到最后发现平台给的选项就是不够用——比如需要针对文档结构做深度定制的切块和检索策略——那可能已经到了平台边界，见低代码 Agent 平台的能力边界。这类活我们做，可以聊聊。