Back to Index
基础概念 /

向量数据库

为什么需要向量数据库、ANN 算法原理、主流产品对比，以及何时用专用向量 DB 何时用 pgvector

16 min read Part of AI Foundation · Ch. 8

向量数据库

flowchart LR
  A["向量数据库"]
  A --> B["分类：基础概念"]
  A --> C["关键词：AI"]
  A --> D["关键词：向量数据库"]
  A --> E["关键词：RAG"]
  A --> F["关键词：ANN"]

当你有几百万、几千万甚至上亿条 Embedding 向量时，问题就不再是“怎么算相似度”，而是“怎样在足够短的时间里找出最相似的那些向量”。向量数据库要解决的，就是这个检索层面的工程问题。

这篇文章会讲什么

上一篇文章讲了 Embedding：把文本变成向量，再用 Cosine Similarity 或点积去比较“谁和谁更像”。但一旦进入真实业务，问题会立刻升级：

  • 知识库不是 100 条文档，而是 100 万、1000 万甚至更多
  • 每条文档不止一段文本，而是被切成很多 chunk
  • 用户查询不能等几秒，更不能在高并发下崩掉
  • 检索不只是“语义相似”，还常常要叠加租户、时间、权限、文档类型等过滤条件

这时候，你会发现：

Embedding 解决了“怎么表示”，向量数据库解决的是“怎么高效找”。

很多团队刚开始做 RAG 时，会先用最直接的方法：
把 query 向量和所有文档向量逐个比较，再按相似度排序。数据量小时这没问题；但数据一大，这种方式很快就会在延迟、吞吐和成本上碰到天花板。

向量数据库（Vector Database）以及更广义的向量检索系统，正是为这个问题而生。它们的核心价值不是“能存向量”，而是：

  • 能为向量建立近似最近邻索引
  • 能在超大规模下做毫秒级检索
  • 能和 metadata 过滤、分区、多租户、更新、持久化结合起来
  • 能成为 RAG 和语义搜索系统的可运营底座

所以本文的重点不是 API 用法，而是把底层逻辑讲清楚：

  • 为什么暴力搜索会失效
  • ANN（Approximate Nearest Neighbor）为什么能大幅提速
  • HNSW、IVF、PQ 各自在解决什么问题
  • metadata filtering 为什么是生产级系统的必需品
  • 什么时候该用 Pinecone、Qdrant、Milvus 一类专用系统
  • 什么时候 pgvector 这样的 PostgreSQL 扩展就已经够用了

延伸阅读：

先说结论：向量数据库不只是“一个存向量的数据库”

很多人第一次听到“向量数据库”时，容易把它理解成：

一个专门拿来存 embedding 的地方。

这个理解只对了一半。

因为“存”其实不难。
真正难的是：

  • 存进去之后怎么查
  • 查的时候怎么快
  • 快的同时怎么尽量不漏
  • 不同租户、不同权限、不同时间范围怎么过滤
  • 有写入、有删除、有更新时索引怎么维护
  • 查询延迟、召回率、内存占用怎么权衡

所以从工程视角看，向量数据库真正提供的是三样东西：

  1. 向量索引能力：用 ANN 算法做大规模相似搜索
  2. 检索系统能力：支持过滤、分页、批量写入、分片、持久化等
  3. 应用集成能力：能接进 RAG、推荐、搜索、Agent 工作流

换句话说：

向量数据库的核心不是“保存向量”，而是“把向量检索变成可上线的系统能力”。

1. 为什么需要向量数据库

先看定义：当向量规模足够大时，暴力遍历虽然精确，但在实时系统里会变得过慢；向量数据库通过索引和近似搜索，把这件事从秒级甚至分钟级压到毫秒级。

暴力搜索为什么很快就不现实

假设你有一个并不夸张的知识库：

  • 1000 万条向量
  • 每条 1536 维
  • 每次查询要找 Top-10 最相似结果

如果你采用最直接的方式：

  1. 把 query 也变成一个 1536 维向量
  2. 与 1000 万条向量逐个计算相似度
  3. 排序后取最相似的 10 个

这就是 brute-force search（暴力搜索）。

它的优点很明显：

  • 逻辑简单
  • 结果精确
  • 不会漏掉真正最近的邻居

但问题也一样明显：

  • 计算量线性增长
  • 数据越大越慢
  • 高并发时成本极高
  • 对实时 RAG、在线搜索、推荐召回不友好

