Andrej KarpathyがLLM Wikiパターンを公開: フォルダ構造に1600万ビュー

AIアシスタントに何ヶ月も研究してきたことを尋ねるたびに、ゼロから始まってしまう。 先週要約するよう頼んだ論文を覚えていない。 今尋ねている質問が3ヶ月前の3つの質問とつながっていることに気づかない。 外部ドキュメントへのアクセスを提供するAIモデルの主要なアーキテクチャであるRAGパイプライン（retrieval-augmented generationの略）は、各クエリを独立したものとして扱う。 何も蓄積されず、何も複合化されない。

2026年4月3日、OpenAIの共同創業者で元TeslaのAI責任者、現在は独立した研究者であるAndrej Karpathyは、X上でこの問題を回避する方法を説明する投稿を公開した。his GitHub Gist 完全なアーキテクチャを詳述している。 ベクトルデータベースなしでAIモデルが構造化された知識ベースをコンパイル、維持、クエリする3フォルダのMarkdownセットアップというパターンは、その単一の投稿で1600万ビューを獲得した。 Andrej KarpathyのLLM関連の活動を追っている人にとって、この投稿は単なる技術的な好奇心以上のものだった。 Gistは数日で5000のスターと485のコメントを集めた。

この数字は一考に値する。フォルダ構造の説明だけで1600万ビューだ。 それはバイラルな製品のローンチではない。 長年回避してきた問題を認識し、AI研究コミュニティでKarpathyの地位を持つ人物がそれを正確に指摘したことを、開発者たちが理解した結果だ。

What Happened: A GitHub Gist With 16 Million Views

Karpathyが説明したコンセプトは、構造としては単純だが、その意味するところは単純ではない。 3つのフォルダ：raw/、wiki/、およびすべてをマッピングし、単一のコンテキストウィンドウに収まるように設計されたindex.mdファイル。

raw/には研究論文、記事、GitHub README、ドキュメント、YouTubeトランスクリプトなどのソースマテリアルが含まれる。 何も整理されておらず、何も処理されていない。 潜在的に関連するすべてのもののダンプだ。wiki/はモデルが関与する場所だ。定期的に、モデルがrawマテリアルを読み込み、構造化された百科事典スタイルのMarkdown記事にコンパイルする。 各記事はrawソースが概念について何を述べているかを統合し、それらの間の矛盾を解決し、関連記事へのリンクを構築する。index.mdは目次であり、wiki内のすべての記事の構造化されたマップで、単一のコンテキストロードに収まる程度に簡潔だ。

システムにクエリすると、モデルはまずindex.mdを読み、関連する記事を特定し、それらをロードし、rawソースの断片ではなくコンパイルされた知識から回答する。 エンベディングステップも、ベクトルデータベースも、検索パイプラインもない。The pattern doesn't retrieve information. It has already synthesized it.

Karpathyの配信形式の選択自体が声明だった。 彼はpublished a Gist, not a repositoryし、インストール可能なコード、パッケージマネージャの統合、セットアップ手順のREADMEはなかった。 その後の報道で広く引用された彼の理由：「LLMエージェントの時代において、アイデアを共有することはコードを共有するよりも価値がある。なぜなら他者のエージェントがあなたの特定のニーズに合わせてカスタマイズし構築するからだ。」 数日以内に、コミュニティはこの枠組みを検証し、複数の独立した実装を生み出した：obsidian-wikiプラグイン、完全なLLM-wiki GitHubリポジトリ、および元のバターンをエージェントメモリアーキテクチャで拡張したv2 Gistなど。

VentureBeat's coverageはリリースの実用的魅力を正確に捉えた。Andrej Karpathy LLM knowledge baseアーキテクチャは「AIによって維持される進化するMarkdownライブラリでRAGをバイパスする」というものだ。 この枠組みが重要だ。これは新しい製品や訓練されたモデルではなく、知識がモデルに到達する前にどのように組織されるべきかに関するアーキテクチャパターンだ。 RAGパイプラインを構築・維持してきた開発者にとって、ベクトルデータベースとエンベディングインフラをMarkdownファイルのフォルダに置き換える prospectは即座に魅力的であり、それがまさにGistが受けた反応だ。

Why the Pattern Matters

RAGとこのアプローチの根本的な違いは、知識の組み立てがいつ行われるかにある。 RAGはクエリ時にコンテキストを組み立てる。質問をすると、システムがベクトルストアから関連チャンクを取得し、モデルがそれらのチャンクから応答を生成する。 応答の品質は検索品質に完全に依存し、正しいチャンクが特定されたかどうか、それらが十分なコンテキストを含んでいるかどうか、それらが互いに矛盾していないかどうかも含まれる。

