AIエージェント

llm-wikiとqmdの違い：LLM知識ベースは編纂か検索か

2026/9/9 （更新: 2026/11/3）

🤖 AIを使用して執筆

編纂する設計

Andrej Karpathyが2026年4月4日（UTC）に公開したllm-wikiは、「LLMを使って個人の知識ベースを構築するためのパターン」だと自ら述べている¹。実装ではなく、自分のLLMエージェントに貼り付けて使うための考え方を書いた文書だと明記されている。Karpathyは、OpenAIの創業メンバーでのちにTeslaのAI部門を率いた研究者で、これを会社の製品ではなく個人のgist（GitHubで一つの文書やコード片を公開する仕組み）として置いており、GitHubの表示ではstarが5,000件以上ある³¹。

出発点は、既存のやり方への観察である。Karpathyは、多くの人の経験が「ファイルの集まりをアップロードし、LLMが質問時に関連する断片を取得して答を生成する」形だと書き、それが機能することは認める。そのうえで、この形では「LLMが質問のたびに知識をゼロから再発見している。蓄積が無い」と指摘する。

提案する構造は三層からなる。第一層は生の資料で、これは「不変であり、LLMは読むが決して変更しない」。第二層がwikiで、LLMが生成する markdown ファイルの集まりである。第三層がスキーマで、wikiがどう構造化されているかをLLMに伝える文書を指す。Claude CodeならCLAUDE.md、CodexならAGENTS.mdが例として挙がっている。

操作は三つある。資料を取り込むIngest、wikiに問うQuery、そしてLintである。Queryについては、よい答えを新しいページとしてwikiへ書き戻せることを「重要な洞察」として挙げ、wikiは資料を足すたびにも質問するたびにも豊かになるとしている¹。Lintの中身は具体的に書かれている。ページ間の矛盾、新しい資料によって置き換えられた古い主張、入ってくるリンクの無い孤立ページ、言及はあるが独立したページを持たない重要概念、欠けた相互参照、Web検索で埋められるデータの穴を、定期的に探させる。

なぜこの設計が成り立つのかについて、Karpathyは維持コストの所在で説明する。「知識ベースを維持するとき面倒なのは、読むことでも考えることでもない。事務作業のほうだ」。そして「人間がwikiを放棄するのは、維持の負担が価値より速く増えるからだ」と書く。事務作業をLLMが引き受けられるなら、人間が維持をやめていたwikiを維持できる、という筋である。

Karpathyはここで強い言い方をしている。「LLMは退屈しないし、相互参照の更新を忘れないし、一度に15のファイルに触れる。wikiが維持され続けるのは、維持の費用がほぼゼロだからだ」¹。ただしこの一文が指すのは事務作業をLLMが引き受ける分で、同じ節は直後に「人間の仕事は、資料を選び、分析の方向を決め、よい問いを立て、それが何を意味するかを考えることだ。LLMの仕事はそれ以外のすべてだ」と人間の側の仕事を切り分けている¹。

検索する設計

tobi/qmdは、Shopifyの創業者でCEOのTobi Lütkeが個人名義で公開しているコマンドライン検索エンジンである⁴。リポジトリの説明文は「ドキュメント、知識ベース、議事録などのための小さなCLI検索エンジン。すべてローカルで動かしながら現在のsotaな手法を追う」となっている²。sotaはstate of the artの略で、その時点の最先端を指す。2025年12月8日に作成され、2026年9月12日時点でstarは29,679件だった。

qmdは要約を先に作らないので、どの文書を答えに使うかを質問が来てから選ぶ。そこで解くべき課題が二つある。質問と違う言い回しで書かれた文書を取りこぼさないことと、高価なLLMに全文書を読ませないことである。本稿は、READMEが並べる手順をこの二つの課題に分けて説明する²。

取りこぼしを防ぐのが前半である。質問をそのまま使うと、言い換えられた文書に当たらない。そこでLLMに、質問を言い換えたクエリを作らせる（クエリ展開）。

検索の方式も一つではなく、語の一致を見る全文検索と、意味の近さを見るベクトル検索の二つがある。ベクトル検索は、文章を数値の並び（ベクトル）に変え、質問のベクトルに近い文書を探す。文章をベクトルに変える処理を埋め込みと呼ぶ。展開したクエリは全文検索向けとベクトル検索向けに型を分けて書かせ、それぞれ一方の検索だけに流す。元の質問は両方の検索に流し、その結果には2倍の重みを掛ける。

