RAGパイプラインの背後に知識を閉じ込めるのはやめよう——Markdownで十分だ

ここ数年、AIシステムに知識を与えるということは、インフラを構築することを意味していた。ドキュメントをチャンク化し、埋め込みモデルを選び、ベクターデータベースを立ち上げ、検索をチューニングし、SDKでラップし、さらにその上にグラフを構築するかもしれない。それが終わる頃には、あなたの会社の知識はもはや読めるものではなく、パイプラインを通じて、サービスの背後で、たまたま選んだフレームワークに所有されたクエリ対象になっていた。

そのアプローチ全体が、決して閉じ込める必要のなかった知識を閉じ込めていた。その修正はほとんど恥ずかしいほどシンプルだ：Markdownである。

RAGは良いアイデアだった——しかし代償があった

検索拡張生成（RAG）は、コンテキストウィンドウが小さくモデルが高価だった時代に、実際の問題を解決した。Graph RAGはそれをさらに押し進めた。これらの手法は機能する。しかし、その代償を見てほしい。知識をRAGシステムに投入するには、システムだけが理解できる形に変換する。ドキュメントは埋め込みになり、関係性はデータベースのエッジになる。知識はパイプラインに入った瞬間に人間が読めなくなる。エージェントが実際に「知っている」ものを確認したい場合、単にファイルを開くことはできず、それを閉じ込めたのと同じ仕組みに対してクエリを実行しなければならない。

すべてのチームがこれをゼロから再構築している。すべてのエージェントビルダーが同じコンテキスト組み立て問題を解決している。すべてのカタログベンダーが同じデータモデルを再発明している。知識は結局、それを生み出した表面の背後に、次のツールが翻訳なしでは読めない形式で閉じ込められる。それが門だ：ペイウォールではなく、フォーマットの壁である。

誰もが再発見し続けたパターン

そのインフラがすべて構築されている間、もっと静かなことが起こっていた。人々はMarkdownを書き始めた。Claude CodeやCodexを使ったことがあるなら、CLAUDE.mdやAGENTS.mdをアーキテクチャとは思わずに書いたことがあるだろう。プロジェクトの仕組み、従うべき規約、触れてはいけないものを書き留めた——するとエージェントが改善された。埋め込みもベクターストアもない。モデルがセッションの開始時に読み込むファイルだけだ。

このパターンはさまざまな名前で現れ続けた：リンク付きノートで埋め尽くされたObsidianボールト、DESIGN.md、MEMORY.md、「メタデータ as コード」リポジトリ。これらすべては同じ本能だ：知識をプレーンテキストとして書き留め、断片をリンクでつなぎ、モデルに直接読ませる。LLMが真に、確実に得意とする形式は、標準化するには原始的すぎると私たちが扱っていたものだったことが判明した。Markdownは儀式なしで構造を持つ——見出し、リスト、リンク、少しのフロントマター。モデルがナビゲートするのにちょうど十分な足場であり、人間が同じファイルを読んで即座に理解するのにちょうど十分にシンプルだ。

KarpathyのLLM Wikiパターン

Andrej KarpathyはこれをLLM Wikiパターンと名付けた。アイデアは3層構造で、すべてプレーンファイルで構成される。sources/ディレクトリには、モデルが不変として扱う生の素材を置く。wiki/には、モデルが生成し所有するMarkdownページ——要約、概念ページ、エンティティページ——を置く。そしてスキーマファイル（CLAUDE.mdまたはAGENTS.md）が、エージェントに全体の維持方法を指示する。

洞察：LLMは飽きず、相互参照の更新を忘れず、1回のパスで15のファイルに触れることができる。人間が個人Wikiを放棄する原因となる簿記作業こそ、LLMが得意とするものだ。したがって、トレードが逆転する。RAGはクエリのたびに知識をゼロから再発見する。Wikiは知識を一度コンパイルし、最新の状態に保つ。相互参照はすでに存在する。矛盾はすでにフラグが立てられている。合成はすでに与えたすべてを反映している。そしてそれはすべて単なるファイルだ——開き、編集し、gitに入れられる。知識は何にも閉じ込められていない。

GoogleのOpen Knowledge Format

6月、Google CloudはOpen Knowledge Format（OKF）（現在バージョン0.1）を発表した。これは、誰もがすでに実践していたMarkdown Wikiの本能を、ベンダーに依存しない標準に変えるものだ。OKFバンドルはMarkdownファイルのディレクトリであり、各ファイルが1つの概念を表す：データセット、テーブル、メトリクス、ランブック、API。これらは適切な階層に配置され、YAMLフロントマターにtype、title、description、resource、tags、timestampなどの構造化フィールドを持つ。

概念は通常のMarkdownリンクで相互にリンクする——注文テーブルの外部キーは単に[customers](/tables/customers.md)を指す。これらのリンクはディレクトリを関係のグラフに変え、フォルダが示す親子の入れ子よりも豊かになる。グラフデータベースを立ち上げずにGraph RAGの利点を得られる。リンクこそがグラフなのだ。

仕様が必須とするフィールドはtypeだけだ。それ以外はすべて、従っても無視してもよい規約である。それがモデルのすべてだ。埋め込みも、ベクターストアも、パイプラインもない。ただのファイルだ。