> [!abstract] 概要（abstract 日本語訳） > LLM エージェントは、検索が一度限りの文脈取得ではなく推論のように振る舞うことを必要としている。すなわち、検索し、読み、辿り、証拠として十分かを判断するという動作が必要だ。しかし現在の検索拡張生成（RAG）システムは外部知識を埋め込み類似度で取得するフラットなチャンクとして組織し、反復的な推論エージェントには不適切な「検索＝ルックアップ」インタフェースを公開している。本論文では LLM-Wiki を提案する。LLM-Wiki はエージェントネイティブな検索システムであり、外部知識を静的な検索インデックスではなくコンパイル可能・合成可能・自己進化可能な構造として扱うことで Retrieval-as-Reasoning パラダイムを実現する。LLM-Wiki は文書を双方向リンク付き構造化 Wiki ページにコンパイルし、検索・読み取り・リンク追跡操作を標準ツール呼び出しインタフェースで公開し、永続的な構造的・意味的自己修正のための Error Book を導入する。LLM-Wiki は HotpotQA・MuSiQue・2WikiMultiHopQA で最先端の結果を達成し、HippoRAG 2・LightRAG・GraphRAG を 2.0–8.1 F1 ポイント上回る。AuthTrace では、特にマルチ文書構造化クエリで顕著な向上を示し総合精度で最高を達成し、コンパイルベース検索が連鎖型マルチホップ推論を超えて汎化することを確認した。 ## 論文情報 - **タイトル**: Retrieval as Reasoning: Self-Evolving Agent-Native Retrieval via LLM-Wiki - **著者・所属**: Haoliang Ming・Feifei Li・Xiaoqing Wu・Wenhui Que（WeChat, Tencent Inc., 北京） - **媒体**: arXiv プレプリント (cs.CL) - **発表年**: 2026-05-26（v2） - **arXiv ID**: 2605.25480 - **URL**: https://arxiv.org/abs/2605.25480 ## 概要 現在の RAG システムが文書をフラットなチャンクに分割して埋め込み類似度で検索するという「検索＝ルックアップ」パターンに対し、本論文は知識を構造化 Wiki ページにコンパイルしエージェントが推論と連動して検索を制御する「Retrieval-as-Reasoning」パラダイムを提案する。LLM-Wiki は Compilability（コンパイル可能性）・Composability（合成可能性）・Evolvability（進化可能性）の 3 原則を Wiki 構造化知識・構成的検索・Error Book で実現し、マルチホップ QA の複数ベンチマークで SOTA を達成した。推論深度が増すほど優位性が拡大するという知見は、コンパイルベース検索の設計原則を支持する。 ## 問題設定 - **入力**: 生の文書コーパス（複数パッセージ）と自然言語クエリ（マルチホップ QA タスク） - **出力**: 根拠付き回答 - **課題**: 既存 RAG の 3 つの制約 1. フラットチャンクは検索をマッチングに縮退させ推論に不適 2. 検索が一度限りのブラックボックスでエージェントが中間観察に基づいて検索を改訂できない 3. LLM でコンパイルした知識ベースはダングリングリンク・インデックス不整合・根拠なし事実が蓄積し自己修正機構がない ## 提案手法 ### アーキテクチャ全体像 3 原則 × 3 メカニズム: | 原則 | メカニズム | |------|-----------| | Compilability（コンパイル可能性） | Wiki 構造化知識 | | Composability（合成可能性） | 構成的検索・構成的 Wiki 横断 | | Evolvability（進化可能性） | Error Book | **Figure 1: LLM-Wiki のインデックス時コンパイルと構造化 Wiki 知識ベース** ![[_attachments/arxiv-2605.25480/fig01-index-time-construction.png]] (Figure 1. 左: 生文書を LLM が Wiki ページにコンパイルし、Error Book がエラーを検出して制約注入・自動修正・LLM 定期修正を行うループ。右: 生成された構造化 Wiki 知識ベース。グローバルインデックス・カテゴリインデックス・双方向リンク付き個別ページから構成される。) ### Wiki 構造化知識（Compilability） インデックス時に各ソースパッセージを処理し、現在の Wiki 状態に対して関連既存ページを選択しながら構造化 Wiki ページを生成・更新する（Algorithm 1: 疑似コードで全手順を定義）。 各 Wiki ページの構成: - YAML frontmatter（type・タイムスタンプ・aliases・tags） - 1 行 blockquote サマリー - 構造化キーファクト - 双方向 wikilinks（関連ページへの明示的ポインタ） - ソース参照（来歴の維持） ディレクトリ構造例（2WikiMHQA 評価コーパス: 5,825 知識ページ + 6,840 ソースページ）: ``` wiki/ index.md # グローバルインデックス concepts/ entities/ geography/ history/ media/ organizations/ people/ _index.md # カテゴリ別ブラウズ可能インデックス Page-A.md ... # 個別知識ページ sources/ # パラグラフ単位ダイジェスト + 原文アーカイブ ``` ### 構成的検索（Composability） エージェントは 2 つのツールを標準ツール呼び出しインタフェースで利用: - `wiki_search(query)`: ページ名・aliases・タグ・説明を優先してコンテンツへフォールバック。候補ページとメタデータを返す - `wiki_read(paths)`: ディレクトリインデックス（`_index.md`）または全ページをバッチ読み込み。ページ間リンクを含む エージェントはクエリ特性に基づいて適応的に横断戦略を選択: - **Direct access**: 既知エンティティなら直接読み込み - **Bridge queries（A→B→answer）**: A のページから B へのリンクを追い、多段推論を反復リンク追跡に還元 - **Exploratory browsing**: オープンエンドクエリにはディレクトリインデックスを読んで俯瞰し有望ページを選択 各 `wiki_read` 後に証拠充足性を評価し、不十分なら検索を改訂・追加リンクを追跡・追加ページを読み込む。 **Figure 2: Retrieval-as-Lookup vs. Retrieval-as-Reasoning（Search-First / Browse-First 横断）** ![[_attachments/arxiv-2605.25480/fig02-retrieval-as-reasoning-traversal.png]] (Figure 2. 左: フラットチャンク RAG の一回限りの類似度検索。中間エンティティが欠落する。中・右: LLM-Wiki の 2 種の横断ルート。Search-First は wiki_search→wiki_read→wikilinks 追跡→充足性チェックのループ。Browse-First はインデックス読み込み→ページ選択→wiki_read→充足性チェックのループ。) ### Error Book（Evolvability） 永続的自己修正機構。`error_book.yaml` として永続化。 **5 段階ライフサイクル**: 1. **Discover**: 構造的バリデータ（ダングリングリンク・不正参照の検出）と LLM 検証（根拠なし事実の特定） 2. **Attribute**: コンパイルエラーへの根本原因遡及 3. **Constrain**: 自然言語制約規則への形式化（例:「リンクターゲットを発行前に検証せよ」） 4. **Inject**: 将来のコンパイルプロンプトへの制約付加 5. **Verify & Close**: 定期再バリデーションでエラーをクローズ **2 層修復**: - **コード自動修正**: ダングリングリンク・フォーマット・インデックス不整合の決定的修正 - **LLM 定期修正**: N 記事ごとに起動し欠落ページ・不完全コンテンツ・矛盾修正を実施 **エラータクソノミー**（Table 6 より 7 種）: - ダングリングリンク / 不完全ページ / 不正フォーマット / インデックス不整合 / 根拠なし事実 / ページ矛盾 / 未見上書き ## 新規性 | 先行手法 | インデックス成果物 | 知識形式 | LLM-Wiki との差異 | |---|---|---|---| | Vanilla RAG | フラットチャンク | 埋め込みインデクシングパッセージ | 中間ノードを横断できない | | RAPTOR / MemWalker | サマリーツリー | テキスト圧縮 | 横断的関連付けを欠く | | GraphRAG | コミュニティサマリー | 階層的圧縮 | 詳細損失・高コスト | | HippoRAG 2 | KG トリプル | 機械可読フラグメント | ロッシートリプル・PPR は近似 | | LightRAG | エンティティ/関係ベクタ | ベクタインデックス | 中間エンティティを発見できない | | **LLM-Wiki** | Wiki ページ + リンク | 構造化知識（人間可読・機械横断可能） | コンパイルコスト（初期一回のみ） | (Source: Table 4 より) 本論文は LLM-Wiki を、[[Andrej Karpathy]] が 2026 年に提案した [[LLM Wikiパターン]]（[[@2026__GitHub Gist__LLM Wiki]]）の最初の操作的実装として位置づける。Karpathy の抽象設計パターンを、コンパイル・品質保証・構成的検索の 3 機構で具体化した。 ## 実験設定 **評価データセット（各 500 サンプル）**: - **HotpotQA**: 2-hop ブリッジ推論・比較型 QA - **MuSiQue**: 2〜4-hop 合成型 QA（ショートカット防止設計） - **2WikiMultiHopQA**: 2-hop・4-hop（ブリッジ・比較・合成・推論型） - **AuthTrace**: 中国語近代散文 5 作家による公開ドメイン作品 860 作から構築した 2,099 QA。証拠ファンイン（シングル文書・Low マルチ文書・High マルチ文書）で層別化 **ベースライン**: Vanilla RAG(BM25/Dense)・RAPTOR・GraphRAG・LightRAG・HippoRAG 2 **評価指標**: F1 / EM（公開ベンチマーク）、GPT-4o-mini ジャッジによる正解率 AC（AuthTrace） ## 実験結果 **Table 1 主要結果（F1 / EM）**: | 手法 | HotpotQA | MuSiQue | 2WikiMHQA | |---|---|---|---| | Dense RAG | 0.764 / 0.642 | 0.611 / 0.500 | 0.815 / 0.724 | | LightRAG | 0.819 / 0.682 | 0.659 / 0.550 | 0.847 / 0.764 | | HippoRAG 2 | 0.805 / 0.668 | 0.624 / 0.514 | 0.831 / 0.706 | | **LLM-Wiki** | **0.839 / 0.710** | **0.739 / 0.634** | **0.911 / 0.854** | LightRAG に対して +2.0 (HotpotQA)、+8.1 (MuSiQue)、+6.4 (2WikiMHQA) F1 ポイント。 **Table 2 AuthTrace（正解率 AC %）**: | 手法 | シングル | Low マルチ | High マルチ | 全体 | |---|---|---|---|---| | HippoRAG 2 | 78.3 | 59.6 | 46.5 | 68.3 | | **LLM-Wiki** | **76.0** | **64.6** | **55.4** | **70.4** | マルチ文書クエリで特に顕著な優位性。シングル文書では HippoRAG 2 がわずかに上回る。 **アブレーション結果（HotpotQA F1）**: - Wiki 構造なし: −6.1〜−7.0 ポイント - 段階的横断なし: −11.7〜−13.8 ポイント（最大の寄与要因） - Error Book なし: −3.4〜−4.0 ポイント ## 考察 **推論深度との相関**: **Figure 3: 2WikiMHQA ホップ別 F1** ![[_attachments/arxiv-2605.25480/fig03-hop-wise-f1-2wikimhqa.png]] (Figure 3. 推論深度（2-hop / 4-hop）別の F1 スコア。LLM-Wiki は 4-hop で 0.983 F1 を達成し、ホップ数増加に伴う優位性の拡大が顕著。LightRAG との差は 2-hop で 5.7 ポイントから 4-hop で 8.3 ポイントへ拡大。) 2WikiMHQA で LightRAG との差が 2-hop の 5.7 から 4-hop の 8.3 ポイントへ拡大し、合成型質問では Dense RAG 比 +15.6 ポイント・LightRAG 比 +7.3 ポイント。GPT-4o での実験でも Dense RAG 比 +5.1〜+16.9 ポイントを維持し、利得が知識組織化から来ることを示唆。 **クエリ効率**: LLM-Wiki のクエリ時レイテンシは BM25/Dense RAG と同等。LightRAG・HippoRAG 2・RAPTOR（それぞれ 39.7–51.3s・32.4–38.2s・28.0–40.2s）を大幅に下回る。コンパイルコストを初期一度に前払いすることでクエリ時の組み合わせマッチングを排除している。 **改善の源泉**: 「より強い類似度関数」ではなく「知識ベースとエージェントの間の異なる契約」にある。コンパイルが探索空間を明示化し、構成的ツールが観察を次の検索ステップに結びつけ、Error Book が横断される構造の品質を維持する。 ## 強み / 弱点・課題 **強み**: - 推論深度の増加に比例して優位性が拡大するスケーラビリティ - 人間可読かつ機械横断可能という二重性（デバッグ・監査が容易） - クエリ時レイテンシが RAG 並みで実用的 **弱点・課題**: - **コンパイルコスト**: 各パッセージに SELECT_PAGES + COMPILE_WIKI_PAGES が必要。初期構築はチャンク埋め込みより高コスト（クエリで償却） - **スケーラビリティ**: 数万ページ規模ではディレクトリインデックスが肥大化しページ選択が劣化する可能性 - **動的コーパス非対応**: 大規模・頻繁更新コーパスへの階層インデックス・シャーディング・陳腐化処理は未解決 - **マルチモーダル・クロスコーパス転移**: 将来課題