この記事は、2024/10/22に公開された「The Evolution of LLMOps: Adapting MLOps for GenAI」の翻訳です。
近年、機械学習モデルの開発、展開、管理のための標準的な手法となっているのが機械学習運用 (MLOps) です。MLOps は、プロセスとワークフローを標準化し、モデルをより迅速かつ安全に、そしてスケーラブルに展開できるようにします。また、モデル管理を一元化し、展開のための CI/CD を自動化すると同時に、継続的な監視機能を提供し、ガバナンスとリリースのベストプラクティスを確保します。
その一方で、大規模言語モデル (LLM) の急速な台頭により、コンピューティングコスト、インフラストラクチャーのニーズ、プロンプトエンジニアリング、その他の最適化手法、ガバナンスなどに関する新たな課題が生じています。これに対応するために、MLOps を「大規模言語モデル運用」(LLMOps) と呼ばれるものへと進化させることが求められています。
このブログでは、LLMOps がもたらす新たなプロセスとワークフローによってどのような領域に違いが生じるのか、従来の MLOps と比較しながら説明します。
- 開発に関わる人材の広がり: 従来の ML アプリケーションでは、主にモデルの構築をデータサイエンティストが担う一方で、ML エンジニアが中心となってパイプラインの構築と運用を行っていました。しかし LLM の登場により、このパラダイムに変化が生じています。開発に携わるのは、もはやデータサイエンティストだけではありません。ビジネスチーム、プロダクトマネージャー、エンジニアもより積極的にその役割を担うようになってきています。その主な理由として、LLM によって AI ドリブンアプリケーションの開発への障壁が下がったことが挙げられます。 オープンソースモデル (Llama や Mistral など) と独自のサービス (OpenAI など) の両方の技術進歩によって、モデルの構築とトレーニングに関する複雑な作業の多くが取り除かれました。しかし、このような民主化は諸刃の剣でもあります。LLM は製品への統合が容易である一方で、コンピューティングコスト、インフラストラクチャーのニーズ、ガバナンス、品質など、対処すべき新たな課題を生み出しています。
- 中核機能としてのローコード/ノーコード: MLOps のツールは、主にデータサイエンティスト向けに設計されたものであり、API 中心のアプローチで、Python や R との統合に重点が置かれていました。LLMOps では、広範なユーザーの要求に応え、さまざまなチームが LLM にアクセスできるようにするために、ローコード/ノーコードのツールが不可欠になっています。技術者以外の関係者が最小限のコーディング知識で LLM を構築、実験、展開できるように、プラットフォームがいかに使いやすいインターフェースを備えているかを前面に押し出すことが、現在の LLMOps のトレンドです。
- モデルの最適化を重視: LLM を使用する場合、汎用モデルを対象に、独自のデータを使用して特定のビジネスニーズに合わせてモデルを微調整するのが一般的です。そのため、モデルの最適化のための手法が LLMOps の中心的な課題となりつつあります。対象となるユースケースに合わせて LLM を改良するためには、量子化、プルーニング、プロンプトエンジニアリングといった手法がきわめて重要です。最適化はパフォーマンスを向上させるだけでなく、LLM アプリケーションのコストと拡張性を管理するためにも不可欠です。
- プロンプトエンジニアリング: LLMOps の登場によってもたらされたまったく新しい概念の1つに、プロンプトエンジニアリングがあります。これは、モデルの動作をガイドするための詳細な指示を作成する手法です。プロンプトエンジニアリングは技術であると同時に科学でもあり、LLM レスポンスの品質、関連性、効率を向上させるための重要な手法として機能します。プロンプト管理のためのツールには、プロンプトチェイニング、テストプレイグラウンドのほか、高度な概念であるメタプロンプティングなどがあります。メタプロンプティングとは、ユーザーがプロンプトを活用して別のプロンプトを改善する手法であり、LLMOps を構成する重要な技術の1つです。また、Chain of Thoughts (CoT) や Assumed Expertise などの手法も、この新しい領域における標準的な戦略になりつつあります。
- 検索拡張生成 (RAG) の出現: 従来の ML モデルとは異なり、LLM を含む多くのエンタープライズレベルの生成 AI のユースケースでは、事前にトレーニングされた知識だけでなく、外部ソースから取得した関連データも利用しながら回答を生成しています。これが、検索拡張生成 (RAG) アーキテクチャの発展へと繋がりました。このアーキテクチャは、検索モデルを統合して企業のナレッジベースから情報を取得し、LLM がその情報をランク付けして要約します。 RAG は、ハルシネーション (幻覚) を大幅に減らすと同時に、エンタープライズデータを活用するための費用対効果の高い方法を提供する、LLMOps の新たな基盤となっています。RAG パイプラインの構築と管理は、MLOps 環境では存在しなかったまったく新しい課題です。LLMOps のライフサイクルでは、RAG パイプラインの構築と管理が、従来のモデルトレーニングに取って代わる重要な焦点となっています。ML モデルのトレーニングと同様に、LLM の微調整は依然として重要ですが、これにはインフラストラクチャーとコストに関する新たな課題が生じています。また、RAG パイプラインでエンタープライズデータを使用する際には、データ管理に関する新たな課題も生まれます。ベクトルストレージ、セマンティック検索、埋め込みなどの機能は、LLMOps ワークフローにとって不可欠な構成要素となっています。これらは、MLOps ではあまり一般的ではなかった領域です。
- 評価と監視の予測が困難: LLM の評価と監視は、従来の ML モデルの場合よりも複雑です。LLM アプリケーションはコンテキストへの依存度が高く、評価にあたっては特定分野の専門家 (SME) からの大量のインプットが必要になります。そこで、自動評価フレームワークという技術も登場し始めています。これは、LLM が別の LLM を評価する技術です。一方、生成モデルの予測不可能性の課題やハルシネーション (幻覚) などの問題は、依然として対処が困難です。これらの課題を克服するために、多くの企業はまず、エージェントアシスタントなどの LLM ユースケースを社内に展開し、その信頼性を確認した後、顧客向けアプリケーションをリリースするという戦略を取っています。
- リスク管理とガバナンス: モデルのリスク管理は、MLOps においても常に重要な焦点でしたが、LLMOps では新たな懸念をもたらしています。LLM がどのようなデータを使ってトレーニングされたかについては不透明な部分が多いため、プライバシーや著作権、偏見に関する懸念を引き起こしています。さらに、LLM の監査可能性と説明可能性についての問題は未解決のままです。企業では AI リスクフレームワークの導入が進められていますが、ベストプラクティスはまだ確立してはいません。当面のところ、徹底した評価、継続的な監視、承認済みモデルのカタログ作成、ガバナンスポリシーの確立に注力することが、初期の重要なステップとなるでしょう。今後は、AI ガバナンスが LLMOps ツールの重要な柱となるはずです。
企業での LLM の導入が進むにつれて、直面する独自の課題に対処するためには、MLOps から LLMOps への移行が不可欠です。そして LLMOps においては、プロンプトエンジニアリング、モデルの最適化、RAG が重要です。さらに、ガバナンス、リスク管理、評価の分野に新たな複雑さが加わったことにより、これらの高度なモデルを本番環境で適切に拡張および管理していくためにも、LLMOps の重要性が高まっています。
LLM の活用方法についてさらに詳しく知りたい方は、こちらをご覧ください。
