Amazon Web Services ブログ

GraphRAG Toolkit の紹介

本稿は 2025 年 1 月 27 日に公開された “Introducing the GraphRAG Toolkit” を翻訳したものです。

Amazon Neptune チームは 2025 年 1 月 21 日に GraphRAG Toolkitリリースしました。これは、グラフデータベースを活用した検索拡張生成 (Retrieval Augmented Generation; RAG) ワークフローの構築を容易にするオープンソースの Python ライブラリです。このツールキットは、非構造化データから、ベクトル埋め込みを含むグラフを自動的に構築するフレームワークを提供します。ユーザーの質問に答える際に、構造的に関連する情報を取得するために、このグラフをクエリする質問応答戦略を組み立てることができます。

本稿では、GraphRAG Toolkit の使い方について説明します。まず、RAG アプリケーションにグラフを追加することのメリットについて説明します。次に、クイックスタート環境のセットアップ方法とツールキットのインストール方法を説明します。最後に、このツールキットのグラフモデルとコンテンツ取得アプローチに至った設計上の考慮点について説明します。

なぜ RAG アプリケーションにグラフを追加するのか?

以下のような架空の物語を考えてみましょう。これは数週間にわたる、様々な架空のニュース記事、プレスリリース、業界出版物、アナリストレポートを集めたものであり、他の多くの文書と共に RAG ワークフローに投入されると想定しています。

  • Example Corp (人気の個人用ガジェットである “Widget” を製造する米国企業) は最近、国際的な輸送、保管、ラストマイル配送を提供する AnyCompany Logistics と提携することで、世界的な流通チャネルを拡大しました。“Widget” は、新世代の生成 AI テクノロジーによって会話機能を備えた AI 搭載のパーソナルデスクトップペットです。オースティンを拠点とする Example Corp の研究所で開発され、台湾で製造されています。
  • まだ 8 月であるにもかかわらず、英国のクリスマストップ 10 おもちゃの予測が既に発表されており、業界アナリストは Example Corp のおしゃべりデスクトップペット “Widget“ への大きな需要を予測しています。ロンドン、マンチェスター、その他の主要都市の小売業者は既に 100 万台以上 (1,500 万ドル相当) の注文を行っており、クリスマスまでの数ヶ月でその数字はさらに増加する見込みです。
  • AnyCompany Logistics は本日、最近開通した Fictitious Canal (架空の運河) を通じて全ての配送を行うことで、 2 週間かかっていた台湾から英国までの輸送時間を僅か 3 日に短縮すると発表しました。Fictitious Canal は、製造業者や流通業者がエネルギー消費とコストを削減するため、空輸から海運への移行を検討する中で、今後 5 年間で最も交通量の多い水路のひとつになる見込みです。
  • Fictitious Canal で地滑りが発生し、閉塞と遅延が続いています。現在、500 万トン以上の岩が南部水域を塞ぎ、コンテナ船を閉じ込め、国際サプライチェーンを混乱させています。ヨーロッパ向けの商品は数ヶ月の遅延が予想され、多くの小売業者のクリスマス在庫が危機にさらされています。

あなたがアナリストだとしましょう。どんなことを知りたいでしょうか?例えば、Example Corp の英国での販売見通しはどうか調査したいとします。

まず、ベクトルベースの主要な RAG アプリケーションに質問したところ、以下のような回答が得られました。

提供されたコンテキストに基づくと、 Example Corp の Widget 製品の英国での販売見通しは、きたるクリスマスシーズンに向けて非常に明るいものとなっています。業界アナリストは Widget おしゃべりデスクトップペットへの大きな需要を予測しており、クリスマスのトップ 10 おもちゃにもランクインしています。ロンドンやマンチェスターなど英国の主要都市の小売業者は既に 1,500 万ドル相当の 100 万台以上の注文を行っており、クリスマスが近づくにつれてさらに注文数は増加すると予想されています。このコンテキストは、 Example Corp が重要な年末商戦期間中、英国市場で Widget 製品の非常に高い販売量と収益を見込めることを示唆しています。

