嵌入模型怎么选？中文场景要注意什么
数据截至 2026-07，各项目能力与模型参数以官方文档当前版本为准。
嵌入模型的选型，不该从”哪个模型排名高”开始，而该从”我的查询长什么样、文档长什么样”开始。同一个模型，用在客服问答上和用在合同条款检索上，效果差别会很明显；而中文语料的麻烦，多半不出在模型的语义能力上，出在简繁、中英混排、专有名词和最大长度截断这些很土的地方。
一个流传很广的误解是：嵌入模型选错了，检索就废了，所以要先把模型选对。实际做下来顺序常常是反的——分块方式没理顺、文档解析就是乱的，换再好的嵌入模型也救不回来。嵌入模型确实是一个重要旋钮，但它排在解析和分块之后。这篇假设你已经能把文档干净地切成块了，只谈”接下来这个把文本变成向量的模型该怎么挑”。
一、先分清对称检索和非对称检索
这是选型时第一个要想明白的问题，因为它决定了后面所有对比是否有意义。
非对称检索指的是：查询很短、很口语，文档很长、很正式。用户输入”年假能攒到明年吗”，要去匹配一整段人事制度条文。绝大多数知识库问答都属于这一类。
对称检索指的是：两边的形态差不多。比如做相似工单去重、找重复的商品标题、判断两段描述是不是一个意思，输入和被检索对象都是同一种长度和语气。
为什么要分？因为不少嵌入模型是按非对称场景训练的，它们要求你在编码时给查询和文档加不同的前缀指令——查询前面加一句类似”为这个问题检索相关段落”的提示，文档不加。这个细节在模型的官方说明里通常写得很清楚，但用的人经常整库都用同一种方式编码，等于把模型训练时的假设直接破坏掉。检索质量不好，回头怀疑是模型不行，其实是用法不对。
可操作的做法：在真正入库前，去看一遍你选中模型的官方使用说明，确认三件事——是否需要查询前缀、推荐的相似度度量是余弦还是内积、向量是否需要先做归一化。这三条不对齐，后面调什么都是白调。
二、中文场景里最容易翻车的四个地方
这四条不是理论问题，是实际跑起来会直接掉召回的地方。
第一，简繁混排。 内地企业的资料里出现港澳台文档、旧版合同、繁体扫描件是很常见的事。有些模型对简繁的语义对齐做得不错，有些则会把”員工”和”员工”编码到不那么近的位置。稳妥做法是在入库前统一做一次简繁归一化，查询侧也做同样处理——这是数据预处理层面能解决的事，不必指望模型全包。
第二，中英混排和专有名词。 中文技术文档、医疗资料、财务报表里满是英文缩写、型号、编号。“申请 VPN 权限”这种查询，真正的信息量集中在那三个英文字母上。纯向量检索对这类精确串是薄弱环节，模型越倾向语义泛化，越容易把”VPN”和”网络访问”混作一谈，把包含具体术语的那一段挤出候选。这一点靠换嵌入模型收益有限，更该做的是补上关键词检索这条腿，两路结果合并。具体做法在RAG 检索调优：嵌入、混合检索与重排的取舍里展开过。
第三，口语提问和书面语文档的落差。 用户会打”我这个能报销不”，文档写的是”差旅费用报销标准”。这就是典型的非对称场景，选模型时要优先看它在中文问答检索上的表现，而不是看它在语义相似度任务上的表现——这是两类不同的能力，榜单上也常常是两栏不同的分数。
第四，最大序列长度导致的静默截断。 每个嵌入模型都有最大输入长度上限，超出部分通常被直接截掉，而且多数库不会报错。中文按 token 切分的密度和英文不同，同样的字符数，中文占用的 token 数往往更多，于是”我按英文经验估的块大小”在中文语料上就悄悄超限了。结果是每个块只有前半段进了向量，后半段等于没索引。排查方法很简单：随机抽几十个块，用模型自带的分词器数一遍 token 数，看有没有贴着上限。
三、榜单只能当候选池，不能当结论
中文嵌入评测榜单是有价值的，但它的价值是帮你把上百个模型筛到五六个，而不是帮你选出第一名。原因有三点：
- 榜单任务和你的任务不是一回事。榜单混合了分类、聚类、重排、检索等多类任务，总分高的模型不一定在你关心的那一类检索上表现最好。看总分不如看检索那一栏。
- 榜单语料和你的语料不是一回事。公开评测集大多是新闻、百科、通用问答，你的语料可能是工单、图纸说明、内部制度，词汇分布差得远。
- 提交结果存在过拟合的可能。公开榜单长期存在针对评测集调优的动机，名次差距很小的时候，那点差距在你自己的数据上基本没有意义。
替代做法：自己攒一份小评估集。找业务同事要一批真实提问，人工标出每个问题应该命中哪几个块，然后对候选模型跑同一套检索，比较召回情况。这份评估集的价值远高于任何榜单，而且换模型、改分块、加重排的时候都能复用。评估怎么做体系化一点，可以参考用 RAGAS 评估 RAG 效果。
四、维度、长度、量化：三个直接影响成本的参数
选模型不只是选效果，还在选一条长期的成本曲线。
向量维度。 维度越高，存储和检索开销越大，索引占用的内存也越多。维度翻倍，向量库的内存占用基本也跟着翻倍。对于几万到几十万块的中小知识库，这点差别无所谓；到了百万级以上，维度就是笔实打实的账。有些模型支持在推理时截断维度（保留前若干维仍可用），这类特性能让你在效果和成本之间做调节，但是否支持要看模型自己的说明。
最大序列长度。 上一节说过它会造成静默截断。反过来，支持超长输入的模型也不是无脑加分——把一整篇长文压成一个向量，语义会被平均掉，检索时反而定位不到具体段落。长度上限的意义是给你的分块留余量，不是让你不分块。
量化与压缩。 向量库这一层通常提供标量量化、二值量化等手段，用少量精度损失换存储和速度。选模型时可以先不管，等规模上来再开；但要注意有些量化方式对某些模型的向量分布更敏感，开之前用评估集回归一遍。向量库这一侧怎么挑，向量数据库怎么选里有横向对比。
五、走 API 还是自己托管
这个选择的分界线不是技术，是数据能不能出内网。
走云服务的嵌入 API：省事，不用管显卡和推理服务，模型升级由厂商负责。代价是每次入库和每次查询都要把文本发出去——查询侧尤其要注意，用户的提问往往比文档更敏感。另外，如果打算用海外厂商的嵌入服务，得先确认准入前提：以各厂商官方公布的受支持地区为准，本文不提供也不背书任何第三方中转渠道。付款与订阅这一层的现实情况，国内怎么付费订阅海外 AI 工具里讲得更细，别等到系统上线才发现这条路走不通。
自己托管开源嵌入模型：数据不出内网，长期成本可控，但要自己扛住推理服务的运维——批量入库时的吞吐、查询时的延迟、显存占用、模型更新，都得有人管。
有个细节值得知道：开源 RAG 引擎在打包时会区别对待嵌入模型。以 RAGFlow 为例，它提供两种 Docker 镜像，一种是精简版、一种是完整版，两者的差别就在于是否内置嵌入模型，完整版的体积因此明显更大（第三方对比资料给出的量级是精简版约 2GB、完整版约 9GB，具体以项目官方文档当前版本为准）。这说明一件事：嵌入模型在自托管方案里是个有分量的组件，不是随手带上的附属品，磁盘、内存、启动时间都要算进去。相关部署细节见RAGFlow 部署实操。
检索性能方面，配套的向量库同样影响体感。第三方资料称 Qdrant 在百万级以上向量规模下可以做到 50 毫秒以内的检索（第三方口径，非官方指标，实际取决于硬件、索引参数和过滤条件）。这个数量级可以当参考，但不该当承诺——真实延迟必须在你自己的数据和机器上压测。
六、换模型的真实代价：整库重算
这是最容易被低估的一项。不同嵌入模型产出的向量之间没有可比性，哪怕维度一样也不能混着用。所以换模型意味着：把所有文档块重新编码一遍，重建索引，重新验证效果。
语料量小的时候这只是跑个脚本；到了几十万、上百万块，重算就是一次带成本和窗口期的工程动作。API 计费的按量再付一次，自托管的占着显卡跑好几个小时。
降低代价的几个做法：
- 把编码这一步做成可重放的离线任务。原始文本和分块结果单独存一份，别只存向量。想重算时能直接从原始数据重跑，不用回头再解析一遍 PDF。
- 用影子索引做灰度。新模型的向量写进一个新集合，线上仍读旧集合，用评估集在新集合上跑一轮，确认更好再切流量。
- 把模型名和版本写进索引的元数据。哪一批向量是哪个模型、哪个版本编码的，事后要能查得出来。混用两个模型的向量是很隐蔽的事故，查起来非常费劲。
- 别频繁换。除非评估集上有明确且稳定的提升，否则换模型的收益经常抵不过工程成本。
七、嵌入模型解决不了的事
说点局限，免得期待放错地方。
- 文档本身没写的，检索不出来。 语料缺失是内容问题，不是模型问题。
- 需要跨多篇文档做推理的问题，向量检索只能捞回相关片段，串不起因果和时序，这类需求要考虑图检索或者更结构化的方案。
- 解析阶段就丢了的信息，后面全白搭。 表格被拍平成一行、扫描件没做识别、页眉页脚混进正文，这些在RAG 解析瓶颈里是单独一类问题，换嵌入模型完全无济于事。
- 精确匹配类查询，前面说过，靠关键词检索补，别指望嵌入。
- 排序质量，嵌入负责把正确答案捞进候选，把它顶到第一位是重排模型的活儿。
八、一个可执行的选型顺序
按下面的顺序走，比对着榜单纠结要快得多：
- 先确认自己是对称检索还是非对称检索，据此圈定模型类型。
- 攒一份小评估集：真实提问加人工标注的正确块，量不用大，但必须是真实业务语料。
- 从中文评测榜单的检索那一栏里挑三到五个候选，注意看它们的最大序列长度和维度是否符合你的规模。
- 逐个读官方说明，确认前缀指令、相似度度量、归一化要求，按各自的正确用法编码。
- 在评估集上跑一轮，比召回，不比感觉。
- 效果接近时，选部署更省事、长期成本更低的那个。
- 定下来之后，把精力转回分块、混合检索和重排——那里的提升空间通常更大。
如果你还在纠结整套框架该用哪个，选型逻辑是一样的：按瓶颈选而不是按名气选，具体展开在RAG 框架怎么选。
小结
嵌入模型的选型，先分清对称还是非对称检索，这一步决定了后面所有对比的前提。中文场景的坑集中在简繁混排、中英专有名词、口语与书面语的落差，以及最大长度导致的静默截断，其中两条靠数据预处理和分块就能缓解，不必全押在模型上。榜单适合筛候选，不适合下结论，自建一份小评估集的价值远高于名次。维度、序列长度、量化决定长期成本曲线，规模上来之前差别不大，上来之后就是硬账。最后记住换模型要整库重算，把编码做成可重放的离线任务、用影子索引灰度，能把这笔代价压到可控范围。