エージェント ワークフロー フォールバックを考慮する必要があるのはなぜですか?
運用グレードのエージェント ワークフローを構築するときの最大の幻想は、「モデルは期待どおりに返される」ということです。実際の操作では、LLM 呼び出しがタイムアウトになり、ツール チェーンが壊れ、コンテキストがオーバーフローする可能性があります。フォールバックを使用しないと、1 つの障害が発生するとエージェント全体がフリーズし、ユーザーはインターフェイスが応答しなくなったり、コンテキストを逸脱した応答が返されたりする可能性があります。
エージェントの障害モードは従来のサービスよりも多様です。モデルの戻り形式エラーにより解析例外が発生したり、外部 API の電流制限により 429 が返されたり、複数ステップの推論における特定のループの出力が期待を満たしなかったりします。フォールバックはオプションではありませんが、エージェント エンジニアリングの最終ラインです。
フォールバックの中核的な仕組み: 再試行だけではない
多くの人はフォールバックを再試行メカニズムと同一視しますが、エージェント ワークフローのフォールバックはより多くの次元を処理する必要があります。
1. タイムアウトと電流制限のロールバック
LLM 呼び出しとツール呼び出しの両方にタイムアウト ウィンドウがあります。 LLM 呼び出しが 10 秒を超えて返されない場合 (モデルとシナリオに基づいて調整)、フォールバックは結果のキャッシュに切り替わり、回答をダウングレードするか (「現時点では処理できません。後でもう一度お試しください」)、複数のモデルをサポートするアーキテクチャではより小さくて高速なモデルに切り替えることができます。
# 简化示例：超时 fallback 到缓存
import asyncio
async def call_llm_with_fallback(prompt, cache, fallback_model=None):
try:
result = await asyncio.wait_for(llm_api(prompt), timeout=10)
cache.update(prompt, result)
return result
except asyncio.TimeoutError:
cached = cache.get(prompt)
if cached:
return cached
if fallback_model:
return await fallback_model(prompt)
return "当前请求超时，请稍后重试"
这个阶段最容易犯的错误是不设置合理的超时值。设置太短会导致正常慢响应被截断，设置太长会让用户等待过久。建议根据模型 P99 延迟动态调整，并配合客户端感知的进度反馈。
2. 工具调用失败的回退路径
Agent 工作流通常涉及多个工具调用，比如搜索、数据库查询、代码执行。任何一个工具失败，如果只是抛出异常，工作流就会中断。好的 fallback 应该是给 agent 一个“绕行”选项。
真实场景：一个客服 agent 需要查询订单物流信息，但下游物流 API 暂时不可用。这时 fallback 策略可以是：
- 尝试从本地缓存获取历史数据
- 切换到备选物流查询服务
- 告知用户“物流信息暂时无法查询，请稍后重试”，并记录工单
实现时，可以在工具定义中声明 fallback 行为：
tools = [
{
"name": "track_order",
"description": "查询订单物流状态",
"fallback": [
{"type": "cache", "ttl": 300},
{"type": "alternative_api", "endpoint": "https://backup-logistics.example.com"},
{"type": "user_message", "content": "物流查询暂时不可用，已记录您的请求"}
]
}
]
3. 推論パスのフォールバック: エージェントが無限ループに陥った場合
エージェントは、同じキーワードを常に検索するなど、特定のステップで同じ決定を繰り返し行う場合があります。これは通常、プロンプトの設計が適切でないか、外部条件が満たされていないことが原因です。この時点で、ループを中断したり、新しい情報を提供したり、状態をリセットしたりして、フォールバックが介入する必要があります。
実践的なアプローチ: ワークフローに「ループ検出」モジュールを追加して、最後の N ステップの決定が繰り返されるかどうかをカウントします。ループが見つかった場合、フォールバックは「同じ操作を 3 回繰り返しました。別の方法を試してください。たとえば、ユーザーに「より正確な情報が見つかりません」と直接答えるか、ユーザーに詳細を提供するよう依頼します。」というプロンプトを強制的に挿入します。
最も簡単な落とし穴: 順次フォールバックと並列フォールバック
フォールバックを設計するとき、多くの人は、A が失敗した場合は B を試行し、B が失敗した場合は C を試行するという順序での判断を記述することに慣れています。これは一部のシナリオに当てはまりますが、B と C への呼び出しが高価であるか、時間枠がある場合は、順次ブロックすると遅延が直線的に加算されます。より良い戦略は並列フォールバックです。つまり、A と B (2 つの候補モデルまたはツール) を同時に起動し、エラー以外の結果を最初に返す方を使用します。
順次か並列かの選択は、障害モードの遅延特性によって異なります。主な失敗がフォーマット エラーであるが、通常の応答が速い場合は、連続した再試行で十分です。主な障害がタイムアウトまたはスロットルである場合、並列フォールバックにより、ユーザーが認識する遅延を大幅に短縮できます。
特定の失敗ケース: チームはエージェントに対して 3 レベルのフォールバックを構成しました。最初にモデルをより大きなサイズに調整し、次にタイムアウト後にモデルをより小さなサイズに調整し、次にタイムアウト後に固定応答を調整します。並列実行がないため、各フォールバックには 10 秒のタイムアウトが必要で、ユーザーは「処理できません」というメッセージが表示されるまで最大 30 秒待つ必要があります。並列化に変更すると、小規模モデルの結果が 3 秒以内に得られました。
フォールバックの適用可能な境界と制限事項
フォールバックは万能薬ではありません。入力プロンプト自体がセキュリティ リスクを引き起こす場合、またはモデルの知識の境界を超える場合、フォールバックによってエラーが増幅される可能性があります。たとえば、悪意のあるプロンプトがメイン モデルのセキュリティ ガードレールをバイパスした場合、フォールバック モデルの安全性はさらに低くなる可能性があります。現時点でのより良いアプローチは、フォールバックではなくサービスを拒否することです。
もう 1 つの制限: フォールバックにより、特に複数のフォールバック チェーンを維持する場合、システムが複雑になる可能性があります。無限再帰を避けるために、エージェント ワークフローごとにフォールバックの最大深さを設定することをお勧めします。
実行可能なアプローチ: フォールバック リストを作成する
- エージェントワークフローの各呼び出しポイント（LLM呼び出し、ツール呼び出し、API呼び出し）を整理します。
- 各ポイントの障害モード (タイムアウト、フォーマット エラー、ビジネス例外、コンテキスト オーバーフロー) を決定します。
- 各モードのフォールバック アクション (再試行、キャッシュ、モデルのダウングレード、代替ツール、ユーザー メッセージ) を設計します。
- フォールバックの実行順序 (順次または並列) を決定し、最大試行回数を設定します。
- 開発環境で障害をシミュレートし、フォールバックが期待どおりにトリガーされるかどうかを確認します。
- フォールバック トリガー レートを監視します。フォールバックが頻繁にトリガーされる場合は、フォールバックに頼ってカバーするのではなく、メイン パスの安定性を向上させる必要があることを意味します。
失敗した場合のフォールバック計画
すべてのフォールバックが失敗した場合、エージェントは正常に機能を低下させる必要があります。最低限の要件は、わかりやすいエラー メッセージを返し、何が起こったのかをユーザーに通知し、代替アクションのエントリ (手動のカスタマー サービスや再試行など) を提供することです。空の回答や不完全な回答を返さないでください。
代替案のリスト:
- 静的な応答を返し、ユーザーに後で再試行するよう促します。
- 障害の詳細をログに記録して、その後の分析を容易にします。
- 運用担当者と保守担当者に介入するよう非同期的に通知します。
エージェントの初心者からエージェント エンジニアへ
フォールバックは、エージェント エンジニアリングの基本機能です。フォールバックをマスターするということは、「デモ エージェントの作成」から「運用レベルのエージェントの構築」への移行を開始することを意味します。ただし、フォールバックだけでは安定性の問題をすべて解決できるわけではありません。また、権限管理、メモリ管理、コンテキスト制御、評価、反復についても理解する必要があります。
コメントはまだありません