Model Registry

モデルレジストリは、機械学習モデルのライフサイクル全体にわたって、モデルを整理、バージョン管理、ガバナンス、取得するための集中型システムです。学習済みのモデルウェイトなどのモデルファイルと、各モデルの学習、評価、承認、デプロイ方法を説明するメタデータを関連付けます。機械学習オペレーションの中核コンポーネントとして、レジストリは、どのモデルバージョンで本番トラフィックを処理すべきかをチームが判断するための信頼できる情報源を提供します。

モデルレジストリの仕組み#

モデルの登録は、トレーニング実行によって候補モデルが生成された後に始まります。レジストリは名前付きエントリを作成し、バージョンを割り当て、そのアーティファクトを理解して再現するために必要な情報を記録します。一般的なエントリには、次の情報が含まれます。

• モデルアーティファクト: シリアライズされたウェイト、前処理ロジック、設定ファイル、またはそれらの保存場所への参照です。
• バージョン: ある候補を別の候補と区別する不変の識別子です。
• メトリクスとパラメーター: 検証精度、適合率、再現率、レイテンシ、データセットの詳細、ハイパーパラメーター、その他の測定値です。
• 系譜: モデル、ソースコード、トレーニング実行、データ間の関連です。
• ステータス: 候補、承認済み、却下、チャンピオン、アーカイブ済みなどのラベルです。
• デプロイ情報: 現在そのバージョンを使用している環境とエンドポイントです。

プラットフォームによって、これらの概念の実装方法は異なります。MLflow Model Registryのワークフローでは、登録済みモデル、バージョン、エイリアス、タグを使用します。一方、Amazon SageMaker Model Registryは、モデルグループ、承認状態、系譜、デプロイの自動化をサポートします。システムによっては、モデルシグネチャも記録します。これは、Snowflakeモデルシグネチャのドキュメントで説明されている、想定される入力および出力スキーマです。

championやproductionなどのエイリアスは、不変のバージョン間で移動できる安定した名前を提供します。Vertex AIモデルエイリアスガイドで説明されているように、アプリケーションはバージョン番号をハードコーディングせずにエイリアスをリクエストできます。

モデルレジストリと関連概念の比較#

モデルレジストリはいくつかのMLツールと重複する機能を持ちますが、固有の目的を果たします。

• **実験トラッキング**は、パラメーター、メトリクス、中間アーティファクトなどのトレーニング実行を記録します。レジストリは、これらの実験から選択された出力を受け取り、リリース候補として管理します。
• アーティファクトストレージは大容量ファイルを保持します。レジストリはファイルを直接保存することもできますが、外部のオブジェクトストレージを指すメタデータインデックスとして機能することもできます。Kubeflow Model Registryのアーキテクチャは、このメタデータ中心の設計を示しています。
• ソース管理はコードをバージョン管理します。一方、モデルレジストリは、学習済みアーティファクトとそれらに固有のMLメタデータをバージョン管理します。GitLabモデルレジストリは、モデルバージョンをCI/CDジョブ、ログ、メトリクス、パラメーターに関連付けることができます。
• **モデルデプロイ**は、選択したモデルを推論に利用できるようにします。レジストリは承認済みのアーティファクトを特定し、デプロイシステムがそれを実行します。
• **モデルモニタリング**は、リリース後の本番環境での動作を監視します。モニタリング結果によって、評価、再トレーニング、登録、後続バージョンの昇格がトリガーされる場合があります。

したがって、レジストリは周辺のすべてのコンポーネントを置き換えるのではなく、実験と本番環境の間の制御ポイントとして機能します。

実世界での利用例#

製造検査システムでは、カメラ、素材、または製品設計が変更されるたびに、エンジニアが欠陥検出器を再トレーニングする場合があります。レジストリには、各モデルのデータセット参照、平均適合率、推論レイテンシ、対応ハードウェア形式を保持できます。テストによって、バージョン12が誤警報を増加させずに傷の検出性能を向上させることが確認された後、承認者はそのバージョンを昇格させ、即時ロールバック用にバージョン11を保持できます。

医療画像解析では、複数のチームが腫瘍検出の候補モデルを評価する場合があります。登録により、各バージョンの検証結果、トレーニング設定、担当オーナー、承認履歴が保持されます。本番アプリケーションをレビュー済みモデルに限定する一方で、監査と再現性確保のために古いバージョンを利用可能な状態に保つことができます。Snowflake Model Registryのガバナンスで説明されているようなロールベースの制御は、機密性の高いアーティファクトの無許可の置き換えや検査を防ぐのに役立ちます。

Ultralyticsのワークフローにおけるモデル登録#

Ultralytics Platformは、コンピュータビジョンモデルのデータセットへのアノテーション付け、トレーニング、結果比較、エクスポート、デプロイ、モニタリングのための集中型モデル管理を提供します。文書化されたPlatformのモデル管理ワークフローは、アップロードされた.ptウェイトと、クラウドまたはリモートトレーニングで生成されたモデルをサポートします。

次の文書化されたワークフローでは、Ultralytics YOLO26をローカルでトレーニングし、その結果生成されたモデル、設定、メトリクス、ログを名前付きのPlatformプロジェクトに送信します。

import os

from ultralytics import YOLO

# Authenticate remote training with Ultralytics Platform
os.environ["ULTRALYTICS_API_KEY"] = "YOUR_API_KEY"

model = YOLO("yolo26n.pt")

model.train(
    data="coco8.yaml",
    epochs=3,
    project="username/model-registry-demo",
    name="candidate-001",
)

プロジェクト名と実行名によって、候補モデルを関連モデルと並べて見つけられるようになります。チームは候補モデルを評価したり、追加の実験ログ記録にUltralytics MLflow統合を使用したり、登録済みモデルを特定のクラウドまたはエッジハードウェアで実行する必要がある場合にYOLOモデルのエクスポートを適用したりできます。

レジストリ運用に関する実践的なガイダンス#

登録したすべてのバージョンを不変として扱ってください。デプロイには人間が読みやすいエイリアスを使用し、検証の証拠を保持し、明確な昇格要件を定義してください。セマンティックバージョニングに基づく命名ポリシーによって互換性の変更を伝えられますが、自動的にインクリメントされるバージョンも効果的です。

最も重要なのは、説明のないウェイトファイルではなく、完全なモデルパッケージを登録することです。前処理ルール、クラス名、入力スキーマ、依存関係、データセット参照が欠落すると、一見有効なモデルでも再現できなくなったり、安全にデプロイできなくなったりする可能性があります。アクセス制御、自動テスト、承認ゲート、監査ログ、ロールバック手順によって、モデルレジストリは単なるファイルカタログから、信頼性の高い本番環境のセーフガードへと変わります。