手册

需要一个集中式协作平台来管理整个机器学习生命周期，从数据准备到部署和监控。

→Azure 机器学习工作区。

原因: 它是集成所有必需组件的基础服务：计算、数据存储、环境、实验跟踪、模型注册表和终结点。

参考↗

要求所有 ML 工作区流量，包括流向 Storage 和 ACR 等依赖资源的流量，都保留在 Azure 私有网络上，并且不暴露给公共 Internet。

→为 Azure ML 工作区配置托管虚拟网络，并为工作区及其所有依赖资源（Storage、Key Vault、ACR）使用私有终结点。

原因: 私有终结点为 Azure 服务提供安全、私密的连接，确保流量不经过公共 Internet。托管 VNet 简化了 ML 计算的此配置。

参考↗

ML 解决方案必须符合严格的数据驻留规则，确保所有数据和计算都保留在特定地理区域（例如，欧盟）内。

→在所需地理区域内的某个区域中创建 Azure ML 工作区、所有关联的存储帐户和计算资源。使用网络隔离来防止数据泄露。

原因: Azure 资源绑定到其创建的区域。这确保了物理数据位置合规性。网络隔离（托管 VNet）可防止数据在此边界之外进行处理。

在所有 ML 工作区中强制执行组织标准，例如要求成本分配标签、限制 VM 大小或强制执行诊断日志传输。

→使用 Azure Policy 应用和强制执行资源创建和配置规则。

原因: Azure Policy 提供可扩展的集中式治理。它可防止创建不合规的资源，确保无需手动监督即可实现一致的标准。

参考↗

从 ML 工作区访问 Azure Storage 中的数据，而无需在代码或配置中存储凭据（帐户密钥、SAS 令牌）。

→使用基于身份的身份验证创建数据存储连接。向工作区的托管标识（或用户/计算标识）授予存储帐户上适当的 RBAC 角色（例如，Storage Blob Data Reader）。

原因: 这是一种无需凭据、零信任的模式，它使用 Azure AD 进行身份验证，从而提高安全性并简化凭据管理。

多个团队在具有不同安全级别（例如，PII 数据与匿名数据）的项目上工作。需要提供资源隔离。

→为每个安全边界创建单独的 Azure ML 工作区。用于 PII 项目的工作区应比用于非敏感项目的工作区具有更严格的网络隔离。

原因: 工作区是主要的安全性与隔离边界。按安全级别进行隔离是防止数据泄露和应用适当控制的最佳实践。

需要将开发/实验活动与生产级模型训练和部署分开，以防止干扰并确保稳定性。

→为开发和生产环境使用单独的 Azure ML 工作区。

原因: 这将生产资源、数据和模型与实验工作隔离开来，为生产 MLOps 管道提供稳定性和明确的治理。

为间歇性运行的 ML 训练作业预配计算资源，并高度优先考虑最小化成本。

→使用具有低优先级 VM、最小节点计数为 0 且配置了自动缩放的 Azure ML 计算群集。

原因: 低优先级 VM 为可中断的工作负载提供显著的成本节约。最少 0 个节点可确保群集空闲时无需付费。

参考↗

需要为数据科学家进行的交互式笔记本开发以及运行大型无人值守训练作业预配计算资源。

→为交互式开发预配计算实例（每个用户一个）。为批处理训练作业预配计算群集。

原因: 计算实例是单用户、持久性 VM，针对交互式工作进行了优化。计算群集是自动缩放的多节点资源，针对批处理作业进行了优化。

通过捕获所有软件依赖项，包括特定的 Python 包版本，确保 ML 训练运行可重现。

→使用 conda 环境 YAML 文件或 Dockerfile 定义 Azure ML 环境。注册此环境并对其进行版本控制，以用于训练作业。

原因: 环境是运行时的版本化、可重用规范。这使环境与计算分离，确保使用该环境版本的任何运行都是相同的。

特征工程逻辑在训练和推理之间需要保持一致，并且特征应在多个模型和团队之间可重用。

→使用 Azure ML 托管特征存储来定义、计算和提供特征。

原因: 特征存储可确保一致性（防止训练-服务偏差），支持特征发现和重用，并提供离线（用于训练）和在线（用于低延迟推理）存储。