Karpathyのアプローチはコンパイル時にコンテキストを組み立てる。 質問をする前に、モデルはすでにすべてのrawソースを読み、それらの関係を理解し、その理解を統合した構造化記事を書いている。 質問をするとき、断片を取得しているのではない。 検索のためではなく理解のために構築された知識構造をクエリしているのだ。

この違いから3つの実用的意味が導かれる：

Token efficiency. 小規模な知識ベースの場合、インデックスと2〜3つのwiki記事をコンテキストにロードすると、同等のrawソースマテリアルをロードするよりも約95%少ないトークンを使用する。 より重要な効果はコンテキストの品質だ。よく構造化された3000語の記事は、異なるドキュメントから取得された10個の300語チャンクよりもモデルにとってはるかに使いやすい。

Transparency. 記事内のすべての事実は、人間が読んだり、編集したり、削除したりできるMarkdownファイルにトレース可能だ。 ベクトルエンベディングはそうではない。 システムが間違った回答をした場合、ソース記事を見つけて修正できる。 RAGパイプラインが間違った回答をした場合、エラーは直接アクセスできない方法でエンベディング空間にある可能性がある。

Knowledge accumulation. これはKarpathyが最も強調する特性だ。 数ヶ月かけてwikiを維持するモデルは、重みの変化としてではなく、概念間の関係をエンコードする構造化されたアーティファクトとして、ドメインに関する一種の制度的記憶を発達させる。 新しい論文と過去の研究のつながりについて尋ねる研究者は、6ヶ月間関連論文をコンパイルしてきたシステムと、各論文をクエリ時に独立して扱うシステムとでは、質的に異なる回答を得る。

実用的ユースケースはこれらの特性を反映している。 数十の論文にわたる文献空間を追跡する研究者は、孤立した要約ではなく相互参照された統合を得る。 アーキテクチャ決定記録を維持する開発者は、月単位のコンテキストにわたって設計選択がなぜなされたかをトレースできるシステムを得る。 競合インテリジェンスを追跡するプロダクトマネージャーは、蓄積するリポジトリを得て忘却しない。

Why Most Implementations Quietly Fail

1600万ビューはアイデアに向けられた。The 485 gist comments went to what breaks when you try to build it.

コミュニティフィードバックで最も一貫したパターンは次のようなバリエーションだ。フォルダ構造は正しく構築され、最初のコンパイルは印象的な結果を生むが、その後の数週間で知識ベースは徐々に信頼できなくなり、重複し、または放棄される。 これはコンセプトの理解の失敗ではない。 コンセプトが自らのメンテナンス要件を指定できなかった失敗だ。

Knowledge has a lifecycle that the pattern doesn't address. Markdownファイルはデフォルトで永続的に有効であると想定されている。 しかし実際には、先週見つけたバグは6ヶ月前のものよりも関連性が高い。 12回見たアーキテクチャパターンは、1回見たものよりも信頼性が高い。 元のパターンは時間的関連性や減衰を表現するメカニズムを提供しない。 1ヶ月目と6ヶ月目に書かれた記事が、どちらが現在の理解を反映しているかを示すことなくwiki/に共存する。

Contradictions accumulate without automatic detection. リポジトリが成長するにつれ、新しいコンパイルパスが以前のものと矛盾する記事を導入する。 Karpathyのアーキテクチャは「lint pass」、つまりwiki全体を定期的にスキャンして不整合を特定し解決するものを説明している。 これは機能する。 しかし、意図的かつ定期的に実行する必要がある。 ほとんどの実装はこの実践を維持しない。

The scale ceiling is hard and arrives unexpectedly. このアプローチは、コンパイルされたコンテンツの約5万〜10万トークン以下では確実に機能する。 その閾値を超えると、index.md自体が単一のコンテキストウィンドウに収まらなくなり、クエリモデル全体が破綻する。 焦点を絞ったドメインにわたる個人的な研究プロジェクトでは、この上限に達しないかもしれない。 チームや部門規模に近づくものでは、すぐに遭遇する。

The enterprise limitations are structural rather than solvable through iteration. A local folder of Markdown files managed via one person's file system has no access control model, no multi-user conflict resolution, and no audit trail. For teams, this is not a limitation to work around. It's a reason to use a different architecture.

LLM Wiki v2, published on GitHub Gist by developers extending Karpathy's original, explicitly addresses some of these gaps by adding persistence patterns from agent memory research, documenting failure modes at scale, and proposing mechanisms for knowledge lifecycle management. The existence of v2 within weeks of the original confirms that the pattern as described is incomplete for production use.

