导读本次分享的主题是“打造 LLMOps 时代的 Prompt 数据驱动引擎”。其中 LLMOps 想要表达的概念是 LLM for AIOps。AIOps 概念提出至少已有四年，从去年开始详情页外包，在学术界出现了 LLMOps 的趋势，大家都在想把 LLM 用于 AIOps 来做运维，但中间会遇到一些挑战。本文将重点探讨在 Prompt 数据方面，LLMOps 可能遇到的一些挑战，及其解决方案。

首先简要介绍一下华为文本机器翻译实验室。我们在学术界和业界都有分享和产品，感兴趣的朋友可以关注我们的公众号，那里有很多我们的研究成果以及发表的论文。

本次分享的主要内容包括以下几大部分：

1. 背景：从 AIOps 到 LLMOps 面临 prompt 挑战

2. 打造 LLMOps Prompt application 引擎

3. LLMOps 持续成长源动力：Prompt learning 数据飞轮

4. 未来畅想

分享嘉宾｜刘逸伦 华为文本机器翻译实验室 工程师

编辑整理｜王甲君

内容校对｜李瑶

出品社区｜DataFun

01

背景：从 AIOps 到 LLMOps 面临 prompt 挑战

从 AIOps 到 LLMOps，重点在于大模型强大的泛化能力和语言理解能力。和自然语言任务类似，AI 运维领域也有很多细分任务，基于大模型的泛化能力，我们预期可以用其统一处理这些零散的下游任务，建立一个多任务处理场景。这就是我们研究的初衷。

我们认为 LLMOps 有两个关键要素：Prompt application 和 Prompt learning。Prompt 是大语言模型在预训练过程中学到的知识，需要与人类的期望对齐，它是人类认知世界与模型数字世界的桥梁。

第一个关键要素是高质量的 Prompt，即 Prompt application，它帮助模型理解人类的目标，也就是说人类直接向模型提出命令或一条通向目标的推理路径。实际上，就是设计一个更有效的交互策略，使得模型生成的内容能符合人的意图和需求。

另外一个关键要素是 Prompt learning。Prompt learning 是指当前一些大模型会自动生成 Prompt 指令数据集，如 Self-instruct 策略，生成许多预制问题和答案对，称为 Prompt 训练集。这些训练集用人类的真实 Prompt 或合成 Prompt，让模型模拟人类可能遇到的问题，实质上是模型在学习人类的 Prompt，因此称为 Prompt learning。图中显示了更好的 Prompt 策略确实能提升模型性能，而训练阶段的低质量 Prompt 会降低效果。

本文将重点探讨这两个方向的问题，并分享我们的一些探索。

这两个方向分别有两大痛点：

在 Prompt application 方面，传统智能运维算法依赖于任务数据，专家标注耗时耗力；且可解释性差，可交互性弱。

在 Prompt learning 方面，Prompt 训练数据质量不稳定，导致模型性能下降；训练数据全面性不足，影响了模型能力。

接下来将分别介绍我们为解决这些问题所做的工作。

02

LogPrompt：打造 LLMOps Prompt application 引擎

首先来介绍 Prompt application。这里以 AIOps 三大支柱之一的日志分析为例，介绍如何打造 Prompt application 引擎。

软件系统产生的半结构化文本详情页外包，传统上需要运维工程师手动分析，但随着自动日志分析算法的出现，出现了很多细分任务，其中两个经典任务是日志解析和日志异常检测。日志解析涉及从原始日志中提取模板和变量，模板是日志词，变量是 IP 地址或序号等，传统方法将其转化为 1/0 组合。而日志异常检测则是输入日志，输出 1 或 0 表示是否异常。

修图美工

我们重点关注的是在线场景，由于软件更新频繁，新版本日志往往没有历史数据，模型缺乏适配的训练数据，这就要求模型能快速泛化以处理大量未知的新日志。在训练数据很少的情况下实现高效的日志分析，这是学术界的一大难题。

传统日志分析的两大痛点是依赖大量训练数据和缺乏可解释性。我们做了一些小实验，发现传统方法在训练数据占整个数据集 70-80% 时表现很好，但当训练数据减少到 10% 时，效果显著下降。这就是由于在线场景中大部分日志是新的，模型缺乏适配的训练数据，导致性能下滑。频繁重新训练模型成本高，因此需要新的解决方案。

