Back to Index
基础概念 /

Embedding 原理

从文本到向量：Embedding 如何将语义编码成数字，以及 Cosine Similarity、主流模型与实战应用

16 min read Part of AI Foundation · Ch. 7

Embedding 原理

flowchart LR
  A["Embedding 原理"]
  A --> B["分类：基础概念"]
  A --> C["关键词：AI"]
  A --> D["关键词：Embedding"]
  A --> E["关键词：向量"]
  A --> F["关键词：语义搜索"]

把文字、图片、代码，甚至用户、商品、文档这些对象，变成一串可以计算的数字，让“意思相近”的东西在数学空间里靠得更近——这就是 Embedding 在做的事。

这篇文章会讲什么

RAG、语义搜索、推荐系统、聚类、去重、召回排序……这些 AI 应用背后，往往都离不开同一个基础能力：Embedding。

很多人第一次接触 Embedding 时，会觉得它很抽象：

  • 文本为什么能变成向量？
  • 向量为什么能表示“意思”？
  • 为什么两段说法完全不同的句子，也能被判断为相似？
  • 为什么 RAG 不是做关键词搜索，而是先做 Embedding 再检索？
  • 为什么同样是 Embedding 模型，有的更适合中文，有的更适合长文，有的更适合多语言？

这些问题如果不搞清楚，后面做 RAG、向量数据库、检索优化时就会一直停留在“会调参数，但不知道为什么”的状态。

本文不讲复杂数学公式，只讲概念、直觉和实战含义。读完你应该能理解：

  • Embedding 到底是什么
  • 它为什么能把“语义”变成可计算的向量
  • 主流训练方式是怎么让“相似内容靠近”的
  • Cosine Similarity 为什么几乎成了默认选择
  • 2026 年常见 Embedding 模型该怎么选
  • 在语义搜索、聚类、分类和 RAG 里它到底怎么工作

想深入？

先说结论：Embedding 不是“理解文本”，而是“把语义关系几何化”

很多入门文章会说：

Embedding 就是把文本变成向量。

这句话没错，但还不够抓住本质。

更准确的说法是：

Embedding 是把原本离散、不可直接计算相似度的对象，映射到一个连续空间里，使“相关性”能用距离或方向来近似表示。

这意味着，Embedding 的价值不在于“数字化”本身，而在于：

  • 原来两个句子只能靠人读来判断相似
  • 有了 Embedding 以后，它们可以在向量空间里比较远近
  • 这样就能支持搜索、聚类、推荐、匹配、分类等一系列任务

从工程角度看，Embedding 做的事情其实很务实：

它把“语义相近”这件事，转换成了“数学上靠近”。

1. 什么是 Embedding

先看定义：Embedding 是把离散符号映射成连续稠密向量，使得语义相近的内容在向量空间中更接近。

从离散符号到连续向量

计算机天然擅长的是数字运算，不擅长直接处理“意思”。

例如，“猫”和“狗”在人类看来显然比“猫”和“汽车”更接近。
但如果你只是给它们编号：

  • 猫 = 17
  • 狗 = 42
  • 汽车 = 105

那这些数字之间并没有语义意义。
17 不会因为“猫和狗都属于动物”就自然更接近 42。

早期 NLP 里常见的一种表示方法是 one-hot 编码。
比如一个词表里有 10000 个词，每个词都对应一个长度为 10000 的向量，只有一个位置是 1，其余全是 0。

这种表示的最大问题是：

  • 维度极高
  • 非常稀疏
  • 任何两个不同词之间的距离都差不多
  • 完全无法表达“猫”和“狗更像”

Embedding 的出现，解决的就是这个问题。

它把一个词、一个句子、一个段落，映射成一个固定维度的稠密向量，例如：

  • 384 维
  • 768 维
  • 1024 维
  • 1536 维
  • 3072 维

这些维度上的实数本身通常没有可直接解释的人类含义，但整体位置和方向却能编码语义关系。

为什么 Embedding 有用

因为一旦你把文本放进了同一个向量空间，就可以用数学方式做很多原本很难做的事：

  • 比较两段文本是否相似
  • 找出和用户问题最相关的文档
  • 把相似反馈自动聚到一类
  • 判断一段文本更像哪个标签
  • 为推荐系统找到“相似商品”或“相似用户”

