清华裴丹 | 运维大模型展望-上篇

随着数字化和智能化技术的涌现与发展，数字生产力正逐渐成为推动经济发展和社会进步的重要引擎。人工智能场景落地效果的重大突破，尤其是以ChatGPT为代表的大语言模型的出现，彰显了AI技术能够在更多领域场景中普及，并将引发令人瞩目的行业变革。在运维行业中，大语言模型亦有广阔的应用空间，但如何将大语言模型和运维场景有效结合，以实现为运维工作创造价值仍然是一个行业普遍探索的问题。

本文内容来自清华大学计算机系长聘副教授裴丹在CCF国际AIOps挑战赛宣讲会暨AIOps研讨会，及其他运维领域前沿研讨会议上，关于《运维大模型展望》的演讲。

2023 CCF国际AIOps挑战赛火热报名中（AIOps挑战赛火热报名中，26万奖金池等你来瓜分！）

运维行业有其独特的特点。以某银行IT系统架构为例，如果将数据中心中的每个组件视为一个节点，并将它们连接成一个知识图谱，大约有400多万个节点和几千万条边，每个节点都有自己的监控数据，而且这些数据是多模态的。例如，最常见的可观测性数据是指标、日志、调用关系等数据，这些数据间的关系非常复杂，而且需要深厚的领域知识才能理解。作为运维人员，我们需要了解IT架构、数据中心运作方式以及软件工程的架构，才能做好运维工作。因此，领域知识对我们来说非常重要。同时，运维的场景也非常丰富，涉及到故障、质量、安全、效率和性能等多个方面。总之，运维领域是一个非常复杂的庞大场景，这是运维行业的特点。

关于运维大模型，我们先举个例子（上图）

运维大模型与我们过去使用的自动化运维、智能运维以及其他运维工具之间存在很强的互补关系。大模型出现之前，我们需要手动操作，并将新工具交付相应的用户，告诉他们如何使用。现在通过大模型，我们可以以对话形式操作。

如当告警发生，我们想查看它的根因并诊断时，我们可以如此操作：1、直接与大模型对话，提供一个告警ID，大模型调用出后台的根因诊断工具；2、诊断工具调用完成后给出一个结果，给出根因并提供一个链接，以解释这个结果是如何得出的。

实际上，该诊断工具的原理就是基于一个诊断图，根据该图推断出最有可能的几个原因。这个工具也有自己的展示界面。从这例子可以看出，通过最基本的人机对话功能，可以增强与现有任何一种工具（这个例子中是根因诊断工具）的输入输出交互。

以上这些是完全可以实现的，而大模型的应用不止于此。

在“运维大模型领域”，很可能会面临以下问题：

运维大模型的概念是什么？
与大语言模型的关系是什么？
是不是“通用大语言模型+提示/外挂文档”就足够了？
与AIOps、自动化运维工具的关系是什么，如何融合对接？
面对百花齐放、日新月异的开源大语言模型，如何选取大语言模型底座、模型规模、微调方法？
短期内有哪些可以快速落地的应用？
中长期内有哪些应用？运维大模型的能力边界是什么？

同时，大模型在运维领域应用也将面临以下技术挑战：

如何满足私有部署成本、可演进要求？
如何解决训练私有语料不足的问题？
作为严肃应用，如何做到杜绝幻觉、可解释、安全性高？
如何处理通用大模型无法处置的私域、实时数据？
如何处理通用大语言模型无法直接处理的运维多模态数据？
如何融入运维领域的现有强领域知识，特别是针对多模态数据，多个细分领域的不同专家知识？

这些都是大家可能感兴趣的问题，我其实也并没有最终答案，但我确实有一些自己的看法。回答上述这些问题的时候，我引用一下21年在我们举办的AIOps挑战赛上做的一次分享，AIOps落地五大原则，15条细分原则，这对于大模型也同样适用。如：

知己知彼：知道运维有什么特点、大模型进展到什么程度。

触类旁通：我经常会拿一些医学方面的例子来做举例。当前医学领域的大语言模型也突飞猛进，最近某公司做了一个线下实验，请了一些领域专家评判由AI对真实病人问诊，并与初级医生进行的真实问诊进行对比，二者效果的一致性约是96%。医学大模型的架构是怎样的？如何解决“幻觉问题”？诊断的过程有哪些值得我们借鉴？在另外一篇文章中提到了上海的人工智能研究中心和医学研究中心的例子，它们的架构目标是建立一个中文的医学大语言模型，以便理解医学术语和关键词。他们针对医学的多模态数据（如影像数据和其他数据）分别建立了单独的基础模型。同时如核磁共振和CT扫描虽然都是图像数据，但具有不同特点，需要分别建立影像模型。类似地，每个器官都有自己的基础模型（例如大脑和肺部）。这种类比推广的方法在我们所研究的运维领域中也同样适用。

具体详见文章：AIOps落地五大原则

我后面的分享包含三个章节：

第一章节，运维大语言模型及应用，需要整个社区一起训练一个运维的大语言模型，后面详细展开说明原因。

第二章节，运维大模型的整体架构。

