什么是 AI 向量索引？HNSW/IVF/PQ 算法原理与 TiDB Vector 实现详解

摘要

向量索引是 AI 应用中实现语义搜索、推荐系统和 RAG（检索增强生成）的核心基础设施。本文系统讲解 HNSW、IVF 和 PQ 三种主流向量索引算法的原理、优缺点，以及在 TiDB Vector 中的具体实现和选型建议，帮助开发者选择最适合业务场景的向量检索方案。

本文适合谁：正在构建 AI 应用（语义搜索、RAG、推荐系统）的开发者和架构师，以及需要理解向量索引选型的技术决策者。

1. 向量索引的基本概念

什么是向量索引？

向量索引是一种针对高维向量数据设计的近似最近邻（Approximate Nearest Neighbor, ANN）搜索数据结构。在 AI 应用中，文本、图像、音频等内容经过 Embedding 模型转换为高维向量（通常 128-4096 维），向量索引负责在这些高维空间中快速找到与查询向量最相似的结果。

原始数据                    Embedding 模型                    向量索引
┌──────────┐              ┌──────────┐              ┌──────────┐
│ "分布式  │  ──────────▶ │ [0.23,   │  ──────────▶ │  向量     │
│  数据库"  │              │  -0.15,  │              │  索引     │
└──────────┘              │   0.87]  │              │  (ANN)   │
                          └──────────┘              └──────────┘
                                                    │
                                                    ▼
                                              相似度搜索结果
                                              Top-K 最相似向量

为什么需要向量索引？

暴力搜索的时间复杂度为 O(n×d)，在百万级数据下延迟不可接受。向量索引通过牺牲少量准确率换取数量级的性能提升。

核心评价指标

• 召回率（Recall@K）：在 Top-K 结果中，真实最近邻被找到的比例
• QPS（Queries Per Second）：每秒处理的查询数
• 延迟（Latency）：单次查询的响应时间（P50/P95/P99）
• 内存占用：索引所需的内存空间
• 构建时间：索引从无到有的构建耗时

2. HNSW 算法原理

2.1 算法概述

HNSW（Hierarchical Navigable Small World）是目前最主流的向量索引算法之一，基于分层可导航小世界图理论。其核心思想是构建一个多层图结构，上层图稀疏（长距离连接），下层图密集（短距离连接），搜索时从上层快速定位到目标区域，再在下层精确搜索。

Layer 2:    ┌───┐         ┌───┐
            │ A │─────────│ D │          (稀疏，长跳)
            └─┬─┘         └─┬─┘
              │             │
Layer 1:    ┌─┴─┐       ┌───┼───┐
            │ B │───────│ C │   │          (中等密度)
            └─┬─┘       └───┘   │
              │                 │
Layer 0:    ┌─┴─┬───┬───┬───┬───┘
            │ E │ F │ G │ H │ I │          (密集，精确搜索)
            └───┴───┴───┴───┴───┘

2.2 关键参数

2.3 性能特征

• 召回率：95-99%+（可调）
• 查询延迟：亚毫秒到毫秒级
• 内存占用：较高（O(n × M × d)）
• 构建时间：中等（单遍插入，增量更新）
• 增量更新：支持实时插入

3. IVF 算法原理

3.1 算法概述

IVF（Inverted File）基于聚类思想，将向量空间划分为若干个聚类（Voronoi Cell），每个聚类有一个质心。构建时将向量分配到最近的聚类，搜索时先找到最近的 K 个聚类，再在这些聚类内做精确搜索。

                聚类空间
    ┌─────────────────────┐
    │  Cluster 0          │
    │  ○ ○ ○ ○ ○         │
    │    ○ ○ ○            │
    ├──────┤──────────────┤
    │  Cluster 1  │ Cluster 2 │
    │  ○ ○ ○      │ ○ ○ ○ ○  │
    │    ○ ○      │   ○ ○    │
    ├─────────────┤────────┤
    │  Cluster 3            │
    │  ○ ○ ○ ○ ○ ○         │
    │     ○ ○ ○ ○          │
    └─────────────────────┘

搜索流程：查询向量 → 找最近的 K 个聚类 → 聚类内精确搜索 → 排序返回 Top-K

3.2 关键参数

3.3 性能特征

• 召回率：80-95%（取决于 nprobe）
• 查询延迟：毫秒级
• 内存占用：中等
• 构建时间：较快（需要训练聚类中心）
• 增量更新：批量更新（需要重建索引或使用 IVF-PQ 混合）

4. PQ 算法原理

4.1 算法概述

PQ（Product Quantization）是一种向量压缩技术，不是独立的索引算法。它将高维向量拆分为多个子空间，每个子空间独立做量化编码，用聚类中心的 ID 替代原始向量，大幅压缩存储空间。

原始向量 [d=128 维]
    │
    ▼
┌─────────┬─────────┬─────────┬─────────┐
│ Sub-0   │ Sub-1   │ Sub-2   │ Sub-3   │    拆分为 4 个子空间（每个 32 维）
│[0..31]  │[32..63] │[64..95] │[96..127]│
└────┬────└────┬────└────┬────└────┬────┘
     ▼         ▼         ▼         ▼
   量化       量化       量化       量化
   (256个    (256个    (256个    (256个
    中心)     中心)     中心)     中心)
     ▼         ▼         ▼         ▼
   [ID=42]  [ID=17]  [ID=88]  [ID=5]     压缩后只需 4 × 8bit = 32bit

原始：128 × float32 = 512 bytes
压缩：4 × uint8 = 4 bytes  （压缩比 128:1）