所以 Embedding 的核心价值不是“表示”，而是：

表示之后，你终于可以做检索、比较、聚类和匹配。

能被 Embedding 的不只是文字

虽然本文重点讲文本 Embedding，但 Embedding 的思想并不局限于文本。

输入类型典型模型常见维度范围
文本（词 / 句 / 段）OpenAI text-embedding-3, BGE, Jina384–3072
图像CLIP, DINOv2512–1024
图文多模态CLIP, Cohere Embed 4256–1536
代码CodeBERT, 各类代码检索模型768–1024
用户 / 商品 / 广告 ID推荐系统自训练 embedding低维到中维不等

不同对象都能做 Embedding，本质原因是一样的：

只要你希望“相似对象彼此靠近”，就可以考虑把它们映射到一个向量空间里。

2. 语义空间（Semantic Space）：为什么“意思近”会变成“距离近”

先看定义：Embedding 的目标，是构造一个语义空间，让表达相近含义的内容，在这个空间里彼此更靠近。

什么叫“语义空间”

所谓语义空间，其实就是 Embedding 向量所在的高维空间。

如果一个模型训练得足够好，那么在这个空间里：

  • “中国的首都是北京”
  • “北京是中国首都”
  • “首都在中国是北京”

这些句子的向量应该彼此很近。

而像：

  • “今天下雨了”
  • “这段代码报错”
  • “咖啡口感偏酸”

这些语义完全不同的内容，就应该离得更远。

这就是“语义空间”的直觉含义：

空间里的几何关系，尽量对应内容之间的语义关系。

为什么不是完全一样的句子才靠近

Embedding 之所以强大，就在于它不是做字符串匹配。

它不要求两个句子：

  • 用同样的词
  • 用同样的顺序
  • 甚至用同一种语言

只要它们表达的含义足够接近，就有机会在向量空间中彼此靠近。

这也是为什么语义搜索和关键词搜索本质不同：

关键词搜索关心：

你有没有用到同一个词。

语义搜索关心：

你是不是在说同一件事。

例如用户问：

“怎么改密码？”

知识库里写的是：

“密码重置流程如下”

关键词搜索可能效果一般，因为“改密码”和“密码重置”不是同一个短语。
但好的 Embedding 模型往往能把它们映射到相近区域，所以语义搜索能召回。

一个直观类比：给语言世界画地图

可以把 Embedding 想成一种“自动画地图”的方法。

在这张地图上：

  • 法律文本会聚成一片区域
  • 编程问题会聚成一片区域
  • 客服 FAQ 会聚成一片区域
  • 财务术语会聚成一片区域
  • 关于“退货”的文本会更靠近“售后”
  • 关于“部署报错”的文本会更靠近“日志”和“配置”

这张地图不是靠人手工定义出来的，而是模型在大量训练数据上学出来的。

所以 Embedding 真正神奇的地方，不在于“输出一串数字”，而在于：

它自动学会了怎样把世界中的语义关系，摊平到一个可以计算的空间里。

3. Embedding 模型如何训练

先看定义：Embedding 模型的训练目标通常不是“生成文本”，而是“让相关样本靠近、不相关样本远离”。

和生成模型最大的区别

大语言模型通常在做 next-token prediction，也就是：

给定前文，预测下一个 token。

而 Embedding 模型更常见的目标是：

给定两个对象，判断它们该不该在空间里彼此接近。

这两个目标非常不同。

生成模型关心“接下来写什么”。
Embedding 模型关心“这两个东西像不像”。

所以尽管两者都可能基于 Transformer，训练重点却不一样。

主要训练范式

范式代表思路核心目标
Contrastive LearningSimCLR、双塔检索模型、现代 embedding 训练正样本拉近，负样本推远
BERT-style 预训练 + 微调BERT、RoBERTa 再做句向量任务先学表示，再针对相似度任务调优
Sentence TransformersSBERT、各类句向量模型优化句子级相似度、检索、匹配能力

Contrastive Learning：最核心的直觉

现代 Embedding 训练里，最重要的一类思想就是 对比学习（Contrastive Learning）。

它的训练数据往往长这样：

  • 正样本对：意思相近
  • 负样本对：意思不相近

