kangarooking Source Metadata
Original cangjie-skill frontmatter from the distillation run:
id: f22
title: "不等完美数据 — 先用起来再迭代"
book: "AI for Everyone"
author: "Andrew Ng（吴恩达）"
source: p18, p20
tags: [data-strategy, execution, iteration, pragmatism]
related_skills:
- slug: unified-data-warehouse, relation: composes-with
- slug: data-flywheel, relation: composes-with
R — Reading（原文引用）
"不要等待完美的数据才开始...数据不需要完美，只要足够好就可以开始" — p18
I — Interpretation（用自己的话重新阐述）
追求"完美数据"是AI项目最常见的拖延借口。很多团队花了数月甚至数年在数据准备上，迟迟不进入建模阶段。
核心理念：数据不需要完美，足够好就可以开始。原因：
- AI系统对噪声有鲁棒性：现代ML算法可以处理一定程度的噪声和不完美数据。
- 早期反馈更有价值：用一个"不够完美"的模型跑起来，获得的真实反馈比在空想中完善数据更有价值。
- 数据改进是持续过程：模型上线后，用户反馈和数据飞轮会自然推动数据质量的提升。
- 完美是好的敌人：追求完美数据会导致项目永远无法启动。
正确做法：定义"足够好"的门槛（标注一致性达到80%、覆盖主要场景、没有系统性偏差），达到门槛就开始建模，后续持续迭代数据质量。
A1 — Past Application（过去应用案例）
- Bing搜索引擎：早期搜索数据远不如Google丰富，但Bing没有等到"数据赶上Google"才开始，而是用现有数据启动，通过用户交互逐步改进。虽然至今数据量仍不如Google，但已经是一个可用的产品——如果当年等待完美数据，Bing永远不会上线。
A2 — Future Trigger（未来触发条件）
触发场景：
- 团队说"数据还没准备好"，项目一直无法启动
- 数据清洗工作已经持续了很长时间但没有明确终点
- 业务方要求"数据100%准确"才能开始建模
语言信号：
- "数据还没准备好"
- "再等等，数据还不够"
- "数据质量不行"
- "等数据完善了再说"
- "先做数据治理"
区分要点：当团队因为数据质量问题而推迟启动时，使用本框架来推动"先用起来"。
E — Execution（执行步骤）
- 定义"足够好"的门槛：与AI团队协商，明确数据质量的最低可接受标准（如标注一致性≥80%、覆盖核心场景、无系统性偏差）。
- 评估当前数据状态：检查现有数据是否已达到"足够好"的门槛。
- 如果达到门槛 → 立即开始建模：不要继续等待，用现有数据训练第一个模型。
- 如果未达到 → 做最小必要改进：只修复最严重的问题，达到门槛后立即开始。
- 上线后持续迭代：通过用户反馈和数据飞轮持续改进数据质量。
完成标准：团队在数据达到"足够好"门槛后立即启动了建模工作，没有无期限等待。
B — Boundary（使用边界）
不适用场景：
- 数据存在系统性偏差（如训练数据与真实场景分布完全不同）
- 安全关键场景（医疗、航空——数据质量直接关系生命安全）
- 法律合规要求数据必须准确的领域
失败模式：
- 用"不等完美"掩盖懒惰：不是"不等完美"而是"完全不准备"
- 忽视系统性偏差：数据有噪声可以接受，但系统性偏差会导致模型学到错误规律
- 永远不回头改进：启动后就把"数据改进"忘得一干二净
作者盲区：
- Andrew Ng没有明确定义"足够好"的量化标准——这需要结合具体业务场景来判断。建议团队在启动前明确写出"我们认为数据已经足够好的三个理由"，避免主观臆断。
相关 skills
- unified-data-warehouse — composes-with：不等完美数据的心态与统一数据仓库的建设相辅相成——先有基本的数据汇聚就能启动，后续持续完善数据仓库。
- data-flywheel — composes-with：飞轮冷启动阶段特别需要"不等完美数据"的心态——先用不完美的数据启动产品，飞轮转起来后数据自然越来越好。