GraphRAG をもくもく会の教材 104 本に適用してみた
— 原論文の主張は、自分のコーパスでも再現するか

論文の主張は 3 つとも再現した。そして論文に書いていないことが 2 つ見えた

• 再現した：①全体俯瞰の問いでは包括性・多様性で勝つ、②特定の問いでは naive RAG が勝つ（Global Search は「言えることがない」と答えた）、③LLM 審判の位置バイアスは実在する
• 論文に無かった発見①：エンティティの型の揺れで同名ノードが分裂する。「Project Panama」は 5 つの型に分かれて 5 ノードになった。名前＋型の完全一致という MS 準拠の統合は、日本語混在コーパスでは粗すぎる
• 論文に無かった発見②：根拠を「教材 ID」で出すと、審判（＝人間も同じ）は検証できず「存在しない ID を挙げている」と疑う。provenance は人が照合できる形（題名・URL）でなければ効かない

原論文の手順を、最小構成で自前実装した

Microsoft の公式実装は使わず、原論文の 6 段をそのまま Python 400 行で書いた。理由は 2 つ。段ごとの数字（言及数、統合率、コミュニティ数、トークン数）を取りたかったこと、 そして LLM を手元の DGX Spark（vLLM）に向けたかったこと。埋め込みは Mac の Ollama。

7,144 の言及が 2,936 ノードになり、196 のコミュニティに割れた

名寄せの実測：MS 準拠の統合は何を取りこぼすか

公式実装は「名前とタイプが完全一致したら同一エンティティ」とみなす。前回の記事で「表記ゆれの名寄せはしない」と書いたが、実際にどれだけ漏れるかを数えた。

分裂の主犯は表記ゆれ（HuggingFace／Hugging Face、KV キャッシュ／KVキャッシュ、GGUF／gguf）よりも型の揺れだった。 同じ「MCP」がある unit では「技術・手法」、別の unit では「ツール・製品・モデル」と判定される。LLM 抽出の型付けは文脈依存なので、これは避けられない。 統合キーから型を外す（名前だけで束ね、型は多数決で決める）のが現実的な改善で、次にやるならここから直す。

コミュニティ地図

大きなコミュニティ上位 16 と、LLM が付けた題

題はすべて LLM が付けたもので、人手は入れていない。サイトのカテゴリ（環境構築／AI技術教材／IP × AI…）とは違う切り口で塊ができているのが面白い。 たとえば L0-6 は「AI エージェント設計パターン」と「高峰譲吉の日米特許戦略」と「知財ビジネスモデル図鑑」が同じ塊にいる。人間の目には別カテゴリだが、 グラフ上では「制度上の位置取り」というエンティティで橋がかかっていた。コミュニティ要約は、サイト運営者が意識していなかった教材の隣接関係を出してくる。これは Global Search の副産物として最も実用的だった。

7 問対決：全体俯瞰 5 問と、特定 2 問

原論文の「global sensemaking」に相当する問いを 5 つ、対照として「1 本の教材に答えがある」問いを 2 つ用意した。 GraphRAG 側は根レベル要約 100 本への map-reduce、naive 側は埋め込み類似の上位 8 チャンク。生成モデルは同じ。

Global Search は問いによらず約 4 万トークンを読む（要約 100 本を全部舐めるため）。naive は 4〜7 千。問い合わせ 1 回あたり約 8〜10 倍。 q6・q7 で Graph が速いのは、map 段で「言えることなし（score 0）」が大半になり reduce の入力が空に近くなったから——つまり速いのではなく答えられていない。

q2「AI が最も効く工程」— 両者の答え方の違い

どちらが「良い」かは読む人による。Graph は網羅的だが各項目は浅く、naive は狭いが引用が正確で具体的。 原論文が包括性・多様性と直接性を対立軸に置いた理由が、そのまま出た。

q4「手薄な領域」— Global Search が最も向いていた問い

「無いものを問う」問いは、全体を見ないと答えられない。ここが GraphRAG の存在理由で、サイト運営者として最も実用的な答えが出た問いでもあった（商標・意匠・著作権が手薄なのは事実である）。

q6「LLM-jp-4 の導入手順」— Global Search は答えなかった

コミュニティ要約には「LLM-jp-4 は NII の国産 LLM で Ollama で動く」までは入っているが、convert_hf_to_gguf.py のような手順の粒度は要約の時点で落ちている。 Han et al. が "Global search retrieves high-level community summaries, which can lose fine-grained evidence" と書いたそのままで、手順・数値・条文のような細部は要約を経由した時点で失われる。 公式実装に Local Search と DRIFT が別途ある理由がここにある。

