向量数据库

一、向量数据库的背景与需求

1.1 向量数据管理的两个发展阶段

第一阶段：多媒体数据管理

早期向量数据管理主要应用于多媒体数据（视频、图像、文本、音频）的处理。处理流程是：

1
多媒体数据 → 特征工程 → 向量 → 高维数据管理

特征工程的结果就是向量。在特征工程之后，针对特征向量产生了高维数据管理的研究方向。

第二阶段：深度学习与大模型时代

特别是大模型出来之后，嵌入模型（Embedding Model）取代了传统的特征工程。

1
多媒体数据/各种数据 → Embedding模型 → 向量 → 向量数据库

Embedding 模型代替了特征工程，但它也产生了大量的向量，这些向量需要进行管理。

加上现在有RAG（Retrieval-Augmented Generation）等应用，向量的管理变得更加重要。

1.2 向量数据库的重要性

各种数据通过向量模型变成向量后，基于这些向量去做：

• 检索
• 预测
• 推荐
• 数据分析的各种任务

至少在近期的人工智能时代，向量这种方式用处非常多。

有了大量向量之后，对它们进行管理和检索就成了一个重要问题，于是产生了向量数据库的需求。

二、向量数据库的特点与架构

2.1 向量数据库的核心特征

查询方式

以相似性查询（Similarity Search）为主，包括：

• Top-K查询
• 范围查询（Range Query）

数据从各种形式变成向量之后，语义实际上会发生一定变化，严格匹配的查询意义不是那么大，但相似性查询用得更多。

数据特点

• 支持向量存储和查询
• 可以混合属性查询
• 可以进行多模态管理（多个向量）

性能要求

• 读写速度要快，特别是对大量高维数据
• 需要像传统数据库一样的ACID特性、事务等支持

2.2 向量数据库的系统架构

Embedding模型的集成

向量数据库中一个非常重要的组件是Embedding模型。不同向量数据库有不同的处理方式：

1. 外挂方式：Embedding模型作为外部组件，与数据库分离。可以针对不同数据更换模型，在各个领域构建自己的Embedding模型。

2. 内置方式：直接把模型放在DBMS里面，任何数据都通过这个模型处理。

三、向量数据库的索引技术

3.1 索引类型概述

向量数据库的索引主要有三大类：

• 基于哈希表的索引
• 基于树的索引
• 基于图的索引

最近也有人在研究多个向量合在一起的索引。

索引构建方式：

• 随机构建
• 基于学习的构建

3.2 基于哈希表的索引

局部敏感性哈希（LSH, Locality-Sensitive Hashing）

LSH是高维数据上效果比较好的哈希方法，在数据分析、数据挖掘、机器学习中是非常重要的工具。

LSH的特点

与一般哈希相反：

• 一般哈希：把数据分得越散越好
• LSH：把相邻的数据尽可能放到一块

LSH的原理

举例：投影方法

• 放两条垂直的直线
• 所有节点往这两条线上投影
• 把每条线分成若干段
• 投影到同一块的点，向量结果比较接近

多哈希表方法

做多个哈希表，每个数据分别投射到多个哈希表中。如果两个数据比较接近，它们在某些哈希表上有更大概率在同一个桶里。

LSH函数的要求

对于两个点 $x$ 和 $q$：

• 如果 $d(x,q) < r_1$（距离小于阈值），它们在同一个桶的概率 $> p_1$
• 如果 $d(x,q) > r_2$（距离大于阈值），它们在同一个桶的概率 $< p_2$

这样，相邻的数据通过哈希函数落在同一个桶的概率就会比较大。

哈希函数的构造方法

1. 基于深度学习
   • 对于相似的对象，告诉模型它们是同一类，应该在同一个哈希桶
   • 对于不同的对象，告诉模型应该放在不同的桶
   • 训练模型使其具有预测能力
2. 基于图的哈希
   • 考虑图上的关系
   • 在图上连接在一起的点，距离更近
   • 类似GNN的做法，通过Network在图的结构上让结构相近的对象生成相邻的向量
3. 基于空间划分
   • 通过调整类似SVM的模型
   • 把整个空间分割成若干区域
   • 让每个区域里的对象比较相似

基于学习的LSH vs 传统LSH

优点：

• 学习方法：存储效率高，聚类效率高，收敛速度快
• 传统方法：有理论保证

缺点：

• 学习方法：数据分布变化后模型会失效，需要不断调整
• 传统方法：存储空间代价较大

所有学习类方法在数据库中使用的最大问题就是数据分布发生变化，模型就失效了。

量化技术

向量数据库中也会使用大模型里的量化技术来减少数据管理规模。

基于表格索引的优缺点

