RAG(検索拡張生成)とは？ 仕組みからわかる、"動く"から"使える"へのステップアップ！

生成AIと社内データをつなぐ手段として「RAG（検索拡張生成）」が注目を集めています。
PoCや試験導入のフェーズを経て、「RAGの仕組みはなんとなく理解した」「とりあえず動かすところまではできた」という方も増えてきました。しかし一方で、「一応与えたデータを参照して答えてくれるけど、正直現場で使えるレベルじゃない」「業務に役立つ回答が得られるように改善したいが、どこを改善すべきか検討がつかない」のような声も聞かれます。

本記事では、RAGをこれから構築しようとしている方や、既に構築しているが思ったような成果が出ていない方に向けて、RAGの仕組みと精度改善のポイントを丁寧に解説します。

なぜ、いまRAGに注目が集まるのか？

生成AIは東大に受かるのに、現場で使えない？

2025年、「生成AIはついに東大入試に合格するレベルまで到達した」というニュースが報じられて話題を呼びました。共通テストと二次試験の両方で高得点を記録し、知識・思考力・表現力のすべてで人間超えを達成したとも言えるほどです。

しかし、そんな優秀な生成AIを業務に導入しても、実際には期待したような成果が得られるとは限りません。その要因のひとつとして、AIは社内のことを知らない という点が挙げられます。
生成AIはインターネット上の公知情報を学習していますが、あなたの会社の規程や手順書、業務マニュアルといった非公開情報までは学んでいません。AIの知らないことについてユーザーが質問してしまった結果、「思ったより使えない」と思われてしまう、という事態はしばしば起こります。

RAG = AIと社内ナレッジの橋渡し

知らなくて答えられないなら教えてあげればいい、ということで登場したのが RAG（Retrieval-Augmented Generation；検索拡張生成） です。RAGとは生成AIと社内ナレッジを連携させる仕組みです。ユーザーからの質問に対して社内の関連情報を検索し、それをAIに渡すことで、まるでAIが社内事情を知っているかのように回答を生成できるようになります。
例えば、「出張時の日当はいくらですか？」という質問に対して、素の生成AIは正しく回答することはできません。しかし、生成AIが社内規定のドキュメントを参照し、そこから「旅費規程第14条　日当は1日あたり5,000円を支給する」のような文面を検索できれば、それをもとに正しい回答を生成できます。

「動く」から「使える」へ

近年、生成AIの普及と性能向上に伴い、多くのRAGソリューションが市場に投入されつつあります。社内でRAG構築のPoCを進める企業も増えてきていますが、ここで思ったような成果をあげられていない企業は少なくありません。
なぜなら、RAGは「とりあえず動く」と「実務で使える」の間のギャップが非常に大きい技術であるからです。さまざまな要因が積み重なった結果、文書の検索精度がイマイチで実用には耐えないものになっていたり、現場の期待との間にギャップが生じていたりといったケースが多いのです。

このギャップを埋め、RAGを「使える」レベルまで持っていくにあたって、何か万能な手法が存在しているわけではありませんが、それでも解決策を考える上では以下の3つの理解が必要となるでしょう。

• RAGの仕組み に対する理解
• 業務課題 に対する理解
• 利用する データ に対する理解

今回は、特に RAGの仕組み に焦点を当てて、そこから見えてくる精度改善のポイントについて説明します。

RAGの仕組み

RAGの精度改善を考える上でまず重要なのは、RAGがどのような考え方に基づいてどのように設計されているのかを知ることです。
ここでは、RAGの本質的な考え方と、それを実現するための構成要素について解説します。

RAGの本質：「知識問題」+「ヒント」→「読解問題」

RAGの本質は、「AIを再学習させる」のではなく、「必要な情報を適宜ヒントとして与える」という発想です。これは、AIに試験問題を解かせるときに、参考資料を渡して解かせるのに似ています。

