向量数据库选型与 RAG 架构实践：从原型到生产

RAG Pipeline 全链路概览

检索增强生成（RAG）的核心思路是让大语言模型不再"凭记忆回答"，而是从你的私有知识库里实时检索相关内容，再基于检索结果生成回答。一条完整的 RAG Pipeline 包含六个关键环节：

1. 文档加载（Document Loading）：从 PDF、Word、网页、数据库等异构数据源中抽取原始文本
2. 分块（Chunking）：将长文档切分为适合嵌入和检索的片段
3. 向量嵌入（Embedding）：将文本片段转换为高维向量表示
4. 向量存储（Vector Storage）：将向量写入向量数据库并建立索引
5. 检索（Retrieval）：根据用户查询检索最相关的向量片段
6. LLM 生成（Generation）：将检索结果注入 Prompt，由大模型生成最终回答

每个环节的选择都会直接影响最终效果。下面逐一拆解关键决策点。

分块策略：粒度决定召回上限

分块是最容易被低估的环节。块太大会稀释语义焦点，块太小又会丢失上下文。

推荐实践：

• 默认采用 256-512 token 的块大小，这是大多数 embedding 模型的最佳语义窗口
• 相邻块之间保留 50-100 token 的重叠（overlap），避免关键信息恰好被切断在两个块的边界
• 对结构化文档（如技术文档），优先按标题层级做语义分块，而非按固定字符数切割
• 在元数据中保留块的来源文件名、页码、标题路径，后续做 metadata filtering 时会用到

一个常见的失败模式是：团队花大量精力选 embedding 模型，却对分块策略草草了事，结果召回率始终上不去。分块质量的天花板，决定了整个 RAG 系统的天花板。

Embedding 模型选择

Embedding 模型将文本映射到向量空间，模型选择直接影响语义检索的准确性。当前主流选项包括：

• text-embedding-3-small：OpenAI 提供，开箱即用，性价比高，适合快速验证
• BGE-M3：支持多语言、多粒度，同时产出稠密向量和稀疏向量，在中文场景下表现优异
• Jina Embeddings：支持超长文本输入，对长文档场景友好

关键建议： 选定 embedding 模型后不要轻易更换——不同模型生成的向量不在同一空间，切换模型意味着全量重新 embedding。建议在项目初期用多种模型做 A/B 测试，对比不同分块策略下的召回率（Recall@K）后再做最终决定。

四大向量数据库横向对比

向量数据库是 RAG 系统的存储与检索引擎。当前市场上主要有四个值得关注的选择：

Milvus

Milvus 采用 Go/C++ 开发，架构上天生为分布式设计。它支持 IVF、HNSW、FLAT 等多种索引类型，能够处理数十亿级别的向量数据。目前 Milvus 占据约 28% 的企业级市场份额，是超大规模场景的首选。

• 适合场景： 数据量达到亿级、需要水平扩展、对索引类型有精细化需求
• 注意点： 运维复杂度较高，小团队需要投入专门的基础设施维护

Qdrant

Qdrant 由 Rust 编写，以高性能和低延迟著称。它原生支持稠密向量与稀疏向量的混合存储，同时提供 RESTful 和 gRPC 两种 API。Qdrant 与 LangChain、LlamaIndex 等主流框架深度集成，市场份额约 15%。

• 适合场景： 对延迟敏感的生产环境、需要同时使用稠密+稀疏向量
• 注意点： 社区生态相比 Milvus 稍小，但增长迅速

Weaviate

Weaviate 采用 Go 开发，定位为 AI-Native 数据库。它的特色是内置了多模态支持（文本、音频、视频），并预集成了向量化模块和 RAG 模块。Weaviate 原生支持混合搜索（向量 + 关键词），市场份额约 12%。

• 适合场景： 多模态检索、希望开箱即用获得混合搜索能力
• 注意点： "魔法"多但黑盒也多，深度定制时可能受限

pgvector

pgvector 是 PostgreSQL 的扩展模块，延续了 PostgreSQL 的 ACID 事务特性。如果你的团队已经在用 PostgreSQL，pgvector 几乎是最低成本的入门选择，市场份额约 22%。

• 适合场景： 已有 PostgreSQL 基础设施、数据量在百万级以内、需要事务一致性
• 注意点： 超大规模下的性能不如专用向量数据库

索引类型：性能与精度的权衡

向量数据库的索引类型直接决定了查询速度和召回精度之间的平衡：

• HNSW（Hierarchical Navigable Small World）：召回率高，查询快，但内存占用大。适合对精度要求高、内存预算充足的场景
• IVF（Inverted File Index）：通过聚类将向量分区，在速度和内存之间取得平衡。适合中等规模、资源有限的场景
• FLAT（暴力搜索）：逐一比较所有向量，结果精确但速度最慢。仅适合小数据量的基线测试或对召回率要求 100% 的场景