pgvector 官方文档也明确写到：默认情况下它执行的是 exact nearest neighbor search，也就是精确搜索；而一旦数据量大了，就可以改用 ANN 索引来换取速度。:contentReference[oaicite:0]{index=0}

向量数据库到底在优化什么

向量数据库本质上是在优化一个问题：

如何在不遍历全部向量的前提下，尽量快地找到“足够接近真正最近邻”的那些结果。

注意这里有两个关键词：

1. 不遍历全部

也就是减少计算范围。

2. 足够接近真正最近邻

也就是允许近似，而不要求每次都绝对精确。

这就是 ANN 的基本思想：
用少量精度损失，换数量级的速度提升。

向量数据库通常负责哪些事

从系统功能角度看，一个实用的向量数据库或向量检索系统，通常会承担这些职责：

  1. 存储向量和元数据
  2. 建立 ANN 索引
  3. 支持相似搜索
  4. 支持 metadata filtering
  5. 支持 upsert / delete / reindex
  6. 支持多租户、分区、分片或集群
  7. 提供查询接口和监控能力

所以，向量数据库并不是一个“新型神奇数据库”，而是围绕向量检索这件事做了系统化封装。

2. 向量检索基础：暴力搜索 vs 近似最近邻

先看定义：暴力搜索精确但慢；ANN 不保证每次都找到绝对最优结果，但能在大规模下把检索速度提升几个数量级。

什么叫最近邻搜索

如果你已经有了 embedding，就会得到这样一个任务：

给定一个查询向量，在所有向量里找出距离最近的那些向量。

这就叫 Nearest Neighbor Search。

如果你真的找到的是数学意义上的最近邻，那就是精确最近邻搜索。
如果你找到的是“非常接近最近邻、但不一定每次都是绝对最优”的结果，那就是 Approximate Nearest Neighbor（ANN）。

为什么 ANN 可以接受

很多人第一次听“近似”两个字，会本能担心：

近似不就意味着不准吗？

但在大多数应用里，你真正关心的是：

  • Top-5 或 Top-10 的召回是否足够高
  • 结果是否稳定
  • 延迟是否足够低
  • 系统是否能承载真实流量

而不是：

每次都必须在数学意义上找出全局最优的那个向量。

对于 RAG 来说，检索本来就是整个链路中的第一步。
只要召回率足够高，后面还有 rerank、prompt 组织、生成模型理解等步骤。
所以在工程上，95%–99% 的高召回 ANN 往往比 100% 精确但慢很多的 brute force 更有价值。

这也是为什么 pgvector 官方文档会把 exact search 和 approximate index 明确区分开：前者是完美召回，后者是以 recall 换 speed。:contentReference[oaicite:1]{index=1}

速度、精度、成本三角

向量检索里有一个非常重要的现实：

速度、召回率、资源成本，三者通常无法同时最优。

你几乎总是在做权衡：

  • 想要更高召回率，可能要更大索引、更高内存、更多搜索步骤
  • 想要更低延迟，可能要接受更多近似
  • 想要更省钱，可能要做量化压缩，牺牲一些精度

所以向量数据库的选型和参数调优，本质上都围绕这个三角展开。

3. ANN 算法简解：HNSW、IVF、PQ 到底在做什么

先看定义：主流 ANN 方法大致分三类：基于图的、基于聚类划分的、基于量化压缩的。HNSW、IVF、PQ 分别是这三类思路的代表。

先建立一个直觉：不要在整片海里捞针

暴力搜索像是：

每次都把整个数据库扫一遍，再找最相似的结果。

而 ANN 的思路更像：

  • 先缩小候选范围
  • 再在候选里找最接近的
  • 或者先建立捷径，让搜索不用从头乱撞
  • 或者把向量压缩后更快比较

所以 ANN 并不是一种单一算法，而是一类“让搜索不必全量扫描”的方法。

HNSW：把向量空间变成“多层导航图”

HNSW 是 Hierarchical Navigable Small World 的缩写。
它的核心思想是：把所有向量组织成一个多层图结构。

直觉上你可以把它想成：

  • 底层是本地街道，连接细密
  • 上层是高速公路，连接更稀疏但跳得更远
  • 查询时先在高层快速靠近目标区域
  • 再逐层往下逼近最近邻

这类方法的优点是：

  • 通常召回率很高
  • 查询延迟表现好
  • 在很多通用场景里是默认强项

它的代价是：

  • 建索引更慢
  • 内存占用更高
  • 更新和维护成本通常比简单结构更大

