部署和运维生成式 AI 应用

使用集合让一切井井有条 根据您的偏好保存内容并对其进行分类。

生成式 AI 引入了一种与预测式 AI 不同的新方式来构建和运行 AI 应用。如需构建生成式 AI 应用，您必须从各种架构和大小中进行选择，挑选数据，设计最优提示，针对特定任务调优模型，以及使用真实数据中的地面模型输出。

本文档介绍了如何调整 DevOps 和 MLOps 流程，以在现有基础模型上开发、部署和运行生成式 AI 应用。如需了解如何部署预测性 AI，请参阅 MLOps：机器学习中的持续交付和自动化流水线。

什么是 DevOps 和 MLOps？

DevOps 是一种连接开发和运营的软件工程方法。DevOps 通过持续集成和持续交付 (CI/CD) 等做法，促进协作、自动化和持续改进，以简化软件开发生命周期。

MLOps 基于 DevOps 原则，解决构建和运行机器学习 (ML) 系统面临的挑战。机器学习系统通常使用预测性 AI 来识别模式并进行预测。MLOps 工作流包括以下内容：

• 数据验证
• 模型训练
• 模型评估和迭代
• 模型部署和投放
• 模型监控

什么是基础模型？

基础模型是生成式 AI 应用的核心组件。这些模型是大型程序，使用数据集学习和做出决策，而无需人工干预。基础模型基于多种类型的数据进行训练，包括文本、图片、音频和视频。基础模型包括 Llama 3.1 等大语言模型 (LLM) 和 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，以实现特定目标。您通常不需要特征工程、数据收集或进一步的模型训练周期；只需更改提示模板的措辞即可。

与将 MLOps 用于预测式 AI 相反，将生成式 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 难以评估。例如，您可能不知道基础模型的训练数据分布。您必须构建反映所有用例（包括基本用例、平均用例和边缘用例）的自定义评估数据集。与微调数据类似，您可以使用强大的 LLM 生成、挑选和扩充数据，从而构建强大的评估数据集。

评估

评估过程是开发生成式 AI 应用的一项核心活动。评估的自动化程度可能不同：从完全由人驱动，到完全由流程自动化。

在进行项目原型设计时，评估通常是手动过程。 开发者查看模型的输出，对模型性能的定性了解。但随着项目日渐成熟以及测试用例的数量的增加，手动评估就会成为瓶颈。

自动化评估有两大好处：加快速度并使评估更可靠。它还消除了人类主观性，有助于确保结果的可重现性。

但是，对生成式 AI 应用进行自动化评估也面临一系列挑战。例如，应该考虑以下事项：

• 输入（提示）和输出都可能非常复杂。单个提示可能包含模型必须管理的多条说明和约束条件。输出本身通常是高维的，例如生成的图像或文本块。很难通过简单的指标捕获这些输出的质量。一些成熟的指标（例如用于翻译的 BLEU 和用于摘要的 ROUGE）并非总是能满足的。因此，您可以使用自定义评估方法或其他基础模型来评估您的系统。例如，您可以提示大型语言模型（如 AutoSxS）对所生成文本在不同维度的质量进行评分。
• 生成式 AI 的许多评估指标具有主观性。导致一个输出优于另一个输出的原因可能是观念。您必须确保自动评估与人工判断相符，因为您希望自己的指标能够可靠地代表人们的想法。为了确保实验之间的可比性，您必须在开发过程的早期确定评估方法和指标。
• 缺乏标准答案数据，尤其是在项目的早期阶段。权宜解决方法是生成合成数据作为临时标准答案，您可以随着时间的推移根据人类反馈对其进行优化。
• 综合评估对于保护生成式 AI 应用免受对抗性攻击至关重要。恶意操作者可能会设计提示来尝试提取敏感信息或操纵模型的输出。评估集需要通过提示模糊测试（向模型提供提示的随机变体）和测试信息泄露等技术，专门应对这些攻击向量。

如需评估生成式 AI 应用，请实施以下事项：

• 自动执行评估流程，以帮助确保速度、可伸缩性和可再现性。您可以将自动化技术视为人工判断的“替代品”。
• 根据您的使用场景需要自定义评估流程。
• 为了确保可比性，请在开发阶段尽早使评估方法、指标和标准答案数据保持稳定。
• 生成合成的标准答案数据，以应对缺少真实标准答案数据的问题。
• 将对抗性提示测试用例纳入评估集，以测试系统本身针对这些攻击的可靠性。

部署

生产级生成式 AI 应用是具有许多交互组件的复杂系统。如需将生成式 AI 应用部署到生产环境中，您必须管理这些组件，并与生成式 AI 应用开发的先前阶段进行协调。例如，单个应用可能会将多个 LLM 和数据库搭配使用，所有这些 LLM 都由动态数据流水线提供。其中每个组件都需要有自己的部署过程。

