LLM Wikiとqmd。知識を編纂するか検索するかの二つの設計

Andrej Karpathy, “llm-wiki.md”（GitHub gist, 2026年4月4日公開）。「LLMを使って個人の知識ベースを構築するためのパターン」と自ら述べ、「これはアイデアファイルであり、自分のLLMエージェント（OpenAI Codex、Claude Code、OpenCode / Piなど）にコピー＆ペーストして使うよう設計されている」と明記する。既存のRAGについて「ファイルの集まりをアップロードし、LLMが質問時に関連する断片を取得して答を生成する。これは働くが、LLMは質問のたびに知識をゼロから再発見している。蓄積が無い」と書き、代わりに「LLMが永続的なwikiを漸進的に構築し維持する」形を提案する。「知識は一度編纂され、そして現行に保たれる。問い合わせのたびに再導出されるのではない」「これが鍵となる違いだ。wikiは永続的で複利的に積み上がる成果物である」。三層は生の資料（「これらは不変であり、LLMは読むが決して変更しない」）、wiki、スキーマ（CLAUDE.mdやAGENTS.md）。操作はIngest / Query / Lintの三つで、Lintでは「ページ間の矛盾、より新しい資料に置き換えられた古びた主張、入リンクの無い孤立ページ、言及されているが独自のページを欠く重要概念、欠けた相互参照、Web検索で埋めうるデータの穴」を定期的に探させる。規模については索引ファイル方式が「およそ100件の資料、数百ページという中規模で驚くほどうまく働き、埋め込みベースのRAG基盤を不要にする」と書く。qmdを名指しで推薦し「wikiのページに対する検索エンジンが最もわかりやすい。小規模では索引ファイルで足りるが、wikiが育つと本格的な検索が欲しくなる。qmdは良い選択肢だ。markdownファイルのためのローカル検索エンジンで、BM25とベクトルのハイブリッド検索とLLMによる再ランクを、すべて端末上で行う」と述べる。維持コストについて「知識ベースを維持するとき面倒なのは読むことでも考えることでもない。事務作業のほうだ」「人間がwikiを放棄するのは、維持の負担が価値より速く増えるからだ」と書き、続けて「LLMは退屈しないし、相互参照の更新を忘れないし、一度に15のファイルに触れる。wikiが維持され続けるのは、維持の費用がほぼゼロだからだ」と結ぶ。取り込みの節では「一つの資料が10〜15のwikiページに触れうる」としたうえで、「個人的には資料を一つずつ取り込み、関与を保つほうを好む。要約を読み、更新を確かめ、何を強調するかをLLMに導く」と書き、監督の薄い一括取り込みも選べるとしている。推薦が置かれた節の見出しは「任意のCLI道具」で、推薦文の直後に「もっと単純なものを自分で作ってもよい。必要が生じたときに、素朴な検索スクリプトをLLMと一緒に書けばよい」と続く。文書自身が「この文書は意図的に抽象的である。実装ではなくアイデアを記述している」と断り、末尾の注記で「上に挙げたものはすべて任意で組み替え可能である。役に立つものを選び、そうでないものは無視せよ」「wikiが十分に小さければ索引ファイルだけで足り、検索エンジンは要らない」と書いている。https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸

