KarpathyのLLM Wiki：ナレッジベース locale

#LLM Wiki：二分でわかる仕組み

2026年4月2日、Andrej Karpathy は X で、言語モデルを使って個人用ナレッジベースを構築する方法を説明しました。その2日後、彼は「LLM Wiki」というタイトルの gist を公開し、LLM でこの種のベースを構築するためのパターンとして紹介しました。2つの文章はいずれも短く、読むのに10分かかりません。リンクはページ末尾にあります。

このgistは、LLMとドキュメントを組み合わせる用途の大半がRAGに似ているという認識から始まります。ファイルを置くと、システムが質問の時点で関連する抜粋を見つけ、モデルが回答を作成します。Karpathyは、これが機能することを認めつつ、モデルが質問のたびに知識を再発見し、何も蓄積されない点を指摘しています。五つのドキュメントを横断する必要がある質問では、毎回同じ断片を見つけてつなぎ合わせる必要があります。

LLM Wikiは作業を前倒しします。新しいソースが届くと、モデルは単にインデックスを作成するだけではありません。ソースを読み、要点を抽出し、相互に関連付けられたMarkdownページの集合に統合します。既存のページを更新し、要約を見直し、新しいソースが既存の記述と矛盾する箇所を記録します。gistでは、時間とともに改善される永続的なアーティファクトについて述べています。質問が来た時点で、すでに突き合わせが済んでいるのです。

本文では役割分担が明確です。人間は情報源を選び、調査し、質問します。モデルはそれ以外のすべて、つまり要約、関連付け、分類、記録の管理を担います。Karpathyは、画面の片側でエージェントを開き、もう片側でObsidianを使っていると述べ、構成を次のようにたとえています。ObsidianがIDE、LLMがプログラマー、wikiがコードベースです。

#三つの層：ソース、wiki、規約

gistでは三層構成について説明しています。どの層にも特別なツールは必要ありません。フォルダーとテキストファイルだけで構成されています。

生の情報源

ドキュメントのコレクション：記事、研究論文、画像、データファイルです。これらは不変であり、モデルが読み取るだけで変更することはありません。正しさの基準となるのは wiki ではなく、これらの情報源です。

Wiki

モデルが作成したMarkdownファイルのフォルダーです。ソースの要約、エンティティページ、概念ページ、比較、全体の統合を含みます。この層はモデルに属し、モデルがページを作成・更新し、リンクを維持します。あなたは読み、モデルが書きます。

規約ファイル

Wikiの構成、従うべきルール、ソースの取り込み、質問への回答、整理を行う方法をモデルに指示するドキュメントです。gistでは、Claude Code向けにCLAUDE.md、Codex向けにAGENTS.mdを挙げています。このファイルが、汎用エージェントを規律あるWikiメンテナーに変えます。

二つの特別なファイルが、モデルとあなたの両方が内容を把握するのに役立ちます。一つ目のindex.mdはカタログです。各ページがリンクと一行の要約付きで、カテゴリ別に並んでいます。質問に答えるとき、モデルはまずインデックスを読み、次に必要なページを開きます。二つ目のlog.mdは、取り込み、質問、検証の実行を追記していく時系列のログです。

gistでは、ログの各エントリを一定のプレフィックスで始めることを推奨しています。これにより、単純なUnixツールでフィルタリングできます。示されている例は次の形式です：

## [2026-04-02] ingest | Article Title

#三つの操作：取り込む、問い合わせる、確認する

取り込む（ingest）

ソースを生ソース用フォルダーに置き、モデルに処理を依頼します。gistによれば、モデルはソースを読み、主要な点についてあなたと議論し、要約ページを書き、インデックスと関係するエンティティおよび概念のページを更新し、その後ログにエントリを追加します。Karpathyによれば、一つのソースがwikiの10～15ページに影響することがあります。

問い合わせ（query）

質問を入力すると、モデルが関連するページを探して読み、参照元を引用した回答を作成します。gistが強調している点が1つあります。良い回答は新しいページとしてWikiに整理できるため、探索の成果が会話履歴の中に消えることなく蓄積されます。

確認（lint）

ときどき、wikiの健全性チェックをモデルに依頼します。ページ間の矛盾、より新しい情報源によって古くなった主張、被リンクのない孤立ページ、専用ページのないまま言及されている概念、欠落している相互参照などを確認します。

