技術要約: ContinuityBench

問題提起

プロダクション環境における大規模言語モデル（LLM）のデプロイメントにおいて、高いAPI可用性は必ずしも会話の継続性を保証するものではない。現在のマルチプロバイダー・ゲートウェイ（LiteLLM、Portkey、OpenRouterなど）は、ステートレスなリクエストレベルの抽象化に基づいて動作している。プライマリプロバイダーが失敗したり、レート制限に達したりした場合、これらのシステムは稼働率を維持するためにリクエストをフォールバック先プロバイダーへと正常にルーティングする。しかし、それらは直前の会話履歴を破棄してしまう。その結果、フォールバック先のモデルには、文脈を欠いた最新のユーザーメッセージのみが転送されることになる。

これにより、「継続性のギャップ（continuity gap）」が生じる。システムは有効なHTTP 200レスポンスを返却（可用性）するものの、エージェントは以前のターンを忘れてしまうため、ユーザー体験は崩壊する。これにより、ユーザーは同じことを繰り返すことを強いられたり、エージェントによるパイプラインが、文脈の切り詰めによってマルチステップのタスクに失敗したりする。この失敗モードは広範囲に及び、深刻な影響を及ぼすが、現在は厳密な測定や標準化された緩和策が存在しない。

メソドロジー

著者らは、制御されたフェイルオーバー条件下での文脈保持のストレス・テストを行うために設計された、オープンな評価ハーネスであるContinuityBenchを導入する。

評価設計

• テストスイート: $N=150$ のマルチターン会話からなる合成データセット（各会話は7〜11ターン）。各会話には、最初のターンに特定の「事実的アンカー（factual anchor）」（例：名前、日付、または嗜好）を埋め込み、その後に無関係なフィラー対話が続き、最後にアンカーを想起できなければ正解できない問い（プローブ質問）で締めくくる。
• 障害注入: 決定論的な障害インジェクターを用い、最終的なプローブ・ターンにおいて3つの失敗モード（TIMEOUT、API_ERROR、RATE_LIMIT）をシミュレートする。これにより、プライマリが失敗した直後に、フォールバックプロバイダーが文脈依存の質問に回答しなければならない状況を確実に作り出す。
• スコアリング (LLM-as-Judge): 自動判定器（GPT-4o）が、フォールバックプロバイダーの回答が事実的アンカーを正しく取り込んでいるかを評価する。判定器は人間によるラベルに対してキャリブレーションされており、正確な部分一致を確認するための高速パス・ヒューリスティックを使用する。
• 並行性: 実験は、$C=100$ の同時実行会話数で行われ、レース条件やレート制限処理のストレス・テストを行う。
• 再現性: 本研究は5回の独立したランで構成され、システムあたり合計 $N=750$ 回のフェイルオーバー・イベントを対象とする。

比較対象のシステム

本研究では、同一のインフラストラクチャを共有しながら、フェイルオーバー時に転送されるペイロードのみが異なる2つのアーキテクチャを比較する：

1. ベースライン (Stateless): プロキシは最後のユーザーメッセージのみを抽出し、それをフォールバックプロバイダーに転送する。
2. トリートメント (History-Forwarding): プロキシーは完全な messages[] 配列（完全な会話履歴）をフォールバックプロバイダーに転送する。

主要な貢献

1. 継続性の定式化: 本論文は、会話の継続性を、単純な稼働率メトリクスとは異なる、可用性と直交する特性として定義する。
2. 新しいメトリクス:
   • 継続性保持率 (Continuity Preservation Rate: CPR): フォールバック・イベントのうち、フォールバックモデルが事前の全文脈に正常にアクセスできた割合。
   • 継続性レイテンシ・オーバーヘッド (Continuity Latency Overhead: CLO): 状態の再構築と転送によって発生する追加のレイテンシ・コスト。
3. ステートフル・プロキシ・アーキテクチャ: 異種混合のエンドポイント間で会話の状態を再構築するための「履歴転送（History-Forwarding）」戦略を利用した設計。
4. オープン・ベンチマーク: マルチプロバイダー・システムを評価するための再現可能なハーネスである continuity-bench の公開。
5. システム失敗の特性評価: 高並行フェイルオーバー・シナリオにおける2つの決定的な失敗モードの特定：
   • 並行性レース条件 (Concurrency Race Conditions): 並行して発生するフェイルオーバー・イベント間で会話履歴が混ざり合う、共有状態の破損。
   • リトライ・ストーム (Retry Storms / Thundering Herd): レート制限がかかったフォールバックに対するナイーブな固定間隔のリトライ・ロジックが、フォールバック・エンドポイントをロックアウトする自己持続的なリクエスト・ストームを引き起こす現象。

結果

• 継続性の保持: History-Forwardingによるトリートメントは、750件のイベントを通じて 99.20%のCPR [95% Wilson CI: 98.27%, 99.63%] を達成した。ステートレスなベースラインは 0.00% であった。6件の失敗は、転送メカニズムではなく、フォールバックモデルの指示追従能力の限界に起因していた。
• レイテンシ・オーバーヘッド: 中央値としてのCLOは -450 ms であり、サードパーティAPIの応答時間の分散により、トリートメントの方がベースラインよりもわずかに高速になる場合が多いことを示している。平均CLOは+59 msであった。P95 CLOは+13,614 msであり、これは大規模な文脈ペイロード（9〜11ターン）を処理するために必要な時間によって引き起こされた。
• 安定性: CPRは5回の独立したランすべてにおいて安定していた（98.7%〜99.3%）。
• 並行性の修正: 本研究は、厳格なレート制限がかかったフォールバックに対するリトライ・ストームを防ぐには、指数バックオフとジッター (exponential backoff with jitter) が必要かつ十分であることを実証し、また、文脈の漏洩（context bleeding）を防ぐためには厳格なセッションごとの状態分離が必要であることを示した。

意義と主張

本論文は、業界の現在の焦点である「可用性（答えを返すこと）」が、2つの異なる特性を混同していると主張する。堅牢なマルチモデル推論システムは、継続性（文脈に基づいた答えを返すこと）を保持しなければならない。

著者らは以下の通り主張する：

1. ステートレスなフェイルオーバーは不十分である: インタラクティブな音声エージェントやエージェントによるパイプラインにとって、それは実質的に会話をリセットすることになるためである。
2. History-Forwardingは有効な解決策である: わずかな中央値レイテンシ・オーバーヘッドで、ほぼ完璧な継続性保持を実現する。
3. 信頼性は分散システムの問題である: 単にリクエストをルーティングするだけでは不十分である。プロダクション・ゲートウェイは、状態の破損を防ぐための明示的な並行性制御と、リトライ・ストームを防ぐためのインテリジェントなバックオフ・プロトコルを実装しなければならない。

本研究は、マルチモデル・システムを構築するための原理的な基礎を提供し、信頼性のパラダイムを「リクエストの生存」から「会話の生存」へとシフトさせるものである。