复杂系统诊断的核心难点之一是故障现象、失效模式、部件状态和维修记录之间往往存在多对多、跨层级的因果依赖单个故障树或静态表格很难完整表达。把动态主逻辑模型Dynamic Master Logic Model用知识图谱Knowledge Graph, KG来承载再借助检索增强大型语言模型Retrieval-Augmented Large Language Model, RAG-LLM从维修手册、故障报告和报警记录中提取候选因果链是近年来复杂系统智能诊断里比较可行的自动化建模路线。这里解决的不是“让大模型直接判断故障原因”的问题而是“如何低成本地构建和维护一张可以持续更新的主逻辑模型图”。传统主逻辑模型依赖领域专家手工搭建周期长、维护难把模型落到知识图谱后节点和关系成为数据可以增量合并、版本化、软删除而 RAG-LLM 负责把非结构化资料转成候选节点和候选边再由工程师审核确认。整条链路本质上是“大模型提候选、图谱做存储、人工做裁决”的人机协作流水线。下面从核心概念、架构设计、环境准备、本体设计、检索链路、候选生成、运行验证、常见问题和落地清单九个部分展开。内容面向负责复杂系统诊断建模、PHM故障预测与健康管理系统建设、知识工程平台开发以及想了解 GraphRAG 落地实践的工程师。1. 先理解动态主逻辑模型的三个关键问题1.1 主逻辑模型解决什么诊断问题主逻辑模型源自可靠性工程中的故障树分析FTA和失效模式与影响分析FMEA。在复杂系统诊断场景里它通常把系统级故障顶层事件逐层展开成中间功能失效再落到部件级根因。比如“液压系统压力异常”向下展开为“油泵输出不足”“溢流阀异常开启”“蓄能器漏气”等失效模式每个失效模式继续展开到具体的部件和物理原因。这种分层展开结构就是诊断知识的主干。主逻辑模型的作用不是展示因果而是支持推理。当现场出现一个顶层症状时工程师可以沿着模型找到可能失效的功能、部件和根因再结合当时的报警、传感器数据和维修历史缩小范围。模型覆盖得越完整诊断搜索空间就越小误判概率也就越低。但真实系统并不总是严格树形。一个失效模式可以由多个根因触发一个根因也能表现为多个症状部件之间还存在级联失效。例如“油温过高”既可能是冷却器堵塞也可能是回油管路堵塞而两者又互相加重。树形结构表达这种共享节点和级联关系时会产生大量重复子树维护成本急剧上升。1.2 “动态”为什么是难点而不是可选项所谓动态有两个层面。第一是模型内容动态。系统运行一段时间后设备改造、部件换型、维修策略变化都会让旧的因果关系失效。原来成立的“A 导致 B”在新版本设备里可能不再成立原来罕见的根因在特定工况下变成了高频故障。第二是证据动态。新的报警记录、维修记录和传感器趋势会不断产生新证据。这些证据要么增强某个根因的置信度要么推翻原来的结论。如果模型是静态的等故障再次发生时系统里还是旧版本的因果链必然导致误判。动态更新的难点在于资料来源分散。设备手册是 PDF维修记录在工单系统里报警码字典在 SCADA 系统里专家经验则散落在历史报告里。靠人工把这些信息同步进知识模型速度跟不上系统变化。因此“动态”不是模型的一个装饰属性而是诊断系统能否持续使用的前提。1.3 为什么用知识图谱而不是故障树或关系表三种表达方式的差异可以从结构能力、扩展性、动态更新和查询推理四个角度对比。表达方式结构能力扩展性动态更新推理与查询树形不支持共享节点表达多因一果困难修改需要重建子树困难容易不一致只能自顶向下遍历搜索多条路径麻烦关系表用外键表达关系语义弱频繁改表结构记录可增删但关系含义不直观多表 join 复杂级联查询成本高知识图谱天然支持多对多、跨层级的共享节点增加节点类型和关系类型即可扩展增量 merge、版本化、软删除图遍历、路径检索、可达性分析直接选择知识图谱不是因为它比较新而是因为可扩展性和动态更新这两点直接命中主逻辑模型维护的痛点。图数据库的MERGE支持增量写入节点可以带状态和置信度属性关系可以被软删除。这些机制让“动态”变成数据层能力而不是每次都要改写程序中频繁更新模型。2. 检索增强大模型在模型构建里的真实分工2.1 传统构建方式和 RAG 辅助构建的对比过去构建主逻辑模型主要靠专家访谈和人工读资料。工程师把维修手册、故障报告和报警记录读一遍提炼出因果链再手工画图。这种方式精度高但成本高而且不同专家的表达习惯不一致同一个根因在不同报告里叫法可能完全不同。RAG-LLM 的价值不是替代专家而是把“读资料、提候选”这段最耗时的工作自动化。模型先根据顶层异常从资料库中检索相关片段再基于这些片段生成候选故障链。工程师不需要逐页读报告只需要审核模型给出的候选链是否成立。这样就完成了从“人读资料”到“人审结果”的转变。对比关系可以概括为人工方式把大量时间花在资料阅读和信息提炼上RAG 方式把时间花在检索质量优化、提示词设计和审核规则制定上。前者的瓶颈是人力后者的瓶颈是工程。2.2 RAG 解决幻觉和上下文不足的问题大模型直接生成因果链时有一个突出风险幻觉。模型可能把一个不存在的部件写进链路把“冷却不足”误写成“冷却液泄漏”或者虚构一个业内不存在的故障代码。原因是模型从预训练知识里回忆答案而不是从当前系统的真实资料里推导。RAG 通过检索把真实文档片段注入上下文相当于给模型一份“可以引用的事实材料”。当系统提示词明确要求“只使用检索材料中出现的实体和关系”时幻觉会显著下降。检索到的片段还携带来源编号模型输出的每条边都可以引用这些编号形成证据链路。值得注意的是RAG 并不能完全消除幻觉只能通过“限制证据来源”来降低幻觉概率。模型仍可能错误理解检索片段或把两个不相关片段强行组合。因此候选链必须经过结构化校验和人工审核不能直接落库作为最终结论。2.3 边界划分模型构建、诊断推理、人工审核三层分离整个系统要分清三层职责。第一层是模型构建。RAG-LLM 负责从资料中提炼候选节点和候选边输出一段候选故障传播链。它的产物是“建议”不是“结论”。第二层是诊断推理。图数据库承担从症状出发查找可达根因路径、计算最短路径、检索共享故障模式等任务。这些推理要基于已经审核通过的确定性图谱结构不能依赖大模型每次不同的随机输出。第三层是人工审核。候选链中的PROPOSED状态节点由领域专家确认确认后转为APPROVED驳回后转为REJECTED。人可以批量处理也可以在审核界面逐条对比证据。不要在提示词里让大模型直接回答“当前故障原因是什么”。那属于推理任务容易受模型随机性影响而且难以追溯。正确的做法是让大模型输出“基于哪些证据认为哪些因果关系可能成立”再把审核后的结果交给图数据库去推理。3. 总体架构与选型3.1 五层流水线设计从实际落地角度整个系统可以分成五层。每层只负责一件事层与层之间通过标准数据结构衔接。层级职责关键组件数据源层接入维修工单、设备手册、报警字典、传感器事件文件解析脚本、工单系统导出、SCADA 接口接入解析层文档清洗、切分、元数据补充LangChain 文档加载器、自研解析脚本存储层保存图结构、向量索引和元数据Neo4j、ChromaDB/FAISS、关系表检索层向量检索、关键词检索、图谱子图检索Embedding 模型、混合检索服务生成与治理层提示词模板、LLM 调用、结构化校验、合并策略OpenAI 兼容接口、Pydantic、合并脚本这里的关键设计是“检索层”和“生成层”分离。检索层只负责把相关资料找出来生成层才调用大模型。这样当模型服务变更或提示词调整时检索结果可以重复使用也方便对每一层单独做评估和优化。3.2 技术选型速查表下面是一组用于原型验证和中小规模生产的选型建议。版本更新很快落地前应以实际安装时的稳定版本为准。组件建议方案用途注意点知识图谱Neo4j Community 5.x保存主逻辑模型节点与边需要建唯一约束和索引向量库ChromaDB 或 FAISS保存文档切片向量生产环境可换 Milvus 或 pgvector嵌入模型BAAI/bge-base-zh-v1.5中文维修文档向量化中文场景效果优于通用模型LLM 调用OpenAI 兼容 HTTP 接口生成候选故障链支持 Qwen、DeepSeek、本地 vLLM 等校验框架PydanticJSON 结构化校验强类型约束减少脏数据调度Python 脚本 定时任务定期处理新增维修记录生产可接 Airflow 或流水线平台3.3 学习环境与生产环境的部署差异学习环境一台机器就能跑通Neo4j 容器加 Python 脚本再加本地嵌入模型。向量库用 ChromaDBLLM 可以连主流的模型 API也可以在本地起一个量化模型服务。生产环境还需要额外补几件事。图库要有备份机制和连接高可用向量库与图库要保持一致文档切片的source_id要和图库中的Evidence节点对应LLM API 要处理超时、限流和失败重试维修记录进入检索库前要脱敏候选链审核队列要有负责人和 SLA整条链路要有日志、指标和告警。学习环境不做的这些事恰恰是生产环境是否能长期运行的关键。4. 环境准备与依赖配置4.1 Python 依赖清单建议使用 Python 3.10 或 3.11先创建独立虚拟环境再安装依赖。下面的requirements.txt是一个可运行组合实际项目按需增删。neo4j5.19.0 langchain0.2.5 langchain-community0.2.5 chromadb0.5.0 sentence-transformers2.7.0 pydantic2.7.0 openai1.30.0 python-dotenv1.0.1 pyyaml6.0.1安装命令pip install -r requirements.txt这里的版本号只是示例锁定不要把它当作长期固定版本。安装后建议打印关键库版本避免因为版本不匹配出现奇怪的 API 报错。4.2 启动 Neo4j 图数据库使用 Docker 启动 Neo4j 社区版是最快的方式。下面的命令把数据目录挂载到neo4j_data卷并启用 APOC 插件方便后续做路径分析和数据处理。docker run -d \ --name neo4j-kg \ -p 7474:7474 \ -p 7687:7687 \ -e NEO4J_AUTHneo4j/ChangeMe123 \ -e NEO4J_PLUGINS[apoc] \ -v neo4j_data:/data \ neo4j:5.19-community启动后可以通过docker logs -f neo4j-kg查看日志等待出现 ready 状态。浏览器访问http://localhost:7474使用neo4j / ChangeMe123登录。注意ChangeMe123是临时口令正式环境必须替换为符合复杂度要求的强密码。4.3 配置大模型与嵌入模型所有外部服务统一放在config.yaml中密钥通过环境变量注入不要写死在代码里。下面是一个精简配置kg: uri: bolt://localhost:7687 user: neo4j password: ChangeMe123 llm: base_url: http://localhost:8000/v1 api_key: ${LLM_API_KEY} model_name: qwen2.5-7b-instruct temperature: 0.1 embedding: model_name: BAAI/bge-base-zh-v1.5 persist_dir: ./data/vector_store retrieval: top_k: 6 chunk_size: 600 chunk_overlap: 100读取配置时用代码加载 YAML 再补充环境变量覆盖。api_key如果留空就代表使用本地免鉴权模型服务。temperature压低到 0.1是为了让候选链生成尽量稳定诊断建模场景不希望模型发挥太多创造力。5. 知识图谱本体设计与种子数据5.1 节点类型定义本体设计决定后续提示词和校验逻辑怎么写因此要先定义清楚节点类型和属性。对于动态主逻辑模型建议至少包含以下节点类型。节点类型含义关键属性Symptom观测到的异常表现name, description, source_systemFailureMode功能失效模式name, description, status, confidenceRootCause根因name, description, physical_mechanismComponent部件或设备name, model, serial_noEvidence证据文档片段source_id, doc_source, timestampMaintenanceAction维修动作name, action, effect节点类型不宜过多。常见错误是一上来就设计十几种业务对象导致提示词很难约束、实体对齐很难做。从最小集合开始后续按需增加。5.2 关系类型定义关系名称尽量用动词这样 Cypher 查询读起来接近自然语言。建议定义以下关系关系类型方向含义SIGNALSSymptom - FailureMode症状指向失效模式CAUSED_BYFailureMode - RootCause失效模式由根因导致OCCURS_INRootCause - Component根因发生在部件上PART_OFComponent - Component部件从属关系SUPPORTSEvidence - FailureMode证据支持失效模式TREATED_BYFailureMode - MaintenanceAction失效模式可由维修动作处理一条标准诊断链就是Symptom - SIGNALS - FailureMode - CAUSED_BY - RootCause - OCCURS_IN - Component。此外每个候选节点和候选边都建议带上status、confidence、create_time、evidence_ids这些属性为动态更新和审核做准备。5.3 约束、索引与种子数据导入图库的MERGE依赖唯一约束否则同一实体可能被重复创建。启动 Neo4j 后先执行下面的 CypherCREATE CONSTRAINT IF NOT EXISTS FOR (n:Symptom) REQUIRE n.name IS UNIQUE; CREATE CONSTRAINT IF NOT EXISTS FOR (n:FailureMode) REQUIRE n.name IS UNIQUE; CREATE CONSTRAINT IF NOT EXISTS FOR (n:RootCause) REQUIRE n.name IS UNIQUE; CREATE CONSTRAINT IF NOT EXISTS FOR (n:Component) REQUIRE n.name IS UNIQUE; CREATE CONSTRAINT IF NOT EXISTS FOR (n:Evidence) REQUIRE n.source_id IS UNIQUE;种子数据可以来自设备台账和故障字典。以 JSON 格式准备[ {type: Component, name: 主油泵, properties: {model: PVH131}}, {type: FailureMode, name: 主油泵输出流量不足, properties: {status: APPROVED, confidence: 0.95}}, {type: RootCause, name: 配流盘磨损, properties: {physical_mechanism: 间隙增大导致内泄漏}} ]使用 Neo4j Python Driver 批量导入from neo4j import GraphDatabase with GraphDatabase.driver(cfg[kg][uri], auth(cfg[kg][user], cfg[kg][password])) as driver: with driver.session() as session: for item in seed_data: node_type item[type] name item[name] props item.get(properties, {}) session.run( fMERGE (n:{node_type} {{name: $name}}) SET n $props, namename, propsprops )注意这里的node_type是预设 知识图谱+RAG-LLM驱动动态主逻辑模型：复杂系统智能诊断新路径
复杂系统诊断的核心难点之一是故障现象、失效模式、部件状态和维修记录之间往往存在多对多、跨层级的因果依赖单个故障树或静态表格很难完整表达。把动态主逻辑模型Dynamic Master Logic Model用知识图谱Knowledge Graph, KG来承载再借助检索增强大型语言模型Retrieval-Augmented Large Language Model, RAG-LLM从维修手册、故障报告和报警记录中提取候选因果链是近年来复杂系统智能诊断里比较可行的自动化建模路线。这里解决的不是“让大模型直接判断故障原因”的问题而是“如何低成本地构建和维护一张可以持续更新的主逻辑模型图”。传统主逻辑模型依赖领域专家手工搭建周期长、维护难把模型落到知识图谱后节点和关系成为数据可以增量合并、版本化、软删除而 RAG-LLM 负责把非结构化资料转成候选节点和候选边再由工程师审核确认。整条链路本质上是“大模型提候选、图谱做存储、人工做裁决”的人机协作流水线。下面从核心概念、架构设计、环境准备、本体设计、检索链路、候选生成、运行验证、常见问题和落地清单九个部分展开。内容面向负责复杂系统诊断建模、PHM故障预测与健康管理系统建设、知识工程平台开发以及想了解 GraphRAG 落地实践的工程师。1. 先理解动态主逻辑模型的三个关键问题1.1 主逻辑模型解决什么诊断问题主逻辑模型源自可靠性工程中的故障树分析FTA和失效模式与影响分析FMEA。在复杂系统诊断场景里它通常把系统级故障顶层事件逐层展开成中间功能失效再落到部件级根因。比如“液压系统压力异常”向下展开为“油泵输出不足”“溢流阀异常开启”“蓄能器漏气”等失效模式每个失效模式继续展开到具体的部件和物理原因。这种分层展开结构就是诊断知识的主干。主逻辑模型的作用不是展示因果而是支持推理。当现场出现一个顶层症状时工程师可以沿着模型找到可能失效的功能、部件和根因再结合当时的报警、传感器数据和维修历史缩小范围。模型覆盖得越完整诊断搜索空间就越小误判概率也就越低。但真实系统并不总是严格树形。一个失效模式可以由多个根因触发一个根因也能表现为多个症状部件之间还存在级联失效。例如“油温过高”既可能是冷却器堵塞也可能是回油管路堵塞而两者又互相加重。树形结构表达这种共享节点和级联关系时会产生大量重复子树维护成本急剧上升。1.2 “动态”为什么是难点而不是可选项所谓动态有两个层面。第一是模型内容动态。系统运行一段时间后设备改造、部件换型、维修策略变化都会让旧的因果关系失效。原来成立的“A 导致 B”在新版本设备里可能不再成立原来罕见的根因在特定工况下变成了高频故障。第二是证据动态。新的报警记录、维修记录和传感器趋势会不断产生新证据。这些证据要么增强某个根因的置信度要么推翻原来的结论。如果模型是静态的等故障再次发生时系统里还是旧版本的因果链必然导致误判。动态更新的难点在于资料来源分散。设备手册是 PDF维修记录在工单系统里报警码字典在 SCADA 系统里专家经验则散落在历史报告里。靠人工把这些信息同步进知识模型速度跟不上系统变化。因此“动态”不是模型的一个装饰属性而是诊断系统能否持续使用的前提。1.3 为什么用知识图谱而不是故障树或关系表三种表达方式的差异可以从结构能力、扩展性、动态更新和查询推理四个角度对比。表达方式结构能力扩展性动态更新推理与查询树形不支持共享节点表达多因一果困难修改需要重建子树困难容易不一致只能自顶向下遍历搜索多条路径麻烦关系表用外键表达关系语义弱频繁改表结构记录可增删但关系含义不直观多表 join 复杂级联查询成本高知识图谱天然支持多对多、跨层级的共享节点增加节点类型和关系类型即可扩展增量 merge、版本化、软删除图遍历、路径检索、可达性分析直接选择知识图谱不是因为它比较新而是因为可扩展性和动态更新这两点直接命中主逻辑模型维护的痛点。图数据库的MERGE支持增量写入节点可以带状态和置信度属性关系可以被软删除。这些机制让“动态”变成数据层能力而不是每次都要改写程序中频繁更新模型。2. 检索增强大模型在模型构建里的真实分工2.1 传统构建方式和 RAG 辅助构建的对比过去构建主逻辑模型主要靠专家访谈和人工读资料。工程师把维修手册、故障报告和报警记录读一遍提炼出因果链再手工画图。这种方式精度高但成本高而且不同专家的表达习惯不一致同一个根因在不同报告里叫法可能完全不同。RAG-LLM 的价值不是替代专家而是把“读资料、提候选”这段最耗时的工作自动化。模型先根据顶层异常从资料库中检索相关片段再基于这些片段生成候选故障链。工程师不需要逐页读报告只需要审核模型给出的候选链是否成立。这样就完成了从“人读资料”到“人审结果”的转变。对比关系可以概括为人工方式把大量时间花在资料阅读和信息提炼上RAG 方式把时间花在检索质量优化、提示词设计和审核规则制定上。前者的瓶颈是人力后者的瓶颈是工程。2.2 RAG 解决幻觉和上下文不足的问题大模型直接生成因果链时有一个突出风险幻觉。模型可能把一个不存在的部件写进链路把“冷却不足”误写成“冷却液泄漏”或者虚构一个业内不存在的故障代码。原因是模型从预训练知识里回忆答案而不是从当前系统的真实资料里推导。RAG 通过检索把真实文档片段注入上下文相当于给模型一份“可以引用的事实材料”。当系统提示词明确要求“只使用检索材料中出现的实体和关系”时幻觉会显著下降。检索到的片段还携带来源编号模型输出的每条边都可以引用这些编号形成证据链路。值得注意的是RAG 并不能完全消除幻觉只能通过“限制证据来源”来降低幻觉概率。模型仍可能错误理解检索片段或把两个不相关片段强行组合。因此候选链必须经过结构化校验和人工审核不能直接落库作为最终结论。2.3 边界划分模型构建、诊断推理、人工审核三层分离整个系统要分清三层职责。第一层是模型构建。RAG-LLM 负责从资料中提炼候选节点和候选边输出一段候选故障传播链。它的产物是“建议”不是“结论”。第二层是诊断推理。图数据库承担从症状出发查找可达根因路径、计算最短路径、检索共享故障模式等任务。这些推理要基于已经审核通过的确定性图谱结构不能依赖大模型每次不同的随机输出。第三层是人工审核。候选链中的PROPOSED状态节点由领域专家确认确认后转为APPROVED驳回后转为REJECTED。人可以批量处理也可以在审核界面逐条对比证据。不要在提示词里让大模型直接回答“当前故障原因是什么”。那属于推理任务容易受模型随机性影响而且难以追溯。正确的做法是让大模型输出“基于哪些证据认为哪些因果关系可能成立”再把审核后的结果交给图数据库去推理。3. 总体架构与选型3.1 五层流水线设计从实际落地角度整个系统可以分成五层。每层只负责一件事层与层之间通过标准数据结构衔接。层级职责关键组件数据源层接入维修工单、设备手册、报警字典、传感器事件文件解析脚本、工单系统导出、SCADA 接口接入解析层文档清洗、切分、元数据补充LangChain 文档加载器、自研解析脚本存储层保存图结构、向量索引和元数据Neo4j、ChromaDB/FAISS、关系表检索层向量检索、关键词检索、图谱子图检索Embedding 模型、混合检索服务生成与治理层提示词模板、LLM 调用、结构化校验、合并策略OpenAI 兼容接口、Pydantic、合并脚本这里的关键设计是“检索层”和“生成层”分离。检索层只负责把相关资料找出来生成层才调用大模型。这样当模型服务变更或提示词调整时检索结果可以重复使用也方便对每一层单独做评估和优化。3.2 技术选型速查表下面是一组用于原型验证和中小规模生产的选型建议。版本更新很快落地前应以实际安装时的稳定版本为准。组件建议方案用途注意点知识图谱Neo4j Community 5.x保存主逻辑模型节点与边需要建唯一约束和索引向量库ChromaDB 或 FAISS保存文档切片向量生产环境可换 Milvus 或 pgvector嵌入模型BAAI/bge-base-zh-v1.5中文维修文档向量化中文场景效果优于通用模型LLM 调用OpenAI 兼容 HTTP 接口生成候选故障链支持 Qwen、DeepSeek、本地 vLLM 等校验框架PydanticJSON 结构化校验强类型约束减少脏数据调度Python 脚本 定时任务定期处理新增维修记录生产可接 Airflow 或流水线平台3.3 学习环境与生产环境的部署差异学习环境一台机器就能跑通Neo4j 容器加 Python 脚本再加本地嵌入模型。向量库用 ChromaDBLLM 可以连主流的模型 API也可以在本地起一个量化模型服务。生产环境还需要额外补几件事。图库要有备份机制和连接高可用向量库与图库要保持一致文档切片的source_id要和图库中的Evidence节点对应LLM API 要处理超时、限流和失败重试维修记录进入检索库前要脱敏候选链审核队列要有负责人和 SLA整条链路要有日志、指标和告警。学习环境不做的这些事恰恰是生产环境是否能长期运行的关键。4. 环境准备与依赖配置4.1 Python 依赖清单建议使用 Python 3.10 或 3.11先创建独立虚拟环境再安装依赖。下面的requirements.txt是一个可运行组合实际项目按需增删。neo4j5.19.0 langchain0.2.5 langchain-community0.2.5 chromadb0.5.0 sentence-transformers2.7.0 pydantic2.7.0 openai1.30.0 python-dotenv1.0.1 pyyaml6.0.1安装命令pip install -r requirements.txt这里的版本号只是示例锁定不要把它当作长期固定版本。安装后建议打印关键库版本避免因为版本不匹配出现奇怪的 API 报错。4.2 启动 Neo4j 图数据库使用 Docker 启动 Neo4j 社区版是最快的方式。下面的命令把数据目录挂载到neo4j_data卷并启用 APOC 插件方便后续做路径分析和数据处理。docker run -d \ --name neo4j-kg \ -p 7474:7474 \ -p 7687:7687 \ -e NEO4J_AUTHneo4j/ChangeMe123 \ -e NEO4J_PLUGINS[apoc] \ -v neo4j_data:/data \ neo4j:5.19-community启动后可以通过docker logs -f neo4j-kg查看日志等待出现 ready 状态。浏览器访问http://localhost:7474使用neo4j / ChangeMe123登录。注意ChangeMe123是临时口令正式环境必须替换为符合复杂度要求的强密码。4.3 配置大模型与嵌入模型所有外部服务统一放在config.yaml中密钥通过环境变量注入不要写死在代码里。下面是一个精简配置kg: uri: bolt://localhost:7687 user: neo4j password: ChangeMe123 llm: base_url: http://localhost:8000/v1 api_key: ${LLM_API_KEY} model_name: qwen2.5-7b-instruct temperature: 0.1 embedding: model_name: BAAI/bge-base-zh-v1.5 persist_dir: ./data/vector_store retrieval: top_k: 6 chunk_size: 600 chunk_overlap: 100读取配置时用代码加载 YAML 再补充环境变量覆盖。api_key如果留空就代表使用本地免鉴权模型服务。temperature压低到 0.1是为了让候选链生成尽量稳定诊断建模场景不希望模型发挥太多创造力。5. 知识图谱本体设计与种子数据5.1 节点类型定义本体设计决定后续提示词和校验逻辑怎么写因此要先定义清楚节点类型和属性。对于动态主逻辑模型建议至少包含以下节点类型。节点类型含义关键属性Symptom观测到的异常表现name, description, source_systemFailureMode功能失效模式name, description, status, confidenceRootCause根因name, description, physical_mechanismComponent部件或设备name, model, serial_noEvidence证据文档片段source_id, doc_source, timestampMaintenanceAction维修动作name, action, effect节点类型不宜过多。常见错误是一上来就设计十几种业务对象导致提示词很难约束、实体对齐很难做。从最小集合开始后续按需增加。5.2 关系类型定义关系名称尽量用动词这样 Cypher 查询读起来接近自然语言。建议定义以下关系关系类型方向含义SIGNALSSymptom - FailureMode症状指向失效模式CAUSED_BYFailureMode - RootCause失效模式由根因导致OCCURS_INRootCause - Component根因发生在部件上PART_OFComponent - Component部件从属关系SUPPORTSEvidence - FailureMode证据支持失效模式TREATED_BYFailureMode - MaintenanceAction失效模式可由维修动作处理一条标准诊断链就是Symptom - SIGNALS - FailureMode - CAUSED_BY - RootCause - OCCURS_IN - Component。此外每个候选节点和候选边都建议带上status、confidence、create_time、evidence_ids这些属性为动态更新和审核做准备。5.3 约束、索引与种子数据导入图库的MERGE依赖唯一约束否则同一实体可能被重复创建。启动 Neo4j 后先执行下面的 CypherCREATE CONSTRAINT IF NOT EXISTS FOR (n:Symptom) REQUIRE n.name IS UNIQUE; CREATE CONSTRAINT IF NOT EXISTS FOR (n:FailureMode) REQUIRE n.name IS UNIQUE; CREATE CONSTRAINT IF NOT EXISTS FOR (n:RootCause) REQUIRE n.name IS UNIQUE; CREATE CONSTRAINT IF NOT EXISTS FOR (n:Component) REQUIRE n.name IS UNIQUE; CREATE CONSTRAINT IF NOT EXISTS FOR (n:Evidence) REQUIRE n.source_id IS UNIQUE;种子数据可以来自设备台账和故障字典。以 JSON 格式准备[ {type: Component, name: 主油泵, properties: {model: PVH131}}, {type: FailureMode, name: 主油泵输出流量不足, properties: {status: APPROVED, confidence: 0.95}}, {type: RootCause, name: 配流盘磨损, properties: {physical_mechanism: 间隙增大导致内泄漏}} ]使用 Neo4j Python Driver 批量导入from neo4j import GraphDatabase with GraphDatabase.driver(cfg[kg][uri], auth(cfg[kg][user], cfg[kg][password])) as driver: with driver.session() as session: for item in seed_data: node_type item[type] name item[name] props item.get(properties, {}) session.run( fMERGE (n:{node_type} {{name: $name}}) SET n $props, namename, propsprops )注意这里的node_type是预设