【生成AI入門】「RAG」をできるだけわかりやすく解説してみる


## はじめに

現在、IT業界では生成AIが非常に盛り上がっており、エンジニアとして避けて通れない技術だと考えます。そのため、生成AIのことをいろいろと調べて学んでいきたいと思います。

今回は、「 RAG（Retrieval-Augmented Generation）」について、できるだけわかりやすく解説していきたいと思います。

「RAGって何？」「どうして必要なの？」という基本的なところから、「どうやって実装するの？」というところまで、順を追って説明していきます。

## RAGって何？

まずは、RAGを超簡単に説明すると

:::note info
**AIに自分の持っている情報を教えて、それを使って回答してもらう仕組み**
:::

です。

::: note warn
正式名称は「**Retrieval-Augmented Generation**」(リトーリバル・オーグメンテッド・ジェネレーション）
「**RAG**」は各ワードの先頭文字の略語である
- 日本語では「検索拡張生成」「取得拡張生成」と訳される
- 「検索機能」と「生成AI」を組み合わせた技術のこと
- *Retrieval*（リトーリバル）
    - 「検索」を意味する
    - 原義は「再び見つける」であり、大量のデータ群から目的に合致したものを取り出すことを意味していいる
- *Augmented*（オーグメンテッド）
    - 「増加した」や「拡張された」という意味を持つ形容詞
- *Generation*（ジェネレーション）
    - 「生成」を意味する
:::

### RAGのわかりやすい例え

RAGの意味を理解しやすいように、わかりやすい例えを行います。

あなたは図書館の司書だとします。
司書であるあなたは、図書館の利用者から質問を受けたとき、

1. まずは関連する本や資料を探す
　（Retrieval：検索）
2. それらの情報を基に、質問に対する回答を作成する
　（Generation：生成）

というステップで回答を行うかと思います。

RAGとは、まさにこのような「図書館の司書」のような働きをするものです！

## なぜRAGが必要なのか？

### 従来のAIの限界

GPT-4などの大規模言語モデル（LLM）は非常に賢いが、以下のようにいくつか課題があります。

1. **知識の更新ができない**
   - 学習済みの情報しか知らない
   - 最新情報や専門的な情報には対応できない
　
2. **幻覚（ハルシネーション）の問題**
   - 自信満々に間違った情報を話すことがある
   - 特に具体的な事実に関して信頼性に欠ける
　
3. **情報ソースの透明性がない**
   - どこからその情報を得たのかわからない

### RAGを使うと

RAGを使うことで、これらの問題を解決できます。

1. **最新の情報を使える**
   - 自分のデータを追加できる
   - 必要な情報を都度更新できる
　
2. **より正確な回答**
   - 与えられた情報源に基づいて回答
   - 幻覚（ハルシネーション）を減らせる
　
3. **情報源の明確化**
   - どの情報を参照したか明確になる
   - 回答の根拠が示せる

## RAGの仕組み

RAGでは、大きく３つのステップに分かれて処理が行われます。
飲食店のメニュー開発を例にして、RAGの仕組みを分かりやすく説明します。

1. **知識ベースを準備する**
    - 飲食店には「レシピノート」と呼ばれるものがあり、レシピノートには、材料や調理方法、お客様の反応など、たくさんの情報が書かれています。
    - RAGでは、このレシピノートのように、必要な情報（文書やデータ）を事前に準備し、それらを小さな単位に分けて、コンピュータが理解しやすい形（＝ベクトル）に変換して保存します。
これが「知識ベース」となります。
　
2. **情報を検索する**
    - オーナーからシェフに「新しい夏メニューを考えて欲しい」という依頼があったとします。
シェフは、まずレシピノートの中から「夏」「季節メニュー」「冷たい料理」などの関連情報が書かれているページを探します。
    - RAGでも同じように、質問の内容に関連する情報を知識ベースから探し出します。
これは、質問をレシピノートと同じようにコンピュータが理解しやすい形に変換（ベクトル化）して、似ている情報を見つけ出すことで実現しています。
　
3. **回答を生成する**
    - シェフは、見つけた情報（過去の夏メニューの売れ行き、お客様の好み、季節の食材など）を参考にしながら、新しいメニューのアイデアを考えます。
    - RAGでも、AI（LLM）が検索で見つけた関連情報を参考にしながら、質問に対する回答を作成します。
```mermaid
graph TD
    subgraph "1.知識ベースの準備"
        A[レシピノート] --> B[情報を整理]
        B --> C[データ化]
        C --> D[(レシピ・データベース)]
        
        A1[過去の売上データ] --> B
        A2[お客様の声] --> B
        A3[季節の食材情報] --> B
    end
    
    subgraph "2.関連情報の検索"
        E[新しい夏メニューを<br>考えたい] --> F{情報検索}
        D --> F
        F --> G[関連情報の抽出]
        
        G --> H1[去年の夏メニュー<br>の売れ筋]
        G --> H2[夏に人気の食材]
        G --> H3[お客様の好み]
    end
    
    subgraph "3.アイデア創出"
        H1 --> I[AIシェフ]
        H2 --> I
        H3 --> I
        I --> J[新メニューの提案]
    end

    style A fill:#4CAF50,color:#fff
    style A1 fill:#4CAF50,color:#fff
    style A2 fill:#4CAF50,color:#fff
    style A3 fill:#4CAF50,color:#fff
    style D fill:#FF9800,color:#000
    style E fill:#2196F3,color:#fff
    style I fill:#E91E63,color:#fff
    style J fill:#9C27B0,color:#fff
    
    classDef default fill:#333,stroke:#666,stroke-width:2px,color:#fff
    classDef section fill:#424242,stroke:#666,stroke-width:2px,color:#fff
```

### 飲食店でのメニュー開発例での具体的内容
```mermaid
flowchart LR
    subgraph Input[入力情報]
        A1[過去の夏メニュー<br>冷やし担々麺 売上120食/日<br>評価：⭐️⭐️⭐️⭐️]
        A2[お客様の声<br>「辛さを調整できると嬉しい」<br>「夏でも食べやすい」]
        A3[季節の食材<br>トマト・きゅうり<br>バジル・レモン]
    end

    subgraph Process[分析と検討]
        B[情報統合]
        C{考慮ポイント}
        D1[暑い季節に合う味]
        D2[カスタマイズ可能]
        D3[季節感のある見た目]
    end

    subgraph Output[提案内容]
        E[新メニュー案:<br>冷製トマトラーメン]
        F1[特徴:<br>・辛さ3段階から選択可<br>・季節野菜をトッピング<br>・さっぱりした味わい]
        F2[価格設定根拠:<br>・原価率と競合分析<br>・想定客単価]
    end

    Input --> Process
    Process --> Output

    style A1 fill:#4CAF50,color:#fff
    style A2 fill:#4CAF50,color:#fff
    style A3 fill:#4CAF50,color:#fff
    style E fill:#E91E63,color:#fff
    style F1 fill:#9C27B0,color:#fff
    style F2 fill:#9C27B0,color:#fff
    
    classDef default fill:#333,stroke:#666,stroke-width:2px,color:#fff
    classDef section fill:#424242,stroke:#666,stroke-width:2px,color:#fff
```

### この仕組みの利点

1. **正確な回答**
    - レシピノートという確かな情報源があるので、シェフは自分の記憶だけに頼らず、正確な情報を基に新メニューを考えられる
    - RAGも同様に、用意された知識ベースを基に回答するので、より正確な情報を提供できる
　
2. **最新情報の反映**
    - レシピノートは随時更新できるように、RAGの知識ベースも必要に応じて新しい情報を追加できる
　
3. **情報の根拠が明確**
    - シェフが「このメニューを提案した理由は、去年の夏に似たメニューが人気だったからです」と説明できるように、RAGも提供した情報の出所を示すことができる

:::note info
このように、RAGは「確かな情報源を基に、AIが回答を作成する」仕組みだと言える。
人間が知識を参照しながら考えるのと同じような、自然な流れで動作するシステムとなっている。
:::

## RAGの限界やデメリット

飲食店のメニュー開発を例として、RAGの限界やデメリットを整理すると以下のようになります。

1. **知識ベースの品質に依存する問題**
    - レシピノートの記録の質
        - 記録が曖昧だと（「適量」「程よく」など）、AIは正確な情報を得られない
        - 重要な情報が書き忘れられていると、その情報は永久に欠落する
        - 矛盾する情報があると（あるページでは「人気メニュー」、別のページでは「不評」など）、AIは混乱する
　
2. **検索精度の課題**
    - 関連情報の取りこぼし
        - 「夏メニュー」を探す時に「暑い日にピッタリ」という表現を見落としてしまう
        - 逆に、「冷たい」という表現だけで冬の「冷たいデザート」まで拾ってしまう
        - 文脈を正確に理解できず、的外れな情報を関連情報として抽出してしまう
　
3. **コストとリソースの問題**
    - デジタル化のコスト
        - 全てのレシピノートをデジタル化する手間と時間
        - レシピノートのデータを整理・更新し続けるための人的リソース
        - ベクトルDBの維持管理コスト
        - 大量のデータを処理するための計算コスト
　
4. **レスポンス速度の課題**
    - メニュー開発会議での使用
        - その場ですぐに答えが欲しい時でも、ステップに沿った処理が必要となる
        - 従来のAIと比べて、応答時間が長くなりがちである
　
5. **システムの複雑さの問題**
    - システムのメンテナンス難易度
        - 多くの構成要素（データベース、検索エンジン、LLMなど）を管理する必要がある
        - 各要素のバージョン管理や互換性の維持が必要
        - トラブル発生時の原因特定が難しい
　
6. **データの更新と鮮度の課題**
    - 季節メニューの情報更新
        - 新しい情報を追加する度に、ベクトル化やインデックス更新が必要である
        - リアルタイムの更新が難しい
        - 古い情報の削除や更新の判断が難しい
　
7. **セキュリティとプライバシーの懸念**
    - 機密レシピの管理
        - 秘伝のレシピなど、機密情報の管理が必要である
        - 競合他社の情報と混ざらないよう注意が必要である
        - アクセス権限の適切な管理が必要である
　
8. **カスタマイズの難しさ**
    - 店舗ごとの特性への対応
        - 各店舗の特性（客層、立地など）に応じた情報の重み付けが難しい
        - 地域性や季節性を適切に反映させることが課題
        - 例外的なケースへの対応が困難

### 対策のポイント

1. **データの品質管理**
   - 情報の正確性と一貫性を確保する
   - 定期的にデータのクリーニングを行う
   - 標準フォーマットを整備する
　
2. **段階的な導入**
   - 小規模な範囲から始める
   - 効果を確認しながら拡大していく
   - ユーザーフィードバックを収集する
　
3. **ハイブリッドアプローチ**
   - 従来の方法とRAGを併用する
   - 人間による確認プロセスを維持する
   - 用途に応じて使い分ける

:::note info
これらの限界やデメリットを理解した上で、適切な用途と運用方法を選択することが、RAGを効果的に活用するポイントとなる。
:::

## RAGシステムを作る時のポイント

飲食店のメニュー開発を例として、RAGシステムを作る際のポイントを、以下に整理します。

1. **情報の「切り分け方」を工夫する**
    - レシピの記録方法
        - 良い例
            - 1つのレシピごとに分ける
            - 材料・作り方・コツを1セットにする
        - 悪い例
            - 材料だけを切り出す
            - 複数のレシピを1つにまとめすぎる
　
2. **情報を扱う「AI」の選定を工夫する**
    - レシピを理解するAIの性能コストバランスを考える
        - 考慮すべきポイント
            - 和食レシピが得意なAI
            - アレルギー食材を正確に認識できるAI
            - 予算に見合ったAI
        - バランス
            - 「高機能で高額なAI」vs「シンプルで安価なAI」
　
3. **AIへの「指示の出し方」（プロンプト）を工夫する**
    - 新メニュー開発での指示
        - 良い指示
            - 「夏向けの、辛さ調整可能で、見た目が涼しげな麺料理を考えて」
        - 曖昧な指示
            - 「夏っぽいメニューを考えて」

## RAGのユースケース

RAGは以下のような場面で特に効果を発揮します。

1. **社内の質問応答システム**
   - 社内規定やワークフローの案内
     - 「有給休暇の申請方法を教えて」
     - 「経費精算の書類はどこ？」
   - 新入社員の業務サポート
     - 「この業務の担当部署は？」
     - 「社内システムの使い方は？」
   - 技術ナレッジの共有
     - 「似たような不具合の対応例は？」
     - 「この機能の仕様を教えて」
　
2. **カスタマーサポート**
   - 製品の使い方案内
     - 「この機能の使い方を教えて」
     - 「エラーの対処方法は？」
   - よくある質問への自動回答
     - 「返品の方法について」
     - 「保証期間はいつまで？」
   - トラブル解決支援
     - 「製品が動かない時の確認手順」
     - 「エラーコードの意味と対処法」
　
3. **ドキュメント検索・要約**
   - 法務文書の確認
     - 「この契約書の重要なポイントは？」
     - 「類似の契約書との違いは？」
   - 研究論文の分析
     - 「この研究テーマの最新動向は？」
     - 「関連する研究成果の要約」
   - 市場調査レポートの活用
     - 「競合他社の動向まとめ」
     - 「市場トレンドの分析」
　
4. **医療・診療支援**
   - 診療情報の検索
     - 「類似症例の治療法は？」
     - 「最新の治療ガイドライン」
   - 医薬品情報の提供
     - 「この薬の副作用について」
     - 「併用注意の薬剤は？」
   - 患者説明資料の作成
     - 「この病気の分かりやすい説明」
     - 「治療計画の説明資料」
　
5. **教育・学習支援**
   - 個別学習サポート
     - 「この問題の解き方のヒント」
     - 「関連する学習資料の紹介」
   - 教材作成支援
     - 「この単元の練習問題案」
     - 「補足説明資料の作成」
   - 研究サポート
     - 「関連論文の検索と要約」
     - 「研究テーマの動向分析」

## まとめ

RAGは、大規模言語モデル（LLM）によるテキスト生成に、外部情報の検索を組み合わせることで、解答の精度を向上させる技術となります。
RAGを活用することで、生成AIだけでは解決出来ない課題を実現することができるようになります。