本文内容来自清华大学计算机系长聘副教授裴丹在 CCF 国内 AIOps 挑战赛宣讲会暨 AIOps 研讨会，及其他运维畛域前沿研究会议上，对于《运维大模型瞻望》的演讲。
2023 CCF 国内 AIOps 挑战赛炽热报名中（AIOps 挑战赛炽热报名中，26 万奖金池等你来瓜分！）上一篇文章咱们分享了清华大学裴丹传授演讲的《运维大模型瞻望》的上半局部（链接：清华裴丹 | 运维大模型瞻望 - 上篇），次要讲述了大模型在运维畛域利用可能面临的问题和技术挑战、探讨了对于运维大语言模型状态及利用。本篇文章咱们会重点分享运维大模型的整体架构和中长期利用。
第二局部：运维大模型整体架构
运维大模型大略是一个什么概念？
首先，要把运维的公域和私域离开。在运维畛域共性多于差异化。比方，一个运维专家，从 A 公司入职到 B 公司，适应新的工作环境须要一个过程，然而他依附通用的运维常识也能够疾速的开展工作，所以须要把共性的货色集中力量做好。私域方面做一些简化的工作，因为私域很难进行大规模的训练工作，起因是数据出不来，且算力和语料无限。
其次，利用人工智能社区最新、最强有力的开源大语言模型底座，基于多模态的运维常识图谱和混合专家模型，构建运维通用的大语言模型。
第三，须要多模态运维数据的根底模型群。波及到多模态运维数据的根底模型群，每一项都有典型的、多模态的数据源。就像医学畛域一样，须要影像的根底模型、核磁的根底模型、CT 的根底模型，每一项都须要粗浅地了解它的特点才可能做得更好。间接套用大语言模型解决不是原生的文字语料数据，想要做出好的成果是比拟艰难的。
第四，运维大模型中还蕴含已有的自动化的运维工具，通过根底模型的编程框架（LangChain 等）编排在一起。前提是这些工具的接口尽量标准化，可能分明地形容出 API，用自然语言形容进去的需要可能间接转换成对接口的调用，不论是简略变成 Graph SQL，还是变成配置，或者变成 API 的调用。前提是要做好根底工作，否则参数填错一点点，后果会相差很远。而后，在公有部署方面，能够应用一些轻量级的办法将公有的个性化个性融入运维大模型中。
MetricFM 运维多模态的数据，如最常见的监控中的指标数据，它的状态是多样化的，不同的指标状态不一样，有些业务指标跟人的作息相干，周期性很强；有一些偏基础设施，规律性较弱。
MetricFM 上游工作 - 基线生成
基于这些指标，会有很多工作，比如说监控，用算法动静计算高低稳定的基线。上图是咱们演示的成果，须要针对不同模式计算出基线，其本质是捕捉指标数据外在法则的一种能力。
MetricFM 上游工作 - 模式识别
比如说当初的工作不是计算一个高低稳定的基线并产生告警，而是要辨认进去当初有哪些模式：是爬坡、是上台阶还是下坡，这其实是对模式的一种捕捉能力。
MetricFM 上游工作 - 趋势预测
比方趋势预测，计算它的斜率是向上还是向下，算斜率的时候，这个曲线不肯定是直线，可能是有肯定的趋势又带肯定的稳定。过来咱们用小模型的形式，每一个都是独自做模型，而后评估准确率。实质上须要对底层类型的数据有深刻理解的能力，在这之上建设根底模型，而这些工作就是根底模型的一个个小模型的利用。对于日志、trace 数据、告警数据、其余数据也都是相似的状况。多模态的数据每一个都有本人强烈的特点，基于这些特点建设的根底模型（Foundation Model）, 而后对它的上游利用再建设模型，这种思路对 AIOps 智能运维方向也是一个不错的启发。
过来，咱们可能在小模型上进行了许多尝试，当初大语言模型在“文字模态”的数据下获得了如此好的停顿，这也为咱们在智能运维方向上应用多模态运维数据的根底模型提供了更多信念。
从架构的角度来看，咱们面临一个不可避免的问题：开源大模型层出不穷，那么应该抉择哪个模型、哪个底座呢？如果一个月后所选的已不再是最新、最强有力的，该怎么办？上图中显示的是 6 月 30 日排名靠前的模型，但当初曾经被大幅更新了。大模型疾速倒退给了咱们信念，以后的计算效率问题、能力问题以及模型规模问题都将逐步被 AI 开源社区解决。寰球最聪慧的 AI 专家们都被调动起来，独特朝着一个方向致力，所有问题都将逐个解决。包含公有部署的算力问题也将失去解决，可能不会那么快，但咱们应置信开源合作的力量。
同时，咱们都十分放心被某个模型或办法所解放。上图展现了大语言模型的根本框架，包含适配、部署、优化和监控，以及根底模型的编程框架。相似于 DevOps 的流水线一样，咱们尽量使每个局部都可替换和松耦合，这样在某个组件更新时能够间接替换。底座、微调办法、各种工具等都力求可替换，以便在工具演进过程中能更好地利用开源社区的最新成绩。
第三局部：运维大模型中长期利用
假以时日，运维大模型未来能有哪些利用呢？某些规模宏大的机构，如果领有短缺的语料和算力资源，实际上能够进行相似私域微调的工作。微软曾发表过相应的论文，基于其私有云上大量的工单数据，利用机器主动生成工单。通过评估，机器生成的工单与人工书写的工单十分靠近。阐明机器具备这样的能力，但这波及到语料的品质和数量方面的要求。例如，依据历史工单信息给出故障定位、故障止损倡议和类似故障提醒，提供与历史故障的相似性比拟以及过后的止损办法等，可能对咱们正在产生的故障止损提供重要的提醒和帮忙作用。
此外，还包含当大量的告警产生时，由机器为这些告警信息生成告警摘要。相似一大段文字由机器进行文字摘要一样，这里针对的是正在产生的故障产生的一堆告警信息，甚至是告警风暴，由机器产生告警摘要。总之，但凡波及文字相干的内容，都能够在这方面进行相干的利用尝试。当然并不一定每个机构都具备这样的语料和算力资源。
为已有的智能运维工具和自动化工具提供交互加强。交互加强指的是从文字角度的用意辨认和后果总结能力。举例来说，某款工具导入了所有的监控数据后能够进行各种危险告警、故障告警，从监控数据到主动建单，并给出根因剖析后果。如果在最外层退出基于大语言模型的输入输出的加强，这个工具的便捷性和受欢迎水平将大大晋升，前提是须要进行一些数据处理和接口标准化的工作。这是对单个运维工具进行晋升的办法。
在许多状况下，咱们须要将自然语言转化为模板（Lang2Template），这个模板可能是通过自然语言表达出来的对数据库的查问，而后主动生成相应的 SQL 语句。相似的，咱们也能够将自然语言转化为 Splunk 查问语句，因为像 Elasticsearch 和 Splunk 等工具都提供了用自然语言表白日志数据查问的性能，并且能够进行图形化展现。除此之外，咱们还能够应用自然语言表白图数据库的查问，并主动生成配置和脚本。这与自动化生成代码的过程类似，只是在运维畛域中，咱们常常应用脚本来主动调用各种 API。因而，利用自然语言表白的模块蕴含哪些服务的信息，咱们能够生成一个图数据库查问，相当于是一个拓扑的模块调用的关系存在图数据库里，而后用图数据库中进行主动生成的图形和 SQL。
如果当初要实现一个绝对简单的工作和场景，如出了一个故障，须要查问这个利用上面所有组件的所有的监控数据，而利用上面可能是上图中的一个拓扑图，有许多组件，每个组件下面既有日志数据，又有指标数据，还有其余数据。首先去图数据库里边生成一个 Graph SQL，把这个节点的数据拿进去，而后再拿这节点的信息去挖取不同的指标数据库、日志数据库，再去查对应的数据。能够设想一下其实就是用相似 LangChain 的工具，把方才这一系列操作串联起来。所有已有的运维的工具，接口定义分明，数据根底良好，就是一个无效的编排的工具，能够跟各种已有的运维工具进行交互，把后果应用更容易了解和承受的自然语言反馈给用户。这里答复下后面我提出的问题：运维大语言模型与 AIOps 的关系是什么？能够认为大语言模型是实现 AIOps 的必要和无效的一种伎俩，同时跟已有的工具能够对接能够互补的一个关系。
前我的次要的观点总结成这样的一幅架构图。
运维大模型是一个交融的模型，它涵盖如下几个局部：
首先，运维大语言模型（懂运维的大语言模型）是整个架构的外围根底。其次，在架构上辨别公域和私域的运维能力，公域的局部尽量做好，私域局部也尽量不依赖于那些品质、标准化水平、数量参差不齐的问题。
运维大语言模型：外面蕴含运维的常识图谱、混合的专家模型和开源的大语言模型的底座。底座局部尽量松耦合一些，借助流水线的工具，从而达到可替换可迭代、继续演进。
多模态根底模型群：运维数据是多模态的，目前的大语言模型的成果还有待改良，如果咱们想充分利用大模型的能力，能够在每一种模态的数据外面做根底模型，比方咱们在日志方面曾经做了基于 transformers 的架构，在指标方面基于 transformers 的架构做一些根底模型的尝试。
根底模型编程框架：基于编程框架可能把这些已有的工具和新的工具串联在一起，更好地实现运维场景的智能化。
对于运维大模型利用，运维专家常识的问答可能是最间接的一个利用，基于上述能力和工具，再外挂一些常识就能间接应用。不必对接实时的监控数据，也不必思考监控数据的品质问题，这是一个短期内能够落地的利用。咱们还能够基于绝对丰盛的私域语料做一些尝试、单个运维工具的交互加强也是能够尝试的，前提是咱们运维大语言模型进化到肯定水平，而后从自然语言到各种模板 API 的调用（Lang2Template），最终用根底的编程框架（LangChain/APIChain 等）对经典运维工具进行编排调用，实现更简单运维工作。
这是我目前对运维大模型的一些了解，谢谢大家。