向量数据库（vector database）入门：原理、应用与选型

想让搜索理解意思，不一定要再引入一个数据库：你可能已经在用的关系型数据库 PostgreSQL，装上 pgvector 扩展就能做到。要理解什么是向量数据库（vector database），先分清 3 件事：把内容表示成数字、检索相似记录，以及把结果限定在符合条件的数据内。只有当独立服务的检索能力或运维方式能满足现有方案无法满足的要求时，才值得为它付费。

下文涉及的数据库能力，均已于 2026 年 10 月 20 日对照厂商在线文档核实。客服案例仅用于说明原理，并非性能基准测试，也不是实际部署报告。

向量数据库（vector database）到底如何工作？

向量数据库存储内容的数值表示，并找出与查询表示接近的记录。因此，即使措辞不同，搜索“我登录不了”也可能找到有关账号恢复的文章。它既可以是独立服务，也可以是现有数据库增加的一项能力。Pinecone 的介绍解释了其中的存储、索引和搜索功能。

可以把嵌入向量想象成一张“概念地图”上的地址。**嵌入模型（embedding model）**经过训练，能将内容转成数值表示，把相关内容放在彼此接近的位置。数据库负责保存这些地址，并查找附近的内容。这张地图是模型学习出来的，所以“距离近”可以作为相关性的线索，却不是保证。

**嵌入向量（embedding）**就是这串数字，维度则是其中的一个位置。通常不能给每个位置分别贴上“账单”“安全”或“客户满意度”的标签；语义分布在整个表示中。文字、图片和音频都能用合适的模型生成嵌入向量。Qdrant 的向量文档对这种表示方式作了说明。

数据库里究竟存什么？

一条实用的搜索记录不能只有嵌入向量，还需要稳定的 ID、向量和元数据。元数据是产品、语言、租户、发布状态等普通字段。原文可以与记录一起保存，也可以保留标识符，让应用据此取回原文。单有嵌入向量，答案生成器拿不到可以引用的原始段落。Pinecone 对记录与文档的定义区分了用于搜索的表示和与之关联的字段。

对于客服帮助文章，一条搜索记录可以对应一个内容完整的段落，而不是整篇页面。这样的片段称为文本块（chunk）。将账号恢复步骤完整保留，比在例外说明中间截断更有用，因为那段说明可能正好告诉用户接下来该怎么办。

用一张图理解向量数据库

距离表达的是模型空间中的相似程度，并不是物理距离。示意图只能帮助理解这个概念。

这张地图由嵌入模型决定。换一个数据库，并不会自动让模型更准确地定位含义模糊的查询。选择模型时，可以先看嵌入模型对比，再用真实用户的问题评估。

相似度搜索与索引如何配合？

查询需要使用与已存内容兼容的嵌入模型及配置。如果模型区分查询模式和文档模式，就应按各自要求使用。数据库随后按合适的距离度量比较生成的向量，例如余弦距离或欧氏距离，并返回最近的记录。Pinecone 的索引指南介绍了这一流程。

索引是一种额外的数据结构，可以帮助搜索避免逐一比较所有已存向量。精确搜索会在选定的度量下找出最近的记录。近似最近邻搜索通常简称 ANN，通过允许漏掉部分真正的最近邻来减少搜索工作量。这里的召回率衡量近似搜索找回了多少真正的最近邻，并不衡量答案是否属实。

常见索引有两类：HNSW 将邻近向量组织成连接图；IVFFlat 对向量分组，再搜索距离查询最近的那些组。pgvector README介绍了这两种索引。对产品来说，要判断的是：节省的搜索工作量，是否值得用可能漏掉的相关结果来换。

元数据过滤解决什么问题？

过滤条件决定哪些记录有资格进入结果，相似度则决定这些结果的排序。例如，查询可能同时要求 product=workspace、language=en、status=published，并且记录属于客户获准访问的租户。这些都需要明确设置，不能指望嵌入模型自行理解并执行。Pinecone 的元数据过滤指南展示了如何用过滤条件缩小搜索范围。