另一个问题是现有方法缺乏可解释性。传统方法将日志处理成 1/0，输出也是 1/0，用户只能看到一个概率值。如今用户希望看到详细的解释，如为什么认为日志异常，或者生成简短报告来减轻运维工程师的负担。我们希望通过大模型和 Prompt 策略来解决这两个问题。

把大模型引入到日志分析的动力首先就是大模型具有强大的语言泛化能力，其指令微调过程使用少量指令训练数据，却能泛化到大量未知指令数据上。因此，我们认为 LLM 有能力处理大量未知的新日志。此外，像 ChatGPT 这样的模型擅长复杂的语言生成任务，因此我们认为 LLM 有潜力生成日志报告或解释异常状态。

然而，挑战在于大模型对 Prompt 非常敏感。我们前期实验发现，对于简单的 Prompt，如“请把以下日志分为正常或异常”，大模型的表现较差。用更好的 Prompt 策略后，性能提升了 70-80%。这是因为日志分析高度领域化，包含许多专有名词和 IP 地址等内容，自然语言模型可能缺乏领域知识输入。因此，需要探索更好的 Prompt 策略，以充分发挥大模型的潜力。当前 NLP 社区也提出了许多 Prompt 范式，如 CoT 和 ToT 等。我们希望将这些策略更好地应用于 LLMOps 相关领域。

我们一开始引入了 CoT 策略。CoT 的核心思想是模拟人的思考过程，不是直接输出答案，而是要求模型逐步思考（如“think step by step”），这对解决我们的两个主要问题很有帮助。①CoT 将未知问题分解为可处理的小步骤，解决了大量未见过的新日志的处理难题。②CoT 使模型输出更多的逻辑过程，不仅仅是一个答案，这为生成解释性报告提供了新的思路。通过 CoT prompt，模型的输出内容更加丰富，报告更加完整，逻辑也更清晰，同时释放了其预训练阶段的潜力。

我们探索了一个叫 LogPrompt 的方案，把 CoT prompt 的思想引入日志分析任务，出发点是模拟运维工程师的思考过程。人类工程师在判断日志异常或正常时，会根据系统手册和经验逐步分析，而不是直接得出结论。

基于这个原则，我们设计了两种方法：Implicit CoT 和 Explicit CoT。Implicit CoT 让模型解释每条结论的理由，生成隐式的思维链，类似于“think step by step”。Explicit CoT 则定义了解决问题的四个步骤，判断日志异常时，先检查文本内容中是否有明确的告警字样，然后再进行下一步；如果没有，则排除异常。我们用领域知识教模型如何判定异常，并将其浓缩在一个 Prompt 中。相比标准 Prompt，我们增加了一个 CoT 模块，隐式或显式地指导模型思考过程。

我们还探索了一些其他 Prompt application 策略，比如 Self-prompt，让大模型自己生成 Prompt。首先给它一个原始的 meta-prompt，完整描述任务，例如日志解析。任务是从日志中提取公共部分作为模板，其余部分作为变量。我们告诉大模型它现在是一个 Prompt 工程师，请它想出五个用于执行任务的 Prompt。然后，筛选出这五个 Prompt 中表现最好的一个，使用 100 条测试集进行测试，并分析其表现。

另一个策略是 In-context Prompt，这涉及在描述任务后，给出一些例子，例如十个例子，五个正例，五个负例，全都拼接在后面，希望模型根据这些例子构建任务的上下文。

还有一个策略是 Format Control，用于控制日志的输入和输出格式。格式控制可以减少随机性，避免解析失败。

我们进行了一系列实验，实验设置来自于 LogHub 数据集，其中包含了各种真实收集的日志数据，包括来自 HDFS、Hadoop、Zookeeper 的，软件、操作系统以及手机的日志。其中，BGL 和 Spirit 数据集都有专家标注的异常标签，其余数据集则有人工打的模板。在我们的主实验中，使用了 ChatGPT 的 API，这个实验是去年进行的，包括 temperature 等各项参数都进行了设置。对于训练集和测试集的划分，选择按照时间顺序进行划分，即选取时间上出现的前 10% 的数据作为训练集。

