在大模型时代下，运维界普遍关注一些问题：大模型能带来哪些收益？面临哪些技术挑战？与以往的 AIOps小模型是什么关系？有了大模型之后，那么AIOps的整体框架是什么？近期、中期、长期有哪些应用？

这些都是大家关心的问题，我试图回答这些问题，搭建一个整体的认知框架，欢迎大家批评指正。

首先，从价值的角度，到了大模型时代AIOps工具可以说人话了，这是什么含义呢？运维环境架构复杂、规模巨大，包含了各种多模态数据，导致用户/决策者在早年人工运维时期处理起来比较困难。后来，有了AIOps工具，我们让这些工具具备了眼睛（能够采集监控数据）、手（能够自动化的运维）、大脑（智能运维）。但是众所周知，这里有个问题——就是这些工具的使用方法比较繁琐，得去工具上用它设计好的界面交流，它说的话决策者听不懂。

在大模型时代，已有的运维工具都可以被赋能，通过自然语言与人进行交流。在如上图所示的星战电影比喻中，通过大语言模型在决策者与智能运维工具之间进行翻译，经过几轮交流，决策者做出了决策。大语言模型让智能运维工具有了耳朵和嘴，能够与决策者进行交流了，或者说，可以“说人话”了。

在上面这个例子中，AIOps小模型工具被赋能之后，我们把它叫做工具智能体(Tool Agent)，它具备能够响应自然语言指令和要求进行工作的能力。而工具智能体的定义是：现有工具被大语言模型赋能，其功能上还是边界清晰的工具，可以接受API调用，也可以接受自然语言的指令，但是仍需明确指令，其推理和规划能力（如有）来自工具内置的AIOps与岗位型智能体。

另外一种智能体叫岗位型智能体 (Job Agent)。它利用知识、经验、规则、算法，具备一定的类似运维人员的观察、推理、规划、决策能力，与运维人员、其它岗位智能体以自然语言交互、与工具型智能体以自然语言或API交互。

工具型智能体是现有流程驱动、数据驱动的工具被大语言模型赋能后的升级；而岗位智能体是以人为本，是模拟一线运维、应用运维、网络运维、存储运维等等岗位工程师的智能体。

总而言之，个人的浅显之见认为：大语言模型将是AIOps落地取得突破的最重要的一块拼图；大模型时代的整体框架是多AIOps智能体的人机协同系统，三类实体（岗位型智能体、工具型智能体、运维人员）之间使用自然语言进行交互。

在这个框架下，自然语言作为运维人员、岗位智能体、工具智能体之间的通用接口，单聊、群聊窗口作为“服务总线”，将会连接、编排、融合小模型工具、结构化知识、人类经验和判断，人机协同完成运维任务。

当然以上框架落地还存在非常大的挑战。首先前提假设是大语言模型模型具体具备成为“总线”的能力。像Chat GPT这样的应用的确很厉害，但是它在运维领域到底怎么样？中科院计算机网络信息中心副研究员裴昶华老师上午的报告已经给出了回答，其实还是有差距的。

为了示意一下不懂运维的通识大语言模型可能会导致的鸡同鸭讲问题，我请Chat GPT编了一个对话的小剧本——运维人员与一个不懂运维的大模型翻译机器人的对话：

所以，整体来说通识大语言模型还是有不如人意的地方，我们需要一个客观的认识——大模型在运维这样的深领域知识行业还有很多挑战要克服（如下图所示），我们不能过于乐观：不能天马行空的想象很多应用，然后觉得它马上就能实现。

但是也不要过于悲观，前述的所有挑战都有技术思路可以解决（如下图所示）。

具体而言：

1）为了避免幻觉和增强可解释性强，可以通过检索增强（RAG）的方式，同时增大显式知识占比（思维链、思维树、思维图、知识图谱），并通过“有据可依”的生成策略提供原文引用；

2）严肃语料不足的问题可以通过由易到难的课程学习的方式进行训练；

3）针对“私有部署训练和部署开销都要低，私域数据的数量、质量不足”的问题，可以进行模型分层，在公域做预训练、微调、提示工程，训练一个“懂运维语言”的大语言模型，也就是一个L1层大语言模型；在私有部署时避免预训练、微调，而是通过检索方式融合本地知识库，以文档、提示作为便捷的知识工程手段；通过降低模型精度从而降低私有部署的推理开销。

4）在底座选型的时候，与开源大语言模型的底座尽量解耦。

5）对于结构化、多模态、实时数据的处理，可以有专门的多模态基础模型群、并构建对应的工具智能体。

6）对于存量的AIOps小模型工具、自动化运维工具，可以利用工具智能体的方式融入多智能体整体框架；