系统地跟踪所有 ML 实验，包括代码版本、超参数、指标和模型 artifact，以便进行比较和重现。

→使用本机集成到 Azure ML 中的 MLflow。启用自动日志记录或在训练脚本中使用显式 `mlflow.log_*` 命令。

原因: MLflow 提供了一个标准化、开源的实验跟踪框架。Azure ML 充当托管的 MLflow 跟踪服务器，提供用于比较运行的 UI。

参考↗

在具有严重类别不平衡（例如，欺诈检测）的数据集上训练分类模型，导致在少数类别上性能不佳。

→对训练数据应用 SMOTE（合成少数过采样技术）等技术。使用对不平衡不敏感的指标（例如 Precision-Recall AUC 或 F1 分数）评估模型。

原因: 仅仅使用准确率是具有误导性的。SMOTE 创建合成少数样本以帮助模型学习，并且 PR-AUC/F1 分数正确衡量了正类别上的性能。

需要为训练时间长且计算预算有限的模型找到最佳超参数。

→使用带有贝叶斯采样和早期终止策略（例如，Bandit 或 Median Stopping）的 sweep job。

原因: 贝叶斯采样智能地探索搜索空间，专注于有前景的区域。早期终止可提前停止性能不佳的运行，从而节省大量的计算时间和成本。

使用 AutoML 构建时间序列预测模型。

→使用 `task='forecasting'` 配置 AutoML 作业，指定 `time_column_name`，并设置 `forecast_horizon`。

原因: 将任务指定为“forecasting”使 AutoML 能够应用时间序列特定的技术，例如滞后特征生成、季节性检测和时间感知交叉验证。

在多个计算节点上使用多个 GPU 训练大型深度学习模型，以减少训练时间。

→使用带有 GPU 节点的计算群集。在命令作业中，配置 `distribution` 属性（例如，`type: "PyTorch"`，`process_count_per_instance: <GPU 数量>`）。

原因: Azure ML 通过管理节点设置和通信来简化分布式训练。`distribution` 配置告诉 Azure ML 如何启动分布式训练进程。

参考↗

自动化一个多步骤 ML 工作流（例如，数据准备、训练、评估），该工作流可以使用不同的参数进行重用。

→使用组件为每个步骤定义 Azure ML 管道。使用管道输入来参数化工作流。

原因: 基于组件的管道促进了模块化和可重用性。它们还支持自动步骤缓存（重用），通过不重新运行输入未更改的步骤来节省时间。

模型在训练集上表现非常好，但在验证集上表现不佳，表现为训练损失曲线和验证损失曲线发散。

→这是过拟合的典型迹象。通过应用正则化（例如，dropout，L2）、使用数据增强、实施早期停止或降低模型复杂度来缓解。

原因: 训练和验证性能之间的差距表明模型已经记住了训练数据，而不是泛化。正则化技术惩罚复杂性以提高泛化能力。

在低优先级（spot）VM 上运行的长时间训练作业有被抢占并丢失进度的风险。

→在训练脚本中实现检查点，以定期将模型和优化器状态保存到 `./outputs` 目录。

原因: `./outputs` 目录由 Azure ML 自动持久化。保存检查点允许作业在被抢占时从上次保存的状态恢复，从而保留进度并节省成本。

组织有政策规定，在生产中只能使用某些 ML 算法。需要在 AutoML 运行期间强制执行此政策。

→在 AutoML 配置中，使用 `blocked_models` 参数从搜索空间中明确排除未经批准的算法。

原因: 这提供了一种直接、可强制执行的方法，使 AutoML 与治理策略保持一致，从而防止选择不合规的模型。

部署一个用于实时、低延迟（<100 毫秒）预测且具有高可用性的模型。

→将模型部署到 Azure ML 托管在线终结点。

原因: 托管在线终结点是一种完全托管的服务，针对实时推理进行了优化，提供自动缩放、负载均衡、蓝绿部署和内置监控。

参考↗

以异步方式对大量数据（数百万条记录）进行评分，并优先考虑成本效率。

→将模型部署到 Azure ML 批处理终结点。

原因: 批处理终结点专为大数据集的高吞吐量、异步评分而设计。它们可以使用可扩展的计算群集，在空闲时缩减到零，从而优化成本。