pgvector 官方文档就明确说明：HNSW 索引创建的是多层图结构，通常在 speed-recall tradeoff 上优于 IVFFlat，但 build 更慢、占更多内存。:contentReference[oaicite:2]{index=2}

Milvus 文档也把 HNSW 描述为图结构索引，特点是高精度、低延迟，但内存开销较高。:contentReference[oaicite:3]{index=3}

IVF：先分桶，再在少数桶里找

IVF 是 Inverted File Index。
它的思路不是建图，而是先把向量空间粗略划分成很多簇。

查询时：

  1. 先看 query 更靠近哪些簇中心
  2. 只进入这些簇
  3. 在簇内做更细的搜索

这很像图书馆索引：

  • 不是进馆就把所有书全翻一遍
  • 而是先定位到最相关的几排书架
  • 再在这些书架上找目标

IVF 的优点是：

  • 索引结构更直观
  • 内存通常更可控
  • 非常适合和量化压缩结合

它的局限是：

  • 如果真正最近邻落在“没被选中的簇”里，就会漏掉
  • 聚类质量、簇数量、probe 数量都很影响效果

在 pgvector 里，对应的近似索引类型叫 IVFFlat。:contentReference[oaicite:4]{index=4}

PQ：不是更聪明地找，而是把向量变得更小

PQ 是 Product Quantization。
它解决的不是“如何导航”，而是“如何压缩”。

它的核心思路是：

  • 把高维向量切成若干子空间
  • 每个子空间分别量化编码
  • 不再存完整浮点向量，而是存较短的编码

这样做的好处是非常实际的：

  • 内存占用大幅下降
  • 磁盘和缓存压力变小
  • 大规模数据集更容易装进单机或少量节点

代价则是：

  • 有量化误差
  • 检索精度可能下降
  • 通常需要和 IVF 之类方法结合使用

Milvus 文档明确说明 IVF_PQ 是把 IVF 的簇筛选和 PQ 的压缩结合起来，用更低内存支持大规模 ANN 检索。:contentReference[oaicite:5]{index=5}

一个实用的算法选择直觉

你最在意召回率和查询延迟

优先看 HNSW。

你最在意大规模和内存成本

优先考虑 IVF + PQ 一类路线。

你规模不大，或者现成数据库已够用

先别急着上复杂专用系统，可能 exact search 或简单 ANN 就够。

工程上，算法选择很少是“哪种理论最好”，更多是：

在哪个规模、预算和延迟要求下，哪种方案最划算。

4. Metadata Filtering：为什么“只做语义相似”远远不够

先看定义：生产系统里的搜索几乎从来不只是“谁更像”，还要叠加权限、租户、时间、类型、状态等业务条件；这就是 metadata filtering 的意义。

纯向量相似搜索有什么问题

如果你只按向量相似度搜，理论上能找到“语义最接近”的结果。
但业务里常常还要求：

  • 只搜当前租户的数据
  • 只搜用户有权限访问的文档
  • 只搜最近 30 天
  • 只搜 PDF 或工单类内容
  • 只搜某个产品线、某个语言、某个区域

这些条件很多都不适合编码进 embedding 本身。
因为它们不是语义问题，而是业务约束问题。

所以一个可上线的向量检索系统，几乎一定要支持：

向量相似度 + 结构化过滤条件

Qdrant 的官方文档就明确把 filtering 作为核心能力，强调有些业务特征根本无法完全表达在 embedding 里，例如库存、地理位置、价格区间、ID 或 payload 条件。:contentReference[oaicite:6]{index=6}

Pre-filter 和 Post-filter 的区别

这是一个很实用的设计点。

Pre-filter

先按 metadata 过滤，再在过滤后的子集里做向量搜索。

优点：

  • 业务条件精确
  • 不会先搜出无权限或无关数据

问题：

  • 如果过滤后子集仍然很大，性能可能一般
  • 如果数据库/索引没有很好支持，可能退化严重

Post-filter

先做向量搜索，拿较大候选集，再按 metadata 过滤。

优点：

  • 相似度搜索路径更稳定
  • 在某些索引结构下更容易实现

问题：

  • 候选集可能被过滤掉很多，导致最终结果不够
  • 可能要先取比 Top-K 大得多的候选数

现实系统里，很多产品会做混合优化，而不是非此即彼。

Qdrant 官方资料里专门讨论了 filterable HNSW 和基于 payload 的索引扩展，正是为了解决“过滤条件叠加到 ANN 检索里”的问题。:contentReference[oaicite:7]{index=7}

为什么 filtering 往往比 ANN 本身更影响系统体验

