LLM開発におけるモデルマネジメント
複数の部門が関わるLLM開発における組織的モデルガバナンスに活用できるWandB Model Registryをご紹介します。
Created on December 9|Last edited on December 29
Comment
本レポートはWandB アドベントカレンダー2023の寄稿記事として執筆されました。
💡
何故モデルレジストリーが必要なのか
ML開発においては様々な学習データセットのパターンを試し、ハイパーパラメーターやアーキテクチャーの試行錯誤を行い、結果として多数のモデルを構築し、評価をすることになります。これらのモデルの中から最終的にプロダクションにデプロイするモデルを決定するまでの「産みの苦しみ」が終わってからも、継続的にモデルのアップデートをしていくことになります。3ヶ月後にモデルを更新しようとした時には、そもそもどのモデルをデプロイしたのかがわからなくなってしまったり、デプロイされたモデルがどのような評価を経て選ばれたのかが後からはわからなくなってしまった、というようなことを、私自身経験したことがあります。
ML/LLM開発における典型的なMLOpsワークフロー
このような問題を解決するための手法として、モデルレジストリが挙げられます。実験的な開発を経て生まれたモデルの中から、次の開発ステージに進めることになったモデルやプロダクションへデプロイする候補になったモデルを管理するための仕組みです。
モデルレポジトリとの関わり方はプロジェクトに関わる人たちの役割によって変わってきます。例えば：
- MLエンジニア：自分の作った中でベストなモデルをチームに共有し評価を依頼したい。また、過去にデプロイされたモデルとの比較を行いたい
- プロダクトマネージャー：現在開発中ないしデプロイされたモデルを一覧で管理し、プロジェクト状況を把握したい
- MLOpsエンジニア：モデルのデプロイ前に、評価・アプルーバルの条件を満たしているか確認し、問題なければそのモデルをデプロイ用に入手したい
このように、モデルレジストリーは過去の履歴の記録としてだけではなく、チームの様々な役割のステイクホルダーが効果的に共同作業するための仕組みであることがわかります。
アーティファクトとモデルレジストリ
このレポートでは、簡易的なLLM開発ワークフローを想定し、Weights & Biases (WandB) のModel Registry機能を使ったモデルマネジメントの構築方法を見ていきましょう。今回は12月に行われるLLMファインチューニングのウェビナー（リンク）で使う下記のワークフローを題材にします：
- ファンデーションモデルは外部モデルを使用：CyberAgentのOpenCalm
- ファンデーションモデルをLoRAチューニングし、チャット対応させる
- 出来上がったモデルを評価し、最終的にデプロイするモデルを決定
WandBでは、モデルレジストリに登録する前にまず記録の対象となるオブジェクト（データ、モデル、コードなど）をArtifactとして登録します。また、Artifactは、その利用の履歴を記録することで、各オブジェクトの関係性を保持することができます。
上記の開発ステップの中で作られたArtifactの関係性を実際のWandBのビューから見てみましょう：
cyberagent-open-calm-1b-instruct
Direct lineage view
各オブジェクトと、処理の関係性が想定通り記録されていることがわかります。ここでは簡易的な例として、一つのチューニングされたモデルができました。実際にはこのモデルの評価を多角的に検証し、デプロイするかどうかを判断するプロセスがあるわけですが、ここでは早速このモデルをデプロイ候補として、モデルレジストリに登録します：
これによって、モデルがWandB Model Registryに登録されました。
レポジトリは開発チームに属しているユーザーが確認することができるとともに、下記のコードを使って手元にダウンロードすることができます。
import wandbrun = wandb.init()artifact = run.use_artifact('wandb-japan-partners/model-registry/cyberagent-open-calm-1b-instruct:v4', type='model')artifact_dir = artifact.download()
大規模なLLM開発におけるモデルマネジメント
組織的で大規模なLLMアプリケーションの開発のワークフローにおいては複数の部門にまたがって：
- 基盤モデルの開発
- タスクに適用するためのチューニング
- パフォーマンスオプティマイゼーションとインテグレーション
- 運用・モニタリング
などを行うようになるため、モデル管理における組織関連系と、ガバナンスの課題が重要になります。各プロセスへの部門ごとの関わり方は企業によって様々な形態がありますが、典型的には下図のような部門の連携が求められます：
MLOps/LLMOpsに関わる企業内の各部門
開発に関わるすべての部門が連携するためには、各モデルに関する最新情報をすべてのステイクホルダーが共有するための統合的な記録システム（Central Place of Record）を構築することが求められます。その中で中核的な役割を担うのがWeights & BiasesのModel Registryです。具体的にはこれによって下記のような課題の解決を目指すことができます：
- モデルレポジトリ：評価・デプロイ様のモデルを一箇所に集約し、生のファイルをやり取りぜずにセキュアな組織間の引き渡しを可能にする
- モデル情報の一元管理：開発されたモデルの各バージョンに対して、データセット、ハイパーパラメーター、開発の履歴、評価結果などをすべての関係者が必要に応じてトレースできる
- モデルガバナンス：アプルーバル権限を持つ担当者が、評価結果に基づいて次のステージに進めるモデルを明示し、アドミン権限者だけがデプロイを許可できる
- オートメーション：モデルに付与されたステージ情報に基づいて、事前に定義された自動処理ワークフロー（評価やオプティマイゼーション）をトリガーする
組織的なモデルガバナンスの構築
モデルレジストリはチームメンバーが情報を共有する場所として有効なことはすでに十分に明らかになったと思いますが、組織においてのガバナンスを確立するためには、社内プロセスを構築する必要があります。モデルレジストリへのモデルの登録は誰ができるのか、モデルを特定のステータスに変更するのは誰の権限なのか、最終的なリリースのための確認事項などの取り決めが必要です。
また、各担当者が決められた権限を使ってこのプロセスを推進していくために、モデルレジストリー上でモデルのステージを適切に管理していくことが求められます。具体的には、対象となるモデルを次のステップに進める準備が整ったら、モデルにタグを追加し、関係者に通知します（WandBは自動的に対象者にアラートを送ります：ドキュメント）。ガバナンスを効かせるために、モデルレジストリアドミンとして登録されたユーザーだけが特定のタグを付与できるよう設定します。
また、モデルがどのようなステップでステージアップしていったのかはすべて記録に残るため、後から監査が必要となった場合には履歴を確認することができるようになっています。このような機能があることで、モデルマネジメントプロセスの信頼性を高めることができます。
オートメーション
ガバナンスの観点を重視すると、これらのプロセスに、人間による承認が介在していることはとても重要ですが、同時に自動化できるステップは極力自動化することで、モデルデリバリーまでの時間を短縮していくことが求められるでしょう。WandB Model Registryの発展的な使い方として、任意のジョブをモデルステータスに紐づけてトリガーすることができます。これについてはすでに、Weights & Biases Japanのブログにて詳細な説明がありますので、このリンク先を参照してください：
まとめ
本レポートではシンプルながらパワフルなモデルレジストリーの使い方を開発者レベル、組織レベルの双方から検証しました。実際にModel Registryを現場で使っている事例として、M-KOPAのユースケース記事がとても参考になるので、英語の記事ではありますがこちらをお勧めします。また、モデルレジストリーの使い方については、こちらのビデオもお勧めです：
ここでご紹介したモデルマネジメントの方法論は、大規模化するAI開発において今後ますます求められていくようになると考えています。ご相談はぜひcontact-jp@wandb.comまで、お気軽にお寄せください。
Add a comment
Tags: Articles, Community Posts
Iterate on AI agents and models faster. Try Weights & Biases today.