提示順を入れ替えて 2 回判定させた

原論文と同じ 3 指標（包括性・多様性・直接性）を LLM に一対比較で判定させた。Han et al. の「提示順で判定が変わる」指摘を確かめるため、 Graph を回答 1 にした版と、naive を回答 1 にした版の両方を判定させている。

「Graph」「naive」は両方の提示順で同じ判定だったもの。全体俯瞰の q2〜q5 では包括性・多様性とも Graph が 4/4、特定の q6・q7 では naive が全指標で勝ち、いずれも順序に依存しなかった。 原論文の結果（包括性・多様性で Graph、直接性で naive）と Han et al. の結果（局所 QA では RAG）が、7 問の範囲で両方とも出た。

索引に 173 万トークン、問い合わせ 1 回に 4 万トークン

Han et al. の「構築時間 41 倍」に対し、ここでは 83 分 vs 30 秒で 約 170 倍。ローカル GPU なので金額はゼロだが、API 従量で見積もると 173 万トークン × （入力 $3 / 出力 $15 per 1M 程度の価格帯）≈ $15 前後を、104 本のサイトの索引 1 回に払う計算になる。 問い合わせは 1 回 4 万トークンなので、100 問で索引と同じ額に届く。

原論文が「根レベル要約 C0 は原文の 2〜3%」と書いたのは問い合わせ時のコンテキスト量の話で、索引時のコストとは別。ここを混同すると「GraphRAG は安い」という逆の印象になる。 索引を LLM で作る限り、Microsoft 自身が LazyGraphRAG で「索引コストをベクトル RAG 並みに」した理由は数字で腹落ちする。

原論文・後続研究の主張と、この実験の結果

次の 1 回で直す 4 点

1. 統合キーから型を外す。名前（緩い正規化後）で束ね、型は多数決。これだけで 500 ノード前後が減り、コミュニティの橋が増えるはず。
2. 根拠は題名＋URL で出す。map 段のプロンプトに渡す要約に教材の題名を含め、ID を出させない。審判にも人にも照合できる形にする。
3. Local Search を足し、問いを振り分ける。Han et al. の「Selection」——問いが global か local かを先に LLM に判定させ、local なら naive／Local Search へ。q6 のような回答不能を潰す。
4. 審判を別モデルにし、順序入れ替えで不一致なら「引き分け」扱いにする。今回は生成と審判が同じ Qwen で、自己選好バイアスを否定できない。

そして「このサイトに GraphRAG は要るか」への答えは、問い合わせ用途では要らない、索引の副産物は要る。 104 本の教材に対して読者が投げる問いの大半は local で、naive RAG で足りる。一方、347 本のコミュニティ要約と「手薄な領域」の答えは、 サイト運営者にとって教材群の棚卸しとしてそのまま使える。用途を「検索」ではなく「棚卸し」に置くと、索引コストは年に数回払えばよいものになる。

環境と設計メモ

• LLM：unsloth/Qwen3.8-27B-NVFP4 を vLLM（DGX Spark GB10、max_model_len 65,536、thinking 無効）で OpenAI 互換 API として提供。抽出は temperature 0、max_tokens 1,500。16 並列で 1 unit あたり実効 ≈10 秒
• 埋め込み：Mac 上の Ollama nomic-embed-text。511 本で 30 秒
• グラフ：networkx 3.6 + python-igraph 1.0 + leidenalg（ModularityVertexPartition, seed 固定）
• 抽出プロンプトの要点：型を 8 種に固定／「名前は原文表記のまま、略称と正式名があれば正式名」／一般語（AI・データ・企業）は除外／1 unit あたり entities・relations 各 25 まで／JSON のみ
• 要約プロンプトの要点：題（10〜25 字）・要約（200〜400 字）・findings（3〜6）・rating（1〜10）。根は子レポートを先頭に付けて渡す。入力は 9,000 字で打ち切り
• Global Search：要約をシャッフルして 9,000 字ずつ束ね、map で部分回答＋0〜100 点、0 点は捨て、点数順に 14,000 字まで詰めて reduce。原論文 §2 のまま
• 再開可能性：抽出結果は unit 単位で jsonl に追記し、落ちても続きから。83 分の処理で 1 回 vLLM のタイムアウトがあり、これが効いた