第一个实验显示，LogPrompt 在零样本日志分析场景中表现良好，减少了对训练数据的依赖。我们首先看左边，日志解析中的零样本场景是指算法没有任何训练输入，每个日志都是新的，没有历史日志。相比之下，传统算法需要训练数据。我们使用10% 的数据进行训练，外包美工模拟在线场景，因为以前的研究也有类似的做法。实验表明，在八个领域中，LogPrompt 在六个领域取得了最佳效果，平均来看也是最佳。

再看日志异常检测，与之前类似，baseline 算法使用前 4000 条日志进行训练，后续进行测试，而 LogPrompt 没有进行训练。结果显示 LogPrompt 再次取得了最佳结果。因此，LogPrompt 是在线日志分析的良好选择。这主要归功于 ChatGPT 的强大泛化能力和我们注入的领域知识。

接下来关注 LogPrompt 的可解释性。我们提出了一个新任务，称为 Log Interpretation。从之前提到的八个领域中随机筛选了 200 条日志，并请六位业界 AIOps 专家进行人工评测。输入为原始日志，输出要求 LogPrompt 进行解释，例如异常检测需说明原因，日志解析需解释日志内容。

我们制定了评分标准，分为两个维度：有用性（Usefulness）和可读性（Readability），评分从 1 到 5。有用性（Usefulness）指生成的解释是否详尽、具体、相关且逻辑正确，对实际运维是否有帮助。可读性（Readability）则关注生成内容是否易于理解。左下角展示了评分结果，包括平均分和高分率（评分 4 分及以上）。从平均分来看，六位专家的评分基本都在四分以上，高分率也很高，虽然个别评分有波动。

我们还收集了一些评分专家的反馈，他们普遍认为 LogPrompt 对 AIOps 有帮助。例如，有专家提到，当新设备插入网络时，日志可能不熟悉，通常需要查找说明书，但 LogPrompt 可以快速提供解释，比查官方定义快很多。还有专家表示，该工具能帮助快速生成异常报告，在需要召开会议时很有用。

另一个关键点是误报处理。系统报告异常时，不知道是否需要处理，如果 LogPrompt 能提供简短解释，可能有助于处理误报。我们也做了一些坏案例（Bad Case）分析，发现 ChatGPT 在特定领域的知识不足，例如对某些日志的特定术语和无语义信息的日志解释不够，这是后期需要优化的方向。

我们对三种 Prompt 策略进行了消融分析。第一个是 Self-prompt 和生成的五个 Prompt，测试结果显示 Prompt2 表现最好。我们发现，如果 Prompt 中包含更多的正式、精确的词，如"standards"和"convert"，LLM 的表现可能会变好。另一方面，对中间过程的描述更清晰也能帮助 LLM，例如 Prompt2 中的"identify the replace"。

第二个消融研究是关于 CoT prompt，包括简单 Prompt、implicit CoT（要求 LLM 解释理由）和按照我们规定的步骤解析。有趣的是，仅仅让 LLM 在给出答案时解释理由就能大幅提升表现。我们认为这是因为预训练阶段训练了大量逻辑丰富的语料，当要求 LLM 给出理由时，逻辑链会变得更清晰，这更符合预训练的范式。

第三个消融研究是关于 In-context Prompt，我们改变了输入上下文样本的数量。结果显示，过少或过多的上下文样本都会影响 LLM 的表现。过少的样本无法建立足够的上下文，而过多的样本可能会产生注意力噪声，导致 LLM 过度关注样本而忽略任务本身。

在探索 LogPrompt 之后的应用方向时，发现将这套方法应用到工业界仍存在挑战。当前的模型如 ChatGPT、Gemini 和 Cloud 等，都是基于 API 的，具有脆弱性，可能随时无法使用。因此，我们考虑开发可以部署的小型 LLM 用于 LLMOps。

我们进行了初步实验，使用了 Vicuna 13B 小模型，它可以直接部署。我们使用 Simple Prompt 和 LogPrompt 对日志异常和日常日志解析任务进行测试。尽管 Vicuna 只有 13B 的参数，但在 HDFS、Linux 和 ProxFire 等领域的表现已接近于 ChatGPT。我们认为，小模型有潜力完成这些任务，并且高级 LogPrompt 策略在小模型上也有效。然而，在许多领域的表现仍不理想，提升有限，离实际应用还有距离。Vicuna 等小模型缺乏日志或运维相关语料的训练，知识容量也较小，因此我们可能会对其进行知识注入和领域适应，来提升其性能。

