你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
在 Azure 上测试和评估 AI 工作负载
在 AI 工作负载中进行测试的目的是帮助 确保在系统引入更改时质量。 测试可以验证工作负荷是否满足已识别的目标并满足用户期望。 它还可防止质量回归。 此过程包括跨各种功能领域执行测试，并根据工作负荷要求评估功能质量、负载处理、可预测性和其他标准。
测试结果为决策提供关键数据点，例如 AI 组件是否已准备好发布，以及哪些 SKU 或功能合适。 此外，测试还可以充当 故障通知 系统，并通过常规或综合测试帮助检测生产中的问题。
Azure 精心构建的框架概述了全面的测试方法。 应在 开发生命周期的不同阶段以及跨不同的系统组件和流使用各种类型的测试。 如果没有这些测试，推出的更改可能会降低系统质量。 例如，次要代码错误可能会成为大型系统故障。 由于 AI 系统的不确定性质，系统行为可能会变得不可预知或产生偏见的结果。 此外，资源分配可能效率低下，并且可能会利用实际用户数据或系统资源，因为这些系统容易受到滥用。
必须 考虑到测试来设计和开发工作负荷资产。 例如，在为特征工程执行数据操作和重塑源数据时，请遵循良好的编码做法，并确保构建代码以支持测试。 此策略包括设计代码，以促进有效的单元测试，并将测试与代码的功能及其依赖项隔离开来。 在此示例中，必须设计一个可在测试环境中执行的系统，该系统具有足够具有代表性的测试数据（以卷和类似性而言）。
必须将工作负荷组件安全地部署到生产环境。 任何工作负荷的安全部署做法的一部分是战略测试，以帮助确保在用户或数据使用系统之前正确行为。 战略测试在初始部署期间至关重要，随着系统的发展并经历代码或基础结构更改。 在将更改部署到生产环境之前，先测试 AI 相关代码和基础结构的所有建议更改。
本文重点介绍如何将该方法应用于体系结构的 AI 方面。 如何执行这些测试不在范围内。
建议
下面是本文中提供的建议摘要。
| 建议 | 说明 |
|---|---|
| 定义测试策略的成功指标。 | 与任何其他类型的工作负荷测试一样，需要捕获和分析给定测试的适当指标，以确保测试提供有关 AI 工作负载的有用见解。 ▪ 定义成功指标 |
| 在整个开发生命周期内对数据引入和处理管道进行端到端测试。 | 测试可以验证数据，并帮助确保数据操作过程按预期工作。 在设计阶段早期纳入测试，以确保数据质量和适当的技术和大小调整选择。 在开发过程中开发自定义代码的单元测试，并执行实时生产测试来捕获问题和验证功能。 ▪ 测试数据引入 |
| 针对训练作业运行测试，确保调用脚本并按预期运行。 | 负载和性能测试可以深入了解适合运行作业的计算的选择和大小调整。 单元测试可以验证代码的实用工具，并在更新依赖项时捕获回归。 ▪ 测试训练工作流 |
| 评估和测试模型，以避免在训练、评估和测试数据中重复。 | 为了确保源数据不完全用于训练，必须保留用于模型评估和最终测试的唯一数据。 这些子集不包括在实际训练过程中。 ▪ 评估和测试模型 |
| 测试推理终结点。 | 对推理服务器托管的终结点执行负载测试，并根据这些测试结果选择 GPU SKU。 对于平台即服务（PaaS）托管的终结点，测试吞吐量和潜在故障。 这些终结点可访问，因此进行适当的安全测试，以防止发生越狱情况。 ▪ 测试推理终结点 |
| 测试索引设计的正确性，以便查询产生相关的结果。 | 功能和集成测试可帮助你确保数据准确，并索引架构测试检查是否向后兼容。 必须测试预处理步骤的质量。 负载测试确定适合资源的 SKU，安全控制可保护数据机密性。 ▪ 测试地面数据 |
| 测试业务流程协调程序以验证其功能和安全性。 | 执行单元、功能、集成和运行时测试，包括负载和故障模式测试，以确保性能和可靠性。 安全和内容安全测试对于保护系统和数据也至关重要。 ▪ 测试业务流程协调程序 |
| 测试模型衰减。 | 模型衰减是影响大多数 AI 工作负载的必然问题。 对数据和概念偏移进行测试有助于尽早捕获模型衰减，并缓解问题，然后再对工作负荷造成不利影响。 ▪ 防止模型衰减 |
定义成功指标
建议使用定义完善的指标来比较基准并度量模型的预测能力。 下面是一些常见指标。
准确性 表示正确预测的实例与测试数据集中实例总数的比率。 它是总体模型性能的常见度量值。
精度 是真正预测与真正和假正之和的比率。 例如，将误报降到最低时非常有用，例如在医疗诊断中。
敏感度 测量真正与真正和误报的总和。 当避免误报或缺少相关案例时，这是有价值的。
具体性 计算真负与真负和误报的总和。 针对准确的负预测进行优化时，这一点很相关。
注意
为回归模型定义成功指标时，请考虑添加以下指标：
平均绝对误差（MAE） 测量预测值与实际值之间的平均绝对差。 通过获取每个实际值与其相应预测值之间的绝对差平均值来计算它。 与 MSE 和 RMSE 相比，MAE 对离群值不太敏感。
平均平方误差（MSE） 度量实际值与预测值之间的平均平方差。 通过获取每个实际值与其相应预测值之间的平方差平均值来计算它。 MSE 惩罚比 MAE 更大的错误，因为错误是平方的。
根均方误差（RMSE） 是 MSE 的平方根。 它提供实际值和预测值之间的平均绝对误差度量值，但与原始数据采用相同的单位。 与 MAE 相比，RMSE 对离群值更敏感，因为它在求平均值之前将错误平方。
测试数据引入
数据管道，如提取、转换和加载（ETL）进程、移动和操作数据。 测试工作负荷的 ETL 部分，以确保它可靠地引入数据，并确保数据是高质量且可接受的分析和特征工程。 确保数据清理和处理包括测试，以确认数据操作按预期方式运行。
测试应在整个生命周期内集成，包括设计、开发和生产阶段。
测试以方便设计选择
收集工作负载的要求时，关键决策步骤是选择一个适合设计的特定技术选项。
根据 ETL 要求和验收标准，进行探索性功能测试，以选择最适合的产品、其 SKU 和执行预期任务的功能。 概念证明、技术证明和功能证明测试对于评估你是否选择正确的技术以及是否适当调整大小至关重要。
对于将 AI 纳入现有体系结构的方案，请测试新技术如何与当前系统集成。
初始工作负荷要求可能会更改。 假设业务预计增长，系统需要处理普通用户查询的两倍。 此期望需要适当的容量规划。 建议进行主动测试，以了解系统如何响应额外数据，并针对现有大小或做出新产品选择进行数据驱动的调整。 对于容量测试，我们建议将功能测试与负载和性能测试相结合，并使用合成来模拟现实情况。
测试以确保代码质量
包含代码时，请确保它通过单元测试，如果失败，则不会释放它。 例如，通常让自定义代码作为引入的一部分运行。 还有用于数据清理和处理的代码。 运行单元测试，以确保代码的行为符合其设计，并且数据操作按预期运行。
在持续集成和持续交付管道中运行测试。
在实时系统中进行测试
功能测试应扩展到实时系统。 如果这些测试失败，请考虑触发警报以在必要时启动立即调查。 以下是一些示例：
运行计划测试，以验证是否在具有预期数量的设置计划上引入数据时收集了正确的数据量。
运行检测数据问题（例如缺失值或重复数据）并执行基本数据完整性检查的测试。 如果数据包含指示其新鲜性的临时信息，这些测试可以检查该信息，并可能阻止下游进程使用过时数据。
检查外部依赖项的可用性。 例如，数据清理作业可能会调用另一个服务来提取表或预处理。 运行测试以确保它们可用，因为它们不可用可能会影响 ETL 进程。
测试生产中 ETL 系统的正确性的另一种方法是通过综合测试。 在生产环境中提供已知的测试数据非常有效。 通过将已知起始状态与该数据的预期结束状态进行比较，可以使用它来验证端到端处理。 例如，需要文档才能完成文档智能并包含个人数据。 注入合成文档可以测试工作负荷按预期执行数据操作作业。
此外，通过发布不同的体验（也称为 A/B 测试）进行试验，以在完全提交之前从用户交互中学习。 A/B 测试有助于防止质量回归。
测试引入期间收集的数据
作为来自各种数据源的引入过程的一部分，包括用于验证训练数据是否符合预期的测试。
使用不完整或损坏的数据训练机器学习模型可能会适得其反。 这可能会导致浪费工作，并导致无法进行有意义的预测的模型。 数据引入和预处理管道包括质量测试作为检查点。 这些测试可以帮助你验证数据是否符合在数据分析和特征工程过程中设置的预期。
以下列表包括一些示例测试用例：
测试完整性。 测试预期数量的训练数据，以验证数据集的完整性。 此测试可确保提供足够的数据来训练模型。
测试关键信息。 如果训练基于已知实体（如特定记录或标识符），请测试数据集以确保这些实体存在。 此验证可确保不缺少关键信息。
测试不相关的数据。 引入的数据不应包含不相关的条目或错误条目。 数据引入过程应筛选掉该数据。
测试新鲜度。 引入数据的新鲜度不应影响模型的预测能力。 验证数据是否反映合理的当前信息，并且不会在以前的运行中过时。 例如，如果预期数据包含过去一周的记录，但在导入数据后没有此类记录，这可能表示导入失败或源系统中的数据新鲜度问题。
执行常规测试
数据引入的一个重要问题是数据量和吞吐量。 在操作期间进行持续评估是防止性能瓶颈所必需的。 此持续评估应是运营流程的一部分，而不仅仅是一次性测试。 目标是确保工作负荷团队不会错过其服务级别目标。
请考虑监视指示性能下降的情况。 若要缓解此类情况，请重新评估和优化 ETL 进程。 进行更改后，性能测试可帮助确保修改满足所需的吞吐量。
注意
测试和监视用于不同的目的。 执行测试以评估系统的潜在更改，通常在实现任何更改之前。 持续进行监视以评估系统的整体运行状况。
测试训练工作流
使用自定义代码（如 PyTorch 脚本）训练模型，该脚本执行实际训练工作。 这些脚本在计算上运行，例如笔记本或Azure 机器学习作业，这些作业也需要内存和网络资源。 建议在设计阶段进行负载测试，以评估计算需求，并确保建议的 SKU 合适。 通常需要手动测试来确定在时间限制内高效运行工作负荷的最佳配置。
使用专用 SDK 编写脚本，这些 SDK 处理大部分任务。 但是，由于脚本仍然是代码，因此应将单元测试作为开发的一部分进行集成。 这些测试有助于确保在更新依赖项时不会发生任何回归。 如果无法进行单元测试，则需要在部署新代码之前进行手动测试，以防止质量回归。
这些脚本作为工作流的一部分运行，例如Azure 机器学习工作室，它可以提供有关脚本何时以及脚本是否运行的见解。 但我们建议运行集成测试，以确保这些脚本能够可靠地调用。
评估和测试模型
注意
模型评估和测试通常可互换使用，但应将其视为使用不同数据集的单独进程。 评估是在开发阶段执行的操作的迭代活动。 它侧重于试验，以找到具有适当优化级别的最佳模型。 它包括调整超参数、配置或功能，然后基于各种指标评估模型。 确定最佳模型后，在部署期间执行测试。
测试包括验证整个系统（包括优化的模型和非 AI 组件）以检查它们是否正常运行、很好地集成，并根据质量标准交付预期结果。 与工作负荷的其他组件一起评估模型。 此过程包括向模型发送请求、评估其响应，以及根据测试数据做出一个去或不执行决策。 尽管在生产之前测试不可协商，但我们建议你还使用实际数据和综合数据在生产环境中执行测试。
使用数据来评估和测试
通常，从源数据分区有三个关键数据集：训练、评估和测试。
使用训练数据集（通常是最大的子集）来训练模型。 使用另一个数据集进行评估，通过迭代过程通过评估不同的排列来优化模型。 找到令人满意的排列后，针对测试数据集对其进行测试。
所有数据集都应包含高质量的数据，以尽量减少干扰。 有关数据引入和预处理管道的测试用例可以充当质量检查点。 缺少样本也归因于低质量数据。 使用综合数据平衡和实现数据集中的统一性。 此方法对于训练模型（如欺诈检测模型）非常有用，其中真正的欺诈实例很少见，这使得难以获得足够的统计能力来获得可靠的预测。
若要避免预测中的偏差，请保留所有数据集的不同。 不应使用训练数据进行评估，不应使用评估数据进行测试。 保留用于模型评估和最终测试的唯一数据。
使用评估指标
训练模型并选择适合生产的模型是相互依赖的过程。 你需要最初选择一个模型，但它可能会在试验和评估后更改。
模型评估遵循一个试验循环，该循环使用指标评估模型、参数和特征的许多排列。 这些指标提供科学分级，必须迭代比较不同版本和配置，以确定最佳模型。 有关详细信息，请参阅 评估指标。
类似的方法适用于生成 AI 模型。 具有基于模型性能评估和量化用户体验结果的过程。 例如，基础性是量化模型与源数据对齐程度的关键指标之一。 相关性是另一个重要指标，指示响应与查询的关系。 有关指标示例，请参阅 生成 AI 的评估和监视指标。
使用各种指标评估不同类型的模型。 每个指标的重要性可能因方案而异。 根据用例确定指标的优先级。 例如，公平性对于负责任的 AI 至关重要。 尽管测试良好，但由于源数据偏向，模型仍可能表现出不公平的偏见。 结果的相关性可能很高，但公平性较低。 将公平评估集成到流程中，以确保无偏见的结果。
生成 AI 与业务流程代码、路由逻辑和索引集成，用于检索扩充的生成（RAG），使评估复杂化。 尽管应该使用指标单独评估模型，但评估其他系统组件也很重要。
测试模型
微调本质上是测试，因为它修改了预先训练的模型以更改其行为。 它需要从基线开始才能了解模型的初始性能。 微调后，重新评估模型的性能，以确保其符合质量标准。 请考虑以下常见评估指标：
地面是指 模型与源数据的对齐方式。 基于模型的生成与现实一致的答案。
相关性 指示响应与给定问题的关系。 如果不直接解决问题，则高度基础的答案可能缺乏相关性。
相似性 度量源数据文本与生成的响应之间的相似性。 模型是否使用了精确的措辞？ 缺乏编辑治理可能会降低相似性分数。
检索 指示索引查询的有效性。 评估检索的索引数据与问题保持一致程度。 索引搜索中的不相关数据会降低此分数。 较高的检索分数表示可变性较低，因为它们只依赖于索引查询。
流利 与词汇用法相关。 如果模型遵循样式指南并采用适当的格式呈现内容，即使它缺乏基础或相关性，它也可以流畅。
一致性 评估模型的语音是否自然而连贯。 它评估对话是否像是真正的交流。
测试超参数
模型参数取决于应用程序特定的设计决策。 作为应用程序设计的一部分，请根据工作负荷的用例选择模型和参数。 测试过程具有迭代的内部循环，其中训练数据与测试数据进行比较，以验证模型是否在预期数据集上进行训练。 此外，还优化了参数，以便模型可以进行可接受的准确性级别的预测。
折衷。 内部循环包括训练模型的计算成本，以及通过测试评估模型的成本。 必须考虑模型训练和测试在此循环中所需的时间。 预计测试过程需要比训练过程更长的时间。 可以对训练数据的子集进行初始测试，以评估模型是否生成合理的结果。 可以逐步纵向扩展该测试集到整个数据集。
测试推理终结点
推理终结点是 REST API，允许访问用于进行预测的模型。 它是作为请求的一部分发送数据的接口，并获取包含模型结果的响应。 终结点托管在计算上，可以是 PaaS（例如 Azure OpenAI 服务）或非Microsoft推理服务器，例如 NVIDIA Triton Inference Server、TorchServe 和 BentoML。 在 PaaS 方案中，服务提供商在一定程度上处理测试。 但是，如果托管终结点，请将其视为任何其他 API 并对其进行彻底测试。
尽管在训练和评估期间测试模型，但测试推理终结点涉及确保该模型周围的机制（例如请求处理、响应创建、缩放和协调跨实例）正常工作。 创建一个全面的测试计划，根据你的要求涵盖用例。 本部分介绍需要考虑的一些示例测试用例和测试类型。
推理托管服务器的测试注意事项
请务必了解计算的负载特征，并通过负载测试验证性能。 这些操作有助于在设计或优化体系结构时选择技术。 例如，不同的推理服务器具有不同的性能特征。 随着并发连接数的增加，代码会消耗 CPU 周期和内存。 了解代码和计算资源在标准负载和峰值负载条件下的性能。 Azure 负载测试是负载测试的一个不错的选择，可以生成大容量负载。 其他开源选项（如 Apache JMeter）也很受欢迎。 请考虑直接从环境调用这些测试。 例如，机器学习与负载测试很好地集成。
另一个关键决策是选择 GPU 功能。 许多模型要求 GPU 进行有效的推理，因为它们的设计。 负载测试可帮助你了解 GPU SKU 的性能限制，并防止过度预配，这是重要的财务注意事项。
对于非 PaaS 托管平台，安全性至关重要，因为 API 公开。 请务必确保终结点不会被利用或泄露，这可能会危及整个系统。 将此终结点包含在例行安全测试和其他公共终结点中。 考虑在实时系统上进行渗透测试（如渗透测试）。 安全性的另一个方面是内容安全。 代码可以调用专用 API 来检测请求和响应有效负载中的有害内容。 可以从测试中调用 Azure AI 内容安全，以促进内容安全测试。
有关关键策略，请参阅 安全测试建议。
PaaS 推理终结点的测试注意事项
当客户端向 PaaS 服务上的推理终结点发送请求时，客户端应会出现错误。 由于系统重载、后端无响应和其他错误条件，可能会发生故障。 对服务执行故障模式分析，并测试这些潜在故障。 在客户端代码中设计和实现缓解策略需要故障模式分析。 例如，Azure OpenAI API 通过返回 HTTP 429 错误响应代码来限制请求。 客户端应使用重试机制和断路器处理该错误。 有关详细信息，请参阅执行失败模式分析的建议。
测试 PaaS 服务可以帮助你选择服务 SKU，因为你了解相关的成本，例如即用即付或预预配的计算。 使用 Azure 定价计算器评估工作负荷、频率和令牌使用情况，以确定最佳计费和计算选项。 使用低成本 SKU 模拟工作负荷，并证明适用于 Azure OpenAI 的预配吞吐量单位（PTU）等高端选项是正当的。
负载测试与即用即付计算无关，因为具有无限容量时，你不会遇到问题。 测试会验证限制和配额。 不建议对即用即付计算进行负载测试，因为这是一笔重大财务费用。 但是，应进行负载测试以验证吞吐量，吞吐量以每分钟令牌或每分钟请求为单位。 与考虑指标（如请求大小）的标准 API 不同，此方法根据令牌评估工作负荷以确定使用情况。 关键是了解活动用户数并相应地测量吞吐量。 有关详细信息，请参阅 度量吞吐量。
使用安全控制
无论你是使用推理服务器还是 PaaS 选项，安全性都是你的责任。 使用 API 终结点时，测试越狱和内容安全控制至关重要。 确保无法绕过这些控件并按预期运行。 例如，发送已知阻止的项有助于验证安全控制是否已到位，并在部署前正常工作。 请考虑根据需要运行这些测试，或将它们集成到发布过程中。
请务必测试系统是否无意中公开它不应该的信息。 例如，系统不应在响应有效负载中公开个人信息。 此外，测试以确保客户端无法访问用于其他标识的终结点。 执行安全测试来验证 API 及其身份验证和授权机制是否不会泄露机密信息并维护适当的用户分段。
测试地面数据
数据设计会影响生成模型的效率，而地面数据是关键组成部分。 地面数据提供更多上下文来提升响应的相关性。 它在到达模型之前对其进行索引。 当用户等待答案时，将实时访问此索引。
进行端到端测试，并将该过程合并为数据设计的一部分。 实现一个测试过程，该过程根据模型的性能、业务流程、索引、预处理和源数据来评估和量化客户体验的结果。 以迭代方式监视和度量质量指标。 下面是一些注意事项：
使用功能和集成测试彻底测试数据处理。 验证数据是否按预期加载，以及是否存在所有数据。
测试索引架构以实现向后兼容性。 应测试对文档或字段所做的任何更改，以确保新版本仍能容纳以前版本的数据。
在对数据编制索引之前，它会进行准备，以减少干扰和偏差，并启用高效的查询。 此过程包括预处理、分块和计算嵌入内容，每个步骤将数据保存到索引中的上下文或文件。 业务流程管道（例如 Azure AI 搜索提供的技能集）执行这些步骤。 必须测试业务流程代码，以确保不会错过任何步骤，并且处理的数据质量很高。
测试应检查旧数据、合成值、空表、数据刷新和最新版本的处理。 如果测试失败，可能需要调整搜索查询和索引。 此过程包括调整筛选器和前面讨论的其他元素。 应将测试视为迭代活动。
索引很复杂，查询性能可能因索引结构而异，这需要负载估算。 适当的负载测试可以帮助确定存储、计算和其他资源的不同 SKU，这些资源可用于支持你的要求。
必须测试所有安全控制。 例如，可将数据分区为单独的文档。 每个分区都有访问控制。 必须正确测试这些控件以保护机密性。
测试业务流程协调程序
RAG 应用程序的关键组件是中央业务流程协调程序。 此代码协调与初始用户问题相关的各种任务。 业务流程协调程序任务通常需要了解用户意向、与索引的连接来查找基础数据以及调用推理终结点。 如果代理需要执行诸如调用 REST API 之类的任务，此代码将处理上下文中的这些任务。
可以使用任何语言开发业务流程代码，也可以从头开始编写它。 但是，我们建议在 Azure AI Studio 或 Apache Airflow 的定向无环图（DAG）中使用提示流等技术来加快和简化开发过程。 提示流提供设计时体验。 使用它将任务模块化为单元，并连接每个单元的输入和输出，最终形成表示整个过程的业务流程代码。
隔离业务流程代码。 单独开发它，并将其部署为具有联机终结点和 REST API 的微服务 进行访问。 此方法可确保模块化和易于部署。
从测试的角度来看，将此代码视为任何其他代码并 执行单元测试。 但是，更重要的方面是其功能，例如其路由逻辑，可以通过功能和集成测试进行验证。 测试提示工程，以确保代码可以适当地检测用户意向和路由调用。 有多个用于测试的框架和库，例如 Scikit-learn、PyTorch 的 torch.testing 模块、FairML 用于偏差和公平性测试，以及用于模型评估的 TensorFlow 模型分析。
此外，执行运行时测试，例如故障模式测试。 例如，测试与令牌限制相关的潜在故障。
某些运行时测试可以帮助你做出决策。 运行负载测试 ，了解此代码在压力下的行为方式，并使用结果进行容量规划。 由于此代码位于体系结构中需要访问其他服务的关键位置，因此它可以帮助从所有这些调用中收集遥测数据。 此数据可以深入了解本地处理与网络调用花费的时间，并确定其他组件的行为，例如潜在的延迟。 提示流等技术具有内置的遥测功能，可促进此过程。 否则，请在自定义代码中合并遥测数据。
注意
测试此代码会产生成本影响。 例如，如果使用 Azure OpenAI 托管推理终结点，压力测试是一种常见做法，可帮助确定系统的限制。 但是，每次调用的 Azure OpenAI 费用都会产生大量压力测试费用。 优化费用的一种方法是在测试环境中使用 Azure OpenAI 的未使用的 PTU。 或者，可以模拟推理终结点。
安全问题适用于业务流程代码和模型。 包括对越狱的测试，目标是打破模型的安全性。 攻击者不会直接与模型交互。 它们首先与业务流程代码进行交互。 业务流程代码接收用户请求并对其进行分析。 如果业务流程代码收到恶意请求，它可以将该请求转发到模型，并可能危及模型。
内容安全是另一个重要方面。 在聊天机器人应用程序中，业务流程代码接收聊天文本。 在代码中， 请考虑调用内容安全服务。 同时发送用户提示和地面上下文进行分析，并接收对风险的评估。 Prompt Shields 是一个统一的 API，用于分析大型语言模型输入并检测用户提示攻击和文档攻击，这是两种常见的对抗输入类型。
安全控制和身份验证对于 RESTful 终结点至关重要 。 你需要管理身份验证并确保进行彻底的测试。
防止模型衰减
所有模型的一个常见问题是随时间推移而下降。 工作负荷内部和外部的更改最终会导致模型的质量及其输出下降。 模型衰减以两种方式发生：
输入数据发生更改时发生数据偏移 。 新的数据输入使训练的模型过期。 例如，你可能有一个模型来预测特定地理区域的投票模式，例如某个地区。 如果区域重新绘制并且该区人口的人口统计发生变化，则需要更新模型以考虑更改。
在工作负荷和模型外部的条件发生更改时，概念偏移 发生，使模型输出不再与现实匹配。 例如，可能有技术产品的销售预测模型。 如果竞争对手意外引入更高级的竞争产品，引起公众的极大关注，则需要根据消费者趋势的变化来更新模型。
如果可能，请使用自动测试来检测和评估模型的生命周期内模型衰减。 如果模型预测离散值，则可以创建测试来针对这些值评估预测，并测量预期结果与实际结果之间的偏差。 通过比较汇总统计信息和距离指标，通过监视来补充此测试，以检测偏移量。
识别模型衰减的另一种常见方法是用户反馈。 用户反馈的示例是竖起大拇指或大拇指向下响应机制。 跟踪一段时间内的正反馈与负反馈，并在满足负面反馈阈值时创建警报有助于了解何时调查模型的质量。
无论用于识别模型衰减的信号如何，对潜在衰减发出警报的操作团队都需要让数据科学家研究信号并确定衰减是否发生以及根本原因。
实现工具
使用Azure 机器学习数据收集器从部署到托管联机终结点或 Kubernetes 联机终结点的模型获取输入和输出数据的实时日志记录。 机器学习将记录的推理数据存储在 Azure Blob 存储中。 然后，可以将此数据用于模型监视、调试或审核，从而提供对已部署模型性能的可观测性。 如果将模型部署到机器学习外部或机器学习批处理终结点，则不能利用数据收集器，并且需要操作另一个数据收集过程。
使用机器学习模型监视来实现监视。 机器学习通过对流式生产推理数据和引用数据执行统计计算来获取监视信号。 参考数据可能是历史训练数据、验证数据或基准真相数据。 另一方面，生产推理数据是指在生产中收集的模型的输入和输出数据。
- 请参阅机器学习模型监视，了解机器学习的监视功能及其捕获和分析的指标。
- 有关监视的更多建议，请参阅最佳做法。