【ITニュース解説】LLM wiki vs. RAG: what each one is, and what I measured when I used a wiki as a RAG replacement (it was slower)

LLM（大規模言語モデル）の活用において、正確な情報に基づく回答を生成させるためのアプローチは多岐にわたる。本記事では、RAG（Retrieval-Augmented Generation）とLLM Wikiという二つの主要な手法の仕組みと、実際のコードベースでの利用実験から得られた知見を解説する。

RAGは、「検索拡張生成」と訳される技術だ。これは、LLMが質問に答える際に、事前に用意された大量の文書の中から最も関連性の高い情報を探し出し、その情報をLLMへのプロンプト（指示）に含めて回答を生成させる方法である。具体的な流れとしては、参照したい情報源（例えば、プロジェクトの仕様書や過去のドキュメントなど）を細かく分割し、「文書ストア」と呼ばれる場所に保存しておく。ユーザーが質問をすると、RAGシステムは質問の内容を理解し、この文書ストアの中から質問に最も適した情報のかけら（チャンク）を特定する。この特定には、キーワードだけでなく、情報の意味的な近さも考慮して特定される。そして、選ばれた情報がLLMに渡され、LLMはその情報に基づいて回答を生成する。RAGの重要な特徴は、文書ストアの内容は基本的に固定されており、LLMが新しい情報を書き込んだり、学習内容を更新したりすることはない点だ。常に元の文書ストアから情報を検索し、回答に利用する。エージェントがgrepのようなシェルツールを用いてソースを直接読み解き、回答を探す「エージェント検索」もRAGの派生形である。

一方、LLM Wikiは、RAGとは異なるアプローチをとる。これは、LLMを搭載したAIエージェントが、Markdown形式のページを自ら作成し、維持・管理するシステムである。LLM Wikiでは、プロジェクトの重要な概念、過去の意思決定、各モジュールの機能など、様々な情報がそれぞれのページにまとめられる。それぞれの情報には、ファイル名、行番号、変更ログ、会話履歴といった具体的な情報源が明確に記載される。さらに、関連するページ同士は内部リンクで結びつけられており、エージェントはこれらを読み解くことで、より深い知識を得ることができる。LLM Wikiの最大の特徴は、エージェントが質問に回答する際、もしWikiページだけでは情報が不足していると判断した場合、元のソースコードなどを読み込み、そこから得た新しい知識をWikiページに書き戻して更新する点だ。つまり、RAGが「すでに書かれているものを検索する」システムであるのに対し、LLM Wikiは「知識を自ら学び、記録し、更新していく」システムであり、特に「なぜその決定がされたのか」といった、ソースコードには直接書かれていないような「意思決定の背景」を記録できる点が大きな違いとなる。

今回行われた実験では、約1200行の小規模なPythonライブラリを対象に、開発者が実際に尋ねるような4つの質問について、Wikiなし（エージェントが直接ソースコードを読む方法）とWikiあり（Wikiを介して質問する方法）の二つのパターンで、回答にかかる時間、費用、正確さを比較した。

最初の4つの質問に対する結果は非常に興味深いものだった。Wikiなしの場合、エージェントはソースコード、変更履歴、ドキュメントを直接読み込み、平均で1質問あたり約31秒、$0.48の費用で、すべての質問に正確に回答した。しかし、Wikiありの場合では、まずWikiを構築するのに約8分間と$4.23の事前費用がかかった。そして、構築されたWikiを使って最初の4つの質問に回答させたところ、1質問あたり平均約48秒、$0.65の費用がかかり、Wikiなしの場合よりも55%遅く、34%費用がかかる結果となった。これは、Wikiのページだけでは情報が不足している場合、エージェントが再度ソースコードを読み込み、学習した内容をWikiに書き戻す作業が発生するためだ。たとえWikiが新しい知識を書き戻した後、同じ質問を再度実行したとしても、Wikiは回答の信頼性を確保するために、Wikiに記載された情報が本当に正しいかをソースコードで再確認するステップを踏む。この検証ステップがあるため、小規模なコードベースでは、ソースを直接読む方法と比べて、速度や費用の面で大きな改善は見られなかった。つまり、今回の小規模なプロジェクトにおいては、RAGや直接ソースを読む方が、Wikiを構築し運用するよりも、時間も費用も少なく済むという結果になった。Wikiの構築費用は、この規模のライブラリでは決して回収できない、という結論が出ている。

