こんにちは、AWS re:Invent から帰国した a2 (@Atsuhiro_tim) です。すき家がサラダをつけても $5 で、その美味しさと安さに涙を流しています。

さて、AWS re:Invent 2024 のセッションカタログを見ると、今年も GenAI が猛威を振るっていたことがわかります。

昨年は Gen AI x 〇〇が多かったのですが、今年は一歩進んで、 RAG x 〇〇や Agent x 〇〇が出てきました。RAG については機能リリースのニュースは認識していたものの、実際に触ることがなかったので、今回の re:Invent で Gen AI や RAG 関連のセッションに参加してきました。複数のセッションの学びをまとめてシェアしたいと思います。

参加したセッション：

Explore generative AI use cases with LangChain and Amazon Bedrock TNC301
DEV336-R | Deep dive into Claude 3.5: Unlocking AI potential on AWS
SAS405 | SaaS and RAG: Maximizing generative AI value in multi-tenant solutions
Build a cost-effective RAG-based gen AI application with Amazon Aurora [REPEAT] DAT313-R1
AWS Jam: Generative AI (sponsored by NVIDIA) GHJ305

RAG (Retrieval-Augmented Generation) とは

だんだん認知も広がってきていますが、 RAG は Retrieval-Augmented Generation の略です。

事前に document などを chunk に分割した上で特徴量抽出 *1 をして保存しておき、プロンプト（クエリ）に対して関連する情報を特徴量から検索、関連する document を発見したのち、その情報をもとに回答を生成する技術です。

単純に LLM だけを使って回答を生成すると、LLM は学習したデータの中にある情報しか返すことできず、質問の種類によっては回答の精度が落ちてしまいます。例えば、カミナシの社外秘の情報は当然学習データには含まれないので、カミナシのプロジェクトについて質問しても、分からないと回答するか、それらしい嘘の回答をしてしまいます（hallucination と呼ばれます）。

RAG を用いると、LLM の自然言語を処理する能力を活用しつつ、元となる情報は LLM の外からも取得することができます。保存された document を解釈した結果を返すので回答の精度が高く、また、回答を生成する根拠となった元の文書にアクセスすることができるため、真偽を検証することも可能です。

RAG のよくある活用例は、社内専用チャットボットです。例えば会社の労働規定に関する資料をあらかじめ特徴量抽出して index しておけば、HR メンバーの代わりに自社のコンテキストに基づいて回答してくれます。

余談ですが、私が個人的に愛用している Perplexity というサービスは、質問をすると、インターネット検索の結果を元に回答を生成し、リンクも教えてくれます。以前は「検索→いくつかのサイトを読む→理解してまとめる」としていましたが、今はフローが丸ごと全て Perplexity に置き換わりました。Perplexity も、インターネットを Knowledge Base に見立てた RAG の一種に思えます。

Amazon Bedrock Knowledge Base の Vector Data Store は色々選択できる

特徴量と元の文書を保存しておくデータベースを Knowledge Base といいます。RAG を実行するにはこの Knowledge Base が必要です。

Amazon Bedrock でも Knowledge Base 機能が提供されているのですが、特徴量データを保存するデータストアは Knowledge Base 機能自体には含まれておらず、作成画面で保存先を指定します。

Knowledge Base の作成時あわせて新規でデータストアを作る場合は、2024年12月12日時点では以下が選択できました。

Amazon OpenSearch Serverless
Amazon Aurora PostgreSQL Serverless
Amazon Neptune Analytics (GraphRAG)

既存のデータストアを利用する場合は、上記に加えて以下も選択できるようです。

Pinecone
Redis Enterprise Cloud

初めはデフォルトの Amazon OpenSearch Serverless を選択するのが良いと思いますが、Workshop で同じテーブルにいた方が AWS Solutions Architect (SA) の方に Amazon OpenSearch Serverless が高いことについて文句を言っていました（正確な英語は聞き取れなかったのですが、概ねそんな感じでした）。Index がそれなりのデータ量になるらしく、コストは監視しておいた方が良さそうです。

ただし、特徴量を自動で抽出してくれる機能は Amazon OpenSearch Serverless にしかないとのことで、そういった実装・運用は自前で行うことを認識した上で、コストとのバランスを考えて他のデータストアを検討してください。

ちなみに、選択肢の一つにある Pinecone ですが、有名らしいです。私は Knowledge Base は詳しくなく、知らなかったのですが、Expo のブースで話を聞いてみたところ、大量のワークロードがある企業で、1/100 以上のコスト削減に成功した事例があるくらい、安いそうです。

ユーザーに直接 RAG 相当の機能を提供するような場合は、顧客に応じてデータ量が増えていくので、こういった外部データストアの検討も必要になりそうです。

マルチテナントの考慮

マルチテナントサービスで RAG を提供する際に、他の企業のデータにアクセスできないように制御する Workshop にも参加しました。

workshop の内容はこちらです。

catalog.us-east-1.prod.workshops.aws

Workshop で用いる構成は以下のよう。

構成図の左の方がデータを Knowledge Base に投入するフローで、右がユーザーのプロンプトから RAG を実行するフローです。Knowledge Base はテナントごとに用意されています。

図には書かれていませんが、ユーザーのクエリを処理する lambda (右)では、テナントIDと Knowledge Base ID の対応を DynamoDB に保存し、動的にアクセスを制御する仕組みです。

他の lambda でも、データがどのテナントに属しているかを意識して処理する必要があり、この図だと、合計で 4 箇所でテナント分離を考慮しています。

率直に、煩雑だなと感じてしまいました。

もちろん、実際のサービス提供では Lambda ではなく Compute Instance を使ったりと、ユースケースごとに差分は発生しますが、いずれにせよ複数の箇所で同じ権限制御を実行する必要があり、うまいこと共通化できるのか、改修する際に修正漏れが起きないのか、不安になる図です。

誤って別のテナントの Knowledge Base にデータを入れてしまっても気づきにくそうなのも気になります。もしマルチテナントで RAG を提供したい場合は、一度 SA さんに相談するのが良さそうです。

コスト最適化はモデル選択から

具体のシナリオを想定して RAG のコスト最適化について議論されるセッションにも参加しました。大まかに以下のようなシナリオでした。

大きすぎも小さすぎもしないワークロード
LLM は Claude 3.5 Sonnet
embedding は Titan Text V2
data store は Amazon Aurora PostgreSQL

以下のように、LLM の呼び出しがコストのほとんどを占めているシナリオです。

実際の運用ではこういったバランスになることも珍しくないようで、以下のような対策が提案されました。

Claude 3.5 Haiku を使う
- 必ずしも大きいモデルを使うことが良いわけではない。
- Sonnet ではなく小さいモデルの Haiku でも十分な性能はあるし、むしろ response が早くなって体験が良くなるケースもある。
プロンプトを改善する
- 必要以上に長いプロンプトを短くする
- 適切なプロンプトを見つけるために実験を繰り返すことが大事
適切なチャンクサイズを見極める
- 小さすぎるチャンクは index size を増加させ、検索にコストがかかるようになる
- 大きすぎるチャンクは LLM のコンテキスト長を超えてコスト増につながる

他にも、よくある質問のプロンプトは結果をキャッシュして返すことでコスト削減する方法も議論されました。

プロンプトは自然言語なのだから、完全一致することは少なく、どうやってキャッシュするのか疑問に思いましたが、「プロンプトが書き始められたら予測補完で残りの文章を提案する」ことでキャッシュヒットさせるという技法でした。既存の検索サービスも同様なのかもしれませんが、予測補完に体験向上以外の効果があるのは面白いアイデアだと思いました。