1. 問題定義

資料專案九成的失敗,不是模型不夠強,而是一開始就解錯題。問題定義(Problem Framing)是整個資料生命週期最重要的第一步,也最貴——這裡歪一度,後面全歪。

核心觀念

動手收資料之前,把三件事寫成白紙黑字:目標與指標(KPI、成功判準)、資料需求與限制(可取得性、隱私、成本)、實驗與推論需求(要不要 A/B 測試、要不要因果推論)。目標明確度越高,後續每個技術決策越有依據,吵架越少。

白話理解

零售老闆說「用 AI 提升業績」——這是願望,不是問題定義。合格版本:「三個月內,讓推薦系統把客單價提升 5%,只能用會員同意收集的消費紀錄,上線前通過 A/B 測試驗證」。目標、指標、限制、驗證方式,一句話全到位。

定義時的檢核清單

• 目標/指標:成功長什麼樣?用哪個 KPI 量?
• 資料需求:需要哪些資料?拿得到嗎?
• 限制盤點:隱私法規、取得成本、時間預算
• 實驗/推論需求先規劃:之後要做 A/B 測試或因果分析,現在就要設計收資料的方式,事後補救通常來不及
• 可行性評估:技術、資料、資源三面向都過關才立案

🎯 口訣:先問「解什麼、怎麼量、缺什麼」,再動手收資料。

iPAS 考點

考題常給一個模糊的業務需求,問「專案第一步該做什麼」——答案方向永遠是釐清目標與定義指標,不是先收資料、先選模型。陷阱選項:「立刻建模」「先擴充運算資源」。另一考法問實驗需求何時規劃,關鍵字是事前規劃,選「專案初期」而非「模型完成後」。