Vector Databases

向量数据库是 RAG 系统的核心存储层，专门用于高效存储、检索和管理高维向量数据。它们是 Retrieval Augmented Generation 实际落地的关键基础设施，也是与 Embedding Models / Vector Representations 紧密配套的存储系统。

Definition

向量数据库是为高维向量（dense vector）的快速近似搜索（Approximate Nearest Neighbor, ANN）而优化的数据库系统。与传统关系型数据库或文档数据库不同，它们以 向量相似度 为核心查询语义，而非精确匹配关键词。

核心特征

特征	说明
ANN 检索	在毫秒级内从百万/十亿级向量中找到最相近的 K 个邻居
向量索引	专门的空间索引结构（HNSW、IVF、倒排等）
多模态支持	文本、图像、音频、视频的统一向量表示
扩展性	支持水平扩展以应对十亿级向量
过滤与元数据	向量搜索 + 传统数据库过滤条件的混合查询

ANN 算法与索引类型

HNSW (Hierarchical Navigable Small World)

原理：构建多层图结构，层级越高边越稀疏，从顶层粗糕搜索逐步下沉到底层精确匹配
特点：构建较慢，查询极快，内存占用较大
适用：小到中等规模数据集（< 10M 向量），对查询延迟要求严格的场景
代表：默认算法之一，被 Pinecone、Chroma、Qdrant 等广泛支持

IVF (Inverted File Index)

原理：用 K-Means 将向量空间分区，查询时只搜索最相关的分区
特点：构建快，内存效率高，查询速度比 HNSW 略慢
适用：大规模数据集，对内存敏感的场景
代表：Faiss 的默认策略之一

倒排索引 (Inverted Index)

原理：将向量量化为离散编码，用反向索引快速检索
特点：极快的检索速度，但精度略低
适用：超大规模数据（十亿级），可以损失部分精度换取速度
代表：Milvus、阿里的 Proxima

平面索引（Flat Index）

原理：暴力搜索，计算查询向量与所有向量的距离
特点：100% 精度，但查询时间随数据量线性增长（O(N)）
适用：小规模数据（< 100K）或对精度要求极高的场景

主流向量数据库对比

特性	Pinecone	Chroma	Milvus	Weaviate	pgvector	Qdrant
部署方式	全托管 SaaS	本地/容器/云	自托管/云/集群	自托管/云	PostgreSQL 扩展	自托管/云
开源	闭源	Apache 2.0	Apache 2.0	BSD	PostgreSQL 协议	Apache 2.0
维度限制	无限制	无明确限制	无限制	无限制	16,000	无限制
支持的索引	内部优化	HNSW	HNSW/IVF/倒排	HNSW	HNSW/IVF	HNSW
混合检索	✅	✅	✅	✅	✅	✅
分布式	自动	❌	✅	✅	❌	✅
元数据过滤	✅	✅	✅	✅	✅	✅
适用规模	中大型	小型/原型	超大型	中大型	小到中型	中大型
语言 SDK	Python/JS/Go	Python/JS/TS	多种	Python/JS/Go/Java	SQL	Python/JS/Go/Rust
最大亮点	零运维负担	极简易用	超大规模/高可用	图形搜索/模型即服务	与现有 SQL 生态无缝集成	性能优异/弹性

详细分析

Pinecone

定位：企业级全托管向量数据库
核心优势：零运维负担，自动扩缩，提供高可用性 SLA
缺点：闭源，价格较高，对数据出境控制有限
适用：希望专注于业务逻辑而非基础设施的团队

Chroma

定位：开源向量存储，极简设计哲学
核心优势：设置简单（pip install chromadb），适合原型快速验证
缺点：分布式能力有限，超大规模生产环境需评估
适用：原型开发、小型项目、教学和实验

Milvus / Zilliz

