ML 最佳实践

1. 六阶段生命周期：不是一次性流水线

生命周期是反馈环：监控发现真实分布和业务目标变化，可能回到数据处理、问题框定，甚至重新判断 ML 是否仍值得使用。自动再训练也不代表自动发布；高风险场景通常保留评估和审批门。

官方框架：Best practices by ML lifecycle

2. 从业务目标到可训练问题

先判断 ML 是否是正确工具

• 存在可重复模式，且有足够、合法、具有代表性的历史或反馈数据。
• 输出允许概率性误差；若规则明确且必须完全确定，规则系统通常更简单。
• 预测能够触发可执行的业务动作，而不只是生成一个没人使用的分数。
• 模型带来的增量价值能覆盖数据、开发、推理、监控和治理的总成本。

用四层指标防止“优化错目标”

考试判断：“最佳模型”不是分数最高的模型，而是在业务、技术、风险和成本约束下满足发布条件的模型。

3. 端到端架构应保留四条链

模块化的数据、训练、评估和部署步骤应有清晰输入输出，并通过版本与 lineage 连接。Feature Store 可减少训练/服务特征不一致，Model Registry 管理候选模型与批准状态，Pipelines 编排可复现步骤，但每项能力都需要 IAM、加密、监控和生命周期策略配套。

4. Well-Architected 六支柱在 ML 中问什么

同一个设计通常影响多支柱。例如训练 Spot 降低成本和资源浪费，但必须 checkpoint 才能保持可靠性；增加超大实例可能降低单次延迟，却提高成本与环境负担。题目问“最符合要求”时要识别它优先优化哪个约束。

5. ML 设计原则

• 明确所有权：业务、数据、模型、平台、安全和风险角色拥有清晰决策权与升级路径。
• 提供保护：保护数据、算法、训练环境、模型工件和推理接口，并验证供应链。
• 支持韧性：通过版本、lineage、解释、备份、回滚和可降级方案恢复服务。
• 支持复用：把特征、容器、pipeline step 和评估模板做成有契约的独立组件。
• 自动化并保留控制点：自动构建、测试和证据收集；把审批放在风险要求的位置。
• 持续观测：同时监控基础设施、数据质量、模型质量、偏差和业务 KPI。

官方来源：Well-Architected ML design principles

6. Responsible AI：把风险变成可测试要求

AWS 当前 Responsible AI Lens 分列十个维度；较早材料常把“隐私与安全”“真实性与鲁棒性”各合并，因此会看到八组表述。概念没有冲突，考试时按题干语义选择措施。

关键区别：公平性看群体影响；可解释性解释行为；透明度向利益相关者披露能力与限制；治理确保组织持续执行这些要求。

当前定义：AWS Well-Architected Responsible AI Lens

7. AWS 工具不是维度本身，而是控制措施

延伸阅读：SageMaker Clarify · SageMaker Model Cards

8. 发布条件必须可判定

“模型表现不错”无法作为质量门。有效发布条件包含指标、阈值、评估数据、置信要求、责任人和失败动作，例如：

• 在锁定的时间外测试集上，PR-AUC ≥ 0.82，且关键群体 recall 均 ≥ 0.75。
• 生产形态负载测试中 p99 延迟 ≤ 150 ms，5XX 比例低于阈值。
• 安全、隐私、偏差、解释和鲁棒性测试完成，无未接受的高严重度风险。
• 模型、镜像、特征转换和依赖均可追踪；Model Registry 状态已批准。
• canary alarm 触发时自动回滚，且有人工升级与停用流程。

上线后继续比较业务 KPI、模型质量、分群影响和系统 SLO。只有在新数据通过质量与评估门后才进入发布；不要把“检测到漂移”直接等同于“立刻自动部署新模型”。

官方方法：Responsible AI release criteria

9. 高频反模式

10. 场景题的十问检查表

1. 业务动作和 KPI 是什么，当前非 ML 基线是什么？
2. 这是分类、回归、排序、聚类还是生成任务？ML 真的是必要的吗？
3. 哪种错误最贵，哪个模型指标能反映它？
4. 训练数据是否代表生产，是否存在泄漏、偏差、许可或隐私问题？
5. 延迟、吞吐、可用性、成本和 Region 有什么硬约束？
6. 哪个 Responsible AI 维度正面临风险？
7. 需要什么证据，以及哪个 AWS 能力收集它？
8. 谁批准模型，发布门槛能否明确判定？
9. 如何逐步发布、告警、回滚或降级？
10. 何时监控、再训练、重新框定或停用模型？

答题时先圈出“必须”“最低运维”“最具成本效益”“近实时”“可审计”等约束，再用这十问排除只解决局部问题的选项。