优点：对磁盘友好（类似哈希表）

缺点：前面提到的各种限制

3.3 基于树的索引

K-d树（K-dimensional Tree）

• 每次把空间一分为二（横批竖直划分）
• 在低维数据上效果不错

其他树形索引

有些方法每次划分考虑多个维度（至少两个维度），在高维上效果更好。

基于树索引的特点

基础是对空间的划分，有各种不同的划分方法（不同直线分割空间）。

优点：

• 低维数据上：K-d树等维度管理简单的方法效果好
• 高维数据上：多维度划分的方法效果更好

缺点：整体在高维数据上效果不如图索引

3.4 基于图的索引（重点）

基本思想

高维向量的每个维度语义不像关系数据那么清晰。如果用欧式距离算每个点的最近邻居，计算量很大。

给定一个点，要扫描和每个点都算一遍，计算量非常大。

图索引的构造

每个点和周围的点连边：

• 距离比较近的点之间连一条边
• 如果每个点只和最近的一个点连边，图可能不连通，会有很多小分支
• 可以让每个点和最近的k个点都连边（如k=2），边的数量增加，图更连通
• 如果还是不连通，可以在上面再加边，变成连通图

KNNG（K-Nearest Neighbor Graph）算法

基本流程：

1. 从图上随机找一个起始点P
2. 如果查询点Q在P的邻居区域，或区域有重叠，比较好处理
3. 如果Q的区域和P的区域没有重叠：
   • 看P周围的点
   • 找距离Q更近的点
   • 把这些点放入队列
   • 从队列取出点，继续寻找更近的邻居

使用队列的方式，类似广度优先搜索。

贪婪搜索（Greedy Search）

类似深度优先搜索：

• 从一个点出发
• 每次都找离查询点最近的邻居
• 沿着这个方向一路走过去

图索引的优缺点

优点：

• 结构简单
• 不需要像树那样先做聚类
• 添加新点简单：只要找到周围相邻的点就可以连上
• 速度较快（目前大家认为速度最快的索引方式）

缺点：

• 可能找到局部最优，不一定能找到全局最优
• 路径依赖于边的连接，有不确定性

深度优先搜索的最大问题是可能找到局部最优，全局最优的点不一定从这个点出发在这个方向上。

在RAG中的应用

虽然不一定找到最近的点，但凭借大模型的推理能力，找到相关数据后也可能得到最终结果。因为效率比较好，在RAG里用得比较多。

3.5 小世界假设与HNSW索引

小世界假设（Small World Property）

很多图都有小世界假设的特点：任何两个点之间都可以通过很少的边快速到达。

从小学、中学到大学的朋友，小学和中学的同学可能分散在不同行业、不同领域，这些就是距离比较远的边。虽然两个人离得很远，但通过这些边还是可以很快找到。

小世界的形成原因

关键是相对远的边的存在。如果每个点都只跟周围的点连，形不成小世界假设。

HNSW（Hierarchical Navigable Small World）

基于小世界假设的启发：在图上增加一些离得比较远的边。

距离越远的边，添加的概率越低（使用负指数的概率）： \(P(\text{add edge}) \propto e^{-d}\)

分层结构

把不同距离的边放在不同层次上，这样查询时可以一下子跳到非常远的距离。

HNSW的特点

• 2020年左右提出
• 后面有很多优化来进一步提升效率
• 现在用得比较多的索引，也是向量数据库里用得比较多的索引

优点：

• 找相似查询比较快
• 可以通过分层管理和增加长程边提高效率

缺点：

• 构造比较慢（要考虑很多因素，加长程边等）

四、向量查询的挑战

4.1 语义损失问题

向量模型虽然保持了一定的原始数据语义，但实际上对原始数据是有变化的，变成向量时会损失一定的语义。

问题表现

查询点Q的真正相关对象，并不一定在最临近的10个点里面。你该选择什么阈值？应该找10个、15个还是更多？

虽然你要找最近的十个点，但真正和查询相关的对象可能不在最近的十个里，可能在第30到第40个之间。

数据分布的局部性问题

和查询相关的对象可能没有局部性，实际上分散得比较远。

4.2 维度灾难（Curse of Dimensionality）

现象

随着维度增加，对象之间的距离会逐渐趋同，数据分布越来越窄。

以1000维为例，距离分布非常窄，对象的区分度成为问题。

应对方法

希望把数据转化到比较小的维度上来进行处理。

权衡

维度小可能表达能力差，所以有各种不同做法。100维左右可能是一个比较折中的点。

五、向量数据库的查询处理

5.1 距离函数

向量查询需要定义相似性的表达方式，常用的距离函数包括：

