Karpathyが、RAGを回避しAIが保守する進化するMarkdownライブラリで動く「LLMナレッジベース」アーキテクチャを共有

VentureBeat / 2026/4/4

💬 オピニオンSignals & Early TrendsIdeas & Deep AnalysisTools & Practical Usage

要点

  • アンドレイ・カラパシーは、LLMが保守する進化し続ける永続的なMarkdownライブラリを用いて、研究トピックを管理する「LLM Knowledge Base」アプローチを説明している。
  • 主な目的は、セッションの再構築に頼るのではなく、構造化されたコンテキストを継続的に更新し続けることで、コンテキスト制限のリセットによる「ステートレス」なつらさを軽減することにある。
  • 通常のRAGとは異なり、この方法はベクトルデータベースや類似検索によるチャンク取得を回避し、中規模データセットでは、読みやすく相互にリンクされたMarkdown上で推論できるというLLMの能力を重視している。
  • そのアーキテクチャには、段階的な取り込み(生データをObsidian Web ClipperでローカルのMarkdownへ変換し、ビジョン参照用に画像を保存すること)と、その後にLLMが知識ファイルをコンパイル、リンティング(静的検査)、およびリンク付けする工程が含まれる。
  • カラパシーは、知識が人間に読める.md形式のまま維持されるため、それを「セカンドブレイン」の設計図として、自律的に自己修復し、かつ監査可能だと位置づけている。

AIバイブのコーダーたちには、「用語を作った」 アンドレイ・カーパシーに感謝すべき、また別の理由があります。

かつてテスラのAI部門ディレクターで、OpenAIの共同創業者でもある彼は、現在は自身の独立したAIプロジェクトを運営しており、最近Xにて「『LLMナレッジベース』」というアプローチについて投稿し、研究上関心のあるさまざまなトピックを扱うために使っていると説明しました。

カーパシーは、プロジェクトの持続的で、LLMが管理する記録を構築することで、「ステートレス」なAI開発における根本的な苛立ち――憎きコンテキスト上限リセット――を解決しようとしています。

バイブでコーディングしたことがある人なら誰でも言えるように、使用上限に当たったりセッションが終わったりすると、プロジェクトに対して強制的な「脳外科手術」のような感覚になることがよくあります。あなたは貴重なトークン(そして時間)を投じて、AIにコンテキストを再構築させることを強いられます。そして、「さっきまでにあなたが確立したアーキテクチャのニュアンスを、AIが“覚えて”くれる」ことを期待することになります。

カーパシーは、典型的なエンタープライズ解決策――ベクターデータベースとRAGパイプライン――よりも、もっとシンプルで、より大まかに、ぐちゃっとしていながらも美しい何かを提案しています。

その代わりに彼は、LLM自身が、常勤の「リサーチ・ライブラリアン」として振る舞うようなシステムを描いています。つまり、Markdown(.md)ファイルを能動的に収集し、整合性をチェックし、互いにリンクさせることで、最もLLMに親和的でコンパクトなデータ形式を用いるのです。

カーパシーは「トークンのスループット」のかなりの部分を、定型のコード処理ではなく、構造化された知識の操作に振り向けることで、「Second Brain(セカンド・ブレイン)」の次のフェーズの設計図を浮かび上がらせました。そこでは自己修復し、監査可能で、完全に人間が読めるものになります。

RAGの彼方へ

ここ3年ほど、LLMに独自データへのアクセスを与えるための支配的なパラダイムはRetrieval-Augmented Generation(RAG)です。

標準的なRAG構成では、ドキュメントは任意の「チャンク」に切り分けられ、数学的なベクトル(埋め込み)に変換され、専用のデータベースに保存されます。

ユーザーが質問すると、システムは「類似検索」を行って最も関連性の高いチャンクを見つけ、それをLLMに渡します。カーパシーのアプローチであり、彼がLLM Knowledge Basesと呼ぶものは、中規模のデータセットに対してはベクターデータベースの複雑さを退けます。

代わりに、構造化されたテキストに対して推論するLLMの能力がますます高まってきていることに依拠します。

Xユーザーの@himanshu による可視化(そしてカーパシーの投稿に対するより広い反応の一部)によると、システムのアーキテクチャは3つの明確な段階で機能します:

  1. データ投入: 生の素材――研究論文、GitHubリポジトリ、データセット、Web記事――がraw/ディレクトリに放り込まれます。カーパシーはObsidian Web Clipperを使って、WebコンテンツをMarkdown(.md)ファイルに変換します。画像も含めてすべてローカルに保存されるため、LLMはビジョン機能を通じてそれらを参照できます。

  2. コンパイル手順: ここが中核の革新です。単にファイルをインデックス化するのではなく、LLMがそれらを「コンパイル」します。生データを読み取り、構造化されたウィキを書き上げるのです。ここには、要約の生成、重要な概念の特定、百科事典のような記事の執筆、そして――決定的に重要な――関連する考え同士のバックリンクの作成が含まれます。

  3. 能動的なメンテナンス(Linting): このシステムは静的ではありません。カーパシーは、「ヘルスチェック」や「linting(整合性チェック)」の実行、つまりLLMがウィキをスキャンして、不整合や不足データ、新しいつながりがないかを検出するようなプロセスを説明しています。コミュニティメンバーCharly Wargnierが観察したように、「それは実際に自己修復する、生きたAIのナレッジベースとして機能します。」

