本番環境で実際に機能する retrieval-augmented generation システムを構築する。アーキテクチャの決定から評価フレームワークまで、信頼性の高い RAG システムを出荷するために必要なすべてを本ガイドが網羅する。
Retrieval-Augmented Generation (RAG) は、外部の知識ソースから関連する文脈を提供することで大規模言語モデルを強化するアーキテクチャパターンである。モデルの学習データのみに依存する代わりに、RAG は推論時に関連ドキュメントを検索し、それを用いてモデルの応答を根拠づける。
このアプローチは、LLM のいくつかの根本的な制約を解決する：
ただし、RAG システムはその実装次第である。不適切なチャンク化、不十分な検索、ずれたプロンプトは、素の LLM と同程度にハルシネーションを起こすシステムを生み — しかも誤った自信を伴う。本ガイドは機能するパターンを扱う。
本番環境の RAG システムは6つの中核コンポーネントから成り、それぞれに固有の最適化上の考慮事項がある。これらのコンポーネントを理解することは、スケールするシステムを構築するうえで不可欠である。
さまざまな形式のソースドキュメントを読み込み、前処理する
ドキュメントを意味的にまとまりのあるチャンクに分割する
テキストチャンクを密なベクトル表現に変換する
効率的な検索のために embeddings を保存・インデックス化する
与えられたクエリに対して関連チャンクを見つける
検索された文脈を用いて回答を生成する
本番システムでは、取り込みパイプラインをクエリパイプラインから分離する。取り込みは非同期（バッチ処理、キュー）で実行できる一方、クエリは低レイテンシの同期実行を必要とする。この分離により独立したスケーリングが可能になる。
チャンク化は RAG において成否を分ける決定であることが多い。不適切なチャンク化は無関係な検索と不完全な文脈につながる。適切な戦略はドキュメントの種類とクエリのパターンに依存する。
| 戦略 | 最適な用途 | トレードオフ | 複雑さ |
|---|---|---|---|
| 固定サイズ | 単純なドキュメント、一貫した構造 | 意味単位を分断する可能性 | Low |
| 文ベース | 自然言語コンテンツ | 可変的なチャンクサイズ | Medium |
| 意味的 | 複雑なドキュメント、多様なトピック | より高い計算コスト | High |
| 階層的 | 長いドキュメント、多階層検索 | 複雑な実装 | High |
Embeddings はテキストを意味を捉えた数値ベクトルに変換する。適切な embedding モデルとベクトルデータベースの選択は、検索品質・レイテンシ・コストに影響する。
| モデル | 次元数 | 性能 | コスト | 備考 |
|---|---|---|---|---|
| OpenAI text-embedding-3-large | 3072 | 優秀 | $$ | 総合品質が最高、次元削減に対応 |
| Cohere embed-v3 | 1024 | 非常に良い | $$ | 多言語対応、圧縮オプション |
| Voyage AI | 1024 | 優秀 | $$$ | ドメイン特化モデルが利用可能 |
| BGE-large | 1024 | 良い | Free | オープンソース、セルフホスト可能 |
| Mistral Embed | 1024 | 非常に良い | $ | 欧州プロバイダー、GDPR フレンドリー |
クイックスタート、マネージドインフラ
ハイブリッド検索、GraphQL API
性能、きめ細かなフィルタリング
開発、プロトタイピング
既存の Postgres インフラ
基本的な意味検索は出発点にすぎない。本番システムは関連性を最大化するために複数の検索戦略を用いる。
密なベクトル検索と疎なキーワード検索（BM25）を組み合わせる。これにより、ベクトル検索が見逃す可能性のある意味的一致と完全なキーワード一致の双方を捉える。
クロスエンコーダーモデルを用いて初期の検索結果を再ランク付けする。コストは高いが、top-k 結果の関連性を大幅に向上させる。
LLM を用いて複数のクエリのバリエーションを生成するか、複雑なクエリをサブクエリに分解する。それぞれについて検索し、結果をマージする。
ベクトル検索の前にメタデータ（日付、ソース、カテゴリ）で事前フィルタリングする。大規模なドキュメントコレクションやマルチテナントシステムに不可欠である。
生成フェーズは、検索された文脈を一貫した回答へと統合する。プロンプトエンジニアリングとコンテキスト整形は品質に不可欠である。
128k+ のコンテキストウィンドウであっても、文脈は多ければよいとは限らない。研究によれば、LLM は長い文脈の「中間」にある情報を扱うのが苦手である。検索された文脈を 3-5 個の高関連チャンクに絞り、reranking を用いて量より質を確保すること。
測定しないものは改善できない。本番環境の RAG システムは、複数の次元にわたる継続的な評価を必要とする。
| 指標 | 説明 | 目標 | 測定方法 |
|---|---|---|---|
| 検索精度（Precision） | 検索されたチャンクのうち関連するものの割合 | > 80% | 検索結果の手動ラベリング |
| 検索再現率（Recall） | 関連チャンクのうち検索されたものの割合 | > 90% | グラウンドトゥルースデータセットとの比較 |
| 回答の関連性 | 回答がクエリにどれだけ適切に対応しているか | > 85% | LLM-as-judge または人手評価 |
| 忠実性（Faithfulness） | 回答が検索された文脈に根拠づけられているか | > 95% | 主張の抽出と検証 |
| レイテンシ（P95） | エンドツーエンドの応答時間 | < 3s | パフォーマンス監視 |
忠実性、関連性、コンテキスト再現率の指標を備えた RAG 評価向けのオープンソースフレームワーク。
トレーシング、評価、プロンプトのバージョン管理を備えた本番環境向けオブザーバビリティ。
プロトタイプから本番への移行には、信頼性、セキュリティ、運用上の課題への対処が必要である。
基本的な RAG を超えて、これらのパターンは特定のユースケースに対応し、可能性の限界を押し広げる。
エージェントループを用いて検索を反復的に洗練する。エージェントは、いつ検索するか、何を検索するか、回答に十分な文脈が得られたかを判断できる。
複雑で多段階の質問に最適ドキュメントから知識グラフを構築し、検索時に関係をたどる。マルチホップ推論とエンティティ中心のクエリを可能にする。
関係を持つ構造化ドメインに最適検索が必要なタイミングを判断し、検索の関連性を評価し、生成された応答を自己批評するようモデルを学習またはプロンプトする。
不要な検索を低減検索品質を評価し、内部知識が不十分または信頼できない場合に Web 検索や他のソースにフォールバックする。
エッジケースのカバレッジを改善