はじめに

こんにちは、フクナガです。
AWS re:Invent 2024 内で Amazon Bedrock ナレッジベースが GraphRAG をサポートするようになったとアナウンスがありました！
Amazon Bedrock の新しい機能により、データ処理と取得が強化されます
GraphRAG について語られるコンテンツが増えてきていたので言葉は知っていましたが、
ここまで注目度の高いものだと思っていなかったので、非常に驚きました！

ただ「そもそも GraphRAG って何なんだ」と思っている人も少なくないと思います。
今回は、GraphRAG そのものについて解説しながら、実際に Amazon Bedrock で実装する際のやり方をご紹介したいと思います！
最後には、従来のベクトルデータを用いた RAG との出力結果の違いも簡単にお見せしていきます！

GraphRAG とは

GraphRAG とは、「グラフデータベースを用いて RAG を実装するソリューション」です。

「どゆこと？？」
となった人はまだ読むのをやめないでください。ちゃんと解説します！

まず、グラフデータベースとはデータ間の関係性を表現することができるデータベースです。
AWS でいうと「Amazon Neptune」がグラフデータベースとして提供されているサービスとなります。
参考：グラフデータベースとは?

従来の RAG では、AWS だと Amazon Kendra や Amazon OpenSearch、Amazon Aurora などを活用した
ベクトルデータに対して検索をしていたと思います。
RAG 用途において、なぜ「グラフデータベース」を使う方法が注目されているのでしょうか？

なぜグラフデータベースは RAG を高性能にするのか

ずばり「関係を表現することができる」からです。
ベクトルデータではデータ間の「類似度」はわかっても「関係」に関する情報を得るのは難しいです。
データ間の関係を表現するグラフデータベースとベクトルデータを組み合わせることで高い精度を得ることができます。
参考：The GraphRAG Manifesto: Adding Knowledge to GenAI

AWS で実装する際はそこまで深いことを考えなくてもよさそうですが、一般的な GraphRAG を使用するパターンについても抜粋してご紹介します。

GraphRAG を使用する一般的なパターンの 1 つは次のとおりです。

1. ベクトルまたはキーワード検索を実行して、初期のノード セットを見つけます。
2. グラフを走査して、関連するノードに関する情報を取得します。
3. 必要に応じて、PageRank などのグラフベースのランキング アルゴリズムを使用してドキュメントを再ランク付けします。
出典：The GraphRAG Manifesto: Adding Knowledge to GenAI

関連情報を検索することができるので「検索精度が良くなりそうだな」というのがなんとなくつかめたかなと思います。

GraphRAG についての結論

覚えておくべきなのは「GraphRAG を実装すると、従来 RAG よりも回答精度が上がる場合がある」ということです。（ユースケースによると思うので断言は控えます）
GraphRAG については、解説ページや論文もたくさん発表されているので、興味がある方はチェックしてみてください！！
参考：
・GraphRAGとは何かを解説、従来型RAGとの違いは？活用手順もイチから紹介
・Improving Retrieval Augmented Generation accuracy with GraphRAG
・The GraphRAG Manifesto: Adding Knowledge to GenAI

Amazon Bedrock ナレッジベースを利用した GraphRAG 環境構築

このブログで実装する環境は下記です。

Amazon Neptune の利用料金

本構成については、ナレッジベース、言語モデル、Amazon Neptune のそれぞれの課金が発生します。
料金の大部分を占める Amazon Neptune について料金をご紹介します。

Amazon Bedrock ナレッジベースで自動で作成される Amazon Neptune については下記です。
エンジン： Amazon Neptune Analytics
サイズ：16 m-NCU

m-NCU については、公式ページに下記の案内があります。

各m-NCUは、1時間の計算およびネットワーク容量と1GiBのメモリに相当します。
出典：Amazon Neptune Analytics を用いた膨大なグラフデータ分析とベクトル検索の紹介

