生成式 AI 引入了一种不同于预测性 AI 的构建和运行 AI 应用的新方式。如需构建生成式 AI 应用，您必须从各种架构和大小中进行选择、精选数据、设计最佳提示、针对特定任务调整模型，并根据真实数据对模型输出进行接地。
本文档介绍了如何调整 DevOps 和 MLOps 流程，以便在现有基础模型上开发、部署和运行生成式 AI 应用。 如需了解如何部署预测性 AI，请参阅 MLOps：机器学习中的持续交付和自动化流水线。
什么是 DevOps 和 MLOps？
DevOps 是一种连接开发和运维的软件工程方法。DevOps 提倡协作、自动化和持续改进，通过持续集成和持续交付 (CI/CD) 等实践来简化软件开发生命周期。
MLOps 基于 DevOps 原则，旨在解决构建和运行机器学习 (ML) 系统时面临的挑战。机器学习系统通常使用预测性 AI 来识别模式并做出预测。MLOps 工作流包括以下内容：
- 数据验证
- 模型训练
- 模型评估和迭代
- 模型部署和投放
- 模型监控
什么是基础模型？
基础模型是生成式 AI 应用的核心组件。这些模型是大型程序，它们使用数据集进行学习并做出决策，而无需人工干预。基础模型基于多种类型的数据进行训练，包括文本、图片、音频和视频。基础模型包括大语言模型 (LLM)（例如 Llama 3.1）和多模态模型（例如 Gemini）。
预测性 AI 模型是针对特定任务在特定数据集上训练的，而基础模型则是在海量且多样化的数据集上训练的。通过此训练，您可以使用基础模型为许多不同的应用场景开发应用。基础模型具有涌现属性 (PDF)，这使它们能够在没有明确训练的情况下对特定输入提供回答。由于这些涌现属性，基础模型很难创建和操作，需要您调整 DevOps 和 MLOps 流程。
开发基础模型需要大量数据资源、专用硬件、大量投资和专业知识。因此，许多企业更愿意使用现有的基础模型来简化其生成式 AI 应用的开发和部署。
生成式 AI 应用的生命周期
生成式 AI 应用的生命周期包括以下阶段：
- 发现：开发者和 AI 工程师确定哪种基础模型最适合其应用场景。他们会考虑每个模型的优缺点和成本，以便做出明智的决策。
- 开发和实验：开发者使用提示词工程来创建和优化输入提示词，以获得所需的输出。在可用时，少量样本学习、参数高效微调 (PEFT) 和模型链有助于引导模型行为。模型链是指按特定顺序编排对多个模型的调用，以创建工作流。
- 部署：开发者必须在部署过程中管理许多工件，包括提示模板、链定义、嵌入模型、检索数据存储区和微调的模型适配器。这些制品有自己的治理要求，需要在整个开发和部署过程中进行细致的管理。生成式 AI 应用部署还必须考虑目标基础设施的技术能力，确保满足应用硬件要求。
- 在生产环境中持续监控：管理员通过 Responsible AI 技术（例如确保模型输出的公平性、透明度和问责制）提高应用性能并维护安全标准。
- 持续改进：开发者会通过提示技术不断调整基础模型，将模型替换为更新的版本，甚至组合多个模型，以提高性能、成本效益或缩短延迟时间。对于需要定期微调或纳入人工反馈环的场景，传统的持续训练仍然具有相关性。
数据工程实践在所有开发阶段都发挥着关键作用。 为了生成可靠的输出，您必须有事实依据（确保模型的输出基于准确和最新的信息）以及来自内部和企业系统的最新数据。调优数据有助于使模型适应特定任务和风格，并纠正持续存在的错误。
找到适合您应用场景的基础模型
由于构建基础模型需要大量资源，因此大多数企业更愿意使用最适合其应用场景的现有基础模型。由于基础模型众多，因此很难找到合适的基础模型。每个模型都有不同的架构、大小、训练数据集和许可。此外，每个用例都有独特的要求，需要您从多个维度分析可用模型。
评估模型时，请考虑以下因素：
- 质量：运行测试提示，以评估输出质量。
- 延迟时间和吞吐量：确定用例所需的正确延迟时间和吞吐量，因为这些因素会直接影响用户体验。例如，聊天机器人比批量处理的摘要任务需要更低的延迟时间。
- 开发和维护时间：考虑初始开发和持续维护的时间投入。与自行部署的公开可用模型相比，托管式模型通常需要更少的工作量。
- 使用费用：考虑与模型关联的基础设施和消耗费用。
- 合规性：评估模型遵守相关法规和许可条款的能力。
开发和实验
在构建生成式 AI 应用时，开发和实验是迭代和编排的。每次实验迭代都涉及优化数据、调整基础模型和评估结果。评估可提供反馈，指导后续迭代，形成持续的反馈环。如果性能不符合预期，您可以收集更多数据、扩充数据或进一步整理数据。此外，您可能需要优化提示、应用微调技术或改用其他基础模型。这种由评估洞见驱动的迭代优化周期对于优化生成式 AI 应用至关重要，就像对于机器学习和预测式 AI 一样。
基础模型范式
基础模型与预测模型不同，因为它们是多用途模型。基础模型不是针对特定任务的数据进行单一用途训练，而是基于广泛的数据集进行训练，因此您可以将基础模型应用于许多不同的应用场景。
基础模型对输入的变化也非常敏感。模型的输出和执行的任务由模型的输入决定。基础模型只需更改输入即可翻译文本、生成视频或对数据进行分类。即使输入发生细微变化，也可能会影响模型正确执行该任务的能力。
基础模型的这些属性需要不同的开发和运营实践。虽然预测性 AI 上下文中的模型是自给自足且特定于任务的，但基础模型是多用途的，需要用户输入之外的其他元素。生成式 AI 模型需要提示，更具体地说是提示模板。提示模板是一组说明和示例，以及用于容纳用户输入的占位符。应用可以将提示模板和动态数据（例如用户输入）组合在一起，以创建完整的提示，即作为输入传递给基础模型的文本。
提示的模型组件
提示的存在是生成式 AI 应用的一个显著特征。模型和提示都不足以生成内容；生成式 AI 两者都需要。模型和提示的组合称为提示模型组件。提示模型组件是足以创建生成式 AI 应用的最小独立组件。提示无需过于复杂。例如，它可以是一条简单的指令，如“将以下句子从英语翻译成法语”，后跟要翻译的句子。但是，如果没有该初步指令，基础模型将无法执行所需的翻译任务。因此，除了输入之外，还需要提供提示（即使只是基本指令），才能让基础模型执行应用所需的任务。
在开发生成式 AI 应用时，提示模型组件为 MLOps 实践创造了重要的区别。在开发生成式 AI 应用时，必须在提示模型组件的上下文中进行实验和迭代。生成式 AI 实验周期通常从测试提示变体开始，包括更改指令措辞、提供更多上下文或添加相关示例，并评估这些更改的影响。这种做法通常称为提示词工程。
提示词工程涉及以下迭代步骤：
- 提示：精心设计和优化提示，以针对特定应用场景从基础模型中引出所需的行为。
- 评估：评估模型的输出（最好以编程方式进行），以衡量其对提示指令的理解程度和执行效果。
如需跟踪评估结果，您可以选择注册实验结果。由于提示本身是提示工程流程的核心元素，因此它成为实验中最重要的工件。
不过，如需对生成式 AI 应用进行实验，您必须确定工件类型。在预测性 AI 中，数据、流水线和代码各不相同。但在生成式 AI 的提示范式中，提示可以包含上下文、指令、示例、护栏以及从其他地方提取的实际内部或外部数据。
如需确定制品类型，您必须认识到提示具有不同的组件，并且需要不同的管理策略。请考虑以下事项：
- 提示作为数据：提示的某些部分就像数据一样。少样本示例、知识库和用户查询等元素本质上都是数据点。这些组件需要以数据为中心的 MLOps 实践，例如数据验证、偏移检测和生命周期管理。
- 提示即代码：其他组件（例如上下文、提示模板和护栏）与代码类似。这些组件定义了提示本身的结构和规则，需要更多以代码为中心的实践，例如审批流程、代码版本控制和测试。
因此，在将 MLOps 实践应用于生成式 AI 时，您必须拥有可让开发者轻松存储、检索、跟踪和修改提示的流程。这些流程可实现快速迭代和有原则的实验。通常，一个版本的提示可能适用于特定版本的模型，而不适用于其他版本。跟踪实验结果时，您必须记录提示、组件版本、模型版本、指标和输出数据。
模型链式和增强
生成式 AI 模型（尤其是大语言模型 [LLM]）在保持时效性和避免幻觉方面面临着固有挑战。将新信息编码到 LLM 中需要进行昂贵且数据密集型的预训练，然后才能部署。根据应用场景，仅使用一个提示模型来执行特定生成可能不够。为了解决此问题，您可以将多个提示模型连接在一起，并调用外部 API 和以代码表示的逻辑。以这种方式连接在一起的一系列提示模型组件通常称为链。
下图展示了链的组件和相关开发流程。
缓解时效性和幻觉问题
检索增强生成 (RAG) (PDF) 和智能体是两种常见的基于链的模式，可以缓解时效性和幻觉问题。
- RAG 使用从数据库中检索到的知识来增强预训练模型，从而无需进行预训练。RAG 通过将最新的事实信息直接纳入生成过程，实现接地并减少幻觉。
- 智能体因 ReAct 提示技术 (PDF) 而普及，它使用 LLM 作为中介，与各种工具（包括 RAG 系统、内部或外部 API、自定义扩展程序，甚至其他智能体）进行交互。智能体通过动态选择和使用相关信息源，实现复杂查询和实时操作。LLM 充当代理，解读用户的查询，决定要使用的工具，并根据检索到的信息制定回答。
您可以使用 RAG 和智能体创建连接到大型信息网络的多智能体系统，从而实现复杂的查询处理和实时决策。
对不同模型、逻辑和 API 的编排并非生成式 AI 应用所独有。例如，商品推荐引擎结合了协同过滤模型、基于内容的模型和业务规则，可为用户生成个性化商品推荐。同样，在欺诈检测中，机器学习模型会与基于规则的系统和外部数据源集成，以识别可疑活动。
这些生成式 AI 组件链的不同之处在于，您无法事先描述组件输入的分布，这使得各个组件更难单独评估和维护。编排会导致您为生成式 AI 开发 AI 应用的方式发生范式转变。
在预测性 AI 中，您可以单独迭代各个模型和组件，然后在 AI 应用中将它们串联起来。在生成式 AI 中，您可以在集成期间开发链，对链进行端到端实验，并以协调的方式迭代链策略、提示、基础模型和其他 API，以实现特定目标。您通常不需要特征工程、数据收集或进一步的模型训练周期；只需更改提示模板的措辞即可。
与预测式 AI 的 MLOps 相比，生成式 AI 的 MLOps 发生了转变，导致了以下差异：
- 评估：由于链的紧密耦合，链需要进行端到端评估，而不仅仅是针对每个组件，以衡量其整体性能和输出质量。在评估技术和指标方面，评估链与评估提示模型类似。
- 版本控制：您必须将链作为一个完整的工件进行管理。您必须跟踪链配置及其自身的修订历史记录，以便进行分析、重现，并了解更改对输出的影响。您的日志必须包含输入、输出、链的中间状态以及每次执行期间使用的任何链配置。
- 持续监控：为了检测链中的性能下降、数据偏移或意外行为，您必须配置主动监控系统。持续监控有助于及早发现潜在问题，从而保持生成式输出的质量。
- 自省：您必须检查链的内部数据流（即每个组件的输入和输出）以及整个链的输入和输出。通过提供对流经链的数据和生成的内容的可见性，开发者可以查明错误、偏见或不良行为的来源。
下图展示了链、提示模型组件和模型调优如何在生成式 AI 应用中协同工作，以减少时效性问题和幻觉。数据经过精选，模型经过调优，并添加了链，以进一步优化回答。评估结果后，开发者可以记录实验并继续迭代。
微调
在开发涉及基础模型的生成式 AI 应用场景时，可能很难仅依靠提示词工程和链式处理来解决应用场景，尤其是对于复杂的任务。为了提高任务性能，开发者通常需要直接对模型进行微调。通过微调，您可以主动更改模型的所有层或部分层（参数高效微调），以优化模型执行特定任务的能力。最常见的模型调优方法如下：
- 监督式微调：您以监督式方式训练模型，让其学会预测给定输入的正确输出序列。
- 基于人类反馈的强化学习 (RLHF)：训练奖励模型来预测人类更喜欢哪种回答。然后，您可以使用此奖励模型在调优过程中引导 LLM 朝着正确的方向发展。此过程类似于让一个人类评判小组来指导模型的学习。
下图展示了调优如何在实验周期内帮助优化模型。
在 MLOps 中，微调与模型训练具有以下共同功能：
- 能够跟踪属于调优作业一部分的制品。例如，工件包括用于调整模型的输入数据或参数。
- 能够衡量调优的影响。借助此功能，您可以针对经过训练的特定任务评估调优后的模型，并将结果与之前针对同一任务调优的模型或冻结的模型进行比较。
持续训练和调优
在 MLOps 中，持续训练是指在生产环境中反复重新训练机器学习模型的做法。持续训练有助于确保模型保持最新状态，并在真实数据模式随时间发生变化时保持良好性能。对于生成式 AI 模型，持续调优模型通常比重新训练过程更实用，因为后者涉及较高的数据和计算成本。
持续调优的方法取决于您的具体应用场景和目标。对于文本摘要等相对静态的任务，持续调优要求可能较低。但对于需要持续与人类对齐的动态应用（如聊天机器人），则需要使用基于人类反馈的技术（如 RLHF）进行更频繁的调优。
如需确定合适的持续调优策略，您必须评估应用场景的性质以及输入数据随时间的变化情况。成本也是一个主要考虑因素，因为计算基础设施会极大地影响调优的速度和费用。图形处理器 (GPU) 和张量处理单元 (TPU) 是微调所需的硬件。GPU 以其并行处理能力而闻名，在处理计算密集型工作负载方面非常高效，通常与训练和运行复杂的机器学习模型相关。而 TPU 是 Google 专为加速机器学习任务而设计的。TPU 擅长处理深度学习神经网络中常见的大型矩阵运算。
数据方面的做法
以前，机器学习模型的行为完全由其训练数据决定。虽然基础模型仍然如此，但基于基础模型构建的生成式 AI 应用的模型行为取决于您如何使用不同类型的输入数据来调整模型。
基础模型基于以下数据进行训练：
- 预训练数据集（例如 C4、The Pile 或专有数据）
- 指令调优数据集
- 安全调优数据集
- 人类偏好数据
生成式 AI 应用会根据以下数据进行调整：
- 提示
- 扩充或接地数据（例如网站、文档、PDF、数据库或 API）
- 用于 PEFT 的特定任务数据
- 特定任务评估
- 人类偏好数据
预测性机器学习和生成式 AI 在数据实践方面的主要区别在于生命周期流程的开始阶段。在预测性机器学习中，您需要花费大量时间进行数据工程，如果没有合适的数据，您就无法构建应用。在生成式 AI 中，您首先需要一个基础模型、一些指令，可能还需要一些示例输入（例如上下文学习）。您可以使用极少的数据来设计原型并发布应用。
然而，原型设计虽然简单，但也带来了管理各种数据的额外挑战。预测性 AI 依赖于定义明确的数据集。在生成式 AI 中，单个应用可以使用来自完全不同数据源的各种数据类型，所有这些数据类型可以协同工作。
请考虑以下数据类型：
- 条件提示：向基础模型提供的指令，用于引导其输出并设置其可生成内容的边界。
- 少样本示例：一种通过输入-输出对向模型展示您想要实现的目标的方法。这些示例可帮助模型理解特定任务，并且在许多情况下，这些示例可以提升性能。
- 接地或增强数据：这些数据可让基础模型针对特定上下文生成回答，并保持回答的时效性和相关性，而无需重新训练整个基础模型。这些数据可以来自外部 API（例如 Google 搜索）或内部 API 和数据源。
- 特定于任务的数据集：这些数据集有助于针对特定任务微调现有基础模型，从而提高其在特定领域的性能。
- 完整预训练数据集：用于初始训练基础模型的庞大数据集。虽然应用开发者可能无法访问这些数据或分词器，但模型本身编码的信息会影响应用的输出和性能。
这些多样化的数据类型在数据组织、跟踪和生命周期管理方面增加了复杂性。例如，基于 RAG 的应用可以重写用户查询，使用精选示例集动态收集相关示例，查询向量数据库，并将信息与提示模板相结合。基于 RAG 的应用需要您管理多种数据类型，包括用户查询、包含精选少样本示例和公司信息的向量数据库，以及提示模板。
每种数据类型都需要精心组织和维护。例如，向量数据库需要将数据处理为嵌入、优化分块策略，并确保仅提供相关信息。提示模板需要进行版本控制和跟踪，用户查询需要重写。MLOps 和 DevOps 最佳实践可以帮助您完成这些任务。在预测性 AI 中，您需要创建数据流水线来提取、转换和加载数据。在生成式 AI 中，您需要构建流水线，以可版本化、可跟踪和可重现的方式管理、演进、调整和集成不同的数据类型。
微调基础模型可以提升生成式 AI 应用的性能，但模型需要数据。您可以通过以下方式获取这些数据：发布应用并收集真实数据、生成合成数据，或将两者结合使用。使用大模型生成合成数据正变得越来越流行，因为这种方法可以加快部署过程，但仍需要人工检查结果以确保质量。以下示例说明了如何将大模型用于数据工程：
- 合成数据生成：此过程涉及创建在特征和统计属性方面与真实数据非常相似的人工数据。大型且功能强大的模型通常可以完成此任务。 合成数据可作为生成式 AI 的额外训练数据，使其能够在带标签的真实数据稀缺的情况下学习模式和关系。
- 合成数据校正：此方法侧重于识别和更正现有带标签数据集中的错误和不一致之处。通过利用更大模型的强大功能，生成式 AI 可以标记潜在的标签错误并提出更正建议，从而提高训练数据的质量和可靠性。
- 合成数据增强：此方法不仅限于生成新数据。合成数据增强涉及智能地操纵现有数据，以创建多样化的变体，同时保留基本特征和关系。在训练过程中，生成式 AI 遇到的场景比预测性 AI 更广泛，这有助于提高泛化能力，并能够生成细致入微且相关的输出。
与预测性 AI 不同，生成式 AI 很难评估。例如，您可能不知道基础模型的训练数据分布。您必须构建一个自定义评估数据集，以反映您的所有使用场景，包括基本场景、平均场景和极端场景。与微调数据类似，您可以使用强大的大语言模型来生成、精选和增强数据，以构建强大的评估数据集。
评估
评估流程是生成式 AI 应用开发的核心活动。评估可能具有不同的自动化程度：从完全由人工驱动到完全由流程自动化。
在对项目进行原型设计时，评估通常是一个手动过程。开发者会审核模型的输出，从而对模型的性能进行定性评估。但随着项目成熟和测试用例数量增加，手动评估会成为瓶颈。
自动化评估有两大好处：它可以让您更快地行动，并使评估更可靠。它还消除了人为的主观因素，有助于确保结果可重现。
不过，自动评估生成式 AI 应用也面临着一系列挑战。例如，应该考虑以下事项：
- 输入（提示）和输出都可能非常复杂。单个提示可能包含模型必须管理的多个指令和限制。输出本身通常是高维的，例如生成的图片或文本块。用一个简单的指标来衡量这些输出的质量并非易事。一些既定指标（例如用于翻译的 BLEU 和用于摘要的 ROUGE）并不总是足够。因此，您可以使用自定义评估方法或其他基础模型来评估系统。例如，您可以提示大语言模型（例如 AutoSxS）从各个维度对生成文本的质量进行评分。
- 生成式 AI 的许多评估指标都是主观的。输出结果的优劣可能因人而异。您必须确保自动化评估与人工评判结果一致，因为您希望指标能够可靠地反映人们的想法。为了确保实验之间具备可比性，您必须在开发流程的早期阶段确定评估方法和指标。
- 缺乏标准答案数据，尤其是在项目早期阶段。一种解决方法是生成合成数据作为临时标准答案，然后随着时间的推移，根据人工反馈不断优化。
- 全面评估对于保护生成式 AI 应用免受对抗性攻击至关重要。恶意方可能会精心设计提示，试图窃取敏感信息或操纵模型的输出。评估集需要通过提示词模糊测试（向模型输入随机变化的提示词）和信息泄露测试等技术，专门针对这些攻击途径进行测试。
如需评估生成式 AI 应用，请实现以下内容：
- 实现评估流程自动化，以帮助确保速度、可伸缩性和可重现性。您可以将自动化视为人工判断的代理。
- 根据应用场景的需求自定义评估流程。
- 为了确保可比性，请在开发阶段尽早稳定评估方法、指标和标准答案数据。
- 生成合成标准答案数据，以弥补真实标准答案数据的不足。
- 在评估集中添加对抗性提示词测试用例，以测试系统本身抵御这些攻击的可靠性。
部署
生产环境级生成式 AI 应用是具有许多交互组件的复杂系统。如需将生成式 AI 应用部署到生产环境，您必须管理这些组件并将其与生成式 AI 应用开发的先前阶段进行协调。例如，单个应用可能会将多个 LLM 与一个数据库结合使用，所有这些 LLM 都由动态数据流水线提供数据。每个组件都可能需要自己的部署流程。
部署生成式 AI 应用与部署其他复杂软件系统类似，因为您必须部署数据库和 Python 应用等系统组件。我们建议您使用标准软件工程实践，例如版本控制和 CI/CD。
版本控制
生成式 AI 实验是一个迭代过程，涉及开发、评估和修改的重复循环。为确保采用结构化且可管理的方法，您必须为所有可修改的组件实施严格的版本控制。这些部分包括以下几项：
- 提示模板：除非您使用特定的提示管理解决方案，否则请使用版本控制工具来跟踪版本。
- 链定义：使用版本控制工具跟踪定义链的代码（包括 API 集成、数据库调用和函数）的版本。
- 外部数据集：在 RAG 系统中，外部数据集发挥着重要作用。使用 BigQuery、AlloyDB for PostgreSQL 和 Agent Platform Feature Store 等现有数据分析解决方案来跟踪这些更改和这些数据集的版本。
- 适配器模型：适配器模型的 LoRA 调优等技术在不断发展。使用成熟的数据存储解决方案（例如 Cloud Storage）来有效管理这些资产并对其进行版本控制。
持续集成
在持续集成框架中，每次代码更改在合并前都会经过自动测试，以便尽早发现问题。单元测试和集成测试对于确保质量和可靠性至关重要。单元测试侧重于单个代码片段，而集成测试则验证不同组件是否能协同工作。
实现持续集成系统有助于执行以下操作：
- 确保输出可靠、高质量：严格的测试可增强对系统性能和一致性的信心。
- 尽早发现 bug：通过测试发现问题，可防止问题在下游造成更大的问题。尽早发现 bug 可使系统更加稳健，并能更好地应对极端情况和意外输入。
- 降低维护成本：文档完善的测试用例可简化问题排查，并使未来的修改更加顺畅，从而减少整体维护工作。
这些优势适用于生成式 AI 应用。对系统的所有元素（包括提示模板、链、链逻辑、任何嵌入式模型和检索系统）应用持续集成。
不过，将持续集成应用于生成式 AI 会面临以下挑战：
- 难以生成全面的测试用例：生成式 AI 输出的复杂性和开放性使得难以定义和创建涵盖所有可能性的详尽测试用例集。
- 可重现性问题：实现确定性、可重现的结果非常棘手，因为生成模型在输出中通常具有内在的随机性和可变性，即使输入相同也是如此。这种随机性使得持续测试预期行为变得更加困难。
这些挑战与如何评估生成式 AI 应用这一更广泛的问题密切相关。您可以将许多相同的评估技术应用于生成式 AI 的 CI 系统开发。
持续交付
代码合并后，持续交付流程开始将构建和测试的代码移至与生产环境非常相似的环境中，以便在最终部署之前进行进一步测试。
如开发和实验中所述，链元素是需要部署的主要组件之一，因为它们从根本上构成了生成式 AI 应用。包含链的生成式 AI 应用的交付流程可能会因延迟时间要求以及应用场景是批量还是在线而有所不同。
批处理用例要求您部署在生产环境中按时间表执行的批处理。交付过程侧重于在部署之前，在与生产环境类似的环境中测试整个流水线的集成情况。在测试过程中，开发者可以断言有关批处理本身吞吐量的特定要求，并检查应用的所有组件是否正常运行。（例如，开发者可以检查权限、基础设施和代码依赖项。）
在线用例要求您部署一个 API，该 API 是包含链的应用，能够以低延迟响应用户。您的交付流程涉及在与生产环境类似的环境中对 API 进行集成测试。这些测试可验证应用的所有组件是否正常运行。您可以通过一系列测试（包括负载测试）来验证非功能性要求（例如可伸缩性、可靠性和性能）。
部署核对清单
以下列表介绍了使用 Gemini Enterprise Agent Platform 等代管式服务部署生成式 AI 应用时要执行的步骤：
- 配置版本控制：为模型部署实施版本控制实践。版本控制可让您在必要时回滚到之前的版本，并跟踪对模型或部署配置所做的更改。
- 优化模型：在打包或部署模型之前，执行模型优化任务（蒸馏、量化和剪枝）。
- 将模型容器化：将经过训练的模型打包到容器中。
- 定义目标硬件要求：确保目标部署环境满足模型实现最佳性能的要求，例如 GPU、TPU 和其他专用硬件加速器。
- 定义模型端点：指定模型容器、输入格式、输出格式以及任何其他配置参数。
- 分配资源：根据预期流量和性能要求，为端点分配适当的计算资源。
- 配置访问权限控制：设置访问权限控制机制，以根据身份验证和授权政策限制对端点的访问。访问权限控制有助于确保只有获得授权的用户或服务才能与已部署的模型进行交互。
- 创建模型端点：创建端点，以将模型部署为 REST API 服务。通过该端点，客户端可以向端点发送请求并接收来自模型的回答。
- 配置监控和日志记录：设置监控和日志记录系统，以跟踪端点的性能、资源利用率和错误日志。
- 部署自定义集成：使用模型的 SDK 或 API 将模型集成到自定义应用或服务中。
- 部署实时应用：创建流处理流水线，以实时处理数据并生成回答。
记录和监控
监控生成式 AI 应用及其组件需要使用一些技术，您可以将这些技术添加到用于传统 MLOps 的监控技术中。您必须端到端地记录和监控应用，包括记录和监控应用的整体输入和输出以及每个组件。
应用的输入会触发多个组件来生成输出。如果给定输入的输出不符合事实，您必须确定哪些组件表现不佳。您需要在日志记录中为所有已执行的组件提供沿袭。您还必须将输入和组件与它们所依赖的任何其他工件和参数进行映射，以便分析输入和输出。
在应用监控时，优先在应用级层进行监控。如果应用级监控证明应用运行良好，则意味着所有组件也运行良好。之后，对提示的模型组件应用监控，以获得更精细的结果并更好地了解应用。
与 MLOps 中的传统监控一样，您必须部署提醒流程，以便在检测到漂移、倾斜或性能下降时通知应用所有者。如需设置提醒，您必须将提醒和通知工具集成到监控流程中。
以下部分介绍了监控偏差和偏移以及持续评估任务。此外，MLOps 中的监控还包括监控系统整体运行状况的指标，例如资源利用率和延迟时间。这些效率指标也适用于生成式 AI 应用。
偏差检测
传统机器学习系统中的偏差检测是指训练-应用偏差，当生产环境中的特征数据分布与模型训练期间观察到的特征数据分布不同时，就会发生这种偏差。对于在串联在一起以生成输出的组件中使用预训练模型的生成式 AI 应用，您还必须测量偏离。您可以通过比较用于评估应用的输入数据的分布与生产环境中应用的输入数据的分布来衡量偏差。如果两个分布出现偏移，您必须进一步调查。您也可以对输出数据应用相同的流程。
偏移检测
与偏差检测一样，偏移检测会检查两个数据集之间的统计差异。不过，偏移检测不会比较评估输入和传送输入，而是会查找输入数据中的变化。通过偏移，您可以评估输入，从而了解用户行为如何随时间而变化。
鉴于应用的输入通常是文本，您可以使用不同的方法来衡量倾斜和偏移。一般来说，这些方法会尝试识别生产数据与评估数据集相比发生的重大变化，包括文本变化（例如输入大小）和概念变化（例如输入中的主题）。所有这些方法都在寻找可能表明应用可能未准备好成功处理现在传入的新数据性质的变化。常见方法包括：
- 计算嵌入和距离
- 统计文本长度和 token 数量
- 跟踪数据集中的词汇变化、新概念和意图、提示和主题
- 使用统计方法，例如最小二乘密度差 (PDF)、最大平均差异 (MMD)、学习的内核 MMD (PDF) 或上下文感知 MMD。
由于生成式 AI 的应用场景非常多样，您可能需要额外的自定义指标，以便更好地捕获数据中的意外变化。
持续评估
持续评估是生成式 AI 应用监控的另一种常见方法。在持续评估系统中，您需要捕获模型的生产输出，并使用该输出运行评估任务，以跟踪模型在一段时间内的性能。您可以收集直接的用户反馈（例如评分），从而即时了解用户对输出质量的看法。同时，将模型生成的回答与既定的标准答案进行比较，可以更深入地分析性能。您可以通过人工评估或集成 AI 模型方法来收集标准答案，以生成评估指标。此过程可让您了解评估指标从模型开发到当前生产环境的变化情况。
治理
在 MLOps 的背景下，治理涵盖了所有实践和政策，这些实践和政策可对机器学习模型的开发、部署和持续管理（包括与代码、数据和模型生命周期相关的所有活动）建立控制、问责和透明度。
在预测性 AI 应用中，沿袭侧重于跟踪和了解机器学习模型的完整历程。在生成式 AI 中，沿袭不仅限于模型工件，还扩展到链中的所有组件。跟踪包括数据、模型、模型沿袭、代码以及相对评估数据和指标。沿袭跟踪可帮助您审核、调试和改进模型。
除了这些新做法之外，您还可以使用标准 MLOps 和 DevOps 做法来管理数据生命周期和生成式 AI 组件生命周期。
后续步骤
作者：Anant Nawalgaria、Christos Aniftos、Elia Secchi、Gabriela Hernandez Larios、Mike Styer 和 Onofrio Petragallo