4月4日、元Tesla AI責任者でOpenAI創設メンバーのAndrej Karpathy氏が「LLM Wiki」と題したGistを公開した。
RAGの根本的問題を解決する革新的アプローチ
Karpathy氏が提案したのは、従来のRAG（Retrieval-Augmented Generation）の限界を突破する全く新しい知識管理手法だ。この提案はHacker Newsで1000以上のupvoteを獲得し、「これはゲームチェンジャーだ」「まさに欲しかった機能」といった熱い反響を呼んでいる。
一般的なRAGでは、文書をベクトル化してクエリ時に関連断片を検索し、LLMが毎回ゼロから回答を生成する。しかし「LLMが毎回同じ知識を再発見している」という根本的な非効率性がある。5つの論文を総合判断する複雑な質問でも、LLMは毎回同じ推論を繰り返すことになる。
「wikiをLLMが自動管理」という発想の転換
LLM Wikiの革新性は、知識を「一度コンパイルして永続化」する点にある。新しい情報を追加すると、LLMは単なるインデックス化ではなく：
- 既存のwikiページを更新
- エンティティ間の関連性を記録
- 新旧情報の矛盾を検出・記録
- トピック要約を自動修正
一つの情報源が10-15のwikiページに影響を与えることもある。Karpathy氏は「ObsidianをIDE、LLMをプログラマー、wikiをコードベースと考えよ」と表現している。
3層アーキテクチャの設計思想
システムは明確な役割分担を持つ：
1. Raw sources（生の情報源）
記事、論文、画像等の厳選されたコレクション。不変でLLMは読み取り専用。
2. The wiki（wiki層）
LLMが生成・管理するMarkdownファイル群。要約、エンティティページ、概念ページ、比較表などを含む。LLMが完全所有し、人間は読み取り専用。
3. The schema（スキーマ）
wikiの構造・規則・ワークフローを定義。LLMを「汎用チャットボット」から「規律あるwiki管理者」に変える設定ファイル。
なぜ従来手法は失敗するのか
Karpathy氏は核心を突く：「知識ベース維持の最も面倒な部分は読書や思考ではなく、事務作業だ」。
相互参照の更新、要約の最新化、矛盾管理、一貫性維持—これらの維持コストが価値を上回るため、人間はwikiを放棄する。しかしLLMは退屈せず、一度に15ファイルを更新できる。維持コストがほぼゼロになることで、wikiは継続的に成長する。
この考えは1945年のVannevar Bushの「Memex」構想の現代版とも言える。Bushが解決できなかった「誰が維持するのか」という根本問題を、LLMが解決する。
実用的な応用シナリオ
提案されている応用例は多岐にわたる：
- 研究者向け：数週間の調査で得た論文群から自動的に関連マップを構築
- 読書管理：小説を読みながらTolkien Gatewayのような数千ページのwikiをリアルタイム生成
- ビジネス：Slack履歴、会議録、プロジェクト文書から内部知識ベースを自動生成
- 個人管理：健康データ、目標、学習履歴の統合管理
技術実装のポイント
実装には以下のツール群が推奨されている：
- **Obsidian Web Clipper**：WebページのMarkdown変換
- **qmd**：ローカルMarkdownのハイブリッド検索
- Git管理：バージョン履歴、ブランチング、共同作業
Redditの機械学習コミュニティでは「既存のObsidianプラグインとの組み合わせが楽しみ」「APIコストが気になるが、長期的には絶対ペイする」といった実装議論が活発化している。
重要なのは、この手法が実装を規定しない抽象的パターンとして設計されていることだ。各自のドメイン、好み、使用するLLMに応じてカスタマイズできる柔軟性を持つ。
RAGの次の進化形として、この「永続的知識コンパイル」の概念は2024年の重要なトレンドになりそうだ。
詳細はLLM Wikiを参照していただきたい。
