エージェント ワークフロー フォールバックと再試行: どちらを選択すべきですか?

問題定義: フォールバックと再試行はそれぞれどのような問題を解決しますか?

エージェントのワークフローでは、エラー処理がシステムの堅牢性を確保するための鍵となります。フォールバックと再試行はどちらも失敗に対処する方法ですが、適用されるシナリオはまったく異なります。簡単に言うと、特定のステップが失敗した場合、リトライは「再試行」を意味し、フォールバックは「別のパスを選択する」ことを意味します。

• 再試行: 一時的な回復可能なエラーに適しています。たとえば、API 呼び出しのタイムアウト、ネットワークのジッター、リソースが一時的に利用できなくなります。通常、再試行には回数制限 (3 回など) と、雪崩を避けるためのバックオフ戦略 (指数バックオフなど) があります。
• フォールバック: 永続的または回復不可能なエラー、または何らかの種類の障害が予想されることが事前にわかっている場合に適用されます。たとえば、モデルの戻り値が不正であったり、秘密の解決策 (より単純なモデルへのダウングレードなど) であったり、ユーザー入力が範囲外であったりします。フォールバックは通常、キャッシュされた結果の使用、ユーザーに再入力を促す、手動処理への切り替えなどの代替ロジックをトリガーします。

操作手順: ワークフローでフォールバックと再試行を実装するにはどうすればよいですか?

標準的な再試行プロセスを実装する

1. 再試行可能なエラーの種類を特定します: 例: HTTP 5xx、タイムアウト、レート制限。 4xx または認証失敗時に再試行しないでください。
2. 最大再試行回数を設定します: 通常は 2 ～ 3 回ですが、回数が多すぎるとプロセス全体が遅れます。
3. バックオフ戦略を構成します: 固定間隔 (1 秒など)、指数バックオフ (1 秒、2 秒、4 秒など)、またはジッターを伴うバックオフ (雷のような集団を避けるため)。
4. 再試行ログを記録: 問題を特定するのに便利です。
5. 統合されたタイムアウト制御: 合計再試行時間を無限にすることはできません。

特定のシナリオの例: エージェントは、OpenAI API を呼び出して概要を生成する必要があります。場合によっては、ネットワークが中断され、503 が返されることがあります。このとき、2秒間隔で3回リトライしてください。 3 回目でも失敗する場合は、フォールバックに入ります。

フォールバックを実装するための標準プロセス

1. フォールバックが必要なステップを特定します: 通常は、クリティカル パス上の非クリティカルな操作、または明確な機能低下計画のあるタスクです。
2. 代替ロジックを設計: たとえば、より安価または高速なモデルに置き換える、キャッシュされたデータを返す、ユーザーに問い合わせる、またはその後の手動処理のためにデッドレター キューにデータを記録するなどです。
3. ワークフローでフォールバック ノードを構成: メイン パスで回復不能なエラーがスローされた場合、自動的に代替ノードにジャンプします。
4. フォールバック パスのテスト: 代替ロジックが適切に動作し、新たな問題が発生しないことを確認します。

特定のシナリオの例: エージェントは、ユーザーの意図を解析するときに主に GPT-4 を使用します。ただし、GPT-4 が無効な JSON 形式を返した場合 (これは永続的なエラーです)、ルールベースの通常の一致にフォールバックするか、ユーザーに言い換えを求めるプロンプトが表示されます。

実際のシナリオ: カスタマー サービス エージェントにおける意思決定

製品の質問に答える責任を負うカスタマー サービス エージェントを構築しているとします。ワークフローは次のとおりです。

1. ユーザーからの質問を受け付けます。
2. ベクトル検索を使用して、関連する文書の断片を見つけます。
3. LLM を使用して、スニペットに基づいて回答を生成します。
4. ユーザーに回答を返します。

考えられる障害シナリオは次のとおりです。

• ステップ 2 のベクター データベース クエリのタイムアウト: これは回復可能なエラーであり、1 ～ 2 回再試行する必要があります。それでも失敗する場合は、キーワード検索を使用してフォールバックできます (フォールバック プラン)。
• ステップ 3 の LLM 応答に形式エラーまたは応答の拒否 (「応答できません」など) が含まれています。これは永続的なエラーであり、再試行すべきではありません (再試行しても同じ結果が得られる可能性が高い) が、「申し訳ありませんが、現時点では応答できません。後でもう一度お試しください。」などのデフォルトの応答に直接フォールバックする必要があります。

不適切な選択の結果: 永続的なエラー (フォーマット エラーなど) に対して再試行すると、時間とコストが無駄になるだけでなく、同じ役に立たない結果がユーザーに返され、エクスペリエンスが低下する可能性があります。一方、一時的なエラー (ネットワーク タイムアウトなど) に対して低速のスタンバイ ロジックに直接フォールバックすると、不要な機能低下が発生する可能性があります。

最も簡単な落とし穴: よくある 3 つの誤解

誤解 1: すべてのエラーに対して再試行を使用する

多くの人は、失敗しても再試行することに慣れており、再試行しても害はないと考えています。ただし、一部のエラーを再試行すると、システムに負担がかかるだけです。たとえば、ユーザー入力がトークン制限を超えた場合、再試行はトークンを繰り返し消費するか、失敗します。正しいアプローチはエラーの種類を区別することです。永続的なエラーは直接フォールバックします。

誤解 2: フォールバック パスは完全にテストされていません

フォールバック コードは、作成後にほとんど実行されないことが多いため、バグを隠すのが簡単です。実際にトリガーされると、フォールバック自体が失敗し、ワークフロー全体が崩壊する可能性があります。開発フェーズ中に必ずフォールバック シナリオを手動でトリガーし、その実行の影響を監視してください。

誤解3: 失敗原因の分析を無視する

再試行であってもフォールバックであっても、失敗の理由とコンテキストを記録する必要があります。ログがなければシステムを改善することはできません。たとえば、特定のステップで頻繁にフォールバックが発生する場合は、メインのプロセス設計に問題があり、調整する必要があることを意味している可能性があります。

失敗した場合のフォールバック計画: フォールバックも失敗した場合はどうなりますか?

これは、多くの人が見落としている最後のリンクです。メイン パスとフォールバックの両方が失敗した場合、ワークフローには最終的なデフォルト動作が必要です。一般的な解決策:

• 一般的なエラー メッセージをユーザーに返し、手動介入を求めます。
• 管理者による通常の処理のために、失敗したタスクをデッドレターキューに書き込みます。
• 開発チームにアラートを送信します。
• 重要でないプロセスの場合は、この手順をスキップして続行できます。

つまり、フォールト トレランスを設計するときは、再試行 -> フォールバック -> 最終的な失敗という完全なエラー処理チェーンを構築する必要があります。

選択方法: 単純なデシジョン ツリー

まだ迷っている場合は、これを使用して迅速な決定を下すことができます。

• 一時的な状況によりエラーが消える可能性はありますか?その場合は、再試行してください。
• エラーは、現在の方法は実行可能ではないが、代替方法が存在することを示していますか?その場合は、フォールバックを使用してください。
• どちらも不可能な場合は、失敗を受け入れ、適切にダウングレードします。

実際のプロジェクトでは、ワークフロー図の各ステップの耐障害性戦略を明確に示し、チームで検討することをお勧めします。

ここで、エージェントのワークフローを確認できます。明確なフォールバックが欠けているステップがいくつありますか?エラーが発生した場合、何ステップが盲目的に再試行されますか?これらの詳細を最適化することで、システムの安定性が大幅に向上します。