Embedding 是什么？文本转向量是怎么回事

Embedding 解决什么问题

你在做 RAG 的时候，需要判断两段文字"意思是不是接近"。"出差费用报销流程"和"怎么报销差旅费"，关键词完全不同，但意思一样。

计算机不认识中文，它只认识数字。Embedding 就是把一段文字变成一组数字（向量），让计算机能用数学方式计算两段文字的相似度。

这个过程是这样的：

"出差费用报销流程" → Embedding 模型 → [0.12, -0.34, 0.56, ..., 0.78]  （768 维向量）
"怎么报销差旅费"   → Embedding 模型 → [0.11, -0.33, 0.55, ..., 0.77]  （很接近的向量）
"今天天气真好"     → Embedding 模型 → [-0.45, 0.67, -0.12, ..., 0.23] （差异很大的向量）

前两个向量很接近（余弦相似度高），说明语义相似。第三个和前两个差很远，说明语义不同。这就是向量检索的基础。

Embedding 在 RAG 里的位置

整个 RAG 流程中，Embedding 被用了两次：

• 索引时：把文档的每一段都转成向量，存进向量数据库
• 查询时：把用户的问题也转成向量，去向量数据库里找最相似的段落

两次用的必须是同一个 Embedding 模型，否则向量空间不一致，相似度计算没有意义。这是一个很容易犯的错——换了模型就得重新索引所有文档。

主流 Embedding 模型

怎么选模型

第一步：看你的语言。中文场景不要用纯英文模型，效果会差很多。BGE、M3E、GTE 都是中文场景的好选择。 第二步：看你的部署方式。如果用 API 调用，OpenAI 和 Cohere 都很方便。如果需要本地部署（数据不出服务器），选 BGE 或 M3E，用 Sentence Transformers 库加载。 第三步：拿自己的数据测。准备 20-50 对你的真实业务问题和文档段落，跑一遍各家模型，看哪个检索准确率最高。排行榜上的分数是通用基准，和你的场景可能差别很大。

从业者提醒

Embedding 模型选错是 RAG 效果差的头号原因。很多人花大量时间调 prompt、调切块策略，结果发现是 Embedding 模型没选对。如果检索不到正确的内容，后面的生成环节再怎么调也没用。 中文场景的坑。很多流行的 Embedding 模型（包括早期的 OpenAI 模型）在中文上的表现不如英文。如果你的文档是中文的，一定要选在中文上表现好的模型。 维度不是越高越好。高维向量占存储更多、检索更慢。如果你的文档量不大、查询精度要求不高，768 维完全够用。1536 维适合对精度要求高的生产场景。 索引和查询必须用同一个模型。换模型 = 重新索引全部文档。所以选模型的时候要慎重，不要频繁切换。 长文本处理。Embedding 模型有输入长度限制（通常 512 或 8192 token）。超长文本需要先切块再分别 Embedding。这也是为什么 RAG 需要"切块"这一步。

下一步

• 想了解 Embedding 存哪里？看 向量数据库是什么
• 想了解 RAG 的完整流程？看 RAG 是什么
• 想了解怎么写好 prompt？看 Prompt Engineering 是什么