Embedding、向量与向量数据库：彻底理解 AI 是如何进行语义检索的

当我们开始学习 RAG（检索增强生成）时，很快就会遇到几个看起来有些抽象的概念：Embedding、向量、向量检索、向量数据库。

它们经常一起出现，也很容易被混为一谈。

例如，一份文档经过 Embedding 模型处理后，会变成一组数字。这组数字为什么能够代表文本？计算机又如何根据这些数字判断两段文字是否相关？向量数据库究竟负责什么？为什么 PostgreSQL 也能通过扩展支持向量检索？

如果没有理解这些问题，就很难真正掌握 RAG 的工作原理，更难判断应该选择什么技术来构建知识库。

本文将从最基础的概念开始，逐步解释这些技术之间的关系。

阅读本文不需要机器学习基础，也不要求编程经验。理解核心思想后，再进入具体的算法和数据库实现会容易得多。

一、为什么 AI 需要把文字转换成向量？

先看一个例子。

假设知识库中有两段文字：

• 文档 A：系统发生故障后，可以恢复到之前的稳定版本。
• 文档 B：服务异常时，可以切换回先前验证通过的版本。

现在，用户提出问题：

“程序出问题了，怎么退回上一个可用版本？”

这三句话的表达方式并不完全相同，但它们可能涉及同一个解决方案。

如果系统只依赖完全匹配的关键词，就可能错过一些真正相关的资料。

人类可以根据语言和上下文理解它们的关系，但计算机需要一种能够参与数学计算的表示方式。

这就是 Embedding 发挥作用的地方。

1. 什么是 Embedding？

Embedding 通常翻译为“嵌入”或“向量表示”。

在自然语言处理中，Embedding 模型可以将一段文本转换为一组数值，这组数值称为向量（Vector）。

例如，下面是一个用于说明形式的简化示例：

原始文本： 程序出问题了，怎么退回上一个可用版本？ 转换后的向量： [0.23, -0.41, 0.78, 0.12, ...]

这里的数字仅用于解释向量的形式，并不是真实模型的输出。

你可以先把这个过程理解为：模型将文本转换成一种可以参与数学运算的表示，让后续系统有机会根据向量之间的关系寻找相关内容。

但需要注意，Embedding 不是简单地为每个词分配一个编号。

模型通过训练学习如何表示文本。对于经过良好训练的语义 Embedding 模型，含义相关的文本往往能够在相应的向量空间中表现出有用的关联。

这不意味着模型能够完美理解所有语言，也不意味着所有语义相关的文本一定会得到很高的相似度。

Embedding 的核心作用，是把文本转换成适合特定任务使用的数值表示。

2. 为什么不能直接给每个词编号？

假设我们规定：

• “苹果”对应数字 1001。
• “香蕉”对应数字 1002。
• “汽车”对应数字 1003。

这些数字可以唯一标识不同词语，但它们并没有天然的语义含义。

不能因为 1001 和 1002 比较接近，就认为苹果和香蕉的语义相似度比苹果和汽车更高。

Embedding 与这种简单编号不同。它输出的是一个多维数值向量，而不是单个词语的任意编号。向量之间的数学关系可以在一定程度上反映模型学到的文本特征。

对于语义检索，我们通常关注的是文本整体的向量表示，而不只是某个词对应的数字。

3. 向量中的每个数字代表什么？

这是初学者容易产生的疑问。

如果一个向量包含几百个甚至上千个数字，是否每个数字都对应一个明确的语义？

通常不能这样理解。

对于一般的 Embedding 模型，向量各个维度的含义并没有统一、直接可读的人工标签。文本特征通常分布在整个向量表示中，具体表示方式取决于模型的训练过程和设计。

因此，我们一般不需要逐个解释向量中的数字，而是通过模型和相应的相似度计算方法来比较不同文本。

4. 向量有多少个维度？

向量的维度由模型及其配置决定。

例如，一个向量可能包含 384 个、768 个或 1,536 个数值，也可能具有其他维度。

这里的维度可以简单理解为向量包含多少个数值。

不同模型的向量维度不同，表示能力、存储开销和计算成本也可能不同。维度更高并不自动意味着检索效果更好。

此外，不同模型产生的向量也不能仅仅因为维度相同，就认为可以直接进行有效的相似度比较。通常应使用同一个 Embedding 模型处理文档和查询，或者采用经过验证、相互兼容的模型组合。

二、向量是什么？为什么可以计算相似度？

理解了 Embedding 的作用后，下一个问题是：一组数字为什么能够帮助计算机找到相关内容？

我们可以先从一个简单的二维坐标系理解。

假设地图上有三个地点：

