# Retrieval-as-Reasoning Navigation: [[LLM Wikiパターン]] | [[LLM向け情報検索]] ## 定義 Retrieval-as-Reasoning とは、[[Haoliang Ming]] ら（WeChat/Tencent、2026）が提唱するエージェントネイティブ検索のパラダイムである。従来 RAG（検索拡張生成）における「検索＝ルックアップ」（Retrieval-as-Lookup）——クエリを埋め込みで符号化し上位 k チャンクを固定文脈として渡す一回限りの操作——を刷新し、検索そのものをエージェントが制御する段階的推論活動として再定義する。(Source: [[@2026__arXiv__Retrieval as Reasoning]]) 具体的には: - エージェントが探索すべき知識単位を計画し - 証拠を読み取り、コンパイル済みリンクを追跡し - 中間観察に基づいて検索計画を改訂し - 収集した証拠が十分かを判断して初めて回答する この実現に必要な 3 原則: 1. **Compilability（コンパイル可能性）**: 生文書を構造化・相互結合された永続的知識単位にコンパイルする 2. **Composability（合成可能性）**: 検索を Search・Read・リンク追跡・充足性チェックなどのアトミック操作に分解し、エージェントが推論ループで合成する 3. **Evolvability（進化可能性）**: 知識構造が時間とともに静かに劣化するのではなく自己修正する LLM-Wiki はこの 3 原則を Wiki 構造化知識・構成的検索・Error Book という 3 機構で実現した最初のシステムである。(Source: [[@2026__arXiv__Retrieval as Reasoning]]) ## Retrieval-as-Lookup との対比 | 側面 | Retrieval-as-Lookup（従来 RAG） | Retrieval-as-Reasoning（LLM-Wiki） | |---|---|---| | 知識組織 | フラットチャンク・埋め込みインデックス | 構造化 Wiki ページ・双方向リンク | | 検索のタイミング | 推論前の一回限り | 推論と連動した反復 | | エージェントの制御 | なし（固定 top-k 文脈） | あり（次に探索するノードを計画） | | 中間エンティティ | セマンティックに遠い場合欠落 | リンク追跡で到達可能 | | 知識の自己修正 | なし | Error Book による継続的修正 | | コスト配分 | クエリ時（ランタイムマッチング） | インデックス時（コンパイル一回払い）+ クエリ時は軽量 | ## Error Book パターン LLM-Wiki が導入した自己修正機構。LLM でコンパイルされた知識ベースに蓄積する構造的・意味的エラー（ダングリングリンク・根拠なし事実・ページ矛盾等）を永続的に検出・修正する。 5 段階ライフサイクル: Discover → Attribute → Constrain → Inject → Verify & Close。 2 層修復: コード自動修正（構造エラー）+ LLM 定期修正（意味エラー）。 この Error Book は Reflexion や Self-RAG がクエリ時の単一エピソード内で自己修正するのと対照的に、**インデックス構築バッチをまたいで永続する**点が新規性の核心。 ## 横断的知見 - **推論深度が増すほど Retrieval-as-Reasoning の優位性が拡大する**: LLM-Wiki は 2WikiMultiHopQA で 2-hop の LightRAG 比 +5.7 F1 が 4-hop では +8.3 F1 に拡大し、4-hop で 0.983 F1 を達成した。Retrieval-as-Lookup はセマンティック的に遠い中間エンティティを欠落させるため、ホップ数増加に比例して不利になる。(Source: [[@2026__arXiv__Retrieval as Reasoning]]) - **クエリ時レイテンシは Retrieval-as-Reasoning が有利**: コンパイルコストを初期一回に前払いすることで、クエリ時の組み合わせマッチングを排除し、LightRAG・HippoRAG 2・RAPTOR より大幅に低レイテンシを達成した。知識組織化の設計決定がランタイム性能にも直接影響する。(Source: [[@2026__arXiv__Retrieval as Reasoning]]) - **改善の源泉は「より強い類似度関数」ではなく「エージェントと知識ベースの間の契約変更」**: GPT-4o に切り替えても Dense RAG 比 +5.1〜+16.9 F1 ポイントの優位性が維持され、利得が特定のアンサーモデルでなく知識組織化から来ることが示された。これは [[LLM向け情報検索]] の「検索アルゴリズムより知識組織化が律速」という仮説を実験的に裏付ける。(Source: [[@2026__arXiv__Retrieval as Reasoning]]) ## 未解決の問い - 大規模・頻繁更新コーパス（Web 規模・動的知識）への拡張はどのように設計するか。数万ページ超でディレクトリインデックスが肥大化した場合の階層化・シャーディング戦略は? - Error Book の収束性は保証できるか。制約が蓄積するほどコンパイルプロンプトが肥大化するが、制約の「忘却」や「優先順位付け」の機構が必要ではないか? - Retrieval-as-Reasoning はドキュメント以外のデータ型（コード・表・マルチモーダル）にどこまで汎化するか? - クラウド運用・AIOps のようなリアルタイムデータ（ログ・トレース・メトリクス）を Wiki にどう組み込むか。静的文書とリアルタイムデータの混合コーパスでの Retrieval-as-Reasoning の設計は? ## 関連 - 実装: [[@2026__arXiv__Retrieval as Reasoning]]（LLM-Wiki） - 抽象パターン: [[LLM Wikiパターン]]（Karpathy 2026 の設計思想を操作化した位置づけ） - 比較概念: [[LLM向け情報検索]] / [[RAGベースクラウド運用支援]] / [[RAGノイズ除去]] - 著者: [[Haoliang Ming]]（WeChat/Tencent） ## 出典 - [[@2026__arXiv__Retrieval as Reasoning]]