微软探索使用LLM进行根因诊断和故障处理

内容整理自微软最近在ICSE 2023上发表的一篇文章《Recommending Root-Cause and Mitigation Steps for Cloud Incidents using Large Language Models》。

读这篇文章中，恰逢LLM在全球刮起一阵狂风，我自己也是主要做AIOPS相关内容，也一直在考虑如何使用AI的能力去解决故障定位、根因诊断、应急处理流程等问题。随着软件规模逐步扩大、软件复杂度逐步提升，能独立解决线上问题和快速解决线上问题等这些门槛会越来越高，感觉没有2 ～ 3年经验积累基本不可能具备相关的能力。这些场景几乎跟每个研发同学都相关，相关的处理应急手册等大都也是通过各种作战手册不断完善而成。LLM能否给我们解决这类问题提供一种新的可能性。

这里，按照我个人阅读文章的习惯将内容这里出来（可能会有些凌乱，且跳跃性比较强），这里也会补充一些我不了解的内容（之前是做图像和时序领域的工作，对NLP领域了解不多，也借着这个机会一并学习）。

先看看作者背景

• Toufique Ahmed，加利福尼亚大学戴维斯分校的学生，在微软实习期间的工作
• Thomas Zimmermann，来自微软研究院的高级首席研究员 www.microsoft.com/en-us/resea…
• Supriyo Chosh，一个印度的工程师，看了下最近2年才逐渐转换到故障诊断这个领域中，具体的研究工作可以看这里 www.microsoft.com/en-us/resea…
• Chetan Bansal，主要从事农业自主系统研发的工程师，跟很多IOT设备场景领域相关 www.microsoft.com/en-us/resea…

这个作者团队看起来，并没有特别专业的背景在做AIOPS的，作者背景也是五花八门哈。

再看摘要和结论

**文****章概述：**云服务的事故管理是一个复杂的过程，涉及多个步骤，对服务质量和开发人员的生产力都有巨大的影响。OCEs（值班工程师，on-call engineers）需要大量的领域知识和手动工作来确定和减轻生产事故的根本原因。最近人工智能的进步已经导致了最先进的大型语言模型，如GPT-3.x（包括GPT-3.0和GPT-3.5），这些模型已被用于解决从问题回答到文本摘要的各种问题。在这项工作中，微软进行了第一次大规模研究，评估这些模型在帮助工程师确定和减轻生产事故方面的有效性。在微软公司进行了严格的研究，涉及超过40,000个事故，并使用语义和词汇度量比较了zero-shot、fine-tune、mulit-task手段下的多个大型语言模型。最后，根据人类评估与实际事故所有者展示了使用人工智能解决云事故的有效性和未来潜力。

**核心结论：**通过这项工作，微软展示了GPT-3和GPT-3.5等最先进的大型语言模型在事故管理方面的有效性，特别是在识别根本原因和缓解步骤方面。为了比较模型的有效性，在微软公司进行了一项严格的大规模研究，涉及超过40,000个事故。为了评估这种方法的实际有用性，让实际的生产事故负责人参与其中。预计这篇论文是许多利用LLM使事故管理更加有效的研究之一。微软该团队的下一步是在生产环境中部署模型，帮助OCEs解决事故，还计划探索LLM的其他使用场景，例如事故摘要。

核心贡献一共三点：

• 这是第一项工作，展示了最先进的大型语言模型（LLM），如GPT-3.x（包括GPT-3.0和GPT-3.5），在实际生产环境中解决生产故障的实用性。

• 我们在微软对1000多个云服务的40,000多个故障事件进行了严格的大规模研究，使用了六种语义和词汇度量标准。（坦率的讲，这个工作量很大，也侧面的验证了结果的信任度还是挺高的）

• 模型微调（Fine-tuning）显著提高了LLMs在事件数据方面的有效性；

• 在实验中，GPT-3和GPT-3.5模型明显优于编码器-解码器模型；

• 像BLEU-4这样的度量标准对于衡量不同环境下模型的相对性能是有用的。然而，需要通过手动检查和与专家的验证来评估实际性能；

• 我们与实际生产故障的所有者进行的人类研究有助于证明所提出方法的有效性；

LLM在Incident领域的几个研究课题（Research Questions）

选择了几种OpenAI GPT-3.x模型（Curie、Codex-cushman、Davinci、Code-davinci-002）来生成云事件的根本原因和缓解计划

• RQ1- Are fine-tuned GPT-3.x models effective at finding the incident’s root cause?

• RQ2- Are fine-tuned GPT-3.x models capable of suggesting the mitigation plan for the incident?

