エージェント ワークフローの再試行ポリシーとは何ですか?なぜ必要なのでしょうか?
エージェントのワークフローは、LLM の呼び出し、ツールの実行、メモリの読み取りと書き込み、外部 API との対話という複数のステップで構成されます。各ステップは、ネットワーク ジッター、API スロットリング、タイムアウト、または中間状態の不一致により失敗する可能性があります。 再試行ポリシー は、特定のステップが失敗したときにシステムがどのように再試行するかを決定します。再試行の回数、間隔の長さ、再試行する価値のあるエラーはどれか、再試行中に冪等性を確保する方法などです。
再試行戦略がないと、一時的な障害によってワークフロー全体が完全に失敗します。また、再試行戦略が不適切に設定されていると、計算能力が浪費され、システム負荷が増大し、さらには実際のバグが隠蔽される可能性があります。
コアメカニズム: 再試行条件、バックオフ戦略、タイムアウト
1. 再試行する価値のあるエラーはどれですか?
すべてのエラーを再試行する必要はありません。 2 種類のエラーを区別します。
- 再試行可能: ネットワーク タイムアウト、HTTP 503、API 電流制限 (429)、一時的なサービスの利用不能。これらのエラーは、再試行後に回復される可能性が高くなります。
- 再試行不可能: HTTP 400 パラメータ エラー、401 認証失敗、403 権限が不十分、404 リソースが存在しません。これらのエラーを再試行してもトラフィックが無駄になるだけであり、単に失敗してアラームがトリガーされるはずです。
// 伪代码示例
if (error.IsRetriable()) {
executeWithRetry(step, retryPolicy);
} else {
failImmediately(step, error);
}
2. バックオフ戦略: 指数バックオフ + ジッター
継続的な再試行はシステムの輻輳を増大させるだけです。標準的なアプローチは指数バックオフです。再試行間隔を 2 倍にし、ランダムなジッターを追加して、すべてのクライアントが同時に再試行するのを防ぎます。
| 再試行回数 | 基本間隔（固定） | 指数バックオフ (2^n) | 指数バックオフ + ジッター |
|---|---|---|---|
| 1 | 1秒 | 1秒 | 0.5～1.5秒 |
| 2 | 1秒 | 2秒 | 1.0-3.0秒 |
| 3 | 1秒 | 4秒 | 2.0-6.0秒 |
| 4 | 1秒 | 8秒 | 4.0-12.0秒 |
推奨構成: 初期間隔 1 秒、最大間隔 30 秒、合計タイムアウト制限 60 秒、再試行 3 ～ 5 回。
3. タイムアウトとサーキットブレーカー
いつまでも待つことはできません。各ステップには独立したタイムアウト (タイムアウト) が必要であり、ワークフロー全体にはグローバル タイムアウトが必要です。ステップの継続的な失敗がしきい値に達した場合 (たとえば、3 回以内の失敗率が > 50%)、リソースの枯渇を避けるために、サーキット ブレーカーをトリガーして、一定期間サービスまたはステップの再試行を一時停止する必要があります。
実際のシナリオ: 外部気象 API の呼び出し時に再試行が失敗しました
エージェント ワークフローに、外部 API を通じて気象データを取得するステップがあるとします。特定のリクエストで DNS 解決タイムアウトが発生し、再試行がトリガーされます。リトライ戦略は 2 秒の固定間隔、最大 3 回に設定されます。結果: 次の 2 回の再試行はすべてタイムアウトになり、3 回目には 500 が返されました。最終的に、ワークフローはエラーで失敗しました。
問題分析:
- エラーの種類は正しい: ネットワーク タイムアウトは再試行可能です。
- 不合理なバックオフ戦略: 2 秒の固定間隔は速すぎ、DNS の問題は通常、回復するまでに 10 秒以上かかります。指数バックオフを使用した後、1 回目は 2 秒、2 回目は 4 秒、3 回目は 8 秒で、3 回目は成功する可能性があります。
- サーキットブレーカーの欠如: 3 回連続して障害が発生しても一時停止しません。エージェントをトリガーする後続のリクエストは再試行され続けるため、リソースが無駄に消費されます。
改善後: エクスポネンシャル バックオフ + ヒューズ スイッチ。1 分以内の故障率が 30% を超える場合、ヒューズが 30 秒間オープンされ、その間に直接故障が発生し、キャッシュされたデータがダウングレードされます。
簡単な落とし穴: 冪等性と状態残差の欠如
再試行の最も危険なリスクは、非冪等操作が複数回実行されることです。たとえば、エージェントが支払いインターフェイスを呼び出し、通知を送信し、データベースに書き込む場合、これらの操作が再試行時に冪等であることが保証されていない場合、控除が繰り返され、通知が繰り返され、ダーティ データの書き込みが発生します。
解決策:
- 各リクエストには一意のリクエスト ID (べき等キー) が付加され、サーバーはキーに基づいて重複を削除します。
- または、操作自体が冪等になるように設計されています。たとえば、「在庫を 100 に設定する」は冪等ですが、「在庫を 1 減らす」は冪等ではありません。
もう 1 つの一般的な落とし穴は ステータスの残留物です。つまり、再試行前に中間状態 (「処理中」など) がデータベースに書き込まれており、再試行中にその中間状態が消去またはスキップされず、その結果、論理的消費またはロック タイムアウトが繰り返されることになります。ベスト プラクティスは、再試行ステップ内でトランザクションを維持し、失敗時にロールバックするか、重複を許容できるものとしてマークすることです。
失敗した場合のフォールバック計画
リトライを設定しても失敗する可能性はあります。代替パスを準備する必要があります。
- 劣化: 失敗したステップをスキップし、デフォルト値またはキャッシュされたデータを使用してワークフローを続行します。たとえば、天気予報 API は前日の予測データを使用できませんでした。
- 手動介入: 障害情報をデッドレターキューまたはアラームチャネルに書き込み、手動トラブルシューティング後に再実行します。
- 補償トランザクション (Saga): クロスステップ ワークフローの場合、再試行後もステップが失敗する場合、補償操作がトリガーされ、以前に成功したステップがロールバックされます。たとえば、最初に注文を作成してから、支払いを差し引きます。控除が失敗した場合、補償として注文はクローズされます。
- 再試行キュー: 失敗したステップを再試行キューに非同期的にプッシュし、再試行を遅らせます。メイン プロセスはブロックされません。
概要: 実用的なチェックリスト
エージェント ワークフローの再試行ポリシーを構成するときは、次のチェックポイントを確認してください。
- 再試行可能なエラーと再試行不可能なエラーを区別し、再試行不可能なエラーの場合は直接失敗します。
- 指数バックオフ戦略を採用し、初期間隔は 1 秒、最大 30 秒、25% のランダム ジッターを追加します。
- 合計タイムアウト制限 (60 秒など) と各ステップのタイムアウト (10 秒など) を設定します。
- 連続故障率がしきい値に達したときに一時停止して再試行するサーキット ブレーカーを実装します。
- 各ステップが冪等な操作であるかどうかを確認します。そうでない場合は、べき等キーを使用してください。
- ワークフローの完全な崩壊を回避できない場合に備えて、ダウングレードまたは補償プランを提供します。
- 再試行の回数、間隔、最終結果をログに記録して、その後の分析を容易にします。
次のステップ: 本物のエージェント エンジニアになる
再試行戦略は、エージェント ワークフロー設計の一部にすぎません。普通の開発者からエージェント エンジニアに変身し、システムのコンテキスト管理、ワークフロー オーケストレーション、権限制御、メモリ メカニズムなどをマスターしたい場合は、高品質のオリジナル有料記事と AI の高度なプログラミング コースが完全な知識システムの構築に役立ちます。
コメントはまだありません