LLM Wiki v2（16 分間の読了）

LLM Wiki v2 — エージェントメモリ構築の教訓を踏まえた Karpathy の LLM Wiki パターンの拡張 LLM を用いた個人知識基盤の構築パターン。AI コーディングエージェント向けの永続的メモリエンジンである [agentmemory](https://github.com/rohitg00/agentmemory)（GitHub スター数 1 万超）の構築から得た教訓を拡張して取り入れています。 これは [Andrej Karpathy のオリジナル LLM Wiki アイデアファイル](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f) に基づいています。オリジナルの記述はすべて依然として有効です。この文書では、本パターンを実環境で運用して得た教訓、つまりスケールした際に何が破綻するか、何が欠落しているか、そして有用なウィキと腐敗するウィキを分けるものは何かについて追加しています。 現在、私の発見に基づき、AI エージェント間で永続的な知識を作成・更新・取得・共有するためのプロトコルである [AKBP: Agent Knowledge Base Protocol](https://github.com/rohitg00/akbp) の開発を進めています。 ## オリジナルが正しく捉えている点 核心的な洞察は正しいです。**再導出を止め、コンパイル（集約）を開始する**のです。RAG（Retrieval-Augmented Generation：検索拡張生成）は取得して忘れ去りますが、ウィキは蓄積し複利効果を生みます。3 層アーキテクチャ（生データソース、ウィキ、スキーマ）は機能します。運用プロセス（取り込み、照会、リンティング）も基本を網羅しています。まだオリジナルを読んでいない場合は、そこから始めるべきです。 以下に、数千のセッションでこのパターンを構築・運用した後に発見された事項を示します。 ## 欠落していたレイヤー：メモリのライフサイクル 元のWikiは、すべてのコンテンツを永遠に同等に有効なものとして扱います。しかし実際には、知識にはライフサイクルが存在します。先週発見したバグの方が、6ヶ月前のバグよりも重要です。12回目に確認したパターンは、一度しか見たことのないパターンよりも信頼性が高いです。新しいソースからの主張は、自動的に古い主張を弱めるべきです。 **信頼度スコアリング**。Wiki内のすべての事実は、信頼度スコアを持つべきです：それを支持するソースの数、最後に確認された時期、それに反証するものがあるかどうか。LLMが「プロジェクトXはキャッシュにRedisを使用している」と記述する場合、その主張は2つのソースから来たこと、3週間前に最後に確認されたこと、そして信頼度が0.85であることを認識しているべきです。信頼度は時間とともに減衰し、裏付けによって強化されます。これにより、Wikiは同等の重みを持つ主張の単なる平坦なコレクションから、LLMが「Xについてはかなり確信があるが、Yについてはそれほど確信がない」と言えるような生きたモデルへと変化します。 **代替（上位置換）**。新しい情報が既存の主張と矛盾する場合や更新する場合、古い主張は単に注釈付きで残しておくべきではありません。新しい主張が明示的にそれを置き換えるべきです。リンクされ、タイムスタンプ付きで、旧バージョンは保存されるものの「古くなった」とマークされます。ファイルだけでなく、知識自体に対するバージョン管理です。 **忘却。** すべてのことを永遠に保存する必要はありません。一度も忘れないウィキはノイズだらけになります。保持曲線を実装してください：かつて重要だった事実でも、数ヶ月アクセスや再強化が行われていないものは、徐々に薄れていくべきです。削除されるのではなく、優先度が下がるのです。これは何かを引き出しの奥にしまう LLM 版のアプローチです。エビングハウスの忘却曲線がここでよく機能します。保持率は時間とともに指数関数的に減衰しますが、各再強化（アクセスや新しいソースからの確認）によって曲線はリセットされます。アーキテクチャ決定はゆっくりと減衰し、一時的なバグは急速に減衰します。 **統合ティア。** 生の観測事実と確立された事実は同じではありません。パイプラインを構築してください： - ワーキングメモリ（作業記憶）：最近の観測事実で、まだ処理されていないもの - エピソードメモリ（エピソード的記憶）：セッション要約で、生の観測事実から圧縮したもの - セマンティックメモリ（意味記憶）：セッションを跨ぐ事実で、エピソードから統合されたもの - プロシージャルメモリ（手続記憶）：ワークフローとパターンで、反復されるセマンティクスから抽出したもの 各ティアは、その下のものよりもより圧縮され、より確信に満ちており、より長寿命です。LLM は証拠が蓄積されるにつれて情報を上のティアへ昇格させます。これが「一度これを見た」から「これが仕組みだ」という変化をもたらす方法です。 ## 平坦なページを超えて：ナレッジグラフ 元のウィキはウィキリンクを持つページです。それは機能しますが、構造化された構造を台無しにしています。実際には、ページの上にレイヤーとして積まれた型付きのナレッジグラフ（知識グラフ）が欲しいのです。 **エンティティ抽出。** LLM がソースを摂取する際、単に文章を書くだけでなく、構造化されたエンティティを抽出すべきです。人物、プロジェクト、ライブラリ、概念、ファイル、決定などです。各エンティティには型、属性、および他のエンティティとの関係性が付与されます。「React」はライブラリであり、「認証移行（Auth migration）」はプロジェクトです。「Sarah」は認証移行の所有者であり、React に関する意見を持つ人物です。 **型付きの関係。** すべての接続が等価ではありません。「使用している」「依存している」「矛盾する」「原因となった」「修正した」「代替する」といった関係性は、それぞれ異なる意味的重みを持ちます。「A は B と関連する」というリンクよりも、「A が B を引き起こし、3 つのソースによって確認され、信頼度 0.9」というリンクの方がはるかに有用です。 **クエリのためのグラフ走査。** 「Redis のアップグレードが与える影響は何ですか？」と質問された際、LLM は単なるキーワード検索を行うべきではありません。Redis ノードから開始し、「依存している」「使用している」などのエッジを介して外側へ歩き回り、すべての下流の要素を見つける必要があります。これにより、キーワード検索では見逃される接続も捕捉できます。 このグラフはウィキページを置き換えるものではなく、それを補完するものです。ページは読むためのもの、グラフはナビゲーションと発見のためのものです。 ## 実際のスケーラビリティを持つ検索 元の手法は、すべてのページをカタログ化する単一のファイル `index.md` に依存しています。これはおそらく 100〜200 ページ程度までは機能しますが、それを超えるとインデックス自体が長すぎて LLM が一度のパスで読み込めなくなり、本格的な検索が必要になります。 **ハイブリッド検索。** 最良のアプローチは、3 つのストリームを組み合わせるものです： - BM25（語幹抽出と類義語拡張を伴うキーワードマッチング） - ベクトル検索（埋め込みによる意味的類似性） - グラフ走査（エンティティ認識に基づく関係の探索） これらの結果を相互順位融合で統合します。各ストリームは他が捉え損ねた情報をキャッチします。BM25 は正確な用語を検出し、ベクトルは意味的類似性を発見し、グラフは構造的な接続を見つけます。これらを組み合わせることで、単一の手法よりも優れた結果が得られます。 index.md を人間が読みやすいカタログとして維持しつつ、LLM の主要な検索メカニズムとしては約 100 ページを超えた段階では依存しないようにしてください。 ## オートメーション：手動からイベント駆動へ 元の手法における最大の実際の課題は、すべてが手動である点です。ソースを投入して LLM に処理を指示するだけで、定期的にリンティングを実行するのを忘れたり、回答を提出するタイミングを自分で決定したりする必要があります。 実際にはフックが必要です。自動的に発火するイベントとは以下の通りです： - 新しいソースの追加時：自動取り込み、エンティティ抽出、グラフ更新、インデックス更新 - セッション開始時：直近の活動に基づき、ウィキから関連コンテキストを読み込む - セッション終了時：セッションを観察結果に圧縮し、洞察を提出する - クエリ発生時：回答を提出する価値があるか確認（品質スコアが閾値を超える場合） - メモリ書き込み時：既存の知識との矛盾がないかチェックし、置換トリガーを発動 - スケジュール実行時：定期的なリンティング、統合、保持期間の減衰処理 キュレーションと方向性の決定には人間が関与し続けるべきですが、人々がウィキを放棄してしまう原因となる事務処理部分は完全に自動化されるべきです。 ## 品質と自己修正 - Vector search (semantic similarity via embeddings) - Graph traversal (entity-aware relationship walking) Fuse the results with reciprocal rank fusion. Each stream catches things the others miss. BM25 finds exact terms. Vectors find semantic similarity. The graph finds structural connections. Together they beat any single approach. Keep index.md as a human-readable catalog, but don't rely on it as the LLM's primary search mechanism past ~100 pages. ## Automation: from manual to event-driven The biggest practical gap in the original is that everything is manual. You drop a source and tell the LLM to process it. You remember to run lint periodically. You decide when to file an answer back. In practice, you want hooks. Events that fire automatically: - On new source: auto-ingest, extract entities, update graph, update index - On session start: load relevant context from the wiki based on recent activity - On session end: compress the session into observations, file insights - On query: check if the answer is worth filing back (quality score > threshold) - On memory write: check for contradictions with existing knowledge, trigger supersession - On schedule: periodic lint, consolidation, retention decay The human should still be in the loop for curation and direction. But the bookkeeping, the part that makes people abandon wikis, should be fully automated. ## Quality and self-correction すべての LLM 生成コンテンツが良いわけではありません。品質管理がないと、ウィキにはノイズが蓄積されていきます。 **すべてにスコアを付けましょう。** LLM が作成するあらゆるコンテンツには品質スコアを付与すべきです。構造化は適切か？出典は引用されているか？他のウィキの記述と矛盾しないか？LLM に自己評価させるか、異なるプロンプトで第 2 のパスを実行して評価させます。閾値以下のコンテンツはレビュー対象としてフラグを立てるか、書き直します。 **自己修復機能。** 元の記事にあったリンチ操作（lint operation）は単なる提案ではなく、可能な箇所を自動的に修正するべきです。孤立したページはリンク付けするかフラグを立てます。陳腐化した主張にはマークを付けます。壊れた相互参照は修復されます。ウィキは、あなたが手動で指示を出すときだけでなく、自発的に健全な状態へと向かうべきです。 **矛盾の解決。** 元の記事では矛盾をフラグ立てることが言及されていますが、それは第 1 のステップに過ぎません。第 2 のステップはそれを解決することです。LLM は、情報の鮮度（source recency）、出典の権威性（source authority）、および支持する観測数の多さに基づき、どちらの主張がより正しい可能性が高いかを提案すべきです。人間が上書きすることは可能ですが、デフォルトの動作は通常正しくあるべきです。 ## マルチエージェントとコラボレーション 元の記事は単一ユーザー・単一エージェントを想定しています。しかし、多くの実際のユースケースでは、複数のエージェントや複数の人が同じナレッジベースに貢献するケースが含まれます。 **メッシュ同期。**複数のエージェントが並列で作業している場合（異なるコーディングセッション、異なる調査スレッド）、それらの観測結果は共有ウィキに統合される必要があります。多くのケースでは「最後の書き込みが勝つ」方式で十分です。競合が発生した場合は、タイムスタンプに基づく解決策を採用し、必要に応じて手動での上書きを可能とします。 **共有とプライベートの区別。**一部の知識は個人のものであるべきです（私の好み、私のワークフロー）。一方、プロジェクトアーキテクチャやチームの決定など、共有されるべき知識もあります。ウィキには適切なスコーピングが必要です。プライベートな観測結果は、昇格された際に共有知識へと統合される仕組みとします。 **作業調整。**複数のエージェントが同じナレッジベースで作業する際、軽量な調整メカニズムが必要です。「誰が何に取り組んでいるか」「何がブロックされているか」「何が完了したか」を把握できる程度で十分です。完全なタスク管理システムである必要はなく、重複作業の防止と進捗追跡に十分な機能があればよいのです。 ## プライバシーとガバナンス 原文ではこの点に触れられていませんが、非常に重要です。ソースには機密情報が含まれていることがよくあります：API キー、認証情報、非公開の会話、個人識別情報（PII）などです。 **取り込み時のフィルタリング。**ウィキにデータが到達する前に、機密データを除去する必要があります。API キー、トークン、パスワード、あるいは「プライベート」とマークされたあらゆる情報は自動的に削除されるべきです。これは手動で行うものではなく、自動化されるべきプロセスです。 **監査証跡。**ウィキ上でのすべての操作（取り込み、編集、削除、照会）は、タイムスタンプ、変更内容、およびその理由とともにログ記録される必要があります。これが責任追跡の層となります。ウィキ上で何かが不審な場合、監査証跡によってそれがどのようにしてそこに到達したのかを特定できます。 **ガバナンスを伴うバッチ処理。** wiki が成長するにつれ、古くなったコンテンツの一括削除、サブセットのエクスポート、重複エントリのマージが必要になるでしょう。これらの操作は監査可能で、かつ元に戻せるものであるべきです。 ## 結晶化：探索からの複合効果 原文では「良い回答は新しいページとして wiki に記録できる」と述べられています。これをさらに発展させることができます。 **結晶化（Crystallization）**とは、完了した作業チェーン（研究スレッド、デバッグセッション、分析など）を自動的に構造化された要約へと抽出するプロセスです。問いは何だったか？何が見つかったか？関連するファイルやエンティティは何か？どのような教訓が得られたか？この要約が wiki の主要なページとなり、教訓は知識基盤を強化するための独立した事実として抽出されます。 あなたの探索活動も、記事や論文と同様に情報源です。wiki はそれをそのように扱うべきです。結果を取り込み、グラフを更新し、既存の主張を強化または挑戦してください。 ## マークダウンを超えた出力フォーマット 原文ではスライドデッキに Marp を、チャートに matplotlib を使用すると言及されていますが、wiki の出力はマークダウンページに限定されるべきではありません。クエリに応じて、適切な出力形式は以下のようになります： - 比較表 - タイムラインの可視化 - 依存関係グラフ - 発見結果を提示するためのスライドデッキ - さらなる分析のための構造化データエクスポート（JSON, CSV） - チームメンバーへのブリーフィング wiki は知識の保管庫です。出力フォーマットは、対象となる読者と問いの内容によって決定されます。 ## スキーマこそが真の製品である 原文はこれを暗示していますが、あえて明確に述べるなら：**スキーマドキュメント（CLAUDE.md, AGENTS.md）がシステム内で最も重要なファイルです。** これは汎用的な大規模言語モデル（LLM: Large Language Model）を規律ある知識労働者に転換させるものです。そこには以下のような要素がエンコードされています。 - ドメイン内に存在するエンティティと関係性の種類 - 異なる種類のソースから情報を取り込む方法 - 新しいページを作成すべきか、既存のページを更新すべきかの判断基準 - 適用すべき品質基準 - 矛盾への対処法 - 統合スケジュールの概要 - プライベートな情報と共有情報の区別 あなたと LLM は時間とともにこのドキュメントを共進化させます。最初のバージョンは粗末なものになるでしょうが、数十件のソースを取り込み、数回のリンティング（lint）パスを経ることで、あなたのドメインが実際にどのように機能しているかを反映したスキーマが完成します。そのスキーマは移転可能です。同様のドメインで作業する他者と共有すれば、彼らはすぐにスタートダッシュを切ることができます。 ## 実装のスペクトラム これらすべてはモジュール化されています。初日にすべての機能が必要というわけではありません。 **最小限の実行可能なウィキ**: 生データソース + ウィキページ + index.md + 取り込み・照会・リンティングワークフローを記述するスキーマ。これは原文が概ね説明している内容です。これで動作します。ここから始めましょう。 **ライフサイクルの追加**: 信頼度スコアリング、置換（supersession）、基本的な保持期間の減衰機能。これにより、ウィキがごみ箱化することを防ぎます。 **構造の追加**: エンティティ抽出、型付き関係、ナレッジグラフ。これにより照会精度が向上し、フラットなページだけでは見逃す可能性のある接続性が浮き彫りになります。 **自動化の追加**: 自動取り込み、自動リンティング、コンテキスト注入のためのフック。ここがメンテナンス負担をほぼゼロに下げるポイントです。 **スケーラビリティの追加**: ハイブリッド検索、統合ティア、品質スコアリング。ウィキが数百ページを超えて成長した際に必要な機能です。 **コラボレーションの追加**: メッシュ同期、共有/プライベートスコーピング、作業調整。これはチームやマルチエージェント設定向けです。 ニーズに応じてエントリーポイントを選んでください。このパターンはあらゆるレベルで機能します。 ## なぜこれが重要なのか Karpathy の元の洞察は依然として有効です：ボトルネックは書誌管理（bookkeeping）にあり、LLM はそのボトルネックを解消します。私たちが追加したのは、ウィキがスケールしても健全性を保つための仕組みです。ライフサイクル管理により知識の腐敗を防ぎ、構造により接続が失われないようにし、自動化により人間がファイル作業ではなく思考に集中できるようにし、品質管理により時間とともにウィキへの信頼を築きます。 Memex はついに構築可能になりました。それはより優れたドキュメントや検索があるからではなく、実際に作業を行う司書がいるからです。 *この文書は、[Andrej Karpathy の LLM Wiki](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f) に、[agentmemory](https://github.com/rohitg00/agentmemory) で実証されたパターンを追加したものです。agentmemory は [iii-engine](https://github.com/iii-hq/iii) を基盤とした AI エージェント向けの永続メモリエンジンです。元のアイデアファイルが基礎であり、この文書ではエンジンを構築する過程で得た知見を追加しています。*

LLM Wiki v2（16 分間の読了）

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト