从 RAG 到 RAG 2.0：为什么需要知识图谱与 Agent？

传统 RAG（Retrieval-Augmented Generation）通过向量检索召回相关文本片段，再交给大模型生成答案，有效缓解了幻觉和知识过时问题。然而，在复杂业务场景中，它暴露出三个致命短板：

多跳推理能力弱：当问题需要跨越多个文档或实体才能回答时（例如“A公司收购了B公司，B公司的CTO后来加入了C项目，C项目影响了哪条产品路线？”），向量检索只能找到“看起来相似”的片段，无法串联关系链。

缺乏结构化语义：纯向量检索基于语义相似度，无法理解实体间的显式关系（如“属于”“投资”“影响”），导致答案缺乏可解释性。

Agent 执行断层：Agent 不仅需要检索知识，还要基于结果调用工具、执行任务。若第一步检索出错，后续推理和行动将全面跑偏。

RAG 2.0 的核心思想是：用知识图谱补充结构化关系，用本体约束提供业务规则，用 Agent 编排实现闭环执行。本文将从架构、技术选型到实战落地，系统拆解这一演进路径。

知识图谱增强 RAG：从 GraphRAG 到 SAG

GraphRAG：全局理解与主题总结

微软提出的 GraphRAG 是知识图谱增强 RAG 的代表方案。它离线将文档中的实体、关系抽取为知识图谱，并基于社区检测生成摘要。查询时，系统先定位相关实体，再沿关系扩散，最终生成结构化的答案。

优点：擅长全局性、总结性问题，能捕捉实体间的隐式关联。 缺点：构建成本高（需大量 LLM 调用）、维护困难（实体消歧复杂）、增量更新不友好。

HippoRAG 2：记忆启发的多跳检索

受海马体记忆机制启发，HippoRAG 2 引入 Personalized PageRank 算法，在离线构建的图上进行多跳扩散。它模拟人脑从线索出发激活相关记忆的过程，适合长期记忆场景。

优点：多跳推理能力强，支持长期记忆。 缺点：依赖全局图，每次查询需运行图排序算法，延迟较高；增量更新仍需重建部分图。

SAG：SQL-Retrieval Augmented Generation

SAG（SQL-Retrieval Augmented Generation）是近期提出的新范式，核心思路是：将文本转化为“事项（Event）+ 实体（Entity）”的数据库结构，查询时通过 SQL 动态串联局部线索网。

离线阶段：将每个 chunk 视为一个 Event，提取其中的 Entities，形成多对多的超边结构，存入 SQL 和向量索引。

在线阶段：LLM 从查询中识别实体，通过 SQL JOIN 找到所有相关 Events，再沿共享实体扩展，最终与向量召回结果合并。

优势：

避免全局图维护，增量更新只需添加新 Events。

查询时仅需 SQL 操作，延迟低（在 5 亿条数据规模下仍保持秒级）。

对 embedding 模型不敏感，结构本身贡献主要提升。

实验结果：在 HotpotQA、2WikiMultiHopQA、MuSiQue 上，SAG 的 Recall@2 达 79.3%，领先 HippoRAG 2 约 11 个百分点。

本体约束：让 AI 理解业务规则

知识图谱提供了实体关系，但企业级场景还需要业务规则来约束 AI 行为。本体（Ontology）正是为此而生。

本体三要素

语义元素：实体、关系、事件及其属性（如“工单”有“状态”“优先级”）。

Action：可执行的行为（如“新建工单”“修改预警状态”），需定义角色、属性、边界。

Logic：业务逻辑（如“若温度超过阈值，则触发预警”），可用 DAG 编排。

本体如何增强 RAG 与 Agent？

语义统一：消除不同部门对同一概念的歧义（如“客户” vs “用户”）。

推理可信：每一步结果可溯源，满足审计合规。

行为可控：业务规则形成硬约束，防止 Agent 越权或产生非法操作。

典型案例：趣丸科技采用“LLM+本体约束”三级分层策略，核心知识准确率 >85%，一般知识达 80-85%，整体检索准确率提升 15-20%。

Agent 与 RAG 2.0 的融合架构

RAG 2.0 的最终目标是让 Agent 能够自主执行复杂任务。一个典型的企业级架构分为三层：

本体层（知识定义）

存储本体 Schema（实体、关系、Action、Logic）。

定义 Agent 可调用的工具和技能（Onto-Skills）。

认知引擎层（推理与约束）

在 Agent 启动前，从本体读取领域知识并注入推理上下文。

生成结果后，与本体约束进行校验，违反规则则打回重推。

Agent 执行层（任务编排）

接收用户任务，调用工具，执行多步推理。

支持主动触发（如数据变化时自动生成报告）。

闭环反馈：Agent 执行中产生的新数据可自动识别本体未覆盖的概念，失败信号反馈用于修正本体，形成持续进化。

实战：构建企业级 RAG 2.0 系统

Step 1：文档解析与切片

高质量的文档解析是 RAG 的基石。推荐使用 RAGFlow 的 DeepDoc 模块进行二次开发，支持 PDF、Word 等格式。

结构切分：按标题、段落、表格等版面元素分割。

