当前主流 RAG 架构全景及轻量级向量库选型深度分析

第一部分：RAG 架构演进与主流范式

一、RAG 三代演进：Naive → Advanced → Modular

1. Naive RAG（朴素 RAG）

最原始的"检索→生成"管线：

用户查询 → Embedding → 向量库检索 top-k → 原文片段拼接到 prompt → LLM 生成回答

核心缺陷：

• 检索缺失：检索到的片段与问题无关
• 幻觉：LLM 超出检索上下文编造内容
• 冗余：重叠片段浪费上下文窗口
• 无质量闭环：不对检索结果做任何验证

2. Advanced RAG（进阶 RAG）

在 Naive RAG 基础上增加了检索前优化 + 检索后优化两层：

┌─────────────────────────────────────────────────────────┐ │ 检索前优化层 │ │ ├─ Query Rewriting（查询改写） │ │ ├─ Query Decomposition（查询分解） │ │ ├─ HyDE（假设性文档嵌入） │ │ ├─ Step-back Prompting（退步提问） │ │ └───────────────────────────────────────────────── │ │ 混合检索层 │ │ ├─ BM25（关键词精确匹配） │ │ ├─ Dense Embedding（语义稠密匹配） │ │ ├─ RRF 融合（Reciprocal Rank Fusion） │ │ └───────────────────────────────────────────────── │ │ 检索后优化层 │ │ ├─ Cross-Encoder Reranking（交叉编码器重排序） │ │ ├─ Context Compression（上下文压缩） │ │ ├─ Filtering（过滤无关片段） │ │ └───────────────────────────────────────────────── │ │ 生成层 │ │ ├─ Self-correction loops（自我纠错循环） │ │ ├─ Citation grounding（引用归因） │ │ └───────────────────────────────────────────────── │ └─────────────────────────────────────────────────────────┘

关键改进：Reranking 单独就能将精度提升 10-30%，已成为生产标配。

3. Modular RAG（模块化 RAG）

当前/未来阶段——RAG 被拆解为可插拔组件（searcher、reranker、reader、filter、generator），可自由组装为不同架构，无固定管线顺序：

二、索引策略演进

传统索引

• 固定长度分块（naive chunking）
• 递归字符分块（RecursiveCharacterTextSplitter）

现代索引（2025 生产级）

三、主流检索策略详解

混合检索（Hybrid Search）——生产标配

用户查询 ─┬─ BM25 关键词检索 → 排序列表 A └─ Dense Embedding 语义检索 → 排序列表 B └───────────────────────────── └─ RRF (Reciprocal Rank Fusion) 融合 → 最终排序

为什么是标配？BM25 捕获精确匹配（产品编号、人名、术语），Dense Embedding 捕获语义匹配（“天气"匹配"气温”）。单独使用任一种都有盲区。

Reranking——精度提升核心

两阶段管线：先粗检索 top-50-100，再用 Cross-Encoder 精排到 top-5-10。

主流 Reranker：

查询变换策略

四、新范式 RAG（2024-2026 前沿）

1. Graph RAG（微软 GraphRAG）

用知识图谱替代扁平向量库：

原始文档 → LLM 提取实体+关系 → 构建社区级知识图谱 → 全局摘要查询 → 传统向量 RAG 无法回答的全局性问题

核心价值：传统向量 RAG 只擅长局部片段检索，对"这篇文档的整体主题是什么"这类全局性问题束手无策。GraphRAG 通过社区检测和层级摘要解决此问题。

适用场景：法律、医疗、金融等结构化实体关系密集的领域。Neo4j、Weaviate、LlamaIndex 都在集成图谱能力。

2. Agentic RAG——2025 主导范式

RAG 被嵌入到自主 Agent 循环中，检索成为 Agent 众多工具之一：

┌─────────────────────────────────────────────────────────┐ │ Agent Loop │ │ ├─ 规划：决定是否需要检索、检索什么 │ │ ├─ 工具调用：检索 / 代码执行 / API调用 / Web搜索 │ │ ├─ 评估：判断检索结果是否充分 │ │ ├─ 纠错：不够则改写查询重新检索 │ │ └─ 生成：整合所有信息生成最终回答 │ └─────────────────────────────────────────────────────────┘

与 Claude Agent SDK 的天然契合：Agent SDK 的 observe-decide-act 循环正是 Agentic RAG 的理想载体——检索只是 Agent 可调用的一个 Tool。

三种 Agentic RAG 子模式：

• Router Agent：决定查询哪个检索源（向量库 vs SQL vs Web）
• Corrective RAG Agent：评估检索质量，不够则触发纠错路径
• Multi-Agent RAG：不同 Agent 专门处理不同数据源

3. Self-RAG（自我反思 RAG）

LLM 自我反思，按段落插入反思 token：