服务端必须依据经过身份验证的用户身份，确定租户和权限。浏览器或智能体传来的过滤条件，本身并不构成授权依据。在把非公开段落交给答案模型之前，还要确认用户仍有权访问其来源记录。

向量数据库应用示例：从客服文档中找出答案

客服搜索应该能找到解决用户问题的段落，即使用户不知道文章标题。

假设有 3 篇文章：

• 账号恢复：“如果无法使用身份验证器设备，请使用已保存的恢复码。如果没有恢复码，请联系支持团队。”
• 账单地址：“在账单设置中修改后续发票使用的地址。”
• 邀请同事：“管理员可以在成员设置中发送工作区邀请。”

用户问：**“手机丢了，登录时卡在验证码这一步，怎么办？”**预期应该匹配到账号恢复文章。这是评估时的目标，并不意味着所有嵌入模型都会把它排在首位。

1. 1

   准备原始段落

   为每个能够回答问题的段落保留文章 ID、标题、来源位置和当前权限。不要把操作说明与限定其适用条件的例外说明拆开。

2. 2

   生成嵌入向量并存储

   用选定的嵌入模型处理每个段落，将生成的向量与来源 ID、产品、语言、发布状态等元数据一起保存。同时保留模型配置，确保后续查询使用兼容的表示。

3. 3

   在符合条件的内容中检索

   将用户问题转成嵌入向量，应用产品和权限限制，再检索邻近记录。检查取回的段落本身，不能只看相似度分数。

4. 4

   返回依据或生成答案

   搜索界面可以直接展示匹配的文章。问答界面则可以把文章段落交给语言模型，并要求它引用来源，在依据不足时明确说明。

根据提供的段落，合理的回答是：“请使用已保存的恢复码。如果没有恢复码，请联系支持团队。”即使用户显得很焦急，也不能凭空编造绕过账号安全措施的办法。

如何为 RAG 搭建向量数据库？

先做好检索，再加入答案生成。**检索增强生成（RAG）**是指在语言模型生成回答时，为它提供检索到的材料。向量数据库负责寻找候选依据，语言模型负责组织回答。即使厂商将两者打包提供，它们仍是不同的职责。Pinecone 的 RAG 介绍解释了这种关系。

在客服产品中，先验证账号恢复类问题能否检索到恢复说明，再检查生成的回答有没有超出该段落的内容。如果检索到的是错误文档，修改回答提示词并不能可靠地补救检索问题。

智能体可以决定再次搜索、改写问题或查询其他来源。这是在检索外增加了一层控制循环，并没有改变向量存储的内容。Agentic RAG 指南介绍了这一步架构演进。

PostgreSQL 什么时候够用，什么时候值得购买托管服务？

如果现有数据库中的检索能力已经满足产品要求，就把向量留在那里。当搜索需要独立容量、专门的检索能力，或团队难以自行提供的运维方式时，再将其拆出去。这是根据下文文档所述行为提出的架构建议，并非实测排名。

需要包含价格的完整产品比较，可以参考向量数据库选型对比。这里首先要确定的是：应用到底需要完成什么任务。

pgvector：让检索留在应用数据库里

pgvector 为 PostgreSQL 增加向量相似度搜索，同时保留 SQL 联接和事务：前者用于组合相关记录，后者让相关变更一起提交。如果 SaaS 产品的文档和账号权限本就存放在同一个数据库中，它很适合作为起点。项目 README介绍了这些能力。

这种架构的好处是，可以在同一个地方关联段落及其所有者、状态和来源。内容变动后仍要重新生成嵌入向量，但不必仅仅为了上线搜索，就把权限元数据复制到另一个数据库。

**难点在于带过滤条件的近似检索，以及共享资源带来的影响。**pgvector 默认执行精确搜索。使用近似索引时，过滤发生在扫描索引候选结果之后，因此查询可能返回过少的合格记录。README 列出了迭代扫描、过滤列索引、部分索引和分区等处理方式。详见过滤指南。

例如，权限过滤可能排除最初候选结果中的大多数。先从查询设计入手解决，不要急于认定数据库能力不足。随后再测量：为解决这个问题而增加的内存消耗或搜索耗时，能否与产品的日常事务负载共存。

