導入 AI 之前，大多數團隊準備的是規格書和 Use Case。但這些東西，AI 其實看不懂。
有一次我去跟 BU 說，我們這個專案需要建立一份 Golden Dataset，請他們協助提供標註好的歷史資料。
對方愣了一下，然後說：「這樣很麻煩耶，我們以前做系統的時候，給工程師幾個範例 case 不就好了嗎？」
這句話我聽過很多次。它背後反映的是一個很常見的認知落差，大家以為 Golden Dataset 只是「比較多的 Use Case」，但其實這兩件事的本質完全不同。
Use Case 和 Golden Dataset，根本是兩回事
傳統開發裡Use Case 是給工程師看的，它的目的是讓工程師理解業務邏輯，這個功能在什麼情境下會被觸發、使用者的操作流程是什麼、預期的系統行為是什麼、資料的樣態是什麼等等。本質上，Use Case 是一份給人讀的需求說明，縮短業務邏輯和開發中間的gap。
Golden Dataset 完全不一樣，它不是給人讀的，是給模型學習的。它的內容是大量真實的輸入資料，加上由業務專家人工標註過每一筆資料對應的正確答案。模型透過這份資料集學習「什麼樣的輸入應該對應什麼樣的輸出」，而不是透過你寫的規則去推論。
換句話說：Use Case 定義的是需求，Golden Dataset 定義的是答案。你可以沒有完整的規格書，但你不能沒有 Golden Dataset，因為沒有它，模型根本不知道什麼叫做「對」。
為什麼一定要由業務專家來標註？
這是我在推動 Golden Dataset 建立時最常遇到的阻力，BU 覺得標註資料是技術團隊的事，或是覺得這件事可以外包給不熟悉業務的人來做。
但這個認知是錯的，而且錯得很關鍵。
標註資料不是機械性的分類工作。標註的過程，本質上是在定義業務邏輯。當業務專家看著一筆資料，判斷它應該被標為類別 A 還是類別 B，他做的不只是貼標籤，他是在把自己腦袋裡多年累積的業務判斷，轉化成模型可以學習的訊號。
如果這個工作交給不懂業務的人來做，標出來的答案就會有偏差，模型學到的就是錯誤的邏輯。更糟的是，這種偏差很難被發現，因為模型的輸出看起來「好像還好」，但在真正重要的邊緣案例上會頻繁出錯。等到專案上線之後才發現問題，要回頭重新標註、重新訓練，成本遠比一開始就做對高得多。
所以當 BU 問「為什麼要我們自己來標」，我通常會這樣回答：「因為只有你們知道什麼才是正確答案。這份資料集，是你們業務知識的數位化，不是技術工作。」
什麼才叫做好的 Golden Dataset？
光是「有標註資料」還不夠，標註的品質和結構決定了模型能學到什麼。幾個實務上的具體指標：
