生成AIが急速に普及する中、「RAG」という技術が注目を集めています。
ChatGPTなどの生成AIをビジネスで活用しようとすると、「自社の情報を学習させたい」「最新の情報に対応させたい」という課題に直面します。
この課題を解決する技術が、RAG（Retrieval-Augmented Generation：検索拡張生成）です。
この記事では、RAGの基本的な仕組みから、メリット・デメリット、具体的な活用例まで、初心者にもわかりやすく解説します。
RAG（検索拡張生成）とは
RAGは「Retrieval-Augmented Generation（検索拡張生成）」の略称で、生成AIの回答精度を向上させる技術です。
RAGの定義
RAGとは、大規模言語モデル（LLM）による文章生成を行う際に、外部のデータベースから関連情報を検索して組み合わせることで、より正確で信頼性の高い回答を生成する技術です。
簡単に言えば、「AIが回答する前に、まず資料を調べさせる」仕組みです。
RAGが生まれた背景
RAGは、2020年にFacebook AI Research（現Meta AI）、ユニバーシティ・カレッジ・ロンドン、ニューヨーク大学の共同研究チームによって発表されました。
論文の主執筆者であるPatrick Lewis氏は、現在AIスタートアップCohere社でRAGチームを率いています。
同氏は、「この技術がこれほど広まるとわかっていたら、もっと良い名前を考えた」と後に語っています。
具体例で理解するRAG
例えば、あなたの会社の社員食堂について生成AIに質問するとします。
RAGなしの場合:
質問:「今日の社員食堂のおすすめメニューは？」
AI:「申し訳ありませんが、御社の社員食堂のメニュー情報は持っていません。」
RAGありの場合:
質問:「今日の社員食堂のおすすめメニューは？」
システム:社員食堂のメニューデータベースを検索
AI:「本日のおすすめは、日替わり定食の『鮭の塩焼き定食』です。カロリーは650kcalで、価格は500円です。」
RAGを使うことで、AIが本来知らない情報についても、正確に回答できるようになります。
なぜRAGが必要なのか？生成AIの課題
RAGが注目される背景には、従来の生成AIが抱える3つの大きな課題があります。
課題1:情報が古い
生成AIは、訓練された時点までのデータしか知りません。
具体例:
- ChatGPTの知識カットオフ（2023年4月など）以降の情報は知らない
- 2024年の最新ニュースや統計データに対応できない
- 昨日発表された製品について質問しても回答できない
生成AIは「最新の出来事について常に情報を得ることを拒否しながら、常に自信を持ってすべての質問に答える、熱心すぎる新入社員」のような存在です。
課題2:社内情報や専門知識がない
一般的な生成AIは、インターネット上の公開情報から学習しています。
そのため、以下の情報には対応できません。
対応できない情報:
- 自社の業務マニュアルや規程
- 社内の過去の案件データ
- 専門分野の最新研究論文
- 非公開の技術文書
- 顧客との契約内容
ビジネスで生成AIを活用する上で、これは大きな障壁となります。
課題3:ハルシネーション（幻覚）
生成AIは、存在しない情報をもっともらしく作り出してしまうことがあります。
これを「ハルシネーション（幻覚）」と呼びます。
有名な事例:
Googleが2023年2月に発表したAIツール「Bard」のデモで、ジェームズ・ウェッブ宇宙望遠鏡に関する誤った情報を生成してしまいました。
このミスは、Googleの株価を約1000億ドル下落させる原因となりました。
ハルシネーションは、事実に基づいた情報が必要なビジネス利用において、深刻なリスクとなります。
RAGの仕組み
RAGは、3つのフェーズで動作します。
全体の流れ
- 検索フェーズ（Retrieval）: 関連する情報をデータベースから検索
- 拡張フェーズ（Augmentation）: 検索結果と質問を組み合わせる
- 生成フェーズ（Generation）: LLMが回答を生成
それぞれのフェーズを詳しく見ていきましょう。
フェーズ1:検索（Retrieval）
ユーザーからの質問を受け取ると、システムは関連する情報を外部のデータベースから検索します。
検索の手順:
- ユーザーが質問を入力（例:「経費申請の承認フローは？」）
- 質問をベクトル（数値データ）に変換
- データベース内の文書もベクトル化されて保存されている
- 質問のベクトルと類似するベクトルを持つ文書を検索
- 最も関連性の高い情報を取得
この検索には「ベクトル検索」という技術が使われます。
詳細は後ほど説明します。
フェーズ2:拡張（Augmentation）
検索で得られた情報と、ユーザーの質問を組み合わせます。
拡張の具体例:
元の質問:
「経費申請の承認フローは？」
検索で取得した情報:
「経費規程第5条:10万円未満は課長承認、10万円以上50万円未満は部長承認、50万円以上は役員承認が必要。」
拡張されたプロンプト（LLMへの入力）:
以下の情報を参考に、質問に回答してください。
【参考情報】
経費規程第5条:10万円未満は課長承認、10万円以上50万円未満は部長承認、50万円以上は役員承認が必要。
【質問】
経費申請の承認フローは？このように、質問だけでなく、関連する情報も一緒にLLMに渡すことで、より正確な回答を引き出します。
フェーズ3:生成（Generation）
拡張されたプロンプトを受け取ったLLMが、回答を生成します。
生成される回答の例:
「経費申請の承認フローは、金額によって異なります。10万円未満の場合は課長の承認、10万円以上50万円未満は部長の承認、50万円以上は役員の承認が必要です。」
LLMは、自身の学習データと、検索で取得した最新・正確な情報の両方を活用して、質の高い回答を生成します。
ベクトルデータベースとエンベディングの重要性
RAGの核心技術である「ベクトル化」と「ベクトルデータベース」について解説します。
エンベディング（ベクトル化）とは
エンベディングは、文章や単語を数値の配列（ベクトル）に変換する技術です。
なぜベクトル化が必要なのか？
コンピュータは文章を直接理解できません。
数値に変換することで、文章の意味を数学的に扱えるようになります。
エンベディングの例:
文章「犬が好き」→ ベクトル [0.2, 0.8, 0.3, 0.5, …]（実際は数百〜数千次元）
文章「猫が好き」→ ベクトル [0.3, 0.7, 0.4, 0.6, …]
「犬」と「猫」は意味が近いため、ベクトルの値も似た値になります。
これにより、「意味の近さ」を数値的に計算できます。
ベクトルの次元数
一般的なエンベディングモデルでは、以下のような次元数が使われます。
主なモデルの次元数:
- OpenAI text-embedding-ada-002: 1536次元
- Google Vertex AI Embedding: 768次元
- Sentence Transformers: 384〜768次元
次元数が多いほど、細かい意味の違いを表現できますが、計算コストも増加します。
ベクトル検索の仕組み
ベクトル検索では、「コサイン類似度」などの指標を使って、ベクトル間の類似度を計算します。
検索の流れ:
- 質問「犬のしつけ方法は？」をベクトル化
- データベース内のすべての文書のベクトルと比較
- 類似度が高い順に文書をランキング
- 上位N件（通常3〜10件）を取得
キーワード検索との違い:
- キーワード検索:「犬」という単語が含まれる文書を検索
- ベクトル検索:「犬」と意味が近い「ペット」「動物」なども検索対象
ベクトル検索は、同じ意味でも異なる表現（同義語や言い換え）に対応できます。
ベクトルデータベースとは
ベクトルデータベースは、ベクトル化されたデータを効率的に保存・検索するための専用データベースです。
代表的なベクトルデータベース:
- Pinecone（クラウド型、商用）
- Qdrant（オープンソース、Rust製）
- Chroma（オープンソース、シンプル）
- Milvus（オープンソース、大規模向け）
- Weaviate（オープンソース、GraphQL対応）
- pgvector（PostgreSQL拡張）
通常のデータベースとの違い:
通常のデータベース（MySQL、PostgreSQLなど）:
- 文字列や数値を完全一致で検索
- 「犬」で検索すると「犬」のみヒット
ベクトルデータベース:
- 意味の近さで検索
- 「犬」で検索すると「ペット」「動物」「柴犬」などもヒット
- 数百万〜数億件のベクトルを高速検索
ANN（近似最近傍探索）
ベクトルデータベースは、ANN（Approximate Nearest Neighbor：近似最近傍探索）というアルゴリズムを使います。
ANNの代表的な手法:
- HNSW（Hierarchical Navigable Small World）:現在の主流技術
- LSH（Locality-Sensitive Hashing）
- IVF（Inverted File Index）
ANNは「完全に最も近い点」ではなく「だいたい最も近い点」を高速に見つけ出します。
わずかな精度低下と引き換えに、検索速度を大幅に向上させます。
RAGのメリット
RAGを導入することで、以下のようなメリットが得られます。
メリット1:最新情報への対応
LLMを再訓練することなく、最新の情報を提供できます。
具体例:
- 今日発表されたニュースにも即座に対応
- リアルタイムの株価や為替情報を参照
- 最新の法改正情報を反映
データベースを更新するだけで、AIの知識を更新できます。
メリット2:コスト効率が高い
LLMの再訓練には、膨大な計算コストと時間がかかります。
コスト比較:
- ファインチューニング（追加学習）:数百万円〜数千万円、数週間〜数ヶ月
- RAG:データベース構築のみ、数日〜数週間
RAGは、費用対効果の高いアプローチとして注目されています。
メリット3:社内情報・専門知識の活用
公開されていない情報もAIに学習させることができます。
活用できる情報:
- 社内マニュアル、業務手順書
- 過去の案件データ、FAQ
- 専門分野の論文、技術文書
- 顧客情報、契約書（要注意）
- 医療記録、診療ガイドライン
これにより、各組織に最適化されたAIを構築できます。
メリット4:透明性と信頼性の向上
RAGでは、回答の根拠となる情報源を示すことができます。
引用の例:
質問:「当社の有給休暇の取得ルールは？」
回答:「有給休暇は入社6ヶ月後から付与されます。初年度は10日間です。（出典:就業規則第15条）」
ユーザーは、情報源を確認することで、回答の正確性を検証できます。
これは、ハルシネーションのリスクを大幅に減らします。
メリット5:ハルシネーションの軽減
外部の信頼できる情報を参照することで、AIが誤った情報を生成するリスクが減少します。
ただし、完全にゼロにはできません。
検索された情報を誤解釈する可能性は残ります。
メリット6:柔軟な知識の更新
新しい情報をリアルタイムで追加・変更できます。
更新の例:
- 新しい商品情報を追加
- 古い情報を削除
- 誤った情報を修正
データベースを更新するだけで、すぐに反映されます。
RAGのデメリットと課題
RAGには、いくつかのデメリットや課題もあります。
デメリット1:検索精度への依存
RAGの回答品質は、検索結果の質に大きく左右されます。
問題の例:
- 関連性の低い情報を検索してしまう
- 必要な情報を検索で見つけられない
- 古い情報と新しい情報が混在
検索エンジンの精度が低いと、回答の質も低下します。
デメリット2:応答時間の増加
検索のステップが追加されるため、回答までの時間が長くなります。
処理時間の内訳:
- 質問のベクトル化:0.1〜0.5秒
- ベクトル検索:0.1〜1秒
- LLMでの生成:1〜5秒
合計:1.2〜6.5秒程度
通常のLLM単体よりも、1〜2秒程度遅くなります。
デメリット3:システムの複雑化
RAGシステムには、複数のコンポーネントが必要です。
必要なコンポーネント:
- エンベディングモデル
- ベクトルデータベース
- 検索エンジン
- LLM
- 統合レイヤー（オーケストレーション）
これらを適切に管理・運用するには、一定の技術力が必要です。
デメリット4:データ準備の手間
効果的なRAGシステムには、高品質なデータが必要です。
データ準備の作業:
- 文書の収集
- 前処理（クリーニング）
- チャンク分割（適切なサイズに分割）
- メタデータの付与
- ベクトル化
- データベースへの登録
初期構築に、相応の時間と労力がかかります。
デメリット5:コンテキストウィンドウの制限
LLMには、一度に処理できるテキスト量に上限があります。
主なLLMのコンテキストウィンドウ:
- GPT-3.5:4,096トークン（約3,000語）
- GPT-4:8,192トークン（約6,000語）
- Claude 2:100,000トークン（約75,000語）
- Gemini 1.5 Pro:最大200万トークン
検索結果が多すぎると、すべてをLLMに渡せない場合があります。
RAGとファインチューニングの違い
生成AIをカスタマイズする方法として、RAGとファインチューニング（追加学習）がよく比較されます。
ファインチューニングとは
ファインチューニングは、既存のLLMに追加のデータで学習させる手法です。
ファインチューニングの特徴:
- LLMのパラメータ（重み）を更新
- 特定のタスクやドメインに特化
- 一度学習させれば、推論時は高速
RAGとファインチューニングの比較表
| 項目 | RAG | ファインチューニング |
|---|---|---|
| コスト | 低〜中 | 高 |
| 実装期間 | 数日〜数週間 | 数週間〜数ヶ月 |
| 知識の更新 | 簡単（データベース更新） | 困難（再学習が必要） |
| 最新情報への対応 | 即座に対応可能 | 再学習が必要 |
| 情報の透明性 | 高い（出典を示せる） | 低い（ブラックボックス） |
| 応答速度 | やや遅い | 速い |
| 技術的難易度 | 中 | 高 |
| 専門性 | 中程度 | 高い |
どちらを選ぶべきか
RAGが適している場合:
- 最新情報を頻繁に更新したい
- 情報源の透明性が重要
- 開発コストを抑えたい
- 社内文書を活用したい
ファインチューニングが適している場合:
- 特定のスタイルや口調を学習させたい
- 応答速度が最重要
- 学習データが固定的
- 専門用語や業界特有の表現を習得させたい
併用も可能:
実際には、RAGとファインチューニングを組み合わせるアプローチも有効です。
ファインチューニングで基礎的な知識とスタイルを学習させ、RAGで最新情報を補完します。
RAGの活用例
RAGは、さまざまな業界・用途で活用されています。
活用例1:社内ヘルプデスク・チャットボット
社内の問い合わせ対応を自動化します。
活用シーン:
- 就業規則や社内制度の問い合わせ
- IT機器のトラブルシューティング
- 経費申請や休暇申請の方法
効果:
- オペレーターの負担軽減
- 24時間365日対応可能
- 回答の均一化（ベテラン・新人の差がなくなる）
具体例:
質問:「結婚休暇は何日取得できますか？」
システム:就業規則を検索
回答:「結婚休暇は5日間取得できます。挙式日の前後1ヶ月以内に取得してください。（就業規則第20条）」
活用例2:顧客サポート
顧客からの問い合わせに自動で回答します。
活用シーン:
- 製品の使い方
- トラブルシューティング
- FAQの自動応答
効果:
- 待ち時間の短縮
- サポートコストの削減
- 顧客満足度の向上
具体例:
地方自治体でのゴミ分別の問い合わせ対応に活用されています。
「ペットボトルのキャップは何ゴミですか？」といった質問に、過去のFAQデータベースを検索して即座に回答します。
活用例3:金融業界での文書作成支援
融資稟議書などの文書作成を支援します。
活用シーン:
- 融資稟議書の作成
- リスク評価レポートの作成
- 規制対応文書の作成
効果:
- 作成時間の大幅短縮
- 記載漏れの防止
- 過去の事例の活用
具体例:
過去の融資案件データベースを検索し、類似案件の稟議書を参考に、新しい稟議書を作成します。
活用例4:法律・コンプライアンス
法律文書や規制情報の検索・分析を支援します。
活用シーン:
- 契約書のレビュー
- 法改正情報の確認
- コンプライアンスチェック
効果:
- 調査時間の短縮
- 見落としのリスク低減
- 最新情報への対応
活用例5:技術文書の検索
エンジニアの技術情報検索を支援します。
活用シーン:
- API仕様書の検索
- トラブルシューティングガイド
- 設計書・仕様書の参照
効果:
- 開発生産性の向上
- オンボーディングの効率化
- ナレッジの共有
活用例6:教育・研修
社員教育や学習支援に活用します。
活用シーン:
- 新入社員研修
- 製品知識の学習
- コンプライアンス教育
効果:
- 学習効率の向上
- 個別対応が可能
- 質問のハードルが下がる
RAGシステムの構築に必要な要素
実際にRAGシステムを構築するには、以下の要素が必要です。
必要なコンポーネント
1. データソース:
検索対象となる文書やデータ
2. エンベディングモデル:
テキストをベクトルに変換するAIモデル
3. ベクトルデータベース:
ベクトル化されたデータを保存・検索
4. 検索エンジン:
関連情報を高精度で検索
5. LLM（大規模言語モデル）:
回答を生成するAI
6. オーケストレーションレイヤー:
上記のコンポーネントを統合・制御
主なツール・サービス
エンベディングモデル:
- OpenAI Embeddings（text-embedding-ada-002）
- Google Vertex AI Embeddings
- Hugging Face Sentence Transformers（オープンソース）
- Cohere Embeddings
ベクトルデータベース:
- Pinecone（マネージドサービス）
- Qdrant（オープンソース）
- Chroma（オープンソース）
- Weaviate（オープンソース）
- pgvector（PostgreSQL拡張）
LLM:
- OpenAI GPT-4、GPT-3.5
- Anthropic Claude
- Google Gemini
- AWS Bedrock
- オープンソースLLM（Llama 2、Mistralなど）
統合フレームワーク:
- LangChain（最も人気）
- LlamaIndex
- Haystack
クラウドサービス:
- AWS（Amazon Kendra、Amazon Bedrock）
- Google Cloud（Vertex AI Search）
- Azure（Azure AI Search）
構築の流れ
1. データ準備:
- 文書の収集
- 前処理（クリーニング）
- チャンク分割
2. ベクトル化:
- エンベディングモデルの選定
- 文書のベクトル化
3. データベース構築:
- ベクトルデータベースの選定
- ベクトルの登録
4. 検索システムの構築:
- 検索ロジックの実装
- ランキングの最適化
5. LLMとの統合:
- プロンプトエンジニアリング
- 統合レイヤーの実装
6. テスト・改善:
- 精度の評価
- チューニング
ハイブリッド検索
より高精度な検索を実現するため、「ハイブリッド検索」が注目されています。
ハイブリッド検索とは
ベクトル検索（セマンティック検索）とキーワード検索（BM25など）を組み合わせた検索手法です。
それぞれの長所:
- ベクトル検索:意味の近さで検索（同義語対応）
- キーワード検索:固有名詞・専門用語に強い（完全一致）
なぜハイブリッド検索が必要か
ベクトル検索だけの問題:
- 固有名詞（人名、地名、製品名）の検索精度が低い
- 略語やコード番号の検索が難しい
キーワード検索だけの問題:
- 同義語や言い換えに対応できない
- 文脈を考慮できない
ハイブリッド検索は、両者の長所を活かし、短所を補います。
実装例
多くのベクトルデータベースがハイブリッド検索をサポートしています。
対応データベース:
- Elasticsearch（Elastic Search）
- Weaviate
- Qdrant
- Milvus
よくある質問
RAGに関するよくある質問と回答です。
Q1: RAGとChatGPTのプラグインは何が違いますか？
A: 似ていますが、異なるアプローチです。
ChatGPTのプラグイン:
- OpenAIが用意した仕組み
- 外部APIを呼び出す
- リアルタイムデータの取得が主目的
RAG:
- 自分で構築する仕組み
- ベクトルデータベースから検索
- 社内データや専門知識の活用が主目的
両者は併用も可能で、プラグインでRAGシステムを呼び出すこともできます。
Q2: RAGの精度を上げるにはどうすればいいですか？
A: 以下の方法があります。
データ品質の向上:
- 高品質な文書を用意
- 適切な前処理
- メタデータの充実
チャンク分割の最適化:
- チャンクサイズの調整（通常200〜500トークン）
- オーバーラップの設定
検索精度の向上:
- ハイブリッド検索の採用
- リランキングの実装
- 複数回検索の実施
プロンプトエンジニアリング:
- 効果的なプロンプトテンプレートの作成
- Few-shot learningの活用
Q3: RAGは日本語でも使えますか？
A: はい、日本語でも使用可能です。
日本語対応のエンベディングモデル:
- OpenAI text-embedding-ada-002（多言語対応）
- multilingual-e5シリーズ（日本語に強い）
- Japanese Sentence BERT
ただし、英語に比べて精度が若干低下する場合があります。
日本語専用のモデルを使用することで、精度を向上できます。
Q4: RAGの導入コストはどのくらいですか？
A: 規模によって大きく異なります。
小規模（数千文書）:
- 初期費用:数十万円〜
- 月額費用:数万円〜
中規模（数万〜数十万文書）:
- 初期費用:数百万円〜
- 月額費用:数十万円〜
大規模（数百万文書以上）:
- 初期費用:数千万円〜
- 月額費用:数百万円〜
オープンソースツールを使用することで、コストを大幅に削減できます。
Q5: RAGは個人情報を扱っても大丈夫ですか？
A: 慎重な設計が必要です。
リスク:
- LLMのAPI経由で外部サービスに送信される可能性
- 検索結果に個人情報が含まれる可能性
- ログに個人情報が記録される可能性
対策:
- オンプレミス環境でのRAG構築
- プライベートクラウドの利用
- 個人情報のマスキング処理
- アクセス制御の徹底
個人情報保護法やGDPRなどの法規制に準拠した設計が必要です。
Q6: RAGはどんな業界で使われていますか？
A: ほぼすべての業界で活用可能性があります。
主な活用業界:
- 金融:融資審査、リスク評価
- 医療:診療支援、文献検索
- 法律:判例検索、契約レビュー
- 製造:技術文書検索、品質管理
- 小売:顧客サポート、商品推薦
- 公共:行政サービス案内、FAQ対応
特に、大量の文書データを扱う業界で効果を発揮します。
Q7: RAGとファインチューニングは併用できますか？
A: はい、併用可能です。
併用の利点:
- ファインチューニング:業界特有の表現や口調を学習
- RAG:最新情報や個別の知識を提供
両者を組み合わせることで、より高度なカスタマイズが可能になります。
まとめ:RAGの重要ポイント
RAG（検索拡張生成）について、重要なポイントをまとめます。
RAGとは
大規模言語モデル（LLM）の回答生成時に、外部データベースから関連情報を検索して組み合わせることで、より正確で信頼性の高い回答を生成する技術です。
RAGが解決する3つの課題
- 情報の古さ: 最新情報に即座に対応
- 社内情報の欠如: 非公開データの活用
- ハルシネーション: 誤情報の生成を軽減
RAGの仕組み（3フェーズ）
- 検索（Retrieval）: 関連情報をデータベースから検索
- 拡張（Augmentation）: 検索結果と質問を組み合わせ
- 生成（Generation）: LLMが回答を生成
RAGの主なメリット
- 最新情報への即座の対応
- コスト効率の高さ（再訓練不要）
- 社内情報・専門知識の活用
- 透明性と信頼性の向上
- ハルシネーションの軽減
RAGの主なデメリット
- 検索精度への依存
- 応答時間の増加
- システムの複雑化
- データ準備の手間
ファインチューニングとの違い
| 項目 | RAG | ファインチューニング |
|---|---|---|
| コスト | 低〜中 | 高 |
| 知識の更新 | 簡単 | 困難 |
| 透明性 | 高い | 低い |
| 応答速度 | やや遅い | 速い |
主な活用例
- 社内ヘルプデスク・チャットボット
- 顧客サポート
- 医療分野での情報検索
- 金融業界での文書作成支援
- 法律・コンプライアンス
- 技術文書の検索
構築に必要な要素
- データソース（文書、データ）
- エンベディングモデル
- ベクトルデータベース
- 検索エンジン
- LLM（大規模言語モデル）
- オーケストレーションレイヤー
RAGの今後
RAG技術は急速に進化しており、以下のような発展が期待されています。
技術の進化:
- マルチモーダルRAG（画像、音声、動画への対応）
- より高精度な検索アルゴリズム
- リアルタイム更新への対応強化
活用の広がり:
- AIエージェントとの統合
- 業界特化型RAGシステム
- エッジデバイスでのRAG実装
RAGは、生成AIをビジネスで実用的に活用するための重要な技術として、今後さらに普及していくでしょう。
自社のデータを活用したい、最新情報に対応したい、正確な回答を提供したい。
そんなニーズがある場合、RAGの導入を検討する価値は十分にあります。
コメント