Tech

ナレッジ蓄積再考: とりあえず LLM Wiki で始めてよいのでは

2026年10月22日

仕事で必要になりそうなので、「継続的ナレッジ蓄積」周辺を今一度調べて整理してみました。既存のプロダクトや主要な手法に加えて、最近の論文の傾向を広く検索したあと、AI と対話しながら、自分なりに理解を深めました。

ナレッジ蓄積というと GraphRAG 系と LLM Wiki 系という印象があり、この二つを深掘りしてみたところ、意外と類似点が多いことに気づいたので、そのメモを置いておきます。比較しながら、GraphRAG 系、LLM Wiki 系、共通の課題、どちらを選ぶか、の順に見ていきます。

調べ終わった今の理解を先に書きます。

GraphRAG も LLM Wiki も、生データを LLM で「蒸留」して、一段上の知識表現を作る、という点では同じなのではないかという理解をしました。違うのは、蒸留したものの構造（エンティティ・関係エッジ・コミュニティで構造化された Graph か、ディレクトリ構造・目次ページ・文章間の相互リンクで整理されている Wiki か）です。
両者は、似たような問題にぶつかっています。生成した知識の誤り、時間がたつと古くなること、出典がわからなくなること、事例特有の評価が難しいこと、あたりです（詳しくは「共通の課題」に書きました）。蒸留データ層を厚くするか薄くするか（元データへの参照をどの程度使うべきなのか）は特に気になって調べてみましたが、はっきりした答えは見つかりませんでした。

以下は「私の目にはそう見えた」という整理です。間違っている点があれば、ご指摘ください。

GraphRAG 系: 全体を見るために、先に要約を作る

2023年: Vector RAG。 文書を分割し、質問と意味的に近いものを取ってくる方式が広まりました。一方で、固有名詞やコードに弱いといった弱点も見えて、従来の検索と組み合わせる Hybrid Search が一般的になりました。
2024年4月: GraphRAG。 Microsoft Research の論文「From Local to Global」です。ベクトル RAG は、「この文書群全体の主要テーマは？」のような、全体についての問いに弱い、という問題がありました。GraphRAG は、生データから LLM で Entity と Relation を抜き出して、Graph にした上で、さらにコミュニティ（関連の強いまとまり）に分けて、要約を事前に作ることで、全体の問いに答えられるようにしました。
2024年10月: LightRAG。 HKUDS という香港大学のグループの論文で、AI・NLPのトップカンファレンスである EMNLP 2025 の Findings に採択されています。従来の RAG は、データが平らな表現で、文脈をつかみにくいという問題がありました。LightRAG は、テキストの索引と検索に Graph を取り入れつつ、Graph とベクトル検索を組み合わせて、個別の事実と全体の話題の2段階で検索します。新しいデータを足すときに全体を作り直さない、差分更新も特徴です。
2024年11月: LazyGraphRAG。 同じく Microsoft による改善版です。GraphRAG は Entity と Relation の抽出に LLM を大量に使うので、インデックスの作成が高価なことが課題でした。LazyGraphRAG は、LLM の利用を問いのときまで遅らせて、索引では、名詞句の抽出のような軽い処理だけをします。Microsoft のブログでは、索引のコストはベクトル RAG と同じ、フル GraphRAG の 0.1% だと述べています（自己申告の数字です）。
2026年1月: Relink。 AAAI という AI 系トップカンファレンスに採択された論文です。従来の Graph が静的なこと・不完全なこと・関係のない事実が混ざること（ノイズ）を問題視し、「推論しながら、問いに必要な部分の Graph だけをその場で作る」方式を提案しました。足りない事実は原文から補い、邪魔な事実は捨てます。前述の蒸留データ層を薄くする方向の研究です。

検索のしかたの側でも、変化がありました。2025〜2026年ごろから、検索を1回で終わらせず、エージェントが、検索して、読んで、考えて、また検索する、を繰り返す Agentic Search が広まっています。これは GraphRAG の進化ではなく、検索を多段階にする、という話で、その下にある検索は、単純な grep でも、Hybrid Search でも、GraphRAG でもかまいません。

では、その下の検索は GraphRAG である必要があるのか。実はこれを評価した論文があって、「Do We Still Need GraphRAG?」（2026年4月）です。arXiv の未査読の論文で、引用数も少ないですが、中身が興味深く評価も再現性のありそうなものだったのでご紹介します。GraphRAG と単純な RAG に、それぞれ Agentic Search をさせて比べています。差はかなり縮まりますが、複雑な多段階の推論（1つ目の検索結果を鍵にして、2つ目・3つ目の関連文書を繋ぎ合わせないと解けない質問）では、GraphRAG に利点が残る、という結論でした。

LLM Wiki 系: 人が読める Wiki を、LLM と育てる

