你当前正在访问 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 解决方案使用传统的机器学习做法，例如模型训练和微调。 但是，这些解决方案引入了应标准化的新模式。 生成式人工智能解决方案的技术模式大致可分为三类：
- 预先训练和优化
- 提示设计
- 检索增强生成 (RAG)
训练和优化语言模型
许多生成式 AI 解决方案使用现有的基础语言模型，这些模型在使用前不需要进行优化。 但是，某些用例可以从优化基础模型或训练新的生成 AI 模型（如小型语言模型 (SLM)）中获益。
训练新的 SLM 并微调生成基础模型遵循与训练传统机器学习模型相同的逻辑过程。 这些流程应使用现有的 MLOps 投资。
提示设计
提示工程包括设计作为生成模型输入的有效提示中包含的所有过程。 通常有一个业务流程协调程序来控制生成提示的工作流。 编排器可以通过代理直接或间接地调用多个数据存储来收集信息，包括基础数据。 然后，它会应用所需的逻辑来生成最有效的提示。 然后，将协调器部署为 API 终结点，客户端代码可以在智能应用程序中访问。
下图显示了用于提示工程的体系结构。
此类技术模式可以解决许多用例：
- 分类
- 翻译
- 综述
- 抹布
抹布
RAG 是一种架构模式，它使用提示工程将特定领域的数据作为语言模型的基础数据。 语言模型根据一组特定数据进行训练。 工作负荷可能需要对特定于公司、客户或领域的数据进行推理。 在 RAG 解决方案中，会查询你的数据，并且最相关的结果通常会作为提示的一部分通过业务流程层提供给语言模型。
典型的 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 技术模式的试验。
训练和优化
在对现有语言模型进行微调或训练 SLM 时，可以充分利用您现有的 MLOps 投资。 例如，机器学习管道提供了一个工具包，用于高效高效地进行试验。 通过这些管道，你可以管理整个优化过程，从数据预处理到模型训练和评估。
RAG 和提示工程
使用提示工程和 RAG 工作负荷进行试验需要扩展 MLOps 投资。 对于这些技术模式，工作负荷不会以模型结束。 工作负荷需要业务流程协调程序，该系统可以运行逻辑、调用数据存储或代理以获取所需的信息，如地面数据、生成提示和调用语言模型。 数据存储和存储中的索引也是工作负荷的一部分。 你需要扩展操作，以控制工作负荷的这些方面。
可以在多个维度上尝试提示工程解决方案，包括不同的指令、角色、示例、约束以及高级技术，例如提示串联。 在试验 RAG 解决方案时，还可以尝试其他领域：
- 分块策略
- 用于扩充区块的方法
- 嵌入模型选择
- 搜索索引的配置
- 要执行的搜索类型，例如矢量、全文和混合
如 DataOps 中所述，可重现性和数据版本控制是试验的关键。 良好的试验框架允许存储输入，例如对超参数或提示的更改，以及评估试验时要使用的输出。
就像在现有的 MLOps 环境中一样，可以利用机器学习管道等框架。 机器学习管道具有通过与 AI 搜索等矢量存储集成来支持索引的功能。 GenAIOps 环境可以利用管道的这些功能，并将其与管理提示工程和自定义预处理逻辑的提示流功能相结合。
评估和实验
评估是生成、评估和优化解决方案的迭代试验过程中的关键环节。 对更改的评估提供您所需要的反馈，以便您可以优化或验证当前迭代是否符合要求。 以下部分介绍典型生成 AI 技术模式试验阶段的评估。
训练和优化
为评估经过微调或训练的生成式 AI 模型，应充分利用你现有的 MLOps 资源。 例如，如果使用机器学习管道来协调机器学习模型训练，则可以使用相同的评估功能微调基础语言模型或训练新的 SLA。 这些功能包括使用评估模型组件来计算特定模型类型的行业标准评估指标，并跨模型比较结果。 如果工作负荷使用 Azure AI Foundry，可以改为扩展 MLOps 过程，使其 评估功能 包含在评估 SDK 中。
RAG 和提示工程
你需要扩展现有的 MLOps 投资来评估生成式 AI 解决方案。 你可以使用诸如提供评估框架的提示流之类的工具。 提示流使团队能够定义自定义评估逻辑，并指定条件和指标来评估各种提示变体 和大型语言模型 (LLM) 的性能。 这种结构化方法允许对不同配置（如超参数或体系结构变体）进行并行比较，以确定特定任务的最佳设置。
在实验流程中，任务会在整个实验过程中自动捕获输入和输出数据，以创建全面的实验记录。 你可以通过分析此数据来获取见解并识别有望通知将来迭代的配置。 通过使用提示流来进行高效且系统化的实验，你可以加速生成式 AI 解决方案的开发。
无论生成 AI 解决方案的用例如何，试验过程都保持一致。 这些用例包括分类、汇总、翻译和 RAG。 重要的区别是用于评估不同用例的指标。 根据用例考虑以下指标：
- 翻译：BLEU
- 摘要：ROUGE、BLEU、BERTScore、METEOR
- 分类：准确率、召回率、准确度、交叉熵
- RAG：基础性、相关性
注意
有关如何评估语言模型和 RAG 解决方案的详细信息，请参阅 LLM 端到端评估。
生成式人工智能解决方案通常将机器学习团队的职责从训练模型扩展到提示工程和管理基础数据。 由于提示工程和 RAG 试验和评估不一定需要数据科学家，因此使用软件工程师和数据工程师等其他角色执行这些功能很诱人。 你如果在实验提示工程和 RAG 解决方案的过程中不让数据科学家参与，可能会遇到挑战。 其他角色通常缺乏对结果进行科学评估所需的专业培训，因此不如数据科学家那样有效。 有关详细信息，请参阅 设计和开发 RAG 解决方案。
投资生成式 AI 解决方案有助于缓解数据科学团队的部分工作负担。 软件工程师在这些解决方案中的作用在不断扩大。 例如，软件工程师是管理生成式 AI 解决方案中的业务流程责任的宝贵资源，并且他们擅长在提示流等工具中设置评估指标。 让数据科学家审查这项工作非常重要。 他们受过培训并且有经验，了解如何正确评估实验。
部署
一些生成 AI 解决方案包括部署自定义训练的模型或微调现有模型。 对于生成式 AI 解决方案，需要包括部署编排器和任何数据存储的附加任务。 以下部分介绍了典型生成式 AI 技术模式的部署。
训练和优化
应该使用现有的 MLOps 投资，并进行一些可能的调整，部署生成式 AI 模型和优化基础模型。 例如，若要微调 Azure OpenAI 服务中的 LLM，需要确保训练和验证数据集采用 JSONL 格式，并且需要通过 REST API 上传数据。 你还需要创建优化作业。 若要部署经过训练的 SLM，可以利用现有的 MLOps 投资。
RAG 和提示工程
对于 RAG 和提示工程，其他注意事项包括业务流程逻辑、对数据存储（如索引和架构）的修改，以及对数据管道逻辑的调整。 业务流程逻辑通常封装在提示流、语义内核或 LangChain 等框架中。 您可以将调度器部署到不同的计算资源，包括您当前可能用于部署自定义模型的资源。 有关如何将提示流部署到机器学习管理的在线终结点或 Azure 应用服务的详细信息，请参阅 基线 AI Foundry 聊天参考体系结构。 若要部署到应用服务，Azure OpenAI 聊天体系结构会将流及其依赖项打包为容器。 这种做法可提高不同环境中的可移植性和一致性。
部署对数据库资源的更改（例如对数据模型或索引的更改）是需要在 GenAIOps 中处理的新任务。 使用 LLM 时的一种常见做法是在 LLM 前部署一个网关。
许多使用平台托管语言模型的生成式 AI 架构（例如从 Azure OpenAI 提供的模型）包括一个 网关（如 Azure API 管理）。 网关用例包括负载均衡、身份验证、监视。 网关可以在部署新训练或微调的模型方面发挥作用，这样就可以逐步推出新模型。 使用网关以及模型版本控制，可以最大限度地减少部署更改时的风险，并在出现问题时回滚到以前的版本。
特定于生成式 AI 的元素（如协调器）的部署应遵循适当的操作过程。
- 严格的测试，包括单元测试
- 集成测试
- A/B 测试
- 端到端测试
- 推出策略，如金丝雀部署或蓝绿部署
由于生成式 AI 应用程序的部署责任超出了模型部署的范围，因此可能需要额外的作业角色来管理用户界面、业务流程协调程序和数据存储等组件的部署和监视。 这些角色通常与 DevOps 工程师技能组保持一致。
推理和监视
推理是将输入传递到已训练和部署的模型的过程，然后生成响应。 应从操作监控、从生产中学习和资源管理的角度监视传统机器学习和生成式 AI 解决方案。
操作监视
操作监视是观察系统正在进行的操作的过程，包括 DataOps 和模型训练。 这种类型的监控查找偏差，包括错误、错误率的变化和处理时间的变化。
对于模型训练和微调，通常可以看到 DataOps 来处理功能数据、模型训练和微调。 为了有效监视这些内部循环流程，应利用现有的 MLOps 和 DataOps 投资。
对于生成式 AI 解决方案中的提示工程，你还有额外的监视问题。 你必须监视处理基础数据或用于生成提示的其他数据的数据管道。 此处理可能包括数据存储操作，例如生成或重新生成索引。
在多代理系统中，需要监视业务流程协调程序与之交互的代理的可用性、性能特征和响应质量和一致性。
从生产中学习
推理阶段监视的一个关键方面是从生产数据中学习。 对传统机器学习模型的监视跟踪指标，例如准确性、精度和召回率。 关键目标是避免预测偏移。 使用生成模型进行预测的解决方案（例如用于分类的 GPT 模型）应利用现有的 MLOps 监视投资。
使用生成模型来推理基础数据的解决方案使用指标，例如基础性、完整性、使用情况和相关性。 目标是确保模型完全应答查询，并将响应基于其上下文。 在此解决方案中，需要尝试防止数据偏移等问题。 你希望确保提供给模型的基础数据和提示与用户查询密切相关。
使用生成模型进行非预测任务的解决方案（例如 RAG 解决方案）常常通过来自最终用户的反馈来评估其实用性。 用户界面可以捕获向上或向下的拇指等反馈。 可以使用此数据定期评估响应。
生成式 AI 解决方案的典型模式是在 生成模型前部署网关。 网关的一个用例是 监视基础模型。 可以使用网关记录输入提示和模型输出。
监视生成式解决方案的另一个关键领域是内容安全性。 目标是审查响应并检测有害或不良内容。 Microsoft Azure AI 内容安全工作室 是一种可用于审查内容的工具。
资源管理
使用作为服务公开的模型（如 Azure OpenAI）的生成解决方案具有与自己部署的模型不同的资源管理考虑因素。 对于作为服务公开的模型，基础设施管理不是一个问题。 相反，重点是服务吞吐量、配额和节流。 Azure OpenAI 将令牌用于计费、限制和配额。 应监视配额使用情况，提高成本管理和性能效率。 Azure OpenAI 还提供用于跟踪令牌使用情况的日志记录功能。
工具
许多 MLOps 从业者使用标准化工具包来组织自动化、跟踪、部署和试验等活动。 此方法抽象化了常见问题和实现细节，这使得这些流程更高效且易于管理。 常用的统一平台是 MLflow。 在查找支持 GenAIOps 模式的新工具之前，应查找现有的 MLOps 工具来评估其对生成式 AI 的支持。 例如，MLflow 支持 各种语言模型的功能。
可以探索将新工具引入工作流程的好处和权衡。 例如，适用于 Python 的 Azure AI 评估 SDK 可能是一个可行的选项，因为它在 Azure AI 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。