次に、 GraphRAG Toolkit を使用して構築されたアプリケーションに質問したところ、以下のような回答が得られました。

検索結果に基づくと、 Example Corp のおしゃべりデスクトップペット Widget の英国での販売見通しは当初非常に有望ですが、後にサプライチェーンの問題が販売を妨げる可能性があります。

検索結果によると、ロンドンやマンチェスターなど英国の主要都市の小売業者は、大きな需要を見込んで Widget 製品の 100 万台以上の注文を既に行っています。業界アナリストもこのおもちゃへの高い需要を予測しています。

この予想される需要に応えるため、 Example Corp は AnyCompany Logistics と提携して、英国を含む世界的な流通チャネルを拡大しています。 AnyCompany Logistics は、新たに開通した Fictitious Canal を経由して輸送することで、台湾から英国までの輸送時間を 2 週間から僅か 3 日に短縮する計画を発表していました。

しかし、 Fictitious Canal では地滑りによる大規模な閉塞が報告されており、500 万トン以上の岩が南部水域を塞ぎ、コンテナ船を閉じ込めています。これにより国際サプライチェーンが混乱し、英国を含むヨーロッパ向けの商品が数ヶ月遅延する可能性があります。

そのため、 Example Corp の Widget 製品の英国での初期の販売見通しは、予約注文と予想される需要に基づいて非常に有望に見えますが、状況が早急に解決されない場合、 Fictitious Canal の閉塞によるサプライチェーンの問題が今後数ヶ月間の需要への対応能力を妨げるリスクがあります。

なぜ回答にこれほどの大きな違いがあるのでしょうか?グラフアプローチは、ベクトルベースのアプローチにはない何を提供するのでしょうか?

ベクトル検索では、問われている質問に対して意味的に類似している、つまり言語的に近い情報しか取得できません。類似していない情報は、構造的に取得できません。この例では、 AnyCompany Logistics による Fictitious Canal の使用と、現在 Fictitious Canal を悩ませている閉塞に関する断片情報は、問われている質問との類似性が十分でないため、ベクトルベースのソリューションではコンテキストに取り込まれません。たとえそれらが、より正確で完全な回答を作成する上で極めて重要な情報であったとしてもです。

情報検索における関連性 (relevancy) は関係性 (relatedness) という観点で考えることができます。質問に関連するものは、直接的または間接的に、その質問と何らかの関係があります。関係性は類似性 (similarity) よりも広い概念です。意味的類似性は、私たちが興味を持つものが互いに関係する方法のひとつに過ぎません。例えば、テキスト A と B は意味的に類似しているために関係があると言えるでしょう。しかし、物事が関係を持つ方法は他にもたくさんあります。時間や空間における連続性、因果関係、親子関係、部分-全体関係、あるいは社会的、組織的、法的、分類学的な関係など、このリストは無限に続きます。物事が関係する方法や、それらの関係の相対的な重要性、強さ、質は、業界ドメインによって異なりますが、「意味的に類似している」ことは RAG 検索ツールボックスのひとつのツールに過ぎないと言えます。

私たちのドメインをグラフとしてモデル化し、グラフのエッジを使って私たちにとって重要な異なるタイプの関係を表現することで、質問とは異なるものの、正確で完全な回答を作成する上で構造的に関連する情報へのアクセスを提供できます。

類似性に基づく検索は依然として重要な RAG 戦略であり、質問と意味的に類似したコンテキストは、しばしば良い回答の基礎となります。しかし、類似性に基づく検索だけでは、ニュアンスのある回答を生成するのに常に十分というわけではありません。多くの場合、比較、議論、要約を展開するためのより差別化されたコンテキストを質問応答プロセスに提示するために、ベクトル類似度検索では見つけられない情報を見つけて返す必要があります。グラフ内の関係は、検索プロセスがこのような追加の関連情報を見つけるための手段を提供します。

