多くの人は、モデルの公開をあまりにも簡単だと思い込んでいます。学習が終わったらアップロードして紹介文を書けば、それでタスクは完了。

しかし、本当の意味でプロダクトを作った人なら知っている通り、モデルが一番面倒になるのは、実は本番公開（上线）した後からです。

データが更新されたら再学習が必要。パラメータを調整したら新バージョンを出す必要がある。ユーザーのフィードバックで効果が悪くなったら、どの手順が変わったのかを突き止めなければならない。

ここで、しばしば見落とされがちな矛盾があります。みんなはモデルを素早く更新したい一方で、更新のたびに、以前に使えていた機能がそのまま壊れてしまうのを恐れている。

だから私はずっと、モデルのホスティングは単なるクラウドストレージ（網盤）であってはいけないと思っています。本当に役に立つプラットフォームなら、少なくとも開発者が「各バージョンで何が変わったのか」「旧バージョンをまだ使っているのは誰か」「新バージョンを先にテストしてから本番に出せるのか」を分かるようにする必要があります。

OpenGradientのModel Hubは、この点でモデル公開の“システム”として作り込まれています。

1つのモデルは、まず独立したリポジトリとして作成し、その後v1.00、v1.01、v2.00のような形で異なるReleaseを公開できます。各バージョンの配下に、モデルファイル、設定、説明などを置けるため、新しいファイルを1回アップしただけで旧モデルを直接上書きしてしまうことはありません。

実際のワークフローもかなりスムーズです。

開発者がリスク予測モデルを学習し、まずONNX形式でエクスポート。Model Hubでリポジトリを作成し、v1.00をアップロードします。次に、WebのPlaygroundでそのまま試せます。入力や結果に大きな問題がないと確認してから、アプリ側がそのバージョンを固定で呼び出せます。

後から学習データが更新されたら、v1.01を追加でリリースして変更点を明確に書き、まずは一部のアプリでテストします。旧バージョンは残ったままなので、1回の更新で、それを使っているすべての製品が同時に無効になることはありません。さらにチームは、Python SDKやCLIを使って、モデルのアップロードを自分たちの学習・公開プロセスに組み込むこともできます。

もちろん、バージョン番号がどれほど美しくても、モデルが必ず信頼できることを証明できるわけではありません。ONNXへの変換で差が出る可能性もあるし、新しいデータで効果が変わる可能性もあります。最終的にはテストと、実際に使った結果で判断するしかないのです。

ただ少なくとも、これはとても現実的な問題を解決します。モデルは“一度きりのファイル”ではなく、長期的に保守していく必要があるソフトウェアだということ。毎回の変化をきちんと言語化できるかどうかが、多くの場合、初回公開以上に重要です。

$OPG @OpenGradient #OPG