僅憑模型名稱和基準測試表，無法判斷 AI 系統是否適合真實部署。採購方需要能把訓練資料、評估條件和已知侷限與自身使用者連結起來的文件。
不同的卡片回答不同的問題
模型卡描述預期用途、架構或釋出版本識別、評估結果與侷限。資料卡紀錄資料集的建立動機、構成、收集、處理、訪問方式和負責任使用要求。Google 的《資料卡實踐手冊》（Data Cards Playbook）將資料集文件定位為負責任 AI 的透明度工具。
兩者都不應只是單頁行銷材料。有用的版本應紀錄足夠的背景，讓開發者、審查者或採購方在部署前發現不匹配之處。
詢問來源與治理情況
對資料，應檢視來源類別、同意或許可依據、時間跨度、地區和語言覆蓋範圍、敏感屬性、過濾方式及已知缺口。對模型，則應詢問哪些資料披露資訊仍適用，以及後訓練階段發生了什麼變化。
文件應列出負責人、版本日期和聯絡渠道。如果供應商無法說明各版本之間發生了什麼變化，下游團隊就無法評估迴歸風險。
把評估結果當作有條件的證據
基準測試結果取決於資料集、提示詞、評分方式、模型設定以及防止測試汙染的措施。除了最好的總體分數，還應檢視子群體和不同語言的結果、適用時的置信區間，以及失敗案例。
尋找與自身工作流程相似的任務專項測試。通用基準測試的高分，不能回答模型是否會引用你的政策、能否處理你的文件版式，或是否會拒絕未獲授權的工具操作。
讓侷限變成可執行要求
「可能產生幻覺」過於籠統。更好的文件應說明錯誤出現在哪些場景、哪些語言表現較弱、哪些輸入不受支援，以及測試過哪些改善措施，並區分模型侷限與部署層面的控制措施。
採購方應將每項相關侷限轉化為評估用例、使用限制或監控要求。如果找不到可行的控制措施，這項用途可能並不適合該產品。
維護持續更新的紀錄
將卡片關聯到不可變的模型和資料集版本。紀錄變更、已棄用的用途、新發現的風險和評估更新。歸檔舊卡片，以便調查歷史輸出。
採購要求可以包含這些欄位，而不必要求披露每項專有細節。目標是獲得足夠的證據，支援有據可依的決策與持續監督。
如何付諸實踐
先選擇一項與模型卡、資料卡及其採購用途相關、範圍明確的工作流程。在改變系統之前，寫下一頁基線紀錄：目前的完成時間、品質檢查、常見失敗類別、升級處理路徑，以及對結果負責的人。選擇有代表性的樣本，而不只挑最簡單的例子。納入普通案例、困難的邊緣案例，以及至少一個正確做法是暫停或要求補充資訊的案例。
先讓候選方案與現有流程並行執行，再考慮替換現有流程。成功和失敗的輸出都要檢查，因為整體錯誤率降低，仍可能掩蓋新的高影響故障。紀錄每次測試所用的準確設定，並保留足以讓其他審查者復現結果的材料。試點結束時，應依據事先商定的閾值決定擴大使用、調整還是停止，而不是憑事後對最佳演示的印象做決定。
向供應商或內部團隊提出的問題
詢問支撐核心主張的證據是什麼、證據對應哪些系統和資料版本，以及排除了哪些條件。索取針對部署所涉語言、輸入型別和風險類別的結果。了解變更如何通知、迴歸問題如何發現，以及客戶如何匯出事件覆盤所需的紀錄。
還要詢問置信度低、依賴項故障或請求超出支援範圍時，系統會如何處理。可靠的產品應有明確的失敗狀態，而不只是給出措辭更漂亮的回答。責任歸屬也很重要：明確誰能暫停流程、誰批准例外，以及重大錯誤流入正式環境後由誰通知受影響使用者。
實用檢查清單
- 在選擇模型或工具之前，先定義使用者任務以及真正重要的失敗情況。
- 保留一個從真實工作中抽取的小規模、帶版本識別的測試集，包含棘手及對抗性案例。
- 為每次執行紀錄模型、提示詞、工具、檢索設定、資料版本、延遲和成本。
- 對不可逆、高影響或外部可見的操作，要求人員確認。
- 按類別審查失敗，而不只看平均分，並將迴歸案例納入測試集。
Meydo Journal 延伸閱讀
主要來源
- 資料卡實踐手冊 — Google 開發者平台