03

LLMOps 持续成长源动力：CoachLM 打造 Prompt learning 数据飞轮

在讨论如何编写 Prompt 以便大模型更好地理解人类时，另一个关键点是数据飞轮。为了进行知识注入，我们需要大量训练数据，这就需要我们构建一个 Prompt Learning 的数据飞轮。

以下是我们部署的 Prompt Learning 数据飞轮的过程：①使用开源数据集如 Alpaca，并对其进行泛化，生成合成数据，然后优化质量（机器生成的数据质量可能不高）；②进行质量评测，包括人工编辑，得到高质量的子集；③对这些数据进行模型评价，再让模型生产新数据。

这个数据飞轮的核心是 Prompt 优化，通过自动优化模型 CoachLM 对训练数据进行优化。

我们目前在做的是通用的模型，可以应用于 AIOps 领域，但不仅限于 AIOps，目的是解决机生 Prompt 训练数据质量不稳定和模型性能下降的问题。以 Alpaca 开源数据集为例，它是通过 GPT 合成的，这样的数据可以用于 AIOps。但数据质量需要人工评估和优化，这非常耗时耗力。实验表明，人工优化确实有效，但效率极低。

为了解决这个问题，我们提出了一个自动优化数据的模型。这个模型不仅解决表面问题（如缺少输入），还处理深层次问题（如事实错误）。关键是避免低质量 Prompt 数据堆积，防止训练效果下降和 AI 能力受损。

业界的解决办法是对大模型生成的数据集进行小批量过滤，只有 10% 的数据用于训练。这导致大量数据被过滤，损害了全面性。例如，Alpagasus 模型的代码逻辑被过滤掉，缺失了数学推算能力。

本质上我们使用的是一种称为 Coach Instruction Tuning 的方法。目前，我们让语言专家标注了大约 2000 条数据，并经过了专家的人工优化。然后，我们使用大模型的指令微调技术，构造了这些修改范例，让模型学习专家的优化思路。最终，在真正训练之前，我们使用 CoachLM 模仿专家的修改思路对生成的合成数据进行优化。

上图中给出了一些例子，可以看到，原始数据较为简洁甚至是简陋的，经过 CoachLM 优化后，其逻辑链和思维链变得更为完整丰富，给出了许多思辨过程。

我们进行了一些实验，看到了数据质量的全面提升。左侧是原始的 Alpaca 数据集，右侧是我们优化过的 5 万条数据，使用 ChatGPT 对这些数据进行评分，结果显示优化后的数据质量普遍较高，得分 4.5 以上的数据占比从 17% 增长到了 78%。此外，我们还从六个维度对数据进行了人工评分，对其进行了全面的评估。

我们用这批数据训练了一个模型，并在开源的 benchmark 上进行了测试。结果显示，我们的 7B 模型取得了最佳成绩，超越了所有开源模型。我们还与更强的模型进行了对比，结果发现我们全面超过了 Vicuna-13B 模型，并在五项测试中取得了最佳成绩。

接下来，我们计划将工作扩展到多语言方向。目前大量开源模型主要用英语训练，对多语言支持不佳。我们的实验表明，Coach 的优化效果与基座关系密切，如果基座效果不好，Coach 的效果也会不好。因此，我们未来的方向是通过增量预训练或多语言指令微调，增强模型的多语言能力。

04

未来畅想

结尾部分是对未来的畅想。现在已经进入全模态时代，到 2026 年可能会由两大引擎推动全模态 LLMOps 的发展，即 Prompt application 对齐引擎和 Prompt learning 学习引擎。文本和图片模态将得到进一步支持，语音助手可以一键解决问题，甚至视频平台也可能纳入其中，为 LLMOps 提供全模态支撑。

以上就是本次分享的内容，谢谢大家。

特别声明：以上内容（如有图片或视频亦包括在内）来源于网络，不代表本网站立场。本网站仅提供信息存储服务。如因作品内容、版权和其他问题需要同我们联系的，请联系我们及时处理。联系方式：451255985@qq.com，进行删除。