05.Embedding是什么大模型为什么需要把文字变成向量

Embedding 是什么？大模型为什么需要把文字变成向量？

码海寻道 · 大模型、智能体与 RAG 工程组件系列第 5 篇

在前面的文章里，我们反复提到 Embedding：文档要先做 Embedding，用户问题也要做 Embedding，然后才能交给 Milvus 或 pgvector 检索。

但 Embedding 到底是什么？为什么一段文字不能直接放进向量数据库？为什么语义相近的句子，经过转换后会变成距离较近的向量？

理解 Embedding，是理解 RAG、语义搜索、推荐系统和多模态检索的基础。

从工程视角看，Embedding 不是业务代码里的一个“神奇函数”，而是一项需要独立管理的模型服务能力：它有模型文件、版本、输入长度、批处理、并发、GPU/CPU 资源和失败重试。文档入库和用户查询必须使用同一套可追踪的模型配置，否则向量即使成功写入，也可能无法可靠比较。

一、Embedding 可以先理解成“语义坐标”

Embedding 通常翻译为“嵌入”或“向量表示”。它的核心工作，是把一段文本、图片、音频或其他数据，映射成一串数字：

“如何申请年假？” ↓ Embedding 模型 ↓ [0.018, -0.274, 0.631, ..., 0.092]

这串数字就是向量。它不是把每个汉字简单替换成一个数字，也不是给句子生成一个可以直接阅读的“编码答案”，而是试图把内容中的语义关系表示在一个高维空间中。

可以把它想象成一张非常复杂的地图：

• “如何申请年假？”和“年假申请需要什么材料？”可能距离较近；
• “如何申请年假？”和“数据库索引如何创建？”通常距离较远；
• 表达方式不同但含义相近的句子，有机会被放到相近区域。

因此，Embedding 的价值不是让机器读懂一句话，而是让机器能够用数学方式比较不同内容之间的相似程度。

二、为什么关键词搜索不够？

传统关键词搜索擅长寻找字面上出现过的词。

用户搜索：

“员工离职后还能休年假吗？”

文档里可能写的是：

“劳动关系终止时，未休年休假的处理方式如下……”

两句话表达的是相近问题，但使用的词并不完全相同。单纯依赖关键词，可能因为“离职”和“劳动关系终止”、“休年假”和“未休年休假”没有完全匹配，而漏掉相关内容。

语义搜索希望比较的是“意思是否接近”，而不仅是“词是否相同”。Embedding 就是把文字转换成可进行语义比较的数字表示。

当然，Embedding 不是关键词搜索的全面替代品。订单号、错误码、产品型号、法律条款编号等内容，往往需要精确匹配。实际系统常常把关键词检索和向量检索结合起来，这会在后续“混合检索”文章中展开。

三、Embedding 模型是怎么学会表示语义的？

Embedding 模型通常由神经网络训练而来，常见基础包括 Transformer 等模型结构。训练过程中，模型会接触大量文本关系，并学习哪些内容在语义上更接近、哪些内容应该区分开。

训练目标可能包括：

• 判断两段文本是否相关；
• 让问题和正确答案更接近；
• 让同一语义的不同表达靠近；
• 区分相似但含义不同的内容；
• 让文本、图片等不同模态映射到可比较的空间。

训练完成后，模型会把输入转换成固定维度或约定维度的向量。向量中的某一个数字通常没有可以直接解释的人类含义，真正有用的是整组数字之间的相对关系。

四、向量维度是什么意思？

一个向量可能有 384、768、1024、1536 或更多维度。维度可以理解为描述语义空间的坐标数量。

例如，一个极度简化的二维空间可以这样表示：

横轴：与技术主题的相关程度 纵轴：与数据库主题的相关程度

真实 Embedding 通常不是二维，而是数百到数千维。高维空间可以承载更复杂的语义关系，但维度越高并不意味着效果一定越好。

维度会影响：

• 向量存储空间；
• 检索计算成本；
• 索引构建时间；
• 网络传输大小；
• 对模型和数据质量的要求。

最重要的工程规则是：

向量数据库的维度必须与 Embedding 模型实际输出的维度完全一致。

例如，Milvus 建立向量字段时需要指定dim。如果 Embedding 模型输出 1536 维，而 Collection 的向量字段定义成 768 维，写入时就会报维度不匹配错误。

Milvus 官方 Embedding Function 文档也强调，向量字段的维度必须匹配所选 Embedding 模型的输出维度。