• A：坐标为（2，3）。
• B：坐标为（3，4）。
• C：坐标为（20，30）。

A 和 B 的坐标比较接近，而 C 距离它们较远。

在二维空间中，我们可以计算点与点之间的距离。

向量检索借用了类似的数学思想。不同的是，文本 Embedding 通常处于高维向量空间中，而不是只有两个坐标轴的地图。

这里的距离并不是地理距离，而是根据向量和所选择的数学度量计算出来的数值。

1. 三种常见的向量比较方法

向量检索中，经常会遇到以下三种方法。

这些方法的计算方式不同，因此不能将所有分数都按照同一种规则理解。

余弦相似度

余弦相似度通过向量夹角的余弦值衡量两个向量方向的接近程度。

它是文本语义检索中常见的度量方式之一。

在非零向量的标准定义下，余弦相似度的范围是 -1 到 1。对于经过特定模型训练的文本向量，分数的实际分布取决于模型和数据，不能随意设定一个通用的“正确答案阈值”。

点积

点积是将两个向量对应位置的数值相乘，再将结果相加。

如果向量经过了适当的归一化处理，点积与余弦相似度之间可以建立直接关系。

但如果没有归一化，点积还会受到向量长度的影响。

欧氏距离

欧氏距离衡量两个向量之间的直线距离。

在使用距离排序时，通常是距离越小，向量越接近。

需要注意，具体采用哪一种度量方式，应结合 Embedding 模型的特性和检索系统的设计决定。

2. 相似度高，是否代表答案正确？

不代表。

假设知识库里有两条规则：

• 规则 A：测试通过后，可以激活新版本。
• 规则 B：测试失败后，不应直接激活新版本。

这两句话在用词上高度相似，但关键条件完全不同。

如果用户想知道测试失败后能否激活新版本，系统必须正确处理“通过”和“失败”这两个条件。

即使检索系统找到了语义相关的内容，也可能存在以下问题：

• 否定词被忽略。
• 数字或版本号不匹配。
• 找到的是已经过时的规则。
• 重要条件被分块过程拆开。
• 大语言模型误读了检索结果。

因此，向量相似度只是帮助系统寻找候选内容的一种依据，并不能证明候选内容就是正确答案。

语义相似不等于事实正确，更不等于逻辑结论正确。

这也是为什么实际 RAG 系统还需要关键词检索、元数据过滤、结果排序和回答质量评估等机制。

三、从文本到检索：Embedding 是怎样发挥作用的？

现在，我们把 Embedding 和向量比较结合起来，看一个完整的例子。

假设知识库中有一份操作手册，其中包含以下内容：

服务出现异常时，可以按照回滚流程恢复到之前验证通过的版本。

用户提出问题：

新版本运行不正常，怎样切回以前的版本？

系统希望找到与问题相关的操作手册内容。

一个典型的向量检索流程如下。

第一步：提前处理文档

系统先将文档解析、分块，再通过 Embedding 模型将每个内容片段转换成向量。

例如：

Chunk 1 → 向量 1 Chunk 2 → 向量 2 Chunk 3 → 向量 3

这些向量与原始文本及相关元数据建立关联，并被保存到可检索的存储系统中。

第二步：处理用户问题

系统使用兼容的 Embedding 模型，将用户的问题转换为查询向量。

用户问题： 新版本运行不正常，怎样切回以前的版本？ 查询向量： [0.31, -0.18, 0.65, ...]

以上数字仍然只是示例。

第三步：比较向量并检索候选内容

系统计算查询向量与知识库中候选向量的相似度或距离，找到排名靠前的内容。

如果检索成功，就可能找到操作手册中的回滚规则。

第四步：取回原文

系统根据检索结果关联的标识，取回对应的文本片段、原始文档名称和其他元数据。

这一步很重要，因为向量本身是一组数值，不能直接代替原始文档。

第五步：将资料交给大语言模型

系统将用户的问题与检索到的原文一起提供给大语言模型，让模型根据资料组织答案。

至此，Embedding 才真正融入了完整的 RAG 流程。

这里有两个需要记住的细节。

第一，文档向量通常可以提前生成，不需要每次提问都重新处理所有文档。

第二，当原始文档发生变化时，系统需要根据实际实现更新相关内容、向量和索引，避免检索长期返回过时信息。

四、什么是向量数据库？

现在，假设知识库中有 100 万个文本片段，每个片段都对应一个向量。

这些向量应该存储在哪里？系统又如何快速找到与查询最相关的内容？

这就是向量数据库的主要应用场景。

1. 向量数据库负责什么？

