Amazon Web Services ブログ

AWS での生成 AI アプリケーション運用: その１ – LLMOps ソリューションの概要

生成 AI の人気が高まる中、企業は基盤モデル (FM) について詳しく調査し、ビジネスにもたらすメリットを実感しています。FM は膨大なデータで事前学習された大規模な機械学習モデルで、テキスト生成、コーディング、画像生成など多くのタスクを実行できます。独自の学習モデルを構築したり、FM をファインチューニングしたり、これらのモデルを活用したアプリケーションを展開したりする企業も増えてきました。そういった背景から、これらのプロセスの運用管理手法を確立し、スピード、コスト、品質を最適化するためのベストプラクティスを実践する必要性が高まっています。

大規模言語モデル (LLM) は、要約、テキスト生成、分類、質問応答などの言語を扱うタスクに焦点を当てた大規模な言語モデルの一種です。大規模言語モデルオペレーション (LLMOps) は、基盤モデルオペレーション (FMOps) のサブセットで、LLM の運用管理に使用されるプロセス、手法、ベストプラクティスに焦点を当てています。LLMOps を導入すると、モデルの開発効率が向上し、複数のモデルを管理するためのスケーリングが可能になります。FMOps は、機械学習ソリューションを効率良く製品化するための人材、プロセス、テクノロジーの組み合わせである機械学習オペレーション (MLOps) の概念に由来しています。MLOps の手法に加えて、生成 AI モデルやアプリケーションの運用に必要なスキル、プロセス、テクノロジーを付け加えています。

このブログはゲーム業界向けの LLMOps に関する全 3 回のシリーズの第 1 回目です。AWS での LLMOps 実装に必要な使用事例、サービス、コードを説明します。今回は LLMOps の入門、ソリューションデザインの概要、ゲーム業界における具体的な使用事例についてご案内します。

ゲームにおける LLMOps の活用事例

ゲーム業界のユースケースを見ていきましょう。お客様がどのように生成 AI を利用して、開発者の生産性とゲーム体験の品質を高めているかを確認します。

ノンプレイヤーキャラクター(NPC)のユニークな対話
ゲームを途中から再開できることはプレイヤーにとって重要です。プレイヤーは強敵に何度も敗北しても、特定のセクションを初めからやり直す必要がなくなります。ゲームをやり直すとき、NPC との会話やカットシーンがその度に違うものであればプレイヤー体験が向上する可能性があります。NPC に LLM を組み込むことで、ゲームの設定やプレイヤーに提示する必要のある情報の内容は担保しつつ、NPC には会話の度に異なった返答をさせることができるようになります。

スクリプト作成の効率化
NPC には時として特定の決められたスクリプトを話してもらう必要があります。LLM はこのようなスクリプト作成の効率化にも活用できます。ゲームの背景設定、状況、期待される結末をモデルに提示することで、複数の異なる NPC に対してそのキャラクター設定に応じたセリフをすばやく生成することができます。これによりスクリプト作成者の作業効率が向上し、彼らは新しいキャラクターやアイデアの制作や検討により多くの時間を費やせるようになります。

テキストチャット、ボイスチャットに対するモデレーションおよび有害性検知
テキストチャットやボイスチャットを提供するオンラインゲームにとって、フレンドリーな冗談や軽い罵り合いは受け入れつつも、不適切な発言は許容しないといった健全なゲームコミュニティの維持は難しい課題となっています。モデレーションワークフローを構築して、通報されたプレーヤーのチャットを分析し、そのプレーヤーの発言がゲームパブリッシャーのガイドラインに適合しているか判断するというのが、この課題への対応策となりえます。LLM はプレーヤーの発言の文脈を理解し、対策を講じるべきかどうかを判断する評価エージェントとして使用できます。

モデル カスタマイズのためのデザインパターン

企業がこれらのユースケースを導入するためには、生成 AI アプリケーションが必要です。生成 AI アプリケーションの中核は、1 つ以上のモデルです。アプリケーションは基盤モデルをそのまま使用でき、広範なプロンプトエンジニアリングにより、質の高い結果を得ることが可能です。一方で、ほとんどのユースケースではモデルをカスタマイズすることによってさらなるメリットを享受することができます。以下で説明するように、モデルのカスタマイズには様々な方法があります。

モデルのカスタマイズ手法
ファインチューニング – 独自のデータを用いて基盤モデルを調整 この手法ではモデルのパラメータが変更されるため、多大なコンピューティングリソースを最初に必要とします。しかし、この方法によって、これまではできなかったタスクを実行できるように FM をトレーニングすることができます。

事前学習 – 大量の未ラベルデータのリポジトリを使ってモデルをゼロから学習させる これにより、最大限の制御と カスタマイズが可能になりますが、大量のデータ (テラバイト単位の場合が多い)、機械学習の深い知識、大量のコンピューティングリソースが必要になります。事前学習は、実行させたいタスクに適したファインチューニング可能な基盤モデルがない場合に使用されます。