tobi/qmd, リポジトリとREADME（作成2025年12月8日、最終push 2026年8月18日、star 29,579件。いずれも2026年9月8日にGitHub APIで取得）。作者はTobi Lütke。説明文は「ドキュメント、知識ベース、議事録などのための小さなCLI検索エンジン。すべてローカルで動かしながら現在のsotaな手法を追う」。検索経路について「型付き展開は排他的に振り分けられる。lexはBM25/FTSへ、vecとhydeはベクトル検索へ。元のクエリは両方のバックエンドへ送られ、RRFで融合されて再ランクされる」。融合手順は、クエリ展開（原クエリを重み2倍、LLMによる変形を1つ）、並列取得（各クエリがFTSとベクトル索引の両方を引く）、RRF融合（score = Σ(1/(k+rank+1))、k=60）、上位順位ボーナス（いずれかの一覧で1位なら+0.05、2〜3位なら+0.02）、上位30件の選択、LLMによる再ランク（yes/noとlogprobsによる確信度）、位置を考慮した混合（RRF1〜3位は検索75%と再ランク25%＝「完全一致を保つ」、4〜10位は60%と40%、11位以降は40%と60%で「再ランクをより信頼する」）の7段。この設計の理由は README 自身が手順の直後に書いている——「なぜこの方法か: 純粋なRRFは、展開したクエリが一致しないときに完全一致を薄めうる。上位順位ボーナスは、元のクエリに対して1位を取った文書を保つ。位置を考慮した混合は、再ランクが確信度の高い検索結果を壊すのを防ぐ」。ローカルのGGUFモデルは「GGUF Models (via node-llama-cpp)」節の表に三つ挙がっており（埋め込み・再ランク・クエリ展開）、初回利用時にHuggingFaceから自動取得され~/.cache/qmd/models/にキャッシュされる。既定の埋め込みモデルについては別に「多言語コーパス（中国語・日本語・韓国語など）ではembeddinggemma-300Mの網羅が限られる」と書き、対応モデル族は二つで、既定のembeddinggemmaは英語最適化で設置面積が小さく、Qwen3-Embeddingは多言語（CJKを含む119言語）に対応すると並べる。差し替えはQMD_EMBED_MODEL環境変数で行い、「ベクトルはモデル間で互換ではないのでqmd embed -fで再索引しなければならない」と注記する。索引の更新について「index.ymlの編集はQMDが使うディレクトリとモデルを変えるが、それ自体では再索引しない。path、pattern、ignoreを変えたらqmd updateを、models.embedを変えたらqmd embedを実行せよ」と注記する。再ランクへ回す上位30件という数は融合手順の散文とASCII図に一致するが、同じREADMEのMCPツールのパラメータ表とCLIの--candidate-limitは上限を既定40と書いており、原典の中でこの数は揃っていない。コレクションのupdate欄は「QMDに組み込まれた更新フック」であり、qmd updateを実行すると各コレクションのupdateコマンドが先に走ってから再索引される（設定例はpath: ~/reference/wikiとupdate: "git pull --ff-only"）。分割については「構文木を意識した分割（--chunk-strategy auto）はtree-sitterを使い、コードファイルを関数、クラス、インポートの境界で分割する」一方で「markdownとその他のファイル形式は、戦略にかかわらず常に正規表現ベースの分割を使う」と明記し、既定はregexである。埋め込みは900トークン/チャンク、15%の重なり。READMEが設定例として指すexample-index.yml（raw.githubusercontent.com/tobi/qmd/main/example-index.yml、HTTP 200 / 5,028バイト、2026年9月8日取得）には、path: ~/reference/wikiとupdate: "git pull --ff-only"を持ち、patternが配下のmarkdownを再帰的に拾うglobであるwikiコレクションがあり、そのcontextは「外部のwiki。qmd updateのたびに自動で取得される」。同ファイルのglobal_contextは「関連する[[WikiWord]]を見かけたら、そのWikiWordを検索してさらに文脈を得られる」である。https://github.com/tobi/qmd ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸

