基于 LangGraph 的 Agentic RAG 核心架构

核心摘要当资深运维专家离场留下的往往不仅是空荡荡的工位更是无数无法被Wiki捕捉的“隐性知识”。本文将摒弃空洞的概念炒作基于Agentic RAG架构利用LangGraph与Qwen2.5从零构建一个具备“反思-迭代”能力的“火电运维专家Agent”。这不仅是一份代码实录更是企业核心经验实现数字永生的技术宣言。1. 逝去的“老法师”与沉默的知识断层在火电厂的集控室里最可怕的不是报警灯的闪烁而是当那个总是端着茶杯的“老张”离开后面对同样的故障报警一群硕博工程师却面面相觑。隐性知识——那些写在故障处理规程之外的经验、直觉和手速——往往随着人员的流动而彻底消失。传统的企业Wiki或静态知识库Confluence, SharePoint只能存储“显性知识”即已经被文档化的信息。而真正的运维核心往往存在于“汽温波动与煤质特性的非线性关系”这种即时的判断中。同事被优化了但他的经验必须留下。我们需要构建的不仅仅是一个问答机器人而是一个能够模拟专家思维链的Agent智能体。它不应只是简单的检索增强生成RAG而必须是具备Agentic代理特性的能够规划、执行、反思和纠错。2. 技术选型拒绝玩具级架构市面上大多数“知识库搭建”教程仅停留在“文档切片 - 向量化 - 召回”的初级阶段。这种线性流程在工业场景下是致命的——一旦召回的上下文偏差大模型LLM极易产生幻觉误导运维人员导致停机事故。为此我们确立了基于LangGraph的Agentic RAG架构并选用了Qwen2.5-72B-Instruct作为基座模型。2.1 核心组件选型逻辑组件选型方案选型理由 (工业级考量)替代方案对比基座模型Qwen2.5-72B1.中文理解力在CMMLU榜单上对中文工业术语理解极佳。2.Tool Calling原生支持Function Calling格式稳定。3.长文本支持128k上下文足以吞下整份《锅炉运行规程》。Llama 3.1 (中文逻辑略弱)GPT-4o (私有化部署成本高/合规风险)向量数据库Milvus 2.41.Hybrid Search支持稀疏稠密向量混合检索精准匹配设备编号。2.标量过滤支持按“机组编号”、“时间”等元数据精准过滤。Pinecone (SaaS不可控)FAISS (无元数据过滤不适合生产)编排框架LangGraph1.循环图原生支持“反思-重试”的循环逻辑而非LangChain的DAG。2.Stateful维护对话状态适合多轮故障排查。LangChain Chain (线性死板无法回头)Rerank模型BGE-Reranker-v2-m3在召回后进行精细排序解决“语义相似但逻辑相反”的问题如“开启阀门”vs“禁止开启阀门”。无Rerank (准确率下降20%)3. 架构设计构建“会思考”的闭环传统的RAG是“一锤子买卖”问一次查一次答一次。而我们的目标是模拟人类专家的思维过程分析问题是设备故障还是操作失误查阅资料先看规程再看历史工单。自我评估找到的信息够吗能不能解释通生成答案给出带有置信度的操作建议。以下是基于 LangGraph 的 Agentic RAG 核心架构图工具层 Tools1. 检索规程2. 查历史Re-PlanRewrite用户输入:3号炉汽温异常Qwen2.5 Agent推理与规划向量检索Milvus Hybrid Search关系型查询历史故障工单实时搜索外部技术论坛上下文构建s10答案生成器Answer Generators11最终输出带引用来源4. 硬核实战代码实现环境准备确保你已经部署了 Milvus 和 Ollama (或 vLLM) 服务。开源依赖langchain,langgraph,pymilvus,langchain-community4.1 定义状态与工具首先我们需要定义 Agent 的“大脑”状态。在 LangGraph 中State 是在节点间流转的记忆。fromtypingimportTypedDict,Annotated,List,Unionfromlangchain_core.messagesimportHumanMessage,AIMessage,SystemMessageimportoperator# 定义Agent的状态messages会自动累加classAgentState(TypedDict):messages:Annotated[list,operator.add]# 对话历史query:str# 用户原始问题context:List[str]# 检索到的上下文confidence:float# 置信度评分iterations:int# 迭代次数防止死循环# 模拟连接 Milvus 进行混合检索defsearch_fault_records(query:str,unit_id:str3): 在向量库中检索故障记录和运行规程。 实际生产中应使用 Milvus Client 进行 search。 # 伪代码演示这里应当是 collection.search(...)print(f- [Tool Call] 正在检索机组{unit_id}关于 {query} 的记录...)# 模拟返回的文档片段docs[《锅炉运行规程 4.2.1》当主汽温度超过额定值5℃时应立即检查减温水门开度。,历史工单 #2023-11023号炉发生过热器爆管前兆为减温水流量异常波动。]returndocs# 模拟查询结构化数据如D CS历史数据库defquery_dcs_data(parameter:str):print(f- [Tool Call] 正在查询 DCS 实时数据:{parameter}...)returnf当前{parameter}数值为 545℃ (报警限 540℃)4.2 构建核心节点评估与反思这是区分“玩具”和“专家”的关键。如果检索到的信息是垃圾Agent 必须有能力拒绝回答并重新检索。fromlangchain_openaiimportChatOpenAIfromlangchain_core.promptsimportChatPromptTemplate# 假设我们使用本地部署的 Qwen2.5 接口llmChatOpenAI(base_urlhttp://localhost:8000/v1,modelQwen2.5-72B-Instruct,api_keyempty)# 节点检索defretrieve_node(state:AgentState):querystate[query]# 实际这里应该由LLM提取参数docssearch_fault_records(query)return{context:docs}# 节点评估 - 决定是否需要重新检索或利用外部工具defgrade_documents_node(state:AgentState): 使用LLM作为评判官判断检索到的上下文是否足以回答问题。 print(-- [Node] 正在评估文档相关性...)questionstate[query]documentsstate[context]promptChatPromptTemplate.from_messages([(system,你是一个严谨的火电运维专家助手。请判断以下文档片段是否包含回答用户问题所需的关键信息。),(user,问题: {question}\n\n文档片段: {docs}\n\n如果信息足够回复 YES否则回复 NO。)])chainprompt|llm responsechain.invoke({question:question,docs:\n.join(documents)})ifYESinresponse.content:return{confidence:0.9}# 足够高可以生成else:print(-- [Warning] 文档相关性不足准备触发重试机制...)return{confidence:0.3,iterations:state[iterations]1}# 节点生成答案defgenerate_node(state:AgentState):print(-- [Node] 正在生成最终回答...)# 调用LLM生成包含 System Prompt 防止幻觉pass4.3 编排 LangGraph让逻辑闭环这是最激动人心的部分。我们将定义图的边实现“如果不满意就重来”的逻辑。fromlanggraph.graphimportStateGraph,END workflowStateGraph(AgentState)# 1. 添加节点workflow.add_node(retrieve,retrieve_node)workflow.add_node(grade,grade_documents_node)workflow.add_node(generate,generate_node)# 2. 设置入口workflow.set_entry_point(retrieve)# 3. 添加边workflow.add_edge(retrieve,grade)# 4. 添加条件边 - 核心逻辑defdecide_to_generate(state:AgentState):# 如果迭代次数超过3次强制退出避免死循环ifstate[iterations]3:returnabortifstate[confidence]0.7:returngenerateelse:# 这里可以加入改写Query的逻辑为了演示简洁直接重试returnretry# 从 grade 节点出来根据条件决定去向workflow.add_conditional_edges(grade,decide_to_generate,{generate:generate,retry:retrieve,# 置信度不够回头重新检索abort:END})workflow.add_edge(generate,END)# 5. 编译图appworkflow.compile()5. 实战演练一个复杂的故障排查 Case为了验证效果我们模拟一个复杂的输入。用户并没有直接说“故障”而是描述了现象。输入“3号机组的给水流量突然掉了10%但负荷没变主汽压力还在涨这是什么鬼”Agent 运行日志模拟[Agent Reasoning]分析问题关键词给水流量,负荷,主汽压力。初步判断可能是给水泵故障或阀门误关。[Tool Call]search_fault_records(给水流量下降 主汽压力上升)。[Retrieval]召回文档《给水系统故障处理》。[Evaluation]文档只提到了泵跳闸但用户说负荷没变置信度评分0.4 (FAIL)。[Re-Plan]Agent 决定改写查询词增加负荷不变条件并查询历史工单。[Tool Call]search_fault_records(给水流量下降 负荷不变)ANDquery_dcs_data(主汽压力)。[Retrieval]召回工单 #2021-0405“高压旁路阀误开导致虚假水位及流量异常”。[Evaluation]逻辑自洽置信度0.85 (PASS)。[Generation]“根据《高压旁路运行导则》及历史工单 #2021-0405建议立即检查高压旁路阀状态。虽然给水流量显示下降但主汽压力上升且负荷不变极有可能是旁路阀误开导致蒸汽短路引起给水测量偏差。请就地核对旁路阀位。”效果分析普通的 RAG 在第 3 步就会基于“给水流量”检索到“检查给水泵”的错误建议导致运维人员走弯路。而Agentic RAG通过第 5 步的“反思-重试”成功定位了更深层的逻辑关联。6. 总结与展望经验的各种数字永生我们刚刚做的不仅仅是写了一个 Python 脚本而是完成了一次知识建模。从数据层面我们将非结构化的规程、离散的工单通过向量化和图谱技术变成了机器可理解的“记忆”。从逻辑层面我们通过Evaluator和Re-plan赋予了 AI “怀疑精神”。在“同事被优化”的叙事背景下这套系统的价值显得尤为残酷而珍贵。当一个拥有 20 年经验的老师傅离开他留下的不仅是几本手写笔记更是一个能够 24 小时秒回、不知疲倦、且能随着新数据不断自我进化的数字分身。这才是技术对人类经验最大的尊重。附录参考资源与延伸阅读LangGraph Documentation: https://langchain-ai.github.io/langgraph/ (构建循环Agent的最佳框架)Qwen2.5 Technical Report: https://arxiv.org/abs/2309.16609 (通义千问开源模型国产之光)Milvus Hybrid Search: https://milvus.io/docs/hybridsearch.md (多路召回的关键)BGE Re-ranker Model: https://huggingface.co/BAAI/bge-reranker-v2-m3 (提升检索精度的神器)