Markdownファイルを「唯一の真実(source of truth)」として扱うことで、カーパシーはベクタ埋め込みのブラックボックス問題を回避します。AIによってなされるあらゆる主張は、人間が読める/編集できる/削除できる、特定の.mdファイルにたどり着けます。

エンタープライズへの示唆

カーパシーのセットアップは現時点では「スクリプトのハッキーな寄せ集め」として説明されていますが、エンタープライズに与える影響はすぐに現れます。

起業家Vamshi Reddy(@tammireddy)が発表への反応として指摘したように、「すべてのビジネスにraw/ディレクトリはある。誰もそれをコンパイルしたことがない。それがプロダクトです。」

カーパシーは同意し、この方法論が「信じられないほど新しいプロダクト」カテゴリを示しているのだと示唆しました。

ほとんどの企業は現在、非構造化データに「溺れ」ています。Slackのログ、社内ウィキ、そして誰も統合して合成する時間のないPDFレポートです。

「カーパシー風」のエンタープライズ層は、これらのドキュメントを検索するだけではありません。リアルタイムで更新される「Company Bible(社内バイブル)」を、能動的に作成してくれるはずです。

AI教育者でありニュースレターの執筆者でもあるOle LehmannがXでこう言ったように、「これを普通の人向けにパッケージ化しているのは、ものすごいものに座っている人だと思う。あなたがすでに使っているツール、ブックマーク、あとで読むアプリ、ポッドキャストアプリ、保存したスレッド――それらと同期する1つのアプリです。」

AIエンタープライズエージェント構築・オーケストレーションのスタートアップEdraの共同創業者兼CEOであるEugen Alpezaは、Xの投稿でこう述べました:「個人のリサーチ用ウィキから、エンタープライズの運用へ移行するところが、容赦なくて厳しい。何千人もの従業員、何百万もの記録、そしてチームをまたいで互いに矛盾する部族的知識。実際、新しいプロダクトの余地はありますし、私たちはそれをエンタープライズで作っています。」

コミュニティが「カーパシー・パターン」を探っているうちに、注目はすでに個人のリサーチから、マルチエージェントのオーケストレーションへと移りつつあります。

@jumperz、AIエージェント作成プラットフォームSecondmateの創業者による最近のアーキテクチャ分解は、「Swarm Knowledge Base(スウォーム・ナレッジベース)」を通じてこの進化を示しています。これは、OpenClawで管理された10エージェントのシステムにまで、ウィキのワークフローを拡張します。

マルチエージェントのスウォームにおける中核の課題――1つの幻覚が増幅し、集合的な記憶を「感染」させてしまうこと――は、ここでは専用の「Quality Gate(品質ゲート)」によって対処されています。

構造化された評価のためにNous Researchが訓練したHermesモデルを、独立した監督者として使用します。すべての下書き記事は、ライブなウィキに昇格される前にスコア付けされ、検証されます。

このシステムは「Compound Loop(コンパウンド・ループ)」を生み出します。エージェントが生の出力を投げ込み、コンパイラがそれを整理し、Hermesが真実性を検証し、検証済みのブリーフィングが各セッションの開始時にエージェントへフィードバックされます。これにより、スウォームが「空っぽの状態で目を覚ます」ことはなくなり、代わりに、これまでに集合知が学んだ内容すべてをフィルタし、高い完全性を備えたブリーフィングを各タスクの最初に受け取って始められるようになります

スケーリングとパフォーマンス

ベクター以外のアプローチに対する一般的な批判はスケーラビリティです。しかしカーパシーは、約100の記事・約40万語という規模なら、要約やインデックスファイルを使ってLLMがナビゲートする能力は十分以上にある、と述べています。

部署のウィキや個人のリサーチプロジェクトであれば、「手の込んだRAG」向けのインフラは、解決する以上に待ち時間や「検索ノイズ」を増やしがちです。

テック系ポッドキャスターのLex Fridman(@lexfridman)は、同様のセットアップを使っていることを確認し、さらに動的な可視化の層を追加していると述べました:

"私はしばしば、動的なHTML(js付き)を生成させて、データをソート/フィルタできるようにし、可視化もインタラクティブにいじれるようにしています。もう一つ役立つのは、システムが一時的なfocusedなミニ・ナレッジベース(焦点を絞った小さな知識ベース)を生成してくれることで、それを7〜10マイルの長いラン中にボイスモードでやり取りするためのLLMに読み込ませています。"