因为很多 RAG 和搜索项目后期真正痛的不是：

“HNSW 和 IVF 哪个快 5 毫秒？”

而是：

  • 能不能只搜当前客户的数据
  • 能不能按版本、时间、状态过滤
  • 能不能在有 ACL 的情况下仍然保持性能
  • 能不能稳定处理高选择性过滤条件

这意味着，过滤能力经常比裸 ANN 指标更决定你能不能上线。

5. 主流产品怎么看：不要只看“谁最快”，要看系统形态

先看定义：产品选型的核心不是“谁理论最强”，而是“你需要托管还是自托管、规模多大、过滤多复杂、是否已经有 PostgreSQL 体系、团队愿不愿意维护新组件”。

常见产品可以大致怎么理解

下面这部分不追求“排行榜”，而是给你一个更稳定的理解框架。

Pinecone

更偏托管服务路线，强调开箱即用和少运维。适合想快速上线、希望把基础设施负担外包出去的团队。

Qdrant

开源和托管都可选，近年在过滤和检索结合这块很受关注，文档中明确强调 payload filtering 和 filterable HNSW。适合重视检索性能、过滤能力、又希望保留一定自主控制的团队。:contentReference[oaicite:8]{index=8}

Weaviate

更强调一体化体验，常被用在“向量检索 + schema + 更完整应用层”的场景。适合希望少拼装、多用平台能力的团队。

Milvus

更偏大规模、分布式和底层检索能力。文档中对 HNSW、IVF、IVF_PQ 等索引支持明确，适合数据规模大、愿意投入更多基础设施治理的场景。:contentReference[oaicite:9]{index=9}

Chroma

更轻量，更适合本地开发、原型验证、小规模项目。通常不是你在超大规模线上系统里的最终形态，但非常适合起步。

pgvector

不是独立“向量数据库”，而是 PostgreSQL 扩展。它的意义非常大：
如果你已经在用 PostgreSQL，且规模、延迟和团队能力都还在一个比较温和的区间内，那你可能根本不需要再引入一个新存储系统。pgvector 现在支持 exact search，也支持 HNSW 和 IVFFlat 等 ANN 索引。:contentReference[oaicite:10]{index=10}

一个更实用的选型方式

与其背产品表，不如先问下面这些问题：

1. 你要不要自托管

  • 不想管基础设施：优先托管服务
  • 要求数据留内网：优先开源或自托管方案

2. 你的规模大概在哪

  • 几十万到几百万：pgvector、Qdrant、Weaviate 等都可能够
  • 几千万到上亿：更要考虑专用向量系统和分布式能力
  • 规模再大：压缩、分片、冷热分层都会变重要

3. 你过滤复杂吗

  • 几乎不需要过滤：纯向量检索系统就能跑得很快
  • 权限、租户、时间、类型很多：过滤能力和 query planner 会很关键

4. 你团队熟悉什么

  • 团队已经非常熟悉 PostgreSQL：pgvector 的组织成本最低
  • 团队愿意引入专用组件：专用向量 DB 在复杂检索上通常更灵活

5. 你对延迟和召回的要求有多苛刻

  • 几十毫秒能接受：很多方案都可用
  • P99 亚 10ms 且流量大：索引、缓存、分布式、硬件都要更认真对待

6. 何时用专用向量 DB，何时用 pgvector

先看定义：如果你已经有 PostgreSQL，数据量和性能要求还没到特别极端，pgvector 往往是很强的起点；只有当规模、过滤复杂度、延迟目标或系统解耦需求继续上升时，专用向量数据库的优势才会越来越明显。

pgvector 最大的优点：不是快，而是“省系统复杂度”

很多文章会把 pgvector 和专用向量数据库直接做性能对打。
但从架构角度看，pgvector 最大的价值，往往不是绝对最快，而是：

  • 你不用引入新存储系统
  • 向量和业务数据可以同库管理
  • 可以复用 PostgreSQL 的权限、事务、备份、运维体系
  • 对很多中小规模项目来说，落地成本最低

pgvector 官方文档也明确支持 exact search 以及 HNSW、IVFFlat 两类 ANN 索引，因此它并不只是“玩具方案”。:contentReference[oaicite:11]{index=11}

什么场景更适合 pgvector

通常包括：

  • 你的主业务数据库本来就是 PostgreSQL
  • 数据规模在可控范围内
  • 检索延迟不是极端苛刻
  • 团队不想维护第二套数据库
  • 你更看重系统简单性和一致性