• RQ3- How much fine-tuning improves over zero-shot learning performance of GPT-3.x models?

• RQ4-

  Does multi-task learning improve the performance of GPT-3.x models at finding root causes and mitigation plans?

• RQ5-

  Do GPT-3.x models get better at proposing mitigation plans if the root cause is given?

• RQ6-

  Do the models better propose mitigation plans for machine-detected incidents than human-detected ones?

作者的解决方法

整体流程

• 创建事件时，作者会指定事件的标题并描述任何相关细节，例如任何错误消息、异常行为和其他可能有助于解决问题的细节。
• 一旦OCE开始调查事件，他们可能会通过与事件作者沟通或查看可观测数据和日志来获取更多详细信息。在调查过程中，OCE通常会更新事件详情。
• 对于评估，作者使用事件创建时给定事件的标题和摘要作为输入，并生成根本原因和缓解步骤。这是为了确保我们只使用OCE在开始调查事件时可用的信息。

如何保证高质量的数据

数据质量的困境

• 为了管理这种规模的事件，Microsoft 有一个设计良好的网站来报告和管理事件。 数据库还跟踪网站的数据插入、修改和删除，从事件报告到缓解。
• 模型的输入之一是在事件报告或创建时编写的摘要，以防止从输入到输出的任何数据泄漏。
• 在大多数情况下，OCE 不遵循任何特定格式来编写事件摘要、根本原因和缓解计划。 在故障报告中会包含多种形式的信息：表格、指向先前事件的链接、监控指标或代码片段或是是截图。 当然这个很好理解，OCEs的核心工作不是记录这些现象，而是优先去解决这些问题。此外，一些事件是暂时的并且可以自动缓解。 如果严重程度低，则不进行详细的报告总结的撰写。

如何清洗故障报告

• 由于 GPT-3.x 是文本模型，作者丢弃了摘要中的表格和图像。 因此，我们有可能在丢弃该信息时丢失一些关键信息。
• 最初，我们从严重级别为 0-3 的“已解决”或“已缓解”事件中收集了 123,953 个根本原因实例和 23,544 个缓解措施（最严重的事件属于 0 级）。
• 收集数据后，我们观察到许多具有重复根本原因和缓解措施的事件。 一些严重的事件/拒绝服务会针对同一事件触发数百个事件报告，所有这些事件都有确切的根本原因和缓解措施。 为了公平地评估模型，我们删除了根本原因和缓解计划的完全重复项，最终得到 57,520 个根因和 8,300 个缓解计划。
• 平均根因和缓解措施长度分别为 87 和 12 个Token。 一些根本原因很长，模型和评估人员很难生成和评估模型的输出。 我们保留了多达 100 个标记的根因，使我们能够保留 73% 的根因实例。

模型构建

预训练模型目前正在为各种自然语言和代码任务实现最先进的性能。 这些预训练模型分两个阶段工作（即预训练和微调）。

在预训练阶段，我们训练模型以自我监督的方式从大规模语料库中学习语言（或代码）的统计数据。 之后，我们使用较小的标记数据集针对特定任务微调模型。 拥有足够的标记数据来训练这种高容量的深度学习模型几乎是不可行的。 预训练模型使我们能够在预训练阶段以自我监督的方式使用未标记数据训练如此大的模型。

Baselines encoder-decoder models

将编码器-解码器模型应用于根本原因和缓解措施。 编码器将对输入进行编码，解码器将使用编码器提供的编码表示生成根本原因或缓解措施。

• 选择 RoBERTa 和 CodeBERT

• 这两个模型在架构上与 125M 参数相同

• 这两种模型都被广泛用作基线（事实上，CodeBERT 是 CodeXGLUE [29] 数据集的主要基线模型，它是 10 个 SE 任务的流行基准，包括代码摘要和代码翻译等编码器-解码器任务）。

Roberta: A robustly optimized bert pretraining approach （2019）

• BERT 是第一个引入优于传统 Transformer 模型的预训练策略的模型。 它应用了两种预训练策略：Masked Language Modeling (MLM) 和 NSP (Next Sentence Prediction)。 在 MLM 预训练中，我们随机屏蔽掉 15% 的标记并要求模型恢复这些标记，而在 NSP 中，我们训练模型学习预测输入句子后的下一个句子。应用 RoBERTa 作为 NLP 基线模型。

Codebert: A pre-trained model for programming and natural languages （2020）

