ツールが部分的な成功を返すと、AIエージェントはなぜ早期に停止するのか？
AIエージェントは、ツールからの成功レスポンスを、必要なタスク条件がすべて完了した証拠だと誤認して、早期に停止することがあります。
ホームエージェントに、10個のファイルのコピー、複数のカレンダーイベントの更新、ドキュメントの一括処理、依存サービスの再起動、ページ分割されたレコードの検索などをツールへ依頼する場合があります。ツールは、一部の項目だけを完了した後、ジョブをキューに登録した後、または内部制限に達した後でも、有効なレスポンスを返すことがあります。エージェントが、呼び出しがエラーなしで返ったかどうかだけを追跡していると、局所的な進捗を全体的な成功の主張に置き換えてしまう可能性があります。以下のセクションでは、通信の成功、処理の進捗、検証済みの完了を分けて説明します。
成功したツール呼び出しは、単なる1つの局所イベントにすぎない
HTTPの成功ステータスコード、有効なJSONレスポンス、またはツールステータスの「ok」は、呼び出しが受け付けられたか、ツールの契約に従って処理されたことを示します。しかし、それだけでユーザーの完全な目標が達成されたことを証明するものではありません。
Microsoft Researchは、表面的な成功シグナルが実際の目標状態と一致しないことがあるため、信頼性の高いエージェント評価には結果の検証が必要だと指摘しています。
エージェントには、呼び出しの成功、項目単位の進捗、最終状態、ユーザーから見た受け入れ可能性を判定する、個別の述語が必要です。
一括処理ツールやページ分割ツールは、有効なサブセットしか返さないことがある
ツールは、最初のページ、検証に合格したレコード、またはタイムアウトまでに完了した項目だけを処理することがあります。そのレスポンスは、そのサブセットについては正しい可能性があります。
CAR-benchは、不確実性、情報不足、相互接続されたツールによって、局所的に有効なステップが1つだけでは不十分になる場合におけるエージェントの時期尚早なアクションを明らかにします。
ツールのスキーマでは、曖昧な1つの成功フィールドではなく、要求数、完了数、失敗した項目、継続トークン、保留中のジョブID、再試行可能性を返すべきです。
ツールが入力を暗黙に切り詰めたり、意図したすべての項目を列挙しなかったりする場合、失敗リストが空であるだけでは不十分です。
エージェントはタスク状態から未完了の義務を失うことがある
長いプロンプトや複数ステップの計画には、複数の制約が含まれています。ツールが肯定的なレスポンスを返すと、モデルは完了したステップに意識を集中させ、残りのチェックリストを保持できなくなることがあります。
Berkeley Function Calling Leaderboardは、状態を持つ複数ステップのタスクを評価しています。そこでは、有効な呼び出しを行っただけでは、必要なすべての義務が引き続き表現され、完了していることは証明されません。
永続的なタスク台帳では、検証者が証拠によって満たされたと判定するまで、すべての義務を未完了のまま保持する必要があります。長い一括処理や分岐するワークフローでは、自然言語だけのメモリは信頼性が低くなります。
自信に満ちた終了文が、実際の検証に置き換わることがある
言語モデルは、肯定的なツールレスポンスの後に通常続く「完了しました」「正常に完了しました」といった表現や簡潔な要約のパターンを学習しています。
監査可能な早期停止に関する研究では、自信に満ちた終了文ではなく、検証可能な停止条件が必要とされています。
最終レスポンスは、最後のツールメッセージの感情的なトーンや文言から直接生成するのではなく、状態を検証した後にのみ生成すべきです。
部分的な成功には、明示的な次状態の契約が必要
信頼性の高いツールは、完了、部分完了、キュー登録済み、再試行可能な失敗、永続的な失敗、不明な結果を区別すべきです。各ステータスには、オーケストレーターが次に行うべき処理を指定する必要があります。
長時間稼働するエージェントのエンジニアリングでは、完了済みの作業と未完了の作業がコンテキストの変更やサービスの再起動後も維持されるように、明示的な進捗状態を使用します。
ホームエージェントの場合、次の状態は、次のページを続けて処理する、ジョブの状態をポーリングする、失敗した項目を再試行する、外部状態を照合する、承認を求める、または未解決の項目を正確に報告して停止する、といったものになります。
部分的な結果に、完全に検証済みの処理と同じ終了ステータスを与えてはいけません。
対象システムから得た証拠で完了を判定する
「完了しました」と伝える前に、要求された結果と現在の状態を比較します。確認対象には、ファイル数とハッシュ、イベントID、サービスの健全性、データベースレコード、ジョブの状態、その他の読み取り専用検証エンドポイントなどがあります。
定量的な目標維持に関する研究では、ツールを使用するエージェントの実行中に測定可能な義務が未達成のまま残らないようにするため、検証者による完了判定が提案されています。
ZimaSpaceの読み取り専用エージェントツールに関するガイドは、別の副作用を発生させずにファイル、サービス、デバイス、計画を確認するための、より安全な検証レイヤーを提供します。
対象システムが完了を証明できない場合、エージェントは部分的な進捗を報告し、未解決の項目を列挙し、再開可能な操作IDを保持すべきです。成功した最終回答を提示してはいけません。
よくある質問
HTTP 200のレスポンスは、完全な成功を示すシグナルですか？
いいえ。これはプロトコルレベルでのリクエストについて説明するものです。要求されたすべての処理が完了したかどうかは、レスポンス本文と対象システムの状態によって定義される必要があります。
エージェントは部分的な結果を自動的に再試行すべきですか？
ツールの契約によって失敗した項目が特定され、再試行がべき等であるか、安定した操作キーによって保護されている場合に限るべきです。
言語モデル自体で完了を検証できますか？
証拠を推論することはできますが、件数、ID、状態、必要な出力については、対象システムに対する決定論的なチェックのほうが信頼性が高くなります。
おすすめ商品
テック＆AIハブ
もっと読む
機密ファイルを取り巻くホームAIの信頼境界を実現する機能とは？
家庭用AIの信頼境界は、保存時暗号化、最小権限のアクセス許可、ランタイムサンドボックス化、スコープを限定した検索を組み合わせたものであり、単一の機能だけでは成り立ちません。
プライベート検索結果が頻繁に編集されたファイルを優先する原因とは？
頻繁に編集されるファイルは、更新のたびに鮮度、チャンク、バージョン、またはインタラクションシグナルが追加され、ソースによる正規化が行われない場合、ランキング上の優位性を獲得します。
スマートホームの在宅検知モデルが来客と住人を混同する原因とは？
システムが世帯の活動パターンを観測していても、その活動を生み出している人物の安定した識別情報がない場合、来訪者が居住者のように見えることがあります。