如果这种安排满足要求，团队也有能力运维 PostgreSQL，就选择 pgvector。不要只因为原型规模变大就迁移；能明确指出仍未满足的要求时，再考虑迁移。

Pinecone：为托管检索基础设施付费

如果需要独立检索服务，又不想运维底层基础设施，Pinecone 是一个选择。其架构文档介绍了基于无服务器基础设施的托管服务：底层容量由 Pinecone 负责运维，读写路径可以独立扩展。

其概览介绍了自行提供向量、集成嵌入选项、元数据过滤，以及可用于隔离租户的逻辑分区 namespace。对于需要独立搜索容量的小型产品团队，它的实际价值在于省去自行维护另一套数据库部署的工作。

**难点在于，应用与服务之间的对接仍由你负责。**产品必须把内容修改、删除和权限更新同步到服务中，并发现同步失败。基础设施托管并不会替你判断文章是否仍然有效，或用户是否有权访问。

Pinecone 还说明了其最终一致性行为：记录更新后，可能需要一段时间才能被查询看到。设计“上传后立刻提问”的体验时，应参考其数据新鲜度指南。写入成功，并不能证明下一次搜索就已经包含这次更新。

当团队确实需要把基础设施运维交给厂商，并将搜索与应用流量分开时，Pinecone 才能体现这笔费用的价值。如果现有数据库已经满足这些需求，而数据同步反倒成了最大的新增问题，就很难证明这笔支出合理。

Qdrant：部署方式可选的专用检索引擎

Qdrant 提供专用向量搜索引擎，既有开源版本，也有托管云服务。其概览介绍了由向量和 payload 构成的 point。payload 是附加字段，用于携带上下文和过滤结果。

如果知识产品需要同时按租户、文档状态和访问组过滤，值得细看其过滤文档和索引指南。payload 索引帮助评估过滤条件、规划查询；支持过滤的 HNSW 则会增加与已建立索引的 payload 值相关的连接。

**难点在于，索引需要认真设计，还要多维护一套存储。**Qdrant 建议在导入数据前创建 payload 索引，让向量图能够包含这些考虑了过滤条件的连接。如果之后才添加，为了获得这一收益，可能需要重建 HNSW 索引。自托管意味着部署仍由团队负责；Qdrant Managed Cloud则提供托管集群、扩缩容、监控和备份。

当 Qdrant 的过滤行为或部署选项能满足某项具体要求时，再进行评估。和其他独立搜索存储一样，专用引擎也需要严格处理来源内容的更新和删除。

上线前必须弄清哪些限制？

评估检索时，要带上用户实际会遇到的过滤条件和数据更新。对所有文档搜得很快，并不能说明面对只能访问一小部分内容的客户时，搜索表现也同样好。

**向量维度必须适配索引表示。**pgvector README 列出的限制是：使用 HNSW 或 IVFFlat 时，vector 索引最多支持 2,000 维，半精度表示 halfvec 的索引最多支持 4,000 维。这是索引限制，并非所有存储记录的通用限制。确定嵌入输出方案前，先核对兼容性。参见 pgvector 索引文档。

**召回率和答案质量要分开检查。**将近似结果与精确最近邻结果比较，可以诊断索引造成的漏检。还要单独标注检索出的段落是否回答了用户问题。如果模型没有恰当地表示这类任务，精确搜索也可能准确地返回错误依据。

**数据新鲜度也包括及时移除。**修改文章时，应替换过时段落；删除文章时，应移除对应的搜索记录。撤销权限后，也必须阻止相关段落继续传给模型。对这些变化的测试，应和成功导入数据一样认真。

**资源消耗不只来自搜索。**修改内容后的重新嵌入、索引维护和来源记录同步，都属于系统工作。真正有意义的容量上限，是实际负载触及的限制，而不是孤立的向量条数。

向量数据库有哪些被夸大的能力？

最被夸大的说法，是加上向量存储，应用就有了可靠的记忆。它提供的是检索已存表示的方法。记住什么、谁可以访问、何时失效，以及更正信息如何覆盖旧记录，仍要由你决定。

