在 WPS AI 的知识库里问一句「报销流程是什么」，它能翻出文档库深处的财务制度，哪怕那份文件里从头到尾没出现过「报销」两个字。背后起作用的，是嵌入模型——专门把文字变成一串数字坐标的小模型，意思越近的文本，坐标离得越近。
类比图书馆排架：管理员不会把讲「时间管理」的书分散放到各处，而是集中排在相邻书架，找起来一找一个准。嵌入模型做的就是这件事，只不过书架换成了高维数字空间，每段文字进去都领到一个坐标。
类比失效之处：图书馆的书架位置由管理员人工排定、常年不变，而嵌入坐标由模型从海量语料里学出来，不同模型学出的坐标系互不相通，同一句话在两个模型里的坐标毫无可比性。
它不说话，只报坐标
和聊天模型的分工差异在这里：你给它一段文字，它不回答问题、不写作文，只输出一串固定长度的数字（向量），这串数字编码了文本的语义，供程序计算距离用。所以一个 AI 产品里，聊天模型和嵌入模型常常是两个不同的模型，前者管表达，后者管定位。
可带走的判断：凡是「按意思搜索」「相似内容推荐」「自动归类」的功能，背后几乎都有一个嵌入模型在默默算坐标，哪怕界面上从没提过这个词。
语义检索为什么离不开它
传统搜索靠关键词匹配，你搜「报销」，它只找含这两个字的页面；嵌入模型让搜索按语义找，搜「报销」也能命中写着「费用申请」「差旅结算」的段落。秘塔AI搜索这类产品能理解口语化的提问，语义坐标是基础环节之一。
企业知识库的典型流程：文档先切成小段，逐段算出坐标存进索引；用户提问时，把问题也算成坐标，找出距离最近的一些段落，再交给聊天模型组织答案。嵌入模型在这一步决定「找得全不全」，找漏了，后面的模型写得再好也无济于事。找出来的段落还要再排一次座次，这道质检工序由谁负责，见站内重排序模型一文。
两种检索方式摆在一起，差别在匹配依据和失效处。
| 比较项 | 关键词检索 | 嵌入模型的语义检索 |
|---|---|---|
| 匹配依据 | 只找含这两个字的页面 | 把问题与段落都算成坐标，比谁离得近 |
| 能命中什么 | 字面出现关键词的页面 | 意思相近的段落，搜「报销」也能命中「费用申请」「差旅结算」 |
| 失效之处 | 换个说法就搜不到 | 坐标系不通用，换模型必须全库重算重建 |
换模型时，坐标系要整体重排
使用者最容易踩的坑：不同嵌入模型的坐标系不通用，把用 A 模型算好的向量换成 B 模型来检索，结果会完全乱掉。所以知识库一旦更换嵌入模型，全库文档必须重新算坐标、重建索引，数据量大的话成本不低。
选型时看三处：模型说明里的向量维度、语言支持范围、评测成绩，都可以在模型仓库或 ModelScope 的详情页查到。维度本身没有优劣，与配套的检索工具匹配才要紧。
小模型、低成本，是它的生存方式
嵌入模型通常比聊天模型小得多，因为任务单纯：把文本压成向量，不需要生成流畅的文字。任务简单意味着模型可以小、速度快、成本低，一篇几千字的文档算坐标只需毫秒级。这也解释了为什么很多知识库在文档更新时敢做全量重算——算得起。
至于模型文件的存放形式，几十兆的 LoRA 小文件是怎么回事，见站内LoRA 模型文件一文；多模态场景下图片语音怎么折算进上下文，则是另一条线，见多模态 token一文。
嵌入模型自查清单
- 查语言：中文为主的库，优先看模型对中文的支持说明；
- 查维度：向量维度要与检索工具匹配，换模型就得重建索引；
- 查一致：文档库更新后，新段落必须用同一个模型算坐标；
- 记住一句：坐标体系不通用，混用两个模型的向量，检索结果必然错乱。
读者对嵌入模型的常见疑问
- 它和聊天模型是什么关系？：分工不同的两个角色，前者只把文本变成向量坐标，后者负责生成回答，知识库产品里通常两个都要。
- 向量维度越高效果越好吗？：不一定，维度高存储和计算成本也高，实际效果要看任务和配套工具，不能只盯这一个数字。
- 换了嵌入模型，旧索引还能用吗？：不能，不同模型的坐标系互不相通，必须全库重算重建，这也是选型初期就该慎重的理由。