实践建议： 从 HNSW 开始，它在大多数场景下提供最佳的性价比。如果内存紧张，再考虑 IVF。FLAT 仅用于验证其他索引的召回率是否达标。

检索策略：从单一到融合

检索策略决定了用户查询和知识库之间的匹配质量，这是 RAG 效果最直接的杠杆。

纯向量检索

最简单的策略，将用户查询 embedding 后直接做最近邻搜索。适合语义匹配为主、对关键词精确匹配要求不高的场景。

混合检索（Hybrid Search）

同时执行向量检索和 BM25 关键词检索，再将两路结果合并。Weaviate 原生支持这种模式，其他数据库可以通过应用层实现。

混合检索适合同时存在语义匹配和精确关键词匹配需求的场景——例如，用户既可能问"如何优化查询性能"，也可能直接搜"ERROR 1045"这样的错误码。

RAG-Fusion

RAG-Fusion 引入倒数排名融合（Reciprocal Rank Fusion）算法，对多个检索结果列表进行重新排序：

def reciprocal_rank_fusion(results_list, k=60):
    """将多路检索结果用 RRF 算法融合"""
    fused_scores = {}
    for results in results_list:
        for rank, doc in enumerate(results):
            if doc not in fused_scores:
                fused_scores[doc] = 0
            fused_scores[doc] += 1 / (k + rank + 1)
    return sorted(fused_scores.items(), key=lambda x: x[1], reverse=True)

这种策略在多轮对话和复杂查询场景下表现显著优于单一检索。

Reranking：最后 10-20% 的精度提升

在初步检索之后加入 Reranking 阶段，可以用 Cross-Encoder 模型对候选结果重新打分排序。例如使用 BGE-Reranker 等模型，通常能将精度提升 10-20%。

代价是额外的推理延迟——reranker 需要对每个候选对（query + document）做逐对计算。生产环境中的常见做法是：先用向量检索召回 Top-50，再用 reranker 精排到 Top-5，这样在精度和延迟之间取得平衡。

从原型到生产的升级路径

很多团队在原型阶段选择 Chroma 这样的轻量级方案，这完全没问题。但当数据量增长、并发提升时，就需要规划清晰的升级路径：

1. 原型期（数据量 < 100 万条）：Chroma 或 pgvector 足够，重点验证分块策略和检索效果
2. 成长期（100 万 - 1000 万条）：迁移到 Qdrant 或 Weaviate，引入混合检索和 Reranking
3. 规模期（1000 万 - 10 亿条）：评估 Milvus 的分布式架构，按业务域做数据分片

每一步迁移前，务必做好基准测试——用真实数据和真实查询测试召回率、延迟和成本，不要仅凭文档参数做决策。

生产环境监控要点

RAG 系统上线后，需要持续监控以下指标：

• P99 延迟：从用户发起查询到收到回答的端到端延迟，直接决定用户体验
• Recall@K：Top-K 检索结果中包含正确答案的比例，是检索质量的核心指标
• 成本：包括 embedding API 调用费用、向量数据库的计算和存储费用

成本优化手段：

• 对向量做量化（Quantization），将 float32 压缩为 int8 或 binary，大幅降低存储和内存开销
• 结合使用稀疏向量（如 BGE-M3 的稀疏输出），在混合检索中用稀疏向量替代传统的 BM25，减少维护成本
• 对冷数据做分级存储，热数据常驻内存，冷数据落盘

常见失败模式与避坑指南

根据实际项目经验，RAG 系统效果不佳通常归结为以下几个原因：

• 分块大小不当：块太大导致检索结果语义模糊，块太小导致上下文缺失。务必针对具体数据做分块参数调优
• Embedding 模型与业务不匹配：通用模型在垂直领域（如医疗、法律、金融）可能表现不佳，考虑用领域语料微调
• 缺少 metadata filtering：没有利用文档来源、时间、类型等元数据做预过滤，导致检索结果中混入不相关的内容
• 没有 Reranking 阶段：仅靠向量检索的排序结果直接送入 LLM，损失了精排带来的精度增益
• 忽略评估闭环：上线后没有建立持续的评估机制，无法量化每次调整的实际效果

决策框架：三步选定你的向量数据库

最后，给出一个简明的决策框架：

1. 还在验证想法？ → 选 Chroma，快速启动，专注在分块和检索策略的调优上
2. 团队已有 PostgreSQL？ → 先试 pgvector，零额外基础设施成本
3. 需要混合搜索能力？ → 选 Weaviate，开箱即用的向量+关键词混合检索
4. 对延迟极其敏感且有一定规模？ → 选 Qdrant，Rust 带来的性能优势在高并发下尤为明显
5. 数据量达到十亿级？ → 选 Milvus，原生分布式架构是这个规模下的刚需

RAG 不是"选个数据库就完事"的工程。它是一条从数据处理到检索优化再到持续迭代的完整链路。选对工具只是起点，真正的差异化来自于对每个环节的精细打磨。