Retrieval-Augmented Generation（RAG）は、エンタープライズAIアプリケーションのデフォルトアーキテクチャになっています。LLMで構築している企業に聞けば、おそらくRAGシステムを構築しています。
しかし、不都合な真実があります。デモで動作するほとんどのRAGシステムは、本番環境で失敗します。
デモでは、キュレーションされたテストセットから3つの関連文書を取得します。本番環境では、1,000万のノイズの多い文書から3つの無関係な文書を取得します。モデルはハルシネーションを起こします。ユーザーは信頼を失います。プロジェクトは失敗します。
私は数十の本番RAGシステムを監査してきました。失敗パターンは驚くほど一貫しており、驚くほど修正可能です。
基本的なトレードオフ
すべてのRAGシステムは、精度と再現率のスペクトル上に存在します。
**高精度**：取得された文書は非常に関連性が高いが、良いものを見逃す可能性がある。
**高再現率**：ほとんどの関連文書をキャプチャするが、一部の無関係なものを含む。
LLMはある程度無関係なコンテキストをフィルタリングできますが、レイテンシーと精度のコストがかかります。適切なバランスはユースケースによって異なります。
チャンキング戦略
文書をチャンクに分割する方法は、検索品質に大きな影響を与えます。核心的な緊張関係：
再帰的チャンキング
最も堅牢な汎用アプローチ。高レベルのセパレータ（段落、セクション）から始め、チャンクが大きすぎる場合は再帰的に分割します。研究によると、100トークンのベースサイズを持つ再帰的トークンベースのチャンキングは、他の代替案を一貫して上回ります。
セマンティックチャンキング
構造ではなく、意味に基づいて分割します。文の類似性を分析し、トピックが変わる場所でチャンクを作成します。意味を保持しますが、追加の埋め込み計算が必要です。
構造認識メソッド
構造化された文書（Markdown、HTML、明確なヘッダーを持つPDF）の場合は、構造認識スプリッターを使用します。これはしばしば行える最大の単一の改善です。ヘッダーは自然なセマンティック境界を提供します。
チャンキングしない場合
ユーザーの質問に直接回答する小さく焦点を絞った文書は、チャンキングが必要ない場合があります。これらの文書をチャンキングすると、実際に検索が悪化する可能性があります。
埋め込み選択
埋め込みモデルはテキストをベクトルにマッピングします。このマッピングの品質が検索品質を決定します。
汎用オプション
ドメイン固有のファインチューニング
専門ドメイン（法律、医療、技術）では、ドメインデータで埋め込みをファインチューニングすると、検索が劇的に改善される可能性があります。10,000件のドメイン固有のサンプルでも、パフォーマンスを有意義に向上させることができます。
多言語の考慮事項
文書が複数の言語にまたがる場合、多言語埋め込みが必要です。Cohereの多言語埋め込みやBGE-M3などのオプションがこれをうまく処理します。
検索戦略
ベクトル検索だけでは不十分
セマンティック検索は強力ですが、盲点があります。名前、コード、希少な用語の完全一致を見逃す可能性があります。ハイブリッド検索（ベクトル類似性とBM25キーワードマッチングの組み合わせ）は、セマンティックな関連性と完全一致の両方をキャプチャします。
リランキング
初期検索は高速ですが不正確です。リランキングモデル（Cohere Rerank、ColBERT）は上位k件の結果を取得し、関連性で並べ替えます。これは計算コストが高いですが、精度を大幅に向上させます。
メタデータフィルタリング
セマンティック検索の前にメタデータを使用して検索を絞り込みます。ユーザーが2024年の契約について質問していることがわかっている場合は、最初に2024年の契約にフィルタリングします。これにより精度が向上し、計算が削減されます。
本番アーキテクチャ
キャッシング
頻繁なクエリをキャッシュします。100人のユーザーが休暇ポリシーについて質問する場合、一度だけ検索します。キャッシュ無効化戦略が重要です。新鮮さとコストのバランスを取ってください。
非同期処理
リアルタイムではないアプリケーションの場合、検索を非同期で処理します。クエリをキューに入れ、バッチ処理し、コールバックで結果を返します。
監視
すべてを追跡します。
監視なしでは最適化できません。
グレースフルデグラデーション
検索が失敗したらどうなるか？LLM APIがタイムアウトしたら？フォールバック動作を設計します。キャッシュされた応答、人間へのエスカレーション、透明なエラーメッセージ。
一般的な失敗モード
過剰検索
多すぎるチャンクを検索すると、コンテキストウィンドウがわずかに関連する情報で埋まり、良いものが希薄化します。少ないチャンク（3-5）から始め、必要な場合のみ増やします。
不十分なクエリ前処理
ユーザークエリはしばしば曖昧で、スペルミスがあり、会話的です。検索前にクエリを前処理します。略語を展開し、スペルを修正し、文として書き直します。
文書品質の無視
RAGは投入したものを検索します。文書コーパスが古く、矛盾があり、品質の低いコンテンツで満ちている場合、RAGシステムは自信を持ってそれを引用します。文書キュレーションは検索最適化よりも重要なことがよくあります。
一律のアプローチ
異なるクエリタイプは異なる戦略から恩恵を受けます。事実の検索は精度が必要です。探索的な質問は幅が必要です。異なる検索構成にクエリをルーティングすることを検討してください。
本番への道
ステップ1：評価データセットを構築
最適化する前に、良いものがどのようなものかを知ってください。人間が検証した正しい回答を含む100以上のクエリ-回答ペアのデータセットを構築します。このデータセットに対してすべての変更を実行します。
ステップ2：ベースライン指標を確立
現在のパフォーマンスを測定します：精度、再現率、レイテンシー、コスト。測定しないものは改善できません。
ステップ3：体系的に反復
一度に1つのことを変更します。影響を測定します。うまくいくものは維持し、うまくいかないものは破棄します。すべてを一度に変更する誘惑に抵抗してください。
ステップ4：本番環境で監視
本番データは評価データと異なります。検索品質を継続的に監視します。障害を特定するためのフィードバックループを構築します。
ステップ5：継続的改善
RAGシステムは、文書コーパスが進化するにつれて時間とともに劣化します。定期的な再インデックス作成と再評価をスケジュールします。
結論
RAGは解決済みの問題ではありません。本番スケールで確実に動作するRAGシステムを構築するには、チャンキング、埋め込み、検索、監視にわたる慎重なエンジニアリングが必要です。
良いニュースは、技術はよく理解されているということです。難しい作業は、デモがスケールすることを期待するのではなく、それらを体系的に適用することです。