2026年4月: LLM Wiki。 Andrej Karpathy が GitHub Gist で提案した考え方です。LLM が生データを読んで、人間とエージェントが読める Markdown の Wiki を作り、これを育て続けます。構成は、書き換えない生データ、LLM が管理する Wiki、規約を書くファイル（CLAUDE.md や AGENTS.md のようなもの）の3層で、操作は、取り込み（ingest）、質問（query）、全体の点検（lint）の3つ、と説明されています。普通の RAG が「質問のたびに、毎回生データから知識を再発見している」ことへの対案であり、GraphRAG よりもあとに出たコンセプトですがこれに対する言及はありません。
2026年6月: Google の Open Knowledge Format（OKF）v0.1。 LLM Wiki のパターンを、複数のツールでやりとりできる形式に標準化したものです。Google Cloud のブログによると、AI エージェントに必要な文脈が、メタデータカタログ、Wiki、共有ドライブなどに散らばり、ベンダーごとに形式も違う、という問題が出発点でした。形式は単純で、1つの概念を1つの Markdown ファイルにして、先頭の YAML（frontmatter）に type、title、description、resource、tags、timestamp を書きます。必須なのは type だけで、概念どうしは普通の Markdown のリンクでつなぎ、全体が Graph になります。LLM Wiki の「ディレクトリとリンク」を、そのまま仕様にしたものです。出典は、本文の Citations に書く程度でした。
2026年7月: OKF v0.2。 v0.2 のブログの問題意識は、エージェントが書いた知識には、人が書いた知識のような「誰かが責任を持つ」という暗黙の保証がない、というものです。そこで、「何から作ったか（provenance）」「どれくらい信頼できるか（trust）」「まだ正しいか（freshness）」「最新版か（lifecycle）」「その数字は決められた方法で作られたか（attestation）」に答えるための項目が追加されました。具体的には、sources（元資料と、著者や参照回数などの客観的な信号）、generated と verified（作った主体と、確認した主体を分ける）、status（draft → stable → deprecated）、stale_after（この日を過ぎたら古いとみなす日付）、そして、決められた計算が実行されたことを機械的に検査する Attested Computation という型です。信頼度のスコアは、あえて入れていません。スコアは主観的で、使う側によって違い、書いた瞬間から古くなる、と説明されています。

共通の課題: 蒸留した以上、どちらも同じ壁にぶつかる

以下の課題に対しては、双方でメタデータを足す対策が取られています。上記では省略しましたが、GraphRAG も Node や Edge にメタデータを足しています。たとえば Microsoft の GraphRAG は、関係（Edge）に、元の文章の塊への参照（text_unit_ids）を持たせています。claims には、確からしさ（status）や期間（start_date、end_date）もあります（公式ドキュメント）。LightRAG も、Entity や Relation に元の文書の塊やファイルを紐づけ、2025年3月に出典表示（citation）に対応しました。

生成した要約や知識が間違っている。
時間がたつと古くなる。更新や差分の反映が難しい。
出典や根拠がわからなくなる。

この他にも、以下のような課題があります。

元のデータの細かい情報が落ちる。
事前の処理が重い。
将来どの情報が必要になるかは、作る時点ではわからない。
事例特有の評価が難しい。

特に厄介なのは、間違いが残り続けることです。蒸留層に間違ったデータがあると、その誤りが、以後の検索のたびに事実として使われます。

どちらを選ぶか: 小さく始めるなら LLM Wiki だと思う

では、どちらを選ぶのかですが、調査を進めていると私なりの判断軸が見えてきました。

まずデータの規模です。LLM Wiki 系は、文書量が多くなると、Wiki 全体の整合性を担保する操作の質やコストが不安定になるのではと考えています。Karpathy 自身も、約100ソース・数百ページ程度の規模でうまく動き、大きくなったら本格的な検索を足す、と書いています。次に、改善を回しやすいかです。Wiki は Markdown なので、人が読めて直せます。そして、複雑さです。GraphRAG はインデックスの構築やデータの表現形式も含め、仕組みが複雑です。

小さく始めて改善ループをまわす、という観点では LLM Wiki 系が有利だと思います。データ量が多く関係も複雑な場合に、GraphRAG の検討が必要になるのではと考えています。

ただ、改善ループには人のレビューが要ります。私も LLM Wiki を運用していますが、レビュー対象をコア部分だけの最小限に削っても、読むのが追いつきません。かといって、情報密度を高くする方向にプロンプトを調整すると内容が理解できなくなります。指示するだけで質問に答えてくれない上司みたいになっちゃってます。

最後に、面白いものをご紹介。2026年8月に、OSS の RAG である RAGFlow（GitHub のスターは約9.3万。比較として Dify は約15.9万、2026年10月時点）が、Knowledge Compilation という機能を出しました。生データから、Graph や Wiki に加えて、Tree、Mindmap など様々な形式の蒸留データを作れるようにした機能です。

こういった、蒸留層の表現の組み合わせや切り替えのコストが低くなるような技術を採用するのも重要なのかもな、と考えさせられました。

コメント (0)

まだコメントはありません。最初のコメントを投稿しましょう！