なぜフォールバックと再試行を比較する必要があるのでしょうか?
エージェント ワークフローを構築する場合、エラー処理は避けられない手順です。 LLM 呼び出しがタイムアウトするか、外部 API が例外を返すか、ツールの実行が失敗するかにかかわらず、再試行する (リトライ) か、代替パスに切り替える (フォールバック) かを決定する必要があります。間違ったものを選択すると、リソースの無駄、タスクのデッドロック、または一貫性のない結果が発生する可能性があります。この記事は、実際のエンジニアリング シナリオに基づいて、この 2 つの本質的な違いと該当する境界を詳しく説明しています。
フォールバックと再試行の定義と主な違い
フォールバック (ダウングレード/バックアップ): プライマリ パスに障害が発生した場合に、事前定義された代替手段を実行します。たとえば、LLM 呼び出しが空の結果を返した後、ルール エンジンに切り替えて応答を生成します。または、支払いサービスが利用できない場合は、代替ゲートウェイに切り替えます。
再試行: 一時的な障害の回復後に再び成功することを期待して、失敗した操作を繰り返します。たとえば、ネットワーク タイムアウト後の指数バックオフの再試行や、LLM 出力形式が正しくない場合の再生成などです。
| 寸法 | フォールバック | 再試行 |
|---|---|---|
| 実行ロジック | 代替パスに切り替える | 現在のパスを繰り返す |
| 該当するシナリオ | 回復不可能なエラー、ビジネスのブロックは許可されません | 回復可能な一時的な障害 |
| リソース消費 | 通常は高い (バックアップ リソースが必要) | 可能な累積コール数 |
| レイテンシへの影響 | 切り替え時間 + 代替実行 | リトライ間隔 × 回数 |
| 成功の確率 | バックアップ パスの信頼性を信頼する | 徐々に衰退または平坦化 |
実際のシナリオ: インテリジェントな顧客サービス注文クエリ
エージェントが注文ステータスをクエリする必要があるとします。まず新しい注文システムを呼び出し、失敗した場合は古いシステムにフォールバックします。同時に、ネットワーク タイムアウトなどの一時的なエラーの場合は、最大 3 回の再試行が使用されます。
シナリオ: 新しいシステムは 503 (サービス過負荷) を返します。このとき、再試行すると負荷が増加するため、古いシステムに直接フォールバックする必要があります。ただし、新しいシステムが 429 (電流制限) を返した場合は、待ってから再試行できます。エラーのタイプが区別されていない場合、すべての再試行を使用すると雪崩が発生する可能性があります。すべてのフォールバックを使用すると、古いシステムに負荷がかかる可能性があります。
決定点: メカニズムはエラー コードとコンテキストに基づいて選択する必要があります。実際には、再試行はクライアント エラー (タイムアウト、フォーマット エラーなど) に使用され、フォールバックはサーバー エラー (利用不能、認証失敗など) に使用されます。
最も簡単な落とし穴: 無制限の再試行と暗黙的なフォールバック
ピット 1: 無制限の再試行。チームは LLM 呼び出しに無限の再試行を設定しました。その結果、LLM は例外を返し続け、数千元の API 料金を消費しました。正しいアプローチ: 最大再試行数 (通常は 2 ～ 3) と指数バックオフを設定します。
ピット 2: 暗黙的なフォールバック カバレッジの問題。たとえば、フォールバック パスは独立して監視されないため、障害発生後にプライマリ パスが自動的にバックアップに切り替わります。バックアップ自体にも欠陥があり、ユーザーは知らないうちに誤った結果を取得してしまいます。フォールバック パスのログとアラームも記録する必要があります。
ピット 3: べき等性を無視します。再試行操作は冪等でなければなりません。そうしないと、繰り返し実行すると、重複した注文や重複した控除が発生する可能性があります。操作がべき等でない場合は、フォールバックの使用または重複排除メカニズムの設計を優先する必要があります。
特定の操作: 選択および実装方法
- 分類エラーのタイプ。エラーを一時的 (再試行可能) と永続的 (フォールバックが必要) に分けます。たとえば、ネットワーク タイムアウトと HTTP 503 は瞬間的なものとみなされます。認証失敗と 404 は永続的なものとみなされます。
- 再試行戦略を設定します。指数バックオフ + ジッターを使用すると、最大再試行回数はサービス SLA に従って調整されます。 LLM 呼び出しの場合は、1 ～ 5 秒の間隔で 2 ～ 3 回行うことをお勧めします。
- フォールバック パスの設計。バックアップ パスのリソースとデータが独立しており、適切な場所で監視されていることを確認します。たとえば、支払いの際は Alipay を使用し、WeChat Pay にフォールバックします (ユーザーの確認が必要です)。
- 併用。最初に数回再試行し、それでも失敗する場合は、フォールバックをトリガーします。たとえば、外部 API の呼び出し: 3 回再試行 → キャッシュされた結果にフォールバックします。
- 決定トラックを録音。デバッグと最適化を容易にするために、各再試行/フォールバックの理由、時間、結果をログに書き込みます。
失敗した場合のフォールバック計画
どちらも利用できない場合、または決定できない場合は、次のことを検討してください。
- 手動介入: タスクを保留中としてマークし、開発者に手動で修正するよう通知します。
- 現在のステップをスキップ: ビジネスで許可されている場合は、このタスクを無視して後続のステップの実行を続けます。
- 安全なデフォルト値: ワークフロー全体の中断を避けるために、適切なデフォルト値を返します。
バックアップ ソリューションにはログと監視も必要であり、ブラック ボックスにならないように注意してください。
結論
フォールバックと再試行はどちらか一方ではなく、補完的です。正しいアプローチは、エラーのタイプとビジネス要件に応じて組み合わせを使用することです。再試行は一時的な障害を処理し、フォールバックは永続的な障害を処理します。同時に、エージェントのワークフローを安定して信頼できるものにするために、境界 (再試行回数、タイムアウト時間) を設定し、フォールバック パスを監視し、冪等性を確保する必要があります。
コメントはまだありません