目录一、组成部分及作用未来的产品化方向成企业数据先说下产生这个想法的背景大语言模型的出现这是最重要的原因因为大模型可以打通多模态数据和结构化数据之间的隔阂AI去理解业务意图、理解数据变成了可能2 DFMEA的痛点大家都认为DFMEA很重要组织上串联了设计、仿真、测试、市场等重要的核心业务的知识认知但是按我实际所经历不得不说DFMEA太容易流于形式了而且在实际业务中这种宝贵的资源很难过程共享和思想传承这点后面会展开讲具体数据分析的利用率不高由于最近几年接触大数据比较多大部分数据都在躺在数据库里面的发挥不到应有的价值一、大数据部分构成实时数据业务数据关键点元数据管理、数据治理、数据质量技术栈Hadoop、spark、flink、mysql、doris、grafana等二、知识图谱部分知识图谱也就是DFMEA作用是赋予可解释性让大模型懂业务同时DFMEA是企业知识沉淀的重要载体需要包含特征失效原因、失效机理、失效模式失效模式将成为非常重要的部分因为是联系知识图谱和数据的纽带一来他是引发其他所有变量和工作的第一因素二来他的质量会直接关系到大模型对数据的处理效果、失效工况这个可以引发正向的诊断类似DVP的概念比方水泵的某个元器件需要300次启停实验验证那这个系统可以对市场的状态进行判断这里单独说一下DFMEA重要性不言而喻是企业非常重要的知识一、可以链接各个重要业务部门的系统性工程二、以前所有的人都认为DFMEA很重要但是确确实实很容易流于形式每次出问题才意识到重要性当前DFMEA的模式不利于闭环鲜有企业做DVP、沉淀、理解只有当事人清楚其他人不清楚、继承三、并且DFMEA和DVPR系统是天然割裂的一、为什么先拿诊断入手企业都在说做实际效果都一般目前形式上最多的也就是诊断码的模式再针对单一专题去找数据分析能在出问题前做一步工作的比较少。像我们业务人员能直接应用大数据平台做分析这种范式就不错了关注度非常高因为故障是重点关注且优先需要解决的事情使用度高围绕一个问题会做很多的工作并且问题是不断的有粘性目前的诊断主要是故障诊断其实也应该做正向诊断DFMEA状态是动态更新的注意这个动态更新表示同一个问题可以设置不同的状态也可以引起触发新的状态希望做成一种灵活的范式灵活面对业务人员的需求、数据库这个就是实时更新就可以了三、大模型部分大模型最重要的是理解业务意图因此最最重要的是前两步的数据部分和知识部分当数据治理和知识治理做好之后大模型上有知识、下有数据作用就会很好的发挥出来PHM呈现最终效果根据知识图谱DFMEA和数据库实时自动运行识别出针对各种失效模式的实时状态包括OK正向的、有故障负向的状态诊断相对好做一些有指标、有评价就好说负向有故障的需要展开给业务人员提供进一步的工具价值。这块是核心形式也是比较多的怎么展开还得结合后面应用层再考虑考虑成企业数据未来的产品化方向数据飞轮数据孤岛知识传承最终形成企业数据飞轮解决当前企业诊断数据孤岛掌握在个人手里单独业务面手里、无继承、数据资产复用让业务人员一直用、离不开三、参与方提供价值业务方软件方业务流程设计、底层技术架构、用户体验提升软件方的价值点在哪呢做垂直行业深度比较难的一来这里从根本上来说图谱、数据、技术大多数都不是自己的做下去深度只属于业务方二来做垂直业务方肯定会把工程困难问题留给软件这是难以解决的相当于走了工业软件的路。做平台/工具这是一个好的切入点如果单纯从这点出发我认为用户工程体验才是第一位的比如业务顺畅、数据开放、反应迅速四、几个层面数据层知识图谱水泵系统运行时序数据库元数据管理、各种数据子库的管理模型层大模型至少识别知识图谱DFMEA/业务人员意图去联动数据库更进一步如果考虑再增加一些知识库让大模型甚至能提供一些主动性的建议有那种AI-Native的感觉更佳小模型理想状态下很多诊断用小模型应用够了但是那些传统的机器学习模型应用在业务中确实比较难比如KNN/随机森林等等吧基于规则类的诊断应该就够了但是基于规则类的形成这个过程是需要耗费大量时间和精力的地方这个地方我觉得可以是个突破点比如根据业务人员描述让大模型生成个类似特征画像然后去联动数据库应用层当一个新产品开发设计阶段甚至还没有物理样机的时候这个时候DFMEA就已经做为知识图谱放到平台中了再往后随着物理样机数据的产生整个系统级/部件级的状态都会动起来实时更新哪些有问题、哪些没问题、状态是什么样的一目了然整个全是从0-1-闭环的生态。当状态偏离业务人员预期的时候业务人员直接可以更改DFMEA图谱调整状态调整允许业务人员开放新场景独立workshop进行小场景、小部件、小应用的分析、识别、训练等等比如系统61吹扫状态窜漏诊断、某个产品匹配公交车的健康管理等等五、用到的技术大数据技术、大模型技术、机器学习技术目前能展望到的困难一、大模型的data agent更多的是texttosql有些功能比较难展开二、工程问题比如多产品多型号