RAG

とっても頭のいい友達がいるとしましょう。でも時々、質問されても100%確信を持って答えられないことがあります。先週起きたことや、すごく細かいことについてとか。

RAGは、その頭のいい友達に本やノートがいっぱい入ったリュックをあげるようなものです。質問に答える前に、リュックの中をサッと調べて正しい情報を見つけることができるんです。そして、今読んだ内容をもとに答えてくれます！

だから、当てずっぽうで答えたり、「たぶんこうだと思う」と言う代わりに、実際に調べてからより良い答えを出せるんです。これがRAGがAIにやらせていること — 返事をする前に「調べ物」ができるようにしているんです。

歴史的背景：「Retrieval-Augmented Generation」という用語は、2020年にFacebook AI Research（現Meta AI）の論文で初めて使われました。この技術が生まれた背景には、GPTのような大規模言語モデル（LLM）の根本的な限界があります：知識が学習時点で固定されてしまうのです。2023年に学習したモデルは、2024年の出来事を知りません。

RAG以前は、2つの世界が別々に存在していました：検索システム（Google検索のような、ドキュメントを見つけるもの）と生成システム（ChatGPTのような、テキストを書くもの）。RAGはこれらを1つのパイプラインに統合しました。

核心となるアイデア：すべての知識をモデルの重みに詰め込もうとする（コストがかかり、古くなる）のではなく、推論時に外部の知識ベースにアクセスさせる。

なぜこれが重要か：

• 正確性：回答が実際のドキュメントに基づいており、「なんとなく」ではない
• 鮮度：再学習なしで知識を更新できる
• 帰属：情報の出典を引用できる
• ドメイン特化：汎用AIを自社ドキュメントの専門家にできる

RAGパイプラインの解説：

1. インデックス作成（オフライン）：ドキュメントを小さなチャンク（通常256〜512トークン）に分割し、エンベディングモデル（OpenAIのtext-embedding-3やBGE、E5などのオープンソース）を使ってベクトル埋め込みに変換します。これらのベクトルはベクトルデータベースに保存されます。

2. 検索（クエリ時）：ユーザーが質問すると、クエリもベクトルに変換されます。システムは類似度検索（コサイン類似度、内積）を実行し、最も関連性の高いk個のドキュメントチャンクを見つけます。

3. 拡張：取得したチャンクがLLMのプロンプトにコンテキストとして挿入されます。典型的な形式：「以下のドキュメントに基づいて：[チャンク]。ユーザーの質問に答えてください：[クエリ]」

4. 生成：LLMが提供されたコンテキストに基づいて回答を生成します。

主要な技術コンポーネント：

• エンベディングモデル：テキストを意味を捉えた密なベクトルに変換
• ベクトルデータベース：類似度検索に最適化された専用DB（Pinecone、Weaviate、Chroma、pgvector）
• チャンキング戦略：ドキュメントの分割方法 — 文、段落、または意味的な境界で
• リランキング：取得したチャンクの関連性を再スコアリングする第2段階モデル

高度なRAGパターン：

ハイブリッド検索：密なベクトル検索とスパースな語彙検索（BM25）の組み合わせ。密な検索は意味的類似性を捉え（「車」が「自動車」にマッチ）、スパース検索は完全一致に優れる（製品コード、名前）。本番システムでは両方を使うことが多い。

クエリ変換：検索前にユーザークエリを変換して結果を改善：

• HyDE（Hypothetical Document Embeddings）：仮の回答を生成し、その回答に似たドキュメントを検索
• クエリ拡張：同義語や関連用語を追加
• クエリ分解：複雑な質問をサブ質問に分割

エージェンティックRAG：単一の検索→生成ステップではなく、エージェントが反復的に判断：「もっと情報が必要？別のソースを検索すべき？この回答は完全？」複雑なマルチステップ推論に対応。

マルチモーダルRAG：テキスト以外に画像、表、構造化データへの検索拡張。GPT-4Vのようなモデルは取得した画像を処理可能。テーブル検索には特別な処理（text-to-SQL、構造化抽出）が必要。

評価指標：

• 検索：Recall@k、MRR（Mean Reciprocal Rank）、NDCG
• 生成：忠実性（回答がソースと一致しているか）、関連性、完全性
• エンドツーエンド：回答の正確性、人間の選好スコア

GraphRAGと構造化検索：

Microsoft ResearchのGraphRAG（2024）は、検索前にソースドキュメントからナレッジグラフを構築します。複数ドキュメントにまたがる統合が必要なクエリ（「すべての顧客クレームに共通するテーマは？」）では、グラフ走査がフラットなベクトル検索を上回ります。グラフはベクトル類似度では見逃される関係性を捉えます。

ファインチューニング vs RAGのトレードオフ：

• ファインチューニング：スタイル/フォーマットに優れ、推論が高速、検索レイテンシなし。但しコスト高、知識が古くなる、更新困難
• RAG：更新容易、帰属可能、ロングテール知識に対応。但しレイテンシ追加、検索失敗の可能性、コンテキストウィンドウ制限
• ハイブリッド：本番システムではドメインスタイルでベースモデルをファインチューニングしつつ、事実の根拠付けにRAGを使用することが多い

検索拡張事前学習（RETRO、REALM）：

推論時のみに検索を追加するのではなく、これらのアーキテクチャは学習中に検索を組み込みます。モデルは後付け機能としてではなく、コア推論の一部として取得ドキュメントを使用することを学習。

Self-RAGと適応的検索：

Self-RAG（2023）は、いつ検索するか（すべてのクエリに必要ではない）を決定し、出力の忠実性を批評するようモデルを訓練。不要な検索呼び出しを減らし、回答品質を向上。

本番環境の考慮事項：

• レイテンシ予算：エンベディング + ベクトル検索 + リランキング + 生成で200〜500ms追加
• コスト：100万ドキュメントのエンベディング、ベクトル保存、大きなコンテキストでのLLM推論
• セキュリティ：アクセス制御 — このユーザーはこれらの取得ドキュメントを見られるか？
• 可観測性：検索品質のログ、帰属追跡、フィードバックループ