客戶端的轉折：資料規格書的推進

在前述低效率的流程持續了約三個月後，專案迎來了轉折。客戶團隊新加入一位協理，開始主導資料規格的協調工作。這位主管的出現，等於替專案建立了「單一窗口」與「決策權責」，讓溝通效率有了大幅提升。

首先，我們取得了舊有反洗錢模型的欄位邏輯，並據此對照新模型的需求，重新調整資料規格書的內容。接下來，會議仍維持每週兩次，但形式更聚焦：由業務單位、專案窗口與我們的資料治理團隊共同確認，哪些舊欄位邏輯可以沿用？哪些必須依照新業務規則重新定義？

經過兩個多月的持續來回，最終所有欄位都獲得確認，並正式產出了完整的資料欄位規格書。

最終的資料規格書長什麼樣子？

不同專案的資料規格書可能形式各異，但以這個專案為例，最終的文件結構大致如下：

• 特徵欄位名稱（Feature Name）：模型訓練所需的欄位，例如交易金額、交易頻率等。
• 資料型別（Data Type）：如 String、Timestamp 。
• 欄位描述（Description）：以業務語言撰寫，方便非技術人員理解。
• 業務規則（Business Rules）：欄位計算或判斷邏輯，例如「過去 30 日內平均交易金額」。
• 來源系統（Source System）：欄位原始出自的業務系統，如核心銀行系統、支付平台等。
• 來源資料表與欄位（Source Table & Column）：精確對應至資料庫中的表與欄位名稱。
• 轉換邏輯（Transformation Logic）：以 SQL 或 ETL 規則描述，例如：

CASE WHEN txn_type IN ('A','B') THEN amount ELSE 0 END

小結

回顧這段經驗，我更加確信：資料規格書是資料專案中最重要的協作工具。它不只是工程師的參考文件，更是跨部門的共同語言，幫助業務、資料治理、合規與工程團隊對齊認知。

千里之行，始於資料規格書。當規格明確，專案才能順利推進，技術方案才能正確實作，模型才能真正發揮價值。