GraphRAG Toolkit

すべての RAG アプリケーションは、インデックス化 (indexing) とクエリ処理 (querying) というふたつのコア機能を中心に構築されています。 GraphRAG Toolkit は、データをグラフとベクトルストアにインデックス化し、このグラフから関連コンテンツを取得する質問応答ソリューションを構築するために使用できるオープンソースの Python ライブラリです。

ツールキットの第 1 版では、非構造化および半構造化テキストコンテンツ (ウェブページ、PDF、JSON ドキュメントなど) を用いてグラフベースの RAG アプリケーションを構築することに焦点を当てています。ツールキットのセットアップと実行の詳細については、この投稿の後半にある「GraphRAG Toolkit のインストール」セクションをご参照ください。

インデックス化

コンテンツのインデックス化は、少量のコードで実現できます。

from graphrag_toolkit import LexicalGraphIndex
from graphrag_toolkit.storage import GraphStoreFactory
from graphrag_toolkit.storage import VectorStoreFactory

from llama_index.readers.web import SimpleWebPageReader

import nest_asyncio
nest_asyncio.apply()

doc_urls = [
    'https://docs.aws.amazon.com/neptune/latest/userguide/intro.html',
    'https://docs.aws.amazon.com/neptune-analytics/latest/userguide/what-is-neptune-analytics.html',
    'https://docs.aws.amazon.com/neptune-analytics/latest/userguide/neptune-analytics-features.html',
    'https://docs.aws.amazon.com/neptune-analytics/latest/userguide/neptune-analytics-vs-neptune-database.html'
]

docs = SimpleWebPageReader(
    html_to_text=True,
    metadata_fn=lambda url:{'url': url}
).load_data(doc_urls)

graph_store = GraphStoreFactory.for_graph_store(
    'neptune-db://my-graph.cluster-abcdefghijkl.us-east-1.neptune.amazonaws.com'
)

vector_store = VectorStoreFactory.for_vector_store(
    'aoss://https://abcdefghijkl.us-east-1.aoss.amazonaws.com'
)

graph_index = LexicalGraphIndex(
    graph_store, 
    vector_store
)

graph_index.extract_and_build(docs)

LexicalGraphIndex はコンテンツのインデックス化の主要な手段です。この例で示すように、連続取り込み方式で使用できます。コンテンツは一連の抽出とビルドのステージを通してパイプライン処理され、グラフはすぐにデータで埋められ始め、取り込みが続いている最中でもクエリを実行できるようになります。また、抽出とビルドのステージを別々に実行することもできます。1 回限りのジョブを実行する場合だけでなく、同じ抽出されたコンテンツを再利用してグラフを複数回構築したい場合にこの仕組みが役立ちます。

LexicalGraphIndex は、グラフストアとベクトルストアで構成されています。この例では、 Neptune Database グラフストアと Amazon OpenSearch Serverless ベクトルストアを使用しています。執筆時点で、このツールキットは Neptune Database と Neptune Analytics 、OpenSearch Serverless、およびコンテンツの抽出と埋め込みに使用される基盤モデル用の Amazon Bedrock をサポートしています。

前述の例では、インデックス化するコンテンツとして、 Neptune のドキュメントの複数ページを取り込んでいます。データをパースしてインデックスに取り込むために、 LlamaIndexSimpleWebPageReader を使用しています。ソースデータの種類と場所に応じて、 SimpleDirectoryReaderJSONReader を含む他の LlamaIndex リーダーを使用してデータをインデックスにロードすることもできます。

クエリ処理

クエリ処理、つまり質問応答は、インデックス化と同じくらい簡単です。

from graphrag_toolkit import LexicalGraphQueryEngine
from graphrag_toolkit.storage import GraphStoreFactory
from graphrag_toolkit.storage import VectorStoreFactory

