1. はじめに
- Bedrock Knowledge BaseでRAGを作るときに使うデータベースとしては、OpenSearchやS3 Vectorsがいいかな、みたいな認識だったが、GraphRAGのほうがいい場合があるかも、という話があり、Neptune AnalyticsによるGraphRAGに入門して、違いを確認してみる。
2. やったこと
- GraphRAGを使ったほうが検索・回答精度が上がりそうな文書リストを用意する。
- 同じ文書リストをソースとして、2つのBedrock Knowledge Base (S3 Vectors版とNeptune Analytics版)を作成する。
- 質問を行い、S3 Vectors版とNepture Analytics版の回答内容を比較する。
3. 構成図
4. 手順
4.1 文書リストの用意
- 文書間に関係性があるような文書リストをGeminiに作ってもらい、S3に保存する。文書は以下の5つ。
doc_01_billing_service.txt
Internal Service Architecture: Billing Application
The company's core Customer Billing Service (Service-ID: BILL-PROD) is designed as a microservice to handle all subscription renewals. To process payments and retrieve ledger data in real-time, this Billing Application establishes a persistent, high-throughput connection to the primary transaction database engine, known in our inventory as "DB-Alpha-9".
doc_02_database_hosting.txt
Database Infrastructure Inventory
The transaction database "DB-Alpha-9" is configured with a high-availability active-passive clustering setup. The primary active node of DB-Alpha-9 is hosted on and powered by the physical hardware server labeled "Rack-Host-Mercury" located in our Oregon Data Center (Zone-A).
doc_03_hardware_rack.txt
Data Center Hardware Layout
The physical server "Rack-Host-Mercury" is mounted in Rack 12 of Zone-A. Power delivery to Rack-Host-Mercury is managed by the Intelligent Power Distribution Unit (PDU) identified as "PDU-West-03". Additionally, all network traffic for this server passes through the primary top-of-rack network switch "Switch-Nexus-X".
doc_04_maintenance_schedule.txt
Urgent Infrastructure Maintenance Bulletin
This weekend, the network operations team will perform an urgent hardware replacement. Due to recurring port failures, the top-of-rack network switch "Switch-Nexus-X" will be shut down and replaced with a newer model. This operation is scheduled for Sunday, June 14, at 02:00 AM UTC and will result in a temporary network blackout for all connected hardware under Switch-Nexus-X.
doc_05_unrelated_pdu_info.txt
Facility Power Grid Upgrades
The backup power distribution unit "PDU-West-04" is undergoing routine load testing. Please note that "PDU-West-03" (which powers adjacent server racks) is running at normal capacity and is not scheduled for any maintenance this month.
-
文書リスト内の主要な関係性として以下のようになる。
- BILL-PRODというサービスはDB-Alpha-9というデータベースに依存。
- DB-Alpha-9というデータベースは、Rack-Host-Mercuryに収容。
- Rack-Host-Mercuryは、Oregon Data Center Zone-Aに収容。
- Rack-Host-Mercuryは、PDU-West-03に依存。
- Rack-Host-Mercuryは、Switch-Nexus-Xに依存。
- Switch-Nexus-Xは、June 14にメンテナンス。
- PDU-West-03は通常稼働。
- PDU-West-04は負荷試験中。
-
主要なキーワードがどのファイルにあるかは下表のようになる。
- 「June 14 のメンテナンスにより影響を受けるサービスは何ですか？」のような質問に、文書間の関係を理解して、「Mainetenance」⇒「Switch-Nexus-X」⇒「Rack-Host-Mercury」⇒「DB-Alpha-9」⇒「BILL-PROD」と関係を辿っていき、結論として「BILL-PRODです」と回答できることを期待する。
4.2 Bedrock Knowledge Base の作成
- 2種類のBedrock Knowledge Baseを作成する（詳細手順は割愛し、主要パラメータのみ記載）。マネコンでの操作画面はこちらのブログ「Amazon Bedrock で GraphRAG を実装する、ってどういうこと？」などを参照のこと。
- S3 Vectors の場合
- データソース
- S3(5つの文書ファイルがあるバケット)
- 解析戦略： Amazon Bedrock デフォルトパーサー
- チャンキング戦略： デフォルトチャンキング
- データストレージと処理
- 埋め込みモデル： Titan Text Embedding V2
- ベクトルストア： Amazon S3 Vectors
- データソース
- Neptune Analytics の場合
- データソース
- S3(5つの文書ファイルがあるバケット)
- 解析戦略： Amazon Bedrock デフォルトパーサー
- チャンキング戦略： デフォルトチャンキング
- データストレージと処理
- 埋め込みモデル： Titan Text Embedding V2
- ベクトルストア： Amazon Neptune Analytics (GraphRAG)
- Model for graph construction： Claude Haiku 4.5
- データソース
4.3 動作確認
4.3.1 初回動作確認
- 普通にいくつか質問して、動作の違いを確認する。
- マネコンでテストしているが、AWS CLIの以下のコマンドに相当。LLMは Claude Sonnet 4.6、チャンク取得最大数(numberOfResults)は10としている。
aws bedrock-agent-runtime retrieve-and-generate
--input "{\"text\": \"What user-facing services or applications will be affected by the maintenance scheduled on Sunday, June 14?\"}"
--retrieve-and-generate-configuration "{\"type\": \"KNOWLEDGE_BASE\", \"knowledgeBaseConfiguration\": {\"knowledgeBaseId\": \"XXXXXXXXXX\", \"modelArn\": \"arn:aws:bedrock:ap-northeast-1:XXXXXXXXXXXXX:inference-profile/global.anthropic.claude-sonnet-4-6\", \"retrievalConfiguration\": {\"vectorSearchConfiguration\": {\"numberOfResults\": 10}}}}"
--region ap-northeast-1
| 質問 | S3 Vectors | Neptune Analytics |
|---|---|---|
| What user-facing services or applications will be affected by the maintenance scheduled on Sunday, June 14? | 【結果：OK】 The maintenance on Sunday, June 14 involves shutting down the network switch "Switch-Nexus-X," which will cause a temporary network blackout for all hardware connected to it. One of those connected servers is "Rack-Host-Mercury."[1] [2] Rack-Host-Mercury is the physical server hosting the primary active node of the transaction database "DB-Alpha-9."[3]Since DB-Alpha-9 will lose network connectivity during the maintenance window, the Customer Billing Service (BILL-PROD) — which relies on a persistent, real-time connection to DB-Alpha-9 to process subscription renewals and retrieve ledger data — will be directly impacted and likely unable to function during that period.[4] |
【結果：OK】 The maintenance scheduled for Sunday, June 14 involves replacing the top-of-rack network switch "Switch-Nexus-X," which will cause a temporary network blackout for all hardware connected to it.[1]One of the servers connected to Switch-Nexus-X is "Rack-Host-Mercury," which handles all its network traffic through that switch.[2]Rack-Host-Mercury hosts the primary active node of the transaction database "DB-Alpha-9."[3] DB-Alpha-9 is the database that the core Customer Billing Service (Service-ID: BILL-PROD) relies on for processing payments and retrieving ledger data in real-time. Therefore, the Customer Billing Service — responsible for all subscription renewals — will be directly impacted by this maintenance window.[4] |
| Is there any maintenance scheduled for the power unit PDU-West-03? | 【結果：OK】 PDU-West-03 is not scheduled for any maintenance this month. It is currently running at normal capacity.[1] |
【結果：OK】 There is no maintenance scheduled for PDU-West-03 this month. It is currently running at normal capacity.[1] |
- S3 Vectors と Neptune Analytics の回答には差がなく、どちらも正しく回答できている。どちらのKnowledge Baseにおいても、ファイル＝チャンクとなっており、ソースにはチャンクが5個存在するが、チャンク取得上限が10であり、全てのチャンクを取得して回答作成に使えるため、結果が同様になっていると考えられる。
4.3.2 チャンク取得上限数の制限
- 「What user-facing services or applications will be affected by the maintenance scheduled on Sunday, June 14?」の質問に正確に回答するには、文書#01～#04が必要（文書#05は関係ないので不要）。
- チャンク取得上限数を4に変更して、それぞれのKnowledge Baseが適切なチャンクを選択できるか、またその選択した結果を使用した回答がどうなるかを確認する。（4.3.1項のコマンドをnumberOfResults=10⇒4に変更して実行）
| 質問 | S3 Vectors | Neptune Analytics |
|---|---|---|
| What user-facing services or applications will be affected by the maintenance scheduled on Sunday, June 14? | 【結果：OK】 【取得文書：#01,#03,#04,#05】 On Sunday, June 14 at 02:00 AM UTC, the network switch "Switch-Nexus-X" will be shut down and replaced due to recurring port failures. This will cause a temporary network blackout for all hardware connected to it.The physical server "Rack-Host-Mercury" routes all its network traffic through Switch-Nexus-X, meaning it will lose network connectivity during the maintenance window. The primary transaction database "DB-Alpha-9" is hosted on Rack-Host-Mercury (based on the infrastructure layout). The Customer Billing Service (Service-ID: BILL-PROD) maintains a persistent, high-throughput connection to DB-Alpha-9 to process payments and retrieve ledger data in real-time. Therefore, the Billing Application — which handles all subscription renewals — is the key user-facing service expected to be disrupted during this maintenance window. |
【結果：NG】 【取得文書：#03,#04,#05】 The physical server "Rack-Host-Mercury" will be affected by the Sunday June 14 maintenance. Its network traffic runs through "Switch-Nexus-X", which is being shut down and replaced that night at 02:00 AM UTC, causing a temporary network blackout for all hardware connected to it. The power supply to Rack-Host-Mercury (via PDU-West-03) is not affected, as PDU-West-03 is running at normal capacity and has no maintenance scheduled this month. The outage will be network-only. |
-
S3 Vectorsでは文書#01,#03,#04,#05が選択された。不要なチャンク(文書#05)を選択してしまい、文書#02が取れていないが、他の文書から関係を推論して（無理やり）正解にたどりついている。
-
Neptune Analyticsでは文書#03,#04,#05が選択された。不要なチャンク(文書#05)を選択してしまい、回答に絶対必要なチャンク(文書#01)を落としてしまったため、回答が不正確になった。また、最大取得数を4に設定しているにも関わらず、チャンクは3個しか取得されなかった（3個しか取得されない原因は不明だが、スコア閾値を満たさないと取得対象にならないのかもと推測）。
-
なお、それぞれのKnowledge Base でどのチャンクがどのような優先順で選択されているかは以下で確認可能。
aws bedrock-agent-runtime retrieve
--knowledge-base-id "XXXXXXXX"
--retrieval-query "{\"text\": \"What user-facing services or applications will be affected by the maintenance scheduled on Sunday, June 14?\"}"
--retrieval-configuration "{\"vectorSearchConfiguration\": {\"numberOfResults\": 4}}"
--region ap-northeast-1
| 優先順 | S3 Vectors | Neptune Analytics |
|---|---|---|
| 1 | #04 (0.485) | #03 (1.898) |
| 2 | #05 (0.385) | #05 (1.612) |
| 3 | #01 (0.356) | #04 (1.050) |
| 4 | #03 (0.354) | なし |
- S3 VectorsとNeptune Analyticsのスコアのレンジが異なる（算出方法不明）のため、直接的な比較はできない。
4.3.3 Neptune Analytics へのノード・エッジの登録状況確認
- 自分の理解として、Neptune Analyticsの場合には、GraphDBとしてのノード・エッジのトラバース結果がチャンクの選択に影響しているのではという認識。
- そのため、Bedrock Knowledge Base用に作成されたNeptune Analyticsにはどのようにノード・エッジが登録されているかを確認する。
aws neptune-graph execute-query
--graph-identifier g-XXXXXXXXX
--query-string "MATCH (n)-[r]->(m) RETURN n, type(r), m LIMIT 50" \
--language open_cypher
--region ap-northeast-1
outfile.json
- 上記のコマンドで取得したjsonファイル（ノード・エッジの一覧）を可視化するスクリプト(kiroで作成)の結果がこちら。
-
Bedrock Knowledge Base で、Neptune Analytics をベクトルDBとして選択した場合に、自動で作成されるノードとエッジは以下になる。
- ノード
- Chunk： ソースドキュメント毎に作成されるチャンク（5個）。例：「doc_01」など。
- Entity： 固有名詞など（13個）。例：「DB-Alpha-9」「Rack-Host-Mercury」など。
- DocumentID： ソースとなったドキュメント（5個）。64バイト程度のハッシュ文字列。
- エッジ
- CONTAINS： doc_01(Chunk) ---> DB-Alpha-9(Entity) など、どのChunkにどのEntityが含まれているか（18本）
- FROM： doc_01(Chunk) ---> xxxxxxxxxxxxxxxx(DocumentID) など、どの文書からどのチャンクが作成されているか（5本）
- ノード
-
基本的には、どの文書にどのキーワードがあるか、が登録されているのみで、自分が勝手に期待していた、『「DB-Alpha-9」は「Rack-Host-Mercury」に収容されている』のような、Entity間の関係性の登録が自動で行われるわけではなかった。そのため、意味的な関係に基づいてはおらず、文書間のEntity共有によるトラバースに基づいたチャンク選択が行われているのかなと推測した。
5. 所感
- 今回の検証では、Bedrock Knowledge Base において、Neptune Analyticsの設定方法は分かったが、その優位性を示すことができなかった。
- 現状(2026/6)のBedrock Knowledge Base の GraphRAG は、Entity間の意味的関係（hosted_on, depends_on 等）を自動抽出するものではなく、Entityのチャンク間の共有関係によるトラバースを行う仕組みのようだった。そのため、本格的なナレッジグラフを活用した検索を行うには、自前でEntityの関係をNeptuneに投入する必要がありそうなため、次回はそういった内容にチャレンジしてみたい。