RAGとは、Retrieval Augmented Generationの略で、自社に蓄積された大量の業務文書・規定などの社内情報、外部の最新情報を活用する手段として、信頼できるデータを検索して情報を抽出し、それに基づいて大規模言語モデル（LLM）に回答させる方法のことです。日本語では、検索拡張生成と言います。
本記事では、RAGの仕組みや活用例、ファインチューニングとの違い、精度向上のノウハウなどについて解説します。
なぜRAGが必要なのか？
生成AIは人間と同じように自然な会話を行うことが可能で、さらに要約や翻訳などさまざまなタスクを実行できる汎用性を持っています。しかし、残念ながら生成AIは常に完璧な回答をしてくれるわけではありません。生成AIの知能にあたるLLMは、学習済みのデータを基に、質問内容（プロンプト）から統計的に確率が高い回答を生成します。したがって、学習済みのデータに含まれない情報に基づいては回答できません。例えば、汎用的なLLMに対し、自社の社内規定や今日の株価について質問しても、LLM単独では正しく回答することはできません。
一方、生成AIのビジネス活用が進展する中で、自社に蓄積された社内情報や外部の最新情報を活用することへのニーズは高まっています。汎用的なタスクだけでなく、自社の業務に特化したタスクを生成AIに任せたいと考えた場合、こうしたニーズに直面するでしょう。RAGは、こうしたニーズを満たすために有効なアプローチです。RAGを用いることで、生成AIが社内情報などに基づいた回答を行うことができるようになります。また、生成AIが事実に基づかない回答を生成し、もっともらしい嘘をつく“ハルシネーション”を低減させることにもつながります。
RAGの仕組み
RAGの仕組みはシンプルです。RAGには、大きく2段階のフェーズが存在します。それは、(1)検索フェーズと(2)生成フェーズです。下図に、RAGがどのように動くかのイメージを示しました。
検索フェーズ
検索フェーズでは、LLMに無い知識を補うべく、自社に蓄積された社内情報や外部の最新情報（以降、外部データ）を取得します。
まず、RAGを用いた生成AIのアプリケーションに対してユーザーが質問を行ったとき（図中①）、アプリケーションは外部データに対して、質問に関連する文書の検索を行います（図中②）。これにより、アプリケーションは外部データから関連性の高い文書を取得します（図中③）。ここまでが検索フェーズであり、RAGという名前のとおり、検索で拡張された部分になります。生成フェーズ
生成フェーズでは、検索フェーズで取得した文書を用いて、ユーザーの質問に答える回答を生成します。アプリケーションは、ユーザーの質問に、検索フェーズで取得した関連文書の情報を付け加えてLLMに送信します（図中④）。一般に、LLMへの指示には、ユーザーの質問の他に、より良い回答のための外部データ（コンテキストと言います）を含めることが可能で、RAGではここで関連文書の情報を利用しています。これを受けて、LLMは回答を生成し（図中⑤）、最終的にアプリケーションがユーザーに回答を表示します（図中⑥）。
こうした仕組みにより、RAGは外部データを活用してLLMに回答させています。仕組みとしてはシンプルですが、実装する際には、(1)検索フェーズの工夫が重要になります。外部データをどのように整形するか（構造化）、データを検索しやすい形にするか（ベクトル化）、検索システムをどのように実装するか（キーワード検索、ベクトル検索、ハイブリッド検索など）、などを考慮する必要があり、これらを適切に設計することでRAGの精度を高められます。
RAGを用いたアプリケーションの例
下図は大和総研が社内で公開している、RAGを用いたアプリケーション（社内情報検索LLMアプリ）のイメージです。LLM単独では難しい、社内情報を反映した回答ができていることが分かります。また、LLMが回答を生成する際に参照した文書および該当箇所が表示されるため、LLMの回答が正しいかどうか、情報源を確かめることが容易になります。
出所：大和総研「社内情報検索LLMアプリ」(2023年7月)の実行結果（イメージ図）
このアプリケーションでは、前述の検索フェーズにおいて社内規定が記載された文書を検索しています。上図の例では、質問内容に最も類似すると思われるX規定の14頁を基に、LLMが回答を生成しています。なお、回答の生成に際して直接参照した文書以外に、類似性が高い文書を順番に表示しており、LLMの回答が不十分な場合にはそれらを確認できる仕様になっています。
RAGとファインチューニングの違い
LLMで外部データを活用する方法として、RAGとよく比べられるのがファインチューニングです。下図に、RAGとファインチューニングの違いを示しました。これらの違いは、LLMの追加学習の有無にあると言えます。図の上部はRAGのイメージで、「RAGの仕組み」で説明した図をさらにシンプルにしたものです。LLM自体は汎用的なモデルを用いており、LLMは都度取得した外部データの情報を基に回答を生成します。一方、図の下部はファインチューニングのイメージで、汎用的なLLMに追加学習をさせることで、特定のタスクに対応させようとするものです。LLM自体が特化モデルとなっているので、ユーザーの質問に対してはLLM単独で回答できます。
RAGとファインチューニングはその性質上、それぞれ得意とするタスクが異なります。一般に、RAGは「特定の事実」に関するタスクが得意で、ファインチューニングは「特定の形式」に関するタスクが得意だと言われています。すなわち、汎用モデルが知らないような事実（社内規定など）を回答させるタスクではRAGに優位性があり、質問に対する回答の形式が定められているタスク（特定の口調やロジックで回答する）ではファインチューニングに優位性があると言えます。
最近の研究によると、やや古い汎用モデルをベースに追加学習した特化モデルよりも、最新の汎用モデルを用いた方が精度は高くなるといったケースもあり、ファインチューニングを用いる場合には注意が必要です。いずれにせよ、社内情報を検索するアプリケーションなど、特定の事実を回答させるタスクではRAGを用いるのが望ましいと言えます。
RAGの精度を高めるには？
RAGの精度を高めるノウハウをいくつか紹介します。ここでは、前述の検索フェーズで求められる工夫のうち、「RAGの検索方法」および「ベクトル化の留意点」について取り上げます。
RAGの検索方法
RAGで用いられる検索方法には、次のようなものがあります。検索クエリ（検索システムに入力する単語や文章のこと）を基に、どのように文書を探すかが異なります。
- キーワード検索：キーワードが含まれる文書を探す方法。フルテキスト検索、全文検索と言うこともある
- ベクトル検索：検索クエリと検索対象の文書を数値表現（ベクトル）に変換し、両者の距離の近さ（類似度）を測ることで文書を探す方法
- ハイブリッド検索：キーワード検索とベクトル検索を組み合わせて文書を探す方法
- セマンティック検索：検索クエリの意味や意図を理解し、それに基づいて文書を探す方法
- ハイブリッド検索＋セマンティックランク付け：ハイブリッド検索の結果に対して、セマンティックランク付けを行うことで、検索の精度を高める方法
下表は、検索方法（セマンティック検索を除く）による精度の違いを、MicrosoftのWebサイトから引用したものです。数字が大きいほど精度が高いことを意味しますが、ハイブリッド検索＋セマンティックランク付けの精度が最も高いことが分かります。ただし、単一の単語のみのクエリの場合、キーワード検索が最も高い精度を示しています。このように、検索対象の文書や検索クエリのタイプによって精度は変わるほか、検索速度はどの程度求められるか、コストをどの程度まで許容するか、などの条件によっても最適な検索方法は変わるため、アプリケーションの目的に応じた適切な設計を行うことが重要です。
クエリタイプ |
キーワード検索 |
ベクトル検索 |
ハイブリッド検索 |
ハイブリッド検索+セマンティックランク付け |
|---|---|---|---|---|
| 抽象的なクエリ 「〇〇はなぜですか」 |
39.0 | 45.8 | 46.3 | 59.6 |
| 単一の答えがあるクエリ 「〇〇の数」 |
37.8 | 49.0 | 49.1 | 63.4 |
| 検索対象ドキュメントの部分文字列の検索 | 51.1 | 41.5 | 51.0 | 60.8 |
| Web検索のようなクエリ 「日本橋 ランチ」 |
41.8 | 46.3 | 50.0 | 58.9 |
| 単一の単語のみのクエリ「大和総研」 | 79.2 | 11.7 | 61.0 | 66.9 |
| 質問とは異なる単語・フレーズを回答に求める検索 | 23.0 | 36.1 | 35.9 | 49.1 |
| スペルミスのあるクエリ | 28.8 | 39.1 | 40.6 | 54.6 |
| 長いクエリ（20トークン以上） | 42.7 | 41.6 | 48.1 | 59.4 |
| 中程度のクエリ（5～20トークン） | 38.1 | 44.7 | 46.7 | 59.9 |
| 短いクエリ（5トークン未満） | 53.1 | 38.8 | 53.0 | 63.9 |
ベクトル化の留意点
それまでの自然言語処理よりも高精度な手法として登場したテキストデータのベクトル化が、Googleが2013年に公開した「Word2Vec」です。これは単語をベクトル化するものでしたが、単語の意味を計算する四則演算の例として「King – Man + Woman = Queen」が大変有名になりました。そして、2014年に考案された「Doc2Vec」では文章・文書全体をベクトル化できるようになりました。その後、さまざまなベクトル化・ベクトル検索のツールが開発されています。これらのツールは、類似度の計算や処理速度、保守・運用コストなどに差が見られるため、導入にあたっては実際に自社データなどを用いた技術検証・比較検証を行う必要があります。
また、類似度の精度に大きく関わるのがベクトル化の単位（チャンクと言います）をどうするか、ということです。これは検索対象の文書が、短文の箇条書きのようなものなのか、長文の解説文のようなものなのかなどにもよります。一定の文字数で区切る固定長や、句点・段落などで区切る可変長が用いられます。固定長では、チャンク間で少量のテキストを重複させることが効果的とされています。この効果の度合いも検証事項となるでしょう。
さらに、業務系システムによく使われるリレーショナル・データベース（RDB）が、昨今、ベクトルデータを保持・活用できるよう進化してきています。この機能を用いれば、売上数値などの業務データと顧客との対話内容などのベクトルデータを1つのデータベースで管理できるようになります。業務機能面で言えば、通常の属性や数値範囲などでの検索とベクトル検索を一つのSQL で実行できるため、アプリケーション開発者がベクトル検索のための特別なスキルを習得する必要がなく、また当然の事ですが業務データとベクトル検索結果を突合する処理をコーディングする必要もありません。保守・運用の面では、新たにサーバーを用意したり、サーバー内のRDBプロセスを増やしたりする必要がないため、バックアップなどの運用や管理の負担がありません。
下図のOracle Databaseでは、バージョン19cでベクトルの格納・検索は可能ではありましたが、バージョン23cではベクトルデータ型が列属性として追加されました。既存のパーティショニング（表や索引などの細分化）や並列検索（Oracle Real Application Cluster）などが活用でき、ベクトル検索性能も大幅に向上しているといいます。
バージョン23cではデータ更新のタイミングでリアルタイムにベクトル化を行うため、既存業務処理への負荷が気になるところではありますが、もし影響がある場合はベクトル化の処理を夜間バッチ処理（一括処理）に切り出してベクトルデータの鮮度を落とすとしても、データベースが一元管理できる効果は大きいでしょう。なお、バージョン23cに対するベクトル検索はOracle AI Vector Searchを用いますが、これらはOracle Cloud Infrastructure（OCI）というパブリッククラウドサービスでも利用できますし、OCI Dedicated Regionというサービスを通してオンプレミス環境でも利用できます。
今後、社内データをいかにビジネスに活かしていくかを考える場合、このようなRDBをベクトルデータベースとしても利用する手段は、選択肢の一つとして検討に値するでしょう。
RAGへの期待
昨今、生成AIをビジネスで活用する企業が増えていますが、その活用度合いも高度化が進んでいます。社内情報や最新情報に基づく回答が必要な場合など、より高度に生成AIを活用するときには、本ページで紹介したような取り組みが必要となるでしょう。
RAGは、信頼できる情報を基に生成AIで回答を生成する手段であり、回答の精度を向上させることが可能です。これは生成AIの取り組みを高度化させていくうえで非常に有効な手段である一方で、その強みを最大限発揮させるためには知識や経験に基づくノウハウも必要です。大和総研では、生成AIに関する豊富な知識や経験に基づき、お客様の課題を解決する最適な手段を提案することができます。生成AIの活用について検討している方は、お気軽にお問い合わせください。
関連するソリューション
大和総研では、Azure等のパブリッククラウドを活用したChatGPT構築支援サービスを行っています。ITソリューションサービスサイトからお問い合わせください。