import nest_asyncio
nest_asyncio.apply()

graph_store = GraphStoreFactory.for_graph_store(
    'neptune-db://my-graph.cluster-abcdefghijkl.us-east-1.neptune.amazonaws.com'
)

vector_store = VectorStoreFactory.for_vector_store(
    'aoss://https://abcdefghijkl.us-east-1.aoss.amazonaws.com'
)

query_engine = LexicalGraphQueryEngine.for_traversal_based_search(
    graph_store, 
    vector_store
)

response = query_engine.query('''What are the differences between Neptune Database 
                                 and Neptune Analytics?''')

print(response.response)

クエリ処理は実際には 2 段階のプロセスです。基礎となるストレージから関連情報を取得することから始まり、その後、この情報を大規模言語モデルに渡して回答を生成します。 LexicalGraphQueryEngine はこの両方のステップをあなたに代わって実行します。

インデックス化の段階で LexicalGraphIndex を構成したときと同様に、ここでも、グラフストアとベクトルストアを引数にして LexicalGraphQueryEngine を構成しています。一見すると、これは少し冗長に思えるかもしれません。しかし、インデックス化とクエリ処理はそれぞれ異なるプロセスであり、異なる環境で、異なるマシン上で、異なる時間に実行される可能性があります。そのため、各プロセスを構成する際には個別にグラフストアとベクトルストアの URI を指定する必要があります。

GraphRAG Toolkit のインストール

プロジェクトの GitHub リポジトリにあるクイックスタート用の AWS CloudFormation テンプレート を使用して、 GraphRAG Toolkit を使い始めることができます。このテンプレートは、 Neptune Database と OpenSearch Serverless コレクション、そしてサンプルコードを含む Amazon SageMaker ノートブックインスタンスを作成します。これらの例では、 Amazon Bedrock の基盤モデルを使用してコンテンツの抽出と埋め込み、および回答の生成を行います。

前提条件

テンプレートを実行する前に、 Amazon Bedrock で適切な基盤モデルへのアクセスを有効にしていることを確認してください。デフォルトのモデルは以下の通りです:

  • anthropic.claude-3-sonnet-20240229-v1:0
  • cohere.embed-english-v3

クイックスタートの例で構成されているモデル以外でも、ツールキットを構成することができます。

CloudFormation スタックは、これらのモデルを提供している AWS リージョンで実行する必要があり、ノートブック例を実行する前にモデルへのアクセスを有効にする必要があります。

CloudFormation スタックのデプロイ

以下のスクリーンショットは、 CloudFormation テンプレートのスタックの詳細を示しています。

まず、スタック名を指定する必要があります。ほとんどのパラメータには適切なデフォルト値が設定されていますが、変更したい項目がいくつかあるかもしれません。

  • ApplicationId – Neptune クラスターとインスタンス、 OpenSearch Serverless コレクションを含むデプロイメント内のリソースの名前付けに使用される一意の識別子を指定する。
  • IamPolicyArn – SageMaker ノートブックインスタンスにアタッチされる追加の AWS Identity and Access Management (IAM) ポリシーの Amazon リソースネーム (ARN) を指定する。このカスタムポリシーには、特定の Amazon Simple Storage Service (Amazon S3) バケットや追加の Amazon Bedrock 基盤モデルなど、使用したい追加リソースへのアクセス権限を含めることができる。

なお、このテンプレートは以下のリソースを作成します。

  • 3 つのプライベートサブネット、1 つのパブリックサブネット、およびインターネットゲートウェイを持つ仮想プライベートクラウド (VPC)
  • 単一の Neptune サーバーレスインスタンスを持つ Neptune Database クラスター
  • パブリックエンドポイントを持つ OpenSearch Serverless コレクション
  • GraphRAG Toolkit のサンプルノートブックを含む SageMaker ノートブック