例えば、先ほどの例と同じ「出張時の日当はいくらですか？」という質問を考えてみましょう。この質問だけをAIに尋ねた場合、これは正解を知らなければ答えられない知識問題です。しかし、ヒントとして旅費規定も一緒に与えれば、そこから情報を読み取ることで正解できる読解問題となります。
以下の図は、「出張時の日当はいくらですか？」という質問（知識問題）と一緒に「旅費規程第14条　日当は1日あたり5,000円を支給する」という情報をヒントとして与えることで、正しい回答が得られる（読解問題に解答できる）ようになる様子を表しています。

生成AIは、テキストの文脈を踏まえて内容を把握する能力に長けており、「読解問題」に答えるのは得意と言えます。一方で「知識問題」の場合、答えを知らなければ生成AIは適切に回答できません。そこで、「ヒント」を組み合わせることで「読解問題」に持ち込むというのがRAGのセオリーなのです。

上記の例では、ヒントとなる旅費規程を手動でプロンプトに追加しても、正しい回答が得られます。しかし実際には、ヒントとなりそうな文書を質問のたびに手動でプロンプトに追加する、というのは現実的ではありません。上記のRAGのセオリーをスムーズに実行するには、ヒントとなりそうな文書を自動で検索するシステムが併せて必要になります。
以下の図は、ユーザーの入力した質問（知識問題）に対して、ヒントとなりそうな情報を検索システムが探し出し、それをもとにAIが回答を生成（読解問題に解答）するまでの流れをまとめたものです。

以上で説明したRAGの仕組みをまとめると、RAGについて次の図のようなイメージを持つことができます。たくさんの公知情報を覚えている賢いAIですが、社内の情報については何も知らないので、資料を急いで探し出して、その場で回答を組み立てているにすぎません。

RAGの構成要素

これまで紹介した仕組みを実現するために、RAGにおいては、通常の生成AIによる回答生成プロセスの他に以下の2つのパーツが必要です。

• ヒントとなるテキストデータを格納した データベース
• データベースから適切なヒントを探し出す 文書検索システム

以下では、この2つのパーツの概要について説明します。

データベース：ヒントとなる情報の保存場所

RAGの構築において土台となるのが データベース です。「ヒント」となる文書を正確に検索・抽出するためには、あらかじめ文書群から適切な形式のデータベースを構築し、検索可能な形で保持しておく必要があります。

典型的なRAGにおいては、文書データを以下のような流れで処理することで、 ベクトルデータベース を構築します。

1. テキスト抽出
   PDFやWord、スキャン画像など、さまざまな形式の文書データからテキストを抽出します。
   図表についても、ビジョンモデルやOCRを使うことでテキストの抽出が可能です。
2. チャンキング（分割）
   抽出したテキストデータが長大であった場合、そのままでは後の検索精度が悪くなるなどの問題が発生します。
   そこで、抽出したテキストデータをチャンクと呼ばれる小さなまとまりに分割します。以下のイメージ図のように、テキストを意味内容ごとに区切るようにしてチャンキングするのが望ましいでしょう。

   

3. ベクトル化
   各チャンクをベクトル（数値の列）に変換し、ベクトルデータベースに格納します。
   チャンクをベクトルに変換すると言っても、ただ闇雲に数値化するのではありません。意味内容のよく似たチャンクどうしが互いによく似たベクトルになるよう、うまく変換されるのです。
   これは文書埋め込み（sentence embedding）と呼ばれる自然言語処理の技術を用いることで実現されます。このベクトル化のおかげで、類似検索システムはユーザーからの質問と関連の深いチャンクを探し当てることができます。

文書検索システム：適切なヒントを探し出す仕組み

データベース構築とならんで重要なのが 文書検索システム です。生成AIが自らの知識だけでは答えられない質問を受け取ると、検索システムがデータベースの中から関連情報を探し出し、それをもとに生成AIが回答を生成します。