上文提到的运维领域所必需的L1层大语言模型是什么呢？整体上来说，其实就是一个懂运维语言的大语言模型。在松耦合的通识大语言模型底座上，基于公域的运维语料、知识库对其进行预训练、微调和提示工程。从而避免私有部署时的数据不足，数据质量也不足，用这种方式把各部分的长处短处都分清楚。打个比喻：L0层类比于一个大学本科生，L1层类比于一个运维专业研究生外加5年运维工龄，而L2层类比于一个10年运维工龄、5年司龄的运维工程师。

基于前述挑战和解决思路的难易程度，我提出如下应用落地建议：不求在现阶段全面开花，而是要小步快跑，以用促建，错误容忍度从高到低，循序渐进。从岗位助手、岗位培训教练、岗位顾问、岗位参谋最后变成内部专家，从提升效率逐渐到做决策。

举个例子，某监控数据采集厂家，他们就是在Chat GPT上传售后文档搭建了一个“售后工程师GPT助手”。售后专家工程师在钉钉群里跟客户进行交流时，把客户问题拿来交给“GPT助手”回答，然后对“GPT助手”的回答审核修改后再传给客户。如此一来，售后专家工程师的效率大幅提升。注意：这个应用就是“售后技术支持岗位助手”，是帮助售后技术专家提升效率，而不是替代专家做售后。

上图中根据不同发展阶段简单罗列了一些应用，整体而言就是根据错误容忍度从高到低以及技术挑战解决难度从易到难。

近期应用举例

（1）基于结构化知识检索的问答

企业里有很多存量的结构化知识，我们希望能够用自然语言的方式快速多轮问答，能够把清晰的排障路径用问答方式非常有效的回答出来。前置条件是有不低于60分的运维大语言模型OpsLLM，并支持检索增强(RAG) 。

（2）多文档问答

目前很多企业都拥有大量的存量文档，例如：运维文档、应急手册、产品手册、排障手册等，一般都是以PDF、word等方式保存，从某种意义上讲这些文档都是知识。

以售后技术支持文档为例，以前需要手动存储、查询、FAQ，现在可以把成百上千的技术文档上传至L2层（私有部署运维大语言模型），再利用L1层（运维大语言模型）的能力，根据文档中的内容和知识实现快速问答。当然这个过程也会存在技术挑战，例如文档的路由。

作为一个早期的应用，能够实现上面介绍的功能，是非常有意义的，因为回答的内容都是有据可依的，答案是基于上传文档中的某个章节或者某个段落，所谓的幻觉问题也在某种意义上解决了。

（3）数据注释

过去，很多监控数据都是一个个的字段，它不友好、不说人话。但是现在，可以通过运维大语言模型加上调用知识库，把这些冷冰冰的字段和多模态运维数据全都变成自然语言能够理解的内容，这是注释型岗位智能体。

近中期应用举例（具体近期还是中期，取决于具体工具本身的进度）

（1） 数据理解

工具智能体，例如日志工具、告警工具、安全日志工具、指标工具，能否对运维数据快速进行总结。比如5000条日志就发生在两分钟之内，能否快速总结出来具体的1-2件事情，当然这里边在运维领域的总结能力还是有不少工作要做。

（2）脚本解读

很多存量脚本（这不是一般意义上前后端开发的代码），SQL查询语句、日志查询、各种脚本配置等等，都有其物理意义，能否把这些已有的存量查询的脚本翻译成自然语言。大量的知识都是以隐性的方式存在其中，我们能否把它翻译成显示的知识？这对提升老员工培训新员工的效率会有很大提升。

（3）NL2Query（从自然语言到查询），为单个存量工具提供自然语言交互增强，提供意图识别、总结等能力，使其成为工具智能体。

这里包含大量的存量AIOps小模型工具、可观测性工具，还包括图数据库的查询，SQL查询（有些会把它描述成灵活BI），以及一些代码的生成。当然前提条件也要有一个还不错的运维大语言的模型，数据要标准化，工具接口要标准化。整体而言这个其实就是上文中提到的多Agent、人机交互的框架里面重要组成部分。把这个做好了，Agent之间就能够使用自然语言进行交流，就相当于接口，相当于把存量工具跟总线的接口打通。

中期应用举例

（1） 基于不同运维数据模态的基础模型(Foundation Model)的工具智能体

基于不同运维模态的基础模型开发工具智能体，甚至对于指标数据日志、Trace数据、告警数据等。

大家知道指标异常检测落地时有一个落地困境，就是算法本身的确是通用的，但是得具体到对某一家单位的指标在该单位现场训练一个针对该指标的模型。也就是一条数据一个模型。能否往前再进一步，利用Transformer技术、扩散模型Diffusion技术建立一个大模型，而不用看该指标的历史数据，直接零样本进行一场检测呢？当然这很有挑战，也并不容易，因此列为中期应用，但它也是实现上文描述的大模型框架里很重要的一部分。

