向量数据库在 RAG 系统中的应用:从 pgvector 到 Milvus、Qdrant
RAG 系统里的向量数据库负责语义召回,但真正的效果取决于切分、Embedding、索引、元数据过滤、重排和更新链路。
向量数据库在 RAG 系统中的应用:从 pgvector 到 Milvus、Qdrant
RAG 是 Retrieval-Augmented Generation,检索增强生成。它的基本思路是:不要只让大模型依赖训练参数,而是在回答前先从知识库里检索相关内容,再把检索结果交给模型生成答案。
向量数据库在这里负责语义检索。它把文本、图片或其他内容的 Embedding 存起来,通过相似度搜索找到最相关的片段。
向量数据库存什么
一条向量记录通常不只包含向量,还包含原文片段和元数据。
{
"id": "doc_10001_chunk_03",
"embedding": [0.012, -0.034, 0.221],
"text": "PostgreSQL 使用 MVCC 支持并发控制...",
"metadata": {
"doc_id": "doc_10001",
"source": "database-notes",
"chapter": "postgresql",
"updated_at": "2026-05-17"
}
}
元数据非常重要。真实 RAG 往往需要按租户、权限、文档类型、时间范围过滤,而不是在全库里盲搜。
pgvector:先从 PostgreSQL 开始
如果知识库规模不大,业务系统本来就用 PostgreSQL,pgvector 是很务实的起点。
CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE documents (
id BIGSERIAL PRIMARY KEY,
tenant_id BIGINT NOT NULL,
content TEXT NOT NULL,
embedding vector(1536)
);
CREATE INDEX idx_documents_embedding
ON documents USING hnsw (embedding vector_cosine_ops);
SELECT id, content
FROM documents
WHERE tenant_id = 10001
ORDER BY embedding <=> '[0.01,0.02,0.03]'::vector
LIMIT 5;
pgvector 的优势是架构简单,关系数据和向量数据可以放在一起。缺点是当向量规模、并发和召回性能要求上来后,可能需要专用向量数据库。
Milvus、Qdrant、Weaviate
Milvus、Qdrant、Weaviate 这类系统更专注向量检索。它们通常提供更完整的向量索引、集合管理、过滤能力、分布式扩展和向量检索 API。
如果你的知识库很大、召回 QPS 高、需要多租户隔离和在线更新,专用向量数据库会更合适。
选型时不要只看“能不能存向量”,还要看:
- 元数据过滤能力。
- 索引构建速度。
- 更新和删除成本。
- 召回率与延迟。
- 备份恢复。
- 多租户权限。
- SDK 和运维成熟度。
Chunk 切分比数据库更影响效果
很多 RAG 效果差,不是向量数据库选错了,而是文档切分不合理。
Chunk 太小,上下文不完整。Chunk 太大,召回噪声多,也浪费上下文窗口。
常见做法是按标题、段落、语义边界切分,并保留重叠窗口。代码文档还要按函数、类、模块切分。
混合检索
纯向量检索擅长语义相似,但对精确关键词、编号、错误码不一定好。
因此很多系统会使用混合检索:
- BM25 / 全文检索召回关键词相关内容。
- 向量检索召回语义相关内容。
- 重排模型对候选结果重新排序。
数据库领域的问答尤其适合混合检索。比如用户问 “ERROR 1062”,关键词比语义更重要。
更新和权限
RAG 知识库不是一次导入就结束。文档会更新、删除、改权限。
因此向量库要支持:
- 文档版本。
- 增量更新。
- 删除旧 chunk。
- 权限过滤。
- Embedding 重建。
权限过滤一定要在检索阶段做,不能等召回后再随便过滤,否则可能出现越权内容进入上下文。
小结
向量数据库是 RAG 的召回层,但不是全部。
RAG 效果取决于文档切分、Embedding 模型、索引类型、元数据过滤、混合检索、重排和更新链路。
小规模系统可以从 PostgreSQL + pgvector 开始。规模和性能要求上来后,再评估 Milvus、Qdrant、Weaviate 这类专用向量数据库。