こうして複数の順位表ができるので、順位の逆数を足す $\mathrm{score} = \sum 1/(k + \mathrm{rank} + 1)$（$k = 60$）で一本にまとめる。この融合の方式をRRF（Reciprocal Rank Fusion）と呼ぶ。ただし展開には副作用があり、READMEは「純粋なRRFは、展開したクエリが一致しないときに完全一致を薄めうる」と書く。それを受けて、いずれかの一覧で1位だった文書に0.05、2位から3位に0.02を足す加点を置き、狙いを「元のクエリに対して1位を取った文書を保つ」ことだと説明する²。

費用を抑えるのが後半である。まとめた上位の候補（実装とREADMEのパラメータ表の既定は40件で、READMEの手順の説明と図は30件と書く）だけをLLMへ回し、各文書が質問に答えているかを採点させる。この採点を再ランクと呼ぶ。

再ランクにも副作用がある。検索の側で確信度の高かった文書を、LLMの採点が押し下げてしまうことがある。対策は、順位帯によって二つの採点の混ぜ方を変えることである。

• 1位から3位：検索75パーセント、再ランク25パーセント（READMEの注記は「完全一致を保つ」）
• 4位から10位：検索60パーセント、再ランク40パーセント
• 11位以降：検索40パーセント、再ランク60パーセント（同じく「再ランクをより信頼する」）

READMEはこの狙いを「位置を考慮した混合は、再ランクが確信度の高い検索結果を壊すのを防ぐ」と書いている。

三段の比を並べると、方針は一つである。上位ほど検索の一致を信じ、下位ほどLLMの判断を信じる。

qmdは、手元の計算機で動かすモデルを三つ使う。どれもGGUF（ローカル実行向けに言語モデルを1ファイルに収める形式）で、初回利用時に自動で取得する。埋め込みのembeddinggemma-300M-Q8_0が約300MB、再ランクのqwen3-reranker-0.6b-q8_0が約640MB、クエリ展開のqmd-query-expansion-1.7B-q4_k_mが約1.1GBで、合計およそ2GBになる²。すべてローカルで動く代わりに、この分は最初に置いておく必要がある。

二つは競合していない

llm-wikiのgistは、qmdを名前を挙げて推薦している。「ある時点で、LLMがwikiをもっと効率よく操作できるよう、小さなツールを作りたくなるだろう。wikiのページを対象にした検索エンジンが最もわかりやすい。小規模なら索引ファイルで足りるが、wikiが大きくなると本格的な検索が欲しくなる。qmdは良い選択肢だ」¹。コマンドラインで使えることと、MCPサーバーとしても動くことも、推薦の理由として挙げられている。MCP（Model Context Protocol）は、LLMのエージェントが外部のツールを呼び出すための標準の仕組みである。ただしこの推薦は「任意のCLIツール」という見出しの下にあり、直後に「もっと単純なものを自分で作ってもよい」と続く。文書末尾の注記も、挙げたものはすべて任意で組み替え可能であり、wikiが小さければ索引ファイルだけで足りて検索エンジンは要らない、と書いている¹。

規模の目安も同じ文書に書かれている。索引ファイルによる方式は「およそ100件の資料、数百ページという中規模ではうまく働き、埋め込みベースのRAG基盤を不要にする」。この記述は、索引ファイルで足りる範囲と、検索エンジンが要る範囲の境目を、著者自身が引いていることを示す。規模の目安はほかにもあり、Anthropicは20万トークン（約500ページ）より小さい知識ベースなら、RAGのような手法を使わずにプロンプトへ丸ごと入れればよいと書いている⁵。

qmdの側も、wikiを検索の対象に置く使い方を例に含めている。同梱する設定例には、wikiという名前のコレクションが入っている。~/reference/wiki配下のmarkdownを再帰的に拾う指定で、git pull --ff-onlyを更新コマンドに置き、説明文には「外部のwiki。qmd updateのたびに自動で取得される」と書かれている。同じ設定例が置くグローバルコンテキストも「関連する[[WikiWord]]を見かけたら、そのWikiWordを検索してさらにコンテキストを得られる」で、wiki風の記法を前提にしている²。ただし設定例もREADMEもllm-wikiの名を挙げてはいない。これはwiki一般への対応であって、llm-wikiという特定の設計を想定した記述ではない。

したがって、読者が迫られる選択は「どちらの製品を採用するか」ではない。資料の規模と、更新の手間を先に払うか後に払うかの配分である。両方を使う場合は、上のgistの目安を超えてwikiが大きくなり、本格的な検索が要るようになった時点で、その検索の道具としてqmdを足すのがgistの書く組み合わせである¹。

同じ選択は検索研究の側でも起きている

