清水理史の「イニシャルB」
AIのRAGが「GraphRAG」に進化! Microsoftが公開したツールでその性能を試す
構造化により、より精度の高い回答が可能に
2024年7月29日 06:00
Microsoft Researchから、「GraphRAG」を簡単に試せるツールが公開された。GraphRAGは、「Graph」と呼ばれる構造化データを参照して回答を生成するRAG(Retrieval Augmented Generation)の手法だ。文章などの非構造化データから情報を取り出し、それぞれの関係を表すKnowledge Graphを生成し、構造化データとして検索ソースとして利用する。実際に試してみた。
従来のRAGとの違い
GraphRAGは、例えるなら、図式化した文書を基に回答する検索方法だ。
以前、本コラムで「RAG」や「Knowledge Graph」について解説したが、GraphRAGは、これらを組み合わせた方法だ。構造化(Knowledge Graph化)された文書に対して検索を実行することで(RAG)、特定の情報ソースに対して、より精度の高い回答を実現する方法となっている。
RAGとは? Graphとは? という方は、以下の関連記事にざっと目を通しておいてもらえると、以降も理解しやすくなるだろう。
現状のシンプルなRAG(naive RAGと呼ばれている)は、長い文書を「チャンク」と呼ばれる文書に分割してからベクトル化(意味論的な内容を多次元空間内における座標に変換)し、ベクトル検索によって近い意味合いを持つチャンクを抽出し、そのチャンクを回答生成のためのソースとしてプロンプトに含める方法が採用されている。
しかしながら、この手法では、検索によって抽出された特定のチャンクのみが情報源となりがちなため、似たようなチャンクが多くあるケースで検索ランクの低いデータを見落したり、データセット全体の傾向を把握できなかったり、といった課題が存在した。
代表的なのが、似たような複数の文書を基に回答するケースだ。
例えば、本サイトの記事を基に回答するチャットボットを作成する場合、シンプルなRAGでも、「Wi-Fi 7の320MHz幅が国内で解禁されたのはいつか?」のような問いの場合、数あるニュース記事の中からピンポイントで該当する段落を探し出せばいいので、正しく回答できる。
しかし、「Wi-Fi 7の現状の課題を分析してください」のように、いくつかのニュース記事を関連付け、それを統合的に整理する必要がある場合、具体的に課題について言及している記事を見つけられないと回答できなかったり、複数の記事で異なる視点(技術的な視点、法的な視点など)から個別に触れられている場合、検索ランクの低い記事を見落としたりするケースがある。
もちろん、従来のRAGでも、複数の検索結果を参照したり、回答をランク付けして整理したりする手法もあるため、まったくできないわけではないが、Graphの場合、本稿冒頭の「Knowledge Graphのイメージ」のように情報同士が結びつき、その関係も明らかにされているため、個別の内容から全体の把握まで、各階層で正確な回答が期待できる。
GraphRAGのしくみ
GraphRAGのしくみを見てみよう。まず、GraphRAGの情報ソースとして利用するKnowledge Graphは、下図のような構造になっている。
図の小さな点が、文章に含まれる「エンティティ」(人、場所、組織などの情報)だ。重要なエンティティは大きな点で表され、それぞれが他のエンティティと結びついており、その関係が「リレーションシップ」として定義されている。
色分けごとに表現されているのが「コミュニティ」で、エンティティ群がトピックごとにカテゴリ分けされている。
GraphRAGでは、このようなKnowledge Graphを検索で活用するために、下図のようなプロセスでインデックス化する。
ソースとなる文書をチャンクに分割し、そこから人、場所、組織などを表すエンティティを抽出。エンティティごとの要約を言語モデルで生成する。これにより、エンティティが一般的な用語としての定義だけでなく、文書の文脈の中でどのように定義されているのかを明らかにし、他のエンティティとどう結びついているのかを明確化できる。
さらに、GraphRAGでは、上図の色分けされたコミュニティ部分の要約も生成する。これにより、エンティティの関係性やまとまりを考慮しつつ、特定のトピックについての全体的な回答が可能となる。
次の図は、GraphRAGを利用してインデックスを生成した際のログの例だ。本連載の直近5回分の記事読み込ませた場合のものとなる。本来は英語で出力されるが、わかりやすくするために日本語に翻訳して掲載している
例えば、「NPU」のエンティティは、NPUという単語そのものを説明するのではなく、「NPUは最適化の文脈で参照されており」と、文書内でどのような「文脈」で使われているのかが示されている。また、「Cocreator」と「NPU」の「relationship」(関係)なども、文書内での記述を基に生成されている。
こうしたGraphRAGのインデックス処理は、言語モデルによって実現されている。標準ではOpenAIのAPIを利用して、以下のようなプロンプトを使って出力される(下図は日本語訳したもの)。
上図の画面は、プロンプト全体の1/3程度で、本来のプロンプトはさらに例やアウトプット方法の定義など、細かく指示されているが、このようなしくみによって、非構造化テキストが構造化データに形を変えることになる。
GraphRAGのテスト環境を作る
それでは、具体的な使い方を紹介する。まずは環境構築だ。
といっても、Pythonが使える環境さえあれば、以下のコマンドを実行するだけでツールのインストールは完了する。今回は、WindowsのWSL2にPython 3.11の環境を構築して試した。
pip install graphrag
▼GraphRAGをインストールする
GraphRAG(GitHub)
GraphRAG(ドキュメント)
インストールが完了したら、次の手順で作業していく。
STEP 1:フォルダーを作成する
まずは、設定やインデックスを保存するフォルダーを作成する。「initialb」の部分をプロジェクトごとの名前に変更して、次のコマンドでテスト用のフォルダーを作成する。
mkdir -p ./initialb/input
STEP 3:設定ファイルを生成する
作成したプロジェクトのフォルダーに移動後、Pythonでgraphrag.indexを呼び出し、「--init」オプションを付けて初期化を実行する。これにより、GraphRAGに必要な各種設定ファイルが自動的に生成される。
STEP 4:APIキーを設定する
「.env」ファイルを開いて、OpenAIのAPIキーを登録する。Azureにデプロイしたモデルや他のAPIサービス、さらには後述するOllamaを使ったローカルモデルも使用できるが、手っ取り早いのはOpenAIのAPIを使うことだ。
STEP 5:モデルを指定する
「settings.yaml」ファイルを編集し、使用する言語モデルを指定する。標準では「gpt-4-turbo-preview」が指定されているが、最新モデルのGPT-4oの方が性能が高く、安いので変更しておく。
「ローカル」「グローバル」検索の結果を比べてみる
同じくコマンドを利用して、用意したソースに対する質問ができる。GraphRAGでは、「ローカル」と「グローバル」という2種類の検索方法が用意されており、どちらを使うかで結果が変わってくる。
ローカルは、従来のシンプルなRAGのようにピンポイントで情報を検索したい場合、グローバルはGraphRAGならではのデータセット全体から統合的な回答を得たい場合に使う方式だ。
実際の違いは、下の2つの図の通りとなる。今回のケースでは、Wi-Fi 7について個別の事例として記述した5つの記事から「Wi-Fi 7の現状の課題を分析してください」と依頼した。
今回の例では各記事の方向性がほぼ同じなので、「グローバル」と「ローカル」の差はあまり明確に現れないが、グローバル検索は「コミュニティ要約」をベースに、全体をざっくりとまとめたものであるのに対して、ローカル検索ではソースとなる文書を引用しながら詳細に説明していることがわかる。
ローカルとグローバルの差については、複数企業の決算報告書を使うなど、個別の文書の内容は異なるが、全体的な傾向がうかがえるようなものを使った方がわかりやすいかもしれない。
GUIのローカルモデルでも使えるが……
以上、今回は、Knowledge Graphを利用したRAGを簡単に試せるGraphRAGを紹介した。
使い方は簡単だが、やっていることはかなり複雑で、しくみもなかなか面白い。特に、どのようなプロンプトでエンティティを取り出したり、要約を生成したりしているのかは、かなりノウハウが詰まった部分でもあり、勉強になる。こうした情報がオープンソースで公開されることには感謝しかない。
なお、GraphRAGの公開後、有志の手によって、GUIで、かつOllamaを使ったローカルモデルでも使えるコードも公開された。
▼GraphRAG Ollama UI
severian42/GraphRAG-Ollama-UI(GitHub)
試してみたが、GUIもシンプルはシンプルなものの、Knoledge Graphのビジュアル化ができるなど便利な印象だ。
しかしながら、Llama3(8B)とMistral(7B)で試してみたが、日本語環境では言語モデルの性能が不足しており、回答がかなり不正確なものとなった。
前掲したプロンプトを見てもわかる通り、GraphRAGでは、言語モデルに対して、かなり複雑な要求を実行する。抽出する情報が何か、それをどう関連付けるか、どのような形式で出力するかといった指示が、例と共に、長く、かなり細かく規定されている。
この長く、細かな指示を正確に理解して、意図通りに動作するには、GPT-4oのような賢いモデルでないと厳しい。海外では、ローカルモデルでも使えている例も見かけるが、日本語の場合、日本語に単に対応しているだけでなく、内容を正確に理解できる性能が必要と言えそうだ。
ローカルで動作する小規模な言語モデル(SLM)も、日本語に対応するうえ、日本に関する知識もそこそこ備えるようになってきたが、GraphRAGに関して言えば、インデックス作成時の指示の理解と、その指示通りにソース文書を深く分析できる能力が非常に重要になる。そうした意味では、日本発の小規模なモデルでの活用に期待したいところだ。