この記事について
RAG（Retrieval-Augmented Generation）は、質問への回答を生成する際に外部データベースの情報を取得することで、LLM単独では応えきれない問題(最新の情報、社内独自の情報など)へ対応する技術です。
最近話題になっているので、いちど試してみたい！と思っている方も多いのではないでしょうか？
しかし、試してみたいと思っても使うモデルや技術・サービス・手法等々いろいろな情報が溢れていて結局何をどう使えばいいのかわからん…ということになりがちです。
この記事では、「難しいことはわからんが、とりあえずRAGというものを構築してみたい」という方向けに、AWSおよびGoogle Cloud上に少なめの準備でRAGを作って試す手順を紹介します。
とりあえず作ってみて、難しいことは後で考えればいいじゃない！という精神でRAG＋API呼び出しの構築を進めてみて、実際に動作させた感触やかかった利用料などを紹介できればと思います。
なお、この記事を書いている私自身、RAGの手法や精度向上にまったく詳しくないけどとりあえず構築してみた人間のひとりです。
外部情報の準備
RAGを構築する前に、まずは外部データベースに置くための情報を準備する必要があります。
こういうRAG構築例では最新生成AIサービスの説明を書いたPDFなんかがよく使われるんですが、特にそういったものも準備していなかったので…
色々考えたんですが、一般的な生成AIでは答えられない情報として、「我が家のハムスターの情報」を読んでもらおうと思います。
↓こんな感じのテキストファイルを2つ準備しました。文字コードはUTF-8で保存します。
我が家のハムスター一覧（ゴールデン）
あずき（メス）2022年10月生まれ
ぽん（メス）2023年5月生まれ
我が家のハムスター一覧（ジャンガリアン）
しらす（オス）2023年1月生まれ
きなこ（メス）2023年5月生まれ
さくら（メス）2023年11月生まれ
ちま（性別不明）2024年2月生まれ
AWS編
AWSではAmazon Bedrockのナレッジベースを使用します。
ナレッジベースで外部から与える情報源と使いたいデータベースサービスを指定すると、RAGを構築できるようになっています。
手順の詳細については長くなってしまうので、別記事に纏めました。↓をどうぞ。
https://qiita.com/ckw-1227/items/fac42740ba2341cf3947
Google Cloud編
Google CloudではVertex AI Search and Conversation（新サービス名：Vertex AI Agent Builder）を利用することで、AWSと同じような手順でRAGを構築することができます。
こちらも手順の詳細は別記事に纏めました。↓をどうぞ。
https://qiita.com/ckw-1227/items/37a7c1f0c5e63d9b9e8f
AWSとGoogle Cloudの比較
構築の難易度
どちらもストレージバケットにテキストファイルを入れ、それをデータソースにしてRAGを構築していくという流れは変わりません。難易度はどちらも低いと言えると思います。
ただ、細かく比較すると、AWSの方がやや難しいかな、と感じました。
Google Cloudは特に深く考えずコンソールで操作するだけで構築が完了しましたが、AWSではエージェント作成時にモデルへの指示が入力必須となっており、何を入力するべきかちょっと悩みました。
あとは最初の大前提として、AWSではモデルの選択で迷います。日本語を扱うと考えるとClaude一択にはなりましたが、詳しくない人間だとかなり迷ってしまいます。
自由度
上記の難易度が自由度にも直結するのですが、自由度はAWSの方が高いです。
やはり大きいのは選択できるモデルが豊富な点。Google Cloudでは現状選べるのはPaLM2とGeminiだけでしたので、使いたいモデルがある場合はAWSの方が選択肢となりやすいのではないでしょうか。
利用料
気になる利用料については、Google Cloudの方が格段に安いです。
AWSはナレッジベース作成時にOpenSearch Serverlessのリソースが作られますが、そのリソースが存在するだけで1日数ドル課金されるので、一定期間運用しようとするとその部分がかなり痛い出費となります。
もちろんOpenSearch以外の外部ソースを指定することも可能ですので、そちらの費用が抑えられるようなら何とか…という感じになります。
対してGoogle Cloudでは、Vertex AIはクエリ実行分の課金のみなので検索しなければ課金はされません。
生成AIモデル自体の利用料に関しては、AWSはトークンあたりの計算、Google Cloudはクエリあたりの計算になるため比較が難しいですが、使ってみた感覚だとそれほど大きな差はなさそうです。
（あとは個人的な事情ですが、BedrockではAWSの無料クレジットが使えないのがちょっとツラいです。。。）
その他、構築してみた感想など
アップデートの多さ
まず何より先に、コンソールやらサービス名やら変わりすぎ！！！！！
3月末に一度テスト作成をして4月に改めて記事を作ったのですが、AWSではコンソールががらっと変わっていてもう一度テスト作成からやり直しになりましたし、Google Cloudでは記事を書いているタイミングでサービス名自体が変わって記事の文章を書き直すハメになりてんやわんやでした。
ちょっと苦労はしましたが、それだけアップデートが頻繁にされていて今アツい技術なんだということを身をもって知りました。
この記事自体もすぐ古いものになりそうですので、構築にチャレンジする方は最新の情報を調べての構築をよろしくお願いします。
RAG構築の手軽さ
AWS、Google Cloudともにストレージバケットからテキストファイルをアップして、その情報をコンソール上で指定するだけでRAGのデータソースにすることができるという手軽さ。
コードを全く書かずにRAGを構築することができ、コンソール上でテストまでできる。
難しいことが分からなくても生成AIを利用できるのは、とてもありがたいと思いました。
生成AI、RAGの奥深さ
手軽にRAG構築はできるのですが、構築ができて回答が返ってくるようになると、今度は回答の精度を上げたりハルシネーションを回避したりと、いろいろと手を入れたくなります。
ただ、精度を上げようと少し調べてもやっぱり難しくてわからない…！という壁にぶつかります。
生成AI、RAGは奥深いなと改めて実感しました。もっと頑張って勉強しようと思います。
まとめ
AWS、Google Cloudどちらの環境でも、難しいことがわかっていなくてもRAGを構築することができ、LambdaおよびCloud Functonsから呼び出すところまでできました。
今後アップデートが進むことで、利用者の裾野も広がっていくのではないかと思いました。
半面、やはり少し手を入れようとするとある程度の知識が必要になることもわかりました。
また、簡単ではありますがAWSとGoogle Cloudの比較を行い、同じ生成AIサービスであってもそれぞれの特色が出ていることがわかりました。
（ちなみに、私自身が趣味で運用している生成AIサービスはGoogle Cloudで作成しています。やっぱり利用料の差は大きい…。 そのうち記事でそちらのサービスも紹介できたらと思います。）
以上、難しいことはわからないけどRAGというものを知りたいと思っている方に届けば幸いです。