五、一个完整的 RAG Embedding 流程

以企业文档问答为例，建库阶段和查询阶段必须使用兼容的向量表示方式。

建库阶段

原始 PDF ↓ 解析为文本 ↓ 切分成多个 Chunk ↓ Embedding 模型 ↓ 得到每个 Chunk 的向量 ↓ 写入 Milvus / pgvector

查询阶段

用户问题 ↓ 使用同一套 Embedding 体系向量化 ↓ 在向量库中搜索相似向量 ↓ 获取相关 Chunk ↓ 交给大模型生成答案

如果建库和查询使用的模型、距离度量或预处理方式不一致，检索效果可能明显下降。

Embedding 服务通常如何部署？

常见有三种方式：

方式	优点	代价	适合场景
第三方 API	接入快、无需管理模型服务器	网络、费用和数据合规依赖供应商	原型、低运维团队
应用进程内加载	调用链短、部署简单	与 API 服务争抢 CPU/内存，扩缩容不独立	小型内部服务
独立 Embedding 服务	可批处理、限流、独立扩容和版本切换	需要维护模型服务和计算资源	企业知识库、持续批量入库

生产链路更适合把模型服务和业务 API 解耦：

文件上传 → 解析/切分任务 → Embedding 服务 → Milvus / pgvector 用户问题 → Embedding 服务 → 向量检索

Embedding 服务至少应记录模型标识、模型版本、向量维度、归一化方式、请求批次和失败原因。批量入库时要设置批次大小、超时、重试和幂等键，避免同一文档失败重试后产生重复向量。

六、为什么文档和问题必须使用兼容的模型？

假设文档是用模型 A 生成的向量，用户问题是用模型 B 生成的向量。即使两个模型都输出 1536 维，也不能因此认为它们可以直接比较。

向量的每个维度和整体空间结构取决于模型训练方式。模型 A 的“第 100 个维度”和模型 B 的“第 100 个维度”没有天然对应关系。

因此，通常要保证：

• 文档向量和问题向量来自同一 Embedding 模型；
• 使用相同的文本清洗规则；
• 使用相同的语言和任务模式配置；
• 使用匹配的距离度量；
• 模型升级后重新评估，必要时重新建库。

对于某些专门设计的查询向量和文档向量模型，模型会要求使用不同的提示前缀或编码入口。这种差异必须以模型官方文档为准，不能凭经验省略。

七、密集向量和稀疏向量有什么区别？

密集向量

密集向量通常由数百到数千个浮点数组成，大多数维度都有非零值。它擅长表达整体语义和概念关系。

[0.12, -0.04, 0.88, 0.31, ...]

语义搜索通常使用密集向量。

稀疏向量

稀疏向量的维度可能非常高，但只有少数位置有非零值。它更容易保留词项、关键词和局部匹配信息。

{ "indices": [17, 4021, 8920], "values": [1.8, 0.7, 2.4] }

稀疏向量适合词项匹配和学习型关键词检索。Milvus 文档将密集 Embedding 和稀疏 Embedding 作为两类主要向量形式，并支持在检索系统中结合使用。

为什么要考虑混合？

用户搜索“PostgreSQL 16 的 JSONB 索引错误”时，语义相似性很重要，但“PostgreSQL 16”“JSONB”等精确词也很重要。

密集向量可以理解整体意思，稀疏向量或全文检索可以保留明确词项。两者结合，往往比单独使用一种信号更稳健。

八、相似度是如何计算的？

向量检索需要一个距离或相似度指标，常见的有：

• 余弦相似度：关注两个向量的方向；
• 内积：计算向量对应元素乘积之和；
• 欧氏距离：计算空间中的直线距离；
• 其他针对特定向量类型的度量。

以余弦相似度为例：

cos(A, B) = (A · B) / (||A|| × ||B||)

如果两个向量方向相近，余弦相似度通常较高；如果方向差异较大，相似度会降低。

实际项目不能只凭公式选择指标。应遵循 Embedding 模型、向量数据库和索引配置的官方建议，并用真实业务数据进行评估。

下一篇《向量相似度是怎么计算的？从余弦距离到语义检索》会专门讨论距离指标、Top K、阈值和检索结果排序。

九、Embedding 不是万能的“语义理解器”

Embedding 可能出现以下问题：

1. 细节被压缩

一整段文本被压缩成一个向量后，数字、时间、否定词和条件关系可能没有被检索系统准确区分。