スタックのデプロイメントが完了したら、 SageMaker サンプルノートブックを開くことができます (スタックの Outputs タブに、ノートブックインスタンスへのリンクを含む NeptuneSagemakerNotebook 出力パラメータがあります)。そして、コンテンツのインデックス化とクエリ処理を開始できます。

ノートブックの実行

ノートブック「01 – Combined-Extract-and-Build」は良い出発点です。各ノートブックの最初のセルでは、 GitHub リポジトリからツールキットをインストールします。なお、このインストールは、デプロイメントごとに 1 回だけ実行する必要があるもので、各ノートブックごとに実行する必要はありません。

インストールが完了したら、2 番目のセルを実行できます。これによりサンプルコンテンツのインデックスが作成されます。

インデックス化が完了したら、コンテンツへのクエリ処理を開始できます。 ノートブック「04 – Querying」では、ツールキットに含まれる異なるクエリ戦略を試すことができます。

リソースのクリーンアップ

デプロイされたリソースはアカウントに課金されます。不要な料金 (米国東部 (バージニア北部) リージョンで約 1.5 ドル/時) が発生しないよう、使用し終わったらスタックを削除することを忘れないでください。

独自のアプリケーションの構築

ツールキットを使用するためには必ずしもクイックスタート用の CloudFormation テンプレートを起動する必要はありません。独自の環境にツールキットをインストールし、他のライブラリやサービスとツールキットを組み合わせて独自の Python アプリケーションを構築できます (あらかじめ必要なグラフとベクトルストアのリソースをプロビジョニングし、適切な基盤モデルへのアクセスを事前に確保する必要はあります)。

ツールキットとその依存関係は pip を使用してインストールできます (現在、ツールキットは PyPi では配布されていませんが、プロジェクトの GitHub リポジトリ上で頻繁にリリースしています)。最新バージョンをインストールするには、プロジェクトのホームページにあるインストール手順に従ってください。

プロジェクトのドキュメントには、インデックス化クエリ処理プロセスの設定と実行に関する多くの例が含まれています。これらの例を自分のアプリケーションで使用するように適応できます。ドキュメントの例はノートブック環境で実行するように書かれています。メインエントリーポイントを持つアプリケーションを構築する場合は、アプリケーションロジックをメソッド内に配置し、if __name__ == ’__main__' ブロックを追加する必要があります:

import os

from graphrag_toolkit import LexicalGraphIndex
from graphrag_toolkit.storage import GraphStoreFactory
from graphrag_toolkit.storage import VectorStoreFactory

from llama_index.readers.web import SimpleWebPageReader

import nest_asyncio
nest_asyncio.apply()

def run_extract_and_build():

    graph_store = GraphStoreFactory.for_graph_store(
        'neptune-db://my-graph.cluster-abcdefghijkl.us-east-1.neptune.amazonaws.com'
    )
    
    vector_store = VectorStoreFactory.for_vector_store(
        'aoss://https://abcdefghijkl.us-east-1.aoss.amazonaws.com'
    )

    graph_index = LexicalGraphIndex(
        graph_store, 
        vector_store
    )

    doc_urls = [
        'https://docs.aws.amazon.com/neptune/latest/userguide/intro.html',
        'https://docs.aws.amazon.com/neptune-analytics/latest/userguide/what-is-neptune-analytics.html',
        'https://docs.aws.amazon.com/neptune-analytics/latest/userguide/neptune-analytics-features.html',
        'https://docs.aws.amazon.com/neptune-analytics/latest/userguide/neptune-analytics-vs-neptune-database.html'
    ]

    docs = SimpleWebPageReader(
        html_to_text=True,
        metadata_fn=lambda url:{'url': url}
    ).load_data(doc_urls)

    graph_index.extract_and_build(docs, show_progress=True)

if __name__ == '__main__':
    run_extract_and_build()

グラフモデルとクエリ戦略の設計

