第三篇：从普通 RAG 到 Agentic GraphRAG：让 AI 学会主动检索与多跳推理

第三篇：从普通 RAG 到 Agentic GraphRAG：让 AI 学会主动检索与多跳推理

系列：《2026 可验证企业级 AI Agent 工程》
本文关键词：Agentic RAG、GraphRAG、混合检索、RRF、多跳推理、知识图谱

前言

传统 RAG 的核心流程是：

用户问题
  ↓
向量化
  ↓
检索 TopK 文档
  ↓
拼接 Prompt
  ↓
大模型生成答案

它解决了大模型“不知道企业私有知识”的问题，但在复杂业务中仍然存在明显限制。

例如，用户提出：

一号车间昨天能耗为什么升高？是否与最近更换的设备有关？

回答这个问题需要完成多步推理：

1. 找到一号车间包含哪些设备；
2. 查询昨天的能耗数据；
3. 定位能耗异常设备；
4. 查询这些设备最近是否更换；
5. 获取新旧设备额定功率；
6. 查询同期生产负荷；
7. 排除产量增加造成的正常能耗增长；
8. 综合证据形成结论。

普通 RAG 只执行一次相似度检索，很难完成这种跨数据源、多实体、多步骤的任务。

因此，RAG 正在向两个方向演进：

Agentic RAG：让 Agent 主动决定如何检索
GraphRAG：让系统基于实体关系进行检索

二者结合，就形成了 Agentic GraphRAG。

---

一、普通 RAG 到底缺少什么？

1. 固定检索流程

传统 RAG 通常固定执行：

vectorStore.similaritySearch(question, 5);

无论用户询问什么问题，都使用同一个知识库、同一种检索方式和同一个 TopK。

但不同问题需要的检索方式完全不同：

问题	更合适的检索方式
空压机高温如何处理？	向量检索设备手册
告警编号 ALM-1001 是什么？	BM25 精确关键词检索
昨天哪个车间耗电最高？	SQL 聚合查询
设备 A 影响了哪些生产线？	知识图谱关系查询
能耗升高是否与设备更换有关？	多跳图检索与时序查询

如果所有问题都使用向量检索，系统必然会在部分场景中失效。

2. 无法判断是否需要再次检索

普通 RAG 通常只检索一次。

如果第一次没有找到关键内容，模型往往会根据不完整信息继续生成答案，而不是主动调整检索条件。

例如，用户询问：

最近一次空压机高温告警是否与维护记录有关？

第一次检索只找到告警记录：

{
  "deviceId": "AC-001",
  "alarmType": "HIGH_TEMPERATURE",
  "alarmTime": "2026-09-18 14:32:00"
}

当前信息还不足以回答问题。系统需要继续查询：

• 告警前后的运行数据；
• 最近一次维护记录；
• 更换过哪些部件；
• 同类型设备是否出现相同问题。

普通 RAG 缺少这种“发现信息不足并继续检索”的能力。

3. 无法表达实体关系

向量检索擅长寻找语义相似文本，但不擅长回答关系型问题。

例如：

传感器 S-101 异常会影响哪些设备、车间和生产任务？

答案依赖一条关系链：

传感器 S-101
→ 安装于空压机 AC-001
→ 空压机属于一号车间
→ 一号车间支撑生产线 L-01
→ 生产线正在执行订单 O-20260922

这些内容可能分散在多张表和多份文档中。单纯依赖文本相似度，很难完整恢复这条关系链。

---

二、什么是 Agentic RAG？

Agentic RAG 不再把检索看成生成答案前的固定步骤，而是把检索能力注册为 Agent 可以自主调用的工具。

它让 Agent 自主决定：

• 是否需要检索；
• 查询哪个数据源；
• 使用哪种检索方式；
• 如何拆解复杂问题；
• 是否需要二次检索；
• 什么时候停止检索；
• 最终答案是否有证据支持。

Agentic RAG 的核心变化可以概括为：

传统 RAG：Retrieve Then Generate
Agentic RAG：Plan → Retrieve → Evaluate → Refine → Generate

---

三、Agentic RAG 的四种核心能力

1. 查询改写

用户的问题通常不适合直接检索。

例如：

用户问题：
它昨天为什么突然变高了？

系统需要结合对话历史，将其改写为：

查询空压机 AC-001 在 2026-09-21 的耗电量变化，
并分析相对于近七日基线升高的原因。

对于复杂问题，还可以拆分为多个子查询：

查询1：空压机 AC-001 昨日能耗变化
查询2：空压机 AC-001 昨日告警记录
查询3：空压机 AC-001 最近维护记录
查询4：一号车间昨日生产负荷

2. 动态选择检索器

系统可以为 Agent 提供多个检索工具：

searchDocument：检索设备手册和制度文档
searchKeyword：检索设备编号、告警码等精确内容
queryTimeSeries：查询实时和历史指标
queryBusinessData：查询设备、工单和维护记录
queryKnowledgeGraph：查询实体关系

