SPECIALIST

多様な専門性を持つNRIデジタル社員のコラム、インタビューやインサイトをご紹介します。

BACK

Bedrock ナレッジベースによるGraphRAG構築と公開

こんにちは、NRIデジタルの島です。

最近トレンドである「生成AI」関連の情報が世の中に多数出ておりますが、AWSにおいても「Amazon Q」や「Amazon Bedrock(以下Bedrock)」など生成AI関連のアップデートが非常に多く、以下ブログ「週刊AWS」においても多くの割合を占めている印象です。
週刊AWS | Amazon Web Services ブログ

生成AI登場により、筆者のような非データサイエンティストでも、AIを駆使できる時代が到来したと感じるのですが、まだ手を出せていないエンジニアの方々も多いのではないでしょうか。(筆者もまだちゃんと試せていません)
そんな中、最近よく「GraphRAG」というグラフデータベースのRAGがすごい、と話題になっているので、グラフデータベース自体も含め、この機会に簡単な検証をしながら調べてみたいと思います。

グラフデータベースとは

1. 概要

最初にグラフデータベースの概要について確認してみたいと思います。従来のリレーショナルデータベース(RDB)はテーブル形式でデータを管理するのに対し、グラフデータベースは、ノード(点)とエッジ(線)でデータを管理し、データ間の関係を効率的に扱うことができるデータベースとなっています。

AWSにおいては、「Amazon Neptune(以下Neptune)」というグラフデータベースのマネージメントサービスが存在しており、Black Beltや各セミナーなどでグラフデータベース自体について詳しく説明してくれています。
本記事で掲載する図などは一部以下「Black Belt オンラインセミナー」より抜粋しています。
サービスカットシリーズ「Amazon Neptune」
Amazon Neptuneではじめるグラフデータベース入門

グラフの一般的なイメージは以下のようなものです。

ソーシャルネットワーク(SNS)をグラフで表現すると以下のようなイメージとなります。

また、ネットワークIPを表現すると以下のようになります。

このようなノードとその関連を表現する上記のようなグラフをモデル化した「グラフモデル」を効率的に格納し、検索するためのデータベースがグラフデータベースです。

2. 基本構造

グラフデータベースの基本構造(構成要素)は以下の通りです。

ノード(Vertex)
・エンティティ(人、商品、場所など)を表す
・各ノードにプロパティ(属性情報)が付与可能

②エッジ(Edge)
・ノード同士の関係を表す
・各エッジにもプロパティ(属性情報)が付与可能

③プロパティ(Property)
・ノードやエッジの追加情報

例えば、上記「ソーシャルネットワーク(SNS)」であれば、ユーザーエンティティが「ノード」、ユーザーとの関連リンク(矢印)が「エッジ」、それぞれの属性(ユーザーの「ユーザー名」や関連名(フォローなど))がプロパティとなります。

3. データベースの種類

グラフデータベースはデータモデルの違いによって、大きく2種類に分類され、使用できるクエリ言語も異なります。まとめると以下の通りです。

         
種類 特徴 クエリ言語 代表的なDBイメージ
Property Graph ノードとエッジにプロパティを持てる Gremlin
openCypher
Amazon Neptune, Neo4j, ArangoDB, Dgraph, Azure CosmosDB
RDF Graph
(トリプルストア)
主語-述語-目的語 形式で表現 SPARQL Amazon Neptune, GraphDB
なお、どちらのデータモデルでもどのクエリ言語でも、「リレーションのクエリが高速」というメリットがあります。

例えば、友人関係を表現しようとします。

グラフデータベースでは、このイメージままデータモデルとして自然に登録・抽出できますので非常に効率的です。これをリレーショナルデータベース(RDB)で表現しようとすると以下のようになり、JOINのコストが高くなることが想像できます。

4. ユースケース

さいごに、グラフデータベースのユースケースについてです。AWS公式ページでのグラフデータベースの紹介では、以下が挙げられています。
グラフデータベースとは? | アマゾン ウェブ サービス (AWS)