第三章节，运维大模型的中长期有哪些应用？

第一章节：运维大语言模型及应用

在运维这一严肃领域，我们需要训练一个“懂运维”的大型语言模型，而不仅仅是一个通用的大语言模型。它能够真正理解输入的文档和上下文，而不仅仅是大致回答问题。打个比方，开源的大语言模型可以看作是训练出的相当不错的本科生，他们博闻强记，具有很多知识。但如果这个本科生直接从学校来到运维工作岗位，面对具体运维工作，他可能无法理解其中的内容，甚至不了解相关术语，将无所适从。因此，我们需要使用大量与运维相关的语料对模型进行训练、微调和提示工程，以使其能更好地理解运维上下文。只有这样，它才能真正应用于严肃的运维场景。前面提到的中文的医疗大语言模型也是类似的逻辑。

业内专家在“预训练”这个问题上存在一些争议，认为进行预训练非常昂贵，并质疑是否有必要。

我们认为这是必要的，否则运维专家是无法通过普通训练获得。此外，在私有部署阶段，比如在传统行业（如银行和电网），可以基于预训练模型进行提示工程和知识扩展。就像具有多年经验的大厂运维专家，如果他们去一个中型互联网公司，只需要提供一些特定领域的背景知识（像外挂一样），他们之前的运维经验就足以应对那里的个性化情况。但如果期望一个本科生直接适应这样的中型互联网公司，无论给他多少语料，他自己是无法自学出来的，这个成长的过程是需要时间慢慢积累来的。因此，大规模的训练应该在公共领域中进行，培养出数字化的“运维专家”，而不是分散在各个特定领域中进行。

这是我个人的一个核心观点，只是基于个人直觉的判断，尚未得到验证。我的这一观点是基于严肃运维应用的如下硬性需求：我们在应用中需要避免幻觉，注重强的可解释性，并降低部署开销，同时不受私域数据质量问题的限制。那么，以此为出发点的运维大语言模型的形态是怎样的？

首先，要基于一个开源的大模型底座（无论是国内的百川、GLM，还是国外的LLaMA）。其次，我认为目前已经出现的技术中，知识图谱对于杜绝幻觉问题和增强可解释性是有帮助的。同时，知识图谱的构建是一个复杂的过程，不能指望专家对运维的各个子领域都非常熟悉。因此，我们需要使用混合专家模型和多模态的运维知识图谱来构建一个新的大型语言模型，即运维大语言模型（OpsLLM）。当具体应用到某个场景时，可以以外挂的形式，类似于大家使用过的文档外挂（如：DOCGPT），就像一个经验丰富的运维专家一样，到了一个新的单位，简单了解一下情况，基本上就能处理各种运维问题了。

举个例子，假设我们已经总结了一个诊断图（如上图所示），用于分析交易响应时间长的问题。这个应用程序调用了另一个交易，并依赖于一个中间件WebLogic，而WebLogic又与Oracle数据库进行交互。在这个过程中，可能会出现存储异常导致告警产生。无论这些信息以何种形式存储，只要大语言模型能够理解其中的术语，有效地识别和理解运维人员的意图，并能够以运维领域的术语与用户进行对话，它就能够有效地进行交流。

具体而言，在这个例子中如果出现交易响应时间长的问题，可能会问到：现在出现这个问题的可能原因是什么？这与之前提到的诊断图中的问题类似，我们需要确定是否是web出现了问题，然后逐步解决问题，最终给出处置建议。大语言模型确实有一个“思维更全面”的优点，就像我之前提到的医学实验一样（在实验中发现MedGPT在应用中可能会稍微啰嗦一些，会东问一下西问一下，但是它的思考更加全面。相比一般的医生，在一些相对不常见的情况下，更能发挥一定的作用）。但是需要注意的是，这个过程必须是严肃应用，杜绝幻觉，大语言模型不能自行发明一些答案。

这个大语言模型在具备了运维领域的知识的前提下，又外挂了一个诊断知识资源，因此能够有效地对这些知识进行问答。

如果进行私有部署，可以参照上述模型演示。虽然很多知识是公开的，但如果这是一个私有文档（如：MySQL文档），加载进去后可以针对MySQL的知识进行查询，比如查询SQL类故障等。这种个性化的部署设计允许我们共同训练模型，以更好地理解特定的个性化文档，从而在享受运维专家知识的同时解决个性化的知识图谱和运维文档的问题。此外，还可以通过提示工程来进一步优化模型的性能。

从提升模型的可解释性、问答的可解释性和杜绝幻觉的角度来看，结合知识图谱和大语言模型可能是一个不错的方向。最近有一篇综述论文提到了如何将知识图谱和大语言模型结合起来以达到更好的效果。该文章总结了300-500篇论文，并绘制了一个脑图，每个节点代表10-20篇论文，概括了大致的研究方向。

总结起来，知识图谱是一种结构化的显性知识，具有准确性、决断性和强可解释性，但不完整且无法处理自然语言。大语言模型则具有通用的隐性知识处理能力，但可能产生幻觉并且是黑盒的。

