Karpathy LLM Wikiは本当に効果があるのか - 72-runベンチマーク

「エージェントが毎回すべてを再導出しないようにするには、コンパイルされた知識アーティファクトが必要だ。」 — Andrej Karpathy, LLM Wiki (GitHub Gist, 2026-04)¹

TL;DR

• Andrej KarpathyのLLM Wikiパターン（「毎回読み直すのではなく、一度コンパイルした知識を再利用せよ」¹）が実際に得なのかを、30リポジトリのマイグレーション用ワークスペースで8タスク × 3手法 × 3反復 = 72 runのベンチマークとして測定しました。
• LLM Wikiがトークン・時間・品質の3次元すべてで1位。Vanilla比でトークン54%削減、時間39%短縮（統計的にlarge effect、§4）、品質はVanillaと同等でGraphifyより優位。
• **Graphify（GraphRAG）は既定ツールとして不適合。**トークン削減はわずか、時間は最長、品質は最低。
• **ただし万能ではない。**複数のソースを総合するタスクではWikiの圧勝ですが、答えが単一のソースに明確にあるタスク（全件grep・特定の表の参照）では直接readのほうが速く正確です（§3）。
• 結果を受けて、その日の夕方にプロジェクトの既定コンテキスト検索ツールはLLM Wikiに変わりました。

以下はこの結論を裏付ける実験設計と詳細な数値です。

1. 比較した三つの手法

LLM Wikiパターンの核心はRAGとの違いです。RAGは問い合わせのたびに埋め込み・ベクトル検索・チャンク注入を繰り返すstatelessなサイクルであるため、総合・相互参照・矛盾処理を毎回ゼロからやり直します。LLM Wikiはこれを逆転させ、新しいソースが入ってきたときに一度コンパイル（要約・相互参照・衝突の明記）しておき、問い合わせの時点ではすでに総合されたマークダウンページを読みます。コンパイルは一度、問い合わせは複数回 — この非対称なコスト配分がトークン削減の源泉です。

2. 実験設計

意思決定の問い: 「このマイグレーションのワークロードにおいて、トークン効率と回答品質を同時に満たす手法は何か？」従属変数の優先順位は ① トークンコスト ② 回答品質 ③ 作業時間。

ワークロード — 8タスク（T1–T8）:

隔離: 三つの手法をgit worktree 3つに分離し、各worktreeに専用のCLAUDE.mdを上書きしました。submodule・PRD・コード・gitは共通で、違いは補助ツールだけです。worktreeのパスが分かれているおかげで、trial間のprompt cache汚染はありません。

採点（Judge） — 外部モデル（codex/GPT-5）: actorがClaudeであるため、self-evaluationのバイアスを避けようと外部モデルで採点しました。4次元0–25のrubricです。

タスクのプロンプトにはground truthを露出させず、judgeだけが保持します。Inter-rater agreement（Cohenのκ）は加重平均0.86でrubricを通過しました（excess次元のみκ=0.25と弱いものの、重みは0.1）。

3. タスク別の勝者 — パターンは単純ではない

全体平均はWikiに軍配を上げますが、タスク種別によって勝者が分かれます。平均スコア基準の1位は次のとおりです。

• Wikiは混合型・総合型のタスクでrobustです。8件中5件（T1・T2・T5・T6・T7）で1位。とくに複数のソースを総合しなければならないT2（cross-language）・T6（外部資料）で強い。キュレーションが値打ちを発揮しています。
• Vanillaが勝つタスクが二つあります。T4（全件grep）・T8（cross-domain）です。どちらも答えが単一のソースに明確にあり、キュレーションがかえって損失になるケースです。T4はコード全体のgrepで片が付き、T8はPRDの表を直接読むのが最も正確です。
• **GraphifyはT3の1件だけが1位で、それも9.50/25と絶対スコアが低い。**強みを期待していたcross-language（T2）でもwikiに大きく負けました — INFERRED edgeがノイズを加え、query overheadが時間を押し上げたのです。

4. 統計的有意性

Friedmanの主効果: 時間 p=4.5e-07、品質 p=0.0016（どちらも強力）、トークン p=0.093（限界的）。

Wilcoxonのpairwise（Bonferroni補正）:

まとめると、Wikiはvanilla比でトークン・時間を大きな効果量で削減し（品質は同等）、graphify比では品質・時間ともに優越しています。graphify-firstは私たちのワークロードでは既定ツールとして不適合です。

5. では、どう運用するのか

ベンチマーク結果を受けて整理した既定のポリシーです。

1. Wiki-first — 運用上の事実は wiki/index.md → 関連ノートを先に読む。
2. なければ即座に原典へ — wikiになければ PRD → コードのread/grep。決して作り出さない。
3. 単一ソースでの回収が明確ならwikiを飛ばす — 一つのノートに絞り込めないなら、素早く直接readへ移る（T4・T8型）。
4. Graphifyは補助 — cross-componentの依存関係の追跡にのみ選択的に使う。

運用して得た最大の教訓は別にあります。**wikiを作ることよりも、回答のたびに出典を引用させるほうが難しく、より重要です。**初期は記録は活発だったのに、回答の [[..]] 引用が10%未満だったため、wikiの価値が半分しか発揮されていませんでした。回答の直前に「この事実にwikiの引用があるか？」を強制するチェックルール一つで、引用率はすぐに正常化しました。

6. 留意点

• excess次元のIRRが弱い（κ=0.25）。すべての手法のtranscriptを一緒に見ながらの採点だったため、excessのスコアが一律に厳しくなりました。重みが0.1なので結論への影響は小さいものの、絶対値は保守的に見るべきです。
• Wiki biasへの懸念: 8タスクすべてでwikiにground truthがあるため、有利になっている可能性があります。ただしjudgeはsourceではなくground truthの事実そのものを評価します。
• Claude Codeベースの測定です。他のモデル・ツール環境では結果が異なり得ます。この数値は私たちの環境におけるポリシーの根拠であって、universal claimではありません。

まとめ

Karpathyの LLM Wiki パターンは、私たちのドメインでトークン54%削減、時間39%短縮、品質は同等以上の効果を出し、統計的にもlarge effectで有意でした。既定ツールをwikiに変えた決定はデータに裏付けられています。

ただしパターンを直訳してはいけません。答えが単一のソースに明確にあるタスクではキュレーションのコストが損失になりますし、Graphifyは既定ツールとしては不適合であるものの、特定の経路の問い合わせではwikiより優れています。**パターンは受け入れつつ、自分のワークロードのタスク分布とソース構造を併せて見るべきです。**8タスク × 3手法 × 3トライアル = 72 runであれば1〜2日で答えが出るので、ぜひ一度ご自分で測定してみることをお勧めします。