DeepseekMathV2对仪控可靠性管理的启示

如果我们想5-10年后让AI替代人类完成当前仪控可靠性管理工作中具有挑战性的几个工作内容：分析设备潜在的故障模式、设备故障的影响、找到异常事件的根本原因、分析共性的故障模式及其影响因素确定维修策略。那么现在应该积累什么？

最近DeepseekMathV2模型给到我们一个思路：对于需要异常严谨的数学证明题，通过“ 自验证数学推理”，利用生成器、验证器、元验证器组合的方式，成功实现了IMO金牌，并在 Putnam测试中大幅度超越最优秀的人类选手。那么未来，对于像仪控可靠性管理中的分析中，有很多事情严谨性还不如数学证明题，但一样需要不断推理的事情。如果我们能够类似的建立一个专用模型，相信也可以超越最优秀的员工。

模型的训练方法总是在不断迭代，IT代码的编码总归有专业人士，但整个事情的起点--数据集的构建总归是属于我们仪控可靠性工程师来搭建的。就像DeepseekMathV2模型需要数学专家给出17503条冷启动数据。这些数据被分成了3档：

1分：证明逻辑严密，所有步骤均有正当理由

0.5分：部分正确但存在可修复的缺陷

0分：存在根本性错误

那么对于我们希望完成的工作，也需要构建这样一个数据集，有的逻辑清晰完整、数据/案例依据翔实，有的略有缺陷，有的存在根本性错误。

构建这样一个数据集的工作量非常大，显然不是个人或一个小组能够完成的。如果分派给许多人共同完成，不可避免的存在标准和质量不统一的问题。所以未来要落地，这部分冷启动数据不可避免的需要使用生成式数据或AI辅助。在这个过程中，我相信必然需要如下步骤：

1. 将高质量分析数据进行链条拆解。比如IOE/LOE等报告。这些是我们手里质量最高的文本。但对于训练AI来说可能还是不够，因为其中很多思考步骤并没有显式的写出来。所以需要利用AI辅助等手段，对这些报告进行思维链条拆解。
2. 数据治理与高质量查询接口。我们的文档里可能非常简单的写着说“根据XX文档/文件，该设备运行原理为****”或“查询经验反馈可知，该设备曾经****”。这些信息对于外部的种子AI来说，显然是不可知的。需要我们做好数据治理和高质量的查询接口。
3. 找到或定义错误的案例。“失败是成功之母”，对于AI训练来说看来也是一样。而高质量的错误，可能是更难寻找的。对于数学证明过程，利用学生考试中的错误是一个简单的方法。但对于仪控可靠性分析，也许我们能找到一些写的粗糙、简略不合乎格式要求的东西。但“错误”该如何定义和积累将成为难题。大部分已有的IT系统中只积累了最后正确的数据。部分带审批记录的IT系统重退回信息中大部分都缺少真正的原因分析。因此无法筛选是简单的错别字退回，还是由于某些“管理/KPI”考虑的退回，还是真正的逻辑错误。

近期来说，最急迫而且立刻就能做的事情就是数据治理和构建高质量查询接口。这部分工作做成后，就可以先利用这些数据先上一些简单的应用。

长远来看，我觉得新员工是我们迈向AGI时代的宝贵财富。他们充满活力和创造力。如果我们能记录好他们学习的经历和犯下的错误。那么未来训练AI时，这也会是一笔宝贵的财富，让AI能够知道如何学习，或者让AI训练师知道该如何训练一个垂类模型。