この文書検索システムでは、単純なキーワード検索ではなく、「質問と意味が近い文書」を探す 類似検索（ベクトル検索） が用いられます。
検索の際には、質問文と文書チャンクをそれぞれベクトルに変換し、それらの間の距離（≒変換前の文書間の意味の近さ）を比較して、最も近い文書を選びます（以下のイメージ図を参照）。これにより、たとえキーワードが一致していなくても、内容的に関係の深い文書が検索できるのです。

データベースと文書検索システムの質は、いずれも最終的な回答の質に直結します。これらをどのように設計するかは、RAG構築における最重要ポイントであると言えるでしょう。

RAG構築のよくある落とし穴とその回避術

前章では、RAGを構成するパーツである「データベース」「文書検索システム」について説明しました。次のステップは、これらに対する知識や理解をベースとして、RAGの精度をどのように改善していくかを考えることです。
今回は、RAG構築・改善において特にありがちな「落とし穴」に絞って取り上げ、それぞれにどのような問題が潜み、それらをどう回避すべきかを解説します。

落とし穴①：チャンクのサイズが適切でない

データベース構築における落とし穴として、チャンクサイズ の問題があります。
文書から抽出したテキストデータをチャンクに分割する際には、チャンクを適切な粒度で分割することが重要です。これは、チャンクの粒度に応じて、チャンク検索のヒット率と回答の精度の間で以下のようなトレードオフが生じるためです。

• 細かくした場合……各チャンクの内容が明瞭になるため目的のチャンクがヒットしやすくなるが、各チャンクの情報量は減るため回答精度が落ちやすい
• 粗くした場合……各チャンクの内容が複雑になるため目的のチャンクがヒットしにくくなるが、各チャンクの情報量は増えるため回答精度が上がりやすい

どのくらいのチャンクサイズが適切であるかについては、データの形式や内容などによる部分が大きく、一概に決められるものではありません。チャンキングの際には、複数のチャンクサイズを試し結果を比較することで、最適なものを見つける必要があります。

また、文書のサイズや計算のコストなどを考慮しつつ、以下のようなより高度なチャンキング手法を導入するのも手です。

• 文書に様々な粒度のインデックスを与える ドキュメントベースチャンキング ・ 階層的チャンキング
• テキストのベクトル化を活用し、意味内容の類似性にもとづいてテキストを分割する セマンティックチャンキング
• 生成AI を活用し、適切な粒度でテキストを分割するチャンキング

落とし穴②：質問によっては類似検索では不十分なケースがある

類似検索における落とし穴として、「質問文と内容の近いチャンクを選び出す」という仕様上、質問の内容によっては適切な回答の生成につながらない場合があります。

• 複数のチャンク を参照して回答しなければならない質問（例：○○に関連する資料をすべて参照して要約してください）
• 文書のメタデータ を使って回答しなければならない質問（例：いちばん最近更新されたファイルはどれ？）

特にメタデータの必要性については、質問文からはただちに明らかではないケースもあるため注意が必要です。
例えば、社内のとある課の課長の名前を知りたくてAIチャットに尋ねたとします。質問した人は現在の課長の名前を知りたいはずなので、RAGの類似検索システムは最新の社内体制図の内容をデータベースから探す必要があります。
しかし、以下の図のように歴代の体制図のデータがすべてデータベースに保存されていた場合、単純な類似検索システムはどの体制図を選べばよいか判断できません。過去の体制図をデータを取ってきてしまう可能性があります。
このようなケースでは、データの作成日時というメタデータまで参照しなければ確実な回答の生成は困難です。

文書全体を俯瞰したり、メタデータを参照したりする必要のある質問にもうまく回答するためには、以下のようなベクトルデータベース以外の形式のデータベースも併用してRAGを構築することが有効です。

• リレーショナルデータベース：テーブル形式に構造化されたデータを管理
• グラフデータベース：データをグラフ形式で格納することで、複雑な関係性をもつデータを管理
• ドキュメントデータベース：データをより柔軟な形式（JSONなど）で管理

番外編：ユーザー部門とのコミュニケーションがうまくいかない