• 欧式距离（Euclidean Distance）：常用方式
• 余弦距离（Cosine Similarity）
• 汉明距离（Hamming Distance）
• 其他高维距离定义方式

计算代价

距离计算比较昂贵，特别是数据规模非常大时。虽然向量比原始图像或文字算距离快很多，但随着数据量增大，即使全部算欧式距离速度也很慢。

现在知识库里实际上都是把大文档分块，规模非常庞大。

5.2 查询类型

主要查询类型

1. 区间查找：类似R树，在不同维度上做区间查询
2. 精确查询（Exact）：严格找到最近邻或周围的邻居
3. 近似查询（Approximate）：找到近似的最近邻或近似的k邻居

精确 vs 近似

• 精确查询：计算量比较大
• 近似查询：一些高效索引可能找不到严格的最近邻，但可以很快找到近似的最近邻

5.3 查询接口

API接口

因为查询类型比较简单，查询方式比较有限，所以只要设定一系列API就可以。

SQL集成

有些结合SQL的系统，在SQL里增加了函数：

1
2
3
SELECT ... 
FROM table 
ORDER BY vector_column <-> query_vector

例如 PGVector 在 PostgreSQL 的基础上增加了向量类型和相关操作。

5.4 四种查询计划

向量数据库的查询计划相对简单，主要就是四类（不像关系数据库那么多样）：

1. Scan（遍历）

整个表遍历一遍，一边遍历一边找最临近的点。

优点：完全准确（每个点都匹配一次）

缺点：速度比较慢（没有做任何过滤）

2. PreFilter（预过滤）

先用属性约束筛选，再在筛选结果上找Top-K。

流程：

1
属性约束筛选 → 符合条件的点 → Top-K查询

优点：精确

缺点：如果属性选择率不高，效率有问题

3. Single Stage（单阶段）

先在属性约束上找，形成白名单，然后结合向量数据库再去筛选。

流程：

1
2
属性约束 → 白名单
向量查询 ↗     ↘ 最终结果

优点：找出来是准确的

缺点：效率可能相对低一些

4. PostFilter（后过滤）

向量数据库和属性约束分别查询，然后做交集（Join）。

流程：

1
2
3
属性约束 → 结果A ↘
                    Join → 最终结果
向量Top-K → 结果B ↗

优点：效率比较高

缺点：准确性有问题 - 两边可能形不成交集

向量数据库找到的临近10个或20个点，可能都不满足属性要求，满足属性要求的可能在第30到40个之间。不知道Top-K这个K该是什么值。

5.5 查询优化策略

不同向量数据库选择不同方案的方法：

基于规则的优化

例如 Weaviate：

• 数据集小 → 直接扫描
• 数据集大：
  • 属性选择率高 → PreFilter
  • 属性选择率低 → Single Stage

基于代价的优化

例如 Milvus：

• 先进行代价估计
• 根据代价估计公式计算各方案的代价
• 选择代价最小的方案

West的动态优化

• 先看选择率
• 选择率强 → PreFilter（扫描效果好）
• 选择率弱 → PostFilter
• 选择率中等 → 运行时看真实选择率再调整

5.6 查询性能指标

Recall（召回率）

所有相关数据中，能查到多少。

Precision（准确性）

查到的数据中，有多少是准确的。

这两个指标是评估向量查询的方法。

六、商用向量数据库系统

6.1 向量数据库分类

1. Native（原生向量数据库）

从底层存储就直接存向量，完全为向量管理而设计。

代表系统：

• Milvus（米尔沃斯）：比较早的向量数据库
• Pinecone（拼号）：比较早的原生向量数据库

2. Extended（扩展型）

在已有数据库基础上增加向量数据类型和检索能力。

分为两类：

(a) 关系数据库扩展

• PGVector：PostgreSQL + 向量类型
• AnalyticDB：阿里的分析型数据库 + 向量

(b) NoSQL数据库扩展

• Redis：增加向量检索
• MongoDB：增加向量支持
• Neo4j：图数据库 + 向量

3. Search Engine Integration（搜索引擎集成）

在搜索引擎基础上增加向量能力。

代表系统：

• Elasticsearch
• OpenSearch
• Solr

6.2 主要向量数据库介绍

Pinecone（拼号）

架构特点：

• API接口层
• 索引构建（通过Log触发）
• Blob存储方式（用于WAL和recovery）
• 分布式架构

Milvus（米尔沃斯）

特点：

• 比较完整的向量数据库
• 支持多种索引类型
• 可以和GPU对接
• 多模态系统：支持属性数据，不仅仅是向量
• 构建在云平台上（底层用S3和HDFS）
• 支持多种查询类型
• 对读写workload支持较好