长度切分：在结构块内按 token 数切分（建议 256-512），平衡检索精度与上下文完整性。

Step 2：混合检索

结合向量检索（语义理解）与全文检索（精确匹配），提升召回率。

检索方式优势劣势

向量检索语义理解、跨语言、多模态对低频词不敏感 全文检索精确匹配、可解释、支持逻辑运算无法理解同义词

实践建议：使用 BGE-M3 和 BCE 双向量模型互补，配合 BM25 全文检索，通过 RRF（倒数排序融合）合并结果。

Step 3：多跳推理与知识图谱

对于需要多跳推理的问题，推荐采用 SAG 架构：

离线将文档解析为 Event-Entity 结构，存入 SQL 和向量库。

在线时，LLM 提取查询中的实体，通过 SQL JOIN 找到关联 Events。

沿共享实体扩展，形成局部推理链。

与向量召回结果合并，经 reranker 筛选后生成答案。

Step 4：排序与过滤

采用两阶段排序策略：

粗排序：RRF 融合多路召回结果，从 100 个候选降至 20 个。

精排序：使用交叉编码器（如 BGE-Reranker）对 20 个候选排序，取 Top 5。

知识过滤：根据业务规则（如权限、时效性）剔除不合规结果。

Step 5：Agent 编排与执行

基于 LangGraph 或自研框架，将 RAG 结果与工具调用结合：

定义 Onto-Skills（如“查询工单”“发送邮件”），每个 Skill 对应一个工具函数。

Agent 根据问题规划步骤，依次调用 RAG 检索、工具执行、结果验证。

引入记忆模块（短期对话记忆 + 长期本体记忆），支持多轮交互。

示例：在 LED 生产线场景中，Agent 自动调用“质量追溯”Skill，根据预警数据生成改进报告，并分别向供应商、产线负责人、客户推送差异化任务。

效果评估与持续优化

评估指标

检索阶段：Recall@K、MRR

生成阶段：准确率、幻觉率、可解释性评分

Agent 阶段：任务完成率、平均执行步数、用户满意度

优化方向

增量更新：SAG 架构天然支持增量，新文档只需解析为 Event 并入索引。

本体自动构建：利用 LLM 从数据中自动抽取实体与关系，人工审核兜底，冷启动周期从数周降至小时级。

缓存与降级：高频查询使用 Redis 缓存；工具调用失败时自动降级到其他数据源。

总结

RAG 2.0 不是单一技术的升级，而是向量检索 + 知识图谱 + 本体约束 + Agent 编排的有机融合。它解决了传统 RAG 在多跳推理、语义理解和执行闭环上的根本缺陷，为企业级 AI 落地提供了可复用的技术框架。

对于团队而言，建议从以下路径切入：

先用混合检索 + 两阶段排序提升基础召回率。

对复杂查询场景引入知识图谱（优先尝试 SAG 架构）。

结合业务规则构建本体，约束 Agent 行为。

逐步迭代为自主执行的智能体系统。

FAQ

问题1：SAG 与 GraphRAG 的主要区别是什么？ SAG 采用“Event + Entity”的数据库结构，查询时通过 SQL JOIN 动态串联局部线索，无需维护全局图；而 GraphRAG 需要离线构建完整知识图谱并进行社区摘要。SAG 在增量更新、延迟控制和扩展性上更优，尤其适合大规模生产环境。

问题2：本体约束是否会限制大模型的灵活性？ 不会。本体约束只作用于业务核心逻辑和权限边界，对于未覆盖的领域，系统仍允许大模型自由推理，但会标注“未经验证”。这种“硬约束 + 软推理”的混合策略既保证了关键业务的准确性，又保留了模型的创造性。

问题3：如何评估 RAG 2.0 系统的效果？ 建议分阶段评估：检索阶段关注 Recall@K 和 MRR；生成阶段关注准确率和幻觉率（可通过人工标注或自动对比）；Agent 阶段关注任务完成率和执行效率。此外，可解释性（能否溯源）也是企业级场景的重要指标。

问题4：企业级 RAG 2.0 的冷启动周期多长？ 取决于数据复杂度和本体构建方式。使用 LLM 辅助自动构建本体，冷启动周期可从数周缩短至数天；若需手工梳理复杂业务规则，可能需要 1-2 个月。建议先以最小可行本体启动，后续逐步迭代。

问题5：Agent 如何与现有系统集成？ 通过 MCP（Model Context Protocol）或自定义 API 网关，将现有系统（如 CRM、ERP、工单系统）封装为工具。Agent 根据任务规划调用这些工具，实现跨系统操作。例如，通过 Bright Data MCP 服务器，Agent 可像人一样操控浏览器抓取数据。

问题6：知识图谱的实体消歧如何处理？ SAG 采用保守策略：入库前做简单字符串归一和 SQL 模糊匹配，不追求完美合并。因为 Entity 仅作为“路标”，Event 才是答案载体，即使实体名称不统一，也能通过共享 Event 关联。GraphRAG 则需严格消歧，否则会污染整张图。

进一步学习

了解 Agent 编排框架：AI Agent 与多智能体

掌握向量检索与排序优化：RAG 系统评估与调优

学习知识图谱构建：知识图谱与本体工程