本番RAGシステムが徐々に劣化する理由

本番RAGシステムは単一の壊滅的なイベントで故障することはほとんどありません。むしろ、信頼性は一連の運用変更によって徐々に損なわれます。ドキュメントが進化し、検索動作が変化し、プロンプトが改訂され、依存関係が変わり、評価データセットが古くなります。

従来のエンジニアリング手法では、障害をシステムコンポーネント（レトリーバー、プロンプト、ベクトルデータベース、言語モデル）ごとに分類します。これは実装には役立ちますが、長期運用のための指針としては不十分です。そこで本稿では、3つの補完的な次元からなる信頼性フレームワークを提案します。

第1の次元：障害ダイナミクス RAGインシデントが発生したとき、エンジニアは「何が故障したか」ではなく「信頼性が時間とともにどのように変化したか」を最初に問うべきです。従来のソフトウェアシステムは離散的な障害を想定していますが、本番RAGシステムの信頼性は連続的に変化することがよくあります。障害ダイナミクスには以下の種類があります：

• 即時型：システム変更後すぐに現れる。デプロイやプロンプト改訂で正解率が即座に低下。
• 段階型：個々には無害な変更の累積。ドキュメント進化や検索動作の変化。
• 閾値型：累積変化が臨界点を超えると急激に劣化。安定に見えても限界を超えると突然性能が落ちる。
• 振動型：同様の条件下で結果が不安定。入力分布や検索順序、モデルの確率変動に依存。
• カスケード型：局所的な欠陥が下流に伝播して増幅。検索エラーが計画に影響し、ツール選択やメモリ更新に波及。

第2の次元：信頼性制御面 障害ダイナミクスを特定した後、エンジニアはどこに介入すべきかを検討します。制御面は以下を含みます：

• 知識面：コーパスの品質。古いドキュメントの削除、重複除去、不整合の修正。
• 検索面：検索アルゴリズム、チャンキング戦略、埋め込みモデル、メタデータフィルタ、リランカー。
• 生成面：プロンプト設計、モデル選択、デコード戦略、構造化出力制約。
• 評価面：自動ベンチマーク、回帰テスト、本番監視による品質ゲート。
• 運用面：バージョン管理、デプロイポリシー、監視、トラフィックルーティング、インシデント対応。

第3の次元：検出可能性 すべての障害が同じように可視化されるわけではありません。即座に監視システムをトリガーするものもあれば、一見成功したリクエストの背後に隠れるものもあります。障害のコストはその深刻度だけでなく、未検出の期間にも依存します。従来のソフトウェアは観測可能性に投資されてきましたが、本番AIシステムでは、リクエストが成功し、レイテンシが安定し、インフラアラームが発報しなくても、回答品質が低下することがあります。この場合、可用性ではなく正確性が主要な運用関心事になります。

実験と意義 本稿では、7週間のドキュメント進化をシミュレートする制御実験を実施し、段階的知識ドリフトという代表的な障害クラスを示しました。実験は、個々の変更が無害でも、累積効果が検索精度と回答品質を徐々に蝕むことを明らかにしました。

結論として、本番RAGシステムの信頼性問題は、システムの正確性ではなく、持続的な知識品質の問題として捉える必要があります。本フレームワークは、エンジニアが本番AI障害を理解し、分類し、対応するための共通言語を提供します。