> For the complete documentation index, see [llms.txt](https://yeasy.gitbook.io/context_engineering_guide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://yeasy.gitbook.io/context_engineering_guide/di-er-bu-fen-he-xin-ji-shu-yu-ce-le/04_write/4.4_vector_database.md).

# 4.4 向量数据库实践

## 4.4.1 向量数据库概述

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

工作原理：

1. 将文本通过嵌入模型转换为向量（详见 [5.3 嵌入模型与语义搜索](/context_engineering_guide/di-er-bu-fen-he-xin-ji-shu-yu-ce-le/05_select/5.3_embeddings.md)）
2. 将向量存储到向量数据库
3. 查询时，将查询文本也转换为向量
4. 在数据库中搜索最相似的向量
5. 返回对应的原始文本

## 4.4.2 主流向量数据库对比

| 产品                         | 类型      | 特点               | 适用场景        |
| -------------------------- | ------- | ---------------- | ----------- |
| Pinecone                   | 云服务     | serverless、易用    | 快速启动、中小规模   |
| Weaviate                   | 开源/云    | 模块化、GraphQL      | 复杂查询需求      |
| Milvus                     | 开源      | 高性能、云原生          | 大规模生产环境     |
| Qdrant                     | 开源      | Rust 实现、高性能      | 性能敏感场景      |
| Chroma                     | 开源/云    | 本地体验简单、面向 RAG 原型 | 快速原型与中小规模应用 |
| LanceDB                    | 开源/云    | 列式存储、向量/全文/混合检索  | 多模态数据与湖仓场景  |
| PostgreSQL                 | 融合数据库   | pgvector、生态成熟    | 业务数据与向量共存   |
| Elasticsearch / OpenSearch | 搜索引擎    | 向量检索、全文检索与过滤聚合共存 | 已有搜索基础设施    |
| Redis                      | 内存数据库/云 | 低延迟向量搜索、缓存一体化    | 在线推荐与实时检索   |
| 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 系列 | 变化      | 本地部署与快速实验    |

选择考虑：

* 质量需求
* 成本预算
* 是否需要本地部署
* 语言支持

### 文档分块策略

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

```mermaid
graph LR
    A["原始文档"] --> B["分块处理"]
    B --> C["语义块"]
    C --> D["向量化"]
    D --> E["索引存储"]
```

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

分块要点：

* 语义完整性：尽量保持语义单元完整
* 大小适中：通常 200-1000 Token
* 适当重叠：防止信息断裂
* 保留元数据：来源、章节、时间等

### 检索优化

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

**混合检索**

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

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

**元数据过滤**

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

* 按时间范围过滤
* 按类别过滤
* 按来源过滤

**重排序**

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

* 使用专门的重排序模型
* 考虑更多上下文因素

## 4.4.5 实际部署考量

### 性能优化

* **批量操作**：批量写入和批量查询
* **缓存策略**：缓存热点查询结果
* **索引预热**：提前加载索引到内存

### 扩展性

* **分片策略**：数据量大时的分片方案
* **副本配置**：高可用和读扩展
* **容量规划**：预估存储和计算需求

### 成本控制

* **向量维度**：较小的维度降低存储和计算成本
* **压缩技术**：使用量化减少存储
* **冷热分离**：不常用数据使用低成本存储

## 4.4.6 常见问题处理

**1. 检索结果不相关**

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

* **解决方案**：
  * 检查嵌入模型是否适合当前领域的专有名词。
  * 优化分块策略，增加块之间的重叠，或尝试父子文档索引。
  * 引入混合检索（Hybrid Search），结合关键词匹配来纠正语义漂移。
  * 添加重排序（Reranking）步骤，使用高精度模型对召回结果进行二次筛选。

**2. 检索延迟过高**

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

* **解决方案**：
  * 调整索引参数，如 HNSW 的 `efSearch`，在精度和速度间寻找平衡。
  * 使用更高效的索引算法，或者开启量化（如 SQ8, PQ）以减少内存占用和计算量。
  * 考虑硬件升级，使用 GPU 加速索引或查询。
  * 实现分片（Sharding），将数据分布到多台机器并行查询。

**3. 更新导致不一致**

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

* **解决方案**：
  * 实现实时增量更新机制，源数据变更立即触发嵌入更新。
  * 设计合理的版本控制策略，在重建索引期间保留旧版本查询。
  * 定期全量重建索引，以消除增量更新产生的碎片，优化索引结构。