バージニア北部リージョンの場合、16 m-NCU は 0.48 USD/h になります。
1か月で 345.6 USD (約 5.4 万円)ですので、他のベクトルデータベースより少々高額になるようです。
※2025/1/23時点のレートで計算
参考：
Amazon Neptune の料金
【生成AI】Amazon OpenSearch Serverless と Amazon Aurora を RAG 用途で比較してみた
生成 AI ワークロードに特化した Amazon Kendra GenAI Index を深堀してみよう！

GraphRAG 実装してみた

※本手順は us-east-1(バージニア北部リージョン)で実施しております
検索対象として利用するデータとして AWS のホワイトペーパー集を選びました。
あらかじめ検索対象のデータを Amazon S3 に格納しています。
ここからは構築の手軽さを知ってもらうため、実際に構築するまでの手順をご紹介します。

1. Amazon Bedrock コンソールへ遷移する

2. 左側メニューの「ナレッジベース」を押下する

3. 「ナレッジベースを作成」>「Knowledge Base with vector store」を押下する

4. 下記を入力、選択し、「次へ」を押下する

ナレッジベース名：任意の値
データソースを選択：Amazon S3

5. 下記を入力、選択し、「次へ」を押下する

データソース名：任意の値
S3 URI：RAGのデータソースにしたいファイルもしくはパスを入力する
※「S3を参照」から実施するのが、最も確実です

6. 下記を入力、選択し、「次へ」を押下する

埋め込みモデル：今回は「Titan Text Embeddings v2」を選択
ベクトルストアの作成方法：「新しいベクトルストアをクイック作成」
ベクトルストアを選択します：Amazon Neptune Analytics (GraphRAG) – Preview

7. 設定した内容に問題がないか確認し、「ナレッジベースを作成」を押下する

しばらくは同じ画面のまま待機することになります。
少々お待ちを。。。

下記のポップアップが表示されたらデータソースの作成が完了です。

8. 「データソース」から利用するデータソースを選択し、「同期」を押下する

同期が正常に開始されると下記のポップアップが表示されます。

またここからしばらく待ちます。

同期が完了すると、下記のポップアップが表示されます。

これにて環境の構築は完了です！
待ち時間はそれなりにあるものの、構築に伴う作業コストはかなり少ないのではないでしょうか。
ベクトルデータベースを使う従来の方法でも構築した経験がありますが、正直ほとんど作業手順に違いはなかったなという印象です。

構築した GraphRAG を検証してみた

検証した環境で AWS に関わる質問をしてみたいと思います！

様々なデータソースを使って回答してくれていて「すごい！」とはなったのですが、
「GraphRAG がすごい」のか、「RAG という手法そのもの」がすごいのかわかりづらいので、
ベクトルデータベースで構築した RAG でも同様の質問をしてみようと思います。
※可読性のため改行など、元の回答の一部を変更しております

比較対象として Amazon OpenSearch Serverless をベクトルストアとした RAG 環境を構築しました！
参考：Amazon BedrockのKnowledge Baseを構築し、Claude 3 Haikuを使ってみた

GraphRAG と ベクトルデータによる RAG を比較してみた

ケース1：マイクロサービスにおけるベストプラクティス

プロンプト

AWSを活用してマイクロサービスアーキテクチャを実装する際、気を付けるべき点を教えてください。

【GraphRAG での回答】

AWSを活用してマイクロサービスアーキテクチャを実装する際、以下の点に気を付ける必要があります：
1. スケーラビリティと複雑性のバランス：
マイクロサービスはアプリケーションとチームのスケーリングを容易にしますが、同時にアーキテクチャの複雑性と運用の負担が増加する可能性があります。AWSのマネージドサービスを活用して、この複雑性を最小限に抑えることが重要です。
2. 分散モニタリング：
多数の分散したサービスで構成されるマイクロサービスアーキテクチャでは、全体的な可視性を確保することが課題となります。Amazon CloudWatchを使用して、リソースの使用状況、アプリケーションのパフォーマンス、運用の健全性を監視し、システム全体の可視性を確保することが重要です。
3. セキュリティとコンプライアンス：
各サービスのユーザーアクションの可視性を確保し、組織レベルで全サービスの概要を把握することが重要です。AWS CloudTrailを使用してAPI呼び出しを記録し、AWS Configを活用してコンプライアンス違反を検出し、自動的に対応することが推奨されます。[1][2][3][4]
4. サービス間の連携：
マイクロサービス間のワークフローを効率的に管理するために、AWS Step Functionsを活用することができます。これにより、順次的および並列的なステップを組み合わせた複雑なワークフローを実装できます。
5. 継続的な改善：
マイクロサービスアーキテクチャは頻繁に変更が発生するため、変更の追跡と監査が重要です。AWS CloudTrailを使用して、予期しない動作、ポリシー違反、デバッグのために全てのユーザーおよび自動化システムのアクションを記録し、分析することが推奨されます。