• CodeBERT 在架构上与 RoBERTa 模型相同，后者使用两个预训练目标：MLM （Masked Language Modeling） 和 RTD （Replaced Token Detection） 。 我们可以将 RTD 定义为二元分类问题，其中两个数据生成器（即 NL 和 PL）为一组随机屏蔽位置生成合理的备选方案。 训练鉴别器以确定一个词是否是原始词。 CodeBERT 在 CodeSerachNet (Codesearchnet challenge: Evaluating the state of semantic code search 2019) 数据集上进行了预训练。

OpenAI generative models

在生成式预训练中，自回归预测给定先前标记从左向右移动的标记的概率。 这种从左到右的自回归训练可防止模型从未来的标记中检索信息。 所有后续的生成模型（例如 GPT-2、GPT-3）都使用非常相似的预训练目标，但比以前的模型具有更高的容量，并且在更大的数据集上进行预训练。 像 GPT-3.x 这样的超大型语言模型 (LLM) 有 1750 亿个参数，并且被发现可以有效地使用少量学习来代替对一组特定任务进行微调的需要。 然而，微调 GPT-3.x 模型仍然对某些任务有益。 本文使用四种 OpenAI GPT-3.x 模型评估了我们的方法：Curie、Codex、Davinci 和 Code-davinci-002。

• Curie：Curie 是最快的 GPT-3 模型，参数为 6.7B。 该模型使用自然语言数据进行训练，在语言翻译、复杂分类、文本情感和摘要任务上表现良好。 这是我们用于实验的最小模型。
• Codex：Codex 模型也是为理解和生成代码而训练的 GPT-3 模型。 训练数据包含自然语言和来自 GitHub 的数十亿行公共代码。 我们使用一个模型，来自 Codex 家族的 Codex-cushman，具有 120 亿个参数。 尽管模型针对代码相关任务进行了预训练，但它在某种程度上与事件管理相关。 根本原因和缓解措施包含很多术语（例如，文件名、标识符），这些术语更多地与软件开发项目中使用的注释相关。
• Davinci：Davinci 是我们用于实验的最大 GPT-3 模型（1750 亿个参数）。 与其他 GPT-3 模型相比，它可以使用更少的指令执行任务。 Davinci 通常在理解内容或创意内容生成任务方面表现更好。 它也非常擅长解决逻辑问题。 然而，训练 1750 亿个参数模型的成本很高，需要更长的时间（与使用相同数据集的 Curie 相比几乎是四倍）和更多资源。 Davinci 未受过理解或生成代码的训练。
• Code-davinci-002：Code-davinci-002 是我们用于实验的 1750 亿参数 GPT-3.5 模型。 Code-davinci-002 是 Codex 模型的升级版，功能更强大，它是在更新的文本和代码语料库数据集上训练的。

评价指标

Lexical Metrics（词汇度量）

• BLEU-4（Bilingual Evaluation Understudy）一种用来评估机器翻译系统输出文本质量的指标，它基于n-gram匹配度量翻译质量。具体来说，BLEU-4使用四个不同的n-gram（1-gram、2-gram、3-gram、4-gram）进行比较，以评估机器翻译的精度。
• ROUGE-L（Recall Oriented Understudy for Gisting Evaluation）一种评估自动摘要系统输出文本质量的指标，它基于最长公共子序列（LCS）度量相似性。具体来说，ROUGE-L考虑了候选摘要和参考摘要之间的最长公共子序列，以及候选摘要中包含的词和参考摘要中包含的词的数目。
• METEOR（Metric for Evaluation of Translation with Explicit Ordering）一种评估机器翻译、文本摘要和信息检索等任务的指标，它综合了多种度量方法。具体来说，METEOR结合了单词重叠率、语义相似度和词序重排等因素，以评估系统输出文本的质量。

Semantic Metrics（语义度量）

• BERTScore一种评估机器翻译、文本摘要等任务的指标，它基于BERT模型对参考文本和生成文本的向量化表示进行比较。具体来说，BertScore使用余弦相似度度量参考文本和生成文本之间的相似度，并考虑单词的精确匹配和语义相似度。
• BLEURT Score一种评估机器翻译系统输出文本质量的指标，它通过比较生成文本和参考文本之间的相似度来评估翻译质量。BLEURT Score使用BERT模型进行特征提取，并使用线性回归模型将特征映射到评分空间。
• **NUBIA（Nubia： Neural based interchangeability assessor for text generation 2020）**一种用于评估文本生成质量的指标，它基于自然语言推理技术和BERT模型进行评估。具体来说，NUBIA使用BERT模型对生成文本和参考文本进行向量化表示，并使用自然语言推理来比较它们之间的相似性，以评估生成文本的质量。

