Back to blog
    什麼是 AI 模型卡?以及為何 EU AI Act 使其成為強制性的
    model-cardai-governanceeu-ai-actmodel-documentationresponsible-ai

    什麼是 AI 模型卡?以及為何 EU AI Act 使其成為強制性的

    模型卡記錄了 AI 系統是在什麼上訓練的、它擅長什麼、在哪裡失敗,以及與誰一起測試。EU AI Act 的附件四使這種文件記錄成為法律要求。

    EErtas Team·

    模型卡是描述 AI 模型的結構化文件——它被設計來做什麼、如何訓練的、使用了什麼資料、在不同群體和任務中的性能如何,以及已知的局限性是什麼。

    這個概念是由 Margaret Mitchell 和 Google 的同事在 2019 年的一篇論文中提出的。在此後的七年裡,模型卡從學術提案演變為行業實踐,再到在歐盟成為法律要求。本文解釋了模型卡包含什麼、為什麼它在操作上很重要,以及 EU AI Act 附件四對在受監管環境中部署 AI 的組織意味著什麼。

    為什麼模型卡在操作上很重要

    模型卡的合規案例是真實的,但操作案例更直接地令人信服。

    訓練模型的 ML 工程師在 18 個月後就不在了。提供模型的供應商可能在 3 年後就不在了。部署模型的業務背景將會演變。當事情出錯時——或者當某人需要稽核、更新或替換模型時——在訓練時存在的機構知識將消失。

    模型卡是允許某人在不從頭開始的情況下理解模型的機構記憶。它回答了事件調查或合規稽核將提出的問題:這個模型是在什麼上訓練的?它是針對哪個群體評估的?識別了什麼失敗模式?原始團隊對這個模型應該和不應該在哪裡使用了解什麼?

    沒有模型卡,這些問題通過重建來回答——這需要時間,是不完整的,如果原始團隊不再可用,可能是不可能的。有了模型卡,它們在幾分鐘內就能得到回答。

    模型卡應包含什麼

    1. 模型詳細資訊

    名稱、版本、模型類型(分類、回歸、生成等)、擁有的團隊或組織、訓練日期、上次更新日期、許可證、負責任團隊的聯繫資訊。

    這是標題資訊,允許某人識別他們在看什麼以及打電話給誰。

    2. 預期用途

    模型被設計來做什麼。它明確不是被設計來做什麼。預期用戶是誰。模型被設計用於什麼部署環境。

    「不是設計來做」的部分與預期用途同樣重要。一個被設計來幫助客戶服務代理的模型不是被設計來做出自主決定的。一個在英語輸入上訓練的模型不是被設計用於多語言部署的。記錄明確的排除減少了不適當部署的可能性。

    3. 訓練資料

    源資料集、涵蓋的日期範圍、應用的預處理和清洗步驟、訓練資料中已知的偏見或差距、訓練集總大小。

    這一部分是任何對模型行為原因的下游分析的基礎。如果模型表現出偏見,調查將從這裡開始。如果模型在特定群體上表現不佳,訓練資料部分將顯示該群體是否有代表性。

    4. 評估資料

    使用了什麼資料集來評估模型。評估資料如何收集,以及它與訓練資料有何不同。使用這些特定評估集的理由。

    評估資料和訓練資料不應該完全相同——僅在其訓練分布上評估的模型對其在生產中的表現幾乎沒有說明。記錄差距。

    5. 性能指標

    準確率、精確率、召回率、F1、AUC,或與模型任務相關的任何指標。這些應在評估集上報告,而不是訓練集。

    關鍵點:性能指標應按人口統計群體、地理區域或與使用場景相關的其他細分進行分解。整體準確率為 94% 的模型可能對特定人口統計群體的準確率為 82%。單獨的整體指標對任何對影響人的決策進行的模型都是不充分的。

    6. 已知局限性

    模型處理哪類輸入效果不好。它傾向於犯什麼錯誤。什麼條件導致性能下降。模型從未測試過什麼。

    這是在實踐中最常寫不足的部分——組織不願意以可能被用來反對他們的方式記錄局限性。這種推理是倒退的。記錄的局限性允許部署者設計適當的人工監督。未記錄的局限性通過生產失敗被發現。在後一種情況下,訴訟風險要高得多。

    7. 倫理考量

    模型錯誤或濫用的潛在危害。已到位的緩解措施。可能受模型錯誤不成比例影響的群體。在模型開發中諮詢了誰——內部和外部。

    8. 注意事項和建議

    下游部署者在部署模型前應知道什麼。所需的人工監督。性能需要保持的環境條件。推薦的監控實踐。

    EU AI Act 附件四:從最佳實踐到法律要求

    對於 EU AI Act 下的高風險 AI 系統——包括用於就業、信貸、教育、執法、移民和其他指定領域的 AI——附件四規定了強制性的技術文件要求。11 個要素的要求涵蓋:

    1. AI 系統的一般描述
    2. 系統組件和開發過程的描述
    3. 訓練資料的詳細資訊
    4. 人工監督措施的描述
    5. 系統能力和局限性的描述
    6. 風險管理過程的描述
    7. 整個生命週期中所做更改的描述
    8. 應用的標準
    9. EU 合規聲明
    10. 部署者的資訊
    11. 市場後監控系統的描述

    第 1 至 6 個要素直接對應模型卡字段。對於高風險系統,模型卡不是最佳實踐文件——它是法律文件。不完整的模型卡意味著不合規的系統。

    EU AI Act 第 13 條:透明度義務

    第 13 條要求高風險 AI 系統足夠透明,以便部署者和用戶能夠理解系統的能力和局限性。這包括:

    • 關於系統預期目的的資訊
    • 達到的準確率、穩健性和網絡安全級別
    • 可能影響準確率和性能的任何已知或可預見情況
    • 適當的人工監督措施

    如果運營商沒有這些資訊,他們就無法向部署者提供這些資訊。第 13 條的透明度要求,作為先決條件,是運營商首先記錄了這些資訊。模型卡就是那個文件記錄。

    微調模型的模型卡

    當你微調基礎模型時,你需要為微調版本製作一個模型卡。連結到基礎模型的模型卡是不夠的。

    微調模型卡應記錄:

    • 微調資料集包含什麼,以及它被設計來訓練什麼
    • 微調的結果是什麼能力改變了,以及意圖是什麼
    • 基礎模型基準任務上的性能如何變化——包括微調沒有針對的基準。對特定領域的微調可能會降低通用任務的性能。
    • 對微調版本具體進行了什麼評估

    這很重要,因為微調模型是與基礎模型不同的模型。它的行為是基礎訓練和微調組合的結果。只記錄基礎模型的特性,讓微調的貢獻——以及其引入的局限性——未被記錄。

    稽核追蹤的連接

    模型卡是一個時間點文件。它描述了卡片撰寫時存在的模型。模型會改變:它們被重新訓練、更新、微調,有時被回滾。準確描述版本 1.0 的模型卡可能對版本 1.3 具有誤導性。

    模型卡需要與模型一起維護。對於管理多個模型版本的組織,這意味著版本化的模型卡過程:每個模型版本都有一個對應的模型卡版本,並且更改歷史被追蹤。

    模型清單——組織中所有已部署 AI 模型、其版本和操作狀態的登記冊——是使這變得可管理的基礎設施。模型卡是每個模型的文件;清單是組織層面的視圖。

    資料血緣作為模型卡的基礎

    模型卡的「訓練資料」和「評估資料」部分只有在你的資料管線文件準確的情況下才是準確的。如果你無法追蹤進入模型的資料——其來源是什麼、應用了什麼預處理、排除了什麼以及為什麼——你就無法撰寫準確的模型卡。

    通過具有記錄轉換、操作員 ID 和時間戳的結構化管線處理訓練資料的組織,會自動擁有這個文件記錄。資料血緣記錄是模型卡的訓練資料部分的真實來源。非正式組裝訓練資料的組織——下載文件、運行沒有日誌記錄的腳本、在筆記本中應用轉換——通常無法重建準確的訓練資料敘述。

    這是在模型訓練之前(而非之後)建立結構化資料基礎設施的實際論點之一。當你需要模型卡時,訓練資料文件要麼存在,要麼不存在。

    有關更廣泛的治理背景,請參見生產中的 AI 模型治理。有關支撐模型卡資料血緣的稽核追蹤基礎設施,請參見企業 AI 稽核追蹤:要記錄什麼。有關 EU AI Act 高風險系統要求的詳細資訊,請參見EU AI Act 高風險系統要求


    預約與 Ertas 的探索電話 →

    Turn unstructured data into AI-ready datasets — without it leaving the building.

    On-premise data preparation with full audit trail. No data egress. No fragmented toolchains. EU AI Act Article 30 compliance built in.

    Keep reading