前面我们分析了 RAGFlow，它解决了"从文档到答案"的核心问题。但 RAG 领域发展极快，除了文档解析、Chunking、混合检索这些基础能力，还有很多值得关注的技术方向。
这篇文章会系统梳理 RAG 的技术演进路线，帮你建立完整的知识图谱。
一、RAG 的技术演进
RAG 1.0：检索 + 生成
Query → 向量检索 → LLM 生成
RAG 2.0：多路检索 + Rerank + 引用溯源
Query → 多路检索 → 融合 → Rerank → 生成 + 引用
RAG 3.0：Agentic RAG + Graph RAG + 多模态
Query → Agent 规划 → 多轮检索/推理 → 反思修正 → 生成
下面按技术方向逐一展开。
二、Graph RAG：知识图谱 + RAG
本文对 Graph RAG 做概要介绍，详细的开源项目分析和选型指南请参阅 Graph RAG 开源项目全景：从微软 GraphRAG 到 LightRAG。
为什么需要 Graph RAG
传统 RAG 的局限：
问题："A 公司的合作方的竞争对手有哪些？"
传统 RAG：
1. 检索"A 公司的合作方" → 找到 B 公司
2. 检索"B 公司的竞争对手" → 找到 C、D 公司
问题：需要多轮检索，且中间结果可能丢失
Graph RAG：
1. 从知识图谱中找到 A → 合作 → B
2. 从知识图谱中找到 B → 竞争 → C、D
优势：一次图遍历即可完成多跳推理
Graph RAG 的架构
┌──────────────────────────────────────────────────────┐
│ Graph RAG Pipeline │
└──────────────────────────────────────────────────────┘
│
┌───────────────┼───────────────┐
▼ ▼ ▼
┌─────────┐ ┌──────────┐ ┌──────────┐
│ 文档输入 │ │ 实体抽取 │ │ 关系抽取 │
└────┬────┘ └────┬─────┘ └────┬─────┘
│ │ │
└──────────────┼───────────────┘
▼
┌──────────────────┐
│ 知识图谱构建 │
│ (Neo4j / NetworkX) │
└────────┬─────────┘
│
┌──────────────┼───────────────┐
▼ ▼ ▼
┌─────────┐ ┌──────────┐ ┌──────────┐
│ 向量检索 │ │ 图检索 │ │ 混合检索 │
└────┬────┘ └────┬─────┘ └────┬─────┘
│ │ │
└──────────────┼───────────────┘
▼
┌──────────────────┐
│ LLM 生成答案 │
└──────────────────┘
核心技术点
1. 实体抽取
输入文档："苹果公司由史蒂夫·乔布斯于 1976 年创立，总部位于加利福尼亚州库比蒂诺。"
实体抽取结果：
- 苹果公司（Organization）
- 史蒂夫·乔布斯（Person）
- 1976 年（Date）
- 加利福尼亚州库比蒂诺（Location）
技术方案：
- NER 模型（spaCy、Stanford NER）
- LLM 抽取（GPT-4、Qwen）
- 开源工具（DeepKE、OpenIE）
2. 关系抽取
关系抽取结果：
- 苹果公司 -- 创立者 --> 史蒂夫·乔布斯
- 苹果公司 -- 创立时间 --> 1976 年
- 苹果公司 -- 总部位置 --> 加利福尼亚州库比蒂诺
3. 图检索策略
策略 1：子图检索
- 找到问题中的实体节点
- 扩展 N 跳邻居
- 将子图转为文本，喂给 LLM
策略 2：路径检索
- 找到起点和终点实体
- 检索两点间的路径
- 路径上的节点/边作为上下文
策略 3：社区检索
- 预先对图谱做社区发现
- 检索相关社区
- 社区摘要作为上下文
代表项目
| 项目 | 特点 | 适用场景 |
|---|---|---|
| Microsoft GraphRAG | 微软官方，社区摘要 | 大规模文档全局理解 |
| LightRAG | 轻量级，无图数据库依赖 | 快速部署 |
| Neo4j + LangChain | 成熟图数据库，生态完善 | 企业级应用 |
| LlamaIndex GraphRAG | 与 LlamaIndex 深度集成 | 已有 LlamaIndex 项目 |
适用场景
✅ 推荐使用 Graph RAG：
- 需要多跳推理（"A 的 B 的 C 是什么"）
- 需要全局理解（"这篇文章的核心观点"）
- 实体关系密集（知识库、企业图谱）
- 需要可解释的推理路径
❌ 不推荐：
- 文档间无关联
- 问题简单，单次检索可解
- 实体稀疏，图构建成本高
三、Agentic RAG：Agent + RAG
从被动检索到主动规划
传统 RAG（被动）：
Query → 检索 → 生成
问题：检索策略固定，无法应对复杂问题
Agentic RAG（主动）：
Query → Agent 规划 → 执行 → 反思 → 再规划 → ...
Agentic RAG 的核心能力
1. 查询理解与改写
原始问题："那个产品怎么样"
↓ LLM 分析
问题太模糊，需要澄清
改写策略：
1. 分解问题："那个产品" → 识别具体产品
2. 扩展问题：生成多个相关 Query
3. HyDE：生成假设性答案，用答案检索
示例：
Query: "报销流程"
↓
改写为：
1. "公司报销流程步骤"
2. "报销需要哪些材料"
3. "报销审批流程"
2. 迭代检索
第一轮检索：
Query: "A 公司的融资情况"
结果: A 公司 B 轮融资 5000 万
判断：信息不完整，缺少投资方
↓
第二轮检索：
Query: "A 公司 B 轮投资方"
结果: 红杉资本领投
判断：信息完整
↓
生成答案
3. 工具调用
Agent 可用的工具：
- 向量检索：检索内部知识库
- 关键词检索：BM25 搜索
- 联网搜索：Google/Bing API
- SQL 查询：查询结构化数据
- API 调用：获取实时信息
示例：
Query: "今天北京天气怎么样，适合户外活动吗？"
↓ Agent 规划
1. 调用天气 API 获取北京天气
2. 检索知识库中"户外活动适宜条件"
3. 综合判断并回答
4. 自我反思
生成答案后，Agent 自我评估：
评估维度：
- 答案是否完整？
- 是否需要补充检索？
- 是否有矛盾信息？
示例：
答案："A 公司成立于 2010 年"
反思：检索结果中有两个年份（2010 和 2012），需要验证
↓
再次检索："A 公司成立时间 官方"
↓
修正答案
Agentic RAG 架构
┌──────────────────────────────────────────────────────┐
│ Agentic RAG │
└──────────────────────────────────────────────────────┘
│
▼
┌──────────────────┐
│ Query 分析 │
│ - 意图识别 │
│ - 实体抽取 │
│ - 查询改写 │
└────────┬─────────┘
│
▼
┌──────────────────┐
│ 规划器 │
│ - 分解任务 │
│ - 选择工具 │
│ - 生成执行计划 │
└────────┬─────────┘
│
┌──────────────┼───────────────┐
▼ ▼ ▼
┌─────────┐ ┌──────────┐ ┌──────────┐
│ 向量检索 │ │ 联网搜索 │ │ SQL 查询 │
└────┬────┘ └────┬─────┘ └────┬─────┘
│ │ │
└──────────────┼───────────────┘
▼
┌──────────────────┐
│ 反思器 │
│ - 结果评估 │
│ - 是否继续检索 │
│ - 是否需要修正 │
└────────┬─────────┘
│
▼
┌──────────────────┐
│ LLM 生成答案 │
└──────────────────┘
代表框架
| 框架 | 特点 | 适用场景 |
|---|---|---|
| LangGraph | LangChain 出品，状态机模型 | 复杂工作流 |
| AutoGPT + RAG | 自主 Agent | 开放域任务 |
| CrewAI | 多 Agent 协作 | 团队式任务 |
| LlamaIndex Agent | 内置 RAG Agent | 快速构建 |
适用场景
✅ 推荐使用 Agentic RAG：
- 问题复杂，需要多步推理
- 需要调用多种工具
- 需要实时信息（联网、API）
- 需要自我纠错
❌ 不推荐：
- 问题简单，单次检索可解
- 对延迟敏感（Agent 会增加延迟）
- 成本敏感（多轮 LLM 调用）
四、多模态 RAG
为什么需要多模态
企业知识库不只是文本：
- 产品手册：文字 + 图片 + 示意图
- 技术文档：文字 + 代码 + 架构图
- 财务报告：文字 + 表格 + 图表
- 培训视频：音频 + 视频 + 字幕
多模态 RAG 架构
┌──────────────────────────────────────────────────────┐
│ 多模态 RAG Pipeline │
└──────────────────────────────────────────────────────┘
│
┌───────────────┼───────────────┐
▼ ▼ ▼
┌─────────┐ ┌──────────┐ ┌──────────┐
│ 文本 │ │ 图片 │ │ 表格 │
│ 处理 │ │ 处理 │ │ 处理 │
└────┬────┘ └────┬─────┘ └────┬─────┘
│ │ │
▼ ▼ ▼
┌─────────┐ ┌──────────┐ ┌──────────┐
│ 文本 │ │ VLM 描述 │ │ 结构化 │
│ Embedding│ │ Embedding│ │ 存储 │
└────┬────┘ └────┬─────┘ └────┬─────┘
│ │ │
└──────────────┼───────────────┘
▼
┌──────────────────┐
│ 统一向量存储 │
└────────┬─────────┘
│
▼
┌──────────────────┐
│ 多模态检索 │
│ - 文本 Query │
│ - 图片 Query │
└────────┬─────────┘
│
▼
┌──────────────────┐
│ 多模态生成 │
│ (GPT-4V, Qwen-VL)│
└──────────────────┘
各模态的处理方式
1. 图片
方案 1：VLM 描述
图片 → VLM → 文字描述 → Embedding
方案 2：直接 Embedding
图片 → CLIP/SigLIP → 图片向量
方案 3：混合
图片 → VLM 描述 + CLIP 向量 → 双路检索
2. 表格
方案 1：Markdown 化
表格 → Markdown 格式 → Embedding
方案 2：结构化存储
表格 → DataFrame → SQL 数据库
查询时：自然语言 → SQL → 执行查询
方案 3：行列切分
表格 → 每行一个 Chunk → 保留表头上下文
3. 音频/视频
音频：
音频 → ASR → 文字 → Embedding
视频：
视频 → 关键帧提取 → VLM 描述 → Embedding
→ ASR（音轨） → 文字 → Embedding
代表技术
| 技术 | 用途 | 特点 |
|---|---|---|
| CLIP / SigLIP | 图文联合 Embedding | 支持以图搜文、以文搜图 |
| GPT-4V / Qwen-VL | 视觉语言模型 | 理解图片内容，生成描述 |
| ColPali | 端到端文档检索 | 直接用文档图片检索，无需 OCR |
| Whisper | 语音识别 | 音频转文字 |
适用场景
✅ 推荐使用多模态 RAG：
- 知识库包含大量图片/图表
- 需要检索产品图片
- 需要理解架构图/流程图
- 视频内容检索
❌ 不推荐：
- 纯文本知识库
- 对成本敏感（VLM 调用昂贵）
五、长上下文 vs RAG
长上下文模型的崛起
2023 年：Claude 2（100K）、GPT-4 Turbo（128K）
2024 年：Claude 3（200K）、Gemini 1.5 Pro（1M）、Kimi（200K）
2025 年：上下文窗口继续扩大...
长上下文能替代 RAG 吗？
长上下文方案：
Query + 全部文档 → LLM → 答案
优势：
- 不需要检索，不会遗漏信息
- 全局理解能力强
- 实现简单
劣势：
- 成本高（每 token 都要计费）
- 延迟高（处理长上下文需要时间）
- 不适合大规模知识库（100 万 token 放不下）
RAG 的优势
RAG 方案：
Query → 检索 Top-K → LLM → 答案
优势：
- 成本可控（只处理相关文档）
- 延迟低
- 可扩展（知识库无限大）
- 可追溯（知道答案来自哪里）
劣势：
- 可能检索不准，遗漏信息
- 缺乏全局理解
结论：互补而非替代
场景分析：
| 场景 | 推荐方案 | 理由 |
|------|----------|------|
| 小规模文档（<100K） | 长上下文 | 简单，不会遗漏 |
| 大规模知识库 | RAG | 成本、延迟可控 |
| 需要全局理解 | 长上下文 | RAG 擅长局部检索 |
| 需要精确引用 | RAG | 可追溯来源 |
| 实时更新知识库 | RAG | 长上下文需要重新处理 |
最佳实践：RAG + 长上下文
- RAG 检索相关文档
- 长上下文模型处理检索结果
- 兼顾成本和效果
六、检索技术进阶
1. Dense Retrieval 的演进
第一代：Single Vector（单向量）
文档 → 一个向量
问题：语义压缩过度，细节丢失
第二代：Multi-Vector（多向量，ColBERT）
文档 → 每个 token 一个向量
问题：存储成本高，但精度提升
第三代：Late Interaction（延迟交互，ColPali）
检索时不压缩，最后才做交互
优势：精度最高，适合文档检索
ColBERT 的核心思想
传统向量检索：
Query: "机器学习" → 向量 Q
Doc: "机器学习是人工智能的分支..." → 向量 D
相似度 = Q · D
ColBERT：
Query: "机器学习" → [q1, q2]（每个 token 一个向量）
Doc: "机器学习是人工智能的分支..." → [d1, d2, d3, d4, ...]
相似度 = Σ max(qi · dj) ← 每个 Query token 找最相似的 Doc token
优势：
- "机器学习"中的"机器"和"学习"分别匹配
- 精度更高
2. Query 理解技术
HyDE（Hypothetical Document Embeddings）
问题：Query 很短，语义信息不足
HyDE 的思路：
1. 让 LLM 生成一个假设性答案
2. 用假设答案的向量检索
3. 假设答案与真实文档更相似
示例：
Query: "Python 如何读取 JSON 文件？"
↓ LLM 生成假设答案
假设答案: "可以使用 json.load() 函数读取 JSON 文件。首先导入 json 模块，然后用 open() 打开文件..."
↓ 用假设答案检索
检索结果: 找到真实的 JSON 读取教程
Multi-Query（多查询）
问题：用户的 Query 可能表述不清
Multi-Query 的思路：
1. 用 LLM 生成多个相关 Query
2. 多路检索
3. 结果融合
示例：
Query: "报销流程"
↓ LLM 生成
Query 1: "公司报销流程步骤"
Query 2: "报销需要哪些材料"
Query 3: "报销审批流程"
↓ 多路检索，融合结果
3. 自适应检索（Self-RAG）
问题：不是所有问题都需要检索
Self-RAG 的思路：
1. LLM 自己判断是否需要检索
2. 如果需要，检索并生成
3. 生成后，LLM 自我评估答案质量
4. 如果不满意，重新检索
示例：
Query: "写一个 Python Hello World"
↓ LLM 判断
不需要检索（LLM 自己会写）
↓ 直接生成
Query: "公司最新的报销政策"
↓ LLM 判断
需要检索（LLM 不知道）
↓ 检索 → 生成
七、生成技术进阶
1. Citation（引用溯源）
RAG 的可信度关键：答案来自哪里？
输出格式：
答案：参数 timeout 的类型是 int，默认值是 30 秒。
引用：
[1] API 文档.pdf, 第 3 页, 表格 2
[2] 配置说明.md, 第 15 行
实现方式：
1. 检索时记录每个 Chunk 的来源
2. 生成时让 LLM 标注使用了哪些 Chunk
3. 前端支持点击引用跳转原文
2. Fact Checking（事实核查）
问题：RAG 也可能产生幻觉
方案：生成后验证
流程：
1. LLM 生成答案
2. 提取答案中的事实陈述
3. 再次检索验证每个事实
4. 标注置信度或修正错误
示例：
答案："A 公司成立于 2010 年，创始人张三"
↓ 提取事实
事实 1: A 公司成立于 2010 年
事实 2: 创始人是张三
↓ 验证
事实 1: ✅ 文档确认
事实 2: ❌ 文档说是李四，不是张三
↓ 修正
答案："A 公司成立于 2010 年，创始人李四"
八、工程优化
1. 增量索引
问题：知识库每天都在更新
方案：
- 只索引新增/修改的文档
- 向量数据库支持增量写入
- 版本管理（可回滚）
实现：
1. 记录每个文档的 hash
2. 检测变更
3. 只索引变更部分
4. 定期全量重建（避免碎片化）
2. 多级缓存
缓存层级：
Level 1: Exact Match Cache
完全相同的问题 → 直接返回缓存答案
命中率：10-20%
Level 2: Semantic Cache
语义相似的问题 → 返回缓存答案
示例："报销流程" ≈ "如何报销"
命中率：20-30%
Level 3: Query Cache
缓存检索结果，只重新生成
命中率：30-40%
效果：
- 延迟降低 60-80%
- 成本降低 50-70%
3. RAG 评估
评估维度：
检索质量：
- Recall@K：前 K 个结果中相关文档的比例
- MRR：正确答案的平均排名
- NDCG：考虑排序的检索质量
生成质量：
- Faithfulness：答案是否忠实于检索内容
- Relevance：答案是否回答了问题
- Coherence：答案是否连贯
端到端：
- Correctness：答案是否正确
- Completeness：答案是否完整
- Latency：响应延迟
评估工具：
- RAGAS：自动化 RAG 评估
- TruLens：LLM 应用评估
- DeepEval：开源评估框架
九、技术选型指南
按场景选择
场景 1：企业知识库（文档密集）
推荐：RAGFlow / Dify / FastGPT
理由：开箱即用，文档解析强
场景 2：需要多跳推理
推荐：GraphRAG / LightRAG
理由：知识图谱支持复杂推理
场景 3：需要 Agent 编排
推荐：LangGraph / CrewAI
理由：灵活的工作流控制
场景 4：多模态知识库
推荐：RAGFlow / LlamaIndex + VLM
理由：支持图片、表格、视频
场景 5：快速原型
推荐：Dify / AnythingLLM
理由：低代码，快速落地
场景 6：深度定制
推荐：LangChain / LlamaIndex
理由：底层控制能力强
按技术栈选择
已有 LangChain 项目：
→ 继续用 LangChain + LangGraph
已有 LlamaIndex 项目：
→ 继续用 LlamaIndex + GraphRAG
从零开始：
→ 考虑 RAGFlow（一站式）或 Dify（低代码）
需要图数据库：
→ Neo4j + LangChain/LlamaIndex
需要极致性能：
→ 自建向量库 + 自定义检索逻辑
十、开源项目速览
| 项目 | Stars | 特点 | 适用场景 |
|---|---|---|---|
| RAGFlow | 82K+ | DeepDoc 文档解析 | 企业知识库 |
| MinerU | 67K+ | 通用文档解析 | 文档转 Markdown |
| Dify | 50K+ | RAG + Agent 平台 | 低代码构建 |
| FastGPT | 20K+ | 国产 RAG 平台 | 快速落地 |
| LangGraph | 10K+ | Agent 编排 | 复杂工作流 |
| LightRAG | 10K+ | 轻量级 Graph RAG | 多跳推理 |
| GraphRAG | 10K+ | Microsoft 出品 | 企业级图谱 |
| QAnything | 10K+ | 多模态 RAG | 端到端方案 |
| AnythingLLM | 20K+ | 全功能平台 | 企业部署 |
十一、学习资源
必读论文：
- Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks（RAG 原始论文）
- Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection
- GraphRAG: Unlocking LLM Discovery on Narrative Private Data
- Dense Passage Retrieval for Open-Domain Question Answering
官方文档：
- LlamaIndex Documentation
- LangChain RAG Tutorial
- RAGFlow Documentation
评估框架：
- RAGAS: https://github.com/explodinggradients/ragas
- TruLens: https://www.trulens.org/
- DeepEval: https://github.com/confident-ai/deepeval
十二、总结
RAG 技术正在快速演进，从简单的"检索 + 生成"发展为复杂的多技术融合系统。
技术演进路线：
RAG 1.0 → RAG 2.0 → RAG 3.0
基础检索 → 多路融合 → Agent + Graph + 多模态
核心趋势：
1. 从被动检索到主动规划
2. 从单一模态到多模态融合
3. 从局部检索到全局理解
4. 从固定流程到自适应调整
选择技术方案时，关键是明确需求：
- 简单场景：用 RAGFlow、Dify 这类一站式方案
- 复杂推理：引入 Graph RAG
- Agent 编排：用 LangGraph
- 多模态：选择支持 VLM 的方案
- 深度定制：用 LangChain/LlamaIndex 自建
没有银弹，只有最适合的方案。
相关文章：