例如：

正样本对

  • “中国首都是北京”
  • “北京是中国的首都”

负样本对

  • “中国首都是北京”
  • “我今天吃了面条”

训练时，模型被要求：

  • 把正样本向量拉近
  • 把负样本向量推远

经过大量这样的学习，它就逐渐掌握了“什么叫相近”。

所以从直觉上说，Embedding 模型不是在背语法，而是在学：

哪些东西应该被放在一起，哪些东西应该被分开。

正负样本从哪里来

这是很多人容易忽略的一点。

Embedding 好不好，很大程度上取决于训练时你拿什么当“相似”。

常见的数据来源包括：

  • query-document 对
  • 问题-答案对
  • 同义句 / 改写对
  • 自然语言推理（NLI）数据
  • 点击日志和用户行为
  • 检索任务中的 hard negatives

尤其在检索任务里，hard negatives（难负样本） 很关键。
因为真正难的不是把“北京首都”和“今天吃饭”分开，而是把：

  • “密码重置”
  • “账号找回”
  • “修改绑定邮箱”
  • “登录失败处理”

这些看起来都挺相关，但并不完全等价的内容区分清楚。

为什么 Sentence Transformers 很流行

原始 BERT 更擅长 token 级表示和分类任务。
如果你直接拿它的 [CLS] 向量做句相似度，效果通常并不理想。

Sentence Transformers 的思路是：

  1. 先用 BERT / RoBERTa 一类模型做编码器
  2. 再用句子级任务进行对比学习或匹配微调
  3. 最终得到更适合句向量、段落向量和检索任务的表示

这类模型之所以流行，是因为它们很好地解决了一个现实问题：

我们不是想得到“每个 token 的表示”，而是想得到“整个句子的表示”。

这也是为什么今天大多数开源文本 Embedding 模型，都能在 Sentence Transformers 这一脉的思想里找到影子。

4. Query Embedding 和 Document Embedding：为什么检索不是“一种向量打天下”

先看定义：在检索场景里，问题和文档并不总是同一种分布，所以很多系统会分别优化 query 和 document 的表示。

用户问题和文档内容，往往不是同一种语言

看一个最简单的例子：

用户会问：

“怎么改密码？”

文档可能写：

“账户密码重置流程如下”

它们表达的是同一个需求，但形式很不一样：

  • query 通常更短
  • 更口语
  • 信息更不完整
  • 更像意图

而 document 通常：

  • 更完整
  • 更书面
  • 信息密度更高
  • 更像知识材料

所以很多检索系统不会简单假设：

query 和 document 完全是同一分布。

而是会用更适合检索的训练方式，让“问题向量”和“文档向量”在空间中对齐。

为什么这件事很重要

因为在 RAG 里，你真正关心的不是：

两段文本表面是否相似

而是：

用户问题和哪段知识最匹配

这类任务通常叫 query-document retrieval，它和“句子相似度”很像，但不完全相同。

所以一个 Embedding 模型可能：

  • 在 STS（语义相似度）任务上很好
  • 但在真实检索任务上不一定最优

这也是为什么看排行榜时，不能只看总分，而要看它具体擅长：

  • 检索
  • 分类
  • 聚类
  • reranking
  • 多语言
  • 长文
  • 代码

5. Cosine Similarity：为什么它几乎成了默认选择

先看定义：Cosine Similarity 衡量两个向量方向是否一致，而不是长度是否相近。对于文本 Embedding，这通常比直接比较长度更稳定。

先不用公式，也能理解它

假设两个向量都从原点出发。

  • 如果它们方向几乎一致，说明它们指向相似的语义区域
  • 如果夹角很大，说明它们语义更不相关

Cosine Similarity 本质上衡量的就是这个“方向一致性”。

它不太关心两个向量有多长，而更关心：

它们是不是朝着差不多的方向。

这对文本 Embedding 很重要，因为文本长度、表达方式、信息密度，都可能影响向量的模长，但我们真正关心的通常是语义方向。

公式与直觉

$$ \text{cosine}(A, B) = \frac{A \cdot B}{|A| |B|} $$

结果通常在 [-1, 1] 之间：

  • 1：方向完全一致
  • 0：几乎无关
  • -1：方向相反

