モデルのバージョニングとは? モデルバージョンの追跡を解説
モデルのバージョニングとは、トレーニング済みの各モデルに、それを生み出した正確なデータ、コード、パラメータに紐づいた、追跡可能なバージョンを与える実践です。
ソースコードにはGitがあり、あらゆる変更にはcommitがあります。モデルにも同じものが必要です。モデルのバージョニングは、トレーニング済みの各モデルを、区別可能で識別可能なバージョンとして記録します。これにより、何がそれを生み出したかを常に把握でき、以前のどのバージョンにも戻ることができます。
モデルのバージョニングとは何か
モデルのバージョニングは、トレーニング済みの各モデルに一意で順序付けられたアイデンティティを割り当て、それをその系譜 - データセットのバージョン、トレーニングコードのcommit、ハイパーパラメータ、そして結果として得られたメトリクス - に紐づけます。これは、ソフトウェアリリースにおけるセマンティックバージョニングのモデル版です。
なぜモデルのハッシュだけでは不十分なのか
モデルファイルをハッシュ化することはできますが、それでは2つのモデルがなぜ異なるのかは分かりません。有用なモデルのバージョニングは入力を捉えるため、「どのデータとコードがバージョン7を生み出したのか?」に答え、それを再現できます。これが、バージョニングが通常、データのバージョニングや実験の追跡と組み合わせられる理由です。
バージョンはどこに存在するのか
モデルのバージョンは通常、model registryに保持され、そこでは連番のバージョン番号が割り当てられ、ステージが追跡されます。artifact自体はオブジェクトストレージに存在し、registryはバージョンを意味あるものにするメタデータと系譜を保持します。
CIにおけるバージョニング
トレーニングパイプラインは、成功した実行ごとに新しいバージョンを登録し、commitのSHAとデータセットのバージョンでタグ付けすべきです。そうすれば系譜は手作業ではなく自動的なものになります。
git_sha=${GITHUB_SHA}
data_ver=$(dvc status --json | jq -r .rev)
python register.py --model model.pkl \
--tag "git=${git_sha}" --tag "data=${data_ver}"Latchkeyに関する注記
各バージョンは特定のデータセットを固定するため、CIのjobは結果を再現するためにその正確なデータを再取得します。Latchkeyでは、バージョン管理されたデータセットをそのコンテンツハッシュをキーにしてキャッシュすることで、古いバージョンを再現する際に再ダウンロードではなくキャッシュから取得できます。そしてauto-retryが、あらゆる一時的な取得の失敗をカバーします。
重要なポイント
- モデルのバージョニングは、トレーニング済みの各モデルに、そのデータ、コード、パラメータに紐づいた追跡可能なアイデンティティを与えます。
- ファイルのハッシュだけでなく系譜を捉えることが、バージョンを再現可能にします。
- CIのトレーニングパイプラインは、実行ごとに新しいバージョンを登録し、commitとデータセットのバージョンでタグ付けすべきです。