AI RAG システム構築における「過剰設計」を防ぐための実践的ガイドライン

当記事では、RAG（Retrieval-Augmented Generation）システムの構築において、必要以上に複雑化させてしまう傾向と、その解決策をエンジニアの視点から解説します。ユーザーは単なるパスワードリセット方法などの単純なニーズに過ぎないため、**「適切な課題に対して最適なツールが存在する」**という原則に従ってください。

1. アプローチを選択する際の 5 つの判断基準

レシピに入る前に、以下の要素に基づいてアプローチを決定してください。

データの鮮度要件

• リアルタイム更新（ニュース、SNS）：再インデックスが容易なオンザフライ埋め込み。
• 日次〜週次の更新：ハイブリッドアプローチ。
• 安定したコーパス（月次〜四半期）：事前の埋め込み処理が理にかなっている。

コーパスの特性

• ハイパーチャーン（日次変化率 10% 以上）：全量事前埋め込みは避けるべき。
• 安定しているドキュメント：事前埋め込みでも問題ない。
• 長尾分布（アクセスされないものが 90%）：オンザフライ処理が優位である。

クエリのパターン

• キーワード中心：フルテキスト検索から開始するべき。
• セマンティックまたは会話型：埋め込みモデルが効果的。
• 混在したパターン：ハイブリッドアプローチ。

スケーラビリティとパフォーマンス

• 日次 1,000 クエリ未満：シンプルなアプローチで十分。
• 日次 1,000〜10,000 クエリ：選択的な最適化が必要。
• 日次 10,000 クエリ超：フルな最適化が正当化される。

チームの能力

• ML 専門知識なし：フルテキスト検索とクエリ改変に留めるべき。
• 一部の ML 経験あり：ハイブリッド検索の管理が可能になる。
• ML チームあり：高度なアプローチの実施が可能。

---

2. RAG システム構築レシピブック

最初から始めてください。データを提示され、必要性が証明された段階で次のステップへ進んでください。

ステップ 1: 「古き良き BM25」での開始

技術：Elasticsearch または PostgreSQL のフルテキスト検索

「埋め込み」という言葉が普及する以前から存在する堅牢な技術です。

• 使用タイミング
  • 始めたばかりの段階。
  • ユーザーがキーワード形式でクエリを入力する場合（例:

    "pandas merge dataframe"

    ）。
  • 完全一致が必要な場合（例:

    "invoice #12345"

    ）。
  • ML の複雑さを避けたい場合。
  • コーパスに固有の用語が含まれている場合。
• 利点
  • API コストはゼロ。
  • 高速（10ms 未満）。
  • デバッグが容易（なぜ特定ドキュメントが一致したか正確に確認可能）。
  • 驚くほど実用的なパフォーマンスを発揮。
  • チャンキング戦略不要（全文書でも動作）。
  • 評価の複雑さがない（テストと検証が容易）。
  • モデル廃止リスクなし（BM25 は変化しない）。
• 欠点
  • 類語を見逃す可能性（"car" vs "automobile"）。
  • セマンティックなクエリへの対応不可。
  • キーワード以外の意図の理解不能。
• 結論
  • 使用ケースの大部分を処理できるため、このステップをスキップしないでください。驚くほどどこまで進められるか確認できます。

ステップ 2: 「いきなり埋め込みモデル」の是非

• 問題点：すぐに「チャンクサイズは？」「オーバーラップ量は？」といった疑問に直面します。
• 解決策：フルテキスト検索を用いれば、これらのパラメータ調整や評価コストをすべてスキップできます。ドキュメントはそのままの形で検索が機能します。

ステップ 3: LLM を用いた「クエリ改変（Query Rewriting）」

多くの「セマンティック検索」の問題は、実はクエリの定式化不足です。

• 代表的な課題
  • 語彙の不一致：ユーザーが「バグ修正」を言うが、ドキュメントに「デバッグ」とある場合など。
  • 社内用語：フレームワークが「Atlas」と呼ばれるが、一般モデルは「地図・ギリシャ神話」と解釈する場合。
  • クエリ戦略の反復性：迅速なテストと改善が必要になるため。
• コスト効率（GPT-4o-mini 使用例）
  • 1 クエリあたり約 0.001 ドル。
• 機能
  • ストップワードの除去（「どのようにすれば」など不要な語）。
  • 類語の追加（"car" → "車・自動車・車両"）。
  • ドメイン用語への翻訳（"コードの高速化" → "パフォーマンス最適化"）。
  • 複雑なクエリの分解。
  • 辞書（システムプロンプト）からの学習。
• 比較優位性
  • 埋め込みモデルの場合、結果が良くなければチャンキング調整、コーパス全体の再埋め込み、回帰テストが必要で重苦しくなります。
  • クエリ改変の場合、システムプロンプトの調整だけで済みます。すぐにテスト可能でイテレーションが高速です。
• ボーナス機能
  • エージェントによる反復・学習・適応ループを作成でき、再埋め込みなしで実現できます。

ステップ 4: 固有用語への対応

• 事例：貴社の Python フレームワークを「Atlas」と呼ぶ場合。
  • 一般埋め込みモデルの弱点：トレーニングデータに含まれていないため、"Atlas"を検索しても関連性の低い結果（地図など）が返されます。類似度スコアは極端に低くなり（0.15）、実用不可能です。
• 解決策：クエリ改変を用いれば、固有用語に対しては正確なキーワードマッチングがセマンティック理解よりも優先的に機能します。

ステップ 5: ハイブリッド検索の実装