向量数据库是一类面向向量数据存储和检索的系统，通常提供以下能力：

• 保存向量及其唯一标识。
• 建立向量索引。
• 根据相似度或距离查找候选内容。
• 根据元数据筛选结果。
• 返回与向量关联的文本或其他数据。

例如，一条知识记录可能包含以下字段：

这只是一个概念示例，实际数据结构取决于所使用的系统。

当检索系统找到相关向量时，就可以根据标识获取原文，而不是只返回一组没有实际意义的数字。

2. 向量数据库是不是只保存向量？

不一定。

有些系统会同时保存向量、文本和元数据；有些系统则将向量存储与原始文档存储分开。

例如，原始 PDF 可以保存在对象存储中，文本片段和向量保存在检索系统中，而文档的标题、版本和权限等信息则保存在关系型数据库中。

这意味着，向量数据库并不必然是整个知识库的唯一数据存储位置。

实际架构需要根据原始文件管理、数据一致性、权限控制和检索需求进行设计。

3. 向量数据库和 Embedding 模型有什么区别？

两者的职责完全不同。

如果把整个过程比作图书馆：

• Embedding 模型负责把资料转换成适合计算机比较的表示。
• 向量数据库负责管理这些表示，并帮助系统找到相关内容。
• 大语言模型负责利用找到的资料组织答案。

理解这种职责划分，比单纯记住产品名称更重要。

五、向量数据库为什么需要索引？

假设系统中只有 100 个向量，逐个计算查询向量与它们的距离，可能已经足够快。

但如果有数百万个甚至更多向量，每次查询都进行完整扫描，就可能带来较高的计算开销。

因此，系统通常会使用索引来提高检索效率。

向量检索中常见的索引方法包括：

• HNSW：一种基于分层图结构的近似最近邻搜索方法。
• IVF：通过聚类或分区组织向量，减少需要搜索的候选范围。
• 精确搜索：对符合条件的全部候选向量进行距离计算，再选择结果。

具体支持哪些方法，取决于数据库及其实现。

精确搜索与近似搜索

精确搜索会在给定的候选集合中计算并选出真实的最近邻结果。

近似最近邻搜索则通过索引结构等方式减少需要检查的内容，以更低的计算开销寻找足够接近的候选结果。

近似搜索通常能够提高大规模检索的效率，但可能漏掉部分真正的最近邻结果。

这就产生了一个实际工程中的权衡：

查询速度、计算成本与检索召回率之间需要取得平衡。

召回率可以粗略理解为：真正应该找到的相关结果中，系统实际找回了多少。

如果系统要求极高的检索完整性，就需要谨慎选择索引和参数，并通过测试验证结果，而不是只看查询速度。

六、PostgreSQL + pgvector 与 Qdrant 有什么区别？

理解向量数据库后，就会遇到一个实际的技术选型问题：应该使用关系型数据库的向量扩展，还是部署专用向量数据库？

这里以 PostgreSQL + pgvector 和 Qdrant 为例。

1. PostgreSQL + pgvector

PostgreSQL 是关系型数据库。通过 pgvector 扩展，它可以支持向量数据的存储、相似度计算和向量索引。

这意味着，开发者可以在 PostgreSQL 中同时管理结构化业务数据和向量数据，并利用 SQL 进行查询。

例如，系统可以保存文档 ID、版本、权限等字段，并结合向量相似度查找相关内容。

pgvector 支持精确最近邻搜索，也支持 HNSW、IVFFlat 等近似最近邻索引方式。具体功能和参数应以所使用的版本及官方文档为准。

参考：pgvector 官方 GitHub 仓库。

2. Qdrant

Qdrant 是专注于向量相似度搜索的系统，提供向量存储、索引、检索及元数据过滤等能力。

它将向量检索作为核心功能，并围绕向量搜索提供相应的数据组织和查询接口。

参考：Qdrant 官方文档。

3. 两者应该如何选择？

不能简单地认为专用向量数据库一定比 PostgreSQL 更快，也不能认为所有向量检索都应该直接放在 PostgreSQL 中。

选择应基于实际测试和业务需求。

如果一个系统已经使用 PostgreSQL，而且现有的向量检索能力足以满足要求，就没有必要仅仅因为开始使用 RAG，就立即增加一个新的数据库。

反过来，如果向量检索的性能、扩展性或相关功能成为瓶颈，就可以评估 Qdrant 等方案。

数据库选型的核心不是追逐某个产品，而是验证哪种架构最符合实际需求。

七、向量数量越多，就越需要专用向量数据库吗？

不一定。

向量数量是一个重要因素，但不能单独决定数据库选型。

假设两个知识库都保存 100 万个向量：

