検索拡張生成(RAG)を用いたアーキテクチャパターンのAWSとGCPの比較
みなさまこんにちは、あるいはこんばんは。
みじんこきなこです。
今回は、検索拡張生成(RAG)を用いたアーキテクチャパターンの比較についてお話しします。
検索拡張生成(RAG)とは
検索拡張生成（RAG）とは、従来のAIチャットボットよりも、より賢く、より深い会話ができるようにする技術です。
従来のLLMで構築された生成AIを単独で用いたチャットボットは、自分の頭の中にある知識を元に、ユーザーの質問に答えていました。
このため再学習を行わない場合、学習データを作成した時点以降の知識に対しては正確に回答することが出来ず、高確率でハルシネーションを起こしてしまいます。
一方、検索拡張生成(RAG)を用いたチャットボットの場合、設定されたデータソースを元に最適な答えを探し出すことで、よりユーザーのニーズに即した答えを返すことができます。
例えるなら。。。
従来の生成AIチャットボットは、頭の中に蓄えた薀蓄を元に語るおっさんの様なもので、間違ったことももっともらしく言うけど間違っていることを認められない仕組み。
検索拡張生成(RAG)は、ネットに転がっている情報を要約してまとめ記事を作るアフィリエイターのような仕組み。
とそれぞれイメージするとわかりやすいでしょう。
検索拡張生成(RAG)のアーキテクチャ
典型的な検索拡張生成(RAG)のアーキテクチャは、極限まで抽象化すると大きく三つのパートで構成されます。
データソース
検索拡張生成(RAG)に使用するデータの提供元です。
ここにあるデータを増やせば回答はより多様になり、更新すれば回答はより新しくなります。
エンタープライズサーチ
この記事では企業で実装することを目的としてエンタープライズサーチとしましたが、データソースをインターネット全般としたサーチとしても問題ありません。
検索拡張生成(RAG)は、データソースに対して行われた情報探索の結果を元に生成AIに回答を生成させますので、RAGの中核的な要素となります。
生成AI
検索された回答を元に、自然言語での要約や解説を生成して出力するために使用されます。
チャットボットに限って言えばLLMを用いたChatGPTやGemini等を使用しますが、エンタープライズサーチを画像などに対応させ、生成AIにマルチモーダルAIを利用すれば、文章に限らず様々な回答が得られます。
RAGアーキテクチャパターン
それでは、AWSとGCPでそれぞれRAGを構築する場合のアーキテクチャパターンを見ていきましょう。
前提としていずれのクラウドサービスで構築する場合も、可能な限りフルマネージドサービスを用いた典型的なアーキテクチャで構築するものとします。
また、AIのモデルに関してはどちらのクラウドでも0から構築することができますが、そのようなやり方は考慮せずに、学習済みモデルを利用してそれぞれ最も早く簡単に構築できるアーキテクチャを想定しています。
AWSの場合
AWSの場合、RAGを用いたアーキテクチャパターンは、以下のようになります。
データソースとしては、Amazon S3やAmazon RDSなどが利用できます。
データソースの探索には、Amazon Kendraを利用することができます。
データソースを探索した結果を元にユーザに回答を返す生成AIサービスにはいくつか候補がありますが、基本的にはAmazon Bedrockを利用するのが簡便です。
GCPの場合
GCPの場合、RAGを用いたアーキテクチャパターンは、以下のようになります。
データソースとしては、Cloud StrageやBigQueryなどが利用できます。
データソースの探索および生成AIによる回答の生成には、VertexAI Search and Conversationを利用することができます。
どっちがいいの？
性能
基本的に性能面では大して差はないです。
どちらで構築しても十分な性能を持っています。
ただし前提として、AWSの場合はBedrockで利用するAIの生成モデルの選択が適切に行われていること、という注釈がつきます。
利用料金
利用料金面では、GCPの方が圧倒的に安いです。
いずれのアーキテクチャであっても、データソースの利用料金はほぼ同じですが、エンタープライズサーチサービスの利用料金がAmazonKendraの場合約1,008＄/月と高額で、なおかつBedrockの利用料金とは別に計上されます。
参考：
一方、VertexAI Search and Conversationの利用料金は、検索から回答の生成までを含めても、1000クエリ当たり19ドルと非常に安価です。
参考：
柔軟性
柔軟性面では、AWSに軍配が上がります。
今回のアーキテクチャパターンでは、AWSがBedrockを利用することを前提としていますが、Bedrockで利用できるAIの生成モデルを自由に選択することができます。
一方、GCPの場合は、VertexAI Search and Conversationを利用することを前提としていますが、こちらはAIの生成モデルを自由に選択することができません。
ただし、VertexAI Search and Conversationを利用せず、VertexAI APIなどを利用することで、生成AIのモデルを選択することはできるため、柔軟性面での差はあまり大きくないかもしれません。
セキュリティ
セキュリティ面では、どちらも十分にセキュアです。
また、データソースが学習に利用されるかどうか、という点が最も気になる点となってくるかと思いますが、これについてはどちらのサービスも利用されないので気にする必要がありません。
実装難易度
実装難易度面では、GCPの方が圧倒的に簡単です。
AWSの場合は、GCPのように検索から回答の生成までワンストップで実行することができるサービスがないため、LambdaやSageMakerなどを利用して、それぞれのサービスを組み合わせて、コーディングを伴う実装を行う必要があります。
一方、GCPの場合は、VertexAI Search and Conversationを利用するだけで、検索から回答の生成までを一切のコーディングを伴わずに簡単に実装することができます。
結局どっちがいいの？
これについては結論を述べることはやめておきます。
システムやサービスの質を比較することはできますが、実際に企業でどちらのサービスを利用するかは、その企業の事情によって異なるためです。
仮にどちらかを選んだとしても、自社内に専門家がいない製品を無理にえらんでしまんでしまうことは、最終的には自社にとってマイナスになることが多いです。
まとめ
検索拡張生成(RAG)を用いたアーキテクチャパターンは、従来のAIチャットボットよりも、より賢く、より深い会話ができるようにする技術です。
AWSとGCPのどちらでも、RAGを用いたアーキテクチャパターンを構築することができますので、、ご自身のニーズに合わせて最適なアーキテクチャパターンを選択してください。
ここから先は
¥ 300
この記事が気に入ったらサポートをしてみませんか？