结合知识图谱和大语言模型的优点可以通过以下三个主要方向实现：

利用知识图谱增强大语言模型：将结构化的显性知识图谱与大语言模型结合，以提供更准确、可解释的结果。知识图谱可以用作先验知识，指导大语言模型生成更准确的答案或推理结果。

利用大语言模型扩充知识图谱：大语言模型可以处理自然语言并从大规模文本中学习隐性知识。通过使用大语言模型，可以自动从文本中抽取新的知识并将其添加到知识图谱中，从而增加知识图谱的完整性和涵盖范围。

融合知识图谱和大语言模型进行联合建模：将知识图谱和大语言模型进行融合，以建立一个综合的模型。这种联合建模可以在知识图谱的基础上利用大语言模型的语言理解和生成能力，同时通过知识图谱提供的结构化知识进行指导和解释，以提高模型的性能和可解释性。

通过这些方向的结合，可以充分发挥知识图谱和大语言模型的优势，实现更好的效果和应用。

KG（知识图谱）增强LLM（大语言模型）-预训练阶段。首先，大语言模型训练时，可以把知识图谱里边的内容转换成文字。其次，把知识图谱的内容变成新的语料（当然是把握性比较强的语料），把它放进训练的里面。第三，还可以引入一些额外的单独设计的模块，作为该神经网络的架构模型都是可以的。

KG（知识图谱）增强LLM（大语言模型）-推理阶段，同样可以利用知识图谱进行推理。在推理过程中，可以根据当前问题利用知识图谱进行相关的工作，以得出结论。此外，还可以使用基于检索的方法。当问题出现时，可以在知识图谱中查找相应的答案辅助得出更准确、更可靠的答案，并避免产生幻觉。在推理阶段，结合知识图谱的这些方法可以提高推理的准确性和可靠性。

KG（知识图谱）增强LLM（大语言模型）-模拟可解释性。从可解释性的角度来看，可以先由大语言模型给出一个结果，然后再用知识图谱来验证该结果的可靠性。这种方法比较直观，通过将结果与知识图谱进行对比，我们可以确定该结果是否可靠。

此外，从可解释性的角度来看，我们可以将大语言模型得出的结果与知识图谱进行比对，看是否存在一条路径可以走通。这类似于过去使用深度学习得到结果后，与决策树比较一下，从而总结出规则的做法。我们可以通过这种方法来评估模型的效果，并得出大致的规则。

LLM（大语言模型）增强KG（知识图谱）-KG补全。我们还可以反过来利用大语言模型进行知识图谱的补全和扩充。因为它可以处理大量的语料数据，而传统知识图谱中的很多信息也是从语料中提取出来的，通过大语言模型，我们可以更好地进行知识图谱的补全和扩充，进一步完善知识图谱的知识工程构建工作。大语言模型可以通过对知识图谱进行相应的补充和扩展，使其更加完整和准确。这样的应用可以提升知识图谱的质量和可用性。

LLM（大语言模型）增强KG（知识图谱）-KG转文本。我们可以通过将知识图谱中的信息转换为自然语言文本，使其可读性更强，便于阅读和理解。这样的转换可以提升知识图谱的可用性，更加易于应用和传播。

LLM（大语言模型）增强KG（知识图谱）-KG知识问答。如：用完形填空的方式写一个问题，把对应的大语言的模型调用一下，把文字处理一下，最后构建出知识图谱。

LLM（大语言模型）增强KG（知识图谱）-KG构造。假设我们有一段文字，我们可以利用大语言模型来分析其主谓宾结构。之后将这些提取出的主谓宾信息转化为知识图谱中的点和边。通过将这些信息补充到知识图谱中，我们可以丰富图谱的内容，并更好地组织和展示知识。

举一个运维领域的例子，如我们需要认真记录故障工单以进行复盘。在故障工单中，我们需要指出故障发生时的症状、采取了哪些处理措施、诊断出来的故障是什么、整改方案是什么等一系列信息。通常，这些信息以文字形式记录，很难转化为故障的传播关系。

如果交给大语言模型，它可以分析并识别出因果关系，并将其补充到我们的知识图谱中。需要强调的是，这是人机协同的过程。大语言模型可以提取出许多信息和想法，但不一定完全准确。最终，我们还是需要依靠运维专家来进行审核和确认，只有在专家认为可靠的情况下，才将其纳入知识图谱。这就是大语言模型在构建运维知识图谱方面所能发挥的作用。

在运维领域，不同专家可能具备不同领域的知识，例如网络、数据库、存储等。在实际应用中，常常会采用混合专家模型将各个领域的知识图谱进行组合。如没有确定的技术，可通过一种示意图来表示。如：当业务出现问题时，可以按照一定的顺序查看网络、中间件、数据库、存储等，每个领域对应一个子图，最终将这些子图拼接在一起形成一个整体的图谱。这样的混合模型可以帮助我们理解运维领域的知识，并充分利用通用人工智能（如大语言模型）在运维领域的能力。因为只有理解运维领域的知识，并能够有效地利用这些能力，我们才能够在运维工作中取得良好的效果。