Skip to content

4.4_vector_database.md

Latest commit

 

History

History
204 lines (151 loc) · 8.67 KB

4.4_vector_database.md

File metadata and controls

204 lines (151 loc) · 8.67 KB

4.4 向量数据库实践

4.4.1 向量数据库概述

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

工作原理：

  1. 将文本通过嵌入模型转换为向量（详见 5.3 嵌入模型与语义搜索）
  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 系列 变化 本地部署与快速实验

选择考虑：

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

文档分块策略

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

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

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

分块要点：

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

检索优化

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

混合检索

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

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

元数据过滤

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

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

重排序

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

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

4.4.5 实际部署考量

性能优化

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

扩展性

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

成本控制

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

4.4.6 常见问题处理

1. 检索结果不相关

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

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

2. 检索延迟过高

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

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

3. 更新导致不一致

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

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