再試行とフォールバックを分離する
再試行では、障害が一時的なものである可能性があるため、同じルートにリクエストを再送します。フォールバックでは、元のルートが利用できない、または適切でないため、プロバイダーまたはモデルを変更します。
この 2 つの動作を 1 つの汎用的な再試行ループとして扱うと、インシデントの診断が難しくなり、成功率を改善できないままコストだけが増加する可能性があります。
- 再試行: タイムアウト、接続リセット、429、または一時的な 5xx レスポンス。
- フォールバック: プロバイダー障害の反復、モデルのキャパシティ問題、またはポリシー上の制限。
- 停止: 無効なリクエスト、サポートされていないパラメーター、または出力検証の失敗。
機能互換性のあるルートテーブルを構築する
フォールバックモデルは、ブランドではなく機能でグループ化します。画像を扱うリクエストをテキスト専用モデルへフォールバックすることはできません。また、厳格な JSON ワークフローを、スキーマに頻繁に違反するモデルへルーティングすべきでもありません。
- 必要な入力および出力モダリティ。
- 必要な最小コンテキスト長と出力長。
- ツール呼び出しと構造化出力のサポート。
- 許容可能な最大料金とレイテンシ。
リクエスト単位で単一の予算を適用する
リクエスト予算には、すべての再試行およびフォールバック試行を含める必要があります。別の試行を開始する前に、残りのレイテンシ予算とコスト予算でその試行を実行できるか確認します。
const routePolicy = {
maxAttempts: 3,
maxLatencyMs: 18_000,
maxEstimatedCost: 0.12,
retryOn: [408, 429, 500, 502, 503, 504],
fallbackModels: ['primary-model', 'quality-fallback', 'fast-fallback'],
};可用性だけでなくフォールバック品質も測定する
正常にレスポンスを返したリクエストでも、プロダクト上は失敗している可能性があります。フォールバックイベント後の出力検証、ユーザーによる修正率、タスク完了率を追跡します。
推奨ダッシュボード: ルート成功率、フォールバック率、p95 レイテンシ、推定コスト、検証合格率、モデル別の品質スコア。