ユースケース 説明
不正検出 グラフデータベースは、高速なクエリを活用し、不正な取引パターンをリアルタイムで検出できます。例えば、Eメールやクレジットカードの一致、共有IPの異常な使用などの関係性を分析し、不正を素早く特定できます。
レコメンドエンジン グラフデータベースはレコメンデーションに適しており、顧客の興味や購入履歴、友人関係を分析して、関連する製品や人をリコメンドできます。
ルート最適化 グラフデータベースは、最短ルートや最適な従業員、機械の選定など、ルート最適化の問題を迅速に分析できます。グラフクエリにより、ノード間の関係を効率的に評価できます。
パターン検出 グラフデータベースは、データ内の複雑な関係や隠れたパターンを検出するのに適しており、例えばソーシャルメディアでボットとリアルアカウントを識別できます。
ナレッジマネジメント グラフデータベースはレコメンデーションに適しており、顧客の興味や購入履歴、友人関係を分析して、関連する製品や人をリコメンドできます。

上記のうち、重要なユースケースとしてナレッジマネジメントの「ナレッジグラフ」があります。ナレッジグラフは一見関連のなさそうな不均質なデータをリンクさせ、隠れた関連を発見させることができます。これは、正確な情報提供を求められるML/AIモデルの質を向上させる可能性を秘めていると考えられます。

「大規模言語モデル(以下LLM)」での従来のRAGは「ベクトル検索ベース」で、主にデータの意味的類似度、つまり言語的に近い情報しか取得できませんでした。ナレッジグラフを活用したRAGを「GraphRAG」(Graph-based Retrieval-Augmented Generation)といい、事実や事象の関連に基づいた多層的な検索ができるため、より高度なインサイトをAIの自然言語問い合わせで得ることができ、LLMの文脈適合性や精度を向上させる先進的な技術となります。

グラフデータベースの基本知識を得たところで、以降では「GraphRAG」について実際に構築しながら深掘りしてみていきたいと思います。

GraphRAG

GraphRAGは、知識グラフを活用して LLMの回答精度を向上させる技術です。
AWSの代表的なLLMに「Bedrock」がありますが、そのBedrockもGraphRAGとの統合がサポートされ、つい先日GAしました。
Amazon Bedrock Knowledge Bases supports GraphRAG now generally available – AWS
この機能(ナレッジベース)を使用して、GraphRAGを試してみたいと思います。

この「GraphRAG」にはAWSのグラフデータベースのマネージメントサービスであるNeptuneが使われます。Neptuneには「データベース(Neptune Database)」「グラフ(Neptune Analytics)」がありますが、GraphRAGではグラフ(Neptune Analytics)」が使われます。

シナリオ

今回は以下2種類のユースケースについて、従来のRAG(Amazon OpenSearch Service Serverless(以下OpenSeach)でのベクトル検索)と今回のGraphRAG(Neptune Analytics)でどういう違いが出るか確認していきます。
・ソーシャルネットワーク(SNS)
・不正検知
※上記どちらのデータもフィクションで手作成したサンプルデータです

システム構成

Bedrock + 上記RAGをBedrockのAIエージェントと接続し、それぞれのエージェントへSlackから問い合わせるボットの構成を目指します。

構築手順

構築や動作確認は大枠以下のような手順で進めていきます。

  1. ナレッジベースの作成(ベクトル検索RAG)
  2. Bedrock AIエージェントの作成(ベクトル検索RAG)
  3. ナレッジベースの作成(GraphRAG)
  4. Bedrock AIエージェントの作成(GraphRAG)
  5. RAGテスト
  6. Slack接続(Amazon Q Developer in chat applications(旧AWS ChatBot))

①ナレッジベースの作成(ベクトル検索RAG)

まずベクトル検索RAG(OpenSearch)のナレッジベースを作成していきます。

以下のような各シナリオのCSVを用意しS3に保存します。
ソーシャルネットワーク(SNS)シナリオ用

         
ユーザーID 名前 プロフィールテキスト 興味・関心投稿内容
U001 田中太郎 ソフトウェア開発者、AIに興味あり AI、Python、データ分析 「LLMを使って新しいアプリを作っています!」
U002 佐藤一郎 データサイエンティスト、機械学習が好き 機械学習、データ分析 「データ分析の基礎についてブログを書きました」
U003 鈴木花子 Webデザイナー、UI/UXに興味あり デザイン、UI/UX 「最近Figmaを学び始めました!」
U004 渡辺健 Webアプリ開発者、Web技術に興味あり React、UI/UX 「最新のフレームワークを使ったWebアプリに挑戦中」
不正検知シナリオ用
         