なぜこの作業をモデルに任せるのでしょうか。要点は単純です。個人Wikiを壊すのは、読むことでも考えることでもなく、記録の維持です。相互参照を更新し、要約を最新に保ち、矛盾を洗い出す。その保守負担はWikiの価値より速く増大し、やがて放棄してしまいます。モデルは疲れず、一度に十五個のファイルを変更できます。Karpathyはこの発想を、Vannevar Bushが1945年に構想したMemexに結び付けています。

#ローカルモデルで管理するWikiの前提条件

gistは特定のプロバイダーを前提としていません。必要なのは、モデルによって制御され、ファイルを読み書きできるエージェントです。ローカル環境では、次の要素で構成されます。

Ollama、最新

http://localhost:11434上でモデルを提供します。後述するollama launchコマンドは、最近のバージョンにしか存在しません。インストール方法はガイド「Ollamaをインストールする」で説明しています。

ファイルにアクセスできるエージェント

チャットインターフェースだけでは不十分です。ディスク上のファイルを開き、作成し、変更できるツールが必要です。以下の例では、gistで紹介されているターミナルのオープンソースエージェントOpenCodeを使用します。このエージェントはフォルダーのルートに配置されたAGENTS.mdファイルを読み取ります。

ツールを呼び出すことができるモデル

ファイルの読み書きはツール呼び出しを介して行います。ライブラリOllamaでtools機能を表示するモデルを選んでください。私たちの「OpenCode + Ollama」ガイドでは、qwen3-coder:30b、devstral-small-2:24b、gpt-oss:20bなど、複数のモデルを紹介しています。

コンテキスト用のメモリ

重みだけの場合のQ4_K_Mでの目安は、パラメーター70億個で約5 GB、140億個で9 GB、320億個で19 GBです。Ollamaのドキュメントでは、エージェントに少なくとも64 000トークンのコンテキストを要求しており、これが上記の数値に加わります。

Git

wikiはMarkdownファイルのフォルダーにすぎません。gistが指摘しているように、これをgitリポジトリにすれば、何も追加せずにバージョン履歴を得られます。

Obsidian（任意）

wikiを読み、リンクをたどり、ページのグラフを表示するためのものです。どのMarkdownエディターでも構いません。Obsidianは執筆には関与しません。

#Ollama を使ったセットアップ：手順ごとに解説

コマンドはmacOSおよびLinux向けに記述されています。WindowsではWSLを使うのが最も簡単です。ディレクトリ構成と規約ファイルは調整して使う例です。gistにも、フォルダー構成、規約、ページ形式は利用するドメインとモデルによって異なり、すべて任意かつモジュール式であると記載されています。

1. 01
   フォルダーとリポジトリを作成する

   生データ用のフォルダー、ページ用のフォルダー、インデックス、ログをすべてgitの下に置きます。
2. 02
   規約ファイルを書く

   ルートに、構造、記述ルール、そして三つの手順（取り込み、質問、検証）を説明するAGENTS.mdを置きます。
3. 03
   モデルとエージェントを起動する

   Ollama は、64,000トークンのコンテキストでツールを呼び出せるモデルを提供します。OpenCode は wiki のフォルダーで開きます。
4. 04
   最初のソースを取り込む

   単一のドキュメントを目の前で処理し、再確認してからgitに保存します。
5. 05
   レスポンスを確認して整理する

   質問は wiki に投稿し、役立つ要約はページにします。
6. 06
   定期的に確認する

   矛盾、孤立ページ、リンク切れを一覧にするチェック工程。

#1. フォルダーとリポジトリを作成する

mkdir -p ~/wiki/raw
mkdir -p ~/wiki/wiki/sources ~/wiki/wiki/entites ~/wiki/wiki/concepts
cd ~/wiki
touch wiki/index.md wiki/log.md
git init

raw/フォルダーには文書を、wiki/フォルダーにはモデルが作成したページを保存します。二つの区別が明確である限り、名前は自由です。

#2. 規約ファイルを書く

これが最も重要な部分です。これがなければ、エージェントはセッションごとに異なる構成を即興で作ります。~/wikiのルートにAGENTS.mdファイルを作成してください。たとえば、次の内容を基にします：