核心优势：比"总是检索"更高效——模型自主决定何时需要外部知识，何时依靠自身知识即可。

4. CRAG（纠错 RAG）

在检索后增加纠错门控：

检索结果 → 检索评估器评分 → 三条路径 ├─ Correct（相关）→ 直接生成 ├─ Ambiguous（模糊）→ 改写查询 + Web搜索补充检索 └─ Incorrect（无关）→ 丢弃 + 完全依赖 Web搜索

核心价值：使 RAG 对坏检索具有韧性。LangGraph 有官方 CRAG 教程实现。

5. FLARE（前瞻式主动检索）

模型主动生成，遇到低置信度 token（通过 token 概率衡量）时暂停，从上下文构造查询、检索、恢复生成：

生成中 → 遇到低置信度片段 → 暂停 → 构造查询 → 检索 → 恢复生成

避免过度检索和不足检索。其思想正在被 Agentic RAG 吸收。

6. Speculative RAG（推测式 RAG，Google DeepMind 2024-2025）

Draft-then-verify 方法：

• 小型专用模型并行生成候选答案
• 大型验证模型评估哪个候选最佳
• 降低延迟、提高精度、节省成本

7. Adaptive RAG（自适应 RAG）

按查询复杂度动态路由检索策略：

查询 → 复杂度分类器 → ├─ 简单 → 直接生成（无检索） ├─ 中等 → 单轮检索 └─ 复杂 → 多跳检索 + 查询分解

8. 多模态 RAG（2025 前沿）

超越文本，扩展到图像、视频、音频、表格：

五、RAG 评估框架

RAGAS（事实标准，v0.2+）

其他框架

2025-2026 新兴评估方向

• 从静态基准 → 动态生产监控管线
• 从单轮指标 → 多轮/Agentic 评估
• 从 LLM-as-judge → 混合（LLM + 人类 + 统计方法）
• 从仅看精度 → 精度 + 成本 + 延迟 + 鲁棒性权衡
• CI/CD 式评估管线（每次 prompt/模板变更自动评估）

第二部分：轻量级向量库选型深度分析

六、轻量级向量库全景概览

为什么关注轻量级？

2025-2026 的核心趋势：小型项目不应部署独立服务的重方案（Milvus/Weaviate/Pinecone），而应优先考虑嵌入式方案。

理由：

• 部署运维负担：Milvus 需要 etcd+MinIO+Pulsar，Weaviate 需要 Docker
• 成本：小型项目不需要分布式能力
• 延迟：嵌入式方案避免网络往返
• 便携性：嵌入式方案可打包到应用中随走随用

“向量数据库的 SQLite 时刻”

2025 年社区共识：向量数据库正在经历与关系型数据库相同的演化路径——从重型服务到嵌入式库。

关系型数据库演进： Oracle/MySQL (服务) → SQLite (嵌入式) → 全球无处不在 向量数据库正在走同样路径： Milvus/Weaviate/Pinecone (服务) → LanceDB/sqlite-vec (嵌入式) → ?

七、六大轻量级向量库详解

1. LanceDB——“向量数据库的 SQLite”

架构核心

┌─────────────────────────────────────────────────────────┐ │ LanceDB 架构 │ ├─────────────────────────────────────────────────────────┤ │ Lance 列式格式（替代 Parquet，专为向量优化） │ │ ├─ O(1) 随机行访问（Parquet 是 O(n)） │ │ ├─ 增量追加无需重写全量数据 │ │ ├─ 自动数据版本化 │ │ └───────────────────────────────────────────────── │ │ IVF-PQ 索引（主要 ANN 算法） │ │ ├─ IVF：向量分桶，搜索时只探测相关桶 │ │ ├─ PQ：向量压缩（128维 float32 → 32-64 bytes） │ │ ├─ PQ codebook 在内存，实际向量数据在磁盘 │ │ └───────────────────────────────────────────────── │ │ 磁盘优先架构 │ │ ├─ 不需要将全量数据加载到内存 │ │ ├─ 异步磁盘读取 + 预取 │ │ ├─ SSD 上延迟可与内存方案竞争 │ │ └───────────────────────────────────────────────── │ │ Rust 核心引擎 │ │ ├─ 无 GC 停顿，延迟可预测 │ │ ├─ Python / JS/TS / Rust 绑定 │ │ └───────────────────────────────────────────────── │ │ 多模态支持 │ │ ├─ 向量搜索 + 全文搜索 │ │ ├─ 图像、音频、视频嵌入 │ │ └───────────────────────────────────────────────── │ └─────────────────────────────────────────────────────────┘

性能特征

过滤搜索优势——LanceDB 最大杀手级特性

内存向量库（ChromaDB/Qdrant）做过滤搜索时：即使加了过滤条件，仍需扫描全量内存索引。

