第三篇从普通 RAG 到 Agentic GraphRAG让 AI 学会主动检索与多跳推理系列《2026 可验证企业级 AI Agent 工程》本文关键词Agentic RAG、GraphRAG、混合检索、RRF、多跳推理、知识图谱文章目录第三篇从普通 RAG 到 Agentic GraphRAG让 AI 学会主动检索与多跳推理前言一、普通 RAG 到底缺少什么1. 固定检索流程2. 无法判断是否需要再次检索3. 无法表达实体关系二、什么是 Agentic RAG三、Agentic RAG 的四种核心能力1. 查询改写2. 动态选择检索器3. 结果评估与二次检索4. 引用与事实校验四、什么是 GraphRAG五、GraphRAG 的两种典型查询模式1. Local Search2. Global Search六、向量检索和 GraphRAG 应该如何选择七、使用 RRF 融合多路检索结果八、构建 Agentic GraphRAG 执行循环九、能源异常分析示例第一轮任务拆解第二轮动态检索第三轮补充检索最终答案十、GraphRAG 不适合哪些场景十一、如何评测 Agentic GraphRAG总结《AI Agent 为什么需要长期记忆从聊天记录到可治理的 Memory 系统》前言传统 RAG 的核心流程是用户问题 ↓ 向量化 ↓ 检索 TopK 文档 ↓ 拼接 Prompt ↓ 大模型生成答案它解决了大模型“不知道企业私有知识”的问题但在复杂业务中仍然存在明显限制。例如用户提出一号车间昨天能耗为什么升高是否与最近更换的设备有关回答这个问题需要完成多步推理找到一号车间包含哪些设备查询昨天的能耗数据定位能耗异常设备查询这些设备最近是否更换获取新旧设备额定功率查询同期生产负荷排除产量增加造成的正常能耗增长综合证据形成结论。普通 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 RAGAgentic RAG 不再把检索看成生成答案前的固定步骤而是把检索能力注册为 Agent 可以自主调用的工具。不需要需要否是接收用户问题分析任务是否需要检索生成答案选择数据源和检索策略执行检索证据是否充分改写问题或补充检索验证答案与证据它让 Agent 自主决定是否需要检索查询哪个数据源使用哪种检索方式如何拆解复杂问题是否需要二次检索什么时候停止检索最终答案是否有证据支持。Agentic RAG 的核心变化可以概括为传统 RAGRetrieve Then Generate Agentic RAGPlan → 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. 设备负载率没有明显增长。 推断 能耗升高更可能与设备运行效率下降有关 而不是生产负荷增加导致。 待确认 需要进一步检查冷却系统和润滑状态。这比直接输出“可能是设备故障”更加可靠。四、什么是 GraphRAGGraphRAG 将企业知识表示为节点和关系。以能源管理场景为例可以设计以下节点Device设备 Workshop车间 ProductionLine生产线 Sensor传感器 Alarm告警 MaintenanceOrder维护工单 KnowledgeDocument知识文档 EnergyMetric能耗指标节点之间建立关系设备 BELONGS_TO 车间 设备 INSTALLED_WITH 传感器 设备 GENERATED 告警 设备 HAS_ORDER 工单 设备 CONNECTED_TO 生产线 告警 RELATED_TO 故障类型 故障类型 RESOLVED_BY 维护方案对应的知识图谱如下INSTALLED_WITHBELONGS_TOGENERATEDHAS_ORDERCONNECTED_TORELATED_TORESOLVED_BY传感器 S-101空压机 AC-001一号车间高温告警维护工单生产线 L-01冷却系统异常清理冷却器当用户询问空压机高温可能影响哪些业务系统可以沿图关系进行多跳查询而不是仅仅寻找包含“空压机高温”关键词的文档。五、GraphRAG 的两种典型查询模式1. Local SearchLocal 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 202. Global SearchGlobal Search 面向整个知识库进行总结。适用于全厂最常见的设备故障是什么哪些车间存在相似能耗问题最近一年维护工作的主要风险是什么企业设备管理制度有哪些共同缺陷。Microsoft GraphRAG 的典型做法是原始文档 → 抽取实体和关系 → 构建知识图谱 → 社区发现 → 生成社区摘要 → 基于多级摘要回答全局问题Local Search 关注具体实体Global Search 关注整个知识网络的主题和结构。六、向量检索和 GraphRAG 应该如何选择GraphRAG 并不是向量 RAG 的替代品。场景推荐方式查找语义相似段落向量检索查询设备编号或告警码BM25查询实时业务数据SQL分析实体之间的影响关系GraphRAG复杂问题混合检索全局主题总结GraphRAG 社区摘要生产环境中更合理的架构是 Hybrid RAG用户问题检索路由器向量检索BM25检索SQL查询知识图谱结果融合重排序证据评估生成答案七、使用 RRF 融合多路检索结果向量检索和关键词检索返回的分数通常不在同一个范围内不能直接相加。可以使用 Reciprocal Rank Fusion即 RRFRRF(d) Σ 1 / (k ranki(d))其中d表示某个文档ranki(d)表示文档在第i个检索器中的排名k通常设置为一个平滑常数。Java 示例publicMapString,DoublereciprocalRankFusion(ListListStringrankedResults,intk){MapString,DoublescoresnewHashMap();for(ListStringresult:rankedResults){for(intindex0;indexresult.size();index){StringdocumentIdresult.get(index);doublescore1.0/(kindex1);scores.merge(documentId,score,Double::sum);}}returnscores.entrySet().stream().sorted(Map.Entry.String,DoublecomparingByValue().reversed()).collect(Collectors.toMap(Map.Entry::getKey,Map.Entry::getValue,(left,right)-left,LinkedHashMap::new));}RRF 不依赖不同检索器的原始分数因此非常适合融合向量召回结果 BM25 召回结果 图谱检索结果融合后还可以使用 Reranker 对候选文档进行精排。八、构建 Agentic GraphRAG 执行循环可以将一次检索任务抽象成以下状态publicrecordRetrievalState(StringoriginalQuestion,ListStringsubQuestions,ListEvidenceevidence,ListStringmissingInformation,intcurrentRound,booleansufficient){}检索流程publicAnswerexecute(Stringquestion){RetrievalStatestateplanner.createPlan(question);while(!state.sufficient()state.currentRound()MAX_RETRIEVAL_ROUNDS){ListRetrievalTasktasksrouter.route(state);ListEvidenceevidenceexecutor.execute(tasks);stateevaluator.evaluate(state,evidence);}returnanswerGenerator.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不要只评价最终答案还要评价完整检索轨迹。指标说明RecallK关键证据是否被召回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 GraphRAGMicrosoft ResearchProject GraphRAGAnthropicContextual RetrievalRAG vs. GraphRAG 系统评测Vector、Graph 与 Hybrid RAG 基准研究