RAGを構築し終わり、PoC的に動かす段階までは特に問題なかったとしても、その先で落とし穴に遭遇することもあります。
ユーザーヒアリングの内容に即してRAGを構築したにもかかわらず、いざユーザー部門に展開するとユーザーから期待外れの声が聞こえてきてしまう、といったケースです。

このような事態の裏では、以下のイメージ図のようにユーザー部門と開発側で期待度にギャップがある場合があります。これは開発側とユーザー側のコミュニケーションに関する問題であると言えます。

チャットUIは手軽に利用できるぶん、開発時には想定されていなかったような質問が舞い込んでしまうことも少なからずあります。そのような質問が入力されると、データベース内にはヒントとなるテキストが存在しないためAIが無理やりいい加減な答えを返してしまい、結果的に「このシステム、使えないよね」という悪印象につながってしまうことがあるのです。

このようなギャップを防ぐためには、以下の3段階でユーザーに正確な期待度を伝える工夫が必要です。

①RAG導入・改善プロジェクトの実施
PoCの時点ではあくまでも一部の文書データのみを試験的に用いている、ということをユーザーに伝えておくことが必要です。 質問の内容によってはうまく回答が生成されないケースがある、ということをユーザーに理解してもらうことで、「使えない」といった評判が独り歩きすることを防ぎます。

②UI・仕様の設計
この段階においては以下のような工夫が考えられます。

• 以下の内容をUI上で確認できるようにする
  • 参照され得る文書データの一覧
  • 回答生成にあたり参照した文書のリファレンス
  • 質問文のテンプレート
  • AIの思考プロセス、ログ
• ハルシネーションが発生し得ることをUI上でユーザーに伝える
• どの文書データを参照するかをユーザーが指定できるようにする

UIや仕様の設計時にこれらの項目に留意することで、ユーザーの期待する回答が生成されやすくなります。また、生成された回答に対するユーザーの納得感を高めます。

③生成AIのプロンプトエンジニアリング
生成AIの出力をプロンプト側で制御することも有効です。例えば「関連度の低い文書データしか検索で見つからなかった際に、その旨をユーザーに明示的に伝えるような回答が出力されるようにする」といった工夫が考えられます。
これによりハルシネーションなどによるAIの誤回答を抑制し、システムの信頼性を高めます。

おわりに：RAG構築のための「仮説思考」

今回は、「RAG ＝ 生成AIを自社のナレッジとつなぐ技術」について、その仕組みと落とし穴対策を説明しました。
RAGの仕組みを知り、それを踏まえてよくある落とし穴の傾向と対策を押さえておくことは、RAGの精度改善を考える際の基礎として欠かせないものです。

しかしすでに述べたように、今回述べた内容だけ押さえれば誰でもRAGの精度を改善させられる、とは限りません。
RAGが「使える」ものに至っていない理由は現場によってさまざまであり、実際にはもっと複数の要因が絡み合っているのが普通です。あらゆる課題を解決できる万能な方法があるわけではないのです。

課題を特定し解決するためには、地道で堅実なアプローチが必要です。それは、RAGの入出力をつぶさに観察したうえでの仮説思考であると言えるでしょう。

1. さまざまな入出力パターンを試して、どんな場合にうまく精度が出ないのかを知る。
2. 精度が出ない理由について仮説を立てる。
3. 仮説にもとづいて精度改善の施策を立てる。

このプロセスにおいて的を射た仮説を立てるためには、RAGの仕組みを理解することにくわえて、現場が抱える業務課題とデータに対する理解も求められます。

NTTデータ数理システムでは、このようなより包括的な視点からのRAG導入・精度改善について、豊富な知見にもとづいた支援を行なっております。

• 精度のボトルネックとなっている落とし穴の特定
• より高度なRAGアーキテクチャの提案・実装・精度検証

現状の問題点や課題をお伺いし、プロジェクト化に向けて要件を整理するところから当社が伴走いたします。お打ち合わせ後に活用したいデータをお送りいただければ、 無料のアセスメント を通じた課題の洗い出し・解決策の検討も承りますので、ぜひお気軽にご相談ください。