Agent 根据问题类型选择对应工具，而不是将所有问题交给向量数据库。

3. 结果评估与二次检索

每轮检索完成后，需要判断：

结果是否与问题相关？
信息是否足够完整？
数据是否已经过期？
不同来源是否存在冲突？
是否缺少关键证据？

如果证据不足，Agent 可以生成新的检索计划。

例如：

第一次检索发现：
能耗增长 23.7%，同时存在排气温度告警。

仍缺少：
设备负载率和维护记录。

下一步：
查询负载率，并检查最近七天的维护工单。

4. 引用与事实校验

最终答案应将“事实”和“推断”分开：

事实：
1. 昨日耗电量比近七日均值高23.7%；
2. 14:32出现排气温度高告警；
3. 设备负载率没有明显增长。

推断：
能耗升高更可能与设备运行效率下降有关，
而不是生产负荷增加导致。

待确认：
需要进一步检查冷却系统和润滑状态。

这比直接输出“可能是设备故障”更加可靠。

---

四、什么是 GraphRAG？

GraphRAG 将企业知识表示为节点和关系。

以能源管理场景为例，可以设计以下节点：

Device：设备
Workshop：车间
ProductionLine：生产线
Sensor：传感器
Alarm：告警
MaintenanceOrder：维护工单
KnowledgeDocument：知识文档
EnergyMetric：能耗指标

节点之间建立关系：

设备 BELONGS_TO 车间
设备 INSTALLED_WITH 传感器
设备 GENERATED 告警
设备 HAS_ORDER 工单
设备 CONNECTED_TO 生产线
告警 RELATED_TO 故障类型
故障类型 RESOLVED_BY 维护方案

对应的知识图谱如下：

当用户询问：

空压机高温可能影响哪些业务？

系统可以沿图关系进行多跳查询，而不是仅仅寻找包含“空压机高温”关键词的文档。

---

五、GraphRAG 的两种典型查询模式

1. Local Search

Local Search 从具体实体出发，沿关系查找邻居。

适用于：

• 某台设备关联了哪些告警；
• 某个故障影响哪些生产线；
• 某张工单由哪个异常触发；
• 某个传感器安装在哪台设备上。

例如使用 Cypher 查询：

MATCH path =
    (device:Device {id: $deviceId})
    -[:GENERATED]->(alarm:Alarm)
    -[:RELATED_TO]->(fault:FaultType)
    -[:RESOLVED_BY]->(solution:Solution)
RETURN path
ORDER BY alarm.time DESC
LIMIT 20

2. Global Search

Global Search 面向整个知识库进行总结。

适用于：

• 全厂最常见的设备故障是什么；
• 哪些车间存在相似能耗问题；
• 最近一年维护工作的主要风险是什么；
• 企业设备管理制度有哪些共同缺陷。

Microsoft GraphRAG 的典型做法是：

原始文档
→ 抽取实体和关系
→ 构建知识图谱
→ 社区发现
→ 生成社区摘要
→ 基于多级摘要回答全局问题

Local Search 关注具体实体，Global Search 关注整个知识网络的主题和结构。

---

六、向量检索和 GraphRAG 应该如何选择？

GraphRAG 并不是向量 RAG 的替代品。

场景	推荐方式
查找语义相似段落	向量检索
查询设备编号或告警码	BM25
查询实时业务数据	SQL
分析实体之间的影响关系	GraphRAG
复杂问题	混合检索
全局主题总结	GraphRAG 社区摘要

生产环境中更合理的架构是 Hybrid RAG：

---

七、使用 RRF 融合多路检索结果

向量检索和关键词检索返回的分数通常不在同一个范围内，不能直接相加。

可以使用 Reciprocal Rank Fusion，即 RRF：

RRF(d) = Σ 1 / (k + ranki(d))

其中：

• d 表示某个文档；
• ranki(d) 表示文档在第 i 个检索器中的排名；
• k 通常设置为一个平滑常数。

Java 示例：

public Map<String, Double> reciprocalRankFusion(
        List<List<String>> rankedResults,
        int k) {

    Map<String, Double> scores = new HashMap<>();

    for (List<String> result : rankedResults) {
        for (int index = 0; index < result.size(); index++) {
            String documentId = result.get(index);
            double score = 1.0 / (k + index + 1);

            scores.merge(documentId, score, Double::sum);
        }
    }

    return scores.entrySet()
            .stream()
            .sorted(Map.Entry.<String, Double>comparingByValue()
                    .reversed())
            .collect(Collectors.toMap(
                    Map.Entry::getKey,
                    Map.Entry::getValue,
                    (left, right) -> left,
                    LinkedHashMap::new
            ));
}

RRF 不依赖不同检索器的原始分数，因此非常适合融合：