トランザクションID 顧客ID 取引内容 金額時間 ロケーション メモ
T001 C123 ギフトカード購入 50000 02:30 AM 東京 高額かつ深夜の取引
T002 C456 海外送金 100000 03:45 AM ロンドン 不審な送金先
T003 C789 電子機器購入 200000 11:00 AM 大阪 以前のパターンと一致
T004 C123 高額送金 300000 10:00 AM 東京 高額
データソースに上記S3のURLを設定します。

ベクトルデータベースに「OpenSearch Serverless」を選択し、作成します。

これでナレッジベース作成、準備完了です。次に接続するAIエージェントを作成します。

②Bedrock AIエージェントの作成(ベクトル検索RAG)

AI基盤モデルと上記で作成したナレッジベースを指定し、エージェントを作成します。

これでベクトル検索RAG側のエージェント作成まで完了です。次にGraphRAG側も進めていきます。

③ナレッジベースの作成(GraphRAG)

GraphRAG用の各シナリオCSVを用意しS3に保存します。作成するデータはノードのデータとエッジのデータを分けて作成します。

ソーシャルネットワーク(SNS)シナリオ用
ノード
      
ユーザーID 名前 興味・関心 フォロー関係
U001 田中太郎 AI, Python U002, U004
U002 佐藤一郎 データ分析,、Python U003
U003 鈴木花子 デザイン, UI/UX U004
U004 渡辺健 Web技術、UI/UX U001
エッジ(関係性)
出発ノード 関係 到達ノード
U001 フォロー U002
U002 フォロー U003
U003 フォロー U004
U004 フォロー U001
不正検知シナリオ用
ノード
トランザクションID 顧客ID 取引内容 金額 ロケーション
T001 C123 ギフトカード購入 50000 東京
T002 C456 海外送金 100000 ロンドン
T003 C789 電子機器購入 200000 大阪
T004 C123 高額送金 300000 東京
エッジ(関係性)
出発ノード 関係 到達ノード
C123 実行 T001
C123 実行 T004
C456 実行 T002
C789 実行 T003
T001 同一IP T004

以降の作成手順は、基本的にはベクトル検索RAG側と同じです。GraphRAGの場合は以下のように「Neptune Analytics」を選択します。なお、現在AI基盤モデルは「Anthropic Claude 3 Haiku v1」しか使用できないのため注意してください。

ナレッジベースを作成すると「Neptune Analytics」のグラフが起動されます。

④Bedrock AIエージェントの作成(GraphRAG)

こちらもベクトル検索RAG側と手順は同様です。リンクするナレッジベースを上記で作成したGraphRAGのナレッジベースを指定してください。

寄り道

はじめてNeptuneに触れるので、ここでちょっと寄り道して、手動にてNeptuneグラフデータベースの基本動作を確認してみたいと思います。ナレッジベースでは前記したCSVを用意するだけでデータを取り込んでくれますが、ここでは一旦Neptuneでサポートされているクエリ言語の「openCypher」でデータを投入して、グラフエクスプローラで可視化してみます。

まず、どのように操作するかですが、一番簡単なのはグラフノートブックを使用する方法です。以下のようにノードデータを登録するJupyterノートブックを作成し、準備したソーシャルネットワーク(SNS)用CSVのノード部分を登録します。

この時点で、グラフエクスプローラを参照してみます。

まだエッジ(関連性)を登録してないので、ノードのみの表示です。次にエッジ(関連性)も登録してみます。

すると、以下の通り関連性が可視化されるようになりました。

最後に検索もクエリで試してみます。

フォロー関係を取得

「佐藤一郎」さんをフォローしている人を取得

⑤RAGテスト

テストする準備ができましたので、AIエージェント経由でテストをしていきたいと思います。テストにあたり以下のように各ナレッジベースのページにて、作成したCSVファイルをS3経由でRAGにデータ同期させてからテストを実施します。
※データは共存可能ですが、ノイズとならないよう各シナリオごとにデータ同期します

実際にはS3以外のデータソースを指定することも可能です。例えば、Webサイトを指定し、クローリングしてデータを同期するなどです。
※ ただし、現状GraphRAGについてはS3のみとなっています

では、シナリオごとの両者のテスト結果について見ていきたいと思います。

ソーシャルネットワーク(SNS)シナリオ
ベクトル検索RAG(OpenSearch)側

GraphRAG(Neptune)側

GraphRAGの方が、確かに関連性を考慮した回答になっていそうですね。

不正検知シナリオ
ベクトル検索RAG(OpenSearch)側

GraphRAG(Neptune)側