在最小化风险的同时部署新的模型版本。需要逐步将流量转移到新版本并允许轻松回滚。

→使用一个托管在线终结点，其中包含两个部署（例如，旧模型的“蓝色”，新模型的“绿色”）。使用流量拆分来控制每个部署的请求百分比。

原因: 这种蓝绿部署模式允许安全、零停机时间的发布。您可以在将新模型完全切换之前，在少量实时流量上验证新模型。

以标准化、与框架无关的方式打包模型及其依赖项和 artifact，以进行部署。

→使用 MLflow 模型格式。注册模型时，包括 conda.yaml 或 requirements.txt 文件以及任何必要的代码 artifact。

原因: MLflow 提供了一种 Azure ML 本机理解的标准模型打包约定。这简化了部署，因为 Azure ML 可以自动构建所需的环境。

由于部署的模型在每次预测请求时都加载大型辅助文件（例如，大型特征提取器），因此具有高延迟。

→将文件加载逻辑从评分脚本中的 `run()` 函数移动到 `init()` 函数。

原因: `init()` 函数在容器启动时只运行一次。在此处加载资产可使其对所有 `run()` 调用全局可用，从而避免在每个请求上进行冗余加载。

实时终结点遇到可变流量（高 Jozef、低谷）。需要经济高效地保持性能。

→在托管在线终结点部署上配置自动缩放。设置最小和最大实例数，并根据 CPU 利用率或请求延迟定义缩放规则。

原因: 自动缩放会自动调整计算实例的数量以匹配流量负载，确保高峰期的性能并在低谷期节省成本。

模型部署需要特定的系统库、自定义 CUDA 版本或默认 Azure ML 映像中不存在的自定义推理服务器。

→创建一个自定义 Dockerfile，扩展 Azure ML 基础推理映像，添加所需的依赖项，构建它，并将其推送到 Azure Container Registry。在部署环境中引用此映像。

原因: 扩展基础映像可提供对运行时环境的完全控制，同时保持与 Azure ML 服务基础结构的兼容性。

自动化端到端 ML 生命周期，包括由代码或数据更改触发的再训练、评估和部署。

→使用与 Azure ML CLI v2 集成的 Azure DevOps 或 GitHub Actions 创建 CI/CD 管道。该管道应包含一个质量门，用于在部署之前将新模型与基线进行比较。

原因: 此 MLOps 模式自动化了 ML 工作流，确保了一致性、质量和快速迭代。质量门可防止模型性能退化。

由于输入数据分布的变化，生产模型的性能正在下降。当检测到显著的数据漂移时，需要自动重新训练模型。

→在终结点上配置 Azure ML 数据漂移监视器。设置一个警报，触发 Azure Logic App 或 Azure Function，进而启动再训练管道。

原因: 这创建了一个闭环 MLOps 系统，可根据不断变化的数据模式自动维护模型的相关性，而无需人工干预。

在生产中发现新部署的模型版本存在故障。需要快速恢复到以前的稳定版本。

→如果使用蓝绿部署，将 100% 的流量转移回稳定部署。或者，更新终结点以从模型注册表重新部署以前的模型版本。

原因: 流量转移提供即时回滚。从注册表重新部署版本也是恢复已知良好状态的快速可靠方法。

需要监控已部署模型的操作健康状况（延迟、错误）和预测质量（数据漂移、准确性）。

→为操作指标在终结点上启用 Application Insights 集成。为模型质量指标配置 Azure ML 数据收集和数据漂移监控。

原因: 这种双管齐下的方法提供了模型健康状况的完整视图。App Insights 跟踪系统性能，而数据收集/漂移监控跟踪模型的预测性能。

由于客户端的输入数据格式错误或出乎意料，模型终结点正在失败。

→在评分脚本的 `run()` 函数中实现输入验证逻辑。检查数据类型、范围和结构，并为无效请求返回有意义的错误（例如，HTTP 400）。

原因: 服务器端验证可保护模型免于崩溃，并向 API 使用者提供清晰、即时的反馈，从而使服务更加健壮。

需要了解复杂“黑盒”模型做出某些预测的原因，以便进行调试、合规性或利益相关者信任。