在2023年12月16日的“2023 CCF 国际AIOps挑战赛暨‘大模型的AIOps’研讨会”上，我们有幸邀请到总共10篇高水平顶会论文的原作者在大模型应用、指标大模型、日志大模型方面进行分享。

（2）内部专家岗位智能体

内部专家岗位智能体更接近人的岗位角色，比如数据库运维、一线运维、应用运维、网络运维等。这类应用并不要求运维大语言模型一定要水平很高才能开始做，其实可以小步快跑，能力所及的做一些事情，就如前文例子中的“GPT助手”+专家审核的方式。随着L1层能力的不断提升，此类应用的能力上限也会随之显著提升。

中长期应用:多AIOps智能体人机协同，完成复杂运维任务

今天的圆桌主题里有一个问题是关于Killer App爆款应用的，同时综合今天上午的各种方案，还有我自己的一些想法，我认为“多AIOps智能体人机协同的对话聊天室”就是一个Killer App，非常实用、以人为本，而且能够不断的演进。

如下图所示，在运维作战指挥室中，运维人员聚在一起，各种不同角色或操作工具、或密切讨论。在这个Killer App中，每个岗位都有它的大模型数字孪生助手，能够帮它提升效率；各种监控工具、AIOps小模型工具都有其对应的工具型智能体，人、岗位智能体、工具智能体在对话聊天室里通过自然语言进行运维应急处置。这个应用在起步时，可以就是现有的ChatOps运维即时通讯聊天室，人的参与占比会较高，随着智能体能力的不断提升，其负责的任务占比越来越高，人的直接参与的程度会逐渐降低，更聚焦最关键的任务及决策。可以看出，这个应用的可演进性非常强。

比如说运维排障根因定位时，如果期望能够把所有知识都提前预制在工具里一下子做好很困难，但是按照上述框架，预知知识不足时，人可以实时通过自然语言提供专家知识，并与其它智能体互动协作完成任务。这是一个很好的例子：群聊聊天室作为自然语言接口“总线”。

下图是Chat GPT创作的一段模拟人机协同聊天室的内容：

考虑到应用、场景的多样性，L1层的训练难度，知识、语料、经验，专家分散在各个单位，因此，任何一家单位任何一个人任何一个组织都没法单独做成。所以在这里我们也正式发起建立一个开放的智能运维的联盟社区。如果说Hugging Face是AI领域的GitHub+榜单/推理平台，那我们社区就是AIOps领域的Hugging Face。

我们将会有训练语料、训练数据集、微调数据集、评测基准、在线评测系统。类似近几届的挑战赛的真实数据重放、真实故障存放、真实的运维工具采集出的实时监控数据以及在线评测系统。同时，还将有大小模型算法代码、运维大语言模型参数、指标/日志基础参数、智能体代码以及“模型 x 评测基准” 排行榜单。这个平台将从下一届挑战赛开始，成为AIOps挑战赛的主要运转平台。

同时，社区还将提供推理算力，云上推理平台实时运行，可以实际部署Demo模型同时消费平台数据。还可以为各用户单位提供API调用服务，如运维大语言模型的API调用、指标大模型调用，并且支持用户搭建GPTs（个性化运维大语言模型) 。

它是一个群体智慧的社区，成员将会贡献、审核语料、知识、对大模型进行反馈。成员在推理平台API调用的算力规模大了之后会有一些成本费用，如果产生了贡献，那就会有抵用消费券，这也是一种方式，我相信大家在其中受益可不止这些。

所以，这里郑重号召在座以及线上的各位专家、单位一起参与进来，群体智慧协同创新，把我们畅想的大模型在运维领域的应用的美好愿景变成现实。

1月12日（本周五）14:00 将进行 OpenAIOps 社区线上宣讲会，欢迎参与 ！（详情见文章后活动海报）

总结一下：大语言模型是AIOps落地取得突破的最重要的一块拼图，自然语言作为一个通用接口，能够把运维人员、岗位智能体、工具智能体都连接在一起，单聊窗口、群聊窗口作为服务总线，把运维领域所有的元素、工具、知识、人类的经验判断都能够实时的连接在一起，真正做到人机协同完成复杂的运维任务。

在这个过程中，我们把存量小模型工具赋能变成工具智能体，然后构建有着更复杂规划和行动能力的岗位智能体。这里有一个非常重要的前提，我们得构建一个L1层的运维大语言模型，要与L0层通识大语言模型底座解耦，在具体私有部署应用的时候，通过外挂的方式结合个性化的知识。

同时，我们发起一个开放的AIOps联盟社区，大家共享数据\模型、评测榜单、推理算力平台。有了这些，我相信在这样大势所趋的前提下，大模型在运维领域的应用前景非常可期。

我们通过群体智慧、协同创新，然后充分相信并且利用开源，在应用上小步快跑，以用促建，我们设想中的“大模型时代的AIOps多智能体的人机协同系统”一定能够实现！