When Agentic Executions Fail: Detecting and Localizing Runtime Faults from Telemetry
本論文は、現在のLLMベースの手法がテレメトリのみから多様な運用上の失敗を正確に検出し特定することに苦慮していることを示すために、実行時のフォールトを注入した275のエージェント実行トレースからなるベンチマークデータセットであるAGENTCHAOSBENCHを導入する。
原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。 免責事項の全文を読む
現代のソフトウェアは、もはやコンピュータ上で動く単一のプログラムではありません。それはしばしば、協力し合う人工知能エージェントのチームとなっています。旅行の計画を立てるエージェント、航空券を予約するエージェント、そして天気をチェックするエージェントが、地図やカレンダーのような外部ツールを使用しながら互いに通信し合うデジタル・ワークフォース（デジタル労働力）を想像してみてください。これらのシステムは、複雑な接続の網に依存しています。エージェント同士が会話をし、大規模言語モデルに助言を求め、外部ツールを呼び出して作業を行い、そして有害な発言や行動をしないように厳格な安全ルールに従います。すべてがうまくいっているとき、このチームは正しい答えを導き出します。しかし、何かがうまくいかないとき、最終的な答えが間違っていたり、あるいはシステムが単に停止してしまい、ユーザーにはなぜそうなったのかの手がかりすら残らなかったりします。問題は、最終的な結果だけを見ても、何が崩壊の原因なのかは分からないということです。AIが誤った判断を下したのか、それとも必要なツールが遅かったのか、あるいは安全チェックが誤ってスキップされたのか。これらのシステムを修正するために、エンジニアは目的地だけでなく、その旅路全体を見る必要があります。
トロント大学の研究チームは、この謎を解くための新しいテスト場を構築しました。彼らは「AgentChaosBench」と呼ばれるベンチマークを作成しました。これは、AIチームを意図的に壊して、診断ツールがその問題を見つけられるかどうかを確認するための、いわば制御された環境です。研究者たちは、SQLコードを書く、本を執筆する、ソーシャルメディアを管理する、ランディングページを作成する、採用業務を支援するといった、5つの異なる実世界のアプリケーションを取り上げ、10種類の異なる失敗の仕方をシミュレートしました。これらの失敗には、ツールによる回答拒否、ツールの応答遅延、エージェント間でのメッセージの紛失、そして安全ルールのバイパスが含まれていました。すべての故障シナリオに対して、全く同じ開始指示を用いて、完璧で欠陥のないバージョンの同じタスクも実行しました。この組み合わせにより、何がどこで起こったのかを正確に把握することが可能となり、これらデジタルな旅路の詳細な記録が275件作成されました。
彼らの研究の核心は、自動化されたシステムが、失敗した実行の記録を見て、原因を正しく特定できるかどうかを確認することでした。彼らは、答えを教えてしまうようなラベルをすべて取り除き、呼び出しのタイミング、メッセージの内容、各ステップのステータスといった、起きたことの生のデータのみを残しました。そして、小型のローカルモデルから最も強力な最先端モデルに至るまで、さまざまな人工知能モデルに対し、探偵として振る舞うよう求めました。これらのモデルは、記録を読み、どの種類の故障が発生したかを判断し、システムのどの部分が責任を持っているのかを特定しなければなりませんでした。研究者たちはまた、探偵に対して、比較対象となる完璧で欠陥のない実行のコピーを与えることが、助けになるかどうかもテストしました。
結果は、このタスクが予想以上に困難であることを示しました。詩を書き、複雑な論理パズルを解くことができる最も高度なモデルでさえ、実行時の故障を診断することに大きく苦戦しました。単一の記録から故障の種類を特定するよう求められた際、最高のモデルでさえ正解率は25パーセント未満でした。小型モデルでは成功率はさらに低く、13パーセントから19パーセント程度であり、これはランダムな推測とほとんど変わりません。問題は、モデルが失敗した特定のコンポーネントを指し示す必要があるとき、さらに難しくなりました。彼らがシステムの正しい部分を特定できたのは、わずか31パーセント程度でした。故障の名前と場所の両方を同時に行うよう求められると、最高のモデルでも成功率はわずか22パーセントにまで低下しました。
この研究は、特定しやすいエラーとそうでないエラーがあることを明らかにしました。明確なエラーメッセージを返すツールや、接続タイムアウトのように、明らかなシグナルを生み出すエラーは、より頻繁に特定されました。しかし、最も危険で微妙な失敗は、依然としてほとんど目に見えないままでした。リクエストをブロックすべき場面で安全ルールがバイパスされた場合、モデルはほぼ常にそれに気づけませんでした。同様に、ツールのレスポンスが破損していたり、システムがメモリ空間を使い果たしたりした場合も、モデルはこれらの問題を正常な動作と信頼性を持って区別することができませんでした。研究者たちは、完璧な参照実行を提供して比較することが、ツールが異常に遅い場合やシステムがメモリを使いすぎた場合など、いくつかのケースでは役立つことを発見しました。しかし、この比較は安全バイパスやデータの破損については役に立ちませんでした。なぜなら、壊れた出力は依然としてもっともらしく見え、安全チェックも通過しているように見えたからです。
この研究は、複数のAIエージェントを調整するための洗ほど洗練されたシステムを構築している一方で、なぜそれらが失敗するのかを確実に理解するためのツールはまだ構築できていないことを示しています。現在の世代の診断モデルは、たとえ最大かつ最も有能なものであっても、壊れたツール、遅いネットワーク、スキップされた安全チェック、そして正常な動作の違いを、一貫して判別することはまだできません。研究者たちは、これらのシステムを修正するには、単に大規模言語モデルにログを読ませるという手法を超えた、新しい方法が必要になると結論付けています。彼らは、将来の解決策は、現在の実行を既知の正常な実行と比較することや、汎用的な知能だけに頼るのではなく、これらの運用上の故障を特定するために特別に設計されたツールに頼る必要があるかもしれないと示唆しています。進むべき道は、デジタル機械の全体が崩壊してしまう前に、その目に見えない亀裂を見つけるためのより良い方法を構築することにあります。
自分の分野の論文に埋もれていませんか？
研究キーワードに一致する最新の論文のダイジェストを毎日受け取りましょう——技術要約付き、あなたの言語で。