从结构上来讲是比较完整的向量数据库。

Weaviate（微微）

特点：

• 用Transformer模型作为向量化模型
• 使用HNSW索引（比较新）
• 支持比较多的类型
• 效率比较好
• 有对象存储和倒排索引

向量数据库里，特别是基于哈希表的方式，用倒排索引可以快速知道对象在哪个桶，很快找到相应的桶。

Redis扩展

特点：

• 基础是key-value的NoSQL数据库
• 结合向量数据库比较简单（value换成向量）
• 使用HNSW索引
• 向量查询和range查询

Redis本身是大的内存数据库，效率比较高，加上向量后影响不大。

PGVector和PG-DiskANN

基于PostgreSQL的扩展，使用两类索引：

• HNSW（图索引）
• 基于表的索引 + 倒排索引

优点：可以和关系数据库的其他数据类型结合

缺点：效率可能低于原生向量数据库

关系数据库引擎有时不太适合向量管理。

AnalyticDB

阿里的策略：

• 在原来的分析型数据库基础上增加向量能力
• 与其他国内数据库厂商不同（其他基本都有专门的向量数据库）

6.3 性能对比

原生向量数据库

效率最高，专门为向量优化。

扩展型向量数据库

效率相对较低，因为基于已有数据库引擎。

Redis

效率比较高，因为本身是内存数据库。

PostgreSQL扩展

好处是可以跟其他数据类型结合，但效率可能不如原生。

七、向量数据库的挑战与未来方向

7.1 准确性问题

问题表现

在RAG等领域经常听到吐槽：虽然用了向量数据库，但找出来的信息不是特别准确。

原因分析

1. Embedding模型的语义损失
   • 数据在嵌入模型计算过程中丢失了很多信息
   • 为了避免维度灾难，向量维度不能太大
   • 小维度上语言表达能力不够强
2. 通用模型的局限性
   • 现在基本用统一训练的模型（如BGE-M5）
   • 针对性不强，对不同类型数据效果不够好

针对不同类型数据做针对性的Embedding模型研究是一个方向。

7.2 性能问题

图索引对磁盘不友好

图天生的问题就是对磁盘不友好。

原因：

• 磁盘访问以块为单位
• 图是一个个点，每个点信息量太少，不足以充满一个块
• 图的搜索是跳来跳去（根据边跳转）
• 磁盘是线性的，图数据映射到线性存储会有距离
• 图的搜索对磁盘是典型的随机读取
• 磁盘的随机读取效率非常低

解决方向

• 表格方式和树的方式对磁盘友好（哈希表分块，树做空间划分，一个节点可以做得很大）
• 但它们在recall等方面有缺点

怎么做到既对磁盘或分布式环境友好，又综合性能好，是个比较难的事情。

当前状况

基于图的系统基本上都把图放在内存里处理，需要大内存或分布式共享内存。

几乎所有基于图的系统基本上都是非常吃内存的。

7.3 更新维护问题

图索引的update问题

构造时：

• 每个点连接周围离得比较近的点
• 构造过程需要多次查询找近邻

更新时的问题：

• 点不断插入删除
• 某个点被删除后，相关的边就不存在了
• 从一个点到另一个点的路径可能变得很远
• 原来的最短路径可能因为边断了而需要绕很远

图索引的维护成本很高，特别是不断有删除的话，搜索效果会变差。

不确定性

由于点的分布问题，即使不做修改也可能出现路径问题。图的不确定性更强。

构建代价

创建图实际上是非常大的工作量。

7.4 其他研究方向

多向量查询

查询时不是一个点，可能是多个点。例如给三段话，找和这三段话最接近的内容。

安全性

怎么在向量数据库里实现安全性，把数据库的安全性结合进来。

Workload考虑

把各种workload的分布式考虑进来。

语义增强

向量数据库的语义一直是个问题。

结合知识图谱

怎么把知识图谱和向量数据库结合在一起？

优势：

• 知识图谱里的数据准确性比较有保证
• 查询时既考虑向量因素，又考虑知识图谱的信息
• 可以提高效率和准确性

问题核心：

• 从语义上不相关的结果，从向量距离上可能是相关的
• 这是向量数据库的主要问题

八、总结

特别是大模型出来以后，一下子把向量数据库的需求提高了很多，这方面的研究也会越来越多。

向量数据库是这两年刚出来的一个新的数据库类型，如果感兴趣，里面还有很多问题需要研究。

主要内容来源于 SIGMOD 2024 Tutorial，2025-2026年数据库领域会议（SIGMOD, VLDB等）有很多向量数据库方面的论文。

• Previous
  IO系统与中断
• Next
  域扩张与极小多项式