検索の研究で提案された手法も、質問が来る前にLLMに何を書かせておくかで並べられる。以下の四つの手法は、索引を作る段階でLLMに書かせるものがそれぞれ違う。

Stanford大学のSarthiらがICLR 2024で発表したRAPTORは、文書の断片を「再帰的に埋め込み、クラスタリングし、要約して、下から上へ異なる要約水準を持つ木を構築する」手法である⁶。質問時にはこの木から、原文の断片と上位の要約の両方を取り出す。著者らは、平均5,000トークンほどの文章を読んでから答える選択式の読解ベンチマークQuALITYで、GPT-4と組み合わせると最良成績を絶対値で20ポイント上げたと報告する。木を作る費用は文書長に対して線形で、しかも家庭用のハードウェアで収まる範囲にとどまる。原典は付録で、その確認のために16GBのM1 Macを使ったと書いている。要約を先に作っておくという点で、これはllm-wikiと同じ側に立つ。ただし作るのはwikiではなく、検索のための索引である。

Microsoft ResearchのEdgeらが2024年4月にプレプリントで発表したGraphRAGは、索引を作る段階で、LLMに知識グラフと要約の両方を作らせる。著者らは、従来の検索型RAGは「データセットの主題は何か」のような、コーパス（検索の対象になる文書の集まり全体）に向けた問いに答えられないと指摘し、その理由を、これが「検索の課題ではなく、質問に焦点を絞った要約の課題」だからだと説明する⁷。索引の作り方はこうである。まず資料から実体の知識グラフを取り出し、次に関連する実体のまとまりごとに要約をあらかじめ生成しておく。質問が来ると、各要約から部分回答を作り、それを再び要約して答える。100万トークン規模のデータセットで、答えの網羅性と多様性が従来のRAGを大きく上回ったと著者らは報告する。

ただし同じ論文は、グラフ索引を作らずに質問時に原文を直接要約する方式とも比べている。事前に作った要約がこの方式に対して示した改善を、著者らは「小さいが一貫した」ものと書き、最上位の要約だけを使う条件ではその改善も見られなかった。差がはっきり出たのは質問あたりのトークン量で、同じ最上位の条件では97パーセント以上少なかった⁷。この比較から読めるのは、先に編纂した利得が、答えられる問いの広さよりも、同じ問いに質問時に払う費用の軽さに出たということである。

同じグループは7か月後の2024年11月に、LazyGraphRAGを発表した⁸。ブログは「資料の事前要約を必要とせず、利用者や用途によっては法外になりうる前払いの索引費用を避ける」と書き、索引の費用は「ベクトルRAGと同一で、完全なGraphRAGの0.1パーセント」だとする。設計は「LLMの使用をすべて質問時まで遅らせる」もので、費用と品質の釣り合いは「関連性検査の予算」という一つのパラメータで調整する。llm-wikiとqmdの間の選択で言えば、同じ研究グループが7か月で、編纂の側（GraphRAG）に続いて検索の側（LazyGraphRAG）の設計も出したことになる。ただしブログは、グラフを使うRAGをすべて遅延型にすべきかという問いに「答えはノーだと考える」と書き、理由を三つ挙げる⁸。事前に作った要約の索引は報告として読む価値も持ち、それに遅延型の検索を組み合わせれば単独より良い結果になる見込みが高く、遅延型の検索に合わせた新しい索引が最良になる見込みが高い、という理由である。

原典は、索引の費用のほかに質問時の費用も報告している。ブログは、大域的な問いでは完全なGraphRAGの大域検索と同等の答えの品質で質問時の費用が700分の1以下になり、局所的な問いではベクトルRAGと同程度の質問費用で競合手法をすべて上回るとも書いている⁸。索引時の手間が質問時へ移ったのなら質問時の費用は上がるはずで、そうなっていない。ここで起きたのは移動ではなく、両方の時点での減少である。設計を入れ替えれば総量が減ることはあり、作業を取り込み時と質問時のどちらに置くかという見方では、それは説明できない。

粒度をもっと下げた例もある。Anthropicが2024年9月に公開したContextual Retrievalは、断片ごとにその断片を説明する短いコンテキストをLLMに書かせてから埋め込みとBM25の索引を作る⁵。BM25（Best Matching 25）は、質問の語が文書に現れる回数、その語の珍しさ、文書の長さをもとに文書へ点を付ける、全文検索の標準的な採点方式である。索引時にLLMを使う点は編纂の側だが、作るのは要約ではなく、検索の取りこぼしを減らすための注釈である。同社は取り出しの失敗が49パーセント減り、再ランクを足すと67パーセント減ったと報告し、プロンプトキャッシュを使う前提で、注釈を作る一度きりの費用を文書100万トークンあたり1.02米ドルと見積もっている。前払いの手間に値段が付いている例として読める。