在实际文本 Embedding 里，负值并不常是主要关注点，更多时候你关心的是：

  • 谁更接近 1
  • Top-K 里哪些最相似

为什么不是默认用欧氏距离

欧氏距离看的是“两个点离得多远”，它会受到向量长度影响。
而很多文本任务里，长度并不是你想重点关注的属性。

例如：

  • “如何重置密码”
  • “请问应该怎样重置账号密码？”

这两句话长度不同，但语义高度相似。
Cosine 更容易把这种“方向一致但长度不同”的关系抓出来。

所以在文本检索和语义匹配里，Cosine 几乎成了默认选项。

归一化之后，Cosine 和 Dot Product 的关系

如果向量已经做了 L2 归一化，那么：

  • Cosine Similarity
  • Dot Product（点积）

在排序上通常是等价的。

这就是为什么很多向量数据库和 ANN 索引里，实际实现会更偏向用点积或内积，因为计算更方便。

所以工程上常见的经验是：

默认看模型文档；如果向量已归一化，点积往往就足够。

6. 其他距离度量：不是不能用，而是通常没必要先偏离默认

先看定义：除了 Cosine，还有点积、欧氏距离等度量，但在文本 Embedding 里，默认优先 Cosine 或归一化后的点积，通常最稳妥。

度量适合什么情况
Cosine Similarity文本 Embedding 的默认选择
Dot Product已归一化向量、追求更快计算
Euclidean Distance需要保留模长意义时
Manhattan Distance某些高维稀疏任务，文本 Embedding 中较少首选

这里一个常见误区是：
一上来就不断换距离函数，想“调出更高召回”。

实际中更常见的情况是：

  • 问题出在 chunk 切分
  • 问题出在 query 改写
  • 问题出在 Top-K 和 rerank
  • 问题出在模型不适合该语言或任务

而不是单纯距离函数选错了。

所以工程上一个很实用的原则是：

先用模型推荐的默认度量；如果效果不好，优先怀疑数据和检索流程，再考虑更换距离度量。

7. 2026 年 Embedding 模型怎么选：不要只看排行榜，要看任务形态

先看定义：选 Embedding 模型时，最重要的不是“谁总分最高”，而是“你的任务是什么、语言是什么、部署条件是什么”。

先看你要解决什么问题

不同任务对 Embedding 的要求并不一样。

语义搜索 / RAG

最看重 query-document 对齐、召回质量、长文支持和多语言能力。

聚类 / 去重

更看重整体语义空间的一致性和类内聚合效果。

分类

更在意标签可分性和跨样本稳定性。

推荐系统

有时还会叠加行为特征、ID embedding 和业务特征，不只是纯文本。

所以“最强 Embedding 模型”本身就是个不完整问题。
更完整的问题应该是：

最适合我当前场景的 Embedding 模型是什么？

常见模型家族

下面给的是“工程上常见、容易遇到”的模型家族，而不是绝对排名。

模型 / 家族特点更适合什么场景
OpenAI text-embedding-3-small / largeAPI 方便、效果稳定、生态完善闭源 SaaS、快速落地、通用检索
Cohere Embed 系列检索导向强，多语言能力较好，最新一代也支持多模态多语言检索、企业搜索
BGE-M3开源、检索表现强、支持多语言与多粒度检索自托管、RAG、成本敏感场景
Jina Embeddings v3长文本和多语言表现较好，可做维度压缩长文档检索、开源部署
GTE / E5 / Qwen 系列 Embedding中文和通用场景常见，社区资源多中文应用、开源实验、自托管

一个更实用的选型框架

1. 先看部署方式

  • 需要极简接入、容忍闭源：优先 API 型模型
  • 需要私有部署、成本控制、数据不出内网：优先开源模型

2. 再看语言

  • 英文为主：可选范围最大
  • 中文为主：优先看中文优化好的家族
  • 多语言：优先看 multilingual retrieval 表现

3. 再看文本长度

  • 主要是短 query + 短 chunk：大多数模型都够用
  • 长文档、长 chunk：更关注长文本支持和检索稳定性

4. 再看系统预算

  • 查询量大：维度、索引成本、推理延迟都要考虑
  • 文档库大：向量维度会直接影响存储和检索成本

所以选型时，不要只问：