こちらもGraphRAGのほうが確度が高そうな回答のように思います。
単純なサンプルデータなので細かい精度比較まではできておりませんが、それぞれの特徴に応じて(実際にどちらの回答が良いのかは別にして)回答に差が出てることは確認できました。

Amazon Q Developer(旧AWS Chatbot)による外部公開

さいごに、(おまけではありますが、)Slackを通して各エージェントと会話できるのかを確認してみたいと思います。

AWS ChatbotはAmazon Q Developerに統合されています。
AWS Chatbot は Amazon Q Developer に名称が変わりました | Amazon Web Services

①Bedrock AIエージェントのエイリアス作成

既に作成済みのAIエージェントについて、それぞれエイリアスを作成します。
ベクトル検索RAG(OpenSearch)側 AIエージェント

GraphRAG(Neptune)側 AIエージェント

②Amazon Q Developer in chat applicationsの作成

Chatbotを作成し、Slackと連携させます。

「新しいチャネルを設定」から画面の指示に従い、連携させたいSlackチャネルを設定します。デフォルトだとBedrockのポリシーが足りてないので追加する。

③SlackでAmazon Q Chatbotを招待

Amzon Qを招待します。構文は以下の通りです。

@Amazon Q connector add ${コネクター名(※)} ${AIエージェントのARN} ${AIエージェントのエイリアスID}
※問い合わせ時の識別子として利用

コネクター名「os」として、ベクトル検索RAG(OpenSearch)側 AIエージェントを招待します。

同じくコネクター名「nt」として、GraphRAG(Neptune)側 AIエージェントを招待します。

④ Slackで質問

準備ができたのでそれぞれのエージェントへ質問を投げてみますが、筆者が実施した際以下のエラーが発生しました。

エラーメッセージ通りに「bedrock:InvokeAgent」権限追加することで正常に回答が返ってくるようになりました。

ベクトル検索RAG(OpenSearch)側 AIエージェント

GraphRAG(Neptune)側 AIエージェント

検証を通して

以上、BedrockとナレッジベースでAI エージェントを作成し、実際に外部公開するまで試してみました。説明の関係上、記事は長くなってしまいましたが、この内容自体は数十分で実行できるもので、冒頭でもお話しした通り、AIが非常に身近になってきていることを実感しました。データについても、今回は単純な少量のサンプルだったので、見様見真似で手動でCSVを作成しましたが、既にグラフDBを運用されている環境であれば、データをexportしてS3から同期することで簡単に作成することができます。
また、今回の検証では試せませんでしたが、調査したところ以下のようなソリューションもあり、高性能なRAGを生成するための候補として期待できるのでは、と思いました。

GraphRAG Toolkit
GitHub – awslabs/graphrag-toolkit: Python toolkit for building GraphRAG applications
GraphRAG Toolkit の紹介 | Amazon Web Services

Amazon Bedrock データオートメーション
コンテンツからインサイトを生成 – Amazon Bedrock Data Automation – AWS
Amazon Bedrock の新しい機能により、データ処理と取得が強化されます | Amazon Web Services

「GraphRAG Toolkit」は単一のデータソースからベクトル検索RAG及びGraphRAGを生成し、共存させることでより高性能なRAGを構築することが可能なようです。カスタマイズ性も高く、例えばLLMのサービスにBedrock以外を指定することもできるようです。また、「Bedrock データオートメーション」は、今回紹介したナレッジベースとも統合されており、「ドキュメント、画像、音声、動画」など非構造化マルチモーダルデータソースから信頼性が高く正確なインサイトを得ることで、容易に高性能なRAGを構築できるようです。
今回の検証にて、ある程度RAGのイメージを掴めたので、この後はデータやその精度も含めて、上記のソリューションも視野に入れつつ、更に深掘りしていきたいと思います。

さいごに

冒頭でもお伝えしましたが、生成AIやそれを取り巻くサービスや機能のアップデートが非常に多いです。本検証でAIエージェントを試してみましたが、新たなデザインパターンとして「マルチエージェントコラボレーション」なども注目されているようです。
Amazon Bedrock のマルチエージェントコラボレーション機能の紹介 (プレビュー) | Amazon Web Services
Amazon Bedrockマルチエージェントコラボレーションは何を解決するのか – Qiita

これに限らず、特に生成AIやDX関連技術の進化が早くついていくのがかなり大変ですが、遅れないように日々情報のキャッチアップをしていきたいと思います。