生成式 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 模型不同，基础模型是基于庞大且多样化的数据集进行训练的，而预测性 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 和代理创建与大型信息网络关联的多代理系统，从而实现复杂的查询处理和实时决策。
对生成式 AI 应用来说，协调不同的模型、逻辑和 API 并不新鲜。例如，推荐引擎会结合协同过滤模型、基于内容的模型和业务规则，为用户生成个性化商品推荐。同样，在欺诈检测中，机器学习模型会与基于规则的系统和外部数据源集成，以识别可疑活动。
这些生成式 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 很难评估。例如，您可能不知道基础模型的训练数据分布。您必须构建一个自定义评估数据集，其中包含所有用例，包括基本用例、平均用例和极端用例。与微调数据类似，您可以使用强大的 LLM 生成、管理和增强数据，以构建稳健的评估数据集。
评估
评估流程是生成式 AI 应用开发的核心活动。评估的自动化程度可能不同：从完全由人工驱动到完全由流程自动化。
在对项目进行原型设计时，评估通常是一个手动过程。开发者查看模型的输出，从定性角度了解模型的效果。但随着项目的成熟和测试用例数量的增加，手动评估会成为瓶颈。
自动化评估有两个显著的好处：可以让您更快地完成工作，并提高评估的可靠性。它还能消除人为的主观性，有助于确保结果可重现。
不过，自动评估生成式 AI 应用也面临着一系列挑战。例如，应该考虑以下事项：
- 输入（问题）和输出都可能非常复杂。单个提示可能包含模型必须管理的多个指令和约束条件。输出本身通常是高维的，例如生成的图片或文本块。很难用简单的指标来衡量这些输出的质量。有些已建立的指标（例如用于翻译的 BLEU 和用于摘要的 ROUGE）并不总是足够的。因此，您可以使用自定义评估方法或其他基础模型来评估您的系统。例如，您可以提示大型语言模型（例如 AutoSxS）对生成的文本质量进行评分，并从多个维度进行评分。
- 生成式 AI 的许多评估指标都是主观的。哪种输出更好，这可能因人而异。您必须确保自动评估结果与人工判断一致，因为您希望指标能够可靠地反映用户的想法。为确保实验之间具有可比性，您必须在开发流程的早期阶段确定评估方法和指标。
- 缺少标准答案数据，尤其是在项目的早期阶段。一种解决方法是生成合成数据作为临时标准答案，您可以根据人工反馈不断优化这些数据。
- 全面评估对于防范生成式 AI 应用遭到对抗性攻击至关重要。恶意行为者可以构造提示，试图提取敏感信息或操纵模型的输出。评估集需要通过提示模糊处理（向模型提供提示的随机变体）和信息泄露测试等技术来专门解决这些攻击媒介。
如需评估生成式 AI 应用，请实现以下内容：
- 自动执行评估流程，以确保速度、可伸缩性和可重复性。您可以将自动化操作视为人类判断的替代方案。
- 根据您的用例需求自定义评估流程。
- 为确保可比性，请在开发阶段尽早稳定评估方法、指标和标准答案数据。
- 生成合成标准答案数据，以弥补缺少真实标准答案数据的问题。
- 在评估集内添加对抗性提示的测试用例，以测试系统本身对抗这些攻击的可靠性。
部署
生产环境级生成式 AI 应用是包含许多相互交互的组件的复杂系统。如需将生成式 AI 应用部署到生产环境，您必须管理这些组件并与生成式 AI 应用开发的先前阶段进行协调。例如，单个应用可能会同时使用多个 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。这些测试可验证应用的所有组件是否正常运行。您可以通过一系列测试（包括负载测试）来验证非功能性要求（例如可伸缩性、可靠性和性能）。
部署核对清单
以下列表介绍了使用 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 组件生命周期。