概要
- 多くのRAGスタックは 過剰設計 されがちで、ユーザーのニーズに合っていない場合が多い
- 検索要件 ごとに最適な技術選択が重要
- BM25や全文検索 は多くのケースで十分な効果
- 埋め込み・ベクタDB は必要性を見極めて段階的に導入
- クエリリライト・ハイブリッド検索 など柔軟なアプローチが有効
RAGスタック設計の原則と最適化
- AI検索システム でも「適材適所」の原則が重要
- まずは ユーザーの本当のニーズ （例：「パスワードリセット方法」）を把握
- 過剰な技術導入 （埋め込み、ベクタDB、再ランキング等）は段階的に検討
- 主要な判断軸は以下の5点
- データ鮮度要件 ：リアルタイム性・更新頻度による手法選択
- コーパス特性 ：ドキュメントの安定性・長尾分布の有無
- クエリパターン ：キーワード中心か、意味的・会話的か
- スケール・性能 ：1日あたりのクエリ数に応じた最適化
- チームの技術力 ：ML経験の有無で選択肢が変化
最初に試すべき全文検索（BM25等）
- BM25/Elasticsearch/Postgres全文検索 は「埋め込み」以前から存在
- キーワード型クエリ や 完全一致 が重要な場合に最適
- ML不要・デバッグ容易・APIコストゼロ・高速 （10ms以下）
- 専門用語や社内用語 にも強い
- 同義語・意味的検索 は苦手だが、多くのユースケースをカバー
- チャンク分割や評価・モデル更新リスク も不要
クエリリライトによる検索精度向上
- LLMでユーザークエリをキーワード化 し、全文検索精度を向上
- 語彙ミスマッチ や 社内用語 にも柔軟対応
- APIコスト低 （例：GPT-4o-miniで1クエリ0.001ドル）
- 同義語追加・用語変換・複雑クエリ分解 が容易
- 埋め込みと違い、システムプロンプト調整だけで即時評価可能
ハイブリッド検索（BM25＋埋め込み再ランキング）
- BM25で候補抽出後、埋め込みで再ランキング
- キーワードと意味的理解 の両立
- データが安定・許容可能なレイテンシ（100-500ms） で有効
- コスト・速度のトレードオフ に注意
- チャンク分割戦略や再埋め込みの負担 が発生
オンザフライ埋め込み（高頻度更新・リアルタイム対応）
- 高頻度更新やリアルタイム性重視 で有効
- 全ドキュメント再埋め込み不要、API呼び出しのみでモデル切替可能
- レイテンシ（200-500ms） が許容できる場合のみ推奨
- ストレージコスト低・常に最新データ
ホット/コールドティア（アクセス頻度による分割）
- アクセス頻度の高い文書のみ事前埋め込み（ホット）、それ以外はオンザフライ（コールド）
- パレート分布 （20%が80%のトラフィック）に最適
- 大規模・中規模コーパス で、コスト・レイテンシ・柔軟性のバランスが良い
- モデル切替時の再埋め込みコストも最小化
フル事前埋め込み（大規模・安定コーパス向け）
- 全ドキュメント事前埋め込み＋ベクタDB
- 10K/日以上の高クエリ数・50ms以下の超高速性
- コーパスが安定・アクセス分布が均一 な場合のみ推奨
- モデル切替・頻繁なデータ更新には不向き
- 過剰設計になりやすいので注意
エージェント型RAG（複数意図のクエリ分解）
- 「CSV読み込み・欠損値処理・グラフ化」など複数意図クエリ を分解
- サブクエリごとに最適処理・並列実行・コスト最適化
- エージェントが複雑な処理を自動選択
- 高品質・低コスト・良UXの実現
最適なRAG構成の選び方
- まずBM25など全文検索から開始
- 2-4週間ユーザーフィードバックを収集し、課題を特定
- 「見つからない」→クエリリライトをA/Bテスト
- 「結果は悪くないが物足りない」→ハイブリッド検索をA/Bテスト
- 頻繁更新→オンザフライ埋め込み
- 明確なホットドキュメント→ホット/コールドティア
- 安定・大規模→フル事前埋め込み
- 「意味的理解が必要」→ハイブリッド検索を状況に合わせて選択
- 最適化は段階的に、シンプルなアプローチから始めるのが鉄則
まとめ
- 全文検索＋クエリリライト は多くのユースケースで十分
- 埋め込みやベクタDB は必要性を見極めて導入
- 過剰設計を避け、段階的な最適化 が成功の鍵
- ユーザー視点・実データ・現実的な運用コスト を常に意識