生成式 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 和代理创建连接到大型信息网络的多代理系统，从而实现复杂的查询处理和实时决策。
对于生成式 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 是包含链的应用，能够以低延迟响应用户。您的交付流程涉及在类似于生产环境的环境中测试集成中的 API。这些测试可验证应用的所有组件是否正常运行。您可以通过一系列测试（包括负载测试）来验证非功能性要求（例如可伸缩性、可靠性和性能）。
部署核对清单
以下列表介绍了在使用 Vertex AI 等代管式服务部署生成式 AI 应用时应采取的步骤：
- 配置版本控制：为模型部署实现版本控制实践。借助版本控制，您可以根据需要回滚到之前的版本，并跟踪对模型或部署配置所做的更改。
- 优化模型：在打包或部署模型之前，执行模型优化任务（知识蒸馏、量化和剪枝）。
- 将模型容器化：将训练好的模型打包到容器中。
- 确定目标硬件要求：确保目标部署环境满足模型实现最佳性能的要求，例如 GPU、TPU 和其他专用硬件加速器。
- 定义模型端点：指定模型容器、输入格式、输出格式和任何其他配置参数。
- 分配资源：根据预期流量和性能要求，为端点分配适当的计算资源。
- 配置访问权限控制：设置访问权限控制机制，以根据身份验证和授权政策限制对端点的访问权限。访问权限控制有助于确保只有获得授权的用户或服务才能与已部署的模型进行交互。
- 创建模型端点： 创建端点以将模型部署为 REST API 服务。通过该端点，客户端可以向端点发送请求，并接收来自模型的响应。
- 配置监控和日志记录：设置监控和日志记录系统，以跟踪端点的性能、资源利用率和错误日志。
- 部署自定义集成：使用模型的 SDK 或 API 将模型集成到自定义应用或服务中。
- 部署实时应用：创建可实时处理数据并生成回答的流式流水线。
记录和监控
监控生成式 AI 应用及其组件需要一些技术，您可以将这些技术添加到用于传统 MLOps 的监控技术中。您必须对应用的端到端进行日志记录和监控，包括记录和监控应用的整体输入和输出以及每个组件。
应用的输入会触发多个组件来生成输出。如果针对给定输入的输出在事实上不准确，您必须确定哪个组件的性能不佳。您需要在日志记录中包含所有已执行组件的沿袭信息。您还必须将输入和组件与它们所依赖的任何其他制品和参数进行映射，以便分析输入和输出。
应用监控时，请优先考虑应用级监控。如果应用级监控证明应用运行良好，则意味着所有组件也运行良好。之后，对提示模型组件应用监控，以获得更精细的结果并更好地了解您的应用。
与 MLOps 中的常规监控一样，您必须部署提醒流程，以便在检测到漂移、偏差或性能衰减时通知应用所有者。如需设置提醒，您必须将提醒和通知工具集成到监控流程中。
以下部分介绍了如何监控偏差和漂移，以及如何执行持续评估任务。此外，MLOps 中的监控还包括监控整体系统健康状况的指标，例如资源利用率和延迟时间。这些效率指标也适用于生成式 AI 应用。
偏差检测
传统机器学习系统中的偏差检测是指训练-应用偏差，当生产环境中的特征数据分布与模型训练期间观测到的特征数据分布不同时，就会发生这种偏差。对于在链接在一起以生成输出的组件中使用预训练模型的生成式 AI 应用，您还必须衡量偏差。您可以通过比较用于评估应用的输入数据分布与生产环境中应用的输入分布来衡量倾斜度。如果这两个分布出现漂移，您必须进一步调查。您也可以对输出数据应用相同的流程。
偏移检测
与偏差检测类似，偏移检测会检查两个数据集之间的统计差异。不过，漂移不是比较评估和提供输入，而是查找输入数据的变化。借助 Drift，您可以评估输入，从而了解用户行为随时间的变化。
鉴于应用的输入通常是文本，您可以使用不同的方法来衡量偏差和漂移。一般来说，这些方法旨在识别生产数据（包括文本数据 [例如输入大小] 和概念数据 [例如输入中的主题]）与评估数据集相比的显著变化。所有这些方法都在寻找可能表明应用可能未准备好成功处理现在传入的新数据性质的更改。一些常见方法包括：
- 计算嵌入和距离
- 统计文字长度和 token 数量
- 跟踪数据集中的词汇变化、新概念和 intent、提示和主题
- 使用统计方法，例如最小二乘密度差 (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