部署生成式 AI 应用与部署其他复杂的软件系统类似，因为您必须部署数据库和 Python 应用等系统组件。我们建议您采用标准的软件工程做法，例如版本控制和 CI/CD。

版本控制

生成式 AI 实验是一个迭代过程，涉及重复的开发、评估和修改周期。为了确保采用结构化且易于管理的方法，您必须对所有可修改的组件实现严格的版本控制。这些部分包括以下几项：

• 提示模板：除非您使用特定的提示管理解决方案，否则请使用版本控制工具跟踪版本。
• 链定义：使用版本控制工具跟踪定义链的代码版本（包括 API 集成、数据库调用和函数）。
• 外部数据集：在 RAG 系统中，外部数据集发挥着重要作用。使用现有数据分析解决方案（如 BigQuery、AlloyDB for PostgreSQL 和 Vertex AI Feature Store）跟踪这些数据集的这些更改和版本。
• 适配器模型：适配器模型的 LoRA 调整等技术一直在不断发展。使用成熟的数据存储解决方案（例如 Cloud Storage）来有效地管理这些资源并为其进行版本控制。

持续集成

在持续集成框架中，每项代码更改都会在合并之前经过自动测试，以便及早发现问题。单元测试和集成测试对于质量和可靠性非常重要。单元测试侧重于单个代码段，而集成测试用于验证不同的组件能否协同工作。

实现持续集成系统有助于做到以下几点：

• 确保可靠且高质量的输出：严格的测试有助于提高对系统性能和一致性的信心。
• 及早发现 bug：通过测试找出问题，可防止问题给下游造成更严重的问题。及早发现 bug 使系统更稳健，更能应对极端情况和意外输入。
• 降低维护费用：文档齐全的测试用例可简化问题排查过程，将来也能实现更顺畅的修改，从而减少整体维护工作。

这些福利适用于生成式 AI 应用。将持续集成应用于系统的所有元素，包括提示模板、链、链式逻辑、任何嵌入式模型和检索系统。

但是，将持续集成应用于生成式 AI 会面临以下挑战：

• 难以生成全面的测试用例：生成式 AI 输出结果复杂且开放，因此很难定义和创建涵盖所有可能性的详尽测试用例集。
• 可再现性问题：获得确定性、可重现的结果非常棘手，因为生成模型的输出通常具有固有的随机性和可变性，即使对于完全相同的输入也是如此。这种随机性使得持续测试预期行为更加困难。

这些挑战与如何评估生成式 AI 应用这一更广泛的问题密切相关。您可以将许多相同的评估技术应用于生成式 AI 的 CI 系统开发。

持续交付

代码合并后，持续交付流程开始将已构建和测试的代码移至与生产环境非常相似的环境，以便在最终部署之前进行进一步测试。

如开发和实验中所述，链元素成为要部署的主要组件之一，因为它们从根本上构成了生成式 AI 应用。包含该链的生成式 AI 应用的交付流程可能会有所不同，具体取决于延迟要求以及用例是批量还是在线。

批处理用例要求您部署一个按计划在生产环境中执行的批处理。交付过程侧重于在部署之前在与生产环境类似的环境中在集成中测试整个流水线。在测试过程中，开发者可以声明有关批处理进程本身吞吐量的特定要求，并检查应用的所有组件是否正常运行。（例如，开发者可以检查权限、基础架构和代码依赖项。）

在线用例要求您部署一个 API，该 API 是包含链的应用，能够以低延迟响应用户。您的交付流程涉及在类似于生产环境的集成环境中测试 API。这些测试用于验证应用的所有组件是否均正常运行。您可以通过一系列测试（包括负载测试）来验证非功能性要求（例如可伸缩性、可靠性和性能）。

部署核对清单

以下列表介绍了使用 Vertex AI 等代管式服务部署生成式 AI 应用时要执行的步骤：

• 配置版本控制：对模型部署实施版本控制做法。借助版本控制，您可以在必要时回滚到先前的版本，并跟踪对模型或部署配置所做的更改。
• 优化模型：在打包或部署模型之前，请执行模型优化任务（蒸馏、量化和剪枝）。
• 将模型容器化：将经过训练的模型打包到容器中。
• 定义目标硬件要求：确保目标部署环境满足模型最佳性能的要求，例如 GPU、TPU 和其他专用硬件加速器。
• 定义模型端点：指定模型容器、输入格式、输出格式和任何其他配置参数。
• 分配资源：根据预期的流量和性能要求为端点分配适当的计算资源。
• 配置访问权限控制：设置访问权限控制机制，以根据身份验证和授权政策限制对端点的访问。访问权限控制有助于确保只有获得授权的用户或服务才能与部署的模型进行互动。
• 创建模型端点：创建端点，将模型部署为 REST API 服务。该端点允许客户端向端点发送请求并接收来自模型的响应。
• 配置监控和日志记录：设置监控和日志记录系统以跟踪端点的性能、资源利用率和错误日志。
• 部署自定义集成：使用模型的 SDK 或 API 将模型集成到自定义应用或服务中。
• 部署实时应用：创建流处理流水线，用于处理数据和实时生成响应。

