RAG技术框架的演进方向¶
Ch01.193 RAG技术框架的演进方向¶
📊 Level ⭐⭐ | 19.8KB |
entities/rag技术框架的演进方向.md
核心演进路径¶
| 架构 | 核心动作 | 解决的问题类型 | 发展阶段 |
|---|---|---|---|
| Classic RAG | retrieves（检索） | 一跳问答、FAQ、文档查询 | 第一代 |
| Graph RAG | connects（连接） | 依赖分析、影响分析、组织关系、供应链 | 第二代 |
| Agentic RAG | reasons（推理） | 多步骤调查、复杂归因、跨系统分析 | 第三代 |
一句话总结演进逻辑：
- Classic RAG 解决「资料在哪里」
- Graph RAG 解决「资料之间怎么连」
- Agentic RAG 解决「下一步该查什么」
三代框架详解¶
第一代：Classic RAG（检索式）¶
流程： 1. 文档切块（chunk）→ embedding → 入库向量数据库 2. 用户提问 → 问题 embedding → top K 相似片段召回 3. 拼上下文 → LLM 生成回答 适用场景： FAQ 问答、政策查询、产品手册、客服知识库、员工制度查询。 局限： 擅长「找到相关内容」，但不擅长「沿着关系继续往下找」。
第二代：Graph RAG（图谱式）¶
在文本检索之外增加知识图谱层，把知识拆成实体和关系：
- 实体： 人、产品、零件、团队、部门、供应商、客户、系统模块
-
关系： 员工 A 汇报给经理 B；产品 X 使用零件 Y；零件 Y 来自供应商 Z 适用场景： 影响分析、依赖分析、组织关系查询、审批链查询、供应链分析。 解决的核心问题：
-
多跳问题： 例如「A的导师的导师是谁？」——传统 RAG 只能找到 A 的导师=B，找不到 B 的导师=C。Graph RAG 通过图路径追踪找到答案。
- 全局理解： 例如「这部小说的主旨是什么？」——传统 RAG 擅长局部搜索但不擅长总结全书。Graph RAG 通过社区检测（如 Leiden 算法）将图谱分层，为每个簇预生成摘要。 局限： 建图和维护成本高；只能遍历已建模的节点和边。 代表框架： Microsoft GraphRAG、LlamaIndex、LightRAG
第三代：Agentic RAG（智能体式）¶
让 Agent 根据问题目标自己判断下一步该查什么、用什么工具、证据够不够、要不要重新规划。 典型流程（销量下降分析）： 1. 拆解问题：哪个产品、地区、时间段？ 2. 查销售数据，看下降趋势是否真实 3. 查价格历史，看是否有调价 4. 查营销活动记录 5. 查客服工单 6. 查库存系统 7. 证据不足则继续选新工具 8. 综合多个来源给出原因假设和证据链 适用场景： 复杂问题分析、业务异常归因、跨系统调查、多数据源综合判断、技术排障、竞品分析。 局限： LLM 调用次数多、延迟高、调试复杂。
选型决策¶
| 问题形状 | 推荐架构 |
|---|---|
| 答案从单文档片段即可回答 | Classic RAG |
| 答案依赖跨实体、跨文档关系链 | Graph RAG |
| 查询路径无法提前定义，需边查边判断 | Agentic RAG |
| 混合路径策略： 先用 Classic RAG 解决高频明确问题；遇关系链问题引入 Graph RAG；遇开放式多步骤调查交给 Agentic RAG。 |
深度分析¶
1. RAG全链路技术栈成熟度¶
当前 RAG 工程化已形成完整链路：文档加载 → 智能切分（Meta-Chunking 基于 PPL 困惑度）→ embedding 索引构建 → 多路检索（Query改写/HyDE/Doc2Query/标签过滤/ReRank）→ 生成调优 → Ragas 评估。 关键趋势：
- Meta-Chunking： 通过计算句子 PPL（困惑度）判断语义边界，低 PPL=逻辑连贯，高 PPL=逻辑脱节，自动发现切分点。
- HyDE（假设文档嵌入）： 先让 LLM 生成假答案，再用假答案向量匹配真实文档，将「问题-文档匹配」转换为「文档-文档匹配」。
- ReRank 交叉编码器： 使用 Cross-Encoder 将 Query 和候选文档拼接后联合编码，精度远超向量相似度排序。
2. Skill-RAG：从知识检索到技能检索的范式跃迁¶
清华大学提出 Skill Retrieval Augmentation（SRA），将 RAG 的检索目标从「知识文档」扩展到「技能包」。核心动机：截至 2026 年 4 月，SkillsMP 平台托管超过 100 万个技能，Agent 面临技能选择爆炸性困难。 本质区别：
- RAG 检索的是陈述性知识，用来支撑文本生成
-
SRA 检索的是可执行能力，用来扩展 Agent 的功能边界 关键发现（来自 SRA-Bench 评测）：
-
技能检索确实有用：即使最简单的 BM25 检索器，从 26,000+ 技能中找到 Top-1 注入上下文，Agent 表现显著提升。
- Agent 不具备「需求感知」能力： 测试发现 Agent 在答对和答不对的两组任务中，技能加载率几乎相同——它不知道自己哪些题不会、什么时候该求助外部技能。
- 检索不是瓶颈，判断才是： 即使检索到正确技能，Agent 可能选择不用；在不该用的时候也在用。更好的检索质量不能完全转化为最终任务改进。
3. RAG评估体系：Ragas¶
Ragas（Retrieval Augmented Generation Assessment）是 RAG 效果评估自动化工具，核心是 LLM-as-a-Judge。 检索维度：
- Context Precision（上下文精度）： 检索内容中相关文本块排在列表顶部的程度
-
Context Recall（上下文召回率）： 所有相关文档中被成功检索的比例 生成维度：
-
Faithfulness（忠实度）： 生成回答与检索上下文在事实逻辑上的一致性
- Answer Relevancy（答案相关性）： 回答与用户输入的匹配程度
- Noise Sensitivity（噪声敏感度）： 系统因无关检索文档提供错误回答的频率（越低越好）
4. 多模态 RAG 的新边界¶
NVIDIA 提出企业级多模态 RAG：真实世界文档本质是多模态的（文本+表格+图表+图片+扫描件），传统 RAG 只处理文本会遗漏关键信号。企业级 RAG 必须理解视觉和文本双重上下文才能达到生产级准确率。
实践启示¶
1. 架构选型建议¶
- 从 Classic RAG 开始： 先解决单文档片段即可回答的高频问题，积累知识库和 embedding 基建
- 按需引入 Graph RAG： 当出现跨实体、跨文档关系链查询需求（如影响分析、审批链、供应链），再引入知识图谱层
- 谨慎采用 Agentic RAG： 只有当查询路径无法提前定义、需边查边判断时再引入，接受延迟和调试成本
2. RAG 工程化关键点¶
- 文档加载是入口： 质量直接决定后续检索准确性，需兼容多格式、提取元数据、初步清洗
- 智能切分比向量模型更重要： 差的切分导致语义断裂，再好的 embedding 也救不回来；Meta-Chunking 是值得投入的方向
- Query 改写不可省略： 用户提问方式与文档陈述方式天然存在语义鸿沟；HyDE/Doc2Query 是有效的桥接手段
- ReRank 值得投入： 精度提升显著，尤其在多源融合场景；牺牲一定延时换取生成质量是合理取舍
3. 评估驱动优化¶
- 用 Ragas 建立量化评测体系，而非靠体感判断效果
- 关键指标：Context Precision + Faithfulness 是核心，Answer Relevancy 是最终目标
- 定期生成测试集，覆盖单跳/多跳 × 具体/抽象的查询类型矩阵
4. 警惕 Agentic RAG 的「技能加载幻觉」¶
Skill-RAG 的研究揭示了一个深层问题：Agent 不擅长判断「需不需要外部技能」。在设计 Agentic RAG 系统时，需要在 Agent 外部增加「需求感知层」或「技能加载约束机制」，避免盲目调用、成本失控。
5. 技能化 RAG 是下一个演进方向¶
当知识库检索趋于成熟，技能库检索（Skill-RAG）将成为 Agent 能力扩展的核心瓶颈。检索目标从「静态知识」走向「动态能力」，是 RAG 范式的根本性跃迁。 → 原文存档 → 原文存档 → 原文存档
相关实体¶
第 4 来源（2026-06 AI 寒武纪）：Google Agentic RAG 跨语料库框架 + 充分上下文智能体¶
Google Research + Google Cloud 2026 联合发布的 Agentic RAG 框架——核心创新是 "充分上下文智能体"（Sufficient Context Agent），让系统自己判断信息够不够用，不够就继续找。相比标准 RAG，事实性数据集准确率最高提升 34%。在 FramesQA 多跳推理基准上，跨语料库设置下准确率达 90.1%（824 个查询 / 2676 份 PDF 文档）。
5 阶段多智能体管线（编排 → 规划 → 改写 → 搜索 → 充分上下文质检）¶
| 阶段 | 角色 | 做什么 |
|---|---|---|
| 第一阶段：编排 | 编排器（Orchestrator） | 根智能体解析用户请求，把任务分配给子智能体 |
| 第二阶段：规划 | 规划智能体（Planning Agent） | 规划信息获取路径：先查 A 数据库 → 再查 B → 决定拆解成什么子问题 |
| 第二阶段辅助 | 查询改写器（Query Rewriter） | 把复杂请求拆成多个简单可检索子查询（"X 项目怎么样了" → "X 项目 Q3 状态报告" + "X 项目团队关键阻塞点"） |
| 第三阶段：搜索 | 搜索扇出智能体（Search Fan-out Agent） | 把改写后的查询同时发送到多个数据源，收集信息片段 |
| 第四阶段：充分上下文质检 | 充分上下文智能体（Sufficient Context Agent，核心创新） | ① 审查 RAG 拉回来的实际文本片段 ② 对比原始问题 + 草稿答案 + 检索片段 ③ 判断上下文是否充分 ④ 精确指出缺少什么 + 给出具体改进指令 |
| 第五阶段：迭代 | 上述角色再次调用 | 根据"上下文不充分"信号生成新搜索词（如"皮疹"）→ 重新检索 → 充分上下文智能体再次检查 |
| 第六阶段：最终合成 | 合成智能体 | 充分上下文智能体确认信息齐全 → 合成智能体生成最终答案 |
关键洞见：充分上下文智能体 = 流水线末端的质检员——它的核心动作是 "对比原始问题、草稿答案和检索片段"，不是"生成答案"。问题问了三件事（药物、饮食、过敏），但片段里只有两件事的信息，就会被标记为'上下文不充分'"。这与前文 Skill-RAG 揭示的 "Agent 不具备需求感知能力" 完全呼应——充分上下文智能体就是 Google 给 RAG 系统加的需求感知层。
临床场景案例：医生查询病人出院情况¶
用户问题：「小李做完膝关节手术后的出院药物和饮食限制是什么？住院期间有没有过敏反应？除了肝素静脉滴注或 Tenecteplase 之外，不要包含仅在住院或急诊期间使用的药物。」
这个看似一句话的问题 涉及三个不同信息源（药房 / 营养 / 临床记录）——Vanilla RAG 拿到第一个匹配文档就会停，Google 这套会一直找，直到三项信息都齐。
| 阶段 | 真实处理过程 |
|---|---|
| 编排 | 解析请求 → 分配给子智能体 → 规划：查药房 + 营养 + 临床记录 |
| 改写 | 拆成 3 个子查询：药物清单 / 饮食限制 / 过敏反应 |
| 搜索 | 扇出到 3 个数据源 → 找到药物清单 + 饮食信息，但临床记录中没有过敏相关内容 |
| 充分上下文质检 | "已找到：药物清单和低钠饮食说明。缺失：住院期间过敏反应或不良事件的内容。" → 发出"上下文不充分"信号 |
| 改进指令 | "已找到药物和饮食，但缺少过敏信息，请专门搜索'皮疹'或'不良事件'" |
| 迭代 | 查询改写器生成新搜索词"皮疹" → RAG 重新检索之前忽略的文件 → 找到缺失的过敏信息 |
| 最终合成 | 充分上下文智能体再次确认齐全 → 合成智能体生成完整总结 |
评测结果：FramesQA 多跳推理基准¶
FramesQA 基于 FRAMES 论文，专门测试多跳推理能力。典型问题：
在收视最高的两个电视季终集中（截至 2024 年 6 月），哪个终集播出时间更长？长了多少？
回答这个需要：① 找出收视最高的两个终集（MASH + Cheers）→ ② 查时长 → ③ 计算差值。 - Vanilla RAG 答错：多次搜索但找不到 MASH 或 Cheers 的明确播出时长 - Google 框架答对：MAS*H 终集 150 分钟，比 Cheers 终集（约 98 分钟）多 52 分钟
三组对比设置（FramesQA 824 查询 / 2676 PDF）¶
| 设置 | 检索范围 | 准确率 |
|---|---|---|
| Vanilla RAG | Google 自家 RAG Engine（先进检索 + LLM 解析 + 重排） | 基线 |
| 单语料库 Agentic RAG | 仅 FramesQA 文档 | < 跨语料库 |
| 跨语料库 Agentic RAG | FramesQA 文档 + 3 个无关干扰数据集（规划智能体需自己路由） | 90.1% |
关键发现： - 跨语料库设置准确率接近单语料库——在 4 个数据库中正确路由并回答了 90.1% 的问题 - 单库 vs 跨库延迟相差不超过 3%——加入跨库路由几乎没有带来额外时间成本 - 相比标准 RAG，事实性数据集准确率最高提升 34%（在医疗等高合规领域最显著）
与现有 RAG 框架的关系¶
| 框架 | 核心创新 | 与本文对比 |
|---|---|---|
| Classic RAG | retrieves（检索） | 一次性检索 + 生成 → 没有"够不够"判断 |
| Graph RAG | connects（连接） | 关系链推理 → 仍然依赖预先建图 |
| Agentic RAG（本文） | reasons + 判断充分性 | 边查边判断 + 迭代检索 + 跨语料库路由 |
| Skill-RAG | 技能检索 | 检索"可执行能力"而非陈述性知识 → 与 RAG 正交 |
| Protocol-H | 分层 supervisor-worker + Reflective Retry | 模态鸿沟 (SQL+向量) + 幻觉率 ↓60% → 关注幻觉与多模态 |
| Google Agentic RAG | 充分上下文智能体 + 跨语料库规划 | 关注上下文充分性和多库路由 |
关键差异：Google 这套的核心不是新检索算法，而是 "在生成答案前先判断信息够不够，不够就明确说出缺什么然后再去找"——这个"充分上下文"检验步骤让系统的答案变得可审计、可溯源，而不是靠模型猜测填补空白。
与 Skill-RAG 揭示问题的呼应¶
Skill-RAG 清华 SRA 研究揭示：Agent 不具备"需求感知"能力——它不知道自己哪些题不会、什么时候该求助外部技能。Google 充分上下文智能体 就是 RAG 系统的需求感知层——它做了 Skill-RAG 论文建议的 "在 Agent 外部增加需求感知层"。两者的互补： - Skill-RAG：需求感知用于"要不要加载技能" - 充分上下文智能体：需求感知用于"检索的信息够不够回答问题"
实践启示¶
- 充分上下文检验比新检索算法重要：Google 的 90.1% 准确率主要来自"判断够不够 + 继续找"，而不是更新的向量模型
- 跨语料库路由几乎无额外延迟：4 个数据库自动路由 vs 单库检索，延迟差 < 3%——多数据源整合的实际成本远低于预期
- 可审计性是 RAG 系统的关键属性：医疗/法律/金融场景的 RAG 系统必须有"上下文充分性"检验步骤，否则会生成不可溯源的猜测答案
- 临床场景验证了真实价值：医生查询病人的药物 + 饮食 + 过敏问题，标准 RAG 只能答 2/3，Google 这套答 3/3——这是真实使用中的关键差距
上线状态¶
本文框架 已作为公开预览版上线 Gemini Enterprise Agent Platform： - 官方文档: https://docs.cloud.google.com/gemini-enterprise-agent-platform/build/rag-engine/cross-corpus-retrieval - Google Research 博客: https://research.google/blog/unlocking-dependable-responses-with-gemini-enterprise-agent-platforms-agentic-rag/
→ 第 4 原文存档