ようやく Karpathy の LLM Wiki gist を読みました（はい、流行に乗るのが遅れました XD）。
で、正直なところ全体のアイデアはかなりシンプルなものに集約されます：「アップデート可能な RAG」です。
1. 問題点
LLM がドキュメントを処理するとき、何も蓄積されません。クエリのたびに、モデルはチャンクを取得し、ゼロから合成し、忘れてしまいます。知識がコンパイルされることはありません。そして私見では、さらに重要なのは、対話自体から有益な情報がほとんど抽出されないことです。
RAG は部分的に役立ちます（広い意味では、.md ファイルのフォルダも RAG です）が、標準的なパイプライン（誰もが使っているもの）には、更新、蒸留、自己クリーンアップの機能が組み込まれていません。知識は一度インデックスに登録されたら、その後はただそこに眠っているだけです。そのギャップこそ、LLM Wiki が埋めるものです。
Karpathy の逆転の発想：生のソースとあなたの間に、エージェントが段階的に書き、維持する Markdown Wiki を置く。一度コンパイルして、常に最新の状態を保つ。
2. アーキテクチャ：3 層構造
- raw/ - ソース。不変。エージェントはここには書き込まない。
- wiki/ - システムの核心。LLM が自ら書き、相互リンクを張る Markdown ページ（エンティティ、概念）。本質的にはグラフ構造の知識ベース。
- CLAUDE.md - LLM Wiki を実行するためのマニュアル。ページ形式、リンク規則、取り込みフロー、Lint ルールを保持。Claude をチャットボットから規律ある Wiki 管理者に変えるもの。
追加のチューニングなしで数百ページを処理可能：
3. 操作
3 つの操作 - すぐに API 関数として描きたくなります：
- Ingest -> add(source: file | list[file])。ソースをドロップ -> エージェントが読み取る -> あなたと議論 -> 要約を書く -> インデックスを更新 -> 関連するエンティティページを編集 -> ログに追記。1 つのソースで 10～15 ページに影響。
- Query -> search(prompt: str)。最も重要な操作。質問に回答 +（ここが肝心）合成結果を自動的に新しいページとして Wiki にファイルする。探索がチャット履歴で消えずに積み重なる。内部的には基本的に add(source=dialogue) と同じ。
- Lint -> lint()。引数なし。定期的に Wiki を巡回：矛盾、孤立ページ、古い事実、欠落した相互参照をチェック。トリガーはユーザー N メッセージごと、または変更行数カウンター。/schedule に簡単にアタッチ可能。
これは Claude Dreaming を強く思い起こさせます - Dreaming はこのパターンに部分的に触発されていると思います（ただし機能セットは少し異なります）。
4. インデックス
2 つの特別なファイルが Wiki をナビゲート可能にします：
- index.md - 現在の状態。すべてのページのカタログと 1 行説明。エージェントはクエリのたびに最初にこれを読む - 「この Wiki には何があるのか」という最小限のコンテキスト。
- log.md - すべてのイベントのログ、自由形式。追記専用のタイムライン。行が一貫した形式（例：\
## [YYYY-MM-DD] ingest | title\）に従っていれば、ログはプレーンな Unix ツールで簡単に grep できる - 監査に便利。
index.md はさらに拡張可能（ベクトルインデックス、BM25、GraphDB など） - これについては別の投稿で取り上げます。
5. まとめ
私の考えをまとめると：これは RAG か LLM Wiki かの二者択一ではありません - 両者は同じ「蓄積される記憶」という軸上の 2 点です。
RAG はベクトル DB である必要はありません - Markdown ファイルのフォルダも RAG です。
つまり、LLM Wiki は RAG に以下の 3 つを追加したものと言い換えられます：
- 要約レイヤー。
- その要約レベルでの（ほぼ）自由形式の構造作成。
- 定期的な構造監査 + 自己改善（CRON）。