# Conventions du wiki

Tu es le mainteneur de ce wiki. Tu écris et tu mets à jour les pages.
L'humain choisit les sources et pose les questions.

## Structure
- raw/ : sources brutes. Lecture seule : ne jamais modifier, renommer ni supprimer.
- wiki/sources/ : une page de résumé par source.
- wiki/entites/ : une page par personne, organisation, outil ou produit.
- wiki/concepts/ : une page par notion.
- wiki/index.md : catalogue de toutes les pages (lien + résumé d'une ligne), par catégorie.
- wiki/log.md : journal chronologique, ajout seul.

## Règles d'écriture
- Noms de fichiers en minuscules, avec tirets, sans accents.
- Liens internes au format [[nom-de-page]].
- Chaque affirmation renvoie au fichier de raw/ dont elle vient.
- Si deux sources se contredisent, garder les deux versions et le signaler.
- Avant de créer une page, vérifier dans l'index qu'elle n'existe pas déjà.

## Ingestion
Quand on te demande d'ingérer un fichier de raw/ :
1. Lire la source en entier.
2. Présenter les points clés et attendre la validation.
3. Écrire la page de résumé dans wiki/sources/.
4. Mettre à jour ou créer les pages d'entités et de concepts concernées.
5. Mettre à jour wiki/index.md.
6. Ajouter une entrée à wiki/log.md : ## [AAAA-MM-JJ] ingest | Titre

## Question
1. Lire wiki/index.md, puis les pages utiles.
2. Répondre en citant les pages et les sources brutes.
3. Ne rien affirmer qui ne figure pas dans le wiki ; dire ce qui manque.
4. Si la réponse apporte une synthèse nouvelle, proposer de l'enregistrer comme page.

## Vérification
Signaler sans corriger d'office : contradictions, affirmations dépassées,
pages orphelines, concepts cités sans page, liens cassés.

このファイルはKarpathyのものではなく、私たちのものです。gistでは、規約ファイルの役割を説明していますが、ひな形は提供していません。また、自分の分野で何が機能するかが分かるにつれて、モデルとともに内容を発展させることを推奨しています。短く保ってください。エージェントは毎回のセッションでこれを読み直し、各行がコンテキストを占有します。

#3. モデルとエージェントを起動する

ツールを呼び出せるモデルをダウンロードし、wikiのフォルダーでOpenCodeを開いてください。ollama launch opencodeコマンドは、セレクターで選択したOllama提供のモデルを使ってOpenCodeを起動します。OpenCode自体のインストール方法は、ガイド「OpenCode + Ollama」で説明しています。

# Un modèle généraliste avec appel d'outils (à adapter à votre mémoire)
ollama pull gpt-oss:20b

# Ouvrir l'agent dans le dossier du wiki
cd ~/wiki
ollama launch opencode

残るのはコンテキストです。Ollamaのドキュメントによると、デフォルトのウィンドウはVRAMに依存し、24 GB未満では4,000トークン、24～48 GBでは32,000トークンです。一方、エージェントには少なくとも64,000トークンが必要です。OLLAMA_CONTEXT_LENGTH変数でサーバー起動時に設定できます。Ollamaがすでにアプリケーションまたはサービスとして動作している場合は、二つ目のサーバーを起動するのではなく、その設定で値を変更してください。

OLLAMA_CONTEXT_LENGTH=64000 ollama serve

# Dans un autre terminal, une fois le modèle chargé :
ollama ps

ollama psコマンドは、モデルが完全にGPU上に収まっているかどうかを示します。プロセッサー側にはみ出すと、取り込みのたびに非常に遅くなります。コンテキストを削る前に、より小さいモデルを使用してください。

#4. 最初のソースを取り込む

raw/に最初の文書を置きます。Markdownまたはテキスト形式がおすすめです。Webページの場合、gistでは、記事をMarkdownファイルに変換するObsidian Web Clipper拡張機能が案内されています。続いて、エージェントに指示を与えます：

Ingère raw/mon-premier-article.md en suivant AGENTS.md.
Présente-moi d'abord les points clés et attends ma validation avant d'écrire.

エージェントはソースを読み、要点を提案し、その後ページを作成・編集します。先に進む前に結果を確認してください。要約ページ、作成されたエンティティページ、インデックス、ログを確認します。その後、Wikiの状態を保存してください。

git status
git add -A
git commit -m "ingest: mon-premier-article"

#5. 回答を質問して整理する

いくつかのソースを確認したら、同じフォルダーにいるエージェントに質問してください。ページとソースを明示的に引用し、wikiに含まれていない内容も述べるよう求めてください。

D'après le wiki, qu'est-ce qui distingue l'approche A de l'approche B ?
Cite les pages et les sources brutes utilisées, et signale ce qui manque.
Si la réponse apporte une synthèse nouvelle, enregistre-la dans wiki/concepts/
puis mets à jour l'index et le journal.

#6. 定期的に確認する

数回取り込むごとに、検証を一度実行してください。修正する前に問題の一覧を求めます。そうすれば、何を統合、名前変更、削除するかを自分で管理できます。

Fais une passe de vérification du wiki en suivant AGENTS.md.
Liste les problèmes trouvés, sans rien modifier pour l'instant.

ログはエージェントなしで確認できます。入力に付く一定のプレフィックスを使えば、gistに記載されたコマンドで直近の処理が表示されます（変更するのはディレクトリ構成に合わせたパスだけです）：

grep "^## \[" wiki/log.md | tail -5

#LLM WikiまたはRAG：ボスが置き換えないもの

このgistは考え方を理解してもらうためにwikiとRAGを対比しています。一方が他方に取って代わるとは述べておらず、このガイドもそうは述べていません。2つのアプローチは異なる状況に対応します。提示できる測定結果がないため、数字を使わずに違いを説明します。

作業のタイミング

RAG は質問ごとに動作します。抜粋を検索し、その後モデルが文章を作成します。wiki は取り込み時に動作します。要約を一度作成し、質問のたびに読み返します。

保持されるもの

RAGは、そのままでは読めない抜粋とそのベクトルを保持します。wikiは、読んだり修正したりバージョン管理したりできる、文章として作成されたページを保持します。

L'infrastructure

RAGには、埋め込みモデル、ベクトルデータベース、分割戦略が必要です。wikiには、ディレクトリとエージェントが必要です。gistによれば、中程度の規模（およそ百個のソースと数百ページ）であればインデックスだけで十分で、埋め込みを基盤とするRAGインフラを構築せずに済みます。

情報源への忠実性

RAGは元の文章の一節をモデルに渡します。Wikiはモデルが書いた言い換えを渡すため、それに伴う誤りのリスクがあります。

容量

RAGは大規模なコーパス向けに設計されています。Wikiはモデルが一度に読み取れる量によって制限されます。インデックス、必要なページ、ソースがコンテキストウィンドウに収まらなければなりません。

中程度の規模を超えると、gist自体が検索を再導入します。そこでは、BM25、ベクトル検索、LLMによる再ランキングを組み合わせたMarkdownファイル用のローカル検索エンジンqmdを紹介しています。qmdはコマンドラインでもMCPサーバーとしても利用できます。つまり、大規模なWikiは最終的にRAGの構成要素に依存することになりますが、対象となるのは生の文書ではなく、すでに要約されたページです。この二つのアプローチは排他的というより、組み合わせて使うものです。

実際には、コーパスが大規模または常に変化する場合（企業ドキュメント、チケット、契約書）、回答で文書の正確な箇所を再現する必要がある場合、または異なる権限を持つ複数の人が同じデータベースに問い合わせる場合は、従来のRAGを使い続けてください。LLM Wikiは、数週間かけて掘り下げるテーマに適しています。情報収集、調査、読書、資料作成などです。これらはgist自身が挙げている用途です。

#知っておくべき制限、特にローカル環境での制限

エラーも蓄積します

ページに書かれた要約の誤りは、後から読み直され、引用され、次のページへ伝播します。RAGでは、誤った回答は会話とともに消えますが、wikiでは残ります。生のソースへの体系的な参照と、変更内容の再確認が必要なのはそのためです。

ローカルモデルには余裕が少ない

取り込みでは、長い指示に従い、複数のファイルを読み、十個ほどのファイルを一つも漏らさず変更する必要があります。一般に、小型モデルは、このような長いタスクを、gistで挙げられているエージェントの背後でホストされた大型モデルほど適切に処理できません。まずは小さく始め、自分のソースで判断してください。

コンテキストウィンドウがすべてを制限する

非常に長いソース、増大したインデックス、読み直す10ページが、常に64 000トークンに収まるとは限りません。大容量のソースは章ごとに分割し、短いページを維持してください。

取り込みには時間がかかる

各ソースが一連の読み取りと書き込みを発生させます。控えめなマシンでは、一晩でライブラリ全体を処理するimport dのではなく、ソースごとに処理すると考えてください。

構造が派生する

厳格なルールがないと、エージェントは重複（同じエンティティを二つの名前で登録すること）や、どこからもリンクされていないページを作成します。規約ファイルの命名規則と検証パスは、そのために役立ちます。

#ヒントとトラブルシューティング

エージェントが取り込みの手順を飛ばす

コンテキストが短すぎる可能性があります。処理の途中で指示が現在のウィンドウからはみ出しています。OLLAMA_CONTEXT_LENGTH の値を確認し、AGENTS.md を短くするか、ソースを分割してください。

エージェントは、何も書き込まずに実行する内容を説明します

このモデルはツール呼び出しの処理が苦手です。Ollamaのライブラリでtoolsの能力が表示されるモデルを選んでください。

同じエンティティが二つの名前で表示される

重複に絞った検証を一度実行するよう依頼し、マージを一つずつ承認してから、規約ファイルに欠けていた命名規則を追加してください。

インデックスが長くなりすぎる

カテゴリごとに分割し、セカンダリインデックスを参照するメインインデックスを用意するか、gistで紹介されているqmdのようなMarkdownファイル用の検索ツールを追加します。

回答が既存のページを無視します

取り込み時にインデックスが更新されませんでした。wiki/フォルダーの内容から再構築してから、ログを確認してください。

#すぐに使える実装

すべてを手作業で書く必要はありません。Nous ResearchのオープンソースエージェントであるHermes Agentには、研究カテゴリに収録されたllm-wikiという組み込みskillがあり、このパターンを実装しています。すでにOllamaとともにこのエージェントを使っているなら、より迅速に始められます。下記にリンクしたドキュメントページで、その仕組みが説明されています。基本原則は変わりません。情報源を任せる前に、規約を読んでください。

#出典

パトロンについて述べている内容はすべて、Andrej Karpathyの投稿とgistに基づいています。OllamaとOpenCodeの設定は、それぞれのドキュメントに基づいており、当方のガイド『OpenCode + Ollama』ですでに引用しています。コマンドを貼り付ける前に、これらのページを読み直してください。これらのツールは急速に変化します。

https://x.com/karpathy/status/2039805659525644595

https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f

https://hermes-agent.nousresearch.com/docs/user-guide/skills/bundled/research/research-llm-wiki

https://docs.ollama.com/context-length

https://docs.ollama.com/integrations/opencode

#さらに詳しく

LLM Wiki は、サイトですでに扱った複数のテーマが交差する位置にあります。これらのガイドはそれぞれ、このガイドが意図的に扱っていない内容をカバーしています。

ローカル RAG：入門

埋め込み、ベクトルデータベース、分割処理：従来型RAGの仕組みを理解し、いつ適切な選択肢であり続けるのかを知るために押さえておくべき内容です。https://quelllm.fr/guide/rag-local-introduction

Obsidian + ローカル LLM

CopilotとSmart Connectionsのプラグインを使ってローカルモデルをObsidianの保管庫に接続し、自分で書いたノートについて対話します。https://quelllm.fr/guide/obsidian-llm-local-ollama

ローカルでNotebookLM

中間Wikiなしで、ソースノートと引用付き回答を再現するオープンソースツール。https://quelllm.fr/guide/notebooklm-local-alternative

ファインチューニングとRAGの比較

Karpathyは投稿の中で、探究の方向性として、自分のデータベースのデータでモデルをファインチューニングすることに触れています。このガイドは、それに労力をかける価値があるか判断するのに役立ちます。https://quelllm.fr/guide/fine-tuning-vs-rag-choisir

OpenCode + Ollama

ここで使用したエージェントのインストール、コンテキストの設定、権限。https://quelllm.fr/guide/opencode-ollama-agent-terminal