KarpathyのLLM Wikiパターンは1600万ビューを獲得しました。実際に動作する様子はこんな感じです。

新しいAIセッションを開始するたびに、ゼロから始まります。先週行ったリサーチ、先月到達した結論、6ヶ月前に2つの論文の間で気づいたつながり：そのどれも引き継がれません。あなたが話しているAIは、それらの記憶を一切持っていません。RAGは、AIモデルに外部ドキュメントへのアクセスを提供する主要なアーキテクチャですが、オンデマンドで断片を取得し、各クエリを独立したものとして扱います。何も蓄積されません。何も複合されません。

2026年4月3日、OpenAIの共同創設者であり、Teslaの元AI責任者であるAndrej Karpathyは、a GitHub Gistで異なるアプローチを公開しました。LLMがベクトルデータベースなしで構造化された知識ベースをコンパイル、維持、クエリする3フォルダのMarkdownセットアップです。この投稿は1600万ビューを獲得しました。その数字は、研究者、開発者、プロダクトマネージャー、アナリストたちが何年も回避してきた問題を、ついに正確に名付けられたことを示しています。

Karpathyが説明したアーキテクチャは正しいものです。問題は、それを実際に実行するために何が必要かです。LLM APIを直接扱っていない大多数の人にとって、「これは良いアイデアだ」と「これは自分のマシンで動いている」の間のギャップは、数日かかるエンジニアリングプロジェクトであり、継続的なメンテナンスのコミットメントになります。この記事では、そのパターンに必要なもの、動作する実装がどのようなものか、そしてインフラがあなたのために処理されると何が変わるかを説明します。

KarpathyのLLM Wikiパターンが実際に何であるか

Karpathyが公開したllm wikiアーキテクチャは、知識はクエリ時にではなく、クエリ前に組み立てられるべきだという構造的な洞察を中心にしています。

従来のRAGは次のように動作します。質問をすると、システムはベクトルストアから関連するチャンクを検索し、モデルはそこに浮上したものから回答を構築します。品質は完全に検索に依存します：正しいチャンクが表示されるかどうか、十分なコンテキストを含むかどうか、互いに矛盾するかどうか。各クエリは新しく始まります。システムはあなたのドメインを理解しておらず、あなたのドキュメントへのアクセスのみを持っています。

Karpathyのパターンはこれを逆転させます。3つのフォルダが作業を行います。raw/にはソース資料が含まれます：研究論文、記事、ノート、YouTubeトランスクリプト、GitHub READMEなど。wiki/は、LLMが定期的にそのraw資料をすべて読み込み、構造化された百科事典スタイルの記事にコンパイルする場所で、各記事は概念についてソースが何を言っているかを合成し、それらの間の矛盾を解決し、関連するエントリにリンクします。index.mdは、単一のコンテキストウィンドウに収まるほどコンパクトな目次です。

システムにクエリすると、モデルはまずインデックスを読み、関連する記事を特定し、それらをロードし、rawの断片ではなくコンパイルされた知識から回答します。The LLM wikiは情報を検索しません。すでにそれを合成済みです。

実用的な意味は具体的です。トークン使用量は、同等のrawソース資料をロードする場合と比べて約95%減少します。すべての事実は、読みやすく編集可能なMarkdownファイルにトレース可能です。そしてwikiは時間の経過とともに構築されるため、6ヶ月目に尋ねられた質問は、1ヶ月目に同じ質問をした場合よりも豊かでつながりのある知識構造を利用します。

Gistが説明していないのはセットアップです。アーキテクチャは、LLM APIに精通していること、コンパイルやlint操作をトリガーするスクリプトを書いたり実行したりすることに慣れていること、そしてそれらのプロセスを数週間、数ヶ月にわたって定期的に実行し続ける規律を前提としています。この仮定は、複合的な知識を最も必要とする研究者、アナリスト、プロダクトマネージャーにとって大きな障壁となります。動作する実装はフォルダ構造ではありません。それはメンテナンスシステムであり、そのシステムを構築することはKarpathyが読者に残した部分です。

