面向 MLOps 从业者的 GenAIOps

本文提供针对具有现有 MLOps 投资并有兴趣扩展这些投资以在其工作负荷中包含生成式 AI 的工作负荷团队的指导。 为了使生成式 AI 工作负荷可操作，你需要使用 GenAIOps（有时狭义上称为 LLMOps）扩展你的 MLOps 投资。 本文概述传统机器学习和生成式 AI 工作负荷之间常见的技术模式，以及生成式 AI 的特定模式。 本文将帮助你了解在哪些方面能够应用现有操作化投资，以及在哪些方面需要扩展这些投资。

生成式 AI 技术模式

生成式 AI 工作负荷在以下方面不同于传统的机器学习工作负荷：

• 专注于生成式模型 - 传统的机器学习工作负荷侧重于训练新模型执行特定任务。 生成式 AI 工作负荷使用生成式模型，这些模型可用于解决各种各样的用例，并且在某些情况下是多模式模型。

• 专注于扩展模型 - 传统机器学习中的关键资产是已部署的模型。 向一个或多个工作负荷中的客户端代码提供对模型的访问权限，但工作负荷不是 MLOps 过程的一部分。 对于生成式 AI 解决方案，解决方案的关键方面是提供给生成模型的提示。 必须编写提示，并且可以包含来自一个或多个数据存储的数据。 协调逻辑、调用各种后端、生成提示和调用生成式模型的系统是你必须使用 GenAIOps 管理的生成式 AI 系统的一部分。

虽然某些生成式 AI 解决方案使用传统的机器学习做法，例如模型训练和优化，但它们都引入了应标准化的新模式。 本部分概述生成式 AI 解决方案的三大类技术模式：

• 预先训练和优化
• 提示工程
• 检索增强生成 (RAG)

训练和优化语言模型

目前，许多生成式 AI 解决方案使用现有的基础语言模型，这些模型在使用前不需要进行优化。 也就是说，有一些用例可以从优化基础模型或训练新的生成式 AI 模型（如小型语言模型 (SLM) 中获益。

训练新的 SLM 或优化生成式基础模型在逻辑上与训练传统机器学习模型的过程相同。 这些流程应使用现有的 MLOps 投资。

提示工程

提示工程包括生成提示所涉及的所有过程，该提示作为输入发送到生成式模型。 通常有一个业务流程协调程序来控制生成提示的工作流。 业务流程协调程序可以调用任意数量的数据存储来收集信息（如基础数据），并应用所需的逻辑来生成最有效的提示。 然后，业务流程协调程序将部署为由智能应用程序中的客户端代码访问的 API 终结点。

图 1. 提示工程体系结构

此类技术模式可以解决许多用例，包括：

• 分类
• 翻译
• 汇总
• 下一部分讨论的检索扩充生成

检索增强生成

检索扩充生成 (RAG) 是一种体系结构模式，它使用提示工程，其目标是使用特定于域的数据作为语言模型的基础数据。 语言模型根据一组特定数据进行训练。 工作负荷可能需要对特定于公司、客户或域的数据进行推理。 使用 RAG 解决方案时，会查询你的数据，并且结果会作为提示的一部分通常通过业务流程层提供给语言模型。

常见的 RAG 实现是将文档分解成区块，并将其与元数据一起存储在向量存储中。 矢量存储（如 Azure AI 搜索）允许你执行文本搜索和矢量相似性搜索以返回上下文相关的结果。 RAG 解决方案还可以使用其他数据存储返回基础数据。

图 2. 检索增强生成 (RAG) 体系结构

为生成式 AI 技术模式扩展 MLOps

在本部分中，我们将探讨生成式 AI 技术模式的内循环阶段和外循环阶段的以下关键方面，了解可以在哪里应用现有 MLOps 投资，以及需要在哪里扩展投资：

• 内部循环

  • DataOps
  • 试验
  • Evaluation

• 外部循环

  • 部署
  • 推理/监视
  • 反馈循环

DataOps

MLOps 和 GenAIOps 都使用 DataOps 的基础知识来创建可扩展和可重复的工作流，以确保正确清理、转换和格式化数据以用于实验和评估。 工作流可重现性和数据版本控制是 DataOps 的所有技术模式的重要功能，而数据的源、类型和意图依赖于模式。

训练和优化