BM25 の高速な候補取得と、埋め込みモデルのセマンティック理解を組み合わせます。

• 仕組み：BM25 で上位 50〜100 件を取得し、それを埋め込みモデルで再ランク付け（上位 10 件へ）。
• メリット
  • 互いの弱点を補い合います。
  • ユーザーはセマンティックな質問を立てるが、データ裏付けが必要な場合に対応可能。
  • 100〜500ms のレイテンシ許容範囲内で機能。
  • コーパスが比較的安定している場合に最適。

---

3. アーキテクチャのトレードオフと戦略

コスト vs レイテンシ vs データ鮮度

• 計算コスト：オンザフライでの埋め込みは月間約 15 ドル（日次 1,000 クエリの場合）で、実質的に安いです。
• レイテンシの罠：クエリごとにオンザフライ処理すると、200〜500ms の遅延が発生します。これはユーザー体験において顕著です。
• トレードオフの本質：ここで直面するのはコストの問題ではなく、速度か鮮度かという選択です。

戦略的アプローチの比較

A. オンザフライ / オンライン埋め込み

• コスト：月間約 15 ドル。ストレージはテキストのみ（0 ドル）。
• レイテンシ：200〜500ms。
• 鮮度：完璧（常に最新）。
• メリット：モデルスイッチングが容易（API コール変更のみ）、再インデックス不要。
• 適正：高頻度変更ドキュメント、リアルタイムコンテンツ、データ鮮度が最優先のユースケース。

B. フル事前埋め込み（Offline Embedding）

• コスト：100 万ドキュメント×500 トークン＝約 10 ドル（一度きりの処理）。ストレージは約 6GB。
• 検索速度：50ms 未満（非常に高速！）。
• 欠点：再インデックス以降のみデータが反映される。モデル切り替え時、全ドキュメントの再埋め込みと評価テストが必要でダウンタイム発生リスクあり。
• 適正：安定したコーパス、巨大なスケーラビリティ（10 万ドキュメント以上）、速度を最優先する大規模システム。

ハイブリッド戦略：ホット/コールドティア化

アクセスパターンはパレト分布（20% のドキュメントが 80% のトラフィック）に従います。

• ホットティア（頻繁にアクセス）：事前埋め込み。高速な検索を実現。モデル切り替え時は全再埋め込み対象。
• コールドティア（まれにアクセス）：オンザフライ埋め込み。鮮度を維持しつつコストと計算負荷を抑制。

---

4. アーキテクチャの決定要因サマリー

戦略	データ鮮度	セットアップ複雑さ	レイテンシ	モデル切り替え	チャンキング	推奨ユースケース
フルテキスト＋クエリ改変	完璧	低	50ms 未満	容易 (コード変更のみ)	不要	多くの初期ユースケース、固有用語が多い場合
オンザフライ埋め込み	完璧	低	200〜500ms	容易	必要	ハイパーチャーン、リアルタイム内容、小規模データ
ホット/コールドティア	混合	中	50〜100ms	容易 (ホットのみ)	必要	アクセスパターンが明確な中〜大規模コーパス
フル事前埋め込み	ストレージ後（stale）	高	50ms 未満	困難（全再処理）	必要	巨大スケーラビリティ、安定したコーパス、速度最優先

80/20 のルールによる分布推定

• **60%**のシステムは：フルテキスト＋クエリ改変で十分です。
• **25%**のシステムは：オンザフライまたはホット/コールドティアを持つハイブリッド方式。
• **10%**のシステムは：フル事前埋め込み。
• **5%**のシステムは：カスタムソリューションが必要。

重要：60% の問題に対して 5% のソリューション（大規模なベクトル検索）を構築する人になるな。

---

5. 実装プロセスと次のステップ

マルチインテントクエリの処理

ユーザーは単一の意図ではなく、「CSV を読み込み、クリーニングし、プロットする」といった複数の独立したタスクを抱えることがあります。これらを 1 つの検索で処理しようとすると失敗します（ピザを寿司と一緒に求めるようなもの）。

• 現代のエージェント型 RAG（Perplexity, ChatGPT など）：
  • クエリを分解し、各サブクエリを最適にルーティング。
  • 結果を統合して整合性のある回答を提供。
  • コスト削減効果：
    • 分解なしの場合：LLM 全体書き換え（0.005 ドル）＋埋め込み（0.025 ドル）＝合計 0.03 ドル。
    • 分解ありの場合：分解処理（0.001 ドル）＋必要なサブクエリのみ処理。合計 0.002 ドル（約 15 倍安く、品質も向上）。

構築への推奨ステップ

1. 初期段階：検索機能がない場合は、まずBM25 を構築。すぐに運用して開始してください。
2. ベースライン測定：既存システムを 2〜4 週間運行し、ユーザーフィードバックを集める。
   • 「ドキュメントが見つからない」という苦情がある場合 → クエリ改変を試す（コスト低・再インデックス不要）。
   • 「結果は悪くないが素晴らしいわけではない」という場合 → ハイブリッド検索（スパース＋埋め込み再ランク付け）を試す。
   • 「セマンティック理解が必要だ」という場合 → ハイブリッド検索とティア化戦略を検討。
3. 最終判断：データの変化頻度やスケーラビリティ要件に応じて、オンザフライ、ハイブリッド、フル事前埋め込みのいずれかを選択してください。

まとめ まずはシンプルに始めてください。複雑なベクトルデータベースのセットアップに数ヶ月を費やす前に、BM25 とクエリ改変で多くの問題を解決できることを確認しましょう。