RAG ソリューションを設計する際は、特定のワークロードのニーズをサポートできる適切な検索と生成の戦略、および基盤となるインデックス化とストレージの仕組みを決定するために、Working Backwards (お客様を起点に考える) アプローチを採用するといいでしょう。ワークフローは、どのような質問応答やエンドユーザー、アプリケーションのデータニーズを満たすことを意図していますか?それらのニーズを満たすためにどのようなデータを取得する必要がありますか?どのような検索戦略がこのデータをコンテキストウィンドウに最も効果的に提供しますか?そして、どのようなインデックス構造やデータモデルがそのような検索を最も効率的に促進しますか?

GraphRAG Toolkit は、非構造化および半構造化テキストコンテンツに対する質問応答ワークフローをサポートするように設計されており、特に複数の潜在的に無関係なソースから、またはベクトルベースのソリューションのみでは構造的にアクセスできない情報から関連情報を取得する必要があるワークフローをサポートします。これらは検索ベースのワークフローと呼ぶことができ、数値結果の計算を必要とするカウントベース集計ベースのワークフローとは異なります。

検索ベースのワークフローのニーズを満たすために、システムは質問応答プロセス、つまり基盤モデルに対して関連するテキストコンテンツの断片 (テキストのスニペット、または語彙単位 (lexical unit)) を渡す必要があります。これを念頭に置いて、最初に取り組まなければならない設計上の決定のひとつは、 基盤モデルに提供されるコンテキストの基礎となる語彙単位のサイズはどのくらいにすべきか、ということでした。多くの RAG アプリケーションでは、コンテキストの主要な単位はチャンクです。つまり、コンテキストウィンドウはコーパスから取得されたひとつ以上のチャンクで構成されます。異なるチャンク分割戦略は異なるサイズのチャンクを生成します (チャンクの万能な定義はありません) が、チャンクは通常、個々の文よりも大きく、文書全体よりも小さいものです。

GraphRAG Toolkit では、コンテキストの主要な単位はチャンクではなく、独立した主張や命題であるステートメント (statement) です。ソース文書はチャンクに分割され、これらのチャンクからステートメントが抽出されます。ステートメントはトピック (topic) ごとにテーマ別にグループ化され、事実 (fact) によって裏付けられます。質問応答時に、ツールキットはトピックでグループ化された関連ステートメントのセットを取得し、基盤モデルのコンテキストウィンドウに渡します。

基盤モデルにステートメントの形で語彙単位を提供するという要件により、語彙グラフ (lexical graph) モデルと、語彙グラフモデルをターゲットとする抽出プロセスを設計することになりました。この語彙グラフには 3 つの階層があります。

  • 系統 (lineage) – ソース、チャンク、およびそれらの間の関係。下図の水色パート。
  • 要約 (summarization) – トピック、ステートメント、およびステートメントを裏付ける事実。下図の緑色パート。
  • エンティティ-関係 (entity-relationship) – 基礎となるソースから抽出された個々のエンティティと関係。下図の赤色パート。

以下の図は、全体的な語彙グラフモデルを示しています。

このグラフモデルの詳細については、ツールキットのドキュメントで確認することができます。このセクションでは、緑色で示されている「要約」階層についてより深く掘り下げます。

グラフモデルを設計する際、私たちはしばしばこのモデルを、興味のある物事を表現する能力という観点で考えます。もうひとつの、しかし補完的な視点は、モデルがサポートすることを意図しているアプリケーションとデータのニーズの文脈における、各モデル要素の役割や責任を考えることです。ツールキットのために特定した検索ベースのワークフローのニーズの文脈では、モデルは質問に直接または間接的に関連する離散的な語彙単位の取得をサポートする必要があります。モデルがこの関連性や接続性 (connectedness) をどのように示し適用するかが、検索戦略の効果を大きく決定します。単にすべてのものをすべてのものに結びつけてしまうと、無関係な情報の海の中から関連するコンテキストの単位を抽出することが難しくなります。一方、グラフ内の要素間の接続をほとんど許可しないモデルは、関連はあるものの意味的に異なる情報を発見する機会を減らします。よく設計されたグラフはバランスを取ります。関連性を薄めてしまう膨大な量の接続を避けながら、文脈的に重要だが明白でない関係を発見するのに十分な接続を確保します。