此技术模式应充分利用作为 MLOps 实现的一部分所做的现有 DataOps 投资。 可重现性和数据版本控制允许你试用不同的特征工程数据、比较不同模型的性能和重现结果。

RAG 和提示工程

RAG 解决方案中数据的意图是提供作为提示的一部分提供给语言模型的基础数据。 RAG 解决方案通常需要将大型文档处理到适当大小的语义相关区块集合中，并将这些区块保存在向量存储中。 有关详细信息，请参阅设计和开发 RAG 解决方案。 利用 RAG 解决方案的可重现性和数据版本控制，你可以试用不同的分块和嵌入策略、比较性能，以及回滚到以前的版本。

用于对文档进行分块的数据管道不是传统 MLOps 中的 DataOps 的一部分，因此必须扩展体系结构和操作。 数据管道可以使用结构化和非结构化数据从多个不同的源中读取数据。 他们还可以将转换后的数据写入不同的目标。 你必须扩展体系结构，以包含用于基础数据的数据存储。 这些模式的常见数据存储是 Azure AI 搜索等矢量存储。 与训练和优化一样，你可以利用 Azure 机器学习管道或其他数据管道工具来协调分块的各个阶段。 你可以利用 Azure 机器学习管道中的提示流以一致且可重现的方式处理和扩充数据。 你还必须扩展操作，以保持数据存储中搜索索引的新鲜度和有效性。

试验

作为内部循环的一部分，试验是生成、评估（在下一部分介绍）和优化解决方案的迭代过程。 以下部分讨论常见生成式 AI 技术模式的试验。

训练和优化

优化现有语言模型或训练小型语言模型时，可以利用当前的 MLOps 投资。 例如，Azure 机器学习管道提供一个可靠的工具包，用于有效、高效地进行试验。 通过这些管道，你可以管理整个优化过程，从数据预处理到模型训练和评估。

RAG 和提示工程

使用提示工程和 RAG 工作负荷进行试验需要扩展 MLOps 投资。 对于这些技术模式，工作负荷不会以模型结束。 工作负荷需要一个业务流程协调程序，该系统知道如何运行逻辑、调用数据存储以获得所需信息（如基础数据、生成式提示、调用语言模型等）。 数据存储和存储中的索引也是工作负荷的一部分。 你的操作必须进行扩展以控制工作负荷的这些方面。

可以针对提示工程解决方案试验多个维度，包括不同的说明、角色、示例、约束和高级技术，例如提示链接。 试用 RAG 解决方案时，还有一些需要试用的其他区域，包括以下区域：

• 分块策略
• 应扩充哪些区块以及如何扩充
• 您的嵌入模型
• 搜索索引的配置
• 要执行的具体搜索（矢量、全文、混合等）

如 DataOps 中所述，试验的关键是可重现性和数据版本控制。 良好的试验框架允许存储输入，例如对超参数或提示的更改，以及评估试验时要使用的输出。

与现有的 MLOps 环境一样，你可以利用 Azure 机器学习管道等框架。 Azure 机器学习管道具有支持索引的功能，与 Azure AI 搜索等矢量存储集成。 GenAIOps 环境可以利用管道的这些功能，并将其与管理提示工程和自定义预处理逻辑的提示流功能相结合。

评估和实验

评估是生成、评估和优化解决方案的迭代试验过程中的关键环节。 对更改进行评估可为你提供必要的反馈，以便你进行改进或验证当前迭代是否满足要求。 以下各节讨论常见生成式 AI 技术模式试验阶段的评估。

训练和优化

对优化或训练的生成式 AI 模型的评估应该利用现有的 MLOps 投资。 例如，如果使用 Azure 机器学习管道来协调机器学习模型训练，则可以利用相同的评估功能来优化基础语言模型或训练新的小型语言模型。 这些功能包括利用评估模型组件来计算特定模型类型的行业标准评估指标，并跨模型比较结果。

RAG 和提示工程

你必须扩展现有的 MLOps 投资来评估生成式 AI 解决方案。 你可以利用提示流等工具来提供可靠的评估框架。 提示流使团队能够定义自定义评估逻辑，并指定条件和指标来评估各种提示变体 和语言模型 (LLM) 的性能。 这种结构化方法允许对不同配置（如超参数调整或体系结构变体）进行并行比较，以确定特定任务的最佳设置。