Darren Edge, Ha Trinh & Jonathan Larson, “LazyGraphRAG: Setting a new standard for quality and cost”, Microsoft Research Blog（2024年11月25日公開。2025年6月6日付の編集注は、この技術がMicrosoft DiscoveryとAzure Localに統合されたと記す）。冒頭で「本稿では、資料の事前要約を必要とせず、利用者や用途によっては法外になりうる前払いの索引費用を避ける、根本的に異なるグラフ利用RAGの手法を紹介する」と書く。「LazyGraphRAGのデータ索引費用はベクトルRAGと同一で、完全なGraphRAGの費用の0.1%である」。⚠ その直後の2文が、質問時の費用も下がったと報告している——「ベクトルRAGと同等の質問費用で、LazyGraphRAGは局所的な問いにおいて、長文脈ベクトルRAGやGraphRAGのDRIFT検索、GraphRAGの局所検索を含む競合手法のすべてを上回る」「同じLazyGraphRAG構成は、大域的な問いについてGraphRAGの大域検索と同等の答えの品質を示すが、質問費用は700倍以上低い」。比較表は要約索引の段を「無し——『lazy』な手法はLLMの使用をすべて質問時まで遅らせる」と記す。「全体の性能は一つの主パラメータ、関連性検査の予算（relevance test budget）で調整でき、費用と品質のトレードオフを一貫した形で制御する」。⚠ 数値は同グループ自身の測定で、第三者の再現ではない。留保として引く理由: 索引時のLLMの手間を質問時へ遅らせた設計だが、原典は質問時の費用も同時に下がったと報告している。∴ この出典が示すのは手間の移動ではなく両方の時点での減少であり、本稿の「手間は消えず、置き場が移る」という見立てを、そのままは支えない。https://www.microsoft.com/en-us/research/blog/lazygraphrag-setting-a-new-standard-for-quality-and-cost/ ↩ ↩² ↩³

P. Sarthi, S. Abdullah, A. Tuli, S. Khanna, A. Goldie & C. D. Manning, “RAPTOR: Recursive Abstractive Processing for Tree-Organized Retrieval”, ICLR 2024（poster。OpenReview id GN921JHCRw で採択を確認）。arXiv:2401.18059（2024年1月31日投稿、v1のみ）。所属はStanford University。要旨は「文書の断片を再帰的に埋め込み、クラスタリングし、要約して、下から上へ異なる要約水準を持つ木を構築する」手法を提案し、「推論時に、RAPTORモデルはこの木から取り出し、長い文書の情報を異なる抽象度で統合する」と書く。「複雑な多段推論を要する質問応答課題で最先端の結果を示す。たとえばRAPTORの検索をGPT-4と組み合わせると、QuALITYベンチマークの最良成績を絶対精度で20%改善できる」。QuALITYについて本文は「平均およそ5,000トークンの文脈を伴う選択式の問題からなる」データセットと説明する。費用について本文は「システムは構築時間とトークン消費の両方で線形にスケールする」と書き、付録Aは「家庭用のラップトップ、具体的には16GB RAMのApple M1 Mac」で「文脈長を12,500から78,000トークンまで変え」て木の構築のトークン消費と所要時間を測ったと記録し、図5の説明は「RAPTORの木の構築費用は各データセットで文書長に対して線形にスケールする」。付録Eは要約の幻覚を測っている。「RAPTORモデルの要約の質と正確さを評価するため、生成された要約における幻覚に焦点を当てた分析を行った」とし、要約はgpt-3.5-turboが生成したもので、「40作品にわたる150ノードを無作為に抽出し、幻覚について評価した。各ノードは人手で注釈し、幻覚を含むかどうかを判定した」。結果は「抽出した150ノードのうち4%（6ノード）が何らかの形の幻覚を含んでいた。最も多かったのは、要約対象の本文に無い情報を、おそらく訓練データから、モデルが少量付け足すもの、あるいは要約を作る際に情報を誤って外挿するものだった」。続けて「すべての親ノードを見直したところ、幻覚は上位層へ伝播していないことが分かった」「我々の知見では、幻覚は質問応答課題の成績に識別できる影響を与えなかった」。本文6.1節も「約4%の要約が軽微な幻覚を含んでいたが、これらは親ノードへ伝播せず、質問応答課題に識別できる影響を与えなかった」と要約する。留保として引く理由: 要約を先に作る側の利得が手間の置き場ではなく精度の差として報告されており、編纂と検索を「どちらに手間を置くか」だけで並べる本稿の枠を狭める。あわせて、編纂で原典に無い断定が足されるという本稿の懸念を、この論文は測ったうえで軽微だと報告している。https://arxiv.org/abs/2401.18059 ↩ ↩²