本文的结论

针对RQ1的解答

Top1 和 Top5 的含义：针对OpenAI的生成模型，单次结果中可以获取多组根因，但是考虑到OCEs对于根因的判别需求，这里选择了Top5作为最终参与评判的数据。

令人惊讶的是，与 GPT-3 模型相比，编码器-解码器模型在所有六个自动指标中的表现都非常好。 事实上，所有六个指标都无法区分 OpenAI 模型之间的显着差异。

针对RQ2的解答

我们观察到与根本原因观察到的类似且一致的输出模式（表 III）。 编码器-解码器模型像以前一样生成通用评论（例如，“问题是自我缓解的”、“修复已部署到所有区域”），而这些建议对 OCE 来说大多无用。 对于 RQ1 和 RQ2，根据自动指标，经过微调的Davinci模型（即使有 1750 亿个参数）的性能明显低于其他基线方法。 然而，根据事件所有者的说法，Davinci 和 Code-davinci-002 模型是性能最好的模型

针对RQ3的解答

• 正如预期的那样，模型在这种情况下表现不佳，因为模型没有接受来自事件管理空间的机密数据的训练。
• 尽管 Davinci 模型在 RQ1 和 RQ2 中表现不佳，但它在根因和缓解方面的零样本设置下明显优于其他 OpenAI 模型。这是因为该模型具有更高的参数并且接受了更多数据的训练，使其能够在没有显式训练的情况下更好地推断。

针对RQ4的解答

• 总的来说，我们观察到多任务训练并没有明显优于单一任务的训练。
• 根因和缓解措施之间缺乏联系是导致性能下降的主要原因。 将知识从一项任务转移到另一项任务具有挑战性，因为它们的答案空间分布不同，例如根因和缓解长度和具体性的变化。

针对RQ5的解答

与 Top-1 结果的改进相比，Code-davinci-002 模型的 Top-5 推荐的性能提升并不大。 尽管如此，总体有希望的结果突出了根因信息在制定缓解计划中的重要性。

针对RQ6的解答

上表表明，在 Code-davinci-002 的 Top-1 建议的背景下，机器识别的事件可以优于人类检测到的事件，BLEU-4 为 9.5%，ROUGE-L 为 20%，METEOR 为 23% 模型。这是因为机器检测到的事件通常遵循某些模式，机器学习模型更容易识别这些模式。

看一组文中给出的利用GPT-3.x生成的例子:

个人的几个想法

• 作者通过Review大量的故障报告等内容，从中整理并搜集如何详细的供模型使用的数据集，并在后期可以跟事故的处理同学进行沟通确认，这个工作难能可贵，但是没有开源出相关的数据集这多少有点可惜；
• 作者在模型选择和评估指标处理上做了很多工作，在LLMs在故障诊断领域提供了很多实践工作，也为后人进入该领域提供很多参考
• 在建模过程中，并没有考虑很多指标类数据，更多的是考虑到故障排查过程中的文本信息，这多少优点后知后觉的意味，如果可以将故障前期的场景想办法作为一个多模态数据放到GPT中，这就往前迈了一大步了
• 在文中，缺少一个真实的、完整的案例说明，这多少优点让大家感觉不太过瘾

关注下相关工作

读一篇文章，其中很重要的也是通过Related Work来了解这个领域中相关的杰出的工作，这样能帮助我们快速的了解这个领域的目前的最好水平，以及相关的杰出的科研工作。因此我将这篇文章中的相关工作，整理到每个细节领域，并将作者提到的参考文献整理出来，方便大家去了解相关工作。

A. Incident Management

一个事件（Incident）的生命周期

• 检测（Detection）：事件生命周期的第一步是检测，即在服务的内部或外部客户注意到异常行为后，通过报告来发现事件。此外，事件也可以通过由服务所有者配置的自动监视器报告。
• 分类（Triaging）：一旦事件被报告，一组OCE将分析问题并将事件票据路由到适当的工程团队。这个过程通常被称为事件分级。
• 诊断（Diagnosis）：事件诊断和根本原因识别过程需要多次迭代的来回沟通，工程师们会检查不同方面以了解事件的广泛性质，并确定根本原因。
• 处理方案（Mitigation）：根据确定的根本原因，采取行动来缓解问题，以恢复服务的健康状态并最小化对服务用户的影响。

在这之前一些学者的处理工作如下：

• How incidental are the incidents? characterizing and prioritizing incidents for large-scale online service systems (2020)
• Continuous incident triage for large-scale online service systems (ASE 2019)
• How to mitigate the incident? an effective troubleshooting guide recommendation technique for online service systems (2020)
• Towards intelligent incident management: why we need it and how we make it (2020)