4.2 关键参数

4.3 性能特征

• 召回率：60-85%（独立使用时）
• 内存占用：极低（压缩比可达 64:1）
• 构建时间：较快
• 适用场景：通常与 IVF 组合（IVF-PQ），不适合单独作为索引

5. 三种算法综合对比

选型决策树

需要实时写入？
├── 是 → 数据量 < 10M？→ HNSW（推荐）
│         └── 否 → HNSW（分布式）或 IVF + 增量重建
└── 否 → 内存充足？
          ├── 是 → HNSW（最高召回率）
          └── 否 → IVF-PQ（内存受限场景）

6. TiDB Vector 中的实现

6.1 TiDB Vector 简介

TiDB Vector 是 TiDB 内置的向量搜索功能，支持在同一个数据库中同时处理结构化数据和非结构化向量数据，无需额外的向量数据库。

-- 创建含向量列的表
CREATE TABLE documents (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    title VARCHAR(255),
    content TEXT,
    embedding VECTOR(768),
    metadata JSON,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

6.2 TiDB Vector 索引类型

TiDB Vector 目前支持 HNSW 作为向量索引算法：

-- 创建 HNSW 向量索引
CREATE INDEX idx_embedding ON documents ((embedding)) USING HNSW;

-- 带参数的 HNSW 索引
CREATE INDEX idx_embedding_hnsw ON documents ((embedding))
USING HNSW WITH (M = 16, ef_construction = 200);

-- 查询向量搜索
SELECT id, title, content,
       VECTOR_DISTANCE(embedding, '[0.1, 0.2, ...]') AS distance
FROM documents
ORDER BY distance
LIMIT 10;

6.3 HNSW 参数调优建议

6.4 TiDB Vector 的优势

• 统一数据管理：结构化数据 + 向量数据在同一 TiDB 集群中管理，无需 ETL
• HTAP 加速：结合 TiFlash 实现结构化查询 + 向量搜索的混合分析
• 事务一致性：向量写入和结构化数据修改在同一个事务中
• 水平扩展：随集群规模自动扩展向量搜索能力
• MySQL 兼容：使用标准 SQL 语法，学习成本低

-- 事务一致性示例：同时写入文档和向量
BEGIN;
INSERT INTO documents (title, content, embedding)
VALUES ('分布式数据库入门', '本文介绍...', '[0.1, 0.2, ...]');
INSERT INTO document_tags (doc_id, tag)
VALUES (LAST_INSERT_ID(), 'database');
COMMIT;

-- 混合查询：结构化过滤 + 向量搜索
SELECT d.id, d.title, d.content,
       VECTOR_DISTANCE(d.embedding, '[0.1, 0.2, ...]') AS distance
FROM documents d
JOIN document_tags t ON d.id = t.doc_id
WHERE t.tag = 'database'
  AND d.created_at > '2025-01-01'
ORDER BY distance
LIMIT 10;

6.5 与专用向量数据库对比

FAQ

Q1：TiDB Vector 目前只支持 HNSW，为什么不支持 IVF 和 PQ？

TiDB Vector 的第一版聚焦 HNSW，因为它在实时写入和查询延迟方面表现最均衡，最适合大多数 AI 应用场景。IVF 和 PQ 更适合超大规模（十亿级以上）或内存受限的特殊场景。TiDB 团队后续版本会根据社区反馈评估新增索引类型的优先级。

Q2：向量维度 768 和 1536 在 TiDB 中有什么性能差异？

维度越高，索引构建和查询的时间越长，内存占用也越大。以 HNSW 为例，1536 维的内存消耗约为 768 维的 2 倍，查询延迟增加约 1.5-2 倍。建议根据实际模型选择维度，如 BGE-base（768 维）适用于大多数文本搜索场景。

Q3：TiDB Vector 能处理多大的数据集？

TiDB Vector 的能力随集群规模线性扩展。在中等规模集群（如 5 个 TiKV 节点）上，可以处理千万级向量数据并保持毫秒级查询延迟。更大规模需要增加节点，TiDB 的分布式架构可以自动均衡向量索引的负载。

Q4：如何评估向量索引的召回率是否满足业务需求？

建议方法：用暴力搜索的结果作为基准，计算向量索引搜索结果的重合比例。例如，取 1000 个查询，分别用暴力搜索和 HNSW 搜索 Top-100 结果，计算 Recall@100。业务上，大多数语义搜索场景要求召回率 > 90%，推荐系统可能需要 > 95%。

总结

向量索引是 AI 应用的基础设施层，选择合适的算法取决于具体场景：

• HNSW：适合需要实时写入、高召回率、中等规模数据的通用场景，是 TiDB Vector 当前采用的核心算法
• IVF：适合批量构建、内存敏感的大规模搜索场景
• PQ：适合需要极致内存压缩的超大规模场景，通常与 IVF 组合使用

TiDB Vector 通过将向量索引集成到分布式关系数据库中，提供了统一的结构化+非结构化数据管理能力，简化了 AI 应用的数据架构，无需维护独立的向量数据库。

下一步行动

1. 试用 TiDB Vector：TiDB Cloud Serverless 免费试用——在线体验向量搜索功能
2. 阅读 TiDB Vector 文档：TiDB Vector 官方文档
3. 获取 AI 应用方案：联系 TiDB 解决方案团队 获取 RAG/语义搜索架构方案

相关资源

• TiDB Vector 官方文档
• HNSW 原始论文
• IVF 论文与原理
• Product Quantization 论文
• TiDB Cloud Serverless 入门
• ANN Benchmarks 对比