dont-wait-perfect-data

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 (quote from the original text)

"Don't wait for perfect data to start... data doesn't need to be perfect, it just needs to be good enough to start" — p18

I — Interpretation (restate in your own words)

Chasing "perfect data" is the most common procrastination excuse in AI projects. Many teams spend months or even years on data preparation and never move into the modeling phase.

Core idea: data doesn't need to be perfect,good enoughis enough to start. Reasons:

1. AI systems are robust to noise: modern ML algorithms can handle a certain degree of noise and imperfect data.
2. Early feedback is more valuable: running a "less than perfect" model and getting real feedback is more valuable than perfecting data in the abstract.
3. Data improvement is a continuous process: after the model goes live, user feedback and the data flywheel will naturally drive improvements in data quality.
4. Perfect is the enemy of good: chasing perfect data means the project will never get started.

The right approach: define a "good enough" threshold (annotation consistency reaches 80%, covers the main scenarios, no systematic bias), start modeling once the threshold is met, and then continuously iterate on data quality.

A1 — Past Application (past application cases)

• Bing search engine: in its early days, its search data was far less abundant than Google's, but Bing did not wait until its "data caught up with Google" to start; instead, it launched with the data it had and gradually improved through user interaction. Although its data volume still lags behind Google's today, it is already a usable product — if it had waited for perfect data back then, Bing would never have launched.

A2 — Future Trigger (future trigger conditions)

Trigger scenarios：

• The team says "the data isn't ready yet," and the project can never get started
• Data cleaning work has been going on for a long time with no clear end point
• The business side demands "100% accurate data" before modeling can begin

Language signals：

• "The data isn't ready yet"
• "Let's wait a bit longer, the data isn't enough"
• "The data quality isn't good enough"
• "Let's talk about it once the data is complete"
• "Let's do data governance first"

Key distinction: when a teamdelays getting startedbecause of data quality issues, use this framework to push for "getting it in use first."

E — Execution (execution steps)

1. Define the "good enough" threshold: discuss with the AI team and clarify the minimum acceptable data quality standard (e.g., annotation consistency ≥80%, coverage of core scenarios, no systematic bias).
2. Assess the current data state: check whether the existing data has reached the "good enough" threshold.
3. If the threshold is met → start modeling immediately: do not keep waiting; train the first model with the existing data.
4. If not met → make the minimum necessary improvements: fix only the most serious problems, and start immediately once the threshold is reached.
5. Continuously iterate after launch: Continuously improve data quality through user feedback and the data flywheel.

Completion Criteria: The team started modeling as soon as the data reached the "good enough" threshold, without waiting indefinitely.

B — Boundary (Usage Boundaries)

Not Applicable Scenarios：

• Systematic bias exists in the data (e.g., the training data distribution is completely different from the real-world scenario)
• Safety-critical scenarios (healthcare, aviation — data quality is directly related to life safety)
• Fields where legal compliance requires data to be accurate

Failure Modes：

• Using "not waiting for perfection" to cover up laziness: it's not "not waiting for perfection" but "not preparing at all"
• Ignoring systematic bias: noisy data is acceptable, but systematic bias will cause the model to learn incorrect patterns
• Never going back to improve: after launching, completely forgetting about "data improvement"

Author's Blind Spot：

• Andrew Ng did not clearly define a quantitative standard for "good enough" — this needs to be judged in the context of specific business scenarios. It is recommended that teams explicitly write down "three reasons we believe the data is already good enough" before launching, to avoid subjective assumptions.

Related skills

• unified-data-warehouse — composes-with: The mindset of not waiting for perfect data and the building of a unified data warehouse complement each other — once basic data aggregation is in place, you can launch, and then continuously improve the data warehouse afterward.
• data-flywheel — composes-with: The cold-start phase of a flywheel especially requires the mindset of "not waiting for perfect data" — start the product with imperfect data first, and once the flywheel starts spinning, the data will naturally get better and better.