另一个误区是认为语义搜索能取代精确匹配。产品代码、错误字符串和名称往往仍需要按词项匹配的检索。混合搜索会把这种信号与语义检索结合起来。Qdrant 的概览明确指出，稠密向量可能漏掉技术术语和标识符。

还有一个误区，是把相似当成真实。语气肯定的段落也可能已经过时、无权访问，或只是在讨论另一个相关问题。结果应始终关联其依据，应用也要能够说明：现有材料不足以支持回答。

对创业者来说，这意味着应先投入检索评估，再扩建基础设施。对开发者来说，要测试从来源更新到返回获准访问的答案这条完整链路。对运维人员来说，即使数据库由厂商托管，也要明确由谁负责索引失败和内容过时的问题。

如何搭建向量数据库：从现有系统开始落地

从已有数据库、一组能够回答问题的客服文档，以及书面验收标准开始。如果已有 PostgreSQL，先确认服务商支持 pgvector，再按其支持的安装流程启用扩展。

选定嵌入模型和兼容的向量表示，将每个段落与来源 ID、权限字段一起保存。在条件允许时，先用精确检索建立基线；只有实测搜索耗时确实需要优化，再引入近似索引。

收集真实客服问题及其预期来源段落。测试集要包含不同表达方式、精确错误字符串、受限文章、最近修改的内容，以及文档无法回答的问题。相关性和排除能力都要检查：返回有用段落与拦住无权访问的段落，是两项不同要求。

为产品设定可接受的搜索延迟、检索质量和更新可见性要求。现有数据库达标，就在那里上线。如果不达标，再带着失败查询和运维要求评估 Pinecone 或 Qdrant。这样，托管服务需要解决什么问题、凭什么值得付费，就有了具体依据。

常见问题

向量数据库在 AI 中有哪些用途？

它可以支持语义搜索、为答案生成检索材料、基于相似度进行推荐，以及取回已存上下文。嵌入模型必须能够表示应用所需的那种相似性。

为什么需要矢量文件？

矢量图形文件用形状和路径描述图像。这里的“矢量”与本文讨论的数值嵌入是不同概念。AI 搜索功能并不需要矢量图形文件。

哪些数据属于向量数据？

客服段落、商品图片或音频片段的嵌入向量都属于向量数据：它们用一组数字，为特定的相似性任务表示某个对象。这与地理或绘图领域使用的向量不同。

数据科学中的向量是什么？

向量是一组有序的数字。在嵌入系统中，这些数字用于表示一个对象，让数学比较能够帮助识别相关对象。

SQL 是向量数据库吗？

SQL 是查询语言。安装 pgvector 的 PostgreSQL，就是既能存储又能搜索向量的关系型数据库实例。采用独立向量服务属于架构选择，并不是 AI 强加的要求。

有哪些值得考虑的向量数据库？这 3 个怎么选？

针对本文讨论的选型场景：已有 PostgreSQL，可以评估 pgvector；需要托管检索基础设施，可以评估 Pinecone；需要专用引擎，并希望在开源部署和托管部署之间选择，可以评估 Qdrant。这些是按场景给出的起点，并非性能基准排名。

ChatGPT 使用向量数据库吗？

不能仅凭对话界面或记忆功能，就推断产品使用了某个数据库。本文并未确认 ChatGPT 的内部存储架构。为自己的产品选择检索存储时，应以实际要求为依据，而不是猜测其他服务如何实现。

免费的向量数据库选哪个？

如果已经在用 PostgreSQL，先评估开源的 pgvector；如果需要专用引擎，可以考虑开源的 Qdrant。无论选择哪个，都无法省去托管和运维工作。现有数据模型与检索要求，比软件的类别标签更重要。

AI 用什么数据库？

没有一种数据库是必选项。应用可以用关系型存储管理账号和事务，用向量搜索处理相似性，再用来源存储保存文档。这些能力可以放在同一个系统中，也可以分布在独立服务里。

AI 中的向量数据库是什么？

它是对内容的数值表示进行搜索的存储与检索组件，为 AI 应用提供相关记录。它本身不会训练模型，也不会判断答案是否正确。

订阅邮件通讯，获取构建 AI 产品的实用指南。