これらの点に注意を払いながら、AWSの豊富なマネージドサービスを活用することで、マイクロサービスアーキテクチャの利点を最大限に引き出しつつ、課題を最小限に抑えることができます。[5][6]

【ベクトルデータによる RAG での回答】

マイクロサービスアーキテクチャをAWSで実装する際には、以下の点に気を付ける必要があります：
1. サービスディスカバリー：
マイクロサービス間の通信を可能にするため、サービスの発見と接続が重要です。AWSではAmazon ECSの統合サービスディスカバリーやDNSベースのサービスディスカバリーを活用できます。
2. 分散モニタリング：
多数の分散したコンポーネントを監視する必要があります。Amazon CloudWatchを使用して、メトリクスの収集、ログファイルの集中管理、アラームの設定、およびAWS環境の自動対応が可能です。
3. セキュリティとコンプライアンス：
AWS Configを使用して、セキュリティ違反を検出し、自動的に対応することができます。また、APIゲートウェイの設定変更などのセキュリティ上の問題を監視し、修正することが重要です。[1][2][3]
4. 監査とガバナンス：
AWS CloudTrailを使用して、すべてのAPI呼び出しを記録し、ユーザーアクションや系統的な変更を追跡できます。これにより、予期しない動作や企業ポリシーの違反、デバッグのための情報を分析できます。
5. デプロイメントアプローチ：
消費者のサービス契約を破壊しないようにすることが重要です。API所有者が契約を破る変更を行い、消費者が準備できていない場合、障害が発生する可能性があります。APIキーを使用して消費者のメタデータを収集し、変更の影響を評価することが推奨されます。
6. 継続的な検証とテスト：
アプリケーションの機能性を常にテストし、意図したとおりに動作することを確認する必要があります。可能な限り、継続的インテグレーションと継続的デリバリー（CI/CD）を通じて検証を自動化することが重要です。[4][5][6]

---

比較結果を見て

どちらもマイクロサービスについて記載された同じドキュメントから内容を抜粋していましたが、GraphRAG の方が「マイクロサービス」に特化した内容を記載している印象を受けました。
ベクトルデータの方の4,5,6点目ですが、どの AWS アーキテクチャにも当てはまる内容です。
読み手の方でマイクロサービスの内容に読み替えながら考えることは十分可能ですが、GraphRAG で出力した内容の方がよりマイクロサービスに特化した内容に見えます。

---

ケース2：要件を満たす複数のアーキテクチャ

プロンプト

生成 AI の RAG を AWS で構築するにはどういったアーキテクチャのパターンが考えられますか。また、それに利用する AWS サービスにはどういったものがありますか。

【GraphRAG での回答】

生成 AI の RAG (Retrieval-Augmented Generation) を AWS で構築する際、一般的なアーキテクチャパターンとしては、サーバーレスアプローチを用いた複数の AI サービスの組み合わせが考えられます。このパターンでは、データの取り込み、処理、分析、そして生成 AI モデルとの連携を効率的に行うことができます。 主要なコンポーネントとしては以下が挙げられます：
1. データストレージ:
文書やメディアファイルを保存するための Amazon S3
2. データ処理とオーケストレーション:
AWS Lambda 関数と AWS Step Functions を使用してデータ処理のワークフローを管理
3. AI/ML サービス:
Amazon Comprehend (自然言語処理)、Amazon Rekognition (画像・動画分析)、Amazon Transcribe (音声をテキストに変換) などを使用してデータから情報を抽出
4. 検索と索引付け:
Amazon Elasticsearch Service を使用して抽出されたメタデータをインデックス化し、検索可能にする
5. API レイヤー:
Amazon API Gateway を使用してフロントエンドとバックエンドサービスを接続
6. ユーザー認証:
Amazon Cognito を使用してセキュアなユーザー認証を提供
7. コンテンツ配信:
Amazon CloudFront を使用して、静的コンテンツや API レスポンスを効率的に配信[1][2][3]

