在 AI 知识库的搜索框里输入怎么退货,命中的是一篇标题写着申请退款流程的文档。两句话没有一个词相同,却对上了。原因是检索不按字面比,按向量比:先把文本压成一串数字,再算两串数字之间的距离。词嵌入就是这串数字的来源。
从文本到向量,中间有四步
先切分。文本被切成 token,中文可能按字也可能按词,英文按子词切,具体切法由词表大小决定。词表里没有的词会被拆成几段,生僻词和型号经常被切碎,原因就在这里。
再查表。每个 token 对应一个固定长度的向量,这张表是训练出来的参数,不是人工标注的。查出来的向量只表示这个词本身,还带不上上下文。
然后编码。把一串 token 向量送进 Transformer,自注意力让每个位置吸收周围信息。同样是苹果,在吃苹果和苹果发布会里得到的向量不同,多义问题在这一步被拆开。向量维度和模型规模并不直接挂钩,参数量大的模型不一定给更长的向量。
结尾是池化。一句话要变成一个向量,常见做法是取特殊标记位的输出,或对所有 token 取平均。出去的是一个定长数组,768 维或 1024 维都常见,具体随模型而定。
每一步的输入与输出
| 环节 | 进来什么 | 发生什么 | 出去什么 |
|---|---|---|---|
| 切分 | 原始字符串 | 按词表规则拆成子词或字 | 一串 token 编号 |
| 查表 | token 编号 | 按行取嵌入矩阵中的向量 | 每个 token 一个向量,无语境 |
| 编码 | 一串向量 | 自注意力混合上下文信息 | 带语境的向量序列 |
| 池化 | 向量序列 | 取特殊位或求平均 | 一个定长句向量 |
| 比对 | 两个句向量 | 算余弦相似度或欧氏距离 | 一个 0 到 1 之间的分数 |
这张表可以从下往上读。检索出问题时,顺着环节往回找,比笼统地说模型不准有用。
距离为什么能代表意思
依据是分布假设:一个词的意思由它常出现的上下文决定。常和退款、订单、物流一起出现的词,向量会被拉到相近的位置。训练时模型做的就是这个,用上下文预测中心词,或用中心词预测上下文。
距离常用余弦相似度,看两个向量的夹角,不看长度。夹角小说明方向一致,语义相近。文本检索普遍用余弦,因为向量长度容易受文本长短影响,夹角更稳。
关键推论在这里:所谓理解同义,本质是把换个说法变成坐标接近。机器因此能处理字面不同、意思相同的情况,语义搜索、推荐系统、后来的检索增强生成都建立在这个转换上。
国王与王后:那个例子能说明什么
经典演示是 king 减 man 加 woman,结果最接近 queen。它说明性别这一维度在向量空间里近似线性,可以做加减。
但它证明不了模型懂性别这个概念。这只是统计规律在空间里的投影,换语料、换语言,结果会变,偏门词上的类比错误率很高。
合适的用法是把它当成语义关系可以被数值近似的证据,别当成模型会推理的证据。这个区别在做模型评估时很关键,前者支持相似度检索,后者支持不了多步推断。
一词多义是怎么被处理的
早期方法给每个词一个固定向量,苹果是水果还是公司,只能平均成一个中间态。这类静态向量今天主要用于快速召回和轻量场景,成本低,精度有限。
上下文向量解决了这个问题:同一个词在不同句子里得到不同向量。代价是每段文本都要过一遍模型,计算量比查表大得多。
今天做检索用的是后者。整段文本编码成一个向量存起来,查询时再编码问题,两边在同一空间里比距离。索引结构负责在百万级向量里快速找到近邻,不需要逐个比较。
它在检索系统里的位置
离线阶段:文档切块,每块编码成向量,写进向量库并建索引。在线阶段:问题编码成向量,做近似最近邻检索,取回前几块,重排后塞进提示词。整条链路里,嵌入负责把意思变成坐标,索引负责找得快。
召回不准时,排查顺序是切块、嵌入模型、相似度算法。多数问题出在切块:一块里混了两个主题,向量就成了两者的平均,谁都匹配不上。部署成本也要算,嵌入模型同样可以量化后运行,换来更低的显存占用。
混合检索很常见:关键词匹配加向量检索。型号、编号、专有名词靠关键词,换个说法靠向量,两边互补。只用一种,总有一类查询会掉。
它做不到什么
相近不等于相关。退货和退款很近,但退货政策和退款到账时间是两件事。向量只说明语义接近,不等于回答了你的问题。
否定词弱。支持退货和不支持退货的向量距离可能很近,一个否定词改变的是意思,不是话题。这类查询要靠关键词或重排补。
精确匹配弱。型号、日期、金额,向量检索经常不如关键词,这类字段应该单独建索引。长文本还会被稀释,整篇压成一个向量,细节留不下多少,这也是要切块的原因。
偏见会进来。语料里的统计偏差会体现在距离上,某些职业与性别的关联更近就是典型表现。检索结果需要人看一眼,不能直接当结论用。
词嵌入速查
- 四步链路:切分、查表、编码、池化
- 距离看夹角,余弦比欧氏更常用于文本
- 静态向量一词一向量,上下文向量一句一向量
- 召回不准先查切块,再查模型
- 型号、金额、编号配关键词检索,别只靠向量
三个关于嵌入的疑问
- 维度越高越好吗?:不是。维度高能装更多区分信息,但存储和计算成本上升,数据量小时还容易过拟合。选型看评测集上的召回率,不看维度数字。
- 同一个模型,两次检索结果为什么不一样?:嵌入本身是确定性的。先查切块有没有改、索引有没有更新、有没有加重排,漂移多半在数据侧。
- 生成模型能不能直接做嵌入?:部分模型提供嵌入接口,可以用。但要按同一套评测集比较,别因为出自同一个模型就默认效果一致。
再往下走一步,就是部署方式的选择:用云端接口还是自己跑一个开源权重模型,取决于数据能不能出内网、查询量有多大。理解嵌入的机制之后,很多参数选择就不再靠猜,你知道自己在为哪一步付成本。