LanceDB 做过滤搜索时：将元数据列过滤与向量索引探测结合，只读取相关磁盘页——在过滤场景下比内存方案更快。

已知局限

• 索引构建时间：>10M 向量时比分布式方案（Milvus）慢
• nprobe 调优敏感：太少召回率低，太多延迟高
• SSD 依赖：HDD 或高延迟网络存储上性能显著下降
• 目前单节点（有 LanceDB Cloud 选项）

适用场景

✅ 本地优先 AI 应用、边缘部署、单节点生产、需要磁盘持久化、过滤搜索密集的场景
❌ >10M 向量超大规模、需要分布式、HDD 环境

2. ChromaDB——RAG 原型首选

架构核心

┌─────────────────────────────────────────────────────────┐ │ ChromaDB 架构 │ ├─────────────────────────────────────────────────────────┤ │ Python-first API │ │ ├─ pip install chromadb 即可使用 │ │ ├─ 3 行代码启动：Client → Collection → Add/Query │ │ └───────────────────────────────────────────────── │ │ 双模式运行 │ │ ├─ 嵌入模式：in-process，零服务 │ │ ├─ 服务模式：独立服务进程 │ │ └───────────────────────────────────────────────── │ │ 内建 SQLite 持久化 │ │ ├─ 元数据存储在 SQLite │ │ ├─ 向量存储在内存（默认）或文件 │ │ ├─ HNSW 索引（通过 hnswlib） │ │ └───────────────────────────────────────────────── │ │ 内建 Embedding 函数 │ │ ├─ 默认 all-MiniLM-L6-v2 │ │ ├─ 可配置任意 Embedding 模型 │ │ └───────────────────────────────────────────────── │ └─────────────────────────────────────────────────────────┘

优劣分析

适用场景

✅ RAG 原型/实验、Jupyter notebook 分析、小团队内部工具
❌ 生产级部署、>1M 向量、高并发、需要磁盘优先

3. sqlite-vec——极简主义之选

架构核心

┌─────────────────────────────────────────────────────────┐ │ sqlite-vec 架构 │ ├─────────────────────────────────────────────────────────┤ │ SQLite 官方向量扩展 │ │ ├─ 由 Alex Garcia（sqlite-vss 作者）开发 │ │ ├─ SQLite 团队官方维护 │ │ ├─ 替代已停止维护的 sqlite-vss │ │ └───────────────────────────────────────────────── │ │ 纯 C 实现，零外部依赖 │ │ ├─ 不依赖 FAISS（sqlite-vss 依赖 FAISS） │ │ ├─ SIMD 优化（AVX2/NEON） │ │ ├─ 可编译到 WASM/iOS/Android │ │ └───────────────────────────────────────────────── │ │ 暴力搜索（Brute-force / Flat scan） │ │ ├─ O(n) 扫描，无 ANN 索引 │ │ ├─ <50k 向量时延迟可接受（亚毫秒级） │ │ ├─ >100k 向量时显著变慢 │ │ ├─ 未来计划支持 ANN 索引 │ │ └───────────────────────────────────────────────── │ │ 纯 SQL 接口 │ │ ├─ SELECT * FROM vec_table WHERE vec_col MATCH query │ │ ├─ 与现有 SQLite 基础设施无缝集成 │ │ └───────────────────────────────────────────────── │ └─────────────────────────────────────────────────────────┘

sqlite-vec vs sqlite-vss 关键对比

适用场景

✅ 已有 SQLite 基础设施、极小数据集 (<50k)、WASM/iOS/Android 部署、极简主义项目
❌ >100k 向量、需要 ANN 高性能、需要复杂过滤

4. Qdrant（嵌入式模式）——高性能过滤之选

架构核心

┌─────────────────────────────────────────────────────────┐ │ Qdrant 架构 │ ├─────────────────────────────────────────────────────────┤ │ Rust 核心引擎 │ │ ├─ 无 GC 停顿，延迟可预测 │ │ ├─ 高性能 HNSW 实现 │ │ ├─ WASM 单文件模式（轻量嵌入式） │ │ └───────────────────────────────────────────────── │ │ 丰富过滤能力 │ │ ├─ Payload filtering（元数据条件过滤） │ │ ├─ 地理位置过滤 │ │ ├─ 全文过滤 │ │ ├─ 过滤 + 向量搜索融合 │ │ └───────────────────────────────────────────────── │ │ WAL 持久化 │ │ ├─ Write-Ahead Log 保证持久性 │ │ ├─ 内存 + 磁盘双模式 │ │ └───────────────────────────────────────────────── │ │ 水平扩展 │ │ ├─ 分片 + 复制 │ │ ├─ 从嵌入式平滑迁移到分布式 │ │ └───────────────────────────────────────────────── │ └─────────────────────────────────────────────────────────┘

三种运行模式

适用场景

