4.4 向量数据库实践

4.4.1 向量数据库概述

向量数据库 是专门优化用于存储和检索高维向量的数据库系统。在上下文工程中，向量数据库是实现语义检索的核心基础设施。

工作原理：

1. 将文本通过嵌入模型转换为向量（详见 5.3 嵌入模型与语义搜索）

2. 将向量存储到向量数据库

3. 查询时，将查询文本也转换为向量

4. 在数据库中搜索最相似的向量

5. 返回对应的原始文本

4.4.2 主流向量数据库对比

产品	类型	特点	适用场景
Pinecone	云服务	serverless、易用	快速启动、中小规模
Weaviate	开源/云	模块化、GraphQL	复杂查询需求
Milvus	开源	高性能、云原生	大规模生产环境
Qdrant	开源	Rust 实现、高性能	性能敏感场景
PostgreSQL	融合数据库	pgvector、生态成熟	业务数据与向量共存
Oracle 23ai	融合数据库	原生向量、企业级	核心业务系统
MySQL	融合数据库	HeatWave、普及度高	现有 MySQL 用户

4.4.3 向量索引算法

向量搜索因为数据量大、维度高，无法像传统数据库那样通过简单的比较来查找。其核心是 近似最近邻搜索（Approximate Nearest Neighbor, ANN），即在牺牲极小精度的情况下，换取检索速度的指数级提升。

以下是三种最主流的算法原理详解：

1. HNSW

HNSW（Hierarchical Navigable Small World，分层可导航小世界图）是目前综合性能最强的近似最近邻索引之一，结合了“小世界网络”和“分层结构”的思想。

原理机制： 想象一个多层的交通网络：

• 顶层（高速公路）：节点稀疏，连接跨度大，用于快速逼近目标区域。

• 中间层（主干道）：节点较多，连接跨度适中，用于缩小搜索范围。

• 底层（街道）：包含所有节点，连接密集，用于精确定位目标。

搜索过程：

1. 从顶层的一个入口节点开始。

2. 在当前层贪婪地寻找距离目标最近的节点。

3. 找到该层最近点后，“降落”到下一层对应的节点。

4. 重复步骤 2-3，直到到达底层（第 0 层）。

5. 在底层进行最终的精细搜索，找到最近邻。

特点：

• 优点：检索速度极快，查全率（Recall）高，对高维数据适应性好。

• 缺点：构建索引慢，且需要将整个图结构加载到内存，内存消耗大。

• 关键参数：

• M：每个节点的最大连接数（邻居数）。M 越大图越密，搜索质量越高但内存消耗越大。

  • efConstruction：构建索引时的搜索深度。值越大索引质量越好，但构建越慢。

  • efSearch：查询时的搜索深度。值越大召回率越高，但查询延迟增加。

2. IVF

IVF（Inverted File Index，倒排文件索引）是一种基于聚类的倒排索引方法，类似于将数据分桶存储。

原理机制：

1. 训练阶段：使用聚类算法（如 K-means）将向量空间划分为 nlist 个聚类中心（Voronoi 单元）。

2. 索引阶段：将每个向量分配到距离其最近的聚类中心，归入对应的倒排链中。

3. 查询阶段：

   • 粗搜（Coarse Quantizer）：先计算查询向量与所有聚类中心的距离，找到最近的 nprobe 个聚类中心。

   • 精搜：仅在选中的这几个聚类对应的倒排链中进行遍历搜索，忽略其他无关数据。

特点：

• 优点：大大减少了搜索范围，支持增量更新，内存占用相对较低。

• 缺点：如果在边界处的点可能被漏掉（通过增加 nprobe 缓解）。

• 关键参数：

  • nlist：聚类中心的数量。

  • nprobe：查询时扫描的聚类数量。nprobe 越大，精度越高，速度越慢。

3. PQ

PQ（Product Quantization，乘积量化）是一种有损压缩技术，主要用于解决内存占用问题。

