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

Thu, 07 May 2026 11:00:00 +0900

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

チョン・ドヒョン - ROBOCO首席コンサルタント

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に変わりました。

手法	トークン（平均）	時間（平均）	品質（25点）
Vanilla（直接read/grep）	755K	167s	15.1
LLM Wiki	350K	101s	16.0
Graphify (GraphRAG)	617K	180s	13.6

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

1. 比較した三つの手法

手法	動作方式	追加で露出した資料
Vanilla	補助ツールなしでファイルを直接read/grep	（なし）
LLM Wiki	LLMがあらかじめコンパイルしておいたマークダウンのwikiを先に読む	`wiki/` 全体 + 引用ルール
Graphify	エンティティ・関係グラフ（GraphRAG）を先に問い合わせる	`graphify-out/` + CLI

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

Graphrag on ROBOCO

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

チョン・ドヒョン - ROBOCO首席コンサルタント

TL;DR

1. 比較した三つの手法