ストーリー
田
田中VPoE
評価とモニタリングの仕組みを整えた。最後に運用設計だ。インデックスの更新戦略、スケーリング、コスト管理 — 安定運用に必要な設計を固める
あなた
構築よりも運用の方が長く続きますもんね
あ
田
田中VPoE
その通り。RAGシステムは「ナマモノ」だ。ドキュメントが更新されれば再インデックスが必要、利用者が増えればスケーリングが必要、APIの値上げがあればコスト最適化が必要。運用を見据えた設計こそが本番品質だ
インデックス更新戦略
更新パターン
| パターン | トリガー | 処理 | ダウンタイム |
|---|---|---|---|
| 差分更新 | ドキュメントの変更通知（Webhook/ポーリング） | 変更分のみUpsert/Delete | なし |
| 定期全量再構築 | スケジュール（週次/月次） | 新しいコレクションを構築→切り替え | 切り替え時のみ |
| Blue-Green更新 | 手動/CI | 新旧2つのコレクションを並行運用→切り替え | なし |
Blue-Greenインデックス更新
Blue-Green更新の流れ:
[現在] Blue（本番稼働中）
[Step 1] Green（新規コレクション）を構築
→ 全ドキュメントを再チャンキング、再Embedding、再インデックス
[Step 2] Greenの品質検証
→ 評価データセットでRAGASスコアを確認
→ Blue以上の品質であることを確認
[Step 3] トラフィック切り替え
→ API Gatewayの向き先をBlue → Greenに変更
[Step 4] 旧Blueコレクションの削除（一定期間後）スケーリング設計
水平スケーリング
| コンポーネント | スケーリング方法 | トリガー |
|---|---|---|
| APIサーバー | ECS Auto Scaling | CPU/メモリ利用率、リクエスト数 |
| ベクトルDB | Qdrantレプリカ追加 | 検索レイテンシ、QPS |
| 前処理パイプライン | Lambda並列実行数調整 | キューの滞留数 |
キャパシティプランニング
| 項目 | 現在 | 6ヶ月後 | 12ヶ月後 |
|---|---|---|---|
| ドキュメント数 | 38,000件 | 50,000件 | 70,000件 |
| チャンク数 | 190,000 | 250,000 | 350,000 |
| ベクトルDBサイズ | 1.7GB | 2.3GB | 3.2GB |
| 日次クエリ数 | 500件 | 1,000件 | 2,000件 |
| 必要RAM | 4GB | 6GB | 8GB |
コスト管理
コスト最適化施策
| 施策 | 削減効果 | 実装難易度 |
|---|---|---|
| セマンティックキャッシュ | API利用料15〜25%削減 | 中 |
| モデルティアリング（簡単な質問は安価なモデル） | API利用料20〜30%削減 | 中 |
| プロンプト最適化（トークン削減） | API利用料10〜15%削減 | 低 |
| バッチEmbedding（リアルタイムを避ける） | Embedding費用30%削減 | 低 |
| リザーブドインスタンス（EC2） | インフラ費30〜40%削減 | 低 |
コスト監視
| 監視項目 | 頻度 | アラート条件 |
|---|---|---|
| 日次API利用料 | 日次 | 予算の110%超過 |
| クエリあたりコスト | 週次 | 前週比20%以上増加 |
| 月次総コスト | 月次 | 予算の90%到達で警告 |
「コスト管理は後回しにするな。APIの従量課金は知らぬ間に膨らむ。日次での可視化が必須だ」 — 田中VPoE
まとめ
| ポイント | 内容 |
|---|---|
| インデックス更新 | 差分更新 + 定期的なBlue-Green全量再構築 |
| スケーリング | コンポーネント別のAuto Scaling + キャパシティプランニング |
| コスト管理 | キャッシュ、モデルティアリング、プロンプト最適化の3本柱 |
チェックリスト
- Blue-Greenインデックス更新の仕組みを理解した
- コンポーネント別のスケーリング方法を理解した
- コスト最適化の主要施策を理解した
次のステップへ
次は「演習：RAG評価ダッシュボードを設計しよう」です。ここまでの評価・モニタリング・運用設計の知識を統合して、実践的なダッシュボードを設計しましょう。
推定読了時間: 15分