第一部分RAG 架构演进与主流范式一、RAG 三代演进Naive → Advanced → Modular1. 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可自由组装为不同架构无固定管线顺序模块化模式机制适用场景Iter-RAG检索-生成迭代循环需要多轮修正的复杂问题Recursive RAG多跳链式检索跨文档推理问题Adaptive RAG按查询复杂度动态路由混合简单/复杂查询的系统Agentic RAGAgent 自主决定何时检索需要自主决策的场景二、索引策略演进传统索引固定长度分块naive chunking递归字符分块RecursiveCharacterTextSplitter现代索引2025 生产级索引策略机制优势语义分块按嵌入相似度阈值在话题边界切割分块边界更自然命题分块将文档拆为原子事实单元proposition精细检索粒度上下文增强分块父子关系 上下文摘要小块检索、大块生成Late InteractionColBERT/ColBERTv2 的 MaxSim 操作符token 级细粒度匹配元数据增强文档级元数据嵌入到分块中过滤检索双重优化多模态索引图像、表格、音频与文本并行索引超越纯文本三、主流检索策略详解混合检索Hybrid Search——生产标配用户查询 ─┬─ BM25 关键词检索 → 排序列表 A └─ Dense Embedding 语义检索 → 排序列表 B └───────────────────────────── └─ RRF (Reciprocal Rank Fusion) 融合 → 最终排序为什么是标配BM25 捕获精确匹配产品编号、人名、术语Dense Embedding 捕获语义匹配“天气匹配气温”。单独使用任一种都有盲区。Reranking——精度提升核心两阶段管线先粗检索 top-50-100再用 Cross-Encoder 精排到 top-5-10。主流 RerankerReranker类型特点Cohere RerankAPI 服务易集成、效果好BGE-Reranker-v2-m3开源模型多语言、本地部署RankGPTLLM-based利用 LLM 推理能力排序ColBERT RerankerLate Interactiontoken 级精细匹配查询变换策略策略机制解决什么问题Query RewritingLLM 改写/扩展用户查询查询与文档词汇不匹配HyDELLM 生成假设答案作为检索查询查询过于模糊/简短Step-back PromptingLLM 先提出更抽象的高层问题原问题太具体导致检索不足Query DecompositionLLM 将复杂查询拆为子查询多维度分析型问题Query Routing分类器路由到不同检索源多数据源系统四、新范式 RAG2024-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 WebCorrective RAG Agent评估检索质量不够则触发纠错路径Multi-Agent RAG不同 Agent 专门处理不同数据源3. Self-RAG自我反思 RAGLLM 自我反思按段落插入反思 token反思 Token含义[Retrieve]本段落需要检索[No-Retrieve]本段落不需要检索[IsRel]检索结果是否相关[IsSup]检索结果是否支撑生成[IsUse]输出是否有用核心优势比总是检索更高效——模型自主决定何时需要外部知识何时依靠自身知识即可。4. CRAG纠错 RAG在检索后增加纠错门控检索结果 → 检索评估器评分 → 三条路径 ├─ Correct相关→ 直接生成 ├─ Ambiguous模糊→ 改写查询 Web搜索补充检索 └─ Incorrect无关→ 丢弃 完全依赖 Web搜索核心价值使 RAG 对坏检索具有韧性。LangGraph 有官方 CRAG 教程实现。5. FLARE前瞻式主动检索模型主动生成遇到低置信度 token通过 token 概率衡量时暂停从上下文构造查询、检索、恢复生成生成中 → 遇到低置信度片段 → 暂停 → 构造查询 → 检索 → 恢复生成避免过度检索和不足检索。其思想正在被 Agentic RAG 吸收。6. Speculative RAG推测式 RAGGoogle DeepMind 2024-2025Draft-then-verify 方法小型专用模型并行生成候选答案大型验证模型评估哪个候选最佳降低延迟、提高精度、节省成本7. Adaptive RAG自适应 RAG按查询复杂度动态路由检索策略查询 → 复杂度分类器 → ├─ 简单 → 直接生成无检索 ├─ 中等 → 单轮检索 └─ 复杂 → 多跳检索 查询分解8. 多模态 RAG2025 前沿超越文本扩展到图像、视频、音频、表格模态编码器应用图像-文本CLIP医学影像报告、产品搜索音频Whisper会议记录检索视频专用编码器视频QA五、RAG 评估框架RAGAS事实标准v0.2指标衡量什么Faithfulness回答是否基于检索上下文Answer Relevancy回答与问题的相关性Context Precision相关文档排名是否高于无关文档Context Recall所需信息是否全部检索到Answer Correctness与参考答案的对比其他框架框架特点DeepEvalRAG 专用 通用 LLM 指标TruLens“RAG 三元组”上下文相关性、接地性、答案相关性ARES用预测模型自动化评估训练于人类偏好数据CRAG BenchmarkKDD 2024 持续基准挑战2025-2026 新兴评估方向从静态基准 → 动态生产监控管线从单轮指标 → 多轮/Agentic 评估从 LLM-as-judge → 混合LLM 人类 统计方法从仅看精度 → 精度 成本 延迟 鲁棒性权衡CI/CD 式评估管线每次 prompt/模板变更自动评估第二部分轻量级向量库选型深度分析六、轻量级向量库全景概览为什么关注轻量级2025-2026 的核心趋势小型项目不应部署独立服务的重方案Milvus/Weaviate/Pinecone而应优先考虑嵌入式方案。理由部署运维负担Milvus 需要 etcdMinIOPulsarWeaviate 需要 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 绑定 │ │ └───────────────────────────────────────────────── │ │ 多模态支持 │ │ ├─ 向量搜索 全文搜索 │ │ ├─ 图像、音频、视频嵌入 │ │ └───────────────────────────────────────────────── │ └─────────────────────────────────────────────────────────┘性能特征nprobeRecall10延迟 (1M向量, 128维, SSD)1~0.40~3ms5~0.70~6ms10~0.85~10ms20~0.92~15ms指标LanceDB (磁盘)对比搜索延迟 (1M, 128d)~5-15ms可与内存方案竞争内存占用 (1M向量)100MB比内存方案少 ~90%索引构建 (1M)~2-5 分钟比内存方案慢过滤搜索显著快于内存方案磁盘方案可跳过不相关页过滤搜索优势——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 模型 │ │ └───────────────────────────────────────────────── │ └─────────────────────────────────────────────────────────┘优劣分析优势劣势API 最友好3行代码可用不适合高规模生产Python-first生态丰富嵌入模式有局限文档和教程最丰富全量内存模式内存占用高RAG 原型开发最快持久化和并发有短板内建 Embedding 函数大量向量时性能下降适用场景✅ RAG 原型/实验、Jupyter notebook 分析、小团队内部工具❌ 生产级部署、1M 向量、高并发、需要磁盘优先3. sqlite-vec——极简主义之选架构核心┌─────────────────────────────────────────────────────────┐ │ sqlite-vec 架构 │ ├─────────────────────────────────────────────────────────┤ │ SQLite 官方向量扩展 │ │ ├─ 由 Alex Garciasqlite-vss 作者开发 │ │ ├─ SQLite 团队官方维护 │ │ ├─ 替代已停止维护的 sqlite-vss │ │ └───────────────────────────────────────────────── │ │ 纯 C 实现零外部依赖 │ │ ├─ 不依赖 FAISSsqlite-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-vecsqlite-vss搜索算法暴力/Flat (O(n))ANN — HNSW/IVF (via FAISS)外部依赖零FAISS重型 C 依赖便携性WASM/iOS/Android ✅有限 ❌小数据集 (50k)亚毫秒 ✅亚毫秒 ✅大数据集 (500k)O(n) 显著变慢 ❌ANN 10-100x 更快 ✅维护状态活跃停止维护索引构建时间无无需构建较长HNSW 构建存储开销极小仅原始浮点向量较大索引结构适用场景✅ 已有 SQLite 基础设施、极小数据集 (50k)、WASM/iOS/Android 部署、极简主义项目❌ 100k 向量、需要 ANN 高性能、需要复杂过滤4. Qdrant嵌入式模式——高性能过滤之选架构核心┌─────────────────────────────────────────────────────────┐ │ Qdrant 架构 │ ├─────────────────────────────────────────────────────────┤ │ Rust 核心引擎 │ │ ├─ 无 GC 停顿延迟可预测 │ │ ├─ 高性能 HNSW 实现 │ │ ├─ WASM 单文件模式轻量嵌入式 │ │ └───────────────────────────────────────────────── │ │ 丰富过滤能力 │ │ ├─ Payload filtering元数据条件过滤 │ │ ├─ 地理位置过滤 │ │ ├─ 全文过滤 │ │ ├─ 过滤 向量搜索融合 │ │ └───────────────────────────────────────────────── │ │ WAL 持久化 │ │ ├─ Write-Ahead Log 保证持久性 │ │ ├─ 内存 磁盘双模式 │ │ └───────────────────────────────────────────────── │ │ 水平扩展 │ │ ├─ 分片 复制 │ │ ├─ 从嵌入式平滑迁移到分布式 │ │ └───────────────────────────────────────────────── │ └─────────────────────────────────────────────────────────┘三种运行模式模式说明适用Docker/独立服务完整生产级服务生产部署Python 嵌入式pip install qdrant-client进程内运行中小型开发WASM 单文件单个 .wasm 文件运行极轻量/浏览器适用场景✅ 需要丰富过滤 中等规模、需要从嵌入式平滑迁移到分布式、高性能 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 扩展 │ ├─────────────────────────────────────────────────────────┤ │ DuckDBOLAP 分析引擎 │ │ ├─ 列式存储、SQL 接口 │ │ ├─ 嵌入式运行零服务 │ │ ├─ vss 扩展HNSW 向量搜索 │ │ ├─ 分析查询 向量搜索 统一 SQL 接口 │ │ └───────────────────────────────────────────────── │ └─────────────────────────────────────────────────────────┘适用场景✅ 分析型场景 向量混合查询如按地域时间筛选语义相似❌ 纯向量搜索场景不如专用方案八、六大方案全面对比矩阵核心特性对比特性LanceDBChromaDBsqlite-vecQdrant 嵌入Milvus LiteDuckDBvss嵌入/无服务✅ 完全⚠️ 部分✅ 完全⚠️ WASM⚠️ Python内✅ 完全设置复杂度极低低极低中低低磁盘优先✅ 核心❌ 内存优先✅ SQLite文件⚠️ 内存磁盘⚠️ 内存优先✅ 列式文件ANN 索引IVF-PQHNSW❌ 暴力搜索HNSWHNSW/IVFHNSW内存占用极低较高低中中低过滤搜索✅ 强⚠️ 有限⚠️ SQL WHERE✅ 极强✅ 强✅ SQL多模态✅ 强⚠️ 有限❌⚠️ 有限✅ 好❌生产就绪✅ 成长中⚠️ 开发聚焦⚠️ 新兴✅ 成熟⚠️ 新⚠️ 新语言绑定Py/JS/RustPythonC/Py/Rust/WASMPython/JS/RustPythonPython/C分布式迁移Cloud❌❌✅ 原生支持✅ 原生兼容❌性能基准参考社区数据数据库10万向量检索延迟内存占用持久化方式LanceDB~30ms极低磁盘IOLance 列式文件ChromaDB~50ms较高全量内存SQLite 文件sqlite-vec~40ms (暴力)低SQLite 文件Qdrant 嵌入~20ms中内存磁盘Milvus Lite~25ms中本地文件规模适用性数据库10万10-100万100万-1亿1亿LanceDB✅ 优秀✅ 良好⚠️ 可用❌ 需CloudChromaDB✅ 优秀⚠️ 可用❌❌sqlite-vec✅ 优秀⚠️ 勉强❌❌Qdrant 嵌入✅ 优秀✅ 良好⚠️ 需独立服务✅ 分布式Milvus Lite✅ 优秀✅ 良好⚠️ 需完整Milvus✅ 分布式九、选型决策树你的项目是什么场景 │ ├─ 纯Python/Jupyter RAG原型 → ChromaDB │ 最简单上手3行代码可用 │ ├─ 需要磁盘持久化零服务器生产级 → LanceDB ★推荐 │ 最强嵌入式内存极低过滤搜索最快 │ ├─ 已有SQLite基础设施极小数据集 → sqlite-vec │ 最小侵入零依赖WASM可移植 │ ├─ 需要复杂过滤中等规模可能扩展 → Qdrant 嵌入模式 │ 过滤最强HNSW高性能可迁移分布式 │ ├─ 分析向量混合查询 → DuckDBvss │ SQL统一接口OLAP向量融合 │ └─ 当前小规模但未来可能需要分布式 → Milvus Lite API兼容完整Milvus平滑迁移路径十、2025-2026 选型趋势总结五大趋势嵌入式/本地优先成为主流更多项目倾向 no-server 方案避免运维负担LanceDB 热度上升最快零依赖、磁盘持久化、Rust 性能2025年被大量推荐sqlite-vec 是 SQLite 官方力推替代已停止的 sqlite-vss适合极小场景ChromaDB 仍是入门首选但生产级项目越来越多迁移到 LanceDB/Qdrant“向量数据库的 SQLite 时刻”社区共识是嵌入式库式方案将取代独立服务方案一句话选型建议小型项目首选 LanceDB最强嵌入式极简场景选 sqlite-vec零依赖RAG原型选 ChromaDB最易上手需要复杂过滤选 Qdrant 嵌入需要分布式路径选 Milvus Lite。参考来源RAG 架构RAG Evolution Survey: Naive → Advanced → Modular (arxiv)Microsoft GraphRAGSelf-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 TutorialsRAGAS FrameworkLlamaIndex DocumentationWeaviate Hybrid SearchCohere RerankDeepEval RAG MetricsTruLens RAG TriadARES: Automated RAG Evaluation (arxiv)轻量级向量库LanceDB Official Docssqlite-vec GitHubsqlite-vec vs sqlite-vss Analysis (asgari.dev)ChromaDB DocumentationQdrant DocumentationMilvus Lite DocumentationDuckDB VSS Extension文档整理日期2026-06-09
当前主流 RAG 架构全景及轻量级向量库选型深度分析
发布时间：2026/6/9 17:07:43
第一部分RAG 架构演进与主流范式一、RAG 三代演进Naive → Advanced → Modular1. 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可自由组装为不同架构无固定管线顺序模块化模式机制适用场景Iter-RAG检索-生成迭代循环需要多轮修正的复杂问题Recursive RAG多跳链式检索跨文档推理问题Adaptive RAG按查询复杂度动态路由混合简单/复杂查询的系统Agentic RAGAgent 自主决定何时检索需要自主决策的场景二、索引策略演进传统索引固定长度分块naive chunking递归字符分块RecursiveCharacterTextSplitter现代索引2025 生产级索引策略机制优势语义分块按嵌入相似度阈值在话题边界切割分块边界更自然命题分块将文档拆为原子事实单元proposition精细检索粒度上下文增强分块父子关系 上下文摘要小块检索、大块生成Late InteractionColBERT/ColBERTv2 的 MaxSim 操作符token 级细粒度匹配元数据增强文档级元数据嵌入到分块中过滤检索双重优化多模态索引图像、表格、音频与文本并行索引超越纯文本三、主流检索策略详解混合检索Hybrid Search——生产标配用户查询 ─┬─ BM25 关键词检索 → 排序列表 A └─ Dense Embedding 语义检索 → 排序列表 B └───────────────────────────── └─ RRF (Reciprocal Rank Fusion) 融合 → 最终排序为什么是标配BM25 捕获精确匹配产品编号、人名、术语Dense Embedding 捕获语义匹配“天气匹配气温”。单独使用任一种都有盲区。Reranking——精度提升核心两阶段管线先粗检索 top-50-100再用 Cross-Encoder 精排到 top-5-10。主流 RerankerReranker类型特点Cohere RerankAPI 服务易集成、效果好BGE-Reranker-v2-m3开源模型多语言、本地部署RankGPTLLM-based利用 LLM 推理能力排序ColBERT RerankerLate Interactiontoken 级精细匹配查询变换策略策略机制解决什么问题Query RewritingLLM 改写/扩展用户查询查询与文档词汇不匹配HyDELLM 生成假设答案作为检索查询查询过于模糊/简短Step-back PromptingLLM 先提出更抽象的高层问题原问题太具体导致检索不足Query DecompositionLLM 将复杂查询拆为子查询多维度分析型问题Query Routing分类器路由到不同检索源多数据源系统四、新范式 RAG2024-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 WebCorrective RAG Agent评估检索质量不够则触发纠错路径Multi-Agent RAG不同 Agent 专门处理不同数据源3. Self-RAG自我反思 RAGLLM 自我反思按段落插入反思 token反思 Token含义[Retrieve]本段落需要检索[No-Retrieve]本段落不需要检索[IsRel]检索结果是否相关[IsSup]检索结果是否支撑生成[IsUse]输出是否有用核心优势比总是检索更高效——模型自主决定何时需要外部知识何时依靠自身知识即可。4. CRAG纠错 RAG在检索后增加纠错门控检索结果 → 检索评估器评分 → 三条路径 ├─ Correct相关→ 直接生成 ├─ Ambiguous模糊→ 改写查询 Web搜索补充检索 └─ Incorrect无关→ 丢弃 完全依赖 Web搜索核心价值使 RAG 对坏检索具有韧性。LangGraph 有官方 CRAG 教程实现。5. FLARE前瞻式主动检索模型主动生成遇到低置信度 token通过 token 概率衡量时暂停从上下文构造查询、检索、恢复生成生成中 → 遇到低置信度片段 → 暂停 → 构造查询 → 检索 → 恢复生成避免过度检索和不足检索。其思想正在被 Agentic RAG 吸收。6. Speculative RAG推测式 RAGGoogle DeepMind 2024-2025Draft-then-verify 方法小型专用模型并行生成候选答案大型验证模型评估哪个候选最佳降低延迟、提高精度、节省成本7. Adaptive RAG自适应 RAG按查询复杂度动态路由检索策略查询 → 复杂度分类器 → ├─ 简单 → 直接生成无检索 ├─ 中等 → 单轮检索 └─ 复杂 → 多跳检索 查询分解8. 多模态 RAG2025 前沿超越文本扩展到图像、视频、音频、表格模态编码器应用图像-文本CLIP医学影像报告、产品搜索音频Whisper会议记录检索视频专用编码器视频QA五、RAG 评估框架RAGAS事实标准v0.2指标衡量什么Faithfulness回答是否基于检索上下文Answer Relevancy回答与问题的相关性Context Precision相关文档排名是否高于无关文档Context Recall所需信息是否全部检索到Answer Correctness与参考答案的对比其他框架框架特点DeepEvalRAG 专用 通用 LLM 指标TruLens“RAG 三元组”上下文相关性、接地性、答案相关性ARES用预测模型自动化评估训练于人类偏好数据CRAG BenchmarkKDD 2024 持续基准挑战2025-2026 新兴评估方向从静态基准 → 动态生产监控管线从单轮指标 → 多轮/Agentic 评估从 LLM-as-judge → 混合LLM 人类 统计方法从仅看精度 → 精度 成本 延迟 鲁棒性权衡CI/CD 式评估管线每次 prompt/模板变更自动评估第二部分轻量级向量库选型深度分析六、轻量级向量库全景概览为什么关注轻量级2025-2026 的核心趋势小型项目不应部署独立服务的重方案Milvus/Weaviate/Pinecone而应优先考虑嵌入式方案。理由部署运维负担Milvus 需要 etcdMinIOPulsarWeaviate 需要 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 绑定 │ │ └───────────────────────────────────────────────── │ │ 多模态支持 │ │ ├─ 向量搜索 全文搜索 │ │ ├─ 图像、音频、视频嵌入 │ │ └───────────────────────────────────────────────── │ └─────────────────────────────────────────────────────────┘性能特征nprobeRecall10延迟 (1M向量, 128维, SSD)1~0.40~3ms5~0.70~6ms10~0.85~10ms20~0.92~15ms指标LanceDB (磁盘)对比搜索延迟 (1M, 128d)~5-15ms可与内存方案竞争内存占用 (1M向量)100MB比内存方案少 ~90%索引构建 (1M)~2-5 分钟比内存方案慢过滤搜索显著快于内存方案磁盘方案可跳过不相关页过滤搜索优势——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 模型 │ │ └───────────────────────────────────────────────── │ └─────────────────────────────────────────────────────────┘优劣分析优势劣势API 最友好3行代码可用不适合高规模生产Python-first生态丰富嵌入模式有局限文档和教程最丰富全量内存模式内存占用高RAG 原型开发最快持久化和并发有短板内建 Embedding 函数大量向量时性能下降适用场景✅ RAG 原型/实验、Jupyter notebook 分析、小团队内部工具❌ 生产级部署、1M 向量、高并发、需要磁盘优先3. sqlite-vec——极简主义之选架构核心┌─────────────────────────────────────────────────────────┐ │ sqlite-vec 架构 │ ├─────────────────────────────────────────────────────────┤ │ SQLite 官方向量扩展 │ │ ├─ 由 Alex Garciasqlite-vss 作者开发 │ │ ├─ SQLite 团队官方维护 │ │ ├─ 替代已停止维护的 sqlite-vss │ │ └───────────────────────────────────────────────── │ │ 纯 C 实现零外部依赖 │ │ ├─ 不依赖 FAISSsqlite-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-vecsqlite-vss搜索算法暴力/Flat (O(n))ANN — HNSW/IVF (via FAISS)外部依赖零FAISS重型 C 依赖便携性WASM/iOS/Android ✅有限 ❌小数据集 (50k)亚毫秒 ✅亚毫秒 ✅大数据集 (500k)O(n) 显著变慢 ❌ANN 10-100x 更快 ✅维护状态活跃停止维护索引构建时间无无需构建较长HNSW 构建存储开销极小仅原始浮点向量较大索引结构适用场景✅ 已有 SQLite 基础设施、极小数据集 (50k)、WASM/iOS/Android 部署、极简主义项目❌ 100k 向量、需要 ANN 高性能、需要复杂过滤4. Qdrant嵌入式模式——高性能过滤之选架构核心┌─────────────────────────────────────────────────────────┐ │ Qdrant 架构 │ ├─────────────────────────────────────────────────────────┤ │ Rust 核心引擎 │ │ ├─ 无 GC 停顿延迟可预测 │ │ ├─ 高性能 HNSW 实现 │ │ ├─ WASM 单文件模式轻量嵌入式 │ │ └───────────────────────────────────────────────── │ │ 丰富过滤能力 │ │ ├─ Payload filtering元数据条件过滤 │ │ ├─ 地理位置过滤 │ │ ├─ 全文过滤 │ │ ├─ 过滤 向量搜索融合 │ │ └───────────────────────────────────────────────── │ │ WAL 持久化 │ │ ├─ Write-Ahead Log 保证持久性 │ │ ├─ 内存 磁盘双模式 │ │ └───────────────────────────────────────────────── │ │ 水平扩展 │ │ ├─ 分片 复制 │ │ ├─ 从嵌入式平滑迁移到分布式 │ │ └───────────────────────────────────────────────── │ └─────────────────────────────────────────────────────────┘三种运行模式模式说明适用Docker/独立服务完整生产级服务生产部署Python 嵌入式pip install qdrant-client进程内运行中小型开发WASM 单文件单个 .wasm 文件运行极轻量/浏览器适用场景✅ 需要丰富过滤 中等规模、需要从嵌入式平滑迁移到分布式、高性能 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 扩展 │ ├─────────────────────────────────────────────────────────┤ │ DuckDBOLAP 分析引擎 │ │ ├─ 列式存储、SQL 接口 │ │ ├─ 嵌入式运行零服务 │ │ ├─ vss 扩展HNSW 向量搜索 │ │ ├─ 分析查询 向量搜索 统一 SQL 接口 │ │ └───────────────────────────────────────────────── │ └─────────────────────────────────────────────────────────┘适用场景✅ 分析型场景 向量混合查询如按地域时间筛选语义相似❌ 纯向量搜索场景不如专用方案八、六大方案全面对比矩阵核心特性对比特性LanceDBChromaDBsqlite-vecQdrant 嵌入Milvus LiteDuckDBvss嵌入/无服务✅ 完全⚠️ 部分✅ 完全⚠️ WASM⚠️ Python内✅ 完全设置复杂度极低低极低中低低磁盘优先✅ 核心❌ 内存优先✅ SQLite文件⚠️ 内存磁盘⚠️ 内存优先✅ 列式文件ANN 索引IVF-PQHNSW❌ 暴力搜索HNSWHNSW/IVFHNSW内存占用极低较高低中中低过滤搜索✅ 强⚠️ 有限⚠️ SQL WHERE✅ 极强✅ 强✅ SQL多模态✅ 强⚠️ 有限❌⚠️ 有限✅ 好❌生产就绪✅ 成长中⚠️ 开发聚焦⚠️ 新兴✅ 成熟⚠️ 新⚠️ 新语言绑定Py/JS/RustPythonC/Py/Rust/WASMPython/JS/RustPythonPython/C分布式迁移Cloud❌❌✅ 原生支持✅ 原生兼容❌性能基准参考社区数据数据库10万向量检索延迟内存占用持久化方式LanceDB~30ms极低磁盘IOLance 列式文件ChromaDB~50ms较高全量内存SQLite 文件sqlite-vec~40ms (暴力)低SQLite 文件Qdrant 嵌入~20ms中内存磁盘Milvus Lite~25ms中本地文件规模适用性数据库10万10-100万100万-1亿1亿LanceDB✅ 优秀✅ 良好⚠️ 可用❌ 需CloudChromaDB✅ 优秀⚠️ 可用❌❌sqlite-vec✅ 优秀⚠️ 勉强❌❌Qdrant 嵌入✅ 优秀✅ 良好⚠️ 需独立服务✅ 分布式Milvus Lite✅ 优秀✅ 良好⚠️ 需完整Milvus✅ 分布式九、选型决策树你的项目是什么场景 │ ├─ 纯Python/Jupyter RAG原型 → ChromaDB │ 最简单上手3行代码可用 │ ├─ 需要磁盘持久化零服务器生产级 → LanceDB ★推荐 │ 最强嵌入式内存极低过滤搜索最快 │ ├─ 已有SQLite基础设施极小数据集 → sqlite-vec │ 最小侵入零依赖WASM可移植 │ ├─ 需要复杂过滤中等规模可能扩展 → Qdrant 嵌入模式 │ 过滤最强HNSW高性能可迁移分布式 │ ├─ 分析向量混合查询 → DuckDBvss │ SQL统一接口OLAP向量融合 │ └─ 当前小规模但未来可能需要分布式 → Milvus Lite API兼容完整Milvus平滑迁移路径十、2025-2026 选型趋势总结五大趋势嵌入式/本地优先成为主流更多项目倾向 no-server 方案避免运维负担LanceDB 热度上升最快零依赖、磁盘持久化、Rust 性能2025年被大量推荐sqlite-vec 是 SQLite 官方力推替代已停止的 sqlite-vss适合极小场景ChromaDB 仍是入门首选但生产级项目越来越多迁移到 LanceDB/Qdrant“向量数据库的 SQLite 时刻”社区共识是嵌入式库式方案将取代独立服务方案一句话选型建议小型项目首选 LanceDB最强嵌入式极简场景选 sqlite-vec零依赖RAG原型选 ChromaDB最易上手需要复杂过滤选 Qdrant 嵌入需要分布式路径选 Milvus Lite。参考来源RAG 架构RAG Evolution Survey: Naive → Advanced → Modular (arxiv)Microsoft GraphRAGSelf-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 TutorialsRAGAS FrameworkLlamaIndex DocumentationWeaviate Hybrid SearchCohere RerankDeepEval RAG MetricsTruLens RAG TriadARES: Automated RAG Evaluation (arxiv)轻量级向量库LanceDB Official Docssqlite-vec GitHubsqlite-vec vs sqlite-vss Analysis (asgari.dev)ChromaDB DocumentationQdrant DocumentationMilvus Lite DocumentationDuckDB VSS Extension文档整理日期2026-06-09