定位：企业级分布式向量数据库
核心优势：支持十亿级向量，云原生架构，高可用
缺点：部署复杂度较高
适用：大规模生产环境，需要水平扩展的场景

Weaviate

定位：AI-原生向量数据库，强调多模态能力
核心优势：内置模型服务（可直接向量化），支持 GraphQL
缺点：学习曲线略高
适用：需要图像搜索或非结构化数据复杂检索的场景

pgvector

定位：PostgreSQL 扩展，将向量能力添加到现有关系数据库
核心优势：与现有 SQL 生态无缝集成，事务支持，成熟的运维工具链
缺点：维度限制 16,000，超大规模时性能可能不如专用向量数据库
适用：已有 PostgreSQL 基础设施的团队，中小规模 RAG 项目

RAG 中的实践指南

传统 RAG 架构

文档 → 分块(Chunking) → [[embedding-models]] → 向量数据库 → ANN 检索 → Top-K 结果 → LLM 生成

分块策略

策略	优点	缺点
固定长度	简单，实现容易	可能拆分上下文
句子级	保留语义完整性	长句可能超出 token 限制
段落级	保留论证结构	长度不均匀
重叠窗口	减少边界信息丢失	储存成本增加
语义分块	根据内容自然分割	需要模型支持，复杂

检索优化技巧

混合检索：密集向量搜索 + 稀疏关键词匹配（BM25）组合，通常比单独使用任何一种方法效果更好
重排序（Reranking）：用轻量级 cross-encoder 对 Top-K 结果重新排序，显著提升准确性
查询增强：将原始查询扩展为多个相关查询（query expansion）以提高召回率
索引更新策略：定期重建 vs 增量更新，根据数据变化频率决定
中文优化：使用适合中文的 embedding 模型（如 BGE、GTE、multilingual-E5）

比较：向量数据库 vs 传统搜索

维度	向量数据库	传统搜索（Elasticsearch等）
匹配方式	语义相似度	关键词匹配 / 候选词
理解同义词	✅ 天然支持	❌ 需要同义词典
跨语言检索	✅ 多语言 embedding 可以	❌ 难以实现
精确匹配	❌ 近似搜索	✅ 精确匹配
复杂查询语法	❌ 有限	✅ 丰富
数值/范围过滤	❌ 通常需要混合	✅ 天然支持
最佳实践	语义搜索、RAG	结构化数据、日志分析

关键观点：实际生产环境中，最好的方案通常是 向量搜索 + 关键词过滤的混合（如 Milvus 的 hybrid search、pgvector 的多列过滤）。

Relationships

相关概念：Retrieval Augmented Generation、Embedding Models / Vector Representations、Model Inference & Deployment、AI Agents
相关工具：Llama（本地嵌入）、Model Quantization（向量量化）
与其他概念的关联：向量数据库是实现 Retrieval Augmented Generation 的必要基础设施

Open Questions

向量数据库是否会被传统数据库（PostgreSQL + pgvector、MySQL 向量扩展）吞并，还是保持独立品类？
随着 LLM 上下文窗口增长（1M tokens），RAG 的必要性是否会减弱？向量数据库的存在价值如何变化？
向量数据库如何更好地支持多模态数据（图像、视频、音频的统一管理）？
在极端规模（十亿级向量）下，哪种索引算法和架构是最终胜出者？

Vector Databases ​

Definition ​

核心特征 ​

ANN 算法与索引类型 ​

HNSW (Hierarchical Navigable Small World) ​

IVF (Inverted File Index) ​

倒排索引 (Inverted Index) ​

平面索引（Flat Index） ​

主流向量数据库对比 ​

详细分析 ​

Pinecone ​

Chroma ​

Milvus / Zilliz ​

Weaviate ​

pgvector ​

RAG 中的实践指南 ​

传统 RAG 架构 ​

分块策略 ​

检索优化技巧 ​

比较：向量数据库 vs 传统搜索 ​

Relationships ​

Open Questions ​