これらを並べると、編纂と検索の間には段階がある。wiki全体を書く（llm-wiki）、要約の木を作る（RAPTOR）、実体グラフとまとまりの要約を作る（GraphRAG）、断片に注釈を付ける（Contextual Retrieval）、索引時にはLLMに何も書かせない（qmd、LazyGraphRAG）。どれもLLMの仕事をどの時点に置くかの選択である。同じ手法の中で事前の要約の有無を比べれば、先に置いた分だけ、質問時に払うと高くつく答え（コーパス全体の主題、複数段の要約）が安く出せ、その分は資料が変わるたびに古くなる。ただし手法をまたぐとこの関係は保たれず、事前に要約しないLazyGraphRAGは、大域的な問いの質問時の費用でもGraphRAGを下回った⁸。

編纂の側で落ちるものと、足されるもの

編纂は、資料を読んだ時点で内容を書き換える。原典の文はwikiの中では要約と相互参照に置き換わり、読者がふだん読むのは原典ではなくその要約である。gistは生の資料を変更しない「信頼できる情報源」として第一層に保ち、質問への答えには引用を付けさせる¹。本稿の推論では、ここで二つのことが起きうる。原典が手法に付けていた適用条件が要約から落ちることと、原典に無い情報が要約に足されることである。後者は、要約の木を作るRAPTORが実際に測っている⁶。

gistは取り込みの段の運用を利用者に委ねている。著者自身は資料を「一つずつ取り込み、関与を保つ」ほうを好み、要約を読み、更新を確かめると書く一方で、監督の薄い一括取り込みも選べるとしている¹。wikiの健全性検査（lint）を定期的に回すことは、操作の一つとして設計に含めている。取り込みの段で人間が要約を読むのは、著者が好む運用であって、設計が課す条件ではない。一括取り込みを選んでその読みを省けば、落ちた条件と足された情報は、要約だけを読む限りは見分けがつかない。

要約を先に作る側の研究がこれをどこまで測っているかは、研究ごとに違う。RAPTORは生成した要約150ノードを人手で注釈し、4パーセントにあたる6ノードが何らかの幻覚を含み、その多くは元の本文に無い情報を足すか、情報を誤って外挿するものだったと報告したうえで、その幻覚は上位層へ伝播せず質問応答の成績にも影響しなかったとする⁶。一方GraphRAGの評価基準は網羅性・多様性・読者への助けであり、論文は「忠実さ」を「大域的な全体把握には関係ない」基準として評価から外している⁷。

検索の側で利用者が行う作業

qmdの側にも、索引を作ったあとに利用者が行う作業がある。READMEは索引の更新について注意を明示している。「index.ymlの編集は、QMDがどのディレクトリとモデルを使うかを変えるが、それ自体では再索引しない」。path、pattern、ignoreを変えたらqmd updateを、models.embedを変えたらqmd embedを実行するよう求めている²。ただし、利用者が担うのはqmd updateを打つ判断であって、同期そのものではない。上流との同期は組み込まれていて、各コレクションのupdate欄に書いたコマンドが再索引の前に走る。READMEはこれを「組み込みの更新フック」と呼び、qmdを自分で包まなくても上流と同期が保てると書く²。設定ファイルを編集しても再索引が起きないのは、この同期とは別の話である。

既定の埋め込みモデルには言語の制約がある。READMEは、中国語・日本語・韓国語を含む多言語コーパスではembeddinggemma-300Mの網羅が限られると書き、既定を英語最適化と位置づけている。差し替えは環境変数QMD_EMBED_MODELで行うが、ベクトルはモデル間で互換ではないので、全コレクションをqmd embed -fで埋め直す必要がある²。日本語の資料にqmdを当てる読者は、索引を作る前にこの差し替えを検討することになる。

分割の仕方は、利用者が手を入れなくてもmarkdownに合わせてある。READMEによれば、qmdは見出し・段落・コードブロックの境目に点数を付け、約900トークンに近づくとその手前の範囲でいちばん点の高い境目で切り、15パーセントの重なりを付けて埋め込む。tree-sitterを使う構文木単位の分割はコードファイルにこの境目を足す仕組みで、READMEは「markdownとその他のファイル形式は、戦略にかかわらず常に正規表現ベースの分割を使う」と書く²。llm-wikiが生成するmarkdownのページにも、この方式が当たる。

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。