上星期发过一篇关于AIOPS的最后一公里的文章，主要观点是OPS需要确定的回答，而AI给出的泛化分析不能满足OPS的需求。需要通过“知识自动化”来补齐这最后一公里。上周六观摩AIOPS挑战赛的时候发现无论是获得大奖的字节“卷卷卷卷，卷不动了啊”代表队的SRE-COPILOT、华为轻舟队的多AGENT协同框架，还是南瑞研究院的基于运维知识图谱的根因定位方案，都采用了以智能推理+API验证的技术路线。

SRE-Copilot架构的Copilot通过大模型实现，通过意图识别进行参数提取，分解后通过多源Agent调用来进行后续分析，查找根因。而各种Agent对各种数据源进行异常检测，返回故障描述。

上周的文章中我画了一张未来D-SMART的愿景图，当时把大模型推理放到了一个辅助的位置上，作为知识自动化和异常检测工具的辅助。周六的大赛让我脑洞大开，也解放了思想。大模型不仅仅可以作为辅助的工具，可以在整个AIOPS体系中承担更为重要的作用。

确定了大模型的核心地位后，整个系统架构简化了很多，以大模型为核心，将知识自动化和基于小模型的AIOPS三者有机的整合在一起了。简单的东西比较容易做好，简化后的架构图在技术落地上要容易多了。

运维大模型需要选择运维方面性能较好的通识大模型进行微调训练，形成能力较强的基础模型，通过专家知识向量嵌入，打造较为精准的智能化推理分析引擎。直接选择通识大模型进行向量嵌入很容易做成对于专家知识的精准搜索，降低智能运维的泛化能力。通过推形成的结论需要通过结构化的异常分类器进行结构化还原。还原后生成可以用于小模型引擎分析与知识自动化分析的任务，调度任务平台分别进行扫描。发现的异常通过AIOPS小模型算法进行故障收敛和归类。最后将发现的问题再交给只是自动化专家系统进行二次确认，生成更为精准的根因发现结论。最后由运维大模型进行归纳总结，生成分析报告。

在这个框架中，小模型方面的算法有很多比较成熟的方案，不过也需要在运维领域找到比较适合的算法，这个工作相对而言比较容易落地。知识自动化部分的工作量是相对较大的，不过如果不是急功近利，可以耐下心来一点点的梳理，成熟一块上一块，经过一定时间积累，一定是没有问题的。其中最大的变数来自于运维大模型。因为直接使用目前开源的通识大模型效果肯能不佳，而微调训练也是个细活，比较耗时耗力，一般企业缺乏GPU资源，可能做起来也有点费劲，而且目前没有靠谱的商用产品可以购买。

虽然如此，经过这些天的思考，已经初步有了一个可落地的方案，下一步就看如何去干了。很多事情，想的时候却是问题多多，不过做起来就是遇到问题解决问题了。刚才和一个客户的IT部门领导探讨这张图，他看着觉得还行，不过最后说，这玩意必须有效才有用，这话很有道理。

原标题：《再谈大模型加持下的AIOPS,开会回来重新画了张图》