Zenn
🙄

RAGの仕組みを超シンプルに解説

に公開
ChatGPT
LLM
生成 AI
Claude
RAG
idea

はじめに

最近よく見かけるQ&Aシステムやドキュメント検索AI、あれってどうやって作ってるんだろう？

「膨大な技術文書について、ChatGPTみたいに自然に質問できたらいいのに...」「でも全部の文書をAIに学習させるなんて無理だよね？」

そんな疑問を持ったことはありませんか？

実は、こうしたシステムの多くで使われているのがRAG（Retrieval-Augmented Generation）という技術です。LLMを「賢い専門家」として使いつつ、「優秀な司書」が情報を厳選して渡す、とても興味深いアプローチなんです。

本記事では、RAGの概念と仕組みを、技術的な背景を含めながら誰でも理解できるように解説します。

RAGとは何か？

一言で表すと

RAG = 「質問に応じて関連資料を自動選択してLLMに送る仕組み」

これまで人間がやっていたこと：
「この技術文書を読んで、○○について教えて」

RAGが自動化したこと：
「質問内容に応じて、技術文書内の関連性のある箇所を抽出 → 質問と一緒にLLMに送信」
この辺に答えがありそうという目星をつけて送り、詳細な回答はLLMにお任せするという発想

司書と専門家のチームワークに例えると

従来の方法：図書館の全ての本を専門家（LLM）に渡して「この中から答えを見つけて」

  • 専門家が情報過多で overwhelm、時間がかかる、焦点がぼやける

RAGの方法：司書（RAGシステム）が質問を聞いて関連する3冊を厳選 → それを専門家（LLM）に渡して分析

  • 専門家が効率的に分析、速い、的確

つまり：

  • 司書（RAGシステム）：膨大な情報から関連するものだけを素早く見つける
  • 専門家（LLM）：厳選された情報を深く分析して回答を作成

なぜRAGが必要なのか？

1. 物理的制約の問題

ナレッジ全体：200,000トークン
LLMの制限：128,000トークン
結果：そもそも全文が入らない

2. コスト効率の問題

全文送信：1回$2（月1000回で$2,000）
部分送信：1回$0.03（月1000回で$30）
差額：66倍のコスト差

※上記は概算例です。実際のコストはAPIの料金体系、文書量、使用頻度により大きく変動します。

3. 回答品質の問題

全文送信：95%がノイズ（無関係な情報）
部分送信：90%が有用情報（厳選された情報）
→ LLMが迷わず、的確な回答に集中できる

RAGの仕組み：技術的な詳細

前提知識：コンピューターはどうやって「似ている文章」を見つけるのか？

1. 文章をベクトル（数値）に変換

人間の理解：「犬」と「猫」は似ている（どちらもペット）
コンピューターの理解：「犬」= [0.2, 0.8, 0.1, 0.9, ...]（数値の配列）

「犬を飼いたい」    = [0.2, 0.8, 0.1, 0.9, 0.3]
「猫を飼いたい」    = [0.3, 0.7, 0.2, 0.8, 0.4]  ← 数値が似てる！
「車を買いたい」    = [0.9, 0.1, 0.8, 0.2, 0.7]  ← 数値が全然違う

2. セマンティック検索の威力

従来の検索（キーワードマッチング）

  • 「重い」で検索 → 「重要な設定」「重量計算」「重複データ」など無関係な情報も混在

RAGの検索（意味理解）

  • 「重い」の意味を理解 → 「パフォーマンス」「遅い」「最適化」など関連概念で検索

RAGの処理フロー

事前準備フェーズ（一回だけ）

1. 文書群を小さな単位（チャンク）に分割
   「React開発ガイド.pdf（500ページ）」
   ↓
   「セットアップ手順」「コンポーネント設計」「パフォーマンス最適化」...

2. 各チャンクをベクトル（数値）に変換
   「パフォーマンス最適化」 → [0.1, 0.8, 0.3, 0.9, 0.2, ...]

3. ベクトルデータベースに保存
   検索可能な状態で保管

質問回答フェーズ（毎回）

1. ユーザーの質問をベクトルに変換
   「Reactアプリが重い」 → [0.2, 0.7, 0.4, 0.8, 0.3, ...]

2. データベースで類似ベクトルを検索
   質問ベクトルと保存済みベクトルの距離を計算
   最も近い3-5個のチャンクを発見

3. 関連文書を取得
   「パフォーマンス最適化」「メモリリーク対策」「レンダリング改善」

4. 「参考文書 + 質問」をLLMに送信
   ---
   参考文書：
   パフォーマンス最適化では...
   メモリリーク対策では...
   
   質問：Reactアプリが重いです
   ---

5. LLMが回答を生成
   文脈を理解した包括的な回答

従来の方法との具体的な比較

シナリオ：「Reactアプリのパフォーマンス改善」について質問

MCPアプローチ（従来の構造化API）

1. 「パフォーマンス」で検索 → ドキュメント群A
2. 「React」で検索 → ドキュメント群B  
3. 「最適化」で検索 → ドキュメント群C
4. LLMが手動で情報を統合
5. 関連性の薄い情報も混在
6. コンテキスト長を大量消費

問題点：

  • 事前に定義されたパラメータでしか検索できない
  • 意味を理解しない文字列マッチング
  • 情報統合の負荷がLLMに集中

RAGアプローチ

1. 「Reactアプリが重い」の意味を理解
2. 自動的に関連情報を収集・統合：
   - React特有のパフォーマンス問題
   - メモリリーク対策
   - レンダリング最適化
   - 状態管理のベストプラクティス
3. 文脈に沿った包括的な回答を即座に生成

優位性：

  • 曖昧な質問でも意味を理解して対応
  • 文脈を保持した連続した会話
  • 自動的な情報統合

RAGの特徴

メリット

  • 意味理解検索：キーワードが違っても関連する情報を発見
  • 効率的な処理：必要な情報だけを選んで高速回答
  • コスト削減：全文送信より大幅に安価

注意点

  • 文書の準備（ベクトル化）に手間がかかる
  • 検索精度の調整が必要

まとめ

RAG = 「賢い司書 + 専門家」の組み合わせ

よく見るQ&Aシステムの多くは、この仕組みで動いています。膨大な文書から関連部分だけを自動で見つけて、LLMに分析させる。シンプルだけど強力なアイデアです。

「全部の情報をAIに渡すのは無理」→「関連する情報だけを賢く選んで渡そう」

この発想の転換が、RAGの核心なのです。

この記事では、RAGの概念と仕組みについて解説しました。実際にRAGシステムを構築する具体的な実装方法については、次回の【実装編】で、Pythonを使った簡単なサンプルコードとともに詳しく解説する予定です。お楽しみに！

Discussion