→使用 Azure ML 中的 Responsible AI 仪表板生成模型解释。使用 SHAP 进行局部（单个预测）解释，并使用全局特征重要性了解整体模型行为。

原因: SHAP 值提供了一种稳健、与模型无关的方法，用于说明每个特征对特定预测的影响，这对于监管和调试场景至关重要。

用于贷款审批等决策的模型必须公平，不得歧视受保护的人口群体。

→使用 Responsible AI 仪表板的公平性评估来分析敏感特征的公平性指标（例如，人口统计学平等、均衡赔率）。如果发现差异，应用后处理阈值调整等缓解技术。

原因: 公平性评估提供了模型在不同群体中行为的量化证据。缓解技术有助于纠正偏差，以确保公平的结果。

LLM 需要根据特定的私人公司文档回答问题，而不会产生幻觉事实。

→实现检索增强生成（RAG）模式。使用 Azure AI Search 创建文档的向量索引。在查询时，检索相关的文档块并将其作为上下文传递给 LLM。

原因: RAG 将 LLM 的响应基于事实、最新的信息，显著减少幻觉，并使其能够使用其原始训练数据中没有的知识。

LLM 必须始终遵循特定的指南、语调和输出格式（例如，生成 JSON）。

→使用详细的系统提示工程。提供清晰的角色、明确的规则和约束，以及期望的输入/输出对的少量示例。

原因: 精心设计的系统提示是引导 LLM 行为最直接有效的方法，而无需微调的成本和复杂性。

需要衡量基于 RAG 的 LLM 应用程序的质量。

→使用 RAG 特定的评估指标，例如 Groundedness（答案是否由上下文支持？）和 Relevance（答案是否解决了用户的问题？）。

原因: ROUGE 等标准 NLP 指标是不够的。groundedness 和 relevance 直接衡量 RAG 的核心挑战：防止幻觉并提供有用的答案。

LLM 应用程序对于生产使用来说太慢或太昂贵。

→实施路由器以将更小、更便宜的模型（例如，GPT-3.5-Turbo）用于简单任务。为重复查询启用响应缓存。优化提示长度。

原因: 为任务使用合适大小的模型是最有效的成本节约措施。缓存消除了冗余 API 调用，直接降低了成本和延迟。

LLM 应用程序处理敏感数据，这些数据不得离开公司网络或用于模型训练。

→使用私有终结点部署 Azure OpenAI 服务。配置资源以不记录提示/完成数据。

原因: 私有终结点确保网络隔离。无日志记录选项提供了额外的数据隐私层，满足严格的合规性要求。

在 Azure AI Studio 中开发的提示流需要部署为高可用、可扩展的生产终结点。

→将提示流部署为 Azure ML 托管在线终结点。

原因: 这提供了从开发到生产的无缝路径，利用与传统 ML 模型相同的强大基础架构（自动缩放、负载均衡、监控）用于传统 ML 模型。

面向用户的生成式 AI 应用程序必须防止生成或处理有害、冒犯或不安全的内容。

→同时使用内置的 Azure OpenAI 内容筛选器和 Azure AI 内容安全服务，对提示和完成进行深度防御式审核。

原因: 分层安全至关重要。内置筛选器提供了基线，而专用的内容安全服务则提供更精细的控制和多模态功能。

对话式 AI 聊天机器人需要在多个用户轮次中保持上下文。

→LLM 是无状态的。应用程序必须管理对话历史记录（例如，在会话或数据库中），并在每次向 LLM 发送新提示时包含历史记录的相关部分。

原因: 在每次 API 调用中显式提供上下文是无状态 LLM“记住”对话的唯一方法。

需要系统地测试不同的提示，以找到能产生最佳 LLM 性能的提示。

→使用提示流变体。为节点定义多个提示版本，并针对评估数据集运行批量测试以比较性能指标。

原因: 变体为提示工程提供了一种结构化、数据驱动的方法，超越了手动试错，实现了系统优化。

需要监控生产 LLM 应用程序的操作健康状况和响应质量。

→将 Application Insights 用于操作遥测（延迟、错误率、token 使用量）与使用评估流的周期性批量评估作业相结合，以评估响应质量（groundedness、relevance）。

原因: LLM 监控需要跟踪系统性能和生成内容的质量。这种组合提供了应用程序健康状况的整体视图。