はじめに

先日、10月17日から19日にかけて、AWSが生成系 AI を集中的に学び、最新動向を知るセミナーとして「AWS AI Week For Developers」を開催しました。

AWSでは、先日発表されましたBedrockにて本格的に生成AIのサービスを開始したのですが、今回はそれらをどのように活用して欲しいかという事が語られていました。

今回は3日目の「アドバンストトラック」の発表内容をいくつかのトピックに再分類したうえで解説します。

RAG と Fine Tuning

生成AIを、ビジネス上の質問に答えるチャットボットとして利用したいという方は多いと思います。しかし、生成AIは限られたデータセットを用いて事前に学習されたモデルを利用しているため、その際に与えられていない情報には答えられないという点に注意する必要があります。

そして、同じ生成AIを利用して他社と差をつけるという意味でも、自分たちの持つデータを用いてモデルをカスタマイズするということは必須と言えます。

モデルのカスタマイズのアプローチとしては、RAG(検索拡張生成)とFine-Tuningの2種類が挙げられています。

• RAGは、モデルを検索エンジンと組み合わせて新たな情報を得る手法です。初めに、質問文と近い文書を検索してから、その内容をプロンプトに付与して、それを基にしてモデルに思考させるという構成をとります。 この手法は、基盤モデルをそのまま使いながら情報を加えられるため、現在はFine-Tuningよりもよく使われている手法ですが、文書をベクトル化するための埋め込みモデル、そしてデータベースが別途必要になります。 そして、検索した文書と思考の指示を行うためにプロンプトが長くなり、トークン数の肥大化やレスポンスの低下といった副作用もあります。
• Fine-Tuningは、基盤モデルを、新たな教師データ（入力文と期待する出力文のペア）に適合するように、モデルを再学習して更新する手法です。 この手法は、まず再学習を行うための計算コストが（時間、金銭共に）発生します。とくにパラメータを大量に持つモデルであるほど、計算コストは莫大にかかり、さらに本来のモデルの働きが失われるような破壊的忘却のリスクもあります。そのため、比較的小規模なモデルを特定の用途に特化させたい場合、より高度な専門知識が求められるケースで利用することが推奨されています。 再学習コストを抑えるために、PEFTと呼ばれる、一部のパラメータのみを学習させる手法も考案されています。 代表例として、LoRAと呼ばれる基盤モデルの99.9%を凍結し、残り0.1%の低ランク行列だけをチューニングする手法が紹介されました。

両者の相違点を比較すると以下のようになります。 |RAG|Fine-Tuning| |—-|—-| |モデル自体は更新しない|モデルを新規のデータによって更新する| |再学習のコストはかからない|手法にもよるが莫大な再学習コストがかかる| |情報ソースを提示して説明性を担保できる|文体や出力形式など、モデルの振る舞いを変更できる| |プロンプトが肥大化し、入出力コストや応答時間が増加する|プロンプトの長さには影響しない|

また、RAGとFine-Tuningを併用するパターンとして、Amazon EUの倉庫デザイン・建設部門でのサポートbotの事例が紹介されました。 こちらでは建築関連の専門知識によってFine-Tuningしたモデルと、汎用のモデルの2つを用意しており、最初にプロンプトで、Tuning済みのトピックか否かを判断します。 そして専門内の話題であればFine-Tuningのモデルを、そうでなければ汎用モデルをRAGと併用して利用するというという構成をとっていました。 多くのケースではRAGで十分だと考えられますが、より専門的な知識を学習させる必要があるならば、両者を併用する事も検討できると言えるでしょう。

LLM活用パターン

生成AIを活用する際に使えるAWSのサービスについても説明がありました。 – Bedrock : Claude や Amazon Titan など、基盤モデルを提供する – Kendra : 検索サービスで、RAGにおける文書検索に利用する – DynamoDB : チャットの履歴を保存できるDBで、履歴をプロンプトに加える事で、会話を記憶できないAPIからの呼び出しでもチャットを継続できる – Lex : ルールベースのチャットボット作成用のツールで、想定している質問であればこちらで対応し、範囲外についてはAIを利用するというケースもある

以上のようなサービスを利用してシステムを構築した際、どのようにして効果を評価するかという点についても話題があり、具体的には以下のようなチャートが提示されました。

• ラベル付きデータがあるか？ — Yes: 分類タスクか？ — Yes: Accuracy,Precision,F1など、機械学習で一般的なメトリクスを利用 — No: ROUGEやコサイン類似度といった文の類似度を測る値で、出力文と正解ラベルの類似度を計測する — No: 評価を自動化するならLLMで、しないなら人力で評価する必要がある

また、生成AIを利用したソフトウェア開発用のライブラリ LangChain には、質問文と出力文のペアを自動生成する機能も含まれているとのことで、評価の際には役に立ちそうです。

最後に、生成AIを継続的に改善し運用するFMOps/LLMOppsという概念についての説明もありました。今後、推論コストの肥大化に対応するためにはモデルを常に最適化させ、なるべくコンパクトに動作させる必要があるとのことでした。 具体的な方法としては、特定のタスクに特化した小規模のモデルをいくつも用意しておき、処理の際にはタスクを分割し、それぞれのモデルに分散させるといった手法や、 ユーザーのフィードバックを記録し、評価の低い出力傾向を分析して調整を行うといった運用について語られていました。

BedrockとSageMakerの機能

最後に、AWSでAIを使うためのプラットフォームであるBedrockやSagemakerの機能についてまとめました。 – Sagemaker JumpStartでは、Bedrockで利用できるモデルよりもはるかに多い400種類以上の言語モデルと、それらをすぐに利用できるサンプルが用意されています。 利用できるモデルの例に、日本語特化型のRinnaなどがあり、Bedrockの実験場のような位置づけと言えます。これらはSagemaker Studioの機能を使って、すぐに利用可能なエンドポイントとしてデプロイしたり、ノートブックを利用してアプリの開発が可能です。 – Sagemaker Containerは、Sagemakerにおいて低コストでモデルを利用できるようにするためのコンテナ化技術であり、 利用されている技術として、複数GPUにモデルを分割するシャーディングや、モデルのサイズを削減する量子化、ローリングバッチ、レスポンスストリーミングによる処理の高速化が挙げられます。 – Agent for Bedrockは現在プレビュー中の、Bedrockをビジネスで使う上で目玉となるであろう機能です。 上記で解説したRAGを、簡単に実装できるように特化した内容であり、ワークフローの管理やAPI連携の自動化ができます。 RAGの構成にはベクトル化されたデータベースが必要ですが、こちらではS3にそのまま保存したデータを指定するだけで簡単にモデルとの接続が可能で、ドキュメントを利用するためのプロンプトの作成も自動でやってくれます。 APIとの連携は、事前にAPIスキーマを登録しておくことで、必要なアクションをモデルが判断し、Lambdaに登録しておいた関数を実行します。 例として、「おすすめのホテルはないか」と質問するとデータベースから近くのホテルを検索し、その次に「予約して」と言えばホテル予約のAPIを呼び出す、といった挙動のチャットボットが紹介されていました。

おわりに

以上が、セミナーでの主な発表内容でした。

個人的には、基本的なトピックだけではなく、現在の生成AI開発ではマイナーなFine-TUningeの利点や、今後競争が激しくなっていくである業界に対応するために、コンパクトにモデルを活用し運用するという話が印象に残りました。 どこの企業も生成AIを効率化に取り入れることが今後は当たり前になっていくと考えられるので、その中でただ漠然とある基盤モデルを使用するのではなく、自分たちの強みを活かすためにチューニングできるか、が今後差をつけていく上で重要になりそうですね。