このアーキテクチャを使用することで、大量のデータを効率的に処理し、AI サービスを活用して情報を抽出し、それを生成 AI モデルの入力として使用することができます。これにより、より正確で関連性の高い応答を生成することが可能になります。 また、AWS の AI サービスを利用することで、機械学習の専門知識がなくても、高度な AI 機能をアプリケーションに簡単に統合できます。これらのサービスは完全に管理されており、データの準備、分析、モデルのトレーニング、評価などのプロセスを自動化しています。そのため、開発者は単純な API 呼び出しを通じてこれらの機能を統合できます。 このアプローチにより、実験と評価のサイクルを迅速に回すことができ、ビジネス目標に対する効果を素早く確認することができます。結果として、市場投入までの時間を短縮し、コストを削減しながら、高度な AI 機能を持つアプリケーションを構築することが可能になります。[4][5][6]

【ベクトルデータによる RAG での回答】

生成 AI の RAG (Retrieval-Augmented Generation) を AWS で構築する際、一般的なアーキテクチャパターンとしては、サーバーレスアーキテクチャを活用したものが考えられます。このパターンでは、複数の AWS サービスを組み合わせて、効率的かつスケーラブルなソリューションを構築します。 主要なコンポーネントとしては、以下のようなものが含まれます：
1. データストレージ:
ドキュメントや情報を保存するためのストレージ層
2. 検索エンジン:
関連情報を効率的に検索するための仕組み
3. AI/ML サービス:
自然言語処理や生成 AI の機能を提供
4. オーケストレーション:
各コンポーネント間の連携を管理
5. API レイヤー:
クライアントアプリケーションとバックエンドサービスを接続

このようなアーキテクチャを実現するために利用できる AWS サービスには以下のようなものがあります：
1. Amazon S3:
ドキュメントや情報の保存に使用
2. Amazon Elasticsearch Service:
高速な全文検索エンジンとして活用
3. Amazon SageMaker:
カスタム機械学習モデルのトレーニングとデプロイに使用
4. AWS Lambda:
サーバーレス関数として各種処理を実行
5. Amazon API Gateway:
RESTful API の作成と管理
6. AWS Step Functions:
複雑なワークフローのオーケストレーションに使用
7. Amazon Comprehend:
自然言語処理タスクに活用
8. Amazon Rekognition:
画像や動画の分析に使用（必要に応じて）

これらのサービスを組み合わせることで、柔軟で拡張性の高い RAG システムを構築することができます。[1][2][3][4][5]

---

比較結果を見て

このケースではかなり明確に「解説力」に差が出たなと感じました。
「Amazon S3 が何か」ではなく「データストレージの役割として S3 が使える」という順番で説明されている部分にすごく驚きました。

後片付け

検証に伴い構築したリソースの削除を忘れずに実施しましょう。
ナレッジベースを削除しても Amazon Neptune については削除されませんので、ご注意ください。

(1) Amazon Bedrock コンソールから作成したナレッジベースを削除

(2) Amazon Neptune コンソールから作成したグラフを削除する

まとめ

このブログでは AWS で GraphRAG を実装するということをテーマに「GraphRAG とはなにか」であったり「具体的な構築方法」などを解説しました。
また、実際に従来多かったベクトルデータを使った RAG と GraphRAG での回答の違いを見ていくことで、GraphRAG の可能性を感じていただけたかなと思います。

今回はたまたま GraphRAG が優位性を見せたケースがほとんどでしたが、実際のユースケースでは両方に得意/不得意があると思っています。
とにかく実装が楽になりましたので、まずは単純に比べてみて、
皆さんのユースケースに対して適している方を見極めてみてはどうでしょうか？