2. 长文本语义被稀释

一段文本包含多个主题时，整体向量可能只体现一个模糊的平均语义。因此，文档切分对 Embedding 效果非常重要。

3. 领域术语理解不足

通用 Embedding 模型对企业内部缩写、产品代号和专业术语的理解可能有限，需要用领域数据评估。

4. 相似不等于正确

两个文本语义相近，不代表其中一个就是回答问题所需的正确依据。检索后仍然需要重排序、权限过滤和答案校验。

十、如何选择 Embedding 模型？

不要只看向量维度或公开榜单，至少要比较以下方面：

语言能力

中文、英文、多语言和中英混合场景的表现可能不同。使用中文企业资料时，要用真实中文问题和文档测试。

查询类型

问答检索、长文档检索、代码搜索、商品推荐和图片搜索，对 Embedding 的要求不同。

最大输入长度

模型可以接收的最大 Token 数会影响文本切分策略。超过限制的文本不能简单寄希望于模型自动处理。

向量维度与成本

维度越大，通常会增加存储、索引和检索成本；API 模型还会产生调用费用。

部署方式

• API 模型：接入快，运维负担小，但依赖网络和外部服务；
• 本地模型：数据控制力强，但需要计算资源和模型运维；
• 混合方案：敏感数据本地处理，通用内容使用外部服务。

实际评测集

建立几十到几百条真实问题，标注正确文档，比较不同模型的召回结果，而不是只用几句人工感觉“相似”的文本判断。

十一、一个最小的 Embedding 伪代码

下面的示例刻意不绑定某一家模型服务，只展示应用层需要完成的逻辑：

defbuild_index(chunks,embedding_model,vector_store):vectors=embedding_model.embed_documents(chunks)vector_store.upsert([{"id":chunk.id,"vector":vector,"text":chunk.text,"metadata":chunk.metadata,}forchunk,vectorinzip(chunks,vectors)])defsearch(query,embedding_model,vector_store,top_k=5):query_vector=embedding_model.embed_query(query)returnvector_store.search(query_vector,top_k=top_k)

生产实现还需要补充：批量处理、失败重试、模型版本、维度校验、权限字段、删除同步和评测日志。

一个最小的服务边界校验可以这样写：

EXPECTED_DIM=768# 示例值，必须替换为实际模型维度defembed_and_validate(texts:list[str])->list[list[float]]:vectors=embedding_model.encode(texts)iflen(vectors)!=len(texts):raiseValueError("embedding result count mismatch")ifany(len(vector)!=EXPECTED_DIMforvectorinvectors):raiseValueError("embedding dimension mismatch")returnvectors

不要通过截断或补零来“修复”维度错误，这会改变向量空间。正确做法是统一模型配置，或新建版本化集合重新生成向量。

十二、上线前的 Embedding 检查清单

• 文档和查询使用兼容的 Embedding 模型；
• 向量字段维度与模型输出一致；
• 距离指标与索引配置匹配；
• 文本切分没有截断关键条件；
• 记录模型名称、版本和处理时间；
• Embedding 服务是否设置超时、限流、重试和批量大小；
• 批量任务是否有幂等键、批次状态和失败补偿；
• 文档更新后可以重新生成向量；
• 删除文档后对应向量不会继续被召回；
• 使用真实问题评估 Top K 召回效果；
• 对关键词、编号和专业术语进行精确匹配测试；
• 生产环境不会把真实密钥写进代码或日志。

结语：把文字变成向量，是为了让机器能够比较“意思”

Embedding 的本质，是把文本、图片或其他数据映射到一个可以进行数学比较的向量空间。

在 RAG 中，它连接了文档与检索；在推荐系统中，它连接了用户与商品；在语义搜索中，它连接了问题与结果。

但 Embedding 只是检索链路的基础，不是全部答案。向量质量还会受到模型选择、文本切分、距离指标、元数据过滤和重排序的影响。

下一篇，我们继续回答一个更具体的问题：

《向量相似度是怎么计算的？从余弦距离到语义检索》

---

参考资料

1. Milvus Documentation：Embedding Overview
2. Milvus Documentation：Embedding Overview（概念说明）
3. Milvus Documentation：Quickstart
4. Hugging Face Documentation：Tokenizer
5. Pinecone Documentation：Concepts

本文为“码海寻道”原创技术文章。Embedding 模型的接口、维度和部署方式会随版本变化，使用前请以对应模型的官方文档为准。