The Gist's 485 commentsは、主に人々が自分でこれを構築しようとしたときに何が壊れるかの記録です：raw/フォルダは最初の2週間後に成長を止め、コンパイルステップは自動化されず、lintパスはwikiが信頼できないほど不整合になるまでスキップされます。

How AK Wiki Implements the Three Layers

remioは、Webブラウジング、ファイル、ミーティングからコンテンツを自動的にキャプチャするローカルファーストのAIナレッジベースです。AK Wikiは、Karpathyのアーキテクチャに直接基づいて構築されたremio内のaAppです。3つのレイヤーのそれぞれが具体的な実装にマッピングされ、パターンが説明するものと、ほとんDOYの試みが持続できるものの間のギャップは、それぞれで埋められます。

Layer 1: The raw/ problem, solved by automated capture

DIYセットアップでraw/を埋めるには、意図的なキュレーションが必要です：何を含めるかを決め、コンテンツを一貫したフォーマットに変換し、フォルダを最新の状態に保つ組織的な規律を維持します。時間が経つにつれ、これはそれ自体が仕事になります。失敗する実装のほとんどはここで失敗します。raw/フォルダは初期の熱意が薄れた後に成長を止め、新しい資料を受け取らなくなったナレッジベースは、その時点から劣化し始めます。

AK Wikiのソースレイヤーは、remioの既存のキャプチャインフラです。クリップしたすべてのWebページ、インデックスしたすべてのローカルファイル、記録したすべてのミーティングが自動的に流れ込みます。取り込みの決定も、フォーマット変換も、維持するフォルダもありません。資料は、別個の活動としてではなく、作業中に蓄積されます。開発者でもないナレッジワーカーにとって、これはこのシステムを持つことと持たないことの違いです。DIY実装を殺す取り込みの規律は、単に制約として存在しません。

Layer 2: Compiled knowledge, organized by topic and concept

コンパイル操作は2種類の出力を生成します。Topic Collectionsは、あなたが定義したテーマを中心に組織された構造化された知識エントリです：「AI Agents」「competitive research」「Q2 product decisions」など。スコープを設定すると、AIはそれらのテーマに触れるキャプチャしたすべてからエントリを構築します。

Concept Collectionsは異なります。これらは、コンパイル中にAIが発見したつながりや概念で、あなたが明示的に定義していなかったものです。異なる週や異なるコンテキストでキャプチャしたソースが同じ根本的なアイデアを指している場合、AK Wikiはその関係を独自のエントリとして表面化します。システムはあなたの知識を整理するだけでなく、そこにあなたが置いていなかった構造を見つけ出します。

両方の出力タイプは、ベクトル埋め込みや検索スコアではなく、読みやすく構造化された記事です。それらを読んだり、編集したり、すべての主張を由来のソース資料にトレースしたりできます。これは、Karpathyのアプローチをカバーした際にVentureBeat notedした透明性の利点です：人間の所有者にとって読みやすい「AIが維持する進化するMarkdownライブラリ」で、検査にツールを必要とするベクトルインデックスとは異なります。

コンパイル中、AK Wikiは知識のギャップも補完します。キャプチャした資料にソースに登場する概念のカバレッジが不足している場合、システムはWebを検索してそれを埋めます。Karpathyの元のアーキテクチャにはこれに相当するものはありません。raw/に明示的に入れたものだけで動作します。

Layer 3: A queryable topic map that maintains itself

コンパイルされた出力は、ナビゲート可能なトピックビューに整理されます：index.mdの機能的な等価物で、各コンパイル実行で更新されます。手動で維持されるインデックスとは異なり、キュレーションをやめても古くなりません。構造は、キャプチャした資料からシステムが合成したものを反映し、先週の火曜日に文書化することを覚えていたものを反映するものではありません。

What Compile and Lint Actually Do

2つの操作が、AK Wikiが時間の経過とともに知識の品質を維持する方法を定義します。どちらも、KarpathyのパターンのDIY実装でよく文書化されている失敗モードに対処します。