要約階層の要素は、いくつかの異なる責任を果たします。語彙単位の取得に関して、ステートメント (statement) は基盤モデルに返される主要なコンテキストの単位として機能します。接続性に関して、要約階層はローカルとグローバルの接続性を区別します。トピック (topic) は同じソースから派生したステートメント間のローカルな主題的接続を提供します。事実 (fact) は異なるソースから派生したステートメント間のグローバルな接続を提供します。また、トピックと事実には二次的な責任もあります。トピックはステートメントをグループ化する役割を果たし、事実はステートメントに注釈を付けたりより詳細な情報を提供したりします。ローカルとグローバルの接続性の責任のこの区分により、検索戦略はグラフの探索を制御できます。例えば、リトリーバー (retriever) はより遠い機会を試験的に探索しつつ、主にローカルに留まることを選択できます。あるいは、広く探索し始めてから、最も有望なトピックに絞り込むこともできます。

グラフからコンテンツを取得する際、検索戦略はまずひとつ以上の適切なエントリーポイントを見つけ、その後関連するステートメントに移動します。ベクトルストアはここでエントリーポイントを見つけるのに重要な役割を果たします。現在の語彙グラフの実装では、ステートメントとチャンクの両方が埋め込まれています。そのため、リトリーバーはチャンクレベルまたはステートメントレベルで質問と意味的に類似したエントリーポイントを見つけ、そこから近隣のローカルステートメントを探索し、より間接的に接続された遠いステートメントにホップすることができます。リトリーバーはまた、エンティティ-関係階層のエンティティに対してキーワード検索を実行し、そこからステートメントとトピックに移動することもできます。この方法は通常、より広範なステートメントのセットを生成します。

ツールキットには現在、TraversalBasedRetrieverSemanticGuidedRetriever というふたつの異なる高レベルのリトリーバーが含まれています。 TraversalBasedRetriever は、ベクトル類似度検索を通じてチャンクを見つけ、これらのチャンクからトピックを通じてステートメントと事実に移動するトップダウン検索と、エンティティのキーワードベースの検索を実行し、事実からステートメントとトピックに進むボトムアップ検索を組み合わせて使用します。SemanticGuidedRetriever は、ベクトルベースの意味検索と構造化されたグラフ走査を組み合わせます。意味検索とキーワード検索を通じてエントリーポイントを特定し、その後ビーム検索 (beam search) とパス分析 (path analysis) を通じてグラフをインテリジェントに探索し、再ランク付け (reranking) と多様性フィルタリング (diversity filtering) を使用して質の高い結果を得ます。このハイブリッドアプローチにより、正確なマッチングと文脈的な探索の両方が可能になります。

まとめ

この記事では、 GraphRAG Toolkit の使い方について説明しました。このオープンソースの Python ライブラリは、構造的に関連する情報を取得するためにグラフを使用する RAG アプリケーションの構築を支援できます。

ぜひ、ご自身のユースケースでツールキットを試してみて、フィードバックを共有してください。


著者について

Ian Robinson は Amazon Neptune のプリンシパルグラフアーキテクトです。著書に「Graph Databases」と「REST in Practice」(いずれも O’Reilly 出版) があり、「REST: From Research to Practice」(Springer) と「Service Design Patterns」(Addison-Wesley) の共著者です。

Abdellah Ghassel は Amazon Neptune の機械学習エンジニアとしてインターンをしています。

本稿の翻訳は AWS Japan の機械学習スペシャリストソリューションアーキテクトの本橋が担当しました。