「とりあえずRAG」を疑う。ユースケースから見直すナレッジ活用の設計

RAG（Retrieval-Augmented Generation、検索拡張生成）は強力な技術ですが、「とにかく入れれば解決する」という誤解が定着しつつあります。適切な使い分けの視点を持たないまま導入しても、限界にすぐ突き当たります。

RAGという言葉は、Patrick Lewis らが2020年のNeurIPS（機械学習の主要国際会議）で発表した論文「Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks」に由来します。事前学習済みの言語モデルに対して、外部の知識ベース（当初はWikipedia）から関連文書を検索して結合することで、知識集約型のタスク精度を向上させる手法として提案されました。この「検索して生成する」という構造が汎用性を持つことから、現在では社内文書を対象にした企業向け実装として広く普及しています。

問題は、その普及の速さとは裏腹に、RAGが本来「検索で解ける業務」に限定された技術であることが見落とされがちな点です。RAGの相談を受けるとき、まず確認するのは「その業務の答えは、すでにどこかの文書に書いてあるか」という一点です。

RAGが有効に機能するのは、知識の参照を求める業務です。社内規程の照会、製品仕様の確認、過去の問い合わせ事例の検索——「答えが文書として存在する」構造であれば、ユーザーの問いを検索クエリに変換し、関連文書を取得し、その内容を根拠に回答を生成するサイクルが機能します。ここにRAGの本来の強みがあります。

一方、「判断」「突合」「実行」を要求する業務はRAGだけでは解決しません。申請内容が複数の条件を同時に満たすかを判断する業務、複数システムのデータを照合して差異を検出する業務、基幹システムに対して操作を実行する業務——これらは検索の問題ではなく、ロジックとツール呼び出しの問題です。RAGを入れれば解決するように見えて、実際には別のアーキテクチャが必要になります。

もう一つ軽視されやすいのが、「RAGの前に文書整理が必要な業務」です。検索精度は文書の品質に直接依存します。旧版と新版が混在している、同一内容が複数ファイルに分散している、表形式のデータが画像として保存されている——こうした状態の文書群に対してRAGを構築しても、ノイズが多く実用的な精度に達しません。文書の整理・統廃合・メタデータ付与が先行しなければ、システムを入れても意味がありません。

長文脈（ロングコンテキスト）モデルとの使い分けについても触れておく必要があります。2024年以降、数十万から百万トークン規模のコンテキストを扱えるモデルが登場し、「RAGは不要になる」という議論が起きました。しかし実測では、長文脈モデルはリコール（情報の取りこぼし）が文書量の増大とともに低下し、最大40%の情報を見落とす可能性があるとされています。加えて、コスト・レイテンシ・動的な文書更新への対応という観点では、大規模かつ頻繁に更新されるドキュメント群にはRAGが依然として有利です。業界の現在の多数意見は「万能解はない。モデル・コンテキストサイズ・タスク・検索特性によって使い分ける」に収束しています。

RAGを否定したいわけではありません。適切な業務に適切に実装すれば、RAGは企業の知識活用を大きく変えます。問題は「検索で解ける構造かどうかを確認しないまま実装する」ことにあります。業務を「検索で解ける」「判断・突合・実行が必要」「文書整理が先決」の三つに仕分け、さらに長文脈モデルとの使い分けを含めた設計の視点を持つことが、データ運用のベストプラクティスの出発点です。

参考

• Patrick Lewis et al., "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks," NeurIPS 2020. https://arxiv.org/abs/2005.11401
• Qdrant: "Is RAG Dead? Why Long Context Windows Don't Replace RAG" https://qdrant.tech/articles/rag-is-dead/
• Databricks: "Long Context RAG Performance of LLMs" https://www.databricks.com/blog/long-context-rag-performance-llms