ML 系统上线前的设计审计五问

大多数 ML 失败并非模型本身的失败，而是设计上的失败——而且只要知道往哪里看，几乎总能在上线前被发现。

没人检查过的训练-服务偏差。评估集与生产环境不符。反馈循环会悄悄污染下一次重训练。成本和延迟预算没人记录。我见过这些因素毁掉过拥有完美模型的系统。在 19+ 年的软件交付和 AI 研究评审经验后，我现在对每个 ML 设计都进行同样的五道关卡审查后才让它上线。下面就是这套流程。

Gate 1：数据——溯源、泄漏、漂移

问三个问题。每个训练样本从何而来，你能证明吗？未来信息或测试集中的信息有没有可能泄漏到训练中？当真实世界偏离训练分布时会发生什么？

这里典型的杀手是评估泄漏：那个"准确率 99%"的分类器在上线第一天就失效了，因为评估集是从训练数据中意外抽取的。这种事发生得比任何人承认的都多。要把书面数据溯源声明和泄漏检查作为合并（merge）前置条件，而不是可选项。

Gate 2：评估——指标是否匹配任务？

模型可以在指标上拿到高分，却仍然无法完成它的工作。当生产决策对不同方向的错误有不同的成本时，离线准确率毫无意义——一个针对准确率优化的欺诈模型，在欺诈罕见时会乐意批准所有交易。

对于每个模型，写下：模型实际驱动什么决策，每种方向的错误成本是多少，我们的评估集是否像生产流量？如果答案模糊，设计就没准备好。

Gate 3：运营——延迟、成本、降级

直到第一个用户投诉，才有人记录延迟预算。直到第一张云账单，才有人计算预测成本。对于每个模型，记录：p95 延迟预算、预期容量下每 1,000 次预测的成本，以及模型宕机或太慢时会发生什么。"页面崩了"不是降级策略——缓存最后一次好的预测、降级到更简单的模型，或者明确地快速失败。

对于 Agentic 系统，这个关卡重要 10 倍：每个不必要的工具调用都在燃烧 token 并膨胀每个下游上下文窗口。成本纪律始于调用纪律。

Gate 4：安全——对抗性输入与访问控制

谁能向这个模型输入内容，他们能让它做什么？覆盖基础项：输入验证、速率限制、模型端点及其训练数据的访问控制。对于 LLM 支持的系统，添加 prompt 注入审查——把 Agent 可以调用的每个工具视为一种特权，按特权的方式限制其作用域。我把 Agent 建模为 IAM 主体：唯一身份、最小权限角色、会话范围的凭证。

Gate 5：问责制——谁对决策负责？

当模型出错时——它会的——谁负责，修复路径是什么？每个生产 ML 系统都需要指定负责人、回滚计划，以及对已知故障模式的书面策略。"模型决定的"不是问责结构。

把这五个关卡转化为团队在设计评审时填写的一页纸：

Data: provenance documented? leakage check passed? drift monitors planned?

Evaluation: metric matches the mission? eval set production-representative?

Operations: latency budget, cost per prediction, fallback behavior defined?

Security: inputs validated? access scoped? agent tools least-privilege?

Accountability: named owner? rollback plan? known failure modes written down?

任何空白答案都阻止上线。这只需要一小时，但能捕获那些在复盘中总被描述为"事后看来显而易见"的失败。

Karmendra Pandey 是 TEKsystems AI & ML 部门的 Practice Architect。他在 AWS 上构建生产代理 AI 系统，并在 PREreview 上对 AI 研究进行同行评审。