embedding和词向量区别

刚做检索增强的人常在这里卡住：文档里一会儿说词向量，一会儿说 embedding，看起来都是把文本变成一串数字，到底是不是一回事？这篇不绕术语史，直接给判断标准、对照表和在项目里落地要做的动作，帮你在选型、接入和排查时不再混着用。

刚做检索增强的人常在这里卡住：文档里一会儿说词向量，一会儿说 embedding，看起来都是把文本变成一串数字，到底是不是一回事？先给一个能立刻用上的判断：你的输入单位是「一个词」还是「一整句、一整段」？如果是后者，就别再按词向量的思路去理解它，直接按 embedding 的用法来对接。

这篇不绕术语史，直接给判断标准、对照表和在项目里落地要做的动作。术语怎么叫不影响你写代码，但把两者的接口形态、粒度和验证方式混着用，就会在选型、接入和排查上反复踩坑。

先分清：它们差在哪，不是差在名字

词向量是「一个词对一个固定向量」的早期思路，词表里每个词对应一行数字，同一个词在哪出现都是同一个向量。embedding 是「任意一段文本映射到一个向量」的通用说法，输入可以是一个词，也可以是一句话、一段话，粒度和来源都不同。差别不在名字，在编码单位。

• 关键差异看三点：编码单位是词还是句段、向量是否随上下文变化、能不能直接拿来做语义检索
• 一句话判断：输入是单个词，词向量的说法还站得住；输入是整句整段，就必须按 embedding 的用法来对待
• 不要因为某个模型内部学过词级表示，就以为你调用时也能拿到单词语义，多数接口只给你段级结果
• 同一个词在不同上下文里向量不同，这不是 bug，是句级编码的正常表现

落到代码里，字段和接口长什么样

检索链路上真正要对接的是 embedding 接口：输入一个文本数组，输出一个等长的向量数组，顺序一一对应。你在代码里要处理的是第几个输入对应第几个输出，而不是去查某张词表里某个词排在第几行。

# 接口形态示意（字段名以你接入的服务文档为准）
POST /v1/embeddings
{ "input": ["退款流程是什么", "怎么申请退货"] }
# 返回：data 数组，顺序与 input 一致，每项一个向量数组

别把「词向量表」当成接口返回格式：很多模型不暴露单词语义，你拿不到，也没必要拿。真正要在入库前固定的是三件事——向量维度、归一化方式、距离度量。三者不一致，就会出现「相似度看着对、排序全乱」的典型症状。

向量维度

同一批入库向量必须来自同一个模型的同一配置，换模型或换维度等于换了一套坐标系

归一化

决定你是用余弦还是点积，入库前统一处理，别一半归一化一半没归一化

距离度量

查询和入库要用同一种，混用会让排序失去意义

怎么验证你手上这套向量能不能用

1. 小样本对照拿 20 组你自己业务里的同义句和无关句，看同义句的相似度是否稳定高于无关句。同义句比不上无关句，先别急着换模型，先看分块是不是切碎了语义。
2. 重复调用查一致性同一段文本连续调用两次，比对向量是否一致。不一致说明接口、参数或缓存层有问题，这时候任何检索结论都不可信。
3. 看落库召回写入后拿一条已知答案的查询去召回，命中是不是你预期那条。召回不到，排查顺序是分块→维度→度量，最后才怀疑模型本身。
4. 换一批文本再跑一遍用另一类业务文本重复上面三步。只在一种文本上通过，说明不了这套向量通用。

什么情况下这套判断不适用

上面这套判断是为了句段级语义检索服务的，不是万能的。做纯词级任务，比如近义词表、词形聚类、拼写纠错，句级 embedding 反而不合适，粒度太粗，把语境揉进去之后词与词的细微关系反而被抹平。

• 强依赖精确关键词匹配的场景，比如订单号、代码符号、专有名词，单靠向量不如混合检索，向量负责语义、关键词负责精确命中
• 多语言或跨语种检索要单独验证，在一种语言上跑通的阈值换到另一种语言经常翻车
• 短查询对长短文档的匹配要单独看，长度差异会系统性影响相似度，不能直接套用同一阈值
• 合规敏感场景要确认向量存到哪、是否出网，这不是模型能力问题，是部署问题