记录和监控

监控生成式 AI 应用及其组件需要一些技术，您可以将这些技术添加到用于传统 MLOps 的监控技术中。您必须以端到端的方式记录和监控应用，包括记录和监控应用及每个组件的整体输入和输出。

应用的输入会触发多个组件来生成输出。如果给定输入的输出在事实上不准确，则必须确定哪些组件性能不佳。您需要记录所有已执行组件的沿袭。您还必须将输入和组件与其依赖的任何其他工件和参数进行映射，以便您可以分析输入和输出。

实施监控时，应优先在应用级别进行监控。如果应用级监控表明应用性能良好，则表示所有组件也运行良好。然后，对提示的模型组件进行监控，以获取更精细的结果并更好地了解您的应用。

与 MLOps 中的传统监控一样，您必须部署提醒流程，以便在检测到偏移、偏差或性能衰减时通知应用所有者。如需设置提醒，您必须将提醒和通知工具集成到监控流程中。

以下部分介绍了如何监控偏差和偏移以及连续评估任务。此外，MLOps 中的监控包括监控资源利用率和延迟时间等整体系统运行状况指标。这些能效指标也适用于生成式 AI 应用。

偏差检测

传统机器学习系统中的偏差检测是指当生产环境中的特征数据分布偏离在模型训练期间观察到的特征数据分布时发生的训练-应用偏差。对于在链接在一起生成输出的组件中使用预训练模型的生成式 AI 应用，您还必须衡量偏差。要衡量偏差，您可以将用于评估应用的输入数据的分布情况与生产环境中的输入数据的分布情况进行比较。如果这两个分布偏离，您必须进一步研究。您也可以对输出数据应用相同的过程。

偏移检测

与偏差检测一样，偏移检测会检查两个数据集之间的统计差异。但是，偏移操作会查找输入数据的变化，而不是比较评估和应用输入。借助 Drift，您可以评估输入，从而了解用户行为如何随时间变化。

鉴于应用的输入通常是文本，您可以使用不同的方法来测量偏差和偏移。通常，这些方法尝试识别与评估数据集相比，生产数据中的重大更改，包括文本（例如输入大小）和概念（例如输入中的主题）。所有这些方法都在寻找变化，这些变化可能表明应用可能未准备好成功处理现在传入的新数据的性质。一些常见方法，包括：

• 计算嵌入和距离
• 计算文本长度和词元数量
• 跟踪数据集中的词汇变化、新概念和意图、提示和主题
• 使用最小二乘密度差异 (PDF)、最大平均差异 (MMD)、已知内核 MMD (PDF) 或情境感知 MMD 等统计方法。

由于生成式 AI 的使用场景非常多样化，因此您可能需要额外的自定义指标，以便更好地捕获数据中的意外变化。

持续评估

持续评估是另一种常见的生成式 AI 应用监控方法。在持续评估系统中，您可以捕获模型的生产输出，并使用该输出运行评估任务，以跟踪模型的效果随时间的变化情况。您可以收集直接的用户反馈（例如评分），从而即时了解感知的输出质量。同时，将模型生成的回答与既定的标准答案进行比较，有助于更深入地分析性能。您可以通过人工评估或集成式 AI 模型方法收集标准答案，以生成评估指标。此过程可让您了解从开发模型到现在在生产环境中的评估指标有何变化。

治理

在 MLOps 语境中，治理包括对机器学习模型的开发、部署和持续管理建立控制、问责制和持续性的所有做法和政策，包括与代码、数据和模型生命周期相关的所有活动。

在预测性 AI 应用中，沿袭侧重于跟踪和了解机器学习模型的完整历程。在生成式 AI 中，沿袭超出模型工件，可以扩展到链中的所有组件。跟踪包括数据、模型、模型沿袭、代码以及相关评估数据和指标。沿袭跟踪可帮助您审核、调试和改进模型。

除了这些新做法之外，您还可以使用标准 MLOps 和 DevOps 做法来管理数据生命周期和生成式 AI 组件生命周期。

后续步骤

使用 Vertex AI 部署生成式 AI 应用

作者：Anant Nawalgaria、Christos Aniftos、Elia Secchi、Gabriela Hernandez Laarios、Mike Styer 和 Onofrio Petragallo