この記事の要点
- 学術論文の知見を統合する RAG を作るとき、Classic RAG では マルチホップ推論・エンティティ同一性・矛盾検出 で力不足
- Microsoft GraphRAG はコミュニティ要約が強いが Factoid QA に弱い (HotpotQA 正解率 51.6%)
- 論文 MemGraphRAG (KDD 2026) を TypeScript でクリーンルーム実装したのが aira-synapse
- 当初は Neo4j (Docker 必須) / LadybugDB (WAL バグで頓挫) を試したが、研究者が個人 PC で完結できる構成を諦められず 専用グラフDB
aira-graphdbを Rust でゼロから開発- HotpotQA 500問で正解率 89.4% / 意味一致正解率 91.2% を達成。論文 GPT-4o-mini 71.6% に対し +19.6pt
- 日本語版にも GINZA 統合で対応し、GPT-5.5 で正解率 78.3%（Neo4j 基準値 58.5% から +19.8pt）。Comparison は 90.7% で EN に迫る
用語: Str-Acc (文字列一致正解率) = 正解文字列との完全一致ベース、LLM-Acc (意味一致正解率) = LLM による意味同等判定を含む正解率。HotpotQA の問題は Bridge（2文書を橋渡しして推論）と Comparison（2エンティティを比較して判断）の2種に分類される。PPR = Personalized PageRank（個人化ページランク）、RRF = Reciprocal Rank Fusion（逆順位融合）。
AI for Science 時代に、なぜ専用の RAG が必要なのか
科学研究の世界では、毎年数百万本の論文が発表されている。生命科学だけでも年間 150 万本以上。一人の研究者が読める量をはるかに超えており、関連する知見が別の分野・別の年代の論文に埋もれている ことは珍しくない。
LLM の登場で「論文を読ませて質問する」ことは可能になった。しかし LLM 単体では、
- 学習データに含まれない最新論文 には答えられない
- 根拠を提示できない（どの論文のどの記述に基づくか不明）
- ハルシネーション で存在しない引用を生成するリスクがある
これを解決するのが RAG（Retrieval-Augmented Generation）— 論文コーパスから関連情報を検索し、それを根拠として LLM に回答させる仕組みである。しかし、学術論文に特化した RAG を作ろうとすると、話はそう単純ではなかった。
試行錯誤の全体像
筆者は以下の順に手法を試し、最終的に自作システムに至った。
Classic RAG（ベクトル検索 + top-k）
→ ❌ マルチホップ推論ができない。HotpotQA で 50% 以下
→ 学術論文は「複数の文書をまたいだ関係性」が本質。ベクトル類似度だけでは不足
Microsoft GraphRAG（コミュニティ要約型）
→ △ グローバル要約には強いが、Factoid QA 正解率 51.6%
→ 要約に情報が丸められ、個別の事実を正確に取り出せない
MemGraphRAG（KDD 2026 論文 — メモリベース + マルチエージェント）
→ ○ 三層メモリ + スキーマ安定化で 71.6%。方向性は正しい
→ しかし Python + NetworkX 実装で MCP 統合なし、日本語非対応
aira-synapse（MemGraphRAG のクリーンルーム実装 + 独自拡張）
→ ◎ 論文のみからゼロ実装したことで、アルゴリズムの本質と限界を深く理解
→ 論文にない 3 つの拡張（Hybrid RRF, 専門用語辞書, シソーラス正規化）を追加
→ HotpotQA 意味一致正解率 91.2%（論文比 +19.6pt）
クリーンルーム実装（論文の記述のみから再実装し、公式コードは参照しない方式）を通じてわかったのは、
- 三層メモリ・スキーマ安定化・矛盾検出・PPR はすべて精度に寄与する — 論文の主張は正しい
- ただし、論文に書かれていない改善が最も効く — Vector + BM25 のハイブリッド検索と、評価関数の統一で +20pt 以上の差がつく
-
研究者の手元で動かすには、DB を含めて自作する覚悟が要る — Neo4j は重く、LadybugDB はバグで頓挫し、最終的に Rust で専用 DB
aira-graphdbをゼロから開発した
以下、各ステップの詳細を順に解説する。
1. Classic RAG の限界 — 学術論文で精度が出ない理由
学術論文を対象にした RAG は、一般的な FAQ や社内ドキュメント検索とは性質が大きく異なる。
| 課題 | 具体例 | Classic RAG の挙動 |
|---|---|---|
| マルチホップ推論 | 「PPR を使った GraphRAG で最も精度が高い手法は？」 | ❌ 単一チャンクで答えが完結しない |
| エンティティの同一性 | "PPR" = "Personalized PageRank" = "Topic-Sensitive PageRank" | ❌ 別物として索引化される |
| 矛盾するファクト | 論文A「手法Xは95%」vs 論文B「手法Xは80%」 | ❌ 矛盾を検出できない |
| 長い推論連鎖 | 「Aの提唱者が所属していた研究室の系譜」 | ❌ チャンク跨ぎの関係が落ちる |
| 専門用語の同義語 | "TF-IDF" ↔ "term frequency–inverse document frequency" | ❌ 表記揺れで取り逃す |
Classic RAG（埋め込みベクトル + top-k 検索 + LLM 生成）は、「1つの文書に答えが書かれている」場合には十分機能する。しかし学術論文の知識統合では、複数論文・複数チャンクをまたいだ関係性 が本質である。ベクトル類似度だけでは、関係グラフが失われている。
論文 HotpotQA はこのマルチホップ Factoid QA の代表的ベンチマークで、2ホップ以上の推論を強制する ように作られている。Classic RAG は HotpotQA で 50% 台に届かないことが多い。
2. Graph RAG が必要な理由
Graph RAG は、テキストから エンティティと関係を抽出してナレッジグラフ化 し、検索時にグラフ構造を活かす。
Classic RAG:
Query → Embedding → Vector top-k → Chunks → LLM → Answer
Graph RAG:
Query → Entity/Vector → Graph traversal (PPR / community) → Context → LLM → Answer
ナレッジグラフを導入すると以下が解決する。
| 問題 | グラフが効く理由 |
|---|---|
| マルチホップ推論 | エッジを辿って n-hop 先のエンティティに到達可能 |
| エンティティ同一性 | 表記揺れを正規化して同一ノードにマージ |
| 矛盾の可視化 | 同じエンティティに紐づく複数の Fact を並べて比較できる |
| 関係性検索 | 「A の弟子の弟子」のようなパターンマッチが可能 |
ただし、Graph RAG の実装は一様ではない。代表的な系譜を見ていく。
3. 既存 Graph RAG の比較
3.1 Microsoft GraphRAG — コミュニティ要約型
Microsoft GraphRAG (Edge et al., 2024) は Leiden アルゴリズムでコミュニティ検出 → 各コミュニティを LLM で要約 → クエリ時に Map-Reduce する。
Chunking → Entity Extraction → Community Detection (Leiden)
→ Per-community LLM Summary → Query: Map-Reduce of summaries
- ✅ グローバルクエリに強い（「このコーパスの主要テーマは？」）
- ❌ インデックスコストが高い（全コミュニティに LLM 要約が必要）
- ❌ Factoid QA に弱い（要約レベルでしか答えられない）
- ❌ 品質管理機構がない（低レベル抽出ミスが要約に伝播）
- ❌ インクリメンタル更新ができない（論文1本追加で全コミュニティ再構築が必要）
HotpotQA Str-Acc は 51.6%（筆者の検証）。
論文 MemGraphRAG も以下を指摘:
"Despite its utility in summarizing high-level themes, this unsupervised approach faces limitations regarding precision, as inaccuracies in low-level entity relationships can propagate upward."
3.2 LazyGraphRAG — 遅延評価型
LazyGraphRAG (Microsoft Research, 2024) は、インデックス時のコストを 1/100 に削減する遅延評価戦略。
- ✅ コスト効率が極めて高い
- ❌ クエリ時の LLM 呼び出しが増える
- ❌ 構造化ナレッジグラフを構築しない（あくまで軽量 NLP）
3.3 MemGraphRAG — メモリベース＋マルチエージェント
KDD 2026 論文 MemGraphRAG (Xiang et al.) は、コミュニティ検出を捨て、三層グローバルメモリ と マルチエージェント協調 でグラフ品質を底上げする。
Chunking
↓ Stage I: Extraction Agent
Three-Layer Memory (Ontology / Fact / Passage)
↓ Stage II: Schema Stabilization (頻度閾値 τ)
↓ Stage III: Conflict Detection & Resolution
↓ Stage IV: Graph Projection
Hierarchical Indexing Graph
↓ PPR (Personalized PageRank, λ=0.5)
Query Response
論文の主張する仕組みは以下の通り。
| 仕組み | 解決する問題 |
|---|---|
| 三層メモリ（Ontology / Fact / Passage） | 抽象度の異なる検索を1つのバックエンドで |
| スキーマ安定化 (τ=2) | 低頻度・ノイズスキーマの除去 |
| 矛盾検出/解決 | 同一エンティティの相反するファクトを検出 |
| PPR（テレポート λ=0.5） | クエリ起点からのグラフ拡散ベース検索 |
報告された HotpotQA 精度は GPT-4o-mini で Str-Acc 67.2% / LLM-Acc 71.6%。
これは Microsoft GraphRAG (51.6%) と比べて十分高いが、論文実装は Python + NetworkX で、MCP 統合も日本語対応もない。
3.4 比較表
| 特性 | MS-GraphRAG | LazyGraphRAG | MemGraphRAG (論文) | aira-synapse (本記事) |
|---|---|---|---|---|
| 言語 | Python | Python | Python | TypeScript + Rust |
| グラフ構築 | Community-based | NLP-only | Memory-based agents | Memory-based agents |
| メモリ層 | なし | なし | 3層 | 3層 + 辞書/シソーラス |
| スキーマ安定化 | × | × | ✓ | ✓ |
| 矛盾検出 | × | × | ✓ | ✓ |
| PPR | × | × | ✓ | ✓ (hub 抑制付き) |
| ハイブリッド検索 | × | × | × | ✓ (Vector + BM25 RRF) |
| Graph/Index backend | FAISS (vector) | — | NetworkX (in-memory) | aira-graphdb (Rust, 永続化) |
| 日本語 | × | × | × | ✓ (GINZA) |
| HotpotQA Str-Acc | 51.6% | 52.7% | 67.2% | 89.4% |
| HotpotQA LLM-Acc | — | — | 71.6% | 91.2% |
4. aira-synapse が目指したもの
aira-synapse は MemGraphRAG 論文のアルゴリズムを TypeScript で完全クリーンルーム実装 したライブラリ + MCP サーバーである。ここでの「クリーンルーム実装」とは、論文の記述（アルゴリズム・数式・図）のみを参照し、公式 Python 実装のソースコードは一切参照せずにゼロから書き直した ことを意味する。
設計の根本にあるのは以下3つ。
4.1 再現性 — 論文の主張を独立検証する
論文の精度を鵜呑みにせず、ゼロから実装して同条件で検証する。aira-synapse の実装で確認できたのは、
- 三層メモリ・スキーマ安定化・矛盾検出・PPR は すべて精度に寄与する
- 一方、サブクエリ分解は LLM の非決定性で bridge 問題が不安定になる
- 専門用語辞書をテレポートベクトルに注入すると -3.4% の退行 が出ることもある（ablation で判明）
- 最大の改善は論文に書かれていない eval 関数の改善 と Vector+BM25 ハイブリッド
4.2 拡張性 — 日本語論文・専門分野に対応する
論文の公式実装は英語前提。日本の研究者が使うには、
- 日本語形態素解析（GINZA / spaCy）が必須
- 文境界・トークン推定・NER をすべて言語固有にしなければならない
- カタカナ表記揺れ（「コンピュータ」「コンピューター」）の正規化が要る
aira-synapse は Python sidecar 経由で GINZA を呼び出し、チャンキング・NER・トークン推定の全てを日本語専用パイプライン に切り替えられる設計とした。
4.3 実用性 — 研究者個人の PC で完結する
Microsoft GraphRAG や論文実装は クラウド前提 または 重い依存（Docker / JVM） を要求する。研究者が自分のラップトップで「論文 PDF を放り込んで質問する」を完結させたい。
これが後述の 専用グラフDB aira-graphdb を作る動機になった。
4.4 aira-synapse 独自の拡張
論文にない機能を3つ追加している。
| 拡張 | 内容 |
|---|---|
| DictionaryBoost | 専門用語辞書による NER ブースト（PPR → Personalized PageRank 等の略語展開） |
| ThesaurusNormalization | 同義語/上位語/下位語によるスキーマ統合 |
| HybridMemoryFilter | Vector + BM25 Reciprocal Rank Fusion (RRF) |
特に最後の Hybrid RRF は HotpotQA Bridge 問題で +1.8pt の改善を出した（後述）。
5. グラフ DB の選定 — なぜ Neo4j / LadybugDB を諦めて Rust で自作したか
aira-synapse の心臓部は「ナレッジグラフを永続化・検索するグラフ DB」である。
ここに何を使うかが、システム全体の運用性と精度の両方を決める。
筆者は順に3つを試した。
5.1 第1案: Neo4j — 精度は出る、しかし運用が重い
最初の実装では Neo4j Community 5.26 を採用。Cypher が書きやすく、HotpotQA でも 88.4% (Str-Acc, 442/500) という最初の高スコアを出した。
しかし運用面で限界があった:
| 課題 | 詳細 |
|---|---|
| Docker / JVM 必須 | 研究者の個人 PC で起動・終了の負担が大きい |
| ライセンス | Enterprise 版機能を将来的に使えない |
| 単一ファイル化できない | バックアップ・配布が複雑 |
| メモリ消費 | ヒープ調整がシビア、6GB DB で起動が遅い |
結論: 精度は出るが、「研究者が論文 PDF を放り込んで質問する」というユースケースには重すぎる。
5.2 第2案: LadybugDB — 軽量だが WAL バグでブロック
次に試したのが LadybugDB（Rust製の組み込みグラフDB）。単一バイナリ・組み込み型・Cypher サポートと条件は揃っていた。
しかし実環境で WAL（Write-Ahead Log）のリカバリーに致命的バグ があり、500問規模のベンチマークで永続化したデータの読み戻しに失敗。修正待ちで止まるわけにいかず断念。
5.3 第3案: aira-graphdb をゼロから Rust で開発
「組み込み・単一ファイル・高速・自分でメンテできる」を全部満たすには、自作するしかない という結論に達した。
5.3.1 aira-graphdb のアーキテクチャ
┌──────────────────────────────────────────────────────┐
│ hotpotqa.agdb (JSON) + hotpotqa.vblob (binary) │
├──────────────────────────────────────────────────────┤
│ nodes: 206K (entity / concept / passage / schema) │
│ edges: 448K (relations, transitions) │
│ vectors: 98K (passage 7.8K + fact 87K + schema 3.2K) │
│ memory: facts 113K + passages 10K + schemas 3.8K │
│ passages: 10K (FTS index) │
╘══════════════════════════════════════════════════════╛
↕ JSON-RPC over stdin/stdout
┌──────────────────────────────────────────────────────┐
│ aira-graphdb-native (Rust release binary) │
│ - Domain RPCs (get_nodes / get_adjacent / ...) │
│ - Vector search: brute-force cosine (f64 SIMD) │
│ - HNSW index (v0.3.0) │
│ - Cypher engine (MATCH/RETURN/relationship filter) │
│ - Persistence: vblob + WAL + atomic rename │
└──────────────────────────────────────────────────────┘
5.3.2 設計判断
| 判断 | 理由 |
|---|---|
| JSON-RPC over stdin/stdout | TS から Rust バイナリを sidecar で起動するだけ。ネットワーク不要 |
単一 .agdb + .vblob |
バックアップは2ファイルコピー。Docker 不要 |
| ドメイン固有 RPC を維持 |
get_adjacent 等はインデックス済みで O(1)。Cypher より速い |
| Cypher は補助 | アドホックなパターンマッチング用にだけ提供 |
| f64 vector + SIMD | 98K × 1536次元ベクトルで brute-force cosine が p95 < 5ms (Apple M3 Max) |
| HNSW (v0.3.0) | 大規模化に備えて段階的に有効化 |
| vblob 分離 (v0.3.0) | ベクトルを外部バイナリに分離して DB サイズを1/3に削減 |
5.3.3 自作で良かったこと
-
精度バグを自分で直せる: フィールド名の不一致 (
vectorvsvalues) で全ベクトルがゼロベクトル化されていた重大バグを発見・修正できた（後述） -
RPC を任意に追加できる:
memory_save_fileのような独自 RPC を必要に応じて生やせる - 永続化フォーマットを制御できる: vblob / WAL / 増分 persist など最適化が自由
-
依存ゼロでバンドル可能: 英語パイプラインは Rust バイナリ同梱で
npm installだけで動く。日本語パイプラインでは追加で Python + GINZA / spaCy の sidecar が必要
6. HotpotQA 最終ベンチマーク結果
500問の HotpotQA で、Neo4j baseline からどう改善が積み上がったかを示す。
6.1 改善の積み上げ（英語版）
改善を システム改善（検索・生成の実質向上）と 評価補正（採点ルールの統一・拡充）に分けて示す。
システム改善（検索・生成が実際に変わったもの）:
| # | バージョン | Str-Acc | 改善 | 主な変更 |
|---|---|---|---|---|
| 1 | Neo4j baseline | 88.4% | — | 基準値 |
| 2 | aira-graphdb 初期 | 55.0% | — | ID ミスマッチ（バグ） |
| 3 | ID 修正 | 64.8% | +9.8% | バッチベース ID 統一 |
| 8 | Entity dedup | 89.0% | +0.2% | "the_X"→"X" マージ (238ペア) |
| 9 | Hybrid RRF | 89.4% | +0.4% | Vector+BM25 fusion |
評価補正（採点ルールの統一・拡充、実回答は変わっていない）:
| # | バージョン | Str-Acc | 改善 | 主な変更 |
|---|---|---|---|---|
| 4 | normalizedContains 補正 | 84.6% | +19.8 | ⚠️ 旧 eval が過剰に厳しかった補正 |
| 6 | eval関数統一 (Rules 5-9) | 87.4% | +2.8 | ニックネーム・国名等のルール追加 |
| 7 | Answer matcher 15種 | 88.8% | +1.4 | 数詞変換等 |
| 10 | LLM-Acc 評価 | 89.4% → 91.2% | +1.8 | LLM Judge 導入 |
⚠️ 重要: #4 の
64.8% → 84.6%は検索精度が上がったのではなく、旧 eval 関数が部分一致を不正解にしていたバグの補正。実回答の内容は同一。バックエンド間の比較では eval 関数を統一してから比較すべき という教訓。
最終結果: Str-Acc 89.4% (447/500), LLM-Acc 91.2% (456/500)
📊 500問評価では 1問 = 0.2pt のため、+0.2〜+0.8pt の差は統計的には小さい（95%信頼区間 ±約2.7pt）。小幅 ablation は大きな方向性を見る目的で解釈している。Bridge subset は 400/500問 (80%)、Comparison は 100/500問 (20%) で構成。
6.2 効いた改善の中身
Vector + BM25 RRF (Bridge +1.8pt, Overall +0.4pt)
ベクトル検索と BM25 を並列実行し、Reciprocal Rank Fusion で統合:
$$\text{RRF}(d) = \sum_{r \in R} \frac{1}{K + r(d)}, \quad K = 60$$
- Vector: 意味的類似度（"米国" → "アメリカ" も拾える）
- BM25: 固有名詞・年号の exact match（"1958年" を確実に取れる）
- BM25-only 結果は係数 0.7 で減衰（過信を防ぐ）
Bridge subset (400問) では +1.8pt の改善だが、Comparison subset (100問) ではほぼ変化なく、全体 (500問) では +0.4pt に希釈されている。Bridge に固有名詞の橋渡しが多いため、BM25 の exact match が効いた。
Entity Deduplication
"the_X" → "X" パターン (238 ペア) を 80K エンティティから検出してマージ。
1,271 エッジをリダイレクトし、Bridge +0.8pt。
eval 関数統一（最大の罠）
Pure-agdb が低く見えていた 18 件の失敗のうち、13 件はベースラインと完全に同じ回答 を返していた。原因は eval 関数の差:
| ルール | 効果 |
|---|---|
| 5: ニックネーム展開 | Rosie ↔ Roseann |
| 6: ステム F1 (60%) | 長い gold answer |
| 7: 国名エイリアス | USA / United States |
| 8: デモニム ↔ 国名 | Northern Irish ↔ Northern Ireland |
| 9: 姓名マッチング | John Lasseter ↔ John Alan Lasseter |
教訓: 異なる eval 関数で比較すると 3pt 以上の偽の精度差 が生じる。バックエンド比較の前に eval を統一せよ。
6.3 LLM-Acc: LLM Judge による意味同等判定
Str-Acc（文字列完全一致ベース）では同義語・表記揺れで取りこぼす問題がある。これを補うため、LLM Judge による意味同等判定を導入した。
LLM Judge の設定:
- Judge model: GPT-5.4-mini（回答生成と同一モデル、ただし独立した別リクエスト）
- Temperature: 0（決定的判定）
- 判定基準: gold answer と LLM 回答が「事実として同じ対象を指しているか」を yes/no で判定
- Ambiguous case: 「部分的に正しい」は不正解扱い（保守的判定）
EN では Str-Acc 89.4% → LLM-Acc 91.2% (+1.8pt, 9問回収)。
| Gold Answer | LLM 回答 | 回収理由 |
|---|---|---|
| novelist | writer | 同義語 |
| Lord Byron | George Gordon Byron, 6th Baron Byron | 正式名 |
| Scottish Premiership club Hearts | Heart of Midlothian | 略称↔正式名 |
| international football competition | FIFA Women's World Cup | 上位概念↔具体例 |
| TOGO company | Kabushiki-gaisha Tōgo | 日英表記 |
| Vivendi S.A. | Universal Music Group | 親会社↔子会社 |
| ... | ... | ... |
6.4 論文との比較
| 手法 | LLM | Str-Acc | LLM-Acc |
|---|---|---|---|
| MemGraphRAG 論文 | GPT-4o-mini | 67.2% | 71.6% |
| aira-synapse + aira-graphdb | GPT-5.4-mini | 89.4% | 91.2% |
| 差分 | — | +22.2pt | +19.6pt |
LLM が新しい（GPT-5.4-mini）こと、Hybrid RRF など独自改善が効いていること、eval 関数を統一していること等の総合効果。
⚠️ 公平性に関する注記: 本比較はモデル世代（GPT-4o-mini vs GPT-5.4-mini）・評価関数・answer matcher が完全には一致していないため、純粋なアルゴリズム差ではなく、実装改善・検索改善・モデル差・評価関数差を含む総合比較 である。同一 LLM での比較は今後の課題。
6.5 日本語版
英語版の知見を日本語にも適用:
| バージョン | Str-Acc | LLM-Acc | 主な変更 |
|---|---|---|---|
| LadybugDB + Neo4j baseline | 58.5% | — | 基準値 |
| aira-graphdb + GINZA 文分割 | 64.3% | — | 形態素ベースのチャンキング |
| v2 (4 施策統合, gpt-5.4-mini) | 70.8% | 70.8% | tokenize + entity expand + dedup + matcher |
| v3 (JA 強制プロンプト) | 67.3% | — | ❌ -3.5pt 棄却 |
| v3 DB (76K facts, 密度3.4倍) | 71.0% | — | +0.2pt（誤差範囲、v2 を採用） |
| v3 + o4-mini | ~64.5% | — | ❌ gpt-5.4-miniより-6.3pt |
| v2 + GPT-5.5 | 78.3% | 78.3% | +7.5pt LLM Judge 18問回収 |
📝 gpt-5.4-mini では LLM Judge による回収が 0問だったが、GPT-5.5 では 18問を回収。これは GPT-5.5 が意味的に正しいが文字列が異なる回答を生成できるようになったことを意味する。GPT-5.4-mini の失敗は同義語・表記揺れではなく 根本的に異なるエンティティを回答する推論エラー であり、LLM の推論力がボトルネックだったことが裏付けられた。実際、より推論力の高い GPT-5.5 に切り替えるだけで +7.5pt（70.8% → 78.3%）の改善が得られたことが、この仮説を裏付けている（後述 §6.6）。
英語と日本語で チャンキング戦略を別物に作り直した ことが鍵。日本語は GINZA の sentencizer + 文字数×0.5 でのトークン推定が必須で、英語と同じ \n\n 分割を流用すると 1 段落 2,000–5,000 文字の巨大チャンクができてしまう。
6.6 JA 精度改善の徹底検証
日本語 70.8% を超えるため、以下を全て試行した。
| 施策 | 効果 | 理由 |
|---|---|---|
| Fact密度3.4倍 (22K→76K) | +0.2pt | 検索失敗は4%のみ、情報量は問題ではない |
| 英語推論プロンプト | -5.1pt | 日本語質問→英語推論の切替でロス発生 |
| o4-mini (推論特化モデル) | -6.3pt | gpt-5.4-miniより日本語処理が弱い |
| JA回答強制プロンプト | -3.5pt | 固有名詞のカタカナ誤変換が増加 |
| JA優先コンテキスト並替 | 逆効果 | 重要な英語Factが後方に押しやられた |
| topK増加 | -1.3pt | ノイズ増加でLLM判断阻害 |
| 2-hop embedding | 無効 | 89%パッセージ重複、ベクトル不動 |
7施策全てが効果なしまたは逆効果。失敗116問の分析で、96%が「具体的だが誤り」（LLM推論エラー）、検索失敗は4%のみであることが判明した。
📝 分類基準: 各失敗問に対し、gold answer の根拠となる supporting fact が retrieved context に含まれているかを確認。含まれているのに不正解 → 「LLM 推論エラー」、含まれていない → 「検索失敗」と分類。116問中 111問は必要な情報を取得できていたが LLM が誤った回答を生成していた。
GPT-5.5 への切り替え — LLM 推論力がボトルネックだった
7施策の失敗から「RAG パイプラインではなく LLM の推論力がボトルネック」と仮説を立て、GPT-5.5 で同一条件の再実験を実施した。
| 指標 | gpt-5.4-mini | GPT-5.5 | 差分 |
|---|---|---|---|
| Overall | 70.8% (283/400) | 78.3% (313/400) | +7.5pt |
| Bridge | 68.5% (215/314) | 74.8% (235/314) | +6.3pt |
| Comparison | 80.2% (69/86) | 90.7% (78/86) | +10.5pt |
| LLM Judge 回収 | 0問 | 18問 | — |
| 所要時間 | ~60min | ~132min | 2.2倍 |
Comparison 90.7% は EN の 90.0% を超えた。RAG パイプラインの改善では全く動かなかった精度が、LLM を変えるだけで +7.5pt 改善したことは、ボトルネックの正確な特定が最も重要 であることを示している。
6.7 EN vs JA ギャップの根本原因
| 指標 | EN (gpt-5.4-mini) | JA (gpt-5.4-mini) | JA (GPT-5.5) | Gap (mini) | Gap (5.5) |
|---|---|---|---|---|---|
| Overall | 89.4% | 70.8% | 78.3% | 18.6pt | 11.1pt |
| Bridge | 89.3% | 68.5% | 74.8% | 20.8pt | 14.5pt |
| Comparison | 90.0% | 80.2% | 90.7% | 9.8pt | -0.7pt |
GPT-5.5 により Comparison は EN を超え、Gap は 18.6pt → 11.1pt に縮小。残差の支配的要因は Bridge問題の14.5pt差:
- 日英混在コーパスでの推論チェーン断絶 — JA コーパス（日本語 Wikipedia）にも英語固有名詞が多数混在し、エンティティ A → 関連情報 → エンティティ B の推論チェーンが切れる
- LLM の日本語推論力の限界 — GPT-5.4-mini は英語の訓練データ量が圧倒的に多く、日英混在コンテキストからの多段推論で精度が低下
- コーパス品質の差 — EN は英語 Wikipedia オリジナル（エンティティ表記が統一）、JA は翻訳記事が多く表記揺れが大きい（ヴィ/ビ、ー/長音省略等）
- 評価の厳しさ — カタカナ変換の揺れで取りこぼしが発生し、LLM Judge でも回収不能（応答自体が別エンティティ）
結論: JA 70.8% は gpt-5.4-mini での実質的な頭打ちだった。7つのRAGパイプライン改善策を試行していずれも効果がなかったことから、LLM の日本語推論力がボトルネック であると仮説を立て、GPT-5.5 で再実験した結果 78.3% (+7.5pt) を達成。特に Comparison は 90.7% まで伸び、EN の 90.0% を超えた。残る Bridge 問題の Gap (14.5pt) は、日英混在コーパスでの推論チェーン断絶とコーパス品質の差が原因であり、今後のモデル改善と多言語対応の進展に期待したい。
7. 最終構成
┌───────────────────────────────────────────────────────────┐
│ HotpotQA Benchmark Results │
│ EN: Str-Acc 89.4% (447/500), LLM-Acc 91.2% (456/500) │
│ JA: Str-Acc 78.3% (313/400) [GPT-5.5] │
│ Str-Acc 70.8% (283/400) [gpt-5.4-mini] │
│ Bridge: EN 89.3% / JA 74.8% (Gap: 14.5pt) │
│ Compare: EN 90.0% / JA 90.7% (JA が EN を超過!) │
├───────────────────────────────────────────────────────────┤
│ LLM: GPT-5.4-mini / GPT-5.5 (reasoning_effort=high) │
│ Retrieval: HybridMemoryFilter (Vector + BM25 RRF, K=60) │
│ Graph: AiraGraphDbGraphProjection (206K nodes, 448K edges)│
│ Vector: AiraGraphDbVectorIndex (98K vectors, f64) │
│ Memory: AiraGraphDbMemoryStore (113K facts, 10K passages) │
│ Dict/Thesaurus: SQLite │
│ HyperParams: hub=50, topK=10, topM=10, ctx=3000 │
│ Backend: Pure aira-graphdb (.agdb + .vblob, 単一プロセス) │
│ Paper baseline: EN Str-Acc 67.2%, LLM-Acc 71.6% │
│ vs Paper: EN +22.2pt (Str-Acc), +19.6pt (LLM-Acc) │
└───────────────────────────────────────────────────────────┘
研究者の個人 PC で、
- 論文 PDF を Docling で Markdown 化
-
aira-synapse indexでナレッジグラフに投入 - MCP 経由で Claude Desktop / VS Code Copilot から自然言語で質問
- 根拠パッセージ付き回答が返る
これが Docker なし・JVM なし・単一バイナリ + 2ファイルの DB で動く。
7.1 研究者の利用シーン — 何ができるのか
実際の研究ワークフローでの使い方を示す。
シーン 1: サーベイ論文の横断検索
あなた: 「Personalized PageRank を Graph RAG に応用した論文で、
HotpotQA 以外のベンチマークで評価しているものは？」
aira-synapse: PPR を Graph RAG に応用した研究として以下が該当します:
- Xiang et al. (2026) MemGraphRAG — HotpotQA + MuSiQue + 2WikiMultihopQA
- ...
[根拠: passage-1234 (Xiang2026, Section 4.2), passage-5678 (...)]]
Classic RAG では「PPR」「Personalized PageRank」「Topic-Sensitive PageRank」が同じ概念だと認識できず、該当論文を取りこぼす。aira-synapse はスキーマ安定化とシソーラスでこれらを同一エンティティに統合済み。
シーン 2: 矛盾するファクトの検出
あなた: 「手法 X の精度について、論文間で食い違いがないか？」
aira-synapse: 手法 X について矛盾するファクトを検出しました:
- 論文 A: 「F1 = 95.2%」(passage-2345)
- 論文 B: 「F1 = 80.1%」(passage-6789)
差異の原因: データセットが異なる (SQuAD vs NaturalQuestions)
シーン 3: MCP 経由で Claude Desktop / VS Code から直接質問
# 論文 PDF を投入（Docling で Markdown 化 → ナレッジグラフ構築）
aira-synapse index --input ./papers/*.pdf
# MCP サーバー起動 → Claude Desktop / VS Code Copilot に接続
aira-synapse mcp --db ./my-research.agdb
Claude Desktop の設定に MCP サーバーを追加すれば、普段のチャットから「この論文群の中で〜」と質問できる。根拠パッセージ付きで回答が返るため、ハルシネーションを検証可能。
8. まとめ
学術論文から知見を引き出す RAG を本気で作ると、何が必要で何が効かないのか。本記事の全実験から得られた結論を整理する。
なぜ専用の Graph RAG が必要なのか
| アプローチ | HotpotQA | 限界 |
|---|---|---|
| Classic RAG (Vector + top-k) | ~50% 以下 | マルチホップ推論・エンティティ同一性・矛盾検出が不可能 |
| Microsoft GraphRAG | 51.6% | コミュニティ要約型。Factoid QA に弱く、論文追加のたびに全再構築 |
| MemGraphRAG 論文 (GPT-4o-mini) | 71.6% | 三層メモリ＋マルチエージェント。方向性は正しいが未最適化 |
| aira-synapse (本実装) | 91.2% | 論文比 +19.6pt。クリーンルーム実装＋独自拡張 |
達成した精度
| 言語 | モデル | Str-Acc | LLM-Acc | vs 論文 |
|---|---|---|---|---|
| EN | GPT-5.4-mini | 89.4% (447/500) | 91.2% (456/500) | +19.6pt |
| JA | GPT-5.4-mini | 70.8% (283/400) | 70.8% | baseline |
| JA | GPT-5.5 | 78.3% (313/400) | 78.3% | +7.5pt vs mini |
日本語 Comparison は 90.7% で英語の 90.0% を超えた。
得られた7つの知見
- メモリベースの抽出 + スキーマ安定化 がグラフ品質の鍵 — コミュニティ検出ではなく、Fact 単位の品質管理が精度を決める
- Vector と BM25 は相補的 — RRF 統合で Bridge +1.8pt。どちらか一方では取りこぼす
- eval 関数の統一がベンチマークの前提条件 — バックエンドより eval で 3pt 動く。比較前に必ず統一せよ
-
多言語対応はチャンキング層から作り直す — 英語の
\n\n分割を流用すると巨大チャンクが生まれ精度が崩壊する - 研究者の手元で動く RAG には DB 自作の覚悟が要る — Neo4j は重く、LadybugDB はバグで頓挫し、Rust で aira-graphdb を書いた
- Fact 密度を 3.4 倍にしても +0.2pt — 検索品質ではなく LLM 推論力が天井。GPT-5.5 で +7.5pt がその証拠
- ボトルネックの正確な特定が最も重要 — 7つの RAG 改善策が全て無効だった原因は LLM 側にあった。GPT-5.5 への切替だけで Comparison は EN を超えた
技術選定の判断軸
| 判断 | 選んだもの | 理由 |
|---|---|---|
| グラフ構築 | 三層メモリ + マルチエージェント | コミュニティ要約型より Factoid QA に強い |
| 検索 | Hybrid RRF (Vector + BM25) | 単独では取りこぼす情報を相補的にカバー |
| DB | aira-graphdb (Rust 自作) | Docker不要・単一ファイル・研究者の手元で完結 |
| 日本語チャンキング | GINZA sentencizer | 文境界で切らないと固有名詞が分断される |
| LLM | GPT-5.4-mini (デフォルト) / GPT-5.5 (高精度) | コスト vs 精度のトレードオフで選択可能 |
aira-synapse / aira-graphdb のソースは GitHub (nahisaho/aira-synapse) で公開中。精度改善の全履歴と ADR は aira-graphdb-accuracy-journey.md を参照。
試してみたい方へ
# 1. aira-graphdb (Rust 製グラフDB) をビルド
git clone https://github.com/nahisaho/aira-graphdb.git
cd aira-graphdb && cargo build --release
# PATH に追加（または cp target/release/aira-graphdb /usr/local/bin/）
# 2. aira-synapse (Graph RAG エンジン) をセットアップ
git clone https://github.com/nahisaho/aira-synapse.git
cd aira-synapse && npm install && npm run build
# 3. 論文 PDF を投入してナレッジグラフ構築
aira-synapse index --input ./your-papers/*.pdf
# 4. MCP サーバーを起動して Claude Desktop / VS Code Copilot に接続
aira-synapse mcp --db ./your-research.agdb
前提: Rust toolchain (
rustup), Node.js 20+, Docling (PDF→Markdown 変換) が必要です。
Issue / PR / Star 歓迎。特に 自分の研究分野の論文コーパスでの精度報告 をいただけると、多言語・多分野への汎化に大きく貢献します。
参考文献
- Edge et al., 2024. From Local to Global: A Graph RAG Approach to Query-Focused Summarization. arXiv:2404.16130
- Xiang et al., 2026. MemGraphRAG: Memory-based Multi-Agent System for Graph Retrieval-Augmented Generation. KDD 2026. arXiv:2606.00610
- Yang et al., 2018. HotpotQA: A Dataset for Diverse, Explainable Multi-hop Question Answering. hotpotqa.github.io
- Microsoft Research, 2024. LazyGraphRAG: Setting a New Standard for Quality and Cost.