Model Registry

モデルレジストリとは、機械学習モデルのライフサイクル全体にわたって、その整理、バージョニング、ガバナンス、および取得を行うための集中型システムです。学習済みのモデルウェイトなどのモデルファイルと、各モデルがどのようにトレーニング、評価、承認、デプロイされたかを記述するメタデータを結びつけます。機械学習オペレーション (MLOps)の中核コンポーネントとして、レジストリはどのモデルバージョンが本番トラフィックを処理すべきかを判断するための信頼できるソースをチームに提供します。

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

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

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

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

championやproductionなどのエイリアスは、不変のバージョン間を移行できる安定した名前を提供します。Vertex AI model alias guideで説明されているように、アプリケーションはバージョン番号をハードコードすることなくエイリアスをリクエストできます。

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

モデルレジストリはいくつかのMLツールと重複しますが、明確な目的を持っています:

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

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

実社会での応用#

製造検査システムでは、カメラ、材料、または製品デザインが変更されるたびに、エンジニアが欠陥検出器を再トレーニングする場合があります。レジストリは、各モデルのデータセット参照、平均適合率 (mAP)、推論レイテンシ、およびサポートされているハードウェア形式を保持できます。テストによりバージョン12で誤報を増やすことなく傷の検出が改善されたことが確認された後、承認者はそれを昇格させ、バージョン11を即時ロールバック用に保持することができます。

医療画像解析では、複数のチームが腫瘍検出の候補を評価することがあります。登録により、各バージョンの検証結果、トレーニング構成、責任者、および承認履歴が保持されます。本番アプリケーションはレビュー済みのモデルに制限される一方、古いバージョンは監査や再現性のために維持されます。Snowflake Model Registry governanceで説明されているようなロールベースの制御は、機密性の高いアーティファクトの不正な置き換えや検査を防ぐのに役立ちます。

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

Ultralytics Platformは、データセットのアノテーション、トレーニング、結果の比較、エクスポート、デプロイ、およびコンピュータビジョンモデルのモニタリングを行うための集中型のモデル管理を提供します。ドキュメント化されたPlatform model management workflowは、アップロードされた.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 integrationを使用したり、登録済みモデルを特定のクラウドまたはエッジハードウェアで実行する必要がある場合にYOLO model exportを適用したりできます。

レジストリ運用の実践的なガイダンス#

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

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