「乾淨資料」不是絕對狀態。同一份 dataset 可能足以分析全國趨勢，卻完全不能做街道層級 routing。CS 513 最重要的起點因此是 fitness for use：資料品質要依它支援的 decision、operation 或 question 判斷。
把分析問題變成品質契約
假設問題是：
Restaurant menu 的數量如何隨 city 與 decade 改變？
這句話已經隱含要求：
| 必要欄位 | 品質條件 | 原因 |
|---|---|---|
| City | 同一城市映射到同一 canonical value | 否則 group 會碎裂 |
| Date | 可 parse，且在 collection 時間範圍內 | 才能推 decade |
| Record identity | 沒有 accidental duplicate | 否則 count 膨脹 |
| Provenance | 推測出的 city 必須標記 | 才能理解不確定性 |
Price、page count 或 dish description 即使很亂，也未必阻礙這個問題。先清它們只是花成本，沒有提升本次 use 的 fitness。
白話來說： 先決定要使用哪個房間，再決定哪些地方值得打掃。
品質有不同維度
- Accuracy： 是否符合現實？
- Completeness： 必要值是否存在？
- Consistency： 相關值是否遵守同一規則？
- Validity： 是否符合 format 或 domain？
- Uniqueness： 同一真實 entity 是否只出現一次？
- Timeliness： 對當前決策是否夠新？
這些維度可能衝突。替所有 missing value 補值，看起來提高 completeness，卻可能降低 accuracy；丟掉所有不確定 row，survivor 的 validity 變好，dataset 卻可能失去代表性。
兩邊成本都要算
低品質資料會造成搜尋、重工、錯誤決策、信任下降與維護成本；cleaning 本身也需要工程時間、人工 review、compute，甚至會丟失資訊。
可以用簡單的優先級思路：
priority ≈ defect probability
× impact on intended use
× affected consumers它不是通用公式，目的只是逼自己說明：為什麼先修這個問題，而不是另一個。
Prevention、detection、repair 是不同投資
| 階段 | 例子 | 典型優點 |
|---|---|---|
| Prevent | Database constraint、受控輸入 | 提早阻止壞狀態 |
| Detect | Profile、validation query、anomaly report | 找出既有問題 |
| Repair | Canonical mapping、人工確認修正 | 讓資料重新可用 |
能控制 data entry 時，prevention 通常比反覆 repair 便宜；接手 historical data 時，detection 與可追蹤 repair 則不可避免。
「夠好」也要有證據
品質聲明至少要說清楚：
- intended use；
- scope 內的 field 與 population；
- 使用的 rule 或 metric；
- 已知 exception 與 coverage 缺口；
- assessment 的版本與時間。
只說「96% accurate」沒有太大意義，除非同時說明測了哪些值、ground truth 怎麼來，以及 sample 是否代表真正需要 repair 的 row。
複習卡
- 資料品質是對明確 use 的 fitness。
- 把 intended query 轉成 field-level requirement。
- Accuracy、completeness、consistency、validity、uniqueness、timeliness 各自不同。
- Cleaning 可能用一個維度交換另一個。
- 依 likelihood、impact 與 reach 排 defect 優先級。
- 品質聲明需要 scope、method、exception 與 provenance。