しかし、実験はさらに進み、5番目の質問でLLM Wikiの真価が示された。この質問は、「チームがコードレビューで決定した、ソースコードには直接書かれていない運用ポリシー」に関するものだった。例えば、「アプリケーションではシークレットキーを最大3つ保持し、30日ごとに最も古いキーを破棄する」といった、コードには記述されない「なぜそうするのか」という意思決定の背景に関する情報だ。この情報をWikiに記録した上で両者に質問したところ、Wikiなしのエージェントは「ソースにはこの質問に対する回答がない」と答えた。一方で、事前にcaptureコマンドを使ってこの意思決定をWikiに記録しておいたWikiありのエージェントは、この質問に正確に、そして迅速に回答することができた。Wikiにこの決定を記録するのにかかった時間は約34秒、$0.57の費用だったが、一度記録すれば、次に同じ質問がされたときに、LLM Wikiは過去の意思決定の背景も含めて回答できるようになった。これは単なるパフォーマンスの差ではなく、「回答できるか、できないか」という根本的な違いを示している。RAGやエージェント検索は「書かれているもの」しか検索できないのに対し、LLM Wikiはチームの会議やレビューで決まった「書かれてはいないが重要な意思決定」も記録し、共有できる点が最大の利点である。

これらの実験結果から、RAGとLLM Wikiの使い分けに関する明確な推奨事項が見えてくる。

RAGや、RAGに似たエージェントによる直接検索は、次のような場合に特に有効だ。回答が既存のソースコード、APIドキュメント、仕様書など、安定していて明確に書かれた情報源の中にある場合。参照する情報量（コーパス）が非常に大きく、ほとんど更新されない読み取り専用の性質を持つ場合。この場合、効率的な検索インデックスを持つRAGが力を発揮する。知識を修正したり、新しい情報を書き込んだりする必要がなく、単に既存の情報を素早く見つけられればよい場合。

一方で、LLM Wikiは次のような場合に大きな価値を発揮する。プロジェクトに関する知識が、ソースコードだけでなく、開発者の頭の中、コードレビューの議論、インシデントレポート、チャットでのやり取りなど、様々な場所に分散しており、特に「なぜそのような設計や決定がなされたのか」という背景情報が重要になる場合。同じプロジェクトについて、AIエージェントに何度も質問し、セッションをまたいでエージェントに学習内容を記憶・継続させたい場合。すべての主張に情報源が明記され、変更履歴が記録され、バージョン管理システム（Gitなど）で管理されるような、厳密な監査証跡が必要な場合。

非常に大規模なプロジェクトにおいては、RAGとLLM Wikiの両方を併用することが最も効果的かもしれない。Wikiを意思決定や知識の合成に使い、RAGをそのベースとなる生の資料（大量のコードやドキュメント）の検索に使う、というように役割を分けるのだ。Wikiが保持する生の資料を格納するディレクトリは、まさにRAGがインデックスを作成する対象となり得るため、両者は競合するものではない。

ただし、LLM Wikiを既存の情報源に対する「キャッシュ」として、つまり検索を速くするためだけに使おうとするのは適切ではない。今回の実験が示す通り、その目的ではWikiの構築コストと検証コストがメリットを上回ってしまう。Wikiは、検索速度だけでなく、意思決定の記録や知識の蓄積・更新といった、RAGでは代替できない独自の価値を提供するツールとして理解すべきだ。

最後に、実験で明らかになったいくつかの予想外の点についても触れておく。LLM Wikiの問い合わせコマンドは、回答を生成する際に、たとえWikiページに情報があっても、その情報が本当に正しいかを確認するために必ず元のソースを参照するステップを踏んでいた。これは正確性確保のために重要だが、小規模なプロジェクトでは速度的なメリットが得られなかった一因である。もし速度を最優先するなら、Wikiのページを信頼してソース参照を省略するような別コマンドが必要になるだろう。また、Wikiの構築プロセスは完全に決定論的ではないことも分かった。同じプロンプトとコードベースを使っても、別の日に実行すると、生成されるページの数や内容にわずかな違いが生じることがあった。これはLLMの挙動にランダム性が伴うためで、品質指標とする場合は単一の実行結果に依存せず、繰り返し確認が重要だ。