提示流中的作业会在试验过程中自动捕获输入和输出数据，从而创建全面的试用记录。 你可以通过分析此数据来获取见解并识别有望通知将来迭代的配置。 你可以通过使用提示流进行高效且系统化的试验来加快生成式 AI 解决方案的开发。

无论生成式 AI 解决方案的用例如何，试验过程都是相同的，例如分类、摘要、翻译，甚至是 RAG。 重要的区别是用于评估不同用例的指标。 下面是应对每个用例考虑的指标的一些示例：

• 翻译：BLEU
• 摘要：ROUGE。 BLEU、BERTScore、METEOR
• 分类：准确率、召回率、准确度、交叉熵
• RAG：基础性、相关性

一般来说，生成式 AI 解决方案将机器学习团队的职责从训练模型扩展到提示工程和管理基础数据。 由于提示工程和 RAG 试验和评估不一定需要数据科学家，因此使用软件工程师和数据工程师等其他角色执行这些功能很诱人。 当您忽略数据科学家对快速工程和 RAG 解决方案的尝试时，你将遇到挑战。 其他角色通常不会像许多数据科学家那样接受如何科学评估结果的训练。 阅读由七部分组成的文章系列：设计和开发 RAG 解决方案，以了解设计生成式 AI 解决方案的复杂性。

通过投资生成式 AI 解决方案，你可以减轻数据科学资源的一些压力。 软件工程师在这些解决方案中的作用日益重要。 例如，软件工程师是管理生成式 AI 解决方案中的业务流程责任的宝贵资源，并且他们擅长在提示流等工具中设置评估指标。 重要的是，这项工作必须在数据科学家的密切关注下完成。 数据科学家拥有训练和经验，了解如何正确评估实验。

部署

一些生成式 AI 解决方案涉及部署定制训练模型或优化现有模型，而其他解决方案则不涉及。 生成式 AI 解决方案增加了部署业务流程协调程序和任何数据存储的额外责任。 以下部分讨论常见生成式 AI 技术模式的部署。

训练和优化

部署生成式 AI 模型和优化基础模型应该使用现有的 MLOps 投资，并进行一些可能的调整。 例如，为了在 Azure OpenAI 中优化大型语言模型，你需要确保训练和验证数据集采用 JSONL 格式，并且你需要通过 REST API 上传数据。 你还需要创建优化作业。 部署经过训练的小型语言模型可以利用现有 MLOps 投资。

RAG 和提示工程

对于 RAG 和提示工程，还需要部署其他问题，包括业务流程逻辑、对数据存储（如索引或架构）的更改，以及对数据管道逻辑的更改。 业务流程逻辑通常封装在提示流、语义内核或 LangChain 等框架中。 你可以将业务流程协调程序部署到不同的计算资源，包括当前可能将自定义模型部署到的那些资源。 有关将提示流部署到 Azure 机器学习托管联机终结点或 Azure 应用程序服务的示例，请参阅基线 Azure OpenAI 端到端聊天参考体系结构。 为了部署到 Azure 应用服务，基础 Azure OpenAI 聊天架构将流及其依赖项打包为一个容器，这种做法可以提高不同环境之间的可移植性和一致性。

部署对数据库资源的更改（例如对数据模型或索引的更改）是需要在 GenAIOps 中处理的新职责。 使用大型语言模型时的一种常见做法是使用 LLM 前面的网关。

许多使用平台托管语言模型（如从 Azure OpenAI 提供的语言模型）的生成式 AI 体系结构包括 Azure API 管理等网关。 网关用例包括负载均衡、身份验证、监视等。 网关可以在部署新训练的或优化的模型方面发挥作用，从而逐步推出新模型。 使用网关以及模型版本控制，可以最大程度地减少部署更改时的风险，并在出现问题时回滚到以前的版本。

生成式 AI 特定问题（如业务流程协调程序）的部署应遵循适当的操作过程，例如：

• 严格的测试，包括单元测试
• 集成测试
• A/B 测试
• 端到端测试
• 推出诸如 Canary 或蓝/绿部署的策略

由于生成式 AI 应用程序的部署职责超出了模型部署的范围，因此可能需要其他作业角色来管理用户界面、业务流程协调程序和数据存储等项目的部署和监视。 这些角色通常与 DevOps 工程师技能组保持一致。

推理和监视