还有一点容易被忽略：
PostgreSQL 生态本身就很强，如果你的检索常常要和业务表 join、过滤、权限控制混在一起，pgvector 反而可能让系统更自然。

PostgreSQL 官方新闻也提到，pgvector 的新版本持续在改进 ANN 索引与过滤查询之间的执行策略。:contentReference[oaicite:12]{index=12}

什么场景更适合专用向量数据库

当你出现下面这些特点时，专用系统通常更值得考虑：

  • 数据规模明显上升
  • 向量检索成为独立核心服务
  • 需要更复杂的过滤与检索优化
  • 需要更强的分布式扩展
  • 需要更清晰的检索层与业务层解耦
  • 需要专门围绕向量索引做容量和性能调优

换句话说：

当向量检索已经不是“数据库里的一个功能”，而是“系统核心能力之一”时，专用向量数据库的优势才会真正放大。

7. 索引参数与性能调优：为什么没有“默认最优解”

先看定义：向量检索调优本质上是在调三个东西：召回率、延迟、资源占用。不同业务的最优点不一样。

HNSW 参数为什么重要

以 HNSW 为例，常见参数会影响两个阶段：

建索引阶段

例如更大的构建搜索范围，通常会让图结构更好，但构建更慢、内存更高。

查询阶段

例如搜索时探索更多候选，通常会提升召回率，但也会提高查询延迟。

pgvector、Milvus、Qdrant 等系统在索引层面都提供了类似方向的参数控制，只是名字和接口可能不同。:contentReference[oaicite:13]{index=13}

工程上最容易犯的错

1. 只看延迟，不看召回

RAG 场景里，少几毫秒通常不如少漏关键文档重要。

2. 只看小样本测试

10 万条数据时表现很好的参数，到了 1000 万条未必还合适。

3. 只换数据库，不看上游

很多检索问题实际上出在：

  • chunk 太碎或太长
  • embedding 模型不合适
  • query 改写没做好
  • metadata 设计不合理

4. 忽略写入和更新成本

有些索引查询很快，但频繁更新时代价不低。
如果你的数据不是只读语料库，而是高频变动，就要考虑这一点。

一个实用的调优顺序

更稳妥的做法通常是：

  1. 先确定 embedding 模型和 chunk 策略
  2. 再确定是否需要过滤、按什么过滤
  3. 再选择索引类型
  4. 再测召回率 / 延迟 / 内存
  5. 最后才做更细的参数微调

因为很多时候，系统瓶颈并不在 ANN 参数本身，而在更前面的数据组织方式。

8. 一个最好记住的原则：向量数据库解决的是“检索工程”，不是“语义本身”

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

Embedding 决定你把语义映射得好不好，向量数据库决定你能不能在真实规模下把这些相似结果及时找出来。

所以，向量数据库不是在替代 embedding，也不是在替代生成模型。
它是在整个 RAG / 搜索系统里承担“中间检索层”的角色。

把这个位置想清楚以后，你就会更容易做选型：

  • 语义质量差，先看 embedding 和数据
  • 召回慢，先看索引和检索层
  • 检索到了但回答不好，先看 prompt 和生成层
  • 有权限、多租户、多条件过滤，重点看数据库和 query plan

这也意味着：

向量数据库从来不是单独存在的，它总是和 embedding、chunking、filtering、reranking、generation 一起工作。

核心概念速查

概念一句话
Nearest Neighbor Search在向量空间中寻找距离最近的向量
ANN近似最近邻，用少量精度损失换大幅速度提升
HNSW基于分层图结构的 ANN，通常高召回、低延迟，但更吃内存 :contentReference[oaicite:14]{index=14}
IVF / IVFFlat基于聚类划分的 ANN，先找相关簇，再在簇内搜索 :contentReference[oaicite:15]{index=15}
PQ通过量化压缩向量，降低存储和检索成本，常与 IVF 组合使用 :contentReference[oaicite:16]{index=16}
Metadata Filtering在相似检索时叠加租户、权限、时间、标签等业务过滤条件 :contentReference[oaicite:17]{index=17}
pgvectorPostgreSQL 的向量扩展，支持 exact search 与 ANN 索引 :contentReference[oaicite:18]{index=18}
Recall检索系统找回真正相关结果的能力，RAG 场景通常比极致低延迟更重要

下一篇

向量数据库解决了“找相似文档”的问题，但 AI 应用还需要更多能力：查天气、算数学、查数据库、发邮件、调内部 API……这些都要求模型不只是“会说”，还得“能做”。这就轮到 Tool Calling 出场了。