kangarooking Source Metadata
Original cangjie-skill frontmatter from the distillation run:
id: f18
title: "统计化验收标准 — 不追求100%准确"
book: "AI for Everyone"
author: "Andrew Ng（吴恩达）"
source: p16, p24
tags: [project-management, evaluation, acceptance-criteria, communication]
related_skills:
- slug: train-test-split, relation: depends-on
- slug: ml-workflow, relation: depends-on
- slug: iterate-not-perfect, relation: composes-with
R — Reading（原文引用）
"AI系统的一个创新点是性能通常以统计方式定义，与其要求AI系统完美执行，我们更常要求AI系统达到特定准确率" — p16
I — Interpretation（用自己的话重新阐述）
要求AI达到100%准确率是商业界最常见的误区之一。追求完美通常是不可能的，原因有三：
- ML有根本性限制：任何统计学习方法都存在不可消除的误差下限。
- 数据本身有噪声：标注错误、模糊样本、边界案例——数据本身就不完美。
- 人类专家也会分歧：对于模糊案例，不同专家给出的答案可能不同，不存在"标准答案"。
正确做法：将验收标准定义为统计目标（如"在测试集上达到95%准确率"），并认识到一个95%准确率的系统已经能创造巨大价值。关键是提前约定可接受的标准，而非事后要求完美。
A1 — Past Application（过去应用案例）
- 咖啡杯缺陷检测：95%的准确率意味着5%的缺陷产品会漏检。但这仍然非常有价值——可以配合人工抽检来兜底。如果追求100%，项目可能永远无法上线，而95%的系统已经能拦截绝大多数缺陷，大幅降低质检成本。
A2 — Future Trigger（未来触发条件）
触发场景：
- 业务方坚持"AI不能出错"
- 团队因为AI犯了几个错误就否定整个项目
- 验收时对"什么算合格"产生争议
语言信号：
- "必须100%准确"
- "零错误"
- "AI犯错了"
- "完美"
- "100%"
- "零缺陷"
区分要点：当有人（包括你自己）对AI系统提出"零错误"要求时，使用本框架来重新设定合理预期。
E — Execution（执行步骤）
- 与AI团队讨论可达成的准确率：了解在当前数据和技术条件下，合理的准确率目标是什么。
- 定义统计化验收标准：将目标量化为具体数字（如"测试集准确率≥95%"），写入项目文档。
- 接受错误必然发生：明确告知利益相关者——系统会犯错，这是正常的。
- 设计错误处理机制：为那5%的错误规划应对方案（人工复核、降级流程、用户反馈通道）。
完成标准：团队和业务方对"可接受的准确率"达成共识，并建立了错误发生时的应对方案。
B — Boundary（使用边界）
不适用场景：
- 安全关键系统（医疗诊断、自动驾驶、航空控制——这些领域错误会导致人身伤害，需要远高于95%的标准）
- 95%确实不够用的场景（如金融反欺诈，1%的漏检可能造成巨大损失）
- 法律合规要求零容忍的领域
失败模式：
- 盲目接受95%而不评估错误成本：如果每个错误的代价极高，95%可能远远不够
- 没有设计错误兜底方案：告诉业务方"会有5%错误"但没有应对措施
- 用统计标准掩盖技术不足：把"做不到"包装成"不需要做到"
作者盲区：
- Andrew Ng没有深入讨论如何将AI与人工审核结合来处理那5%的错误。在实际项目中，"AI初筛 + 人工复核"的混合模式往往是最佳实践，但书中对此着墨不多。此外，不同类型的错误（假阳性 vs 假阴性）代价不同，简单的准确率数字可能掩盖重要差异。
相关 skills
- train-test-split — depends-on：统计化验收标准需要基于独立测试集上的准确率来定义，没有正确的数据分割就无法建立可信的验收标准。
- ml-workflow — depends-on：验收标准是ML工作流中评估阶段的核心产出，需要嵌入整体工作流中理解。
- iterate-not-perfect — composes-with：接受统计化验收标准与"迭代而非完美"的理念相辅相成——先达到可接受的准确率上线，再持续迭代改进。