✅ 需要丰富过滤 + 中等规模、需要从嵌入式平滑迁移到分布式、高性能 HNSW
❌ 极简主义场景（比 sqlite-vec/LanceDB 重）、纯嵌入式磁盘优先场景

5. Milvus Lite——从轻量到分布式的平滑路径

架构核心

Milvus 2024 新推出的嵌入式版本：

┌─────────────────────────────────────────────────────────┐ │ Milvus Lite │ ├─────────────────────────────────────────────────────────┤ │ pip install pymilvus 即可使用 │ │ ├─ Python 进程内运行，无需独立服务 │ │ ├─ 与完整 Milvus API 完全兼容 │ │ ├─ 未来可无缝迁移到 Milvus 分布式 │ │ ├─ HNSW / IVF_FLAT / IVF_SQ8 索引 │ │ └───────────────────────────────────────────────── │ └─────────────────────────────────────────────────────────┘

适用场景

✅ 当前小规模但未来可能需要分布式的项目、需要 Milvus API 兼容性
❌ 纯嵌入式/边缘场景（比 LanceDB 重）、不需要分布式路径的项目

6. DuckDB + vss 扩展——分析+向量混合场景

架构核心

┌─────────────────────────────────────────────────────────┐ │ DuckDB + vss 扩展 │ ├─────────────────────────────────────────────────────────┤ │ DuckDB：OLAP 分析引擎 │ │ ├─ 列式存储、SQL 接口 │ │ ├─ 嵌入式运行，零服务 │ │ ├─ vss 扩展：HNSW 向量搜索 │ │ ├─ 分析查询 + 向量搜索 统一 SQL 接口 │ │ └───────────────────────────────────────────────── │ └─────────────────────────────────────────────────────────┘

适用场景

✅ 分析型场景 + 向量混合查询（如"按地域+时间筛选+语义相似"）
❌ 纯向量搜索场景（不如专用方案）

八、六大方案全面对比矩阵

核心特性对比

性能基准参考（社区数据）

规模适用性

九、选型决策树

你的项目是什么场景？ │ ├─ 纯Python/Jupyter RAG原型 → ChromaDB │ （最简单上手，3行代码可用） │ ├─ 需要磁盘持久化+零服务器+生产级 → LanceDB ★推荐 │ （最强嵌入式，内存极低，过滤搜索最快） │ ├─ 已有SQLite基础设施+极小数据集 → sqlite-vec │ （最小侵入，零依赖，WASM可移植） │ ├─ 需要复杂过滤+中等规模+可能扩展 → Qdrant 嵌入模式 │ （过滤最强，HNSW高性能，可迁移分布式） │ ├─ 分析+向量混合查询 → DuckDB+vss │ （SQL统一接口，OLAP+向量融合） │ └─ 当前小规模但未来可能需要分布式 → Milvus Lite （API兼容完整Milvus，平滑迁移路径）

十、2025-2026 选型趋势总结

五大趋势

1. 嵌入式/本地优先成为主流：更多项目倾向 no-server 方案，避免运维负担
2. LanceDB 热度上升最快：零依赖、磁盘持久化、Rust 性能，2025年被大量推荐
3. sqlite-vec 是 SQLite 官方力推：替代已停止的 sqlite-vss，适合极小场景
4. ChromaDB 仍是入门首选：但生产级项目越来越多迁移到 LanceDB/Qdrant
5. “向量数据库的 SQLite 时刻”：社区共识是嵌入式库式方案将取代独立服务方案

一句话选型建议

小型项目首选 LanceDB（最强嵌入式），极简场景选 sqlite-vec（零依赖），RAG原型选 ChromaDB（最易上手），需要复杂过滤选 Qdrant 嵌入，需要分布式路径选 Milvus Lite。

参考来源

RAG 架构

• RAG Evolution Survey: Naive → Advanced → Modular (arxiv)
• Microsoft GraphRAG
• Self-RAG: Learning to Retrieve, Generate, and Critique (arxiv)
• CRAG: Corrective Retrieval Augmented Generation (arxiv)
• FLARE: Forward-Looking Active REtrieval (arxiv)
• Speculative RAG (arxiv)
• Gao et al. RAG Survey (updated 2025)
• LangGraph Agentic RAG Tutorials
• RAGAS Framework
• LlamaIndex Documentation
• Weaviate Hybrid Search
• Cohere Rerank
• DeepEval RAG Metrics
• TruLens RAG Triad
• ARES: Automated RAG Evaluation (arxiv)

轻量级向量库

• LanceDB Official Docs
• sqlite-vec GitHub
• sqlite-vec vs sqlite-vss Analysis (asgari.dev)
• ChromaDB Documentation
• Qdrant Documentation
• Milvus Lite Documentation
• DuckDB VSS Extension

文档整理日期：2026-06-09