Model Card

モデルカードとは、AIや機械学習モデルが何を行うのか、どのように開発および評価されたのか、どこで使用されるべきか、そしてユーザーが理解すべき制限やリスクは何かを説明する構造化されたドキュメントです。ソースコードやモデルの内部構造にアクセスしなくてもAIの透明性をサポートし、開発者、レビュー担当者、デプロイ担当者、および影響を受けるステークホルダー向けの実用的な情報シートとして機能します。この文脈において、モデルカードはファッションモデルのプロフォリオである「コンプカード」とは関係ありません。

モデルカードに含まれる内容#

有用なモデルカードには、技術的な証拠と平易な言葉によるガイダンスが組み合わされています。その詳細さはモデルの影響力を反映させるべきであり、実験的な画像分類器には短いカードで十分な場合がありますが、医療や金融の決定に影響を与えるモデルにはより詳細なドキュメントが必要です。

一般的な構成要素は以下の通りです。

• 目的、所有権、およびバージョン： モデル、担当チーム、リリースバージョン、タスク、サポートされている入力と出力、ならびに連絡先やメンテナンス情報を特定します。
• トレーニングデータと開発のコンテキスト： データソース、収集条件、ラベリングのプラクティス、前処理、モデルアーキテクチャ、トレーニング手順、および重要な前提条件について説明します。機密データやプロプライエタリなデータは、開示せずに要約することができます。
• 評価とパフォーマンス指標： 明確に特定された検証用またはテスト用データセットにおける指標を報告します。物体検出の場合、これらには精度、再現率、平均精度（mAP）、推論レイテンシ、および個々のクラスや意味のあるデータサブセットの結果が含まれる場合があります。
• 想定される用途と除外事項： 適切なアプリケーション、想定される運用条件、必要な人間の監督、およびモデルが設計されていないシナリオについて説明します。
• 制限とリスク： 既知の障害モード、不確実性、プライバシーに関する懸念、セキュリティの考慮事項、および考えられるデータセットのバイアスを文書化します。また、不正確な予測がもたらす可能性のある結果についても記載する必要があります。

Amazon SageMaker Model Cardsのドキュメントは、想定される用途、トレーニングの詳細、評価、リスク評価、および推奨事項を網羅した構造化されたライフサイクル記録の例を提供しています。Google DeepMindのモデルカードなどの公開コレクションは、カードがどのようにして能力、安全性評価、および制限事項をより幅広いオーディエンスに伝えることができるかを示しています。

モデルカードが重要である理由#

モデルカードは、チームがモデルを採用またはデプロイする前に十分な情報に基づいた決定を下すのに役立ちます。印象的な見出しの指標は、稀なクラス、珍しい環境、または特定のユーザーグループにおける弱いパフォーマンスを隠している可能性があります。評価データセット、テスト条件、およびグループごとの結果を文書化することにより、カードはそれらの数値を解釈するために必要なコンテキストを読者に提供します。

また、これらはガバナンスと説明責任をサポートします。NIST AIリスク管理フレームワークはAIライフサイクル全体を通じた信頼性の管理を強調し、一方OECDの透明性と説明可能性の原則はAIの能力と制限に関する意味のある情報を求めています。モデルカードは、これらの目標に向けた実用的な成果物を提供します。

組織内では、カードはデータサイエンティスト、プロダクトチーム、コンプライアンスレビュー担当者、およびオペレーションエンジニアの間での引き継ぎを改善します。IBM AI Factsheetsなどのシステムは、開発、承認、デプロイ、およびモニタリング全体にわたってモデルのメタデータを収集することで、このアプローチを拡張します。

関連するドキュメントと主な違い#

いくつかの関連する成果物が異なる目的に役立ちます。

• データカード： データセットの起源、構成、収集プロセス、アクセス条件、想定される用途、および制限について説明します。モデルカードはトレーニング済みのモデルに焦点を当てていますが、関連するデータセットのドキュメントを参照する必要があります。
• モデルレジストリ： モデルの成果物、バージョン、リネージ、およびデプロイステータスを保存および管理します。MLflow Model Registryのワークフローはこの運用の役割を示しています。モデルカードは意味とリスクを伝え、レジストリはモデルの資産を管理します。この2つは接続することができます。
• システムカード：複数のモデル、プロンプト、検索コンポーネント、セーフガード、インターフェース、および人間のプロセスを潜在的に含む、AIシステム全体を文書化します。モデルカードは、より小規模なモデルレベルのスコープを持っています。
• 説明可能性レポート：モデルが特定の結果を生成した理由を調べます。モデルカードは全体的な動作と制限を要約しますが、予測レベルの説明に代わるものではありません。

実社会での応用#

• 製造業の目視検査： 工場では、欠陥検出のためにコンピュータビジョンモデルをデプロイすることがあります。そのモデルカードには、サポートされている欠陥クラス、カメラの配置、照明の前提条件、稀な欠陥に対するパフォーマンス、最小オブジェクトサイズ、およびエッジデバイスのレイテンシをリストアップできます。反射光の下で傷が頻繁に見落とされる場合、その制限を文書化することで、オペレーターが手動レビューを要求したり、追加のトレーニング画像を収集したりするのに役立ちます。

• 臨床画像サポート：医療画像モデルのカードは、評価時に表現されたスキャンタイプ、機器、患者集団、および施設を特定できます。サブグループのパフォーマンスを報告し、出力が独立して診断を決定するのではなく、資格のある臨床医を支援することを明確にすることができます。このコンテキストが欠けていると、病院がサポートされていない機器や集団でモデルを使用するようになり、信頼性の低い推奨事項のリスクが高まる可能性があります。

モデルカードは、サードパーティのモデルを選択する際にも遭遇します。たとえば、Microsoft Foundryモデルカタログのドキュメントでは、モデルの詳細、ベンチマーク、サポートされているデータ型、ライセンス、およびデプロイ情報を含むカードについて説明しています。

モデルカードの作成と維持#

デプロイ後ではなく、プロジェクトの計画段階でカードの作成を開始します。データセットのバージョン、トレーニング設定、評価条件、レビュー担当者の決定など、証拠が生成されるときにそれを記録します。Ultralytics YOLO26物体検出モデルの場合、文書化された検証ワークフローによって評価セクションの指標を生成できます。

from ultralytics import YOLO

# Load the documented model version
model = YOLO("yolo26n.pt")

# Evaluate it on a labeled validation dataset
metrics = model.val(data="coco8.yaml")

# Record these results with the dataset and test conditions
print(f"mAP50-95: {metrics.box.map:.3f}")
print(f"mAP50: {metrics.box.map50:.3f}")
print(f"mAP75: {metrics.box.map75:.3f}")

これらの値は、モデルのバージョン、データセット、スプリット、画像サイズ、ハードウェア、および評価構成が伴う場合にのみ意味を持ちます。チームはUltralytics Platformを使用して、データセットにアノテーションを付け、トレーニングの実行を追跡し、モデルをデプロイし、エンドポイントをモニタリングすると同時に、カードを更新するために必要な証拠を維持することができます。

モデルカードは、バージョン管理された生きたドキュメントである必要があります。モデル、データセット、評価プロセス、デプロイ環境、または既知の制限が変更されるたびに更新してください。最も重要なことは、それをトレーニングしたチーム向けだけでなく、モデルを使用すべきか、どのように使用すべきかを決定している人々に向けて書くことです。