𝗕𝗼𝘂𝗻𝗱𝗲𝗱 𝗥𝗲𝘁𝗿𝗶𝗲𝘀 𝗙𝗼𝗿 𝗔𝗴𝗲𝗻𝘁 𝗧𝗼𝗼𝗹 𝗖𝗮𝗹𝗹𝘀
エージェントが引き起こした最悪のインシデントは、誤った回答ではありませんでした。それは「ループ」でした。
ツール呼び出しが失敗しました。エージェントはリトライしました。リトライもまた失敗しました。エージェントはそれを続けました。トークンを浪費し、1分間に数百回もAPIを叩きました。
エージェントは、私たちが指示した通りに動いていました。ツールが失敗したらリトライするように指示していたのです。しかし、いつ止まるべきかを指示し忘れていました。
リトライは一時的なエラーに対しては有効です。問題は、エージェントが一時的なエラーと永続的なエラーを区別できないことです。制限がなければ、エージェントは何かが強制終了させるまで、失敗した呼び出しをリトライし続けます。
従来のコードではリトライ回数に制限を設けます。しかし、エージェントのツール呼び出しでは、この判断がモデルの推論へと移りました。これにより、ループが不可視で、かつ無制限なものになってしまったのです。
私たちは、モデルの外側に2つの予算（budget）を追加することで、これを解決しました。
• 呼び出しごとの上限（Per-call cap）: 特定のツールに対して試行回数の上限を設定します。失敗した場合、エージェントは別の方法を試みる必要があります。 • セッションごとの予算（Per-session budget）: タスク全体に対して、ツール呼び出しの総回数に制限を設けます。エージェントがこの制限に達した場合、停止して助けを求めます。
制限そのものが解決策ではありません。重要なのは、制限に達した後に何が起こるかです。
単に停止させるだけでは、エージェントは行き詰まってしまいます。代わりに、私たちはエージェントに明確なメッセージを送ります。「呼び出しは失敗しました。リトライしてはいけません」と伝えるのです。これにより、ループが「意思決定」へと変わります。通常、エージェントはその後、新しいアプローチを選択します。
これを導入して以来、ツールの誤用によるループはほぼ消失しました。万が一発生したとしても、膨大なAPI利用料を発生させるのではなく、適切にエスカレーションされます。
適切な制限を見つけるのは困難です。制限が厳しすぎると長いタスクが中断され、緩すぎると高額なループを許してしまいます。私たちは、タスクの長さの95パーセンタイルに基づいて制限を設定しています。
これらの予算を設定するもっと良い方法があれば、コメントで教えてください。
Optional learning community: https://t.me/GyaanSetuAi