AIDBでは日々、AIの最新研究を紹介しています。本記事は初めてRAGに触れる方から、実務での活用を検討している方まで、幅広くお読みいただける企画の一部です。
今回は、「RAG」という技術そのものについて、あらためて包括的に理解が進むことを目指した内容をお届けします。
はじめに
ChatGPTをはじめとするLLMが業務に浸透する中、ある重要な課題が浮上しています。「LLMが知らない情報について、どうやって正確に答えさせるか」という問題です。
LLMは膨大なテキストデータで学習されていますが、学習時点より後の情報は知りません。また、企業の社内文書や個人のメモといった、学習データに含まれていない情報についても答えることができません。さらに、学習した内容であっても、事実と異なる内容をもっともらしく出力してしまう「ハルシネーション」と呼ばれる現象も起こります。
こうした課題への解決策として広く使われているのが「RAG（Retrieval-Augmented Generation）」という技術です。日本語では「検索拡張生成」と訳されることもあります。外部のデータベースから関連情報を検索し、それをLLMに渡して回答を生成させる仕組みです。
RAGは現在、企業で構築されているLLMシステムの約6割で採用されているとの報告もあります。しかし、日々発表される研究論文を追っていると、「検索して答えさせる便利な仕組み」という表面的な理解と、研究の最前線で明らかになっている実態との間には、少し差があることに気づきます。
本記事では、AIDBが日々追っている最新研究の知見をもとに、RAGの本質から実践的な導入・運用のポイントまで体系的に解説します。
そもそもRAGとは何か
RAGとは、ユーザーの質問に対して、まず外部のデータベースから関連する情報を検索し、その検索結果をLLMに渡すことで、より正確で最新の回答を生成させる技術です。
仕組みはシンプルです。たとえば「昨日発表された新しい法規制について教えて」と尋ねたとします。LLMは過去のデータで学習しているため、昨日の出来事は知りません。しかしRAGを使えば、最新のニュース記事や公式文書を検索し、その内容をLLMに読ませてから回答を生成することができます。
ChatGPTやClaudeなどに文書ファイルを添付して回答を生成させる機能を使ったことがある方も多いでしょう。あの機能もRAGの一種です（ただし一説によると、ChatGPTやClaudeは添付文書をそのままコンテキストに入れている可能性もあるとのこと）。
RAGの目標
RAGが目指すのは「必要な情報をしっかり拾い上げつつ、余計なものは混ぜないこと」です。
言い換えると、「見逃しを減らしたいけど、ノイズも減らしたい」ということになります。これを専門的には「網羅性（recall）」と「関連性（precision）」と呼びます。この2つはどちらかを高めるともう一方が下がりやすく、両立が難しいとされています。RAGでは、このバランスを取ることが設計上の大きな課題です。
RAGを構成する4つの基本モジュール
RAGの仕組みと役割を整理した調査では、RAGは次の4つのパートで構成されると説明されています。
インデックス（データに目印をつけて整理する）
最初に行うのは、大量の文書を検索しやすい形に整理しておく作業です。長い文章を短く区切り（これを「チャンク」と呼びます）、それぞれを数値に変換して類似性を比較できるようにします。この数値化のことを「埋め込み（embedding）」といいます。
ただし、文書を細かく分けると全体の流れが失われやすいですし、数値化されたベクトルだけでは因果関係などの複雑な意味を捉えるのが難しい場合もあります。
検索（ユーザーの質問に合うデータを探す）
ユーザーの質問を受け取ると、まずその質問を「検索に適した言葉」に書き換えます。あいまいな表現をわかりやすくしたり、長い質問を分割したりすることもあります。
その後、候補になりそうな文書を広く集めます。このとき、まずは高速に検索できる方法で候補を集め、あとからより深い意味を比較して精度を上げていく段階的なやり方がよく使われます。
生成（探した情報をもとにLLMが回答する）
検索してきた情報をもとにLLMが実際に文章を生成します。ここでは「プロンプトの設計」が重要になります。どの情報をどの順番で渡すか、どんな指示を与えるかで、LLMの出力が大きく変わるためです。
また、検索してきた情報に矛盾があるとき、LLMがどちらを信じるかも課題になります。モデルがもともと覚えていることと外部の情報が食い違ったときに、どう対応するかを工夫する必要があります。
オーケストレーション（全体の流れを調整する）
これまでの3つのパートをどんな順番でどう使うかを判断する役割です。簡単な質問なら検索を飛ばしてLLMに直接答えさせる選択もありえます。一方で、込み入った質問であれば、複数の情報を集めて何度も推論させるような処理が必要になることもあります。
RAGとファインチューニングの違い
LLMを業務に合わせて強化する方法には、大きく分けて2つのアプローチがあります。一つはRAG、もう一つは「ファインチューニング」と呼ばれる方法です。両者は補完的な関係にありますが、特性が大きく異なります。
ファインチューニングとは
ファインチューニングは、モデルそのものを追加学習させる方法です。特定の業務や分野に関するデータを使ってモデルの重みを調整し、その分野での性能を高めます。
この方法は効果が出やすい反面、いくつかの課題があります。まず、計算コストが高く、専門的な知識と環境が必要です。また、もともと備わっていた知識や得意分野が失われる「破滅的忘却」と呼ばれるリスクもあります。さらに、一度学習させた内容を更新するには、再度ファインチューニングを行う必要があります。
RAGの特徴
RAGはモデル自体を変更せず、入力文の工夫によって出力をコントロールする方法です。外部から検索してきた情報をプロンプトに含めることで、その場で必要な知識を与えます。
RAGの利点は、モデルを再学習させる必要がないため導入が比較的容易なことです。また、データベースを更新するだけで最新情報に対応できます。情報の出所を明示しやすいため、回答の根拠を示すことも可能です。
一方で、検索の精度に依存するため、関連する情報をうまく見つけられなければ回答の質も下がります。また、プロンプト設計に大きく左右されやすいという課題もあります。
どう使い分けるか
両者の使い分けについては、一般的に次のような考え方があります。
ファインチューニングが向いているのは、特定の文体やトーンを一貫して出力させたい場合、あるいは特定分野の専門用語や表現を自然に使わせたい場合です。モデルの「振る舞い方」を変えたいときに有効です。
RAGが向いているのは、最新情報や頻繁に更新される情報を扱う場合、あるいは社内文書や非公開データを参照させたい場合です。モデルが「何を知っているか」を拡張したいときに有効です。
実務では、両者を組み合わせて使うケースも増えています。「文脈を育てる」という発想を紹介した研究では、ファインチューニングなしでもRAGの工夫によってLLMの性能を向上させるアプローチが提案されています。失敗した回答の例を集めて共通するパターンを整理し、それを文脈として活用することで、追加学習なしに改善を図る方法です。
研究が明かすRAGの「今」
ここからは、最新研究から見えてきたRAGの実像を紹介します。「検索して答えさせる便利な仕組み」という表面的な理解を超えて、この技術が本当は何をしているのか、どこまでできてどこに限界があるのかを掘り下げていきます。
LLMは情報源によって信頼度を変える
RAGでは、検索によって複数の情報を集めてLLMに渡します。しかし、それらの情報が互いに矛盾している場合、LLMはどちらを信じるのでしょうか。
LLMの情報源バイアスを調べた研究では、興味深い発見が報告されています。13種類のオープンモデルを対象に実験を行った結果、すべてのモデルで「政府機関、新聞、個人、SNSユーザー」の順に情報を信頼するという一貫した階層構造が確認されました。
発行部数やフォロワー数といった人気指標も信頼性判断に影響を与える一方、学術称号や年齢の影響は限定的でした。
さらに興味深いのは、信頼性の低い情報源からの情報でも、繰り返し提示するだけでこの階層構造が逆転してしまうという発見です。これは人間に見られる「錯覚的真実効果」と類似した現象です。何度も目にした情報を真実だと思い込んでしまう傾向が、LLMにも存在するのです。
プロンプトで信頼性を意識させる指示を加えても完全には解消できませんでしたが、ファインチューニングによって繰り返しバイアスを大幅に削減できることが示されています。RAGシステムの設計において、検索結果の重複がLLMの判断を歪める可能性を考慮すべきという実務的な示唆を与える研究です。
ベクトル検索には理論的な限界がある
RAGで広く使われているのが、ベクトル検索（埋め込みベースの検索）です。文書や質問を数値ベクトルに変換し、類似度の高いものを探す方法です。しかし、この方法には根本的な限界があることがわかってきています。
ベクトル検索の限界を検証した研究では、埋め込みモデルの次元数と表現できる関連性パターンのあいだに数学的な上限があることが示されています。次元を増やせば表現の幅は広がりますが、クエリが求める組み合わせの爆発的な増加には追いつけません。
注目すべきは、この限界が大規模データだけの問題ではない点です。クエリが複数の条件を組み合わせるような構造を持つと、小規模なデータでも限界が現れることが実験で確認されています。
RAGの設計においてベクトル検索を万能視せず、スパース検索やリランキングと組み合わせたハイブリッド構成を検討する重要性を示唆しています。
同じ情報でもLLMによって有用性が異なる
RAGで取得した情報がLLMにとって本当に役立つかどうかは、実は使用するLLMによって異なる可能性があります。
LLMごとの情報有用性を検証した研究では、この「LLM固有の有用性」という新しい視点からRAGを見直しています。
短絡的に考えると、ある文書が有用であればどのLLMに対しても同じように役立つと思えます。しかし、LLMはそれぞれ異なる訓練データで学習されており、内部に持っている知識ベースが異なります。あるLLMにとっては新しく重要な情報でも、別のLLMにとってはすでに知っている冗長な情報かもしれません。
また、LLMごとに文章の理解能力や推論能力にも差があります。同じ文書を与えられても、あるLLMは十分に理解して活用できる一方で、別のLLMは内容を正しく解釈できず、かえって誤った回答につながる可能性もあります。
RAGシステムを設計する際に、使用するLLMの特性を考慮した検索戦略が必要であることを示唆しています。
長文コンテキストはRAGを置き換えるか
最近のLLMは、一度に処理できるテキスト量が飛躍的に増加しています。数十万から数百万トークンまで扱えるモデルも登場しました。
こうなると、「文書を細かく分けて検索する必要はなく、そのまま全部渡せばいいのでは」という疑問が生まれます。
20種類のLLMで長文コンテキストとRAGの関係を検証した研究では、この問いに取り組んでいます。
結論として、長文を読ませるやり方にも問題があることがわかっています。たくさんの情報を一度に扱うと、無関係なノイズが混ざりやすくなったり、計算に時間がかかりすぎたりします。また、長いテキストの中間部分の情報が保持・活用されにくい「迷子になる」現象も報告されています。
RAGと長文コンテキストは、それぞれの得意・不得意をふまえて使い分けるのが良いと考えられています。答えが文書全体に広がっているような質問では長文コンテキストが向いており、ピンポイントな証拠が必要なときはRAGのほうが適しています。
コンテキストウィンドウの制限を根本から見直す研究では、LLMが長いプロンプトをそのまま読み込むのではなく、まったく異なるやり方で扱う新しいアプローチも提案されています。両方のよさを活かしたハイブリッドな設計が今後のテーマになるとされています。
RAG導入の実践知
ここからは、RAGを実際のビジネスで導入・活用するための実践的な知見を紹介します。
データソースの構造化という考え方
RAGを実用的なレベルにするには、検索対象となるデータをどう整理するかが重要です。
データソースの構造化を提案した研究では、RAGの限界を克服するためのアプローチが紹介されています。
標準的なRAGは、基本的に「文章の塊」を検索して持ってきます。しかし、それらは構造化されていないバラバラな情報です。たとえば「この製品の保証期間と修理手続きについて教えて」と質問したとき、保証に関する情報と修理手続きの情報が別々の文書にあったり、情報同士の関係性が明確でなかったりします。
また、「A部門とB部門の過去三年間の業績を比較して、その背景にある市場要因を分析して」といった複数のステップを踏む必要がある質問には対応しづらいのです。
こうした課題に対して、意味や関係性をネットワークの形で表す「知識グラフ」を使う方法や、検索を何段階かに分けて行う方法が注目されています。データソースを事前に構造化しておくことで、より複雑な質問にも対応できるようになります。
RAGOpsという運用の考え方
RAGシステムを安定して運用するには、ただ最初に構築すれば終わりというわけにはいきません。
RAGOpsという運用フレームワークを整理した研究では、RAGの仕組み全体を支えるための運用手法が提案されています。
従来の「LLMOps」はモデル本体とプロンプト周辺の管理に特化しており、外部データを検索・取得するプロセスまで含めた運用は想定されていないケースが多いのです。RAGシステム全体の品質を保つには、検索の精度や取得データの妥当性といった「データ側の管理」も含めた視点が必要になります。
RAGOpsでは、5つの品質観点が重視されています。
まず「適応性」です。データ構造や処理の粒度を見直しやすい設計を保つことで、LLMの切り替えや検索方法の改善といった変化に柔軟に対応できます。
次に「監視可能性」です。検索結果の質や応答の速さ、データベースの更新状況などを常にモニタリングし、不調の兆しに早く気づけるようにします。
「観測可能性」も重要です。「この応答、なぜ急に精度が落ちたのか」といった疑問に対し、ログや出力記録をもとに遡って調べられる仕組みが求められます。
「追跡可能性」では、いつ・何が・どう変わったかを記録しておくことで、必要なときにさかのぼって検証できるようにします。
最後に「信頼性」です。負荷分散や自動スケーリングを取り入れ、処理量の変動に耐えられるようにします。
エピソード記憶のようなRAG
通常のRAGは、チャンクを個別に検索するため、情報同士のつながりや時間的な流れを追うのが苦手です。
エピソード記憶をLLMに持たせるRAGの研究では、この課題に取り組んでいます。人間のエピソード記憶（特定の時間と場所に結びついた個人的な経験の記憶）をヒントに、「時間の経過にともなう役割や状態の変化を追いかけること」を可能にする仕組みが提案されています。
たとえば、ある人物の経歴を時系列で追ったり、プロジェクトの進捗状況の変遷を把握したりといった用途に有効です。ビジネス文書や報告書のように「いつ・どこで起きたか」という時空間的な文脈が重要な場面で、従来のRAGを補完する技術として期待されています。
応用事例 対話型の科学データ検索
RAGの具体的な応用事例として、科学技術分野でのデータ検索システムがあります。
AIと対話しながらデータセットを探せるシステム「ScienceDB AI」は、1500万件以上の科学データの中から、ユーザーの意図を理解して適切なものを推薦する仕組みです。ユーザーが要望を伝えると、システムが研究トピックや実験条件を自動で読み取って検索し、対話を重ねて絞り込んでいけます。
LLMにありがちな「存在しないデータをでっち上げる」問題を防ぐため、必ず実在するデータだけを返し、引用用の識別子も付与する設計になっています。技術的にはデータセットをDBとしてLLMがRAGを行うシンプルな設計ですが、用途を絞ることによって使い勝手が向上する好例といえます。
RAGの課題とリスク
RAGには大きな可能性がある一方で、無視できない課題やリスクも存在します。
RAGでも応答を間違う5つの原因
RAGを使えばLLMの回答が正確になると期待されがちですが、コンテキストを参照した場合でも応答を誤るケースがあります。
RAGのエラータイプを分析した研究では、コンテキストが得られても応答を間違うときの原因が5つに分類されています。
1つ目は「ノイズが多い」ケースです。検索結果に無関係な情報が多く含まれていると、LLMが混乱して誤った回答を生成することがあります。
2つ目は「指示と一致していない」ケースです。検索された情報がユーザーの質問の意図とずれている場合です。
3つ目は「構造が異常」なケースです。検索結果のフォーマットや構造がLLMにとって理解しにくい形式になっている場合です。
4つ目は「内容が不完全」なケースです。回答に必要な情報の一部しか検索できていない場合です。
5つ目は「モデルが生成して補完してしまう」ケースです。検索結果に含まれていない情報をLLMが勝手に補ってしまう場合です。
実験では、コンテキストが得られた場合でも約1割はこれらいずれかの原因に基づくエラーに遭遇すると報告されています。対策としてプロンプトエンジニアリングを工夫することが挙げられていますが、RAGは万能ではないという認識が重要です。
不要な情報を無視させるアプローチ
RAGで検索した情報の中には、質問に関係のないものも含まれることがあります。こうした不要な情報がLLMの判断を歪める可能性があります。
UCバークレーの研究者らが提案した「RAFT」というフレームワークでは、関連性の低い文書を無視するようにLLMを学習させることで、QAタスクで従来の手法を大幅に上回る結果を達成しています。
具体的には、質問、関連文書、不要な文書、回答のペアデータを準備し、不要な文書を含めた学習を行います。するとLLMが「無視」することを習得します。実験では、すべてのデータセットにおいてベースラインを上回る性能を示し、思考の連鎖（CoT）を用いることでさらに性能が向上することが確認されました。
セキュリティ対策の投資対効果
RAGシステムを業務に取り入れる企業が増えていますが、情報漏洩やプロンプトインジェクションといったセキュリティリスクへの対応は後回しにされがちです。
RAGのセキュリティ対策の投資対効果を分析した研究では、3つのセキュリティ対策のうち、どれが最も費用対効果に優れているかが検証されています。
プロンプトインジェクションとは、悪意あるユーザーが細工を施した入力を送ることで、モデルに本来想定されていない動作を引き起こさせる攻撃手法です。また、データ漏洩の問題も深刻で、モデルが意図せず機密情報を出力してしまうリスクがあります。
セキュリティ対策にはコストがかかるため、どの手段にどれほど投資すべきかを判断するのは簡単ではありません。研究では、ABAC（属性ベースのアクセス制御）、NER（固有表現認識）を用いたフィルタリング、差分プライバシーといった対策の効果とコストが比較されています。
検索するかどうかの判断がむずかしい
現在のRAGでは、基本的に「とりあえず検索してから答える」という流れになっています。しかし最近のLLMは、内部にある知識だけでも多くの質問に正しく答えられるようになっています。
つまり、「この質問には本当に検索が必要なのか？」という判断が重要になってきています。不要な検索はコストと時間の無駄になりますし、場合によってはノイズを増やして回答の質を下げることにもなりかねません。
モデルがどのくらい自信を持っているかを測って、検索が必要なときだけRAGを使うというアプローチが検討されています。この「自信のなさ」を測るやり方には、質問の意味があいまいなとき、モデルの予測がバラバラなとき、答えの確からしさが低いときなど、いくつかの考え方があります。
LLM性能向上の中でRAGに求められること
LLM自体の性能が飛躍的に向上した今、「そもそもRAGは本当に必要なのか？」という声も出ています。しかし、RAGには今も意味のある役割があります。
RAGが活きる3つの場面
専門的な知識が必要な場面
医療や薬学、法律など、間違いが許されない領域では、モデルが覚えている情報だけでは足りないことがあります。RAGを使って信頼できる外部データベースから根拠を引っぱってくることで、より確実な答えが出せるようになります。
たとえば薬の投与量を判断するような質問では、最新のデータを引いてそれをもとに答えることが大切です。RAGは「根拠に基づいた出力」を支える仕組みとして役立ちます。
社内データや個人情報を扱う場面
社内文書や個人メモなど、外に公開されていない情報を扱うときもRAGは重要です。LLMは一般的な知識には強くても、企業ごとの事情や個人の過去のやりとりまでは知りません。
RAGがそれらの情報を検索してモデルに渡すことで、その人や組織に合った応答を返せるようになります。ユーザーとの会話の履歴を検索対象にすれば、前に話した内容をふまえた一貫性のある返答も可能になります。
情報の変化が早い場面
ニュースや金融、法律の改正など、日々状況が変わる分野でもRAGは活躍します。こうした分野では、モデルを毎回再学習するのは現実的ではありません。RAGが外部の最新情報を引いてきて、それをモデルに読ませることで、すぐに新しい内容に対応できます。
今後の方向性
RAGの研究は今も活発に進んでいます。いくつかの方向性が見えてきています。
まず、検索すべき情報をどう選ぶかの高度化です。単に似ている文を引っ張ってくるだけではなく、質問を分けたり、仮の答えを立ててみたり、手順を踏んで検索する工夫が必要になります。知識グラフを使った整理方法や、検索を何段階かに分けて行う方法、LLMが自分で検索を繰り返す「エージェント型」のアプローチも注目されています。
次に、取り込んだ情報の信頼性をどう担保するかです。外部情報そのものに間違いがあった場合、それをLLMがそのまま信じてしまうと誤った出力につながります。どのデータをどこから引いてくるかを事前に選別したり、ソースごとの信頼度を評価したりする仕組みが重要になります。
そして、RAGと長文コンテキストのハイブリッド設計です。両方のよさを活かし、質問の性質に応じて適切な方法を選択する柔軟な設計が今後のテーマになっています。
まとめ
本記事では、RAGの本質から最新研究動向、導入・運用の実践知まで体系的に解説しました。
最新研究では、LLMが情報源によって信頼度を変えること、ベクトル検索には理論的な限界があること、同じ情報でもLLMによって有用性が異なることなど、RAGの実態が明らかになっています。長文コンテキストとの関係も整理が進み、両者のハイブリッド設計が今後の方向性として注目されています。
また、実務では、データソースの構造化、RAGOpsによる運用管理、エピソード記憶的なアプローチなど、さまざまな工夫が実践されています。同時に、エラータイプの理解、セキュリティ対策、検索判断の最適化といった課題への対応も欠かせません。
RAGは「検索して答えさせる便利な仕組み」という表面的な理解を超えた、奥深い技術領域です。LLMの性能が向上し続ける中でも、専門知識、社内データ、最新情報といった場面でRAGは独自の価値を発揮します。本記事がRAGを理解する入り口となり、継続的な学習のきっかけになれば幸いです。