向量召回结果
+ BM25 召回结果
+ 图谱检索结果

融合后还可以使用 Reranker 对候选文档进行精排。

---

八、构建 Agentic GraphRAG 执行循环

可以将一次检索任务抽象成以下状态：

public record RetrievalState(
        String originalQuestion,
        List<String> subQuestions,
        List<Evidence> evidence,
        List<String> missingInformation,
        int currentRound,
        boolean sufficient
) {
}

检索流程：

public Answer execute(String question) {
    RetrievalState state = planner.createPlan(question);

    while (!state.sufficient()
            && state.currentRound() < MAX_RETRIEVAL_ROUNDS) {

        List<RetrievalTask> tasks =
                router.route(state);

        List<Evidence> evidence =
                executor.execute(tasks);

        state = evaluator.evaluate(
                state,
                evidence
        );
    }

    return answerGenerator.generate(state);
}

这里包含五个核心组件：

Planner：拆解问题
Router：选择检索器
Executor：执行检索
Evaluator：判断证据是否充分
Generator：基于证据生成答案

生产环境必须限制：

• 最大检索轮数；
• 最大工具调用次数；
• 单次返回文档数量；
• 总 Token 消耗；
• 图遍历最大深度；
• 单任务执行时间。

否则 Agent 可能陷入无限检索循环。

---

九、能源异常分析示例

用户提出：

一号车间昨天耗电量为什么增长了？

第一轮：任务拆解

需要确认：
1. 昨日耗电量增长幅度；
2. 哪些设备贡献了主要增量；
3. 生产负荷是否同步增长；
4. 是否发生设备告警或维护变更。

第二轮：动态检索

SQL：
查询车间昨日能耗和近七日基线。

ClickHouse：
查询设备级时序数据。

知识图谱：
查询异常设备所属系统及关联设备。

向量数据库：
检索相关故障手册。

第三轮：补充检索

发现空压机 AC-001 能耗增长明显，但生产负荷没有变化，于是继续查询：

空压机告警记录
最近维护工单
冷却系统运行数据
同型号设备历史案例

最终答案

一号车间昨日耗电量较近七日均值增长18.6%。

其中，空压机 AC-001 贡献了总增量的67%。
同期生产负荷仅增长1.8%，因此基本可以排除产量增长因素。

AC-001 在14:32出现排气温度高告警，
冷却水温比正常范围高8.4℃。
结合设备手册和历史案例，当前能耗增长更可能由
冷却效率下降导致压缩机持续高负载运行。

建议优先检查冷却器堵塞、冷却水流量和温度传感器。

答案中的每个关键结论，都应关联具体数据来源。

---

十、GraphRAG 不适合哪些场景？

GraphRAG 很强，但建设成本也更高。

以下场景不一定需要使用：

• 知识量很小；
• 文档之间几乎没有关系；
• 主要问题是简单语义搜索；
• 实体和关系无法稳定抽取；
• 数据更新非常频繁；
• 团队缺少图数据治理能力。

知识图谱还可能出现：

• 重复实体；
• 错误关系；
• 实体名称不一致；
• 关系缺少时间属性；
• 模型抽取结果不可信。

因此，GraphRAG 应该从高价值关系场景切入，而不是把所有文档都转换为图谱。

---

十一、如何评测 Agentic GraphRAG？

不要只评价最终答案，还要评价完整检索轨迹。

指标	说明
Recall@K	关键证据是否被召回
MRR	正确结果的排名是否靠前
Route Accuracy	是否选择了正确检索器
Evidence Sufficiency	证据是否足够回答问题
Citation Accuracy	引用是否真正支持结论
Hop Accuracy	多跳关系是否正确
Tool Call Count	是否存在无效调用
Retrieval Cost	每次任务的检索成本
Groundedness	答案是否忠于证据

对于高风险业务，还需要评估：

信息不足时，Agent 是否会拒绝下结论？
证据冲突时，Agent 是否能够暴露冲突？
检索失败时，Agent 是否会虚构结果？

---

总结

普通 RAG 解决的是：

从知识库中找到与问题相似的内容。

Agentic RAG 解决的是：

根据任务主动规划、选择、执行并验证检索。

GraphRAG 解决的是：

沿实体关系发现普通向量检索难以获得的多跳证据。

三者的生产级组合是：

向量检索
+ BM25
+ SQL
+ 知识图谱
+ Agent 动态路由
+ 多轮证据评估
+ 引用校验

最终目标并不是让 Agent 检索更多内容，而是让它找到回答问题所必需的证据。

下一篇：

《AI Agent 为什么需要长期记忆？从聊天记录到可治理的 Memory 系统》

参考资料：

• Microsoft GraphRAG
• Microsoft Research：Project GraphRAG
• Anthropic：Contextual Retrieval
• RAG vs. GraphRAG 系统评测
• Vector、Graph 与 Hybrid RAG 基准研究