9月15日、AWSが「Unified Knowledge Graph RAG on AWS: GraphRAG and LightRAG on one stack」と題した記事を公開した。この記事では、MicrosoftのGraphRAGとHKUDS（香港大学データサイエンス研究室）のLightRAGをAWS上の共通スタックで統合した実装フレームワーク「unified-kg-rag-on-aws」について詳しく紹介されている。
ベクトル検索RAGの限界と、ナレッジグラフRAGが解決する問題
コンプライアンス担当者が数千件の契約書・修正書・社内メモを前に「このマイルストーンが遅延したら、どの義務が露出するか？」という問いに答えようとする場面を考えてほしい。答えは1つの文書には存在しない。支払いをマイルストーンに紐付けた基本合意書、そのマイルストーンを変更した修正書、サプライチェーンへの波及効果を記述したリスクメモ——3つの文書にまたがる「構造」の中にある。
従来のRAG（Retrieval-Augmented Generation）は、文書をベクトル化して埋め込み類似度で近いチャンクを取得し、モデルに回答させる方式だ。答えが1つのパッセージに収まっている場合には有効だが、以下のようなケースで限界を迎える：
- マルチホップ推論：「この修正書が変更したマイルストーンに依存する義務はどれか？」——推論の連鎖が、埋め込み的に類似しない複数の文書をまたぐ。
- クロスドキュメント集約：「全契約書で同じ免責上限を参照している条項はどれか？」——1つのチャンクに答えは存在しない。
- グローバル/テーマ的な質問：「コーパス全体の主要リスクを要約せよ」——「最も近いチャンク」という概念自体が成り立たない。
ナレッジグラフRAGはこれに対し、文書群をエンティティと関係のグラフに変換し、その構造を推論の対象にする。
GraphRAGとLightRAG——正反対の設計思想
本プロジェクトは2つのオープンソース手法を論文ベースでクリーンルーム実装している（上流コードのコピーなし、ライセンス表記はTHIRD_PARTY_LICENSESに記載）。
Microsoft GraphRAG（arXiv:2404.16130、GitHub）
GraphRAGの設計思想は「高コストな推論をインデックス時に1度だけ払う」ことだ。
インデックス時にLLMがコーパスを読んでエンティティと関係のグラフを抽出し、その後Leidenコミュニティ検出アルゴリズムが互いに強く参照し合うエンティティの塊（コミュニティ）を特定する。これはフォルダ構造やタグとは無関係に、コーパスの実際のつながりから浮かび上がるトピック群だ。基本合意書・修正書・リスクメモは、別々のシステムに存在していても同一コミュニティに収まる。
LLMが各コミュニティのサマリーを生成し、階層的なサマリーツリーを構築する。これにより：
- グローバルな質問はコミュニティサマリーへのmap-reduceで答えられる
- ローカルな質問はエンティティから関係を辿るグラフ展開で答えられる
代償はインデックス時の計算コストと、クエリごとのコストだ。後述のベンチマーク結果はこれを定量化している。
HKUDS LightRAG（arXiv:2410.05779、GitHub）
LightRAGは逆の設計思想——「インデックスは安く、推論はクエリ時に」だ。エンティティと関係のグラフを抽出するが、コミュニティ検出もサマリー生成も行わない。
肝はクエリ時のデュアルレベルキーワード検索だ。「このマイルストーンが遅延したらどの義務が露出するか？」という問いに対し：
- 低レベルキーワード（obligation、milestone等）→ エンティティ説明に照合（「何があるか」の層）
- 高レベルキーワード（exposure、dependency、schedule risk等）→ 関係説明に照合（「どうつながるか」の層）
この2層を1パスで検索することで、実体の正確性と接続性の広さを同時に得る。コーパスを投入してすぐ質問できるのが利点だが、コストはクエリごとに発生する。記事中のベンチマークによれば、精度で競うモードのうちLightRAGのmixモードはクエリあたりコストが最も高い——「ライトウェイト」はインデックスコストの話であって、mixモードのクエリコストの話ではない点に注意が必要だ。
5つの追加実装
本フレームワークは両手法の上に5つの機能を追加している。このうち特に差別化要因として重要なのが、最初の「1スタックで両手法を切り替え」と「トリプルハイブリッド検索」の2点だ。前者はGraphRAGとLightRAGを用途に応じてクエリ単位で使い分けるという本プロジェクトの核心機能であり、後者は語彙・意味・構造という3つの異なる次元の検索を統合することで、いずれか単独では拾えない関連情報を補完し合う設計になっている。残る3つはそれを支える実用上の実装品質だ。
- 1スタックで両手法を切り替え：
RAGInput.search_strategyをクエリごとに指定するだけでGraphRAG（simple/local/global/drift/auto）とLightRAG（mix/hybrid/naive）を切り替えられる。グラフ・インデックス・キャッシュは共有。 - トリプルハイブリッド検索：BM25（語彙的）、kNN（意味的）、Neptuneグラフ展開（構造的）の3つをRRF（Reciprocal Rank Fusion）で統合し、さらにBedrockによるオプションのリランク。
- 増分インデックス：DynamoDBでドキュメントのコンテンツハッシュを管理し、変更されたドキュメントのみ再インデックス。抽出プロンプトやチャンク設定を変更した場合は全体の再構築が必要。
- 多言語対応：専用の翻訳ステージ、言語対応アナライザー、多言語キーワード/エンティティ抽出を両手法に適用。
- ヘキサゴナルアーキテクチャ：
domain/層にはboto3もLangChainもインポートしない。ストレージバックエンドはコンストラクタ引数で注入、検索戦略はデコレーターでセルフ登録——バックエンドの交換や戦略追加がディスパッチコードへの編集ではなく追加で済む設計。
AWSサービスの役割分担
| 関心事 | AWSサービス | 用途 |
|---|---|---|
| LLM・埋め込み・リランク | Amazon Bedrock | 抽出/サマリー/生成、kNN用埋め込み、オプションのリランク |
| グラフストア | Amazon Neptune | エンティティ/関係グラフ（Gremlin経由） |
| 語彙+ベクトル検索 | Amazon OpenSearch Service | BM25テキストインデックス + kNNベクトルインデックス |
| 増分状態管理 | Amazon DynamoDB | コンテンツハッシュデルタ＋ドキュメント系譜 |
| コーパス+キャッシュ | Amazon S3 | ソース文書と再開可能なパイプラインキャッシュ |
すぐに動かすには
git clone https://github.com/awslabs/unified-kg-rag-on-aws.git
cd unified-kg-rag-on-aws
uv sync --extra dev
cp config-template.yaml config.yaml
# BedrockモデルID、Neptune/OpenSearchエンドポイント、S3バケット、リージョンを設定
# コーパスのインデックス（失敗後は --resume-from-stage で再開可能）
run-ingestion --source-directory ./source --s3-sync --s3-bucket-name my-bucket
# 戦略を切り替えてクエリ
run-rag --query "コーパス全体の主要リスクを要約せよ" --search-strategy global
run-rag --query "免責上限に関連するエンティティは？" --search-strategy mix
本実装はリファレンス実装・サンプルであり、本番環境対応ではない。 Neptune、OpenSearch、Bedrockの実際のキャパシティをプロビジョニングするため、本番利用前にセキュリティ・コスト・スケーリング・データガバナンス設定を必ず確認すること。
インデックスパイプラインは12ステージのチェックポイント方式で、途中失敗時は--pipeline-idと--resume-from-stageで再開できる。ステージはdocument_parsing → text_chunking → translation → graph_extraction → gleaning → graph_resolution → community_detection → indexingと続く。
詳細はUnified Knowledge Graph RAG on AWS: GraphRAG and LightRAG on one stackを参照していただきたい。
