論文の概要: Loud Failures, Quiet Failures: Fault Detection and Recovery in Tool-Using Language Model Agents
- arxiv url: http://arxiv.org/abs/2610.10062v1
- Date: Wed, 07 Oct 2026 13:29:59 GMT
- ステータス: 翻訳完了
- システム内更新日: 2026-10-08 21:58:22.936324
- Title: Loud Failures, Quiet Failures: Fault Detection and Recovery in Tool-Using Language Model Agents
- Title（参考訳）: ラウド障害, クイック障害: ツールを用いた言語モデルエージェントの故障検出と回復
- Abstract要約: 我々は、ツールが明示的なエラーを返す場合の91.3%の試験において、エージェントが障害を問題として扱うことを示したが、その58.8%の試験では、それが妥当な間違った値を返す。
兄弟姉妹に対してペアを組むと(-9.3点、p .001)、変更計画がさらに(+10.4点、p .001)、回復は変化しない(p =.512)。
障害後、エージェントは同じツールに最大22.2%の試験で3回以上連続して戻るが、正確に同じ繰り返しはまれである。
- 参考スコア（独自算出の注目度）: 0.0
- License: http://arxiv.org/licenses/nonexclusive-distrib/1.0/
- Abstract: Tool-using agents are usually scored on whether they finish a task while the tools work. Deployments are less forgiving: services time out, endpoints disappear, parameter names change, and results come back well formed but wrong. Prior work has shown that language models over-trust tool outputs that fail silently; we ask how that over-trust plays out across the stages of failure handling in multi-turn agents. Wrapping the executable environments of an established function-calling benchmark in a fault-injection layer, we inject one of four typed faults at a controlled point in the trajectory and record whether the agent notices, changes plan, recovers the task, or repeats itself. Six models from three families, half of them reasoning variants, ran 1,920 trials over 24 multi-step tasks. Agents treat a failure as a problem in 91.3% of trials when the tool returns an explicit error, but in 58.8% of trials when it returns a plausible wrong value, against a 26.8% rate of reporting problems when nothing was wrong. Reasoning models are not better placed: paired against instruct siblings, they notice less (-9.3 points, p < .001) and change plan more (+10.4 points, p < .001), and recovery is unchanged (p = .512). Because agents are stochastic, two fault-free runs of the same task end in the same state only 63.3% of the time; against that baseline, only a missing tool clearly lowers recovery (39.9%), while timeouts, schema drift, and corruption stay within run-to-run variation. After a fault, agents return to the same tool three or more times in a row in up to 22.2% of trials, though strictly identical repeats are rare. A prompt line asking the agent to check each result did not move detection. Agents respond to the error channel rather than to the content of what a tool returns, so failures that stay inside the expected format pass through.
- Abstract（参考訳）: ツールを使用するエージェントは、通常、ツールが動作している間にタスクを終了するかどうかによってスコア付けされる。
サービスのタイムアウト、エンドポイントの消滅、パラメータ名の変更、結果がうまく形成されているが間違っている。
我々は、オーバートラストがマルチターンエージェントの障害処理の段階でどのように機能するかを尋ねる。
故障注入層に確立された関数呼び出しベンチマークの実行環境をラッピングし、4つの型付き障害のうちの1つを軌道の制御点に注入し、エージェントが気付くか、計画を変更するか、タスクを回復するか、あるいはそれ自身を繰り返すかを記録する。
3つのファミリーの6つのモデル、半数は変種を推論し、24のマルチステップタスクに対して1,920のトライアルを実行した。
エージェントは、ツールが明示的なエラーを返す場合の91.3%の試験では失敗を問題として扱うが、58.8%の試験では、誤りがない場合の報告問題を26.8%の率で返却する。
兄弟姉妹に対してペアを組むと(-9.3点、p < .001)、変更計画がさらに(+10.4点、p < .001)、回復は変化しない(p = .512)。
エージェントは確率的であるため、同じタスクの2つの障害のない実行は63.3%の時間で終わる。
障害後、エージェントは同じツールに最大22.2%の試験で3回以上連続して戻るが、正確に同じ繰り返しはまれである。
エージェントに各結果をチェックするよう要求するプロンプト行は、検出を移動させなかった。
エージェントはツールの返却内容ではなくエラーチャンネルに応答するため、期待されるフォーマット内に留まる障害が通過する。
関連論文リスト
- ArrivalBench: Agent-Generated Data Pipelines Are Correct Once and Wrong Under Time [0.40611352512781873]
ArrivalBenchは、エージェントが残したパイプラインを再実行する。
オラクルは分類ではなく再計算するので、間違ったテーブルとクラッシュは別個の判断である。
論文 参考訳（メタデータ） (2026-10-01T18:39:06Z) - TimeEvo: Failure-Driven Self-Evolution of a Time Series Agent [58.343983191487276]
時系列エージェントは、外部ツールを呼び出すことで分析的な質問に答える。
Human-Agent Tool Misalignment: 21のエキスパートキュレートされたツールのライブラリは、いくつかのタスクを支援し、他の人を傷つけます。
TimeEvoは、エージェントの診断された障害を能力ギャップに集約し、それぞれの測定を計画し、ペアの入場ゲートを通してのみ候補ライブラリを許可する。
論文 参考訳（メタデータ） (2026-09-23T03:08:12Z) - What Stops a Small Language Model From Driving a Database Agent [0.0]
小さなオープンウェイトな言語モデルは、エージェントデータベースの作業で失敗すると仮定される。
私たちはそれを生産システムに対してテストします。
1,590,75.7%の2,100台のモデルが配布されたエージェントモードの損失は、少なくとも1つのツールを起動したランから発生した。
論文 参考訳（メタデータ） (2026-09-18T05:51:31Z) - Fabrication After Tool Failure: Tool-Augmented Agents Assert Values Their Tools Did Not Return [7.146717861821737]
ツール拡張言語モデルは、ツールの供給に失敗した時に正直に報告するかどうかではなく、正しい回答に達するかどうかで評価される。
16のシステムドメインと8つのツール障害タイプにまたがる1024項目のベンチマークで、この障害後の決定を分離する。
論文 参考訳（メタデータ） (2026-09-13T19:46:42Z) - AgentDebugX: An Open-Source Toolkit for Failure Observability, Attribution, and Recovery in LLM Agents [83.37969790806069]
LLMエージェントのエラーは、エラーが表面化するステップが原因ではないことが多いため、デバッグが難しい。
Agent DebuggerXはオープンソースのフレームワークで、デバッグをDe Detect, Attribute, Recover, Rerunのクローズドループとして整理する。
コアとなるDeep Debuggerは、グローバルな軌跡理解を通じてマルチターン根本原因診断を行う。
論文 参考訳（メタデータ） (2026-07-21T06:21:13Z) - AgentCheck: A Reproduce-Intervene-Mitigate Workbench for LLM Agents over MCP [0.0]
AgentCheckは、実際のツールに対してエージェントを実行し、すべてのツール応答を記録し、その後、障害(12タイプ)インジェクタによって妨害されたレスポンスでエージェントを再実行します。
マッチングツールコールはキャッシュからリプレイされ、その後、エージェントが分岐した後にツールコールがライブになる。
開発者は緩和をトグルし、同じ障害に対して再実行し、障害が消滅するかどうかを確認する。
論文 参考訳（メタデータ） (2026-07-13T05:14:12Z) - AgentProcessBench: Diagnosing Step-Level Process Quality in Tool-Using Agents [50.481033105867205]
我々はAgentProcessBenchを紹介した。AgentProcessBenchは、現実的なツール拡張トラジェクトリにおけるステップレベルの有効性を評価するための最初のベンチマークである。
ベンチマークは、1,000の多様な軌跡と8,509の人間ラベル付きステップアノテーションと89.1%のアノテーション間合意で構成されている。
探索をキャプチャする3つのラベリングスキームと、ラベルのあいまいさを減らすためのエラー伝搬ルールを備えている。
論文 参考訳（メタデータ） (2026-03-15T16:13:58Z) - When Agents Disagree With Themselves: Measuring Behavioral Consistency in LLM-Based Agents [0.0]
ReActスタイルのエージェントは、同じ入力でも平均10回の実行毎に2.0--4.2の異なるアクションシーケンスを生成する。
一貫性のある動作を持つタスクは80-92%の精度を達成するが、一貫性のないタスクは25-60%しか達成しない。
この結果から,実行中の動作の整合性を監視することにより,早期のエラー検出とエージェント信頼性の向上が期待できることがわかった。
論文 参考訳（メタデータ） (2026-02-12T06:15:14Z) - DoVer: Intervention-Driven Auto Debugging for LLM Multi-Agent Systems [48.971606069204825]
DoVerは、大規模言語モデル(LLM)ベースのマルチエージェントシステムのための介入駆動デバッグフレームワークである。
ターゲットの介入を通じて、アクティブな検証によって仮説生成を増強する。
DoVerは失敗試験の18～28%を成功させ、最大16%のマイルストーンを達成し、失敗仮説の30～60%を検証または否定する。
論文 参考訳（メタデータ） (2025-12-07T09:23:48Z) - Where LLM Agents Fail and How They can Learn From Failures [62.196870049524364]
大規模言語モデル(LLM)エージェントは、複雑なマルチステップタスクの解決において有望であることを示す。
単一ルート原因エラーがその後の決定を通じて伝播する、障害のカスケードに対する脆弱性を増幅する。
現在のシステムは、モジュール的で体系的な方法でエージェントエラーを包括的に理解できるフレームワークを欠いている。
AgentErrorTaxonomyは、メモリ、リフレクション、計画、アクション、システムレベルの操作にまたがる障害モードのモジュール分類である。
論文 参考訳（メタデータ） (2025-09-29T18:20:27Z)
関連論文リストは本サイト内にある論文のタイトル・アブストラクトから自動的に作成しています。
指定された論文の情報です。
本サイトの運営者は本サイト（すべての情報・翻訳含む）の品質を保証せず、本サイト（すべての情報・翻訳含む）を使用して発生したあらゆる結果について一切の責任を負いません。