RAG 技术方案深度调研(2025-2026)
一、RAG 架构演进
RAG(Retrieval-Augmented Generation,检索增强生成)将 LLM 的生成能力与外部知识库的检索能力结合,解决大模型的幻觉、知识过时和领域知识不足问题。2024-2026 年间,RAG 从简单的”检索+生成”演进为多种专业化架构。
1.1 架构演进路线
flowchart LR
A["Naive RAG"] --> B["Advanced RAG"]
B --> C["Modular RAG"]
C --> D["Agentic RAG"]
C --> E["Graph RAG"]
D --> F["Multi-Agent RAG"]
style A fill:#e8e8e8
style D fill:#4a9eff,color:#fff
style E fill:#4a9eff,color:#fff
style F fill:#ff6b6b,color:#fff
1.2 五代架构对比
| 架构 | 核心思路 | 检索方式 | 适用场景 | 局限 |
|---|---|---|---|---|
| Naive RAG | 问题 -> 检索 -> 生成 | 单次向量检索 | 简单 QA | 无法处理复杂查询;检索质量不可控 |
| Advanced RAG | 查询改写 + 混合检索 + 重排序 | Hybrid + Rerank | 企业知识库 | 流程固定,缺乏自适应能力 |
| Modular RAG | 可插拔模块化管道 | 按需组合 | 需要灵活定制的场景 | 模块间协调复杂 |
| Agentic RAG | AI Agent 动态决策检索策略 | Agent 自主规划 | 复杂推理、多步骤任务 | 延迟和成本增加 |
| Graph RAG | 知识图谱 + 图遍历检索 | 实体关系图遍历 | 实体密集型数据(金融、医疗、法律) | 图构建成本高 |
二、核心架构详解
2.1 Naive RAG — 基础管道
最基本的 RAG 实现,三步流程:
flowchart LR
A["用户问题"] --> B["Embedding"]
B --> C["向量检索 Top-K"]
C --> D["拼接 Context + Query"]
D --> E["LLM 生成答案"]
典型问题:
- 检索到的内容不相关(语义鸿沟)
- 上下文窗口浪费(无关内容占位)
- 无法处理需要多步推理的复杂问题
2.2 Advanced RAG — 工程优化
在 Naive RAG 基础上,通过工程手段优化检索和生成质量:
flowchart TD
A["用户问题"] --> B["查询改写/扩展"]
B --> C["混合检索"]
C --> C1["BM25 稀疏检索"]
C --> C2["向量稠密检索"]
C1 --> D["RRF 融合"]
C2 --> D
D --> E["Cross-Encoder 重排序"]
E --> F["上下文压缩"]
F --> G["LLM 生成"]
G --> H["答案验证"]
关键优化技术:
| 阶段 | 技术 | 效果 |
|---|---|---|
| 查询优化 | HyDE(假设文档嵌入)、Multi-Query、Step-back Prompting | 缩小查询与文档的语义鸿沟 |
| 混合检索 | BM25 + Dense Vector + Sparse Vector | 综合关键词匹配和语义理解 |
| 融合排序 | Reciprocal Rank Fusion (RRF) | 合并多路检索结果 |
| 重排序 | Cross-Encoder、ColBERT | 精细评估查询-文档相关性 |
| 上下文优化 | 压缩、去重、相关性过滤 | 提高上下文质量 |
混合检索(BM25 + Dense + Sparse)+ ColBERT 重排序的组合,在多个基准测试中显著优于纯向量检索。
来源:Optimizing RAG with Hybrid Search & Reranking - Superlinked | Dense + Sparse + Reranker - InfiniFlow
2.3 Corrective RAG (CRAG) — 自我纠错
CRAG 引入检索结果的自动评估和纠错机制:
flowchart TD
A["用户问题"] --> B["检索文档"]
B --> C["轻量评估模型打分"]
C --> D{"文档相关性?"}
D -->|"Correct"| E["直接使用"]
D -->|"Ambiguous"| F["补充检索 + 合并"]
D -->|"Incorrect"| G["查询改写 / Web 搜索"]
E --> H["LLM 生成"]
F --> H
G --> H
核心机制:
- 轻量模型(如 fine-tuned T5)评估文档相关性,分类为 Correct / Incorrect / Ambiguous
- 对于不相关文档,触发 Web 搜索或查询变换寻找更好的来源
- 通过自我纠错循环提高最终答案质量
来源:RAG Architectures: From Naive to Agentic
2.4 Self-RAG — 自适应检索
Self-RAG 让模型自己决定何时需要检索,何时可以直接回答:
flowchart TD
A["用户问题"] --> B{"需要检索?"}
B -->|"是"| C["检索文档"]
B -->|"否"| D["直接生成"]
C --> E["生成候选答案"]
E --> F{"答案有支撑?"}
F -->|"是"| G["输出答案"]
F -->|"否"| H["重新检索/改写"]
H --> C
D --> G
关键特性:
- Retrieve Token:模型输出特殊 token 决定是否需要检索
- Critique Token:对检索结果和生成答案进行自我批评
- 减少不必要的检索调用,降低延迟和成本
2.5 Agentic RAG — 2026 年的主流范式
“Agentic RAG 不是管道,而是一个循环。LLM 作为推理引擎而非单纯的文本生成器。到 2026 年,Agentic RAG 是任何严肃 AI 应用的基线。”
flowchart TD
A["用户问题"] --> B["Agent 规划"]
B --> C{"选择策略"}
C -->|"简单查询"| D["单次检索"]
C -->|"复杂推理"| E["多步检索规划"]
C -->|"实时数据"| F["工具调用 API"]
C -->|"参数知识足够"| G["直接回答"]
D --> H["反思评估"]
E --> H
F --> H
G --> I["输出答案"]
H --> J{"答案质量?"}
J -->|"满意"| I
J -->|"不满意"| B
Agentic RAG 的四大设计模式:
| 模式 | 描述 | 示例 |
|---|---|---|
| Reflection(反思) | Agent 对自己的输出进行批判性评估 | 检查答案是否有检索证据支撑 |
| Planning(规划) | 将复杂问题分解为检索子任务 | ”比较 A 和 B” -> 分别检索 A 和 B 再综合 |
| Tool Use(工具使用) | 动态调用不同检索工具和 API | 向量库 / Web 搜索 / SQL 查询 / 计算器 |
| Multi-Agent(多智能体) | 多个专业化 Agent 协作完成复杂任务 | Research Agent + Synthesis Agent + Critic Agent |
主流 Agentic RAG 框架:
| 框架 | 特点 |
|---|---|
| LangGraph | LangChain 的图编排引擎,支持有状态的 Agent 工作流 |
| LlamaIndex Agents | 专为数据密集型场景设计的 Agent 框架 |
| Microsoft AutoGen | 多 Agent 对话框架,支持人机协作 |
| CrewAI | 基于角色的多 Agent 协作框架 |
来源:Agentic RAG Survey - arXiv | Building Agentic RAG with LangGraph | Standard RAG Is Dead - UCStrategies
2.6 Graph RAG — 知识图谱增强
GraphRAG 将文档转化为可遍历的实体关系图谱,而非扁平的文本块:
flowchart LR
A["原始文档"] --> B["实体抽取"]
B --> C["关系抽取"]
C --> D["知识图谱构建"]
D --> E["社区检测"]
E --> F["层级摘要"]
G["用户问题"] --> H["实体识别"]
H --> I["图遍历检索"]
I --> J["子图提取"]
J --> K["LLM 生成"]
F --> K
GraphRAG vs Naive RAG:
| 维度 | Naive RAG | Graph RAG |
|---|---|---|
| 检索单元 | 文本块 | 实体 + 关系 + 社区摘要 |
| 全局问题 | 很差(只能检索局部片段) | 很强(层级社区摘要覆盖全局) |
| 多跳推理 | 需要多次检索 | 图遍历天然支持 |
| 构建成本 | 低(只需嵌入) | 高(需要 LLM 抽取实体关系) |
| 适用数据 | 通用文本 | 实体密集型(金融、医疗、法律) |
Graph RAG 变体:
| 变体 | 特点 |
|---|---|
| Microsoft GraphRAG | 层级社区检测 + LLM 摘要,开源标杆 |
| LightRAG | 轻量级图 RAG,降低构建成本 |
| FastGraphRAG | 性能优化版本 |
| MiniRAG | 最小化图 RAG 实现 |
| HyperGraphRAG | 超图结构,支持多元关系 |
| KG2RAG | 知识图谱到 RAG 的桥接框架 |
来源:Microsoft GraphRAG | GraphRAG Explained - Zilliz
三、分块策略(Chunking)
分块策略是 RAG 系统中对检索质量影响最大的因素之一。
3.1 策略对比
| 策略 | 原理 | 优点 | 缺点 | 推荐场景 |
|---|---|---|---|---|
| 固定大小 | 按 token 数切分 | 实现简单,速度快 | 破坏语义边界 | 快速原型 |
| 递归字符分块 | 按分隔符递归切分 | 平衡效果与复杂度 | 仍可能切断上下文 | 通用默认推荐 |
| 语义分块 | 按语义相似度切分 | 保持语义完整性 | 计算成本较高 | 长文档、多主题文档 |
| 命题分块 | 分解为原子事实单元 | 检索精度最高 | 需要 LLM 处理,成本高 | 知识密集型场景 |
| Late Chunking | 先嵌入整个文档再切分 | 保留全局上下文 | 效率较低 | 上下文敏感的文档 |
| Contextual Retrieval | 为每个块添加上下文前缀 | 语义连贯性最好 | 计算资源需求大 | 对准确性要求极高的场景 |
3.2 推荐默认配置
RecursiveCharacterTextSplitter 配合 400-512 tokens 的块大小,在 Chroma 的测试中达到 85-90% 的召回率,且没有额外的计算开销,是大多数团队的可靠默认选择。
语义分块 在多个基准测试中比简单方法提升约 9% 的召回率。命题分块 进一步将内容分解为自包含的原子事实单元,研究表明这能显著提高检索精度。
3.3 Late Chunking vs Contextual Retrieval
| 维度 | Late Chunking | Contextual Retrieval |
|---|---|---|
| 原理 | 先对整个文档做嵌入,再切分 | 为每个块添加上下文描述前缀 |
| 语义连贯性 | 中等 | 高 |
| 计算成本 | 较低 | 较高 |
| 检索效率 | 高 | 中 |
| 适用场景 | 效率优先 | 准确性优先 |
来源:Chunking Strategies for RAG - arXiv | Best Chunking Strategies 2025 - Firecrawl | Late Chunking - arXiv
四、检索策略
4.1 混合检索(Hybrid Search)
混合检索是 2025-2026 年 RAG 系统的标准实践,结合三种检索方式:
flowchart TD
A["用户查询"] --> B["BM25 稀疏检索"]
A --> C["Dense Vector 稠密检索"]
A --> D["Sparse Vector 稀疏向量"]
B --> E["Reciprocal Rank Fusion"]
C --> E
D --> E
E --> F["Cross-Encoder 重排序"]
F --> G["Top-K 结果"]
| 检索类型 | 擅长 | 不擅长 |
|---|---|---|
| BM25(稀疏) | 精确关键词匹配、专有名词 | 同义词、语义理解 |
| Dense Vector(稠密) | 语义相似、意图理解 | 精确匹配、罕见词 |
| Sparse Vector | 兼顾关键词和语义 | 计算开销略高 |
4.2 重排序(Reranking)
重排序是提升检索精度的关键一步:
| 方法 | 原理 | 精度 | 速度 |
|---|---|---|---|
| Cross-Encoder | 将 Query+Document 一起输入 Transformer 打分 | 最高 | 慢(不适合大量候选) |
| ColBERT | Token 级交互 + 延迟交互 | 很高 | 快(适合大规模) |
| Cohere Rerank | API 服务 | 高 | 快 |
| BGE-Reranker | 开源模型 | 高 | 中 |
最佳实践:先用混合检索拉回 50-100 个候选,再用 Cross-Encoder/ColBERT 重排到 Top 5-10。
来源:Hybrid Retrieval and Reranking in RAG
五、Embedding 模型选型
5.1 2025-2026 年顶级 Embedding 模型
| 模型 | 提供方 | 维度 | 上下文长度 | MTEB 分数 | 价格 | 特点 |
|---|---|---|---|---|---|---|
| Cohere embed-v4 | Cohere | 1536 | 128K tokens | 65.2 | $0.1/M tokens | 超长上下文,可处理整本书 |
| Voyage-3-large | Voyage AI | 1024 | 32K tokens | ~65 | $0.18/M tokens | 检索相关性最高 |
| text-embedding-3-large | OpenAI | 3072 | 8K tokens | 64.6 | $0.13/M tokens | 高维度,质量稳定 |
| NV-Embed-v2 | NVIDIA | 4096 | 32K tokens | MTEB 榜首 | 自部署 | 基于 Mistral-7B,性能最强 |
| jina-embeddings-v3 | Jina AI | 1024 | 8K tokens | ~64 | $0.02/M tokens | 89+ 语言,任务特化 |
| BGE-M3 | BAAI | 1024 | 8K tokens | 63.0 | 开源免费 | 最佳开源选择 |
| Qwen3-Embedding | 阿里巴巴 | 1024 | 32K tokens | ~64 | 开源免费 | 100+ 语言,中文最强 |
5.2 选型建议
| 场景 | 推荐模型 | 理由 |
|---|---|---|
| 通用英文 RAG | Voyage-3-large | 检索相关性最高 |
| 超长文档 | Cohere embed-v4 | 128K 上下文窗口 |
| 成本敏感 | Jina v3 | 价格最低,质量够用 |
| 中文优先 | Qwen3-Embedding | 中文表现最好 |
| 开源自部署 | BGE-M3 / NV-Embed-v2 | 无 API 依赖 |
| 快速原型 | OpenAI text-embedding-3-large | 生态成熟,接入简单 |
来源:Best Embedding Models - Ailog | 13 Best Embedding Models 2026 - Elephas | Best Open-Source Embedding Models 2026 - BentoML
六、向量数据库选型
6.1 主流向量数据库对比
| 数据库 | 类型 | 规模适用 | 混合搜索 | 特点 | 价格 |
|---|---|---|---|---|---|
| Pinecone | 全托管 | 中大型 | 支持 | 零运维,企业级 SLA | $50-500+/月 |
| Qdrant | 开源/云 | 中大型 | 支持 | 过滤性能最佳,Rust 编写 | 开源免费 / Cloud 按需 |
| Milvus | 开源/云 | 超大规模 | 支持 | 十亿级向量,分布式集群 | 开源免费 / Zilliz Cloud |
| Weaviate | 开源/云 | 中大型 | 最强 | GraphQL API,多向量空间 | 开源免费 / Cloud 按需 |
| pgvector | PostgreSQL 扩展 | 中小型 | 有限 | 复用现有 PG 基础设施 | 取决于 PG 部署 |
| ChromaDB | 开源 | 小中型 | 基础 | 极简 API,开发者友好 | 开源免费 |
6.2 性能基准(50M 向量,99% 召回率)
| 数据库 | QPS | 说明 |
|---|---|---|
| pgvectorscale | 471 | 大幅领先(PostgreSQL 生态) |
| Qdrant | 41.47 | 开源专用向量库最佳 |
| Milvus | ~35 | 分布式场景更强 |
6.3 选型建议
| 场景 | 推荐 | 理由 |
|---|---|---|
| 快速原型 / 小团队 | ChromaDB | 最简单,几行代码启动 |
| 已有 PostgreSQL | pgvector | 复用基础设施,免维护新系统 |
| 生产级开源 | Qdrant 或 Weaviate | 性能强,社区活跃 |
| 十亿级向量 | Milvus | 分布式架构,大规模经验丰富 |
| 零运维 SaaS | Pinecone | 企业级 SLA,但价格高 |
| 需要强混合搜索 | Weaviate | 混合搜索能力最全面 |
来源:Vector Database Comparison 2025 - LiquidMetal | Best Vector Databases - Firecrawl | Best Vector Databases for RAG - Latenode
七、RAG 生产框架
7.1 主流框架对比
| 框架 | GitHub Stars | 定位 | 延迟 | Token 用量 | 最佳场景 |
|---|---|---|---|---|---|
| LangChain | ~103k | 通用 LLM 应用框架 | ~10ms | ~2.4k | 快速原型,灵活集成 |
| LangGraph | ~10k | 图编排 Agent 引擎 | ~14ms | ~2.0k | Agentic RAG 工作流 |
| LlamaIndex | ~40k | 数据密集型 RAG 框架 | ~6ms | ~1.6k | 文档检索、企业知识库 |
| Haystack | ~20k | 企业级 NLP 管道 | ~5.9ms | ~1.57k | 生产部署、企业客户 |
| Dify | ~70k+ | 可视化 AI 应用构建 | - | - | 非开发者、低代码场景 |
| DSPy | ~22k | 编程式 Prompt 优化 | ~7ms | ~2.0k | 研究、自动化调优 |
7.2 选型建议
| 场景 | 推荐 | 理由 |
|---|---|---|
| 快速原型 | LangChain | 生态最丰富,上手最快 |
| Agentic RAG | LangGraph | 专为有状态 Agent 工作流设计 |
| 数据密集型 RAG | LlamaIndex | 索引和检索优化最深,Token 用量最低 |
| 企业生产 | Haystack | 延迟最低,成熟度最高 |
| 低代码 / 非开发者 | Dify | 可视化拖拽,增长最快 |
| 研究 / 自动调优 | DSPy | 编程式 Prompt 优化 |
Haystack 延迟最低(~5.9ms),Token 用量最少(~1.57k),是性能最优的生产框架。LlamaIndex 紧随其后(~6ms / ~1.6k),在检索准确度上 2025 年提升了 35%。
来源:15 Best Open-Source RAG Frameworks 2026 - Firecrawl | Top 10 RAG Frameworks by Stars 2026 | RAG Frameworks Comparison
八、评估框架
8.1 RAGAS — 标准评估框架
RAGAS(Retrieval Augmented Generation Assessment)是目前最广泛使用的 RAG 评估框架,支持无参考答案评估。
核心指标:
| 指标 | 评估维度 | 描述 |
|---|---|---|
| Context Precision | 检索质量 | 检索到的文档中有多少是相关的 |
| Context Recall | 检索质量 | 所有相关文档中被检索到的比例 |
| Faithfulness | 生成质量 | 答案是否忠实于检索到的上下文 |
| Answer Relevancy | 生成质量 | 答案是否与问题相关 |
| Answer Correctness | 生成质量 | 答案是否正确(需要参考答案) |
| Noise Sensitivity | 鲁棒性 | 对不相关检索内容的抵抗力 |
8.2 其他评估工具
| 工具 | 特点 |
|---|---|
| ARES | 自动化 RAG 评估,支持自定义指标 |
| LangSmith | LangChain 配套的追踪和评估平台 |
| AWS Bedrock Evaluation | 集成 AWS 生态的评估服务 |
| Vertex AI Evaluation | Google Cloud 生态评估 |
| Maxim | 专注 RAG 的端到端评估平台 |
8.3 主要 RAG 基准测试
| 基准 | 场景 | 说明 |
|---|---|---|
| RAGBench | 通用 | 综合 RAG 系统基准 |
| CRAG | 复杂推理 | 需要纠正和复杂推理的 RAG 评估 |
| LegalBench-RAG | 法律 | 法律领域专用 |
| T2-RAGBench | 多领域 | 跨领域 RAG 评估 |
来源:RAGAS 官方文档 | RAG Evaluation 2026 - Label Your Data | Top 5 RAG Evaluation Platforms 2026 - Maxim
九、生产最佳实践
9.1 推荐架构(2026 年)
对于大多数生产场景,推荐 Advanced RAG + Agentic 决策层 的组合:
flowchart TD
A["用户输入"] --> B["Agent 路由层"]
B --> C{"问题复杂度?"}
C -->|"简单事实查询"| D["单次混合检索"]
C -->|"复杂推理"| E["多步 Agentic 检索"]
C -->|"全局概览"| F["Graph RAG"]
C -->|"实时数据"| G["工具调用"]
D --> H["Cross-Encoder 重排序"]
E --> H
F --> H
G --> I["数据整合"]
H --> J["上下文构建"]
I --> J
J --> K["LLM 生成"]
K --> L["Faithfulness 检查"]
L --> M{"通过?"}
M -->|"是"| N["输出答案"]
M -->|"否"| B
9.2 技术栈推荐
| 层级 | 推荐方案 | 备选 |
|---|---|---|
| 编排框架 | LangGraph(Agentic)/ LlamaIndex(数据密集) | Haystack(企业) |
| 向量数据库 | Qdrant / Weaviate | Milvus(超大规模)/ pgvector(已有 PG) |
| Embedding | Voyage-3-large / Cohere embed-v4 | BGE-M3(开源)/ Qwen3(中文) |
| 重排序 | Cohere Rerank / ColBERT | BGE-Reranker(开源) |
| LLM | Claude 3.5 Sonnet / GPT-4o | DeepSeek V3(成本敏感) |
| 评估 | RAGAS + LangSmith | Maxim |
| 分块 | RecursiveCharacter(默认)/ 语义分块(长文档) | 命题分块(高精度) |
9.3 关键性能指标
| 指标 | 目标值 | 说明 |
|---|---|---|
| Context Precision | 大于 0.85 | 检索到的内容与问题高度相关 |
| Context Recall | 大于 0.80 | 不遗漏重要信息 |
| Faithfulness | 大于 0.90 | 答案忠实于检索内容,不产生幻觉 |
| Answer Relevancy | 大于 0.85 | 答案切中问题要害 |
| 端到端延迟 | 3 秒以内 | 用户可接受的响应时间 |
9.4 常见陷阱
| 陷阱 | 描述 | 解决方案 |
|---|---|---|
| 分块太大 | 包含太多无关信息,稀释相关内容 | 使用 400-512 tokens 的块大小 |
| 分块太小 | 丢失上下文,碎片化严重 | 增加 overlap,或使用语义分块 |
| 只用向量检索 | 遗漏精确关键词匹配的结果 | 混合检索(BM25 + Dense) |
| 忽略重排序 | 初始检索质量不足 | 加入 Cross-Encoder 重排序 |
| Context 窗口浪费 | 检索内容填满窗口但质量低 | 上下文压缩、去重 |
| 一刀切架构 | 所有查询走同一管道 | 加入 Agent 路由层,按复杂度选择策略 |
十、总结
技术选型决策树
flowchart TD
A["新建 RAG 系统"] --> B{"数据类型?"}
B -->|"通用文本"| C{"规模?"}
B -->|"实体密集型"| D["Graph RAG"]
B -->|"多模态"| E["Multimodal RAG"]
C -->|"原型/小规模"| F["LlamaIndex + ChromaDB + OpenAI Embedding"]
C -->|"生产/中规模"| G["LangGraph + Qdrant + Voyage/Cohere Embedding"]
C -->|"企业/大规模"| H["Haystack + Milvus/Weaviate + 自部署 Embedding"]
D --> I["Microsoft GraphRAG / LightRAG"]
E --> J["LlamaIndex Multi-modal"]
F --> K["评估: RAGAS"]
G --> K
H --> K
I --> K
J --> K
一句话总结
2026 年的 RAG 不再是简单的”检索+生成”管道,而是以 Agentic RAG 为核心范式,结合 混合检索 + 重排序 的检索策略、Graph RAG 的结构化知识理解、和 RAGAS 的系统化评估,构建自适应、高可靠的知识增强 AI 系统。
十一、代码实战示例
11.1 Naive RAG — LlamaIndex 快速上手
最简单的 RAG 实现,5 分钟内跑通:
# pip install llama-index llama-index-llms-openai llama-index-embeddings-openai
from llama_index.core import VectorStoreIndex, SimpleDirectoryReader
# 1. 加载文档documents = SimpleDirectoryReader("./data").load_data()
# 2. 构建索引(自动分块 + 嵌入)index = VectorStoreIndex.from_documents(documents)
# 3. 查询query_engine = index.as_query_engine()response = query_engine.query("什么是 RAG?")print(response)这段代码做了什么:
SimpleDirectoryReader读取./data目录下的所有文档(PDF、TXT、Markdown 等)VectorStoreIndex自动将文档分块、生成 Embedding、存入内存向量库as_query_engine()创建查询引擎,自动检索 Top-K 相关文档并交给 LLM 生成答案
来源:LlamaIndex Introduction to RAG
11.2 Advanced RAG — 混合检索 + 重排序
使用 LangChain 实现 BM25 + 向量混合检索,加上 Cross-Encoder 重排序:
# pip install langchain langchain-openai langchain-community# pip install faiss-cpu rank_bm25 sentence-transformers
from langchain_community.retrievers import BM25Retrieverfrom langchain_community.vectorstores import FAISSfrom langchain_openai import OpenAIEmbeddingsfrom langchain.retrievers import EnsembleRetrieverfrom langchain.retrievers import ContextualCompressionRetrieverfrom langchain.retrievers.document_compressors import CrossEncoderRerankerfrom langchain_community.cross_encoders import HuggingFaceCrossEncoderfrom langchain_openai import ChatOpenAIfrom langchain_core.prompts import ChatPromptTemplatefrom langchain_core.output_parsers import StrOutputParserfrom langchain_core.runnables import RunnablePassthrough
# ---------- 1. 准备文档 ----------from langchain.text_splitter import RecursiveCharacterTextSplitter
text_splitter = RecursiveCharacterTextSplitter( chunk_size=512, # 推荐 400-512 tokens chunk_overlap=50, # 10% 重叠 separators=["\n\n", "\n", "。", ".", " "])# 假设 documents 已经加载chunks = text_splitter.split_documents(documents)
# ---------- 2. 构建双路检索器 ----------# 稠密向量检索embeddings = OpenAIEmbeddings(model="text-embedding-3-large")vectorstore = FAISS.from_documents(chunks, embeddings)vector_retriever = vectorstore.as_retriever(search_kwargs={"k": 20})
# 稀疏 BM25 检索bm25_retriever = BM25Retriever.from_documents(chunks)bm25_retriever.k = 20
# 混合检索(RRF 融合)ensemble_retriever = EnsembleRetriever( retrievers=[bm25_retriever, vector_retriever], weights=[0.4, 0.6] # BM25 权重 0.4,向量权重 0.6)
# ---------- 3. Cross-Encoder 重排序 ----------cross_encoder = HuggingFaceCrossEncoder( model_name="cross-encoder/ms-marco-MiniLM-L-6-v2")reranker = CrossEncoderReranker( model=cross_encoder, top_n=5 # 重排后取 Top 5)retriever = ContextualCompressionRetriever( base_compressor=reranker, base_retriever=ensemble_retriever)
# ---------- 4. 生成答案 ----------llm = ChatOpenAI(model="gpt-4o", temperature=0)
prompt = ChatPromptTemplate.from_template("""基于以下检索到的上下文回答问题。如果上下文中没有相关信息,请说明无法回答。
上下文:{context}
问题:{question}
答案:""")
def format_docs(docs): return "\n\n".join(doc.page_content for doc in docs)
chain = ( {"context": retriever | format_docs, "question": RunnablePassthrough()} | prompt | llm | StrOutputParser())
answer = chain.invoke("RAG 系统的最佳分块策略是什么?")print(answer)关键设计决策:
chunk_size=512:平衡上下文完整性和检索精度weights=[0.4, 0.6]:稠密检索权重略高,兼顾语义和关键词top_n=5:重排后只取最相关的 5 个文档,避免上下文窗口浪费cross-encoder/ms-marco-MiniLM-L-6-v2:轻量级 Cross-Encoder,延迟低
来源:Advanced RAG with Hybrid Search and Reranking | LangChain EnsembleRetriever 文档
11.3 Agentic RAG — LangGraph 实现
使用 LangGraph 构建一个能自我纠错的 Agentic RAG Agent:
# pip install langgraph langchain-openai langchain-community
from typing import TypedDict, Annotated, Literalfrom langgraph.graph import StateGraph, ENDfrom langchain_openai import ChatOpenAIfrom langchain_core.messages import HumanMessage
# ---------- 1. 定义状态 ----------class AgentState(TypedDict): question: str documents: list generation: str retry_count: int
# ---------- 2. 定义节点 ----------llm = ChatOpenAI(model="gpt-4o", temperature=0)
def retrieve(state: AgentState) -> AgentState: """检索相关文档""" question = state["question"] # 假设 retriever 已经定义(如上面的混合检索器) documents = retriever.invoke(question) return {"documents": documents, "retry_count": state.get("retry_count", 0)}
def grade_documents(state: AgentState) -> AgentState: """评估检索文档的相关性""" question = state["question"] documents = state["documents"]
graded_docs = [] for doc in documents: response = llm.invoke([HumanMessage(content=f""" 判断以下文档是否与问题相关。只回答 "yes" 或 "no"。 问题:{question} 文档:{doc.page_content} """)]) if "yes" in response.content.lower(): graded_docs.append(doc)
return {"documents": graded_docs}
def decide_to_generate(state: AgentState) -> Literal["generate", "rewrite"]: """决定是生成答案还是改写查询""" if len(state["documents"]) > 0: return "generate" elif state.get("retry_count", 0) >= 2: return "generate" # 重试上限,强制生成 return "rewrite"
def generate(state: AgentState) -> AgentState: """基于检索文档生成答案""" question = state["question"] documents = state["documents"] context = "\n\n".join(doc.page_content for doc in documents)
response = llm.invoke([HumanMessage(content=f""" 基于以下上下文回答问题。如果上下文不足,请说明。 上下文:{context} 问题:{question} """)]) return {"generation": response.content}
def rewrite_query(state: AgentState) -> AgentState: """改写查询以获得更好的检索结果""" question = state["question"] response = llm.invoke([HumanMessage(content=f""" 原始问题的检索结果不佳,请改写以下问题使其更适合检索: 原始问题:{question} 改写后的问题: """)]) return { "question": response.content, "retry_count": state.get("retry_count", 0) + 1 }
# ---------- 3. 构建图 ----------workflow = StateGraph(AgentState)
# 添加节点workflow.add_node("retrieve", retrieve)workflow.add_node("grade_documents", grade_documents)workflow.add_node("generate", generate)workflow.add_node("rewrite_query", rewrite_query)
# 添加边workflow.set_entry_point("retrieve")workflow.add_edge("retrieve", "grade_documents")workflow.add_conditional_edges( "grade_documents", decide_to_generate, {"generate": "generate", "rewrite": "rewrite_query"})workflow.add_edge("rewrite_query", "retrieve") # 改写后重新检索workflow.add_edge("generate", END)
# 编译app = workflow.compile()
# ---------- 4. 运行 ----------result = app.invoke({ "question": "Agentic RAG 和传统 RAG 有什么区别?", "documents": [], "generation": "", "retry_count": 0})print(result["generation"])工作流程:
flowchart TD
A["用户问题"] --> B["retrieve: 混合检索"]
B --> C["grade_documents: 评估相关性"]
C --> D{"有相关文档?"}
D -->|"有"| E["generate: 生成答案"]
D -->|"没有且未超限"| F["rewrite_query: 改写查询"]
F --> B
D -->|"没有但已超限"| E
E --> G["输出答案"]
来源:LangChain Agentic RAG 文档 | Building Agentic RAG with LangGraph
11.4 Graph RAG — Microsoft GraphRAG 快速上手
使用 Microsoft 开源的 GraphRAG 从文档构建知识图谱并进行查询:
# 安装pip install graphrag
# 创建项目mkdir graphrag_project && cd graphrag_project
# 初始化(会提示选择 LLM 和 Embedding 模型)graphrag init
# 将文档放入 input/ 目录cp your_documents.txt input/
# 构建索引(实体抽取 + 关系抽取 + 社区检测 + 摘要生成)graphrag index
# 本地查询(适合具体问题)graphrag query --method local "什么是 Agentic RAG?"
# 全局查询(适合概览性问题)graphrag query --method global "总结 RAG 技术的发展趋势"GraphRAG 的两种查询模式:
| 模式 | 适用场景 | 原理 |
|---|---|---|
| Local Search | 具体事实性问题 | 从实体出发,遍历相关子图,提取局部信息 |
| Global Search | 概览性、总结性问题 | 利用社区层级摘要,从全局视角回答 |
用 Python API 进行更细粒度控制:
# pip install graphrag neo4j
import graphragfrom graphrag.query.structured_search.local_search import LocalSearchfrom graphrag.query.structured_search.global_search import GlobalSearch
# 使用 Neo4j 作为图存储后端from neo4j import GraphDatabase
driver = GraphDatabase.driver( "bolt://localhost:7687", auth=("neo4j", "password"))
# Local Search: 从实体出发的子图检索local_search = LocalSearch( llm=llm, context_builder=context_builder, token_encoder=token_encoder, llm_params={"max_tokens": 2000, "temperature": 0},)result = local_search.search("Agentic RAG 的核心设计模式有哪些?")print(result.response)来源:Microsoft GraphRAG 官方文档 | GraphRAG Getting Started | Neo4j GraphRAG Python Package
11.5 RAGAS 评估示例
使用 RAGAS 框架评估 RAG 系统的质量:
# pip install ragas langchain-openai
from ragas import evaluatefrom ragas.metrics import ( faithfulness, answer_relevancy, context_precision, context_recall,)from ragas import EvaluationDataset, SingleTurnSample
# ---------- 1. 准备评估数据 ----------samples = [ SingleTurnSample( user_input="RAG 的核心架构是什么?", retrieved_contexts=[ "RAG 由检索器和生成器两部分组成...", "检索器负责从知识库中找到相关文档..." ], response="RAG 的核心架构包含检索器和生成器...", reference="RAG 由检索器(Retriever)和生成器(Generator)组成..." ), SingleTurnSample( user_input="什么是混合检索?", retrieved_contexts=[ "混合检索结合 BM25 稀疏检索和向量稠密检索...", ], response="混合检索是将 BM25 和向量检索结合的技术...", reference="混合检索结合稀疏(BM25)和稠密(向量)两种检索方式..." ),]
dataset = EvaluationDataset(samples=samples)
# ---------- 2. 运行评估 ----------results = evaluate( dataset=dataset, metrics=[ faithfulness, # 答案是否忠实于上下文 answer_relevancy, # 答案是否与问题相关 context_precision, # 检索内容的精确度 context_recall, # 检索内容的召回率 ],)
# ---------- 3. 查看结果 ----------print(results)# {# "faithfulness": 0.92,# "answer_relevancy": 0.88,# "context_precision": 0.85,# "context_recall": 0.80,# }
# 转为 DataFrame 查看详细结果df = results.to_pandas()print(df)指标解读:
| 指标 | 含义 | 目标值 | 不达标时的优化方向 |
|---|---|---|---|
| Faithfulness | 答案中的声明是否都能在上下文中找到依据 | 大于 0.90 | 优化 Prompt,减少 LLM 幻觉 |
| Answer Relevancy | 答案是否回答了用户的问题 | 大于 0.85 | 优化 Prompt 模板 |
| Context Precision | 检索到的文档中相关文档的比例 | 大于 0.85 | 优化检索策略、加入重排序 |
| Context Recall | 回答所需的信息是否都被检索到了 | 大于 0.80 | 增加 Top-K、优化分块策略 |
来源:RAGAS 官方文档 | RAGAS 论文 - arXiv
十二、行业应用案例
12.1 客服与技术支持
Shopify — AI 商家助手 Sidekick
| 维度 | 详情 |
|---|---|
| 场景 | 电商商家的产品咨询、账户问题、故障排除 |
| RAG 架构 | 从店铺库存、订单历史、FAQ 知识库检索,LLM 生成个性化回复 |
| 效果 | 回复准确率显著提升,减少人工客服介入 |
DoorDash — 骑手支持系统
| 维度 | 详情 |
|---|---|
| 场景 | 骑手问题报告处理(配送异常、费用争议等) |
| RAG 架构 | 对话压缩 -> 知识库检索(文章 + 历史案例)-> LLM 生成回复 + Guardrail 安全检查 + LLM Judge 质量评估 |
| 特色 | 三层架构(RAG + Guardrail + Judge)确保回复安全性和质量 |
行业数据
RAG 驱动的 AI 客服可以分流高达 50% 的常规工单,降低运营成本 30%,提升客户满意度约 27%。Gartner 预测到 2026 年,对话式 AI 将为客服中心节省 800 亿美元的人工成本。
来源:RAG in Customer Support 2025 Benchmark - Wonderchat | 10 RAG Examples from Real Companies - Evidently AI
12.2 金融服务
JPMorgan Chase — EVEE 智能问答系统
| 维度 | 详情 |
|---|---|
| 场景 | 呼叫中心(欺诈与理赔、房贷、财富管理、催收) |
| RAG 架构 | 从内部政策文档、客户记录、合规规则库中检索,实时辅助客服人员 |
| 规模 | 每年处理数百万次客户交互 |
| 效果 | 客服响应速度和准确性大幅提升 |
金融分析应用
| 场景 | RAG 价值 |
|---|---|
| 投资研究 | 自动拉取实时市场数据、财报、内部指标,为每位分析师生成定制分析 |
| 合规审查 | 从监管文件库中检索相关法规,辅助合规判断 |
| 风险评估 | 结合历史数据和实时信息,生成风险评估报告 |
来源:Top 10 RAG Use Cases - Uptech | 10 RAG Use Cases 2026 - Stack AI
12.3 企业知识管理
Siemens — 内部知识管理平台
| 维度 | 详情 |
|---|---|
| 场景 | 工程师查询技术文档、维护手册、项目历史 |
| RAG 架构 | 集成到数字助手平台,从内部文档和数据库中快速检索 |
| 效果 | 为技术查询提供相关文档和上下文摘要,大幅缩短信息查找时间 |
其他企业案例
| 公司 | 场景 | RAG 方案 |
|---|---|---|
| Workday | HR 政策查询、员工自助 | RAG 集成到企业平台 |
| ServiceNow | IT 服务管理、工单处理 | RAG 驱动的智能工单系统 |
| The Economist | 内容检索与分析 | 基于 Haystack 的生产 RAG |
| Oxford University Press | 学术出版物检索 | 基于 Haystack 的语义搜索 |
来源:RAG for Enterprise - Aplyca | 10 RAG Examples - Evidently AI
12.4 医疗健康
| 场景 | RAG 价值 | 关键要求 |
|---|---|---|
| 临床决策支持 | 从医学文献、临床指南中检索,辅助诊断决策 | Faithfulness 极高要求 |
| 患者咨询 | 基于病历和保险信息,提供个性化治疗信息 | 隐私保护(HIPAA) |
| 药物相互作用 | 从药物数据库检索,预警潜在风险 | 实时性、准确性 |
| 医学研究 | 从 PubMed 等文献库检索,加速文献综述 | 多语言、大规模 |
医疗 RAG 的核心挑战是 Faithfulness(忠实度)要求极高 — 任何幻觉都可能造成严重后果。推荐使用 Corrective RAG + 多源交叉验证。
来源:Comparative Evaluation of Advanced Chunking for RAG in Clinical Decision Support
12.5 法律研究
| 场景 | RAG 价值 | 技术要点 |
|---|---|---|
| 案例检索 | 从判例库中检索相关案例,辅助律师研究 | Graph RAG(实体关系丰富) |
| 合同审查 | 从条款库中检索类似条款,识别风险点 | 精确匹配(BM25 权重高) |
| 法规合规 | 检索最新法规变更,确保合规性 | 实时更新索引 |
| 法律文书生成 | 基于检索到的先例和模板,生成法律文书 | Faithfulness + 引用溯源 |
法律场景特别适合 Graph RAG — 法律实体(案例、法条、判决、当事人)之间有丰富的关系网络。Microsoft GraphRAG 的搜索精度可达 99%。
12.6 应用效果量化数据
| 指标 | 数据 | 来源 |
|---|---|---|
| 常规工单分流率 | 高达 50% | Wonderchat 2025 基准报告 |
| 运营成本降低 | 高达 30% | Wonderchat 2025 基准报告 |
| 客户满意度提升 | ~27% | Wonderchat 2025 基准报告 |
| 复杂查询处理提升 | 35-50%(Agentic RAG) | LangSmith 150 企业数据(Q4 2025) |
| Agentic RAG 额外延迟 | 200-400ms | LangSmith 生产追踪 |
| 2026 年客服 AI 节省人工成本 | $800 亿 | Gartner 预测 |
12.7 市场规模
| 预测来源 | 2024 | 2030 | CAGR |
|---|---|---|---|
| 预测 A | $12 亿 | $110 亿 | 49.1% |
| 预测 B | $16 亿(2025) | $326 亿(2034) | ~40% |
来源:RAG Market Growth - Stack AI | 10 RAG Architectures Enterprise 2026 - Techment
十三、参考文献
核心综述论文
| 论文 | 年份 | 关键贡献 |
|---|---|---|
| Retrieval-Augmented Generation for Large Language Models: A Survey | 2023 | RAG 领域第一篇全面综述,定义 Naive/Advanced/Modular RAG 三代框架 |
| A Comprehensive Survey of RAG: Evolution, Current Landscape and Future Directions | 2024 | 追踪 RAG 从基础概念到 SOTA 的完整演进 |
| Agentic Retrieval-Augmented Generation: A Survey on Agentic RAG | 2025 | 首篇 Agentic RAG 专题综述,定义四大设计模式 |
| RAG: A Comprehensive Survey of Architectures, Enhancements, and Robustness Frontiers | 2025 | 最新最全面的 RAG 架构综述 |
| RAG Evaluation in the Era of LLMs: A Comprehensive Survey | 2025 | RAG 评估方法全面综述 |
关键方法论文
| 论文 | 年份 | 关键贡献 |
|---|---|---|
| RAPTOR: Recursive Abstractive Processing for Tree-Organized Retrieval | 2024 | 递归树结构文档索引,支持多层次抽象检索 |
| Corrective Retrieval Augmented Generation (CRAG) | 2024 | 检索结果自动纠错机制 |
| Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection | 2023 | 模型自主决定何时检索、自我批评 |
| From Local to Global: A Graph RAG Approach to Query-Focused Summarization | 2024 | Microsoft GraphRAG,知识图谱 + 社区层级摘要 |
| RAGAS: Automated Evaluation of Retrieval Augmented Generation | 2023 | RAG 评估标准框架 |
| Reconstructing Context: Evaluating Advanced Chunking Strategies for RAG | 2025 | 分块策略系统评估 |
| Late Chunking: Contextual Chunk Embeddings | 2024 | Late Chunking 方法 |
实战指南与基准
| 资源 | 类型 | 链接 |
|---|---|---|
| LlamaIndex RAG 入门 | 官方文档 | developers.llamaindex.ai |
| LangChain Agentic RAG | 官方教程 | docs.langchain.com |
| Microsoft GraphRAG | 官方文档 | microsoft.github.io/graphrag |
| RAGAS 指标文档 | 官方文档 | docs.ragas.io |
| Haystack 文档 | 官方文档 | docs.haystack.deepset.ai |
| Dify 文档 | 官方文档 | docs.dify.ai |
| Vector Database Comparison 2025 | 对比指南 | liquidmetal.ai |
| Best Chunking Strategies 2025 | 实践指南 | firecrawl.dev |
| Best Embedding Models 2026 | 选型指南 | elephas.app |
| 15 Best Open-Source RAG Frameworks 2026 | 框架对比 | firecrawl.dev |
| Top 10 RAG Frameworks by GitHub Stars 2026 | 框架排名 | Medium |
| RAG in Customer Support 2025 Benchmark | 行业报告 | wonderchat.io |
| 10 RAG Examples from Real Companies | 案例集 | evidentlyai.com |
开源项目
| 项目 | Stars | 链接 |
|---|---|---|
| LangChain | ~103k | github.com/langchain-ai/langchain |
| Dify | ~70k+ | github.com/langgenius/dify |
| LlamaIndex | ~40k | github.com/run-llama/llama_index |
| DSPy | ~22k | github.com/stanfordnlp/dspy |
| Haystack | ~20k | github.com/deepset-ai/haystack |
| Microsoft GraphRAG | ~27k | github.com/microsoft/graphrag |
| LangGraph | ~10k | github.com/langchain-ai/langgraph |
| RAGAS | ~8k | github.com/explodinggradients/ragas |
| Awesome-GraphRAG | ~3k | github.com/DEEP-PolyU/Awesome-GraphRAG |