向量数据库¶

约 2845 个字预计阅读时间 9 分钟

1.定义¶

向量数据库是一种专门用于存储、索引和查询高维向量数据的数据库。其核心能力是高效执行近似最近邻（ANN）搜索，即快速找到与目标向量最相似的 Top-K 个向量。

1.1 向量的来源¶

向量数据库中的向量并非手动录入，而是通过 Embedding 模型将非结构化数据（文本、图片、音频、视频）转换为稠密向量：

文本向量：如 OpenAI text-embedding-ada-002（1536 维）、BGE、M3E 等模型将句子或段落编码为向量
图像向量：如 CLIP、ResNet 等模型将图像编码为向量
多模态向量：如 CLIP 同时支持文本和图像编码到同一语义空间

1.2 核心概念¶

Embedding（嵌入）：将高维稀疏的原始数据映射到低维稠密向量空间的过程
维度（Dimension）：向量的长度，常见为 768、1024、1536 等
相似度：两个向量在空间中的接近程度，语义越相似的数据其向量距离越近

2.相似度度量¶

在向量检索中，衡量两个向量"有多像"是核心操作。常用的度量方式有以下几种：

2.1 欧氏距离（L2 Distance）¶

计算两个向量在空间中的直线距离。距离越小越相似。适用于需要衡量绝对位置差异的场景。

2.2 余弦相似度（Cosine Similarity）¶

计算两个向量夹角的余弦值，取值范围为 [-1, 1]。值越大越相似。它只关注方向不关注大小，是文本向量检索中最常用的度量方式。

2.3 内积（Inner Product / Dot Product）¶

两个向量对应分量乘积之和。当向量经过归一化处理后，内积等价于余弦相似度。在推荐系统中广泛使用。

2.4 汉明距离（Hamming Distance）¶

计算两个等长二进制串不同位的数量。主要用于二值化向量（如经过二值量化的向量），计算速度极快。

3.ANN 搜索¶

3.1 为什么需要 ANN¶

精确 KNN 搜索需要计算查询向量与数据库中每一个向量的距离，其计算复杂度为 O(Nd)，其中 N 是数据量，d 是向量维度。当数据量达到百万、十亿级别时，这种暴力计算的方式延迟极高，无法满足在线应用的实时性要求。

ANN（Approximate Nearest Neighbor）搜索通过牺牲少量精度（召回率）来换取几个数量级的速度提升。它采用预先构建索引的方式，避免了全局计算。

3.2 两阶段流程¶

向量检索分为两个阶段：

索引构建阶段（离线）：对全量向量数据构建索引结构，如聚类中心、图结构或量化码本。此阶段耗时较长但只需执行一次。
搜索阶段（在线）：查询向量利用已构建的索引快速定位候选集，在候选集内计算精确距离并返回 Top-K 结果。此阶段延迟极低。

4.常见的 ANN 算法¶

4.1 基于树的方法¶

将向量空间递归划分为多个子空间，形成树形结构。搜索时只遍历与查询向量相关的分支。代表算法有 KD-Tree、Ball Tree。适用于低维数据（通常 d < 20），在高维向量场景下性能退化严重（维度灾难）。

4.2 IVF¶

IVF（Inverted File Index）：先对数据集进行聚类（如 k-means），形成 nlist 个聚类中心。搜索时，先找到距离查询向量最近的 nprobe 个聚类中心，然后只在这些中心包含的向量里进行精确搜索。

优点：内存占用相对小，适合大规模数据
缺点：需要训练聚类中心，nprobe 参数对性能和精度影响大

4.3 HNSW¶

HNSW（Hierarchical Navigable Small World）：构建多层图结构，上层稀疏便于快速导航，下层稠密保证精度。查询时从顶层入口节点出发，逐层向下贪心搜索。

优点：查询延迟极低，召回率高，支持动态增删
缺点：内存占用大（通常是原始数据的数倍），构建索引耗时较长

4.4 PQ¶

PQ（Product Quantization）：一种向量压缩技术。将高维向量切分成多个子段，对每个子段进行量化（聚类），用聚类中心的 ID 代表原始子向量。大大减少内存占用和距离计算成本。

通常与 IVF 结合使用，即 IVF-PQ，是内存受限和十亿级数据规模的常用方案。

4.5 ScaNN¶

ScaNN（Scalable Nearest Neighbors）由 Google 提出，结合了 ANQ（Asymmetric Non-Quantization）和树搜索两种技术。在精度和速度之间取得了良好的平衡，是 Google 内部大规模检索的核心算法。

4.6 DiskANN¶

DiskANN 由 Microsoft 提出，核心思想是将图索引的大部分数据存储在磁盘上，仅将少量导航数据保留在内存中。通过高效的磁盘 I/O 调度实现十亿级向量的单机检索，大幅降低内存成本。

5.评估指标¶

召回率（Recall）：返回的 K 个结果中包含真实最近邻的比例，衡量检索精度
QPS（Queries Per Second）：每秒处理的查询数，衡量系统吞吐量
延迟（Latency）：单次查询的耗时，通常关注 P50、P95、P99 分位值
内存占用：索引占用的内存大小，直接影响硬件成本

6.向量数据库的典型架构¶

一个完整的向量数据库通常包含以下核心组件：

6.1 存储层¶

负责向量和元数据的持久化。常见的存储方案包括本地文件系统、对象存储（如 S3、MinIO）以及内嵌的轻量级数据库（如 SQLite、RocksDB）。

6.2 索引引擎¶

核心检索组件，负责构建和维护 ANN 索引（HNSW、IVF、PQ 等），执行向量相似度计算。

6.3 查询引擎¶

接收查询请求，解析过滤条件，协调索引引擎执行检索，对结果进行排序和裁剪后返回。

6.4 分布式协调层（集群模式）¶