Compile is not indexing.コンパイル実行が実行されると、AIはキャプチャしたコンテンツを読み、現在の理解に基づいて知識エントリを書き換えます。新しいソースは別個のエントリとして追加されるのではなく、既存の記事に統合されます。ソース間の矛盾は記事内で特定され解決されます。結果は合成です：3ヶ月間研究したトピックに関する十分にコンパイルされたエントリは、3週間後に構築されたものとは異なって読み取られます。なぜなら、基礎となる資料がより豊かで、つながりがより深いからです。

これはベクトルインデックスを構築するよりも計算量が多く、それが継続的にではなくオンデマンドまたはスケジュールで実行される理由です。それが意図された設計です。出力品質は検索ベースのシステムが生成するものとは質的に異なり、処理コストはその違いを反映しています。技術的な役割以外のナレッジワーカーにとって、このパイプラインを構成する必要がないこと自体が意味のある利点です：コンパイルステップはボタンであり、あなたが書いたスクリプトではありません。

Lint is the operation that prevents knowledge from degrading.Karpathyは元のGistでlintパスを説明しました：wiki全体を定期的にスキャンして不整合、古い情報、より最近の資料と矛盾するエントリを特定するものです。彼はそれが必要であると述べました。彼が指定しなかったのは、それをどのように自動化するか、どのくらいの頻度で実行するか、wikiが大きくなりすぎて実行がコスト高になる場合にどうするかです。

実際には、lintはDIY実装で最初にスキップされるものです。それを実行するには、実行することを覚えていること、利用可能な動作するスクリプトがあること、時間とAPIコストを割り当てることが必要です。強く始まる実装のほとんどは徐々にlintの実行を止め、wikiは明らかな失敗信号なしにその後の数ヶ月で信頼性が低下します。エントリは権威的に見えますが、ますます間違っています。

AK Wikiでは、Lintはメインインターフェースからアクセスできる組み込み操作です。すぐにトリガーするか、自動的に実行するようスケジュールできます。AIは既存のエントリを知識ベースの現在の状態に対してレビューし、不整合になったコンテンツにフラグを立て、更新します。Karpathyのアーキテクチャが必要とするが指定していないメンテナンスループは、AK Wikiではボタンです。

What Your Knowledge Base Looks Like Over Time

このアーキテクチャの価値はセットアップ時には見えません。それは蓄積されます。

1ヶ月目には、Topic Collectionsが最も活発な研究分野を中心に形成され始めます。エントリは有用です：数週間のキャプチャした資料を構造化された記事に合成し、rawソースを検索するよりも速く質問に答えます。クロストピックのつながりは、まだつなぐものが多くないため限定的です。システムはすでにrawファイルのフォルダを検索するよりも有用ですが、複合はまだ始まっていません。これは、DIY実装が有望に感じるが、まだ不可欠な結果を生み出していない段階です。また、Gistのコメントで extensively 文書化されているように、複合がその価値を示す時間ができる前にメンテナンスループが壊れるため、ほとんどの実装がここで停滞する段階でもあります。

3ヶ月目には、Concept Collectionsが重要になり始めます。AIは異なるコンテキストでキャプチャした資料を読みました：3ヶ月前にクリップした記事、先月のミーティングトランスクリプト、先週インデックスしたドキュメント。それらの間のつながりを、あなたが意図的に作成しなかったものとして表面化します。1ヶ月目に構築された競合分析エントリは、あなたが3ヶ月目にキャプチャした製品発表を組み込むために更新され、あなたの側での手動アクションは一切ありません。ナレッジベースは、もはやあなたが入れたものの構造化されたバージョンではありません。あなたが明示的に構築しなかった理解を含み始めています。

6ヶ月目には、システムは尋ねることを知らなかった質問に答え始めます。トピックに十分な密度がある場合、AIは最近キャプチャしたものではなく、数ヶ月の蓄積されたコンテキストを利用します。新しい論文と以前の研究の関係について尋ねる研究者は、その分野での6ヶ月間の読書を反映した回答を得ます。繰り返し発生する苦情パターンについて尋ねるプロダクトマネージャーは、現在のフィードバックをQ1に行われた製品決定に結びつける応答を得ます。特定の建築的選択がなぜ行われたかを尋ねる開発者は、4回の別々のミーティングで起こった議論のスレッドにわたって推論をトレースするエントリを見つけます。

Analytics Vidhyaは直接述べています：意義は技術的な実装よりも、それが表すパラダイムシフトにあります：クエリするツールとしてのAIから、時間の経過とともにあなたの特定のドメインの理解を蓄積するシステムとしてのAIへ。Karpathyが説明した複合効果は本物です。ほとんどの実装が到達しないのは、その効果が可視化される時間的地平線です。なぜなら、そこに到達するのに十分長く存続しないからです。

この種の知識システムから最も恩恵を受ける人々は、必ずしもその背後のインフラを構築し維持するのに最適な立場にある人々ではありません。AK Wikiはそれら2つを分離します。

AK Wiki vs. DIY LLM Wiki vs. RAG

これら3つのアプローチは、異なるユーザー、スケール、要件に適しています。それらの間の選択は、どのアーキテクチャが優れているかについての技術的な判断ではありません。それは、あなたが誰で、何を現実的に持続できるかについての実際的な質問です。

Building it yourselfは、完全なアーキテクチャ制御が必要で、単一の焦点を絞ったドメインで働き、インフラを構築し維持するための技術的背景を持っている場合に正しい選択です。Epsilla's analysisは、このアーキテクチャのエンタープライズ限界を正しく指摘しています：RAGの根本的な問題を特定するが、実際には機能させるために独自のメンテナンスシステムを必要とします。システムのすべてのレイヤーを所有したい開発者にとって、自分で構築することは合理的な道です。

AK Wiki in remioは、インフラのコミットメントなしに複合知識効果を望む場合に正しい選択です。自動キャプチャが手動のraw/キュレーションに取って代わります。組み込みのcompileとlintがカスタムスクリプトとcronジョブに取って代わります。Web検索による情報補完が、ローカルのみのシステムでは対処できないギャップを埋めます。結果は、所有者がエンジニアである必要のないコンパイルされた知識wikiです。

RAGは、厳格なアクセス制御、マルチユーザー要件、コンパイルされたwikiが扱える範囲を超えるドキュメントコーパスを持つ大規模エンタープライズナレッジベースに適した正しいアーキテクチャです。このパターンは、DIYまたは製品を通じて実装されるかどうかにかかわらず、パーソナルおよび小チームの知識管理向けに設計されています。エンタープライズ規模では、検索インフラが正しい基盤です。

• Raw intake:DIYは手動キュレーションを必要とします；AK Wikiは自動的にキャプチャします；RAGは自動的にインデックスします

• Compile:DIYは手動スクリプトを必要とします；AK Wikiはボタンまたはスケジュールで実行します；RAGは継続的にインデックスします

• Lint:DIYのメンテナンスは手動でしばしば放棄されます；AK Wikiには組み込みのスケジュール可能なlint操作があります；RAGには同等物がありません

• Transparency:DIYとAK Wikiの両方が読みやすく編集可能なエントリを生成します；RAGは検査にツールを必要とするベクトル埋め込みを保存します

• Non-technical users:DIYはセットアップでブロックされます；AK Wikiは箱から出してすぐ使えます；RAGはパイプライン構成を必要とします

• Scale ceiling:DIYとAK Wikiはパーソナルから小チーム規模に適しています；RAGは事実上無制限です

Karpathyが名付けた問題は新しいものではありません。AIアシスタントが役立つようになって以来、ナレッジワーカーはセッションの境界でコンテキストを失ってきました。Gistがしたことは、そのアーキテクチャを十分に正確に説明したことで、1600万人が自分たちが欠けていたものを認識したことです。

アーキテクチャは正しいです。それが解決する問題は本物です。数ヶ月にわたって一貫して実行することは難しい部分です。Karpathyが説明した知識システムを、それをサポートするインフラを構築せずに欲しい場合、remio's AI-native second brainには、AK Wikiが箱から出してすぐ使える実装として含まれています：自動キャプチャ、組み込みのcompileとlint、クロストピック合成、情報補完、そして初日から複合する知識。