原理机制：

1. 切分：将高维向量（如 128 维）切分为 $M$ 个子向量（如 8 个 16 维的子向量）。

2. 聚类：对每个子空间分别进行 K-means 聚类（例如每个子空间聚成 256 类）。

3. 量化：将每个子向量替换为它所属聚类中心的 ID（只需 1 byte）。

4. 压缩：原始 128 浮点数向量（512 bytes）被压缩为 8 个 ID（8 bytes），压缩比高达 64x。

5. 查询：查询时，预先计算查询向量各子段与各聚类中心的距离表，通过查表快速计算近似距离。

特点：

• 优点：极大地降低内存占用（通常可达几十倍压缩），使得单机可处理十亿级数据。

• 缺点：距离计算是近似值，存在精度损失。通常与 IVF 结合使用（IVF-PQ）以从海量数据中快速筛选。

4.4.4 向量数据库使用实践

嵌入模型选择

嵌入模型决定语义搜索的质量：

模型（示例）	维度（示意）	特点
商用通用嵌入模型	常见为千级维度	成本/效果平衡，生态成熟
商用高精度嵌入模型	常见为更高维度	精度更高，成本与延迟更高
领域嵌入模型	变化	在特定领域可能更稳健
开源多语言嵌入模型	变化	便于本地部署与可控性
sentence-transformers 系列	变化	本地部署与快速实验

选择考虑：

• 质量需求

• 成本预算

• 是否需要本地部署

• 语言支持

文档分块策略

良好的分块策略直接影响检索效果：

图 4-6：文档分块与索引构建流程

分块要点：

• 语义完整性：尽量保持语义单元完整

• 大小适中：通常 200-1000 Token

• 适当重叠：防止信息断裂

• 保留元数据：来源、章节、时间等

检索优化

提升检索效果的实用技术：

混合检索

结合向量搜索和关键词搜索：

最终得分 = α × 语义得分 + (1-α) × 关键词得分

元数据过滤

先按元数据过滤，再在子集中向量搜索：

• 按时间范围过滤

• 按类别过滤

• 按来源过滤

重排序

对初步检索结果进行二次排序：

• 使用专门的重排序模型

• 考虑更多上下文因素

4.4.5 实际部署考量

性能优化

• 批量操作：批量写入和批量查询

• 缓存策略：缓存热点查询结果

• 索引预热：提前加载索引到内存

扩展性

• 分片策略：数据量大时的分片方案

• 副本配置：高可用和读扩展

• 容量规划：预估存储和计算需求

成本控制

• 向量维度：较小的维度降低存储和计算成本

• 压缩技术：使用量化减少存储

• 冷热分离：不常用数据使用低成本存储

4.4.6 常见问题处理

1. 检索结果不相关

通常是由于语义偏差或分块不当导致。

• 解决方案：

  • 检查嵌入模型是否适合当前领域的专有名词。

  • 优化分块策略，增加块之间的重叠，或尝试父子文档索引。

  • 引入混合检索（Hybrid Search），结合关键词匹配来纠正语义漂移。

  • 添加重排序（Reranking）步骤，使用高精度模型对召回结果进行二次筛选。

2. 检索延迟过高

随着数据量增长，暴力搜索变得不可接受。

• 解决方案：

  • 调整索引参数，如 HNSW 的 efSearch，在精度和速度间寻找平衡。

  • 使用更高效的索引算法，或者开启量化（如 SQ8, PQ）以减少内存占用和计算量。

  • 考虑硬件升级，使用 GPU 加速索引或查询。

  • 实现分片（Sharding），将数据分布到多台机器并行查询。

3. 更新导致不一致

向量更新滞后于源数据更新。

• 解决方案：

  • 实现实时增量更新机制，源数据变更立即触发嵌入更新。

  • 设计合理的版本控制策略，在重建索引期间保留旧版本查询。

  • 定期全量重建索引，以消除增量更新产生的碎片，优化索引结构。