“哪个模型最强？”

而要问：

“哪个模型在我的语言、预算、部署方式和任务形态下最合适？”

8. 实战应用：Embedding 真正落地时怎么用

先看定义：Embedding 最常见的落地场景，是语义搜索、聚类、分类和召回；它们本质上都是“把相似问题转成向量邻近问题”。

这是 Embedding 最经典的应用。

流程通常是：

用户问题
→ 计算 query embedding
→ 与文档库向量比较相似度
→ 取 Top-K 最相近文档
→ 返回结果或交给 RAG 继续生成

它的核心优势是：
不要求 query 和文档用完全相同的词。

所以用户问：

“怎么改密码？”

系统也有机会检索到：

“账户密码重置流程”

这就是 Embedding 之所以成为 RAG 基石的原因。

聚类（Clustering）

如果你有一大堆无标签文本，比如：

  • 用户反馈
  • 工单内容
  • 评论
  • 会议纪要
  • 帖子

先做 Embedding，再聚类，往往能快速发现主题分布。

例如：

  • “登录问题”聚成一类
  • “支付失败”聚成一类
  • “配送投诉”聚成一类

这对于知识库整理、运营分析、投诉归因都很有帮助。

分类（Classification）

在数据不多、标签不多时，Embedding 还可以做轻量分类。

一种简单做法是：

  1. 为每个类别准备少量代表样本
  2. 计算这些样本的平均向量，作为类别中心
  3. 新文本和各类别中心比相似度
  4. 选最接近的类别

这种方法虽然简单，但在很多轻量任务里非常实用，尤其适合：

  • 冷启动
  • 小数据
  • 标签系统经常变动
  • 不想单独训练分类器

去重与近重复检测

很多系统还会用 Embedding 做：

  • FAQ 去重
  • 文章近重复检测
  • 评论相似内容归并
  • 工单合并建议

因为对于“意思差不多、表达略有不同”的内容，关键词方法往往不够稳，而 Embedding 更擅长抓这种近义关系。

9. Embedding 不是 RAG 的全部：检索效果常常坏在别的地方

先看定义：Embedding 很重要，但 RAG 效果不好，往往不只是 Embedding 模型的锅。

很多团队一做 RAG，第一反应就是换 Embedding 模型。
但实际上，常见问题往往出在这些地方：

  • chunk 切得太碎或太长
  • query 改写没做好
  • 文档清洗差
  • Top-K 取值不合适
  • 没做 rerank
  • 标题和正文没一起编码
  • 检索到了，但 prompt 没喂好
  • 检索结果太多，模型反而用不好

所以一个很重要的工程认知是：

Embedding 决定了检索的底座，但最终 RAG 质量是整条链路共同决定的。

从工程上看，向量模型很重要，但它不是唯一杠杆。

10. 一个最好记住的总结

如果你只想记住一句话，那就是：

Embedding 的本质，是把“语义相近”这件事变成“向量更近”，从而让搜索、匹配、聚类和检索都能被数学化、自动化。

而你真正要掌握的，不只是“会调一个 embedding API”，而是理解：

  • 向量为什么能表示语义
  • 相似度为什么默认看方向
  • 检索为什么要区分 query 和 document
  • 模型选型为什么取决于任务，不是只看排行榜
  • RAG 为什么是 Embedding + 检索 + 组织上下文的组合问题

核心概念速查

概念一句话
Embedding把离散对象映射成稠密向量，使相似对象彼此靠近
Semantic Space向量所在空间，几何关系近似语义关系
Contrastive Learning通过正样本拉近、负样本推远来学习向量空间
Query-Document Retrieval优化问题和文档之间的匹配，而不只是句子相似度
Cosine Similarity衡量向量方向一致性，是文本 Embedding 的常用默认选择
Normalization将向量归一化后，点积通常可替代 Cosine 做排序
Sentence Transformers面向句子 / 段落表示优化的一类 embedding 方法
RAG Retrieval用 query embedding 检索知识片段，再交给生成模型回答

下一篇

Embedding 解决了“把文本变成向量”的问题，但当你有几百万、几千万甚至上亿条向量时，暴力遍历找最近邻就不现实了。
这时就轮到 向量数据库 出场：它专门解决“怎么高效找最近的那些向量”。