在分布式部署中，负责数据分片（Sharding）、副本管理、负载均衡和故障恢复。通常借助 etcd、Kubernetes 等基础设施实现。

6.5 工作流程¶

1. 数据写入 → 向量 + 元数据(Payload) → 持久化存储
2. 索引构建 → 从存储读取向量 → 构建 ANN 索引
3. 查询请求 → 解析过滤条件 → 索引检索候选集 → 精确距离计算 → 过滤 + 排序 → 返回 Top-K

7.向量数据库在 RAG 中的应用¶

在 RAG（Retrieval-Augmented Generation）架构中，向量数据库是检索层的核心组件：

7.1 知识入库¶

将文档切分为 Chunk → 通过 Embedding 模型向量化 → 连同元数据（来源、标题、段落编号等）写入向量数据库 → 后台异步构建索引。

7.2 检索增强¶

用户提问 → 问题向量化 → 在向量数据库中检索 Top-K 相关 Chunk → 将检索结果作为上下文拼接到 Prompt → 交由 LLM 生成回答。

7.3 关键考量¶

Chunk 大小：影响检索精度和上下文窗口利用率
元数据过滤：支持按文档来源、时间范围等条件过滤后再检索
混合检索：向量检索 + BM25 关键词检索融合，提升召回质量
重排序（Rerank）：检索结果经过精排模型二次排序

8.常见的向量数据库¶

8.1 FAISS¶

FAISS（Facebook AI Similarity Search）由 Meta 开源，是一个用于高效向量检索的 C++ 库，提供 Python 接口。它不是一个独立的数据库服务，而是一个底层检索引擎。支持 IVF、PQ、HNSW 等多种 ANN 算法，支持 GPU 加速。适合需要将向量检索能力嵌入自有系统的场景，但需要自行处理数据持久化、分布式和高可用等问题。

8.2 Milvus¶

Milvus 由 Zilliz 开发，是一款开源的云原生分布式向量数据库。支持多种 ANN 索引（IVF、HNSW、SCANN 等），支持标量过滤、混合检索、多租户、数据分片和副本。提供独立的 standalone 和分布式集群部署模式，适合大规模生产环境。Zilliz Cloud 是其全托管云服务版本。

8.3 Qdrant¶

Qdrant 用 Rust 编写，是一款开源向量数据库，以高性能和低延迟著称。支持 HNSW 作为默认索引，内置丰富的过滤查询和 payload 管理功能。提供 gRPC 和 REST API，支持 Docker 部署和 Qdrant Cloud 托管服务。其独特的量化机制（标量量化、二进制量化、乘积量化）可在保证召回率的同时显著降低内存占用。

8.4 Weaviate¶

Weaviate 是一款开源向量数据库，特点是内置向量化模块，可以直接在数据库内调用多种 Embedding 模型（如 OpenAI、Cohere、HuggingFace 等），无需外部生成向量再导入。支持 HNSW 索引，提供 GraphQL 查询接口和 RESTful API。适合希望简化 Embedding + 存储 + 检索全链路的场景。

8.5 Chroma¶

Chroma 定位为 AI 原生嵌入式向量数据库，主打轻量级和开发者友好。默认使用 HNSW 索引，支持本地持久化和内存模式，pip install 即可使用。与 LangChain、LlamaIndex 等框架集成良好，非常适合原型开发、本地实验和中小规模应用。但在大规模分布式和高可用方面能力较弱。

8.6 Pinecone¶

Pinecone 是全托管的闭源向量数据库服务，无需运维，开箱即用。支持元数据过滤、命名空间隔离和稀疏-稠密混合检索。其特点是完全托管、自动扩缩容、SLA 保障，适合不想投入运维资源的团队。缺点是数据存储在 Pinecone 云端，存在供应商锁定和数据合规方面的考量。

8.7 pgvector¶

pgvector 是 PostgreSQL 的一个扩展，让传统关系型数据库具备向量存储和检索能力。支持 HNSW 和 IVFFlat 索引，支持将向量数据与业务数据放在同一数据库中，便于关联查询和事务一致性。适合已有 PostgreSQL 基础设施、向量规模不大且希望减少技术栈复杂度的团队。

8.8 对比总结¶

数据库	类型	主要索引	分布式	适用场景
FAISS	库	IVF/PQ/HNSW	否	底层引擎嵌入
Milvus	数据库	IVF/HNSW/SCANN	是	大规模生产
Qdrant	数据库	HNSW	是	高性能低延迟
Weaviate	数据库	HNSW	是	内置 Embedding
Chroma	嵌入式	HNSW	否	原型开发
Pinecone	托管服务	专有	是	零运维
pgvector	扩展	HNSW/IVFFlat	依赖 PG	已有 PG 基础设施

9.如何选择合适的向量数据库¶

选择向量数据库时需要综合考虑以下因素：

9.1 数据规模¶

万到百万级：Chroma、pgvector、Qdrant 单机版即可满足
千万到亿级：Milvus、Qdrant 集群版、Weaviate
十亿级以上：Milvus 分布式、DiskANN 方案

9.2 运维能力¶

零运维：Pinecone、Zilliz Cloud 等全托管服务
有运维能力：Milvus、Qdrant、Weaviate 自建集群
极简部署：Chroma、pgvector（已有 PG 时）

9.3 功能需求¶

需要标量过滤：Milvus、Qdrant、Weaviate、pgvector
需要混合检索：Milvus、Weaviate、Pinecone
需要内置 Embedding：Weaviate
需要 GPU 加速：FAISS、Milvus

9.4 数据合规¶

数据必须本地存储：FAISS、Milvus、Qdrant、Chroma、pgvector（均支持自建）
可接受云端存储：Pinecone、Zilliz Cloud、Qdrant Cloud