推理是将输入传递到已训练和部署的模型的过程，然后生成响应。 应从三个方面监视传统机器学习和生成式 AI 解决方案：操作监视、从生产学习和资源管理。

操作监视

操作监视涉及观察系统正在进行的操作，包括数据操作 (DataOps) 和模型训练。 你正在寻找偏差，包括错误、错误率更改以及处理时间的更改。

对于模型训练和优化，通常观察有关处理功能数据、模型训练和优化的数据操作过程。 这些内部循环问题的监视应使用现有的 MLOps 和 DataOps 投资。

对于生成式 AI 解决方案中的提示工程，你还有其他监视问题。 你必须监视处理基础数据或用于生成提示的其他数据的数据管道。 此处理可能包括数据存储操作，例如生成或重新生成索引。

从生产环境中学习

推理阶段监视的关键方面是从生产中学习的。 对传统机器学习模型的监视跟踪指标，例如准确性、精度和召回率。 一个关键目标是防范预测偏移。 使用生成模型进行预测的解决方案（例如使用 GPT 模型进行分类）应使用现有的 MLOps 监视投资。

使用生成模型来推理基于基础数据的解决方案使用基础性、完整性、利用率和相关性等指标。 目标是确保模型完全应答查询，并将响应基于其上下文。 在此，你要防范数据偏移之类的问题。 你希望确保提供模型的基础数据和提示与用户查询密切相关。

使用生成式模型执行非预测任务的解决方案（例如 RAG 解决方案）通常受益于人工反馈来评估最终用户的有用情绪。 用户界面可以获诸如赞成/反对之类的反馈，并且可以使用这些数据定期评估响应。

生成式 AI 解决方案的一种常见模式是在生成式模型前面部署。 网关的 一个用例是监视基础模型。 网关可用于记录输入提示和输出。

监视生成式解决方案的另一个关键领域是内容安全性。 目标是审查响应并检测有害或不良内容。 Azure AI 内容安全工作室是一个可用于审查内容的工具示例。

资源管理

对于使用公开为服务（例如 Azure OpenAI）的模型的生成解决方案，其资源管理问题与自己部署的模型不同。 你不关心基础结构，而是关注服务吞吐量、配额和限制。 Azure OpenAI 使用令牌的概念进行计费、限制和配额。 应监视配额使用情况，提高成本管理和性能效率。 Azure OpenAI 允许记录令牌使用情况。

工具

许多 MLOps 从业者对工具包进行了标准化，以围绕自动化、跟踪、部署、试验等组织各种活动，以抽象化这些流程的许多共同问题和实现细节。 常见的统一平台是 MLflow。 在查找支持 GenAIOps 模式的新工具之前，应查找现有的 MLOps 工具来评估其对生成式 AI 的支持。 例如，MLflow 支持语言模型的各种功能。

MLOps 和 GenAIOps 成熟度模型

作为当前 MLOps 投资的一部分，你可能已利用 MLOps 成熟度模型来评估机器学习运营和环境的成熟度。 扩展 MLOps 对生成式 AI 工作负载的投资时，应使用 GenAIOps 成熟度模型 来评估这些操作。 你可能很想尝试合并这两个成熟度模型，但我们建议单独衡量每个模型。 MLOps 和 GenAIOps 将相互独立发展。 例如，你可能在 MLOps 成熟度模型中处于第四级，但只是从生成式 AI 开始，可能只处于第一级。

总结

开始扩展 MLOps 投资以包括生成式 AI 时，请务必了解无需重新开始。 你可以利用现有的 MLOps 投资进行一些生成式 AI 技术模式。 优化生成式模型是一个很好的示例。 生成式 AI 解决方案（如提示工程和 RAG）有一些领域是全新的流程，你必须扩展现有运营投资并获得新技能。

作者

本文由 Microsoft 维护， 它最初是由以下贡献者撰写的。

• Paulo Lacerda | 云解决方案架构师 - Microsoft
• Marco Aurelio Cardoso | 高级软件工程师 - Microsoft
• Luiz Braz | 高级技术专家 - Microsoft
• Ritesh Modi | 首席软件工程师 - Microsoft

要查看非公开的 LinkedIn 个人资料，请登录到 LinkedIn。

下一步

相关资源

• 设计和开发 RAG 解决方案
• 基线 OpenAI 端到端聊天参考体系结构
• 机器学习操作