你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
面向 MLOps 从业者的 GenAIOps
本文为负责工作负载的团队提供指导，这些团队已有机器学习操作（MLOps）方面的投资，并希望将这些投资扩展，以在其工作负载中包含生成式人工智能。 要使生成式 AI 工作负载投入运营，您需要通过生成式 AI Ops（GenAIOps，有时称为 LLMOps）来扩展您的 MLOps 投资。 本文概述了传统机器学习和生成 AI 工作负载通用的技术模式，以及生成 AI 的特定模式。 本文可帮助你了解在操作化方面可以应用现有投资的位置，以及需要扩展这些投资的位置。
生成式 AI 技术模式
生成式 AI 工作负荷在以下方面不同于传统的机器学习工作负荷：
专注于生成模型。 传统的机器学习工作负载侧重于训练训练以执行特定任务的新模型。 生成式 AI 工作负载使用可解决更广泛的用例的生成模型，在某些情况下是多模式模型。
专注于扩展模型。 传统机器学习中的关键资产是已部署的模型。 向一个或多个工作负荷中的客户端代码提供对模型的访问权限，但工作负荷不是 MLOps 过程的一部分。 使用生成 AI 解决方案时，解决方案的关键方面是提供给生成模型的提示。 必须编写提示，并且可以包含来自一个或多个数据存储的数据。 协调逻辑、调用各种后端、生成提示和调用生成式模型的系统是你必须使用 GenAIOps 管理的生成式 AI 系统的一部分。
尽管一些生成 AI 解决方案使用传统的机器学习做法，如模型训练和微调，但它们都引入了应该标准化的新模式。 本部分概述生成式 AI 解决方案的三大类技术模式：
- 预先训练和微调
- 提示工程
- 检索增强生成 (RAG)
训练和优化语言模型
目前，许多生成式 AI 解决方案使用现有的基础语言模型，这些模型在使用前不需要进行优化。 但是，某些用例可以从微调基础模型或训练新的生成 AI 模型（如小型语言模型（SLM）中获益。
训练新的 SLM 和微调生成基础模型在逻辑上与训练传统机器学习模型的过程相同。 这些流程应使用现有的 MLOps 投资。
提示工程
提示工程包括生成作为生成模型输入的提示所涉及的所有过程。 通常有一个业务流程协调程序来控制生成提示的工作流。 编排器可以调用任意数量的数据存储来收集信息，例如基础数据，并应用所需的逻辑来生成最有效的提示词。 然后，编排器被部署为一个 API 终结点，智能应用程序中的客户端代码可以访问它。
下图显示了用于提示工程的体系结构。
此类技术模式可以解决许多用例，包括：
- 分类。
- 译本。
- 综述。
- 下一部分讨论的检索扩充生成。
检索增强生成
检索扩充生成 (RAG) 是一种体系结构模式，它使用提示工程，将特定于域的数据合并为语言模型的基础数据。 语言模型根据一组特定数据进行训练。 工作负荷可能需要对特定于公司、客户或领域的数据进行推理。 在 RAG 解决方案中，数据会被查询，结果通常通过编排层作为提示的一部分提供给语言模型。
常见的 RAG 实现是将文档分解成区块，并将其与元数据一起存储在向量存储中。 矢量存储（如 Azure AI 搜索）允许你执行文本搜索和矢量相似性搜索以返回上下文相关的结果。 RAG 解决方案还可以使用其他数据存储返回基础数据。
下图演示了 RAG 体系结构：
显示 RAG 体系结构的 
为生成式 AI 技术模式扩展 MLOps
本部分介绍生成式 AI 技术模式的内外循环阶段的以下关键方面，帮助您了解现有的 MLOps 投资可以应用于哪些方面以及需要在哪些方面进行扩展。
内部循环
外部循环
DataOps
MLOps 和 GenAIOps 都应用 DataOps 的基础知识，以创建可扩展且可重现的工作流，以确保正确清理、转换和格式化数据，以便进行试验和评估。 工作流可重现性和数据版本控制是 DataOps 的所有技术模式的重要功能。 数据的源、类型和意向依赖于模式。
训练和优化
此技术模式充分利用你在 MLOps 实施中所进行的现有 DataOps 投资。 可重现性和数据版本控制允许你试验不同的特征工程数据、比较不同模型的性能以及重现结果。
RAG 和提示工程
RAG 解决方案中数据的意图是提供作为提示的一部分提供给语言模型的基础数据。 RAG 解决方案通常需要将大型文档处理到适当大小的语义相关区块集合中，并将这些区块保存在向量存储中。 有关详细信息，请参阅设计和开发 RAG 解决方案。 利用 RAG 解决方案的可重现性和数据版本控制，你可以试用不同的分块和嵌入策略、比较性能，以及回滚到以前的版本。
用于分块文档的数据管道不是传统 MLOps 中的 DataOps 的一部分，因此必须扩展体系结构和操作。 数据管道可以从包括结构化和非结构化数据的不同源读取数据。 它们还可以将转换后的数据写入不同的目标。 你必须扩展体系结构，以包含用于基础数据的数据存储。 这些模式的常见数据存储是像 AI 搜索这样的矢量存储。
与训练和微调一样，可以使用 Azure 机器学习管道或其他数据管道工具来协调分块的阶段。 你可以利用 Azure 机器学习管道中的提示流以一致且可重现的方式处理和扩充数据。 你还必须扩展操作，以保持数据存储中搜索索引的新鲜度和有效性。
试验
试验是内部循环的一部分，是创建、评估和优化解决方案的迭代过程。 以下部分讨论常见生成式 AI 技术模式的试验。
训练和优化
微调现有语言模型或训练小型语言模型时，可以利用当前的 MLOps 投资。 例如，Azure 机器学习管道提供了一个工具包，用于高效高效地进行试验。 通过这些管道，可以管理整个微调过程，从数据预处理到模型训练和评估。
RAG 和提示工程
使用提示工程和 RAG 工作负荷进行试验需要扩展 MLOps 投资。 对于这些技术模式，工作负荷不会以模型结束。 工作任务需要一个编排器，这是一个能够运行逻辑、调用数据存储获取所需信息（如基础数据）、生成提示、调用语言模型等功能的系统。 数据存储和存储中的索引也是工作负荷的一部分。 你需要扩展操作，以控制工作负荷的这些方面。
可以在多个维度上尝试提示工程解决方案，包括不同的指令、角色、示例、约束以及高级技术，例如提示串联。 试用 RAG 解决方案时，可以试用其他区域：
- 分块策略
- 应扩充哪些区块以及如何扩充
- 您的嵌入模型
- 搜索索引的配置
- 要执行的搜索（矢量、全文、混合等）
如 DataOps中所述，可重现性和数据版本控制是试验的关键。 良好的试验框架允许存储输入，例如对超参数或提示的更改，以及评估试验时要使用的输出。
与现有 MLOps 环境中一样，可以利用 Azure 机器学习管道等框架。 Azure 机器学习管道具有通过与 AI 搜索等矢量存储集成来支持索引的功能。 GenAIOps 环境可以利用这些管道功能，并将其与管理提示工程和自定义预处理逻辑的提示流功能相结合。
评估和实验
评估是生成、评估和优化解决方案的迭代试验过程中的关键环节。 对更改的评估提供您所需要的反馈，以便您可以优化或验证当前迭代是否符合要求。 以下各节讨论常见生成式 AI 技术模式试验阶段的评估。
训练和优化
为评估经过微调或训练的生成式 AI 模型，应充分利用你现有的 MLOps 资源。 例如，如果使用 Azure 机器学习管道来协调机器学习模型训练，则可以使用相同的评估功能来微调基础语言模型或训练新的小型语言模型。 这些功能包括 评估模型组件，该组件计算特定模型类型的行业标准评估指标，并跨模型比较结果。
RAG 和提示工程
你需要扩展现有的 MLOps 投资来评估生成式 AI 解决方案。 可以使用提示流等工具，它提供用于评估的框架。 提示流使团队能够定义自定义评估逻辑，并指定条件和指标来评估各种提示变体 和大型语言模型 (LLM) 的性能。 通过这种结构化方法，可以并行比较不同的配置，例如超参数或体系结构变体，以确定特定任务的最佳设置。
提示流中的作业会在试验过程中自动捕获输入和输出数据，从而创建全面的试用记录。 你可以通过分析此数据来获取见解并识别有望通知将来迭代的配置。 通过使用提示流来进行高效且系统化的实验，你可以加速生成式 AI 解决方案的开发。
无论生成 AI 解决方案的用例如何，试验过程都是相同的。 这些用例包括分类、汇总、翻译，甚至 RAG。 重要的区别是用于评估不同用例的指标。 以下是一些基于用例的指标，要考虑。
- 翻译：BLEU
- 摘要：ROUGE。 BLEU、BERTScore、METEOR
- 分类：准确率、召回率、准确度、交叉熵
- RAG：基础性、相关性
注意
有关评估语言模型和 RAG 解决方案的详细信息，请参阅 LLM 端到端评估。
通常，生成式 AI 解决方案将机器学习团队的职责从训练模型扩展到提示工程和管理基础数据。 由于提示工程和 RAG 试验和评估不一定需要数据科学家，因此使用软件工程师和数据工程师等其他角色执行这些功能很诱人。 如果你忽略了数据科学家在提示工程和 RAG 解决方案实验中的作用，你将遇到挑战。 其他角色通常不接受如何科学评估结果的培训，而许多数据科学家则会。 阅读由七部分组成的文章系列：设计和开发 RAG 解决方案，以了解设计生成式 AI 解决方案的复杂性。
通过投资生成式 AI 解决方案，可以缓解数据科学团队的压力。 软件工程师的作用在这些解决方案中扩展。 例如，软件工程师是管理生成 AI 解决方案中的业务流程责任的绝佳资源，并且擅长在提示流等工具中设置评估指标。 让数据科学家审查这项工作非常重要。 他们具有训练和经验，了解如何正确评估试验。
部署
某些生成 AI 解决方案涉及部署自定义训练的模型或微调现有模型，但其他解决方案则不进行优化。 对于生成式 AI 解决方案，需要包括部署业务流程协调程序和任何数据存储的额外任务。 以下部分讨论常见生成 AI 技术模式的部署。
训练和优化
应该使用现有的 MLOps 投资，并进行一些可能的调整，部署生成式 AI 模型和优化基础模型。 例如，若要在 Azure OpenAI 中微调大型语言模型，需要确保训练和验证数据集采用 JSONL 格式，并且需要通过 REST API 上传数据。 你还需要创建优化作业。 要部署经过训练的小型语言模型，可以利用现有 MLOps 投资。
RAG 和提示工程
对于 RAG 和提示工程，还有其他问题，包括编排逻辑、对数据存储（如索引和模式）的更改，以及对数据管道逻辑的更改。 业务流程逻辑通常封装在提示流、语义内核或 LangChain 等框架中。 您可以将调度器部署到不同的计算资源，包括您当前可能用于部署自定义模型的资源。 有关将提示流部署到 Azure 机器学习管理的联机终结点或 Azure 应用服务的示例，请参阅 Azure OpenAI 端到端聊天体系结构。 若要部署到应用服务，Azure OpenAI 聊天体系结构会将流及其依赖项打包为容器，这种做法可提高不同环境中的可移植性和一致性。
部署对数据库资源的更改（如对数据模型或索引的更改）是在 GenAIOps 中需要处理的新任务。 使用大型语言模型时的一种常见做法是使用 LLM 前面的网关。
许多使用平台托管语言模型的生成式 AI 架构（例如从 Azure OpenAI 提供的模型）包括一个 网关（如 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 对生成式 AI 工作负载的投资时，应使用 GenAIOps 成熟度模型 来评估这些操作。 你可能很想组合这两个成熟度模型，但我们建议单独测量每个模型。 MLOps 和 GenAIOps 将相互独立发展。 例如，在 MLOps 成熟度模型中，你可能处于第四级，但在生成式 AI 中你可能处于第一级。
总结
在您开始扩展 MLOps 投资以便包括生成式 AI 时，请务必了解您无需从头开始。 可以将现有的 MLOps 投资用于某些生成式 AI 技术模式。 优化生成式模型是一个很好的示例。 生成式 AI 解决方案（如提示工程和 RAG）有一些领域是全新的流程，因此你需要扩展现有运营投资并获得新技能。
作者
本文由 Microsoft 维护， 它最初是由以下贡献者撰写的。
- 路易斯·布拉兹 |高级技术专家
- Marco Aurelio Cardoso |高级软件工程师
- 保罗·拉塞达 |云解决方案架构师
- Ritesh Modi |首席软件工程师
要查看非公开的 LinkedIn 个人资料，请登录到 LinkedIn。