LLMOps：基盤モデルに基づくアプリケーション開発のワークフロー
大規模言語モデル（LLM）の可能性を引き出し、その機能を拡張してアプリケーションを開発・提供するためのワークフローは、どのようなものなのでしょうか。私たちはここ数ヶ月、様々な場所でこの課題を耳にしてきました。
これまで機械学習モデルの開発と運用を統合するMLOps（Machine Learning Operations）のワークフローの構築において最も信頼されてきたWeights & Biasesは、OpenAIやStability AIなど、生成AIの開発で最先端をいく企業に活用されてきました。
この経験をもとに、本稿ではMLOpsのベストプラクティスをレビューし、この概念がどのようにLLMOpsに適用されていくのか、現時点のベストプラクティスを示していきます。
特にLLMOpsにおいては、多くの場合社外で開発された基盤モデル（FM, Foundation Model）を軸とする開発が中核的中核的なステップとなり、自社データとFMを適切なバランスで統合することが求められます。
MLOpsとは
上の図は、一般的なMLOpsのワークフローを示しています。ここ数年の様々な企業での開発と実装の経験値が蓄積され、MLOpsのワークフローについては標準化が進んできました。
機械学習によるモデル開発からサービス提供のライフサイクル全体を通じて信頼性の高い価値提供をするためには、プロセスを定義し、再現可能性を高め、関わる開発者・運用者が共通の基盤で情報共有をすることで、スケーラブルな開発体制を構築必要があります。
大きく分けるとこのプロセスは4つに分けることができるでしょう：
MLモデル開発：AI開発において特に重要視されるプロセスです。学習のデータを収集し、機械学習アルゴリズムを使って求める結果を得るために、何度も実験を繰り返す必要があります。科学実験にも似た仮説構築と検証のプロセスからなり、効果的な開発を行うためには優れた実験管理手法が必要となります。
デプロイメント：完成したモデルをサービス側に提供するためのインターフェースとなる推論APIを実装し、開発者以外の監査担当者もモデルのリスク評価など行なった上でリリースされるモデルを選択し、公開します。
インテグレーション：モデルの推論結果を利用し、ユーザーにサービス提供するためのシステム・アプリケーションを開発し、統合的なテストを経てサービス提供を開始します。これを「プロダクション」ステージと呼びます。
モニタリング：運用開始されたサービス・モデルが想定された振る舞いをしているのかを監視するとともに、サービス利用者側の入力が想定からずれてくる「ドリフト」などの現象も監視します。サービスの提供価値をビジネス評価し、それに基づいてモデルの継続的なアップデートとサービスの改善を行います。
効果的なMLOpsの導入・運用についてより深く知りたい方は、弊社の公開している下記のコース（日本語訳あり）をお勧めします！
LLMの導入に求められる基盤モデルと自社開発のバランス
大規模言語モデルの開発運用においても大きな概念としてのMLOpsは変わりませんが、生成AIという技術の新しさからくる不確定要因が現時点ではまだ大きいのが現状です：
そもそも求めるような精度の結果を出力してくれるようなモデル・システムを作ることができるのか
そのためには基盤モデルから開発する必要があるのか、既存のモデルをそのまま使うことができるのか
上記の開発をおこうなうために十分な計算リソースや、人的専門性、開発環境を構築できるのか
そのためにはどれだけのコストと時間がかかるのか
自社データを統合するためには社外のAPIを使うことにリスクはないのか？オープンソースの技術スタックは十分な性能を有するのか
ハルシネーションによる情報の不正確さやプライバシー情報の漏洩の可能性などのリスクにどのように対処すれば良いのか
このような課題に関して十分な答えを求めると現時点では何もできなくなってしまう懸念もあり、「とりあえずやってみる」ことから学ぶ視点の重要さを優先し、大きなリスクを避けながら検証を開始した企業も驚くほど増えてきました。LLMモデルの開発には、主に三つのアプローチが存在します：
LLM基盤モデルをゼロから構築：先進的な企業は自社で日本語に特化したLLMを開発する大規模な取り組みを始めている企業もあります。自社で基盤モデルを有することで、様々な機会を生み出す可能性の高いアプローチではありますが、膨大なリソースを必要とすることから取り組みには躊躇する企業も多いのが現状です。よく勘違いされるポイントですが、素の基盤モデルはそのままでは「入力の次に来る言葉を予測する」という単純な課題に対して訓練されており、実際に役に立つモデルを作るためにはファインチューニングが必要となるケースがほとんどです。
追加学習でFMをファインチューニング：現在のLLMモデルは、ChatGPTのようにチャット型の応答をするものが主に注目されていますが、実はチャット型のモデルは基盤モデルをチューニングして作ることのできる可能性の中の一種類でしかありません。チューニング方法を変えることで、よりプログラムコードの生成に適したモデルを作ったり、広告のコピーの生成に適したモデルなど、様々なタスクにカスタマイズが可能です。いずれの場合も各タスクに適応させるためのインプットとアウトプットの例を示した質の高いデータが必要になります。
自社のデータを融合し、インコンテクストラーニング：すでに公開されているファインチューにイング済みモデルで、基本的な受け答えなどは満足だが、FMが知らない最新の情報や、自社にしかない特別な情報を解答の対象とするために、モデルが検索可能なデータベースを構築し、モデルに対するプロンプトの実行時にコンテクストとして追加情報を渡すことで、知識を拡張する手法です。特に大規模言語モデルに対してこの手法を適用するためのツールとしてLangChainやLlamaIndexなどが登場しています。
W&Bでは特に上記のうち、基盤モデルの構築とファインチューニングについてその技術詳細を示したホワイトペーパーを発表し、日本語化して提供していますので、これらの手法を深掘りしたい方はご覧ください。
LLMOps - LLM開発・運用のワークフロー
前章に挙げた検討事項を考慮し、仮の開発の戦略・方針を決定したら、いよいよ開発が始まります。最終的には新サービス・新製品を提供する前提で考えると開発のパターンは1,2,3の組み合わせで何通りかに分けられます：
1+2+3：完全に自社に閉じた開発プロセスでゼロから開発を行い、サービスに応用するためのチューニングと更なるデータの統合を行う。このパターンでは、開発に関わるすべてのステップを自社でコントロールすることができるため、他社の開発ポリシーに影響されることがなく、たとえば基盤モデル提供会社がバージョンアップを勝手に行なってしまうなどの問題もありません。またモデルの利用料を支払う必要がないため、運用のコストを下げられる可能性があるだけでなく、構築されたモデルを他社に販売するなどのビジネスモデルも可能になります。一方で、質の高い基盤モデルの構築には何億円もの予算が必要になりますし、データの収集や人材の確保などの大きな問題をクリアしても他者を凌駕できるモデルができるかどうかは未知数と言えるでしょう。
2(+3)：既存の基盤モデルを使って、特定タスクへのチューニングを行う開発パターンです。対象用途に対して十分な応用可能性を持つモデルが入手できれば有用な開発方針ですし、実際にHuggingFace常には様々なオープンソースモデルが登場しており、商用利用可能な物の中にも高い評価を受けているものもあります。ファインチューニングにおいては、入力に対する理想的な出力例を持った学習データが必要となり、ここが一番重要なポイントと言えます。たとえば言葉で機械を操作させるようなモデルを作るためには、命令文に対応する正しい機械の操作方法が記されたデータが必要になります。ファインチューニングの学習自体は最近の研究が進み低コストで実現することができるようになってきています。
3：特に対話型のアプリケーションを前提とした場合には、すでに2のファインチューニングも実施済みのモデルも公開されています。たとえばオープンソースモデルでは、rinna社から発表されたモデルなどはこれにあたりますし、ChatGPTもこれにあたります。いずれのモデルにも学習データの「カットオフ」があり、それ以降のデータは学習対象になっていないですし、自社データにしか含まれないような情報を答えさせるためにはそのデータを統合する必要があります。前述の通りこの手法はインコテクストラーニングなどと呼ばれ、その手法は急速に発展しつつあります。後述の実践入門講座でもこの最新手法を学ぶことができます。
すでに基盤モデルの中にはオープンソース化されて提供されているものも発表されつつあり、CyberAgent社のOpenCalmなどは日本語データで開発され公開されたLLM基盤モデルの好例です。モデルの精度を評価する上では、具体的な用途を念頭に評価する必要があり、一概には言うことは難しいですが、オープンソースのモデルの中にはChatGPTなどの先進企業のモデルと同等レベルの精度を出せると謳っているものもあります。ただしこれらの比較はほとんどが英語で行われているため、日本語のアプリケーション開発には役に立ちません。そこで弊社では、JGLUEと言う汎用性の高い検証データの日本語版で様々なオープンソースモデルをChatGPTと比較したところ、様々な課題があることがわかりました：
LLMOpsは、大規模言語モデルのライフサイクル全体をカバーする新しいフレームワークになっていくでしょう。これには、モデルの開発や、チューニングだけではなく、デプロイメント、モニタリング、など、通常のMLOpsに含まれる運用的側面も今後重視されることになるでしょう。特にモデルが想定外の出力をするようなケースを検出しそれに対する対応を行ったり、ユーザーからのフィードバックを使って継続的にモデルの改善を行なっていくワークフローを自動化するなどの取り組みが注目されます。
LLMOpsに必要となる技術基盤と人材
LLMOpsを適切に実施するためには、強力な技術基盤と高度なスキルを持つ人材が必要です。以前からML開発・実装を行ってきた先進企業では、ML開発・MLOpsに関わる人材の幅は広がり続けています。
データエンジニア
データサイエンティスト
MLエンジニア
サーバーエンジニア
ITエンジニア
MLOpsエンジニア
プロダクトマネージャー
リスク・コンプライアンスマネージャー
などなど
また技術基盤としては、GPUの重要性がよく知られていますが、データ・モデルなどのアーティファクトの管理や実験結果からより多くのインサイトを得るための実験管理システム、運用時のモニタリングを行うための統合的なMLOpsプラットフォームの重要性も見逃せません。
今後LLM開発と運用をしていく人材にはどのようなスキルが求められるのでしょうか？プロンプトエンジニア？LLMエンジニア？まだ黎明期にあるこの分野では未知なことが多い質問ですが、Weights & Biasesでは先日OpenAI GPT-4/ChatGPT/LangChain 人工知能プログラミング実践入門を出版された、布留川英一さんをご招待し、学びを深めていくための実践的な入門講座を8月に開催します。特にインコンテクストラーニングとファインチューニングの手法について、ハンズオン形式でいち早くその手法を学ぶことができる内容になっていますので、ご参加をお待ちしています。
この記事が気に入ったらサポートをしてみませんか？