D. Edge, H. Trinh, N. Cheng, J. Bradley, A. Chao, A. Mody, S. Truitt, D. Metropolitansky, R. O. Ness & J. Larson, “From Local to Global: A Graph RAG Approach to Query-Focused Summarization”, arXiv:2404.16130（2024年4月24日投稿、v2は2025年2月19日。査読誌・会議への掲載は確認できていない＝プレプリントとして引く。著者はMicrosoft所属）。要旨は「RAGは『データセットの主題は何か』のようなコーパス全体に向けた大域的な問いには失敗する。これは本質的に、明示的な検索の課題ではなく、質問に焦点を絞った要約（QFS）の課題だからである」と書き、「我々の手法はLLMを使って二段階でグラフ索引を構築する。まず資料から実体の知識グラフを導出し、次に密接に関連する実体のすべてのグループについてコミュニティ要約をあらかじめ生成する」「100万トークン規模のデータセットに対する大域的な全体把握の問いのクラスについて、GraphRAGが従来のRAGベースラインに対し、生成された答えの網羅性と多様性の両方で大幅な改善をもたらすことを示す」。評価基準は網羅性・多様性・エンパワーメント（読者が理解し判断するのをどれだけ助けるか）と、統制用の直接性の4つ。同じ節で「文脈の関連性」「忠実さ」「答えの関連性」は「ベクトルRAGシステムに一般的な基準で、大域的な全体把握には関係ない」として評価から外している。⚠ 網羅性・多様性の比較は、著者らが自ら設計した基準にLLM審判（LLM-as-a-judge）を当てた同グループ自身の測定である。原典は「評価の金標準が無いので、ある基準についての相対的な性能は、競合する二つのモデルの生成をLLMに比較させることで定量できる」と書き、そのうえで「本研究では大域的な全体把握の問いへのRAG回答を評価する基準を設計し、比較の手法で結果を評価する」と述べる（別途「LLMが抽出した検証可能な事実の記述、すなわち『主張』から導いた統計でも結果を検証する」とも書く）。留保として引く理由: 先に編纂することの利得が、手間の置き場ではなく答えられる問いの範囲の差として報告されている。https://arxiv.org/abs/2404.16130 ↩ ↩²

Anthropic, “Introducing Contextual Retrieval”（2024年9月19日公開）。「Contextual Retrievalは、埋め込みの前（Contextual Embeddings）とBM25索引の作成前（Contextual BM25）に、断片固有の説明的な文脈を各断片の前に付けることでこの問題を解く」。「この手法は検索の失敗の数を49%減らし、再ランクと組み合わせると67%減らせる」。内訳は「上位20断片の検索失敗率」で、Contextual EmbeddingsとContextual BM25の組み合わせで5.7%から2.9%（49%減）、再ランクを加えると1.9%（67%減）。文脈の生成にはClaude 3 Haikuを使う。費用の見積もりはプロンプトキャッシュを前提に置いたもので、原典は「プロンプトキャッシュがあれば、断片ごとに参照文書を渡す必要はない。文書を一度キャッシュへ読み込み、以後はキャッシュ済みの内容を参照するだけでよい」と述べたうえで、「800トークンの断片、8kトークンの文書、50トークンの文脈指示、断片あたり100トークンの文脈を仮定すると、文脈付き断片を生成する一度きりの費用は文書100万トークンあたり1.02ドル」と見積もる。⚠ 数値は同社自身の測定で、第三者の再現ではない。支持として引く理由: 索引時にLLMの仕事を置く設計に、前払いの費用が値段として付いている。https://www.anthropic.com/news/contextual-retrieval ↩