LLM Wiki vs RAG: When to Use Which

Karpathyの投稿後に circulated した「RAG is dead」という枠組みは、「email is dead」という枠組みと同様に不正確だ。 2つのアプローチは同じワークロードの競合相手ではない。 異なる規模と要件に適している。

Karpathyのアプローチは、知識ベースが10万トークン未満にコンパイルできるほど小さく、主なユーザーがそれを構築した本人または共有コンテキストを持つ小チームであり、知識の蓄積がraw検索速度よりも重要である場合に正しい選択だ。 RAGは、知識ベースに数十万から数百万のドキュメントが含まれ、異なる権限レベルを持つ複数のユーザーがアクセスする必要がある場合、またはコンテンツが頻繁に変更され curated コンパイルの維持が非現実的である場合に正しい選択だ。

ほとんどの個人知識労働者や小チームにとって、このパターンは単に実行可能であるだけでなく、そうでなければ構築・維持する必要があるRAGインフラよりも優れている。 ベクトルデータベースのセットアップ、エンベディングの管理、検索パラメータの調整、検索ノイズのデバッグの複雑さは現実的だ。 数百のドキュメントを持つ個人的な研究システムでは、that complexity is genuinely unnecessary。

Karpathyのワークフローが表す実用的ミドルグラウンドは、Web Clipperがソースの取り込みを処理し、ファイルシステムがフォルダ構造を処理するObsidianのようなツールにうまくマッピングされる。 元のGistから数日以内に登場したコミュニティ実装は圧倒的にObsidianベースであり、これは偶然ではない。

What This Means for How We Build Knowledge Systems

Karpathyがこれをコードリリースではなく「idea file」として位置づけたことは、AI開発の規範がどのように変化しているかについて何か本質的なことを反映している。 2026年において、知識管理システムの興味深い部分はインフラではない。 コンテキストエンジニアリングだ。情報がどのように構造化され、統合され、クエリ時にモデルに利用可能にされるか。

これが表すより広いトレンドは、開発者や知識労働者がAIツールについて考える方法の再方向付けだ。 以前の質問は「どうすればモデルをより賢くできるか」だった。 2026年の質問はますます「モデルがアクセスできる情報をどう構造化するか」になっている。 Karpathyのパターンは2番目の質問への一つの答えだ。

Ward Cunninghamは1995年にWikiWikiWebをパターンとして公開した。製品ではなく商用ツールではなく、協調的知識を組織する方法の記述だった。 そのアイデアが一般化して今私たちがwikiと呼ぶものになるまでには何年もかかった。 KarpathyのGistは似た立場にある。作成者にとって機能するパターンであり、コミュニティの実装を通じて広がり、そのギャップに対処するバリエーションを生み出す。Analytics Vidhyaは適切に述べた。意義は技術的実装よりも、AIと永続的知識についての実践者が考えるパラダイムシフトにある。

1600万ビューが表す質問は、本当にフォルダ構造についてではない。 何ヶ月も何年もかけて蓄積した知識が実際に複合化するのか、それとも新しいセッションごとにゼロから始まるのかということだ。 それはアーキテクチャについての質問だが、自分自身を取り巻くどのような知識インフラを構築したいかについての質問でもある。

コミュニティからの最も正直な答えは、Karpathyのパターンはそれを構築した本人にとって、彼が関心を持つドメインで、定期的にlint passを実行する規律があればうまく機能するということだ。 他の人にとっては、機能するまで機能し、それからツールへの多大な投資か、メンテナンス層を自動的に処理するより独断的なシステムが必要になる。discussion thread on the original Gist自体が有用なアーティファクトだ。485のコメントが、パターンがどこで破綻するのか、人々が試した修正は何か、どの拡張が実際に残ったかを記録している。 それを読む時間は、失敗するwikiを構築するよりも短い。

Karpathyのパターンが対処する問題、蓄積されるべき知識が蓄積されないという問題が馴染みがあるなら、それは個人的およびチームの知識管理における中心的な問題だからだ。 各セッションをステートレスとして扱うツールは、貴重なコンテキストをテーブルに残す。remio's AI-native second brainは同じ原則を中心に構築されている。知識システムの価値は、オンデマンドで取得するものではなく、時間とともに構築するものから来る。 自分自身のパターンを構築する場合でも、それを代わりに複合化してくれるツールを探す場合でも、問う価値のある質問は同じだ。6ヶ月後にこの情報に戻ってきたとき、AIは何かを覚えているだろうか？