相关的工作主要从2个方向上展开：

• 第一个方向：已经有几项实证研究分析了生产系统中的事件和故障，这些研究着重于研究某种类型的问题引起的事件或特定服务和系统引起的问题

• Taxdc: A taxonomy of non-deterministic concurrency bugs in datacenter distributed systems (2016)

• An analysis of {Network-Partitioning} failures in cloud systems (OSDI 2018)

• An empirical study on crash recovery bugs in large-scale distributed systems (2018)

• Understanding and detecting software upgrade failures in distributed systems (SIGOPS 2021)

• How to fight produc- tion incidents? an empirical study on a large-scale cloud service (2022)

• What bugs cause production cloud incidents? (2019)

• Simple testing can prevent most critical failures: An analysis of production failures in distributed {Data-Intensive} systems (OSDI 2014)

• 第二个方向与微软这篇文章介绍的工作更相关，是使用机器学习和数据驱动技术自动化事件生命周期的各个方面，例如分派、诊断[58]-[60]和缓解[5]等。

• An empirical investigation of incident triage for online service systems (ICSE-SEIP 2019)

• Continuous incident triage for large-scale online service systems (ASE 2019)

• Picking pearl from seabed: Extracting artefacts from noisy issue triaging collaborative conversations for hybrid cloud services (AAAI 2022)

• Learning a hierarchical monitoring system for detecting and diagnosing service issues (SIGKDD 2015)

• Decaf: Diagnosing and triaging performance issues in large-scale cloud services (ICSE-SEIP 2020)

• Correlating events with time series for incident diagnosis (SIGKDD 2014)

• How to mitigate the incident? an effective troubleshooting guide recommendation technique for online service systems (2020)

与以往的研究不同，本研究是首次利用最先进的语言模型来协助运维工程师解决事件。我们希望这项工作也能促进未来的工作，将传统的任务特定的判别模型与LLMs合并，实现对生产事件的端到端自动化处理。

B. LLMs 擅长解决的任务（NLP中常见的任务）

任务

描述

任务

描述

Chunking

组块分析

Common Sense Reasoning

常识推理

Parsing

句法分析

Coreference resolution

指代消解

Dependency parsing

依存句法分析

Intent Detection

意图识别

Slot Filling

槽填充

Dialogue State Tracking

状态追踪

Domain adaptation

领域适配

Entity Linking

实体链接

Information Extraction

信息抽取

Crammatical Error Correction

语法错误纠正

Language Modeling

语言模型

Lexical Normalization

词汇规范化

Machine Translation

机器翻译

Multimodal Emotion Recognition

多模态情感识别

Multimodal Sentiment Analysis

多模态情感分析

Named entity recognition

命名实体识别

Natural language inference

自然语言推理

Part-of-speech tagging

词性标注

Question answering

问答

Word segmentation

分词

Word Sense Disambiguation

词义消除

Text classifcation

文本分类

Summarization

摘要

Sentiment analysis

情感分析

Semantic role labeling

语义角色标注

Semantic parsing

语义解析

Semantic textual similarity

语义文本相似度

Relationship Extraction

关系抽取

Relation Prediction

关系预测

C. LLMs in Software Engineering

虽然这是首次利用LLMs进行AIOps，但在软件工程领域，已有多项研究尝试使用LLMs解决其他具有挑战性的问题。

• Github Copilot使用GPT-3从自然语言输入中自动生成代码。一些研究人员已经解决了代码生成、文档字符串生成、代码修复等问题。

• Evaluating large language models trained on code. (2021)

• A systematic evaluation of large language models of code. (SIGPLAN 2022)

• Few-shot training llms for project-specific code-summarization. (2022)

• Improving automatically generated code from codex via automated program repair (2022)

• Repair is nearly generation: Multilingual program repair with llms (2022)

• Bareiß等人[64]展示了如何使用少量样本学习有效地完成代码变异、从自然语言文档中生成测试用例以及生成测试用例的任务。

• Code generation tools (almost) for free? a study of few-shot, pre-trained language models on code (2022)

• Jain等人提出了一种方法，利用基于程序分析和综合技术的后处理步骤来增强大型语言模型，并取得更好的性能。

• Jigsaw: Large language models meet program synthesis (2022)

然而，与代码生成不同的是，我们在使用最先进的LLMs时，探索的是事件解决问题，这既包含词汇和结构信息，也需要大量的训练数据，这是前所未有的。