• 知识库 A 每分钟只有几次查询，对响应时间要求不高。
• 知识库 B 每秒处理大量查询，要求低延迟，还需要复杂的元数据过滤。

即使两者的数据规模相同，合适的架构也可能不同。

真正需要考虑的因素包括以下几个方面。

1. 数据规模与向量维度

向量数量越多、每个向量的维度越高，通常需要存储和处理的数据也越多。

但索引、元数据、原始文本以及数据库自身开销同样会占用资源，不能只根据向量数量估算全部成本。

2. 查询延迟与并发量

如果系统需要快速响应大量并发查询，就需要测试数据库在目标负载下的表现。

不能只使用少量数据进行测试，就推断系统能够应对未来的实际负载。

3. 检索质量

查询速度快，并不代表找到的内容一定正确。

不同索引方法、参数和过滤条件可能影响检索召回率，因此需要同时评估速度和结果质量。

4. 元数据过滤与查询需求

真实的 RAG 系统往往不只是寻找语义相近的文本，还需要按文档版本、权限、分类或时间等条件过滤。

因此，数据库的选型应考虑完整的查询方式，而不只是孤立的向量相似度计算。

5. 运维与总体成本

引入新的数据库，除了服务器资源，还会增加部署、备份、监控、升级、故障排查和数据同步等工作。

如果新系统带来的性能或功能收益有限，额外的运维成本可能并不划算。

因此，一个合理的决策过程应该是：

1. 先明确查询需求和性能目标。
2. 使用代表真实情况的数据进行测试。
3. 验证现有数据库是否满足要求。
4. 如果存在明确瓶颈，再比较专用数据库的收益和成本。
5. 根据测试结果决定是否迁移或扩展架构。

八、使用 Embedding 就能保证 RAG 检索准确吗？

不能。

Embedding 为语义检索提供了重要基础，但它只是完整检索链路中的一部分。

RAG 的检索效果还会受到多种因素影响。

1. 文档分块不合理

如果一段重要规则被切成多个失去上下文的片段，系统可能无法检索到完整信息。

2. Embedding 模型不适合目标语料

不同模型的训练数据、语言能力和任务适配性不同。

一个模型在通用文本上表现良好，不代表它一定适合所有专业领域或特定语言场景。

3. 检索策略不合适

如果问题包含精确版本号、错误代码或数字条件，单纯依赖语义相似度可能不够。

这时可以考虑关键词检索、元数据过滤或混合检索等方式。

4. 资料已经过期

如果知识库没有及时更新，系统仍可能找到旧版本的内容。

这种问题不能只通过提高向量相似度解决，还需要完善数据更新和版本管理。

5. 大语言模型误读资料

即使检索到了正确内容，模型仍然可能忽略关键条件，或者生成超出证据支持范围的结论。

因此，检索质量和生成质量需要分别验证。

一个可靠的 RAG 系统，不仅要检查最终答案，还应检查实际检索到了哪些内容，以及这些内容是否足以支持答案。

九、总结：从 Embedding 到向量数据库，建立完整认知

现在，我们可以把本文的核心概念串联起来。

Embedding 模型负责将文本转换成向量表示。

向量是由多个数值组成的数据结构，可以用于表示模型提取的文本特征。

相似度或距离计算用于比较向量之间的关系。

向量检索根据这些关系寻找相关候选内容。

向量数据库负责保存向量、建立索引，并提供相应的检索能力。

在典型的 RAG 系统中，文档先经过处理和向量化，查询时再将用户问题转换成向量，检索系统根据向量关系找到候选内容，最后由大语言模型结合原文生成答案。

但必须记住，向量相似度不等于事实正确，向量数据库也不等于整个 RAG 系统。

当你理解了这些概念之间的区别，就能更准确地判断每个技术组件解决什么问题，以及什么时候需要引入它。

下一步，我们还需要进一步研究一个关键问题：

既然向量检索可以找到语义相关的内容，为什么有些 RAG 系统还需要关键词检索、混合检索和重排序？

这将引出下一篇文章的主题：RAG 的检索策略，以及如何提高真正相关内容的召回率。

参考资料

1. OpenAI，Vector embeddings。介绍 Embedding 的概念、文本向量表示及相关应用。
2. Qdrant，Vectors。介绍向量数据及其存储方式。
3. Qdrant，Search。介绍向量搜索、过滤和检索相关能力。
4. pgvector，GitHub 官方仓库。介绍 PostgreSQL 的向量类型、距离计算和索引能力。
5. Lewis, P. et al. (2020)，Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks。经典 RAG 研究论文，帮助理解检索与生成结合的基本思想。