你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
本文将为已投资机器学习运营 (MLOps) 并希望扩大这些投资以在其工作负荷中包括生成式 AI 技术和模式的工作负荷团队提供指导。 要使生成式 AI 工作负载特性真正发挥作用，您需要通过生成式 AI 操作（GenAIOps）来扩展您的 MLOps 投资，有时称为 LLMOps。 本文概述了传统机器学习和生成 AI 工作负载通用的技术模式，以及生成式 AI 特有的模式。 了解在哪里可以应用现有的运营化投资，以及在哪里需要拓展这些投资。
MLOps 和 GenAIOps 的规划和实施是 Azure 上 AI 工作负荷的核心设计领域的一部分。 有关这些工作负载为何需要专用操作的详细信息，请参阅 有关 Azure 上 AI 工作负载的 MLOps 和 GenAIOps。
生成式 AI 技术模式
生成式 AI 工作负载与传统的机器学习工作负载有几种不同之处：
专注于生成式模型。 传统的机器学习工作负载侧重于针对特定任务训练新模型。 生成式 AI 工作负载会使用并有时微调生成模型，以解决更广泛的用例。 其中一些模型是多模式的。
专注于扩展模型。 传统机器学习中的关键资产是训练和部署的模型。 向一个或多个工作负荷中的客户端代码提供对模型的访问权限，但工作负荷通常不是 MLOps 过程的一部分。 使用生成 AI 解决方案时，解决方案的一个关键方面是提供给生成模型的提示。 提示必须由指令组成，并且通常包含来自一个或多个数据存储的上下文数据。 协调逻辑、对各种后端或代理的调用、生成提示和对生成模型的调用的系统是使用 GenAIOps 治理的生成 AI 系统的一部分。
某些生成 AI 解决方案使用传统的机器学习做法，例如模型训练和微调。 但是，这些解决方案引入了应标准化的新模式。 生成式人工智能解决方案的技术模式大致可分为三类：
- Fine-tuning
- 提示
- 检索增强生成 (RAG)
微调语言模型
许多生成式 AI 解决方案使用现有的基础语言模型，这些模型在使用前不需要进行优化。 但是，某些用例可以从微调基础模型中受益，该模型可以是小型语言模型或大型语言模型。
微调基础模型遵循类似于训练传统机器学习模型的过程（如数据准备、模型训练、评估和部署）的逻辑过程。 这些流程应使用现有的 MLOps 投资来确保可伸缩性、可重现性和治理性。
提示
提示是制作语言模型的有效输入的艺术和科学。 这些输入通常分为两个类别。 系统提示定义模型角色、语气或行为。 用户提示表示用户与语言模型的交互。
业务流程协调程序通常管理生成这些提示的工作流。 它可以直接从或通过代理检索来自各种源的地面数据，并应用逻辑来构造最有效的提示。 此业务流程协调程序通常部署为 API 终结点，使客户端应用程序能够将其作为智能系统的一部分进行访问。
下图显示了用于提示工程的体系结构。
此类技术模式可以解决许多用例：
- 分类
- 翻译
- 综述
- 抹布
抹布
RAG 是一种体系结构模式，通过将特定于域的数据合并到提示中来增强语言模型。 此基础数据使模型能够根据特定于公司、客户或域的信息进行推理。 在 RAG 解决方案中，业务流程层会查询数据源，并将最相关的结果注入到提示中。 然后，业务流程协调程序会将此扩充的提示发送到语言模型，通常通过 API 终结点公开，以便在智能应用程序中使用。
典型的 RAG 实现是将源数据分解成区块，并将其与元数据一起存储在向量存储中。 矢量存储（如 Azure AI 搜索）允许你执行文本搜索和矢量相似性搜索以返回上下文相关的结果。 RAG 解决方案还可以使用其他数据存储返回基础数据。
下图演示了包含文档数据的 RAG 体系结构。
显示 RAG 体系结构的 
扩展 MLOps 以支持生成式 AI 的技术模式
你的 MLOps 流程可同时解决内循环和外循环流程问题。 生成式 AI 技术模式还具有许多相同的活动。 在某些情况下，可以应用现有的 MLOps 投资。 在其他情况下，需要扩展它们：
DataOps 公司
MLOps 和 GenAIOps 都应用了数据作（DataOps）的基础知识，以创建可扩展且可重现的工作流。 这些工作流可确保正确清理、转换和格式化数据，以便进行试验和评估。 工作流可重复性和数据版本控制是所有技术模式的 DataOps 的重要特性。 数据的源、类型和意向取决于模式。
训练和优化
此技术模式应充分利用您在 MLOps 实施中的现有 DataOps 投资。 可重现性和数据版本控制允许你试用不同的特征工程数据、比较不同模型的性能和重现结果。
RAG 和提示工程
RAG 解决方案中数据的意图是提供作为提示的一部分提供给语言模型的基础数据（或上下文）。 RAG 解决方案通常需要将大型文档或数据集处理到适当大小的语义相关区块集合中，并将这些区块保存在向量存储中。 有关详细信息，请参阅 设计和开发 RAG 解决方案。 利用 RAG 解决方案的可重现性和数据版本控制，你可以试用不同的分块和嵌入策略、比较性能，以及回滚到以前的版本。
用于对文档进行分块的数据管道不是传统 MLOps 中的 DataOps 的一部分，因此必须扩展体系结构和操作。 数据管道可以从包括结构化和非结构化数据的不同源中读取数据。 他们还可以将转换后的数据写入不同的目标。 你必须扩展管道，以包含用于基础数据的数据存储。 这些模式的典型数据存储是 AI 搜索等矢量存储。
与训练和微调一样，Azure 机器学习管道或其他数据管道工具可用于协调分块的阶段。
搜索索引维护
你还必须扩展操作，以保持数据存储中搜索索引的新鲜度和有效性。 如果无法以增量方式添加、删除或更新数据，则可能需要定期重新生成这些索引。 索引更新必须满足数据新鲜度的业务要求、非功能性要求（例如性能和可用性）以及合规性要求（例如忘记权限请求）。 你需要扩展现有的 MLOps 过程，以考虑维护和更新搜索索引，以确保准确性、合规性和最佳性能。
实验
试验是内部循环的一部分，是创建、评估和优化解决方案的迭代过程。 以下部分介绍典型生成 AI 技术模式的试验。
训练和优化
在微调现有语言模型或训练小型语言模型时，可以充分利用您当前的 MLOps 投资。 例如，机器学习管道提供了一个工具包，用于高效高效地进行试验。 通过这些管道，你可以管理整个优化过程，从数据预处理到模型训练和评估。
RAG 和提示工程
使用提示工程和 RAG 工作负荷进行试验需要扩展 MLOps 投资。 对于这些技术模式，工作负荷不会以模型结束。 工作负荷需要业务流程协调程序，该系统可以运行逻辑、调用数据存储或代理以获取所需的信息，如地面数据、生成提示和调用语言模型。 数据存储和存储中的索引也是工作负荷的一部分。 你需要扩展操作，以控制工作负荷的这些方面。
可以在多个维度上进行试验，以适应不同的提示，包括不同的系统说明、角色、示例、约束和高级技术，如提示链。 在试验 RAG 解决方案时，还可以尝试其他领域：
- 分块策略
- 用于扩充区块的方法
- 嵌入模型选择
- 搜索索引的配置
- 要执行的搜索类型，例如矢量、全文和混合
如 DataOps 中所述，可重现性和数据版本控制是试验的关键。 良好的试验框架允许存储输入，例如对超参数或提示的更改，以及评估试验时要使用的输出。
就像在现有的 MLOps 环境中一样，可以利用机器学习管道等框架。 机器学习管道具有通过与 AI 搜索等矢量存储集成来支持索引的功能。 GenAIOps 环境可以利用这些管道功能。
评估和实验
评估是生成、评估和优化解决方案的迭代试验过程中的关键环节。 对更改的评估提供您所需要的反馈，以便您可以优化或验证当前迭代是否符合要求。 以下部分介绍典型生成 AI 技术模式试验阶段的评估。
Fine-tuning
若要评估优化或训练的生成 AI 模型，请利用现有的 MLOps 投资。 例如，如果使用机器学习管道来协调机器学习模型训练，则可以使用相同的评估功能微调基础语言模型或训练新的小型语言模型。 这些功能包括使用评估模型组件来计算特定模型类型的行业标准评估指标，并跨模型比较结果。 如果工作负荷使用 Microsoft Foundry，则可以扩展 MLOps 过程，使其 评估功能 包含在评估 SDK 中。
RAG 和提示
你需要扩展现有的 MLOps 投资来评估生成式 AI 解决方案。 可以在 Foundry 或 Evaluation SDK 中使用评估。
无论生成 AI 解决方案的用例如何，试验过程都保持一致。 这些用例包括分类、汇总、翻译和 RAG。 重要的区别是用于评估不同用例的指标。 根据用例考虑以下指标：
- 翻译：BLEU
- 摘要：ROUGE、BLEU、BERTScore、METEOR
- 分类：准确率、召回率、准确度、交叉熵
- RAG：基础性、相关性、一致性、流畅性
注意
有关如何评估语言模型和 RAG 解决方案的详细信息，请参阅 大型语言模型端到端评估。
生成式 AI 解决方案通常将机器学习团队的职责从训练模型扩展到提示和管理基础数据。 由于提示和 RAG 试验和评估不一定需要数据科学家，因此你可能希望使用其他角色（如软件工程师和数据工程师）来执行这些功能。 如果在进行有关提示和 RAG 解决方案的实验过程中将数据科学家排除在外，可能会遇到挑战。 其他角色通常缺乏对结果进行科学评估所需的专业培训，因此不如数据科学家那样有效。 有关详细信息，请参阅 设计和开发 RAG 解决方案。
投资生成式 AI 解决方案有助于减少数据科学资源的一些工作负荷。 软件工程师在这些解决方案中的作用在不断扩大。 例如，软件工程师是管理生成 AI 解决方案中的业务流程责任的绝佳资源，并且擅长设置评估指标。 让数据科学家审查这项工作非常重要。 他们受过培训并且有经验，了解如何正确评估实验。
在项目的初始阶段执行评估时，请求主题专家的反馈也是个好主意。
部署
一些生成 AI 解决方案包括部署自定义训练的模型或微调现有模型。 对于生成式 AI 解决方案，需要包括部署编排器和任何数据存储的附加任务。 以下部分介绍了典型生成式 AI 技术模式的部署。
Fine-tuning
使用您现有的 MLOps 投资，并进行一些可能的调整，以部署生成式 AI 模型并微调基础模型。 例如，若要在 Azure OpenAI 中微调大型语言模型，请确保训练和验证数据集采用 JSONL 格式，并通过 REST API 上传数据。 同时创建微调任务。 若要部署经过训练的小型语言模型，请利用现有的 MLOps 投资。
RAG 和提示
对于 RAG 和提示，请考虑业务流程逻辑、对数据存储（如索引和架构）的修改，以及对数据管道逻辑的调整。 业务流程逻辑通常封装在 Microsoft Agent Framework SDK 等框架中。 可以将业务流程协调程序部署到不同的计算资源，包括当前部署自定义模型的资源。 此外，代理业务流程协调程序可以是低代码解决方案，例如 Foundry 代理服务。 有关如何部署聊天代理的详细信息，请参阅 基线Microsoft Foundry 聊天参考体系结构。
部署对数据库资源的更改（例如对数据模型或索引的更改）是需要在 GenAIOps 中处理的新任务。 使用大型语言模型时，一种常见做法是在 大型语言模型前面使用网关。
许多使用平台托管语言模型的生成式 AI 架构（例如从 Azure OpenAI 提供的模型）包括一个 网关（如 Azure API 管理）。 网关用例包括负载均衡、身份验证、监视。 网关可以在部署新训练或微调的模型方面发挥作用，这样就可以逐步推出新模型。 使用网关以及模型版本控制，可以最大限度地减少部署更改时的风险，并在出现问题时回滚到以前的版本。
特定于生成式 AI 的元素（如协调器）的部署应遵循适当的操作过程。
- 严格的测试，包括单元测试
- 集成测试
- A/B 测试
- 端到端测试
- 推出策略，如金丝雀部署或蓝绿部署
由于生成式 AI 应用程序的部署责任超出了模型部署的范围，因此可能需要额外的作业角色来管理用户界面、业务流程协调程序和数据存储等组件的部署和监视。 这些角色通常与 DevOps 工程师技能组保持一致。
推理和监视
推理是将输入传递到已训练和部署的模型的过程，然后生成响应。 应从操作监控、从生产中学习和资源管理的角度监视传统机器学习和生成式 AI 解决方案。
操作监视
操作监视是观察系统正在进行的操作的过程，包括 DataOps 和模型训练。 这种类型的监控查找偏差，包括错误、错误率的变化和处理时间的变化。
对于模型训练和微调，通常可以看到 DataOps 来处理功能数据、模型训练和微调。 为了有效监视这些内部循环流程，应利用现有的 MLOps 和 DataOps 投资。
在生成式 AI 解决方案中进行提示时，您需要额外关注监控方面的顾虑。 你必须监视处理基础数据或用于生成提示的其他数据的数据管道。 此处理可能包括数据存储操作，例如生成或重新生成索引。
在多代理系统中，需要监视业务流程协调程序与之交互的代理的可用性、性能特征和响应质量和一致性。
作为作监视的一部分，跟踪指标（如延迟、令牌使用情况和 429 错误）非常重要，以确保用户不会遇到重大问题。
从生产中学习
推理阶段监视的一个关键方面是从生产数据中学习。 对传统机器学习模型的监视跟踪指标，例如准确性、精度和召回率。 关键目标是避免预测偏移。 使用生成模型（例如 GPT 模型进行分类）的解决方案可以利用现有的 MLOps 监视投资。
使用生成模型来推理基础数据的解决方案使用指标，例如基础性、完整性、使用情况和相关性。 目标是确保模型完全应答查询，并将响应基于其上下文。 在此解决方案中，需要尝试防止数据偏移等问题。 你希望确保提供给模型的基础数据和提示与用户查询密切相关。
使用生成模型进行非预测性任务（如 RAG 解决方案）的方案通常会从用户提供的人工反馈中受益，以评估其有用性。 用户界面可以捕获向上或向下的拇指等反馈。 可以使用此数据定期评估响应。
生成式 AI 解决方案的典型模式是在 生成模型前部署网关。 网关的一个用例是 监视基础模型。 可以使用网关记录输入提示和模型输出。
监视生成式解决方案的另一个关键领域是内容安全性。 目标是审查响应并检测有害或不良内容。 Microsoft Azure AI 内容安全工作室 是一种可用于审查内容的工具。
资源管理
使用作为服务公开的模型（如 Azure OpenAI）的生成解决方案具有与自己部署的模型不同的资源管理考虑因素。 对于作为服务公开的模型，基础设施管理不是一个问题。 相反，重点是服务吞吐量、配额和节流。 Azure OpenAI 将令牌用于计费、限制和配额。 应监视配额使用情况，提高成本管理和性能效率。 Azure OpenAI 还提供用于跟踪令牌使用情况的日志记录功能。
工具
许多 MLOps 从业者使用标准化工具包来组织自动化、跟踪、部署和试验等活动。 此方法抽象化了常见问题和实现细节，这使得这些流程更高效且易于管理。 常用的统一平台是 MLflow。 在查找支持 GenAIOps 模式的新工具之前，应查找现有的 MLOps 工具来评估其对生成式 AI 的支持。 例如，MLflow 支持 各种语言模型的功能。
可以探索将新工具引入工作流程的好处和权衡。 例如，适用于 Python 的 Azure AI 评估 SDK 可能是一个可行的选项，因为它在 Foundry 门户中具有本机支持。
MLOps 和 GenAIOps 成熟度模型
你可能已使用 MLOps 成熟度模型 来评估当前 MLOps 和环境的成熟度。 在扩展 MLOps 对生成式 AI 工作负载的投资时，应使用 GenAIOps 成熟度模型 以评估这些操作。 你可能想要合并这两个成熟度模型，但我们建议单独测量每个模型，因为 MLOps 和 GenAIOps 会单独演变。 例如，你可能处于 MLOps 成熟度模型中的第四级，但仅在 GenAIOps 成熟度模型中的第一级。
使用 GenAIOps 成熟度模型评估。 此评估可帮助你了解对 GenAIOps 的投资进展情况。
总结
当你开始扩展 MLOps 投资以包括生成式人工智能时，请务必了解你无需从头开始这一过程。 可以将现有的 MLOps 投资用于多种生成式 AI 技术模式。 优化生成式模型是一个很好的示例。 生成式 AI 解决方案（如提示工程和 RAG）中的一些流程是新的。 由于它们不是传统 AI 工作流的一部分，因此你需要扩展现有运营投资，并获取新的技能来有效使用它们。
作者
Microsoft维护本文。 以下参与者撰写了本文。
- Luiz Braz | 高级技术专家
- Marco Aurelio Cardoso | 高级软件工程师
- Paulo Lacerda | 云解决方案架构师
- Ritesh Modi | 首席软件工程师
要查看非公开的 LinkedIn 个人资料，请登录到 LinkedIn。