この「エフェメラル・ウィキ(儚いウィキ)」というコンセプトは、ユーザーがAIとただ「チャット」するのではなく、特定のタスクのためのカスタムなリサーチ環境を構築するエージェントのチームを生成し、その後レポートが書き上がると解散するような未来を示唆しています。

ライセンシングと「ファイル・オーバー・アプリ」思想

技術的には、カーパティの手法はオープン標準(Markdown)に基づいていますが、そこには独自形式だが拡張可能という観点(メモ取り・ファイル整理アプリ Obsidian)で見られています。

  • Markdown(.md): Markdownを選ぶことで、カーパティは知識ベースが特定のベンダーにロックされないようにしています。将来を見据えており、Obsidianが消えてもファイルはどんなテキストエディタでも読み取れるままです。

  • Obsidian: Obsidianは独自のアプリケーションですが、その「ローカル・ファースト」思想とEULA(個人利用は無料で商用利用にはライセンスが必要)により、開発者がデータの主権(データソブリンティ)を望む姿勢と整合しています。

  • 「Vibe-Coded(雰囲気で実装)」ツール: カーパティが言及している検索エンジンやCLIツールは、LLMとローカルのファイルシステムの間をつなぐカスタムスクリプトで、おそらくPythonベースです。

この「ファイル・オーバー・アプリ」思想は、NotionやGoogle DocsのようなSaaS中心のモデルに対する真正面からの挑戦です。カーパティのモデルでは、ユーザーがデータを所有し、AIは高度に洗練されたエディタとして、ファイルに「訪問」して作業を行うだけです。

司書 vs 検索エンジン

AIコミュニティは、技術的な裏づけと「vibe-coding(雰囲気で実装)」への熱狂の両方を交えて反応しています。議論の焦点は、業界が、類似性だけでなく本質的に構造に関する問題に対して、Vector DBに過度に最適化(過剰投資)していないかどうかです。

Claudeを使う溶接工のJason Paul Michaels(@SpaceWelder314)も、より単純なツールのほうが頑健であることが多いという趣旨を反響させています:

"No vector database. No embeddings... Just markdown, FTS5, and grep… Every bug fix… gets indexed. The knowledge compounds."

しかし、最も大きな称賛は、Obsidianの共同創設者であるSteph Ango@Kepano)から寄せられました。彼は「Contamination Mitigation(汚染の緩和)」という概念を取り上げています。

彼は、ユーザーは個人の「ボールト」を清潔に保ち、エージェントは「散らかったボールト」で作業させるべきだと提案しました。そして、エージェント向けのワークフローがそれらを選別し、役に立つ成果物だけを持ち帰るようにするのです。

あなたの企業向け「vibe coding」プロジェクトにはどの解が正しい?

機能

Vector DB / RAG

カーパティのMarkdown Wiki

データ形式

不透明なベクトル(数学)

人が読めるMarkdown

ロジック

意味的類似(最近傍)

明示的なつながり(バックリンク/インデックス)

監査可能性

低い(ブラックボックス)

高い(直接的な追跡可能性)

増殖(コンパウンド)

静的(再インデックスが必要)

能動的(リンティングによる自己修復)

理想的なスケール

数百万のドキュメント

100〜10,000の高シグナルなドキュメント

「Vector DB」のアプローチは、とても速いフォークリフト運転手がいる巨大で無秩序な倉庫のようなものです。何でも見つけられますが、なぜそこにあるのか、隣のパレットとどう関係しているのかは分かりません。カーパティの「Markdown Wiki」は、常に新しい本を書いて昔の本を説明し続ける、監修された図書館のようなものです。

次のフェーズ

カーパティの最終的な探究は、このデータの究極の行き先として、合成データ生成とファインチューニングへ向かっています。

ウィキが成長し、LLMの継続的なリンティングによってデータがより「純度の高い」状態になっていくほど、それは完璧なトレーニングセットになります。

LLMが「コンテキストウィンドウ」の中でウィキをただ読むのではなく、ユーザーは最終的に、そのウィキ自体を使ってより小さくて効率的なモデルをファインチューニングできるようになります。これにより、LLMは研究者の個人的な知識ベースを、自身の重みの中に「知っている」状態にでき、結果として、個人の研究プロジェクトをカスタムでプライベートなインテリジェンスに変えることが可能になります。

結論:カーパティは単にスクリプトを共有しただけではありません。彼は思想を共有しました。LLMを、自身のメモリを維持する能動的なエージェントとして扱うことで、「ワンショット」的なAIのやり取りの限界を回避してきたのです。

個人の研究者にとっては、「忘れられたブックマーク」の終わりを意味します。

企業にとっては、「生データ/データレイク」から「コンパイルされた知識資産」への移行を意味します。カーパティ自身がまとめたように:「あなたはウィキを手作業で書いたり編集したりすることはほとんどありません。それはLLMの領域です。」私たちは、自律的なアーカイブの時代へ入っています。