今天是2024年12月05日，星期四，北京，天气晴。
故障分析是知识图谱的一个重要应用，各种高端装备领域的故障案例文本是由业务专家或者专业维修人员撰写的描述相关设备异常、以及故障排查步骤的记录，该记录包括故障现象、故障原因、解决方法以及排故过程等，基于这些数据，可以实现一些问题的快速排查；
更抽象一点，就是：故障检测(从多模态数据源中检测系统是否存在异常)；故障分类(在异常检测能力的基础上，分析出大致的异常类型)；根因定位(即在众多异常中，找到问题根本原因)；故障报告生成(即根据分析结果生成故障报告和恢复建议)；识别用户自然语言提问(用户可以使用自然语言进行提问，模型会理解用户语义并分析出用户给出的任务）。
我们今天来看两个方案，一个是基于朴素知识图谱方案进行故障分析，一个是基于Graph RAG进行故障分析的简单方案，后者显得更粗暴。
供各位参考，多思考，多总结，多实践；
一、基于朴素知识图谱方案进行故障分析
我们之前有讲过故障知识图谱进行分析的一个工作，如在文章《故障知识图谱技术落地探索：装备制造故障知识图谱构建及其应用案例剖析总结》（https://mp.weixin.qq.com/s/CcgLQfgrohwgAQ3TbURlLQ）有过介绍，这里再说下。
先说故障知识图谱构建，这块有个比赛， https://www.datafountain.cn/competitions/584。
对于传统的方案，有个项目https://github.com/wangrenyisme/Shukongdashi，要求从网络上爬取相关设备故障和维修解决方式，并构建知识库，当设备出现故障时，用户通过输入数控机床相关参数（品牌、型号、故障代码、某个或多个超出阈值参数、故障描述(文字或语音)等），系统可以根据知识库来进行故障诊断和排除，如果没有满意的方案，系统会再次进行网络爬取，如果答案有效，则对知识库进行补充和优化。
其中，在技术方案上，主要的数据来源是《实用数控机床故障诊断及维修技术500例》这个PDF文档，对文档里的每一条故障描述进行拆解和分类（CNN），构建出了5中三元式推理规则，分别为：故障现象和故障现象之间存在并发症，故障前执行的操作间接导致的故障现象，某故障原因导致的故障现象，报警信息伴随的故障现象，故障部位常见的故障现象。使用Neo4j图数据库存储。
当用户输入一条故障信息时，按照上面构建RDF的方法，对故障描述先按照标点符号分句，然后使用CNN分类，识别出此次故障中用户执行了哪些操作，出现了哪些故障现象，然后根据知识图谱进行对照，除了推理出故障原因以及解决办法之外，还会推理出与已经发现的故障相关的未发现的设备故障，通过用户进一步检查反馈，可以进一步提高诊断结果的可靠性。如果用户没有找到满意的解决方法，还可以通过在线爬取网上的解决办法来做参考，如果找到了满意的解决办法，系统会将此次维修记录补充到知识图谱中。
最终做成的效果也不错：
而进入大模型时代后，就可以使用RAG的方式来进行排查，例如文章（https://www.asktempo.com/news/industry-information/1777.html）中，针对故障诊断这个话题，有一些大概的宏观思路。
思路很大，原文论述是：当接收到设备故障诊断任务，首先深入理解用户意图，然后基于思维链 CoT技术，大模型将复杂问题分解为一步一步的子问题并依次进行求解，并自主规划最佳任务执行路径，智能地编排并调用模型库诊断模型、机理模型、故障知识库和维修知识库中的经验知识、编写代码计算等不同形式的任务，最后通过大模型的智能分析和总结，给出故障诊断结果、故障定位及故障维修建议。
其实就是agent编排，但其中如何进行流程设计，就是核心点了。
而更大范围的，这其实是属于AIOPS的范畴，所以也可以关注https://www.aiops.cn/aiopschallenge/中的一些思路，例如《构建由大模型辅助的基于多模态数据融合的异常检测、根因诊断和故障报告生成系统》（https://bizseer-png.oss-cn-beijing.aliyuncs.com/2023年挑战赛PPT/季军%20DDopS战队.pdf）提到的方案。
里面提到的思路，其实又包括了知识图谱/事件图谱。
二、基于Graph RAG进行故障分析的简单方案
最近的工作《Knowledge Management for Automobile Failure Analysis Using Graph RAG》(https://arxiv.org/pdf/2411.19539)中提到的基于Graph RAG的思路，可以看看思路，其要解决的问题是如何利用图检索增强生成（RAG）和大模型（LLMs）进行汽车故障分析的知识管理，简单思路就是：首先利用LLMs处理用户查询，识别出与查询相关的汽车问题和故障术语。根据检索到的术语提取子图。每个术语对应的子图定义为目标节点及其相连的边和节点，然后利用LLMs过滤提取的子图，选择与用户查询相关的子图，最后将最终过滤的子图和用户查询一起作为提示输入LLMs，生成最终答案。
这个核心是如何从现有的知识图中提取有用的子图，并将其与LLMs结合以提高故障分析的效率和准确性。
首先，有一个故障图谱，需要先从故障文档中提取组件之间的关系，如下所示：
其中提到的Graph RAG思路，走的是检索底层KG的思路，示意图如下：
以及提出的IR-based Graph RAG思路，很粗暴，示义图如下：
首先，给定用户查询，LLM处理输入并检索一组相关术语，通过识别相关的汽车问题和故障:
其中是指示检索相关单词的提示。
其次，基于检索到的单词提取子图。这种提取涉及生成一个基于规则的搜索查询，该查询没有语法错误。
对于每个单词，定义一个子图为一组关系，包括对应于目标词的节点，以及边和连接的节点。数学上，子图可以表示为：
其中是目标词节点，是与相连的节点集，是连接到或到的边集。但，这些形成了一跳链（这个的问题很大，单跳并不能解决复杂的检索问题）。此外，子图然后表示为图5中显示的文本集合。
接着，使用LLM过滤提取的子图，选择与用户问题相关的候选项。 因为许多边连接到特定单词（如"engine"），导致提取了许多无关的子图，所以这个步骤是必要的。
通过使用LLM，这个步骤减轻了采用IR方法进行KGQA时提取过多子图的常规问题。
设代表提取的子图集。LLM应用一个过滤函数Filter，选择一个与查询相关的子图子集 ：
其中是包含过滤子图指令的提示。
最后，将最终过滤的子图以及用户的问题作为提示提供给LLM，以生成最终答案。 如果选定的子图数量太多且超过了提示的token限制，则在包含在提示之前随机移除子图:
其中是指示LLM推理并生成答案的提示。然后LLM生成最终答案，如下所示：
总结
本文主要围绕故障分析看了两个方案，一个是基于朴素知识图谱方案进行故障分析，一个是基于GraphRAG的方案。后者的本质走的就是召回的路线，其核心点还是说如何召回更为相关的子图，所以，做了一些过滤操作。但缺点很明显，就是没有做到多跳子图，所以大家也可以多尝试。