検索拡張生成 (RAG: Retrieval Augmented Generation) これはファインチューニングの代替手法で、モデルパラメータを変更しない手法です。あらかじめドメインデータをベクトル埋め込み表現に変換し、ベクトルデータベースに保存しておきます。検索時にはプロンプト入力の埋め込み表現とベクトルデータベースの類似検索を実行し、得られたデータをプロンプトのコンテキストとして使用します。

ユースケースごとに最適なカスタマイズ手法は異なります。ファインチューニングは、ゲームの設定に合わせてモデルを調整し、NPC のベースとして利用したり、異なる NPC について異なるプロンプトテンプレートを利用するなどの、ドメイン適用に優れています。根拠が明確で信頼性の高い応答が重視されるユースケースにおいて、RAG はファインチューニングよりも効果的な手法となりえます。さまざまなキャラクターの人格ごとにスクリプトを事前に用意しておき、そのスクリプトにもとづく応答をさせたい場合がその例として挙げられます。このようなスクリプトは更新される可能性があり、スクリプトが更新されるたびにベクトルデータベースにもその変更を取り込む必要があります。ですが、そのプロセスが自動化されていれば、どんなに頻繁にスクリプトの更新が発生しても問題にはなりません。RAG はゲームスタジオにとって、知的財産とゲーム固有のデータを保護する観点でも有効な手法です。RAG を活用することで、再学習やファインチューニングでモデルにデータを直接組み込むことなく、FM に対して安全で統制されたアクセスを提供できます。

カスタマイズ手法によらず、モデルやアプリケーション全体の変更を処理するための LLMOps パイプラインを構築することにより、高速なイテレーションを実現することができます。

LLMOps の概要

LLMOps には、継続的インテグレーション(CI)、継続的デプロイメント(CD)、継続的チューニング(CT)の 3 つの主要フェーズがあります。

CI とは、アプリケーションのすべての作業コピーのコードを 1 つのバージョンに統合し、そのバージョンでシステムテストとユニットテストを実行することです。LLM やその他の FM を使用する際、ユニットテストはモデルの出力に対する手動テストが必要になることがよくあります。例えば、LLM を使って実装されている NPC の場合、NPC に彼らのバックグラウンド、ゲーム内の他のキャラクター、設定について質問することでテストができます。

CD とは、モデルのパフォーマンスと品質を、メトリックスによる評価や人が関与するプロセスによって評価した後、指定された環境にアプリケーションインフラストラクチャとモデルをデプロイすることです。
一般的なパターンは、まず開発環境と 品質保証(QA)環境にデプロイし、その後本番(PORD)環境にデプロイすることです。QA 環境へのデプロイと PROD 環境へのデプロイの間に人間が介在する承認プロセスを入れることで、PORD にデプロイする前に新しいモデルが QA で適切にテストされていることを確認することができます。

CT とは、前のセクションで説明されているように、FM に追加データを使用してモデルのパラメータをファインチューニングし、最適化された新バージョンのモデルを作成するプロセスです。このプロセスは一般に、データの前処理、モデル調整、モデル評価、モデル登録で構成されています。モデルがモデルレジストリに保存されると、レビューを受けてデプロイが承認されます。

AWS での LLMOps

次の図は、AWS 上の LLMOps ソリューションの概要図です。

The diagram describes the LLMOps architecture, with API gateway exposing Text and RAG API, and Bedrock LLM serving those prompts. For RAG, we have Amazon OpenSearch service and Bedrock Embeddings model for generating embeddings. The whole application is wrapped in a CI/CD pipeline using AWS CodePipeline and CodeBuild services.

全体像としては、この設計では、以下のインフラストラクチャが展開されます。

この 3 部構成のブログ記事の第 2 回目では、このアーキテクチャおよび、各サービスが互いにどのように連携しているかについて、より深く掘り下げていきます。

デプロイ

この AWS ソリューションをデプロイする方法は 2 つあります。

  1. このアーキテクチャは、Dynamic Non-Player Character Dialogue on AWS というソリューションとして公開されています。GitHub リポジトリに、このソリューションのデプロイ方法が記載されています。
  2. Operationalize Generative AI Applications using LLMOps ワークショップでは、AWS 上にこの LLMOps を展開するための手順を詳しく説明されています。

まとめ

現在、多くのゲーム会社が多大な労力を費やし、NPC のスクリプト作成、様々なシナリオのスクリプトマッピング、プレイヤーからのフィードバックのレビューを行っています。このブログでは、ゲームやゲームバックエンドにおける大規模言語モデル(LLM)が、プレイヤーにユニークな体験を提供し、マニュアル作業を省力化する方法を探りました。これにより、企業はお客様のために最高のゲーム体験を作り込むことに注力できます。LLMOps は大規模にモデルを調整および管理するための運用プラットフォームを確立するための基盤となります。

第 2 回では、上述のアーキテクチャについて詳しく説明し、AWS リージョン間とアカウント間にまたがって生成 AI アプリケーションを管理できるソリューションを実現するために、それぞれのサービスがどのように連携しているかについて解説します。

この記事は Operationalize generative AI applications on AWS: Part I – Overview of LLMOps solution を翻訳したものです。翻訳はソリューションアーキテクトの小森谷が担当しました。