なぜホームAIエージェントによる再試行は、再実行できないアクションではリスクがあるのか？
ホームAIエージェントによる再試行は、外部状態を変更するアクションで、最初の試行がすでに成功したかどうかをエージェントが証明できない場合、危険を伴います。
ローカルモデルは、タイムアウト、ツールのクラッシュ、ネットワークの中断、不正なレスポンス、オーケストレーションの再起動後に再試行することがあります。この復旧動作は、検索などの繰り返し可能な操作には便利ですが、メッセージの送信、イベントの作成、ファイルの削除、ドアの解錠、購入処理の実行、1回限りのスクリプトの起動では危険になります。重要な曖昧さは、レスポンスを受信できなかったことが、アクションの実行に失敗したことを意味しない点です。以下のセクションでは、この不確実性がどのように家庭内の重複した副作用につながるのかを説明します。
タイムアウトしても副作用が発生したかどうかは分からない
エージェントがリクエストを送信し、ツールがアクションを完了しても、エージェントが成功を記録する前にレスポンスが失われることがあります。エージェントから見ると、その試行は未解決のままです。
復元性の高いエージェントネットワークに関する研究では、これを曖昧な実行結果と呼び、永続的な操作識別子と復旧の証拠が必要だとしています。
無条件に再試行すると、不確実性が2回目の実行へと変わります。一方、すべての再試行を拒否すると、最初の試行が実際には失敗していた場合に、アクションが未完了のままになる可能性があります。
繰り返し不可能なアクションでは、試行のたびに新たな効果が蓄積する
ステータスを2回読み取っても、通常は別の観測結果が返るだけです。しかし、同じメッセージを2回送信したり、同じレコードを2回追加したり、同じ設定を2回インクリメントしたりすると、状態がさらに変更されます。
Fluxは、再試行によるフォールトトレランスが予期しない目に見える副作用を生み出す可能性があるため、べき等性の一貫性を形式化しています。
したがって、エージェントのアクションは、ツール呼び出しで同じJSON引数を使っているかどうかではなく、その意味に基づいて分類する必要があります。同一のリクエストでも、2通のメッセージ、2件のイベント、または2回分の課金が発生する可能性があります。
削除操作にも注意が必要です。すでに存在しないオブジェクトを削除しても問題ない場合がありますが、「最新のバックアップを削除する」といった操作では、2回目の試行で別のオブジェクトが対象になる可能性があります。
ワークフローエンジンは通常、少なくとも1回の試行を保証する
再試行は、必ずしもエージェントのバグではありません。キューやワークフローシステムは、外部の副作用が確定したかどうかをアトミックに判断できないため、ワーカーの障害後に処理を繰り返すことがあります。
分散実行に関する研究では、インフラがリプレイによって復旧する場合、状態を持つリクエストの再試行には、アプリケーションレベルのべき等性が必要だと指摘しています。
停電後にホームエージェントが再起動すると、シャットダウン時に実行中だったステップが再生されることがあります。対象サービスは、その論理アクションがすでに適用されたかどうかを認識できなければなりません。
べき等性キーは論理アクションを識別する必要がある
エージェントは、最初の試行の前に安定した操作IDを1つ生成し、同じ意図のアクションに対するすべての再試行でそのIDを再利用できます。受信側はそのIDを結果とともに保存し、重複したリクエストを拒否するか、以前の結果を返します。
ポリシー優先型のエージェントシステムでは、操作の識別情報を使って再試行を承認済みの1つのアクションに結び付け、各試行を新しいリクエストとして扱わないようにします。
キーには、対象、アクション、重要な引数、ユーザー、承認コンテキストを含める必要があります。パラメーターが変わったアクションに同じキーを再利用すると、正当な新しいアクションが抑止されたり、以前の誤った結果が返されたりする可能性があります。
受信サービスは重複排除を実施しなければなりません。キーをエージェントのプロンプトやログに記載するだけでは、それを無視するツールには効果がありません。
重複排除が利用できない場合は、再試行前に現在の状態を確認する
家庭用ツールの中には、べき等性キーやトランザクション記録を提供しないものもあります。その場合、エージェントは意図した効果がすでに確認できるかどうかを尋ねる照合ステップを必要とします。
クラッシュオンリーシステムの設計では、再起動時の動作を明確かつ検証可能にする復旧状態が重視されます。
再試行する前に、最初の試行で作成されたイベントID、メッセージの下書き、出力ファイル、デバイスの状態、ジョブ記録、またはトランザクションマーカーを検索します。
副作用がすぐに確認できない場合や、似たアクションが複数あって一致するものを特定できない場合、照合は信頼できません。そのような操作は推測で進めず、人による確認のために停止すべきです。
安全な再試行契約を中心にエージェントツールを設計する
読み取り操作、本質的にべき等な書き込み、キーに対応した書き込み、補償可能なアクション、そして本当に1回限りの副作用を分けます。それぞれの分類に固有のタイムアウトと再試行ポリシーを設定します。
ZimaSpaceの安全に繰り返せる自動化に関する記事では、加算的なコマンドを繰り返し発行するよりも、意図する最終状態を設定する方が安全である理由を説明しています。
繰り返し不可能なアクションでは、実行前に意図を永続化し、1つの操作IDを付与し、最終結果を記録して、ステータスを照会できるようにします。重複による損害の取り消しが難しい場合は、下書き、プレビュー、隔離、送信の遅延、または承認を利用します。
信頼できるエージェントは、すべての失敗を一律に再試行するわけではありません。繰り返しの試行が、家庭内での1つの論理アクションを維持するとツール契約によって証明できる場合にのみ、再試行します。
おすすめ商品
テック＆AIハブ
もっと読む
機密ファイルを取り巻くホームAIの信頼境界を実現する機能とは？
家庭用AIの信頼境界は、保存時暗号化、最小権限のアクセス許可、ランタイムサンドボックス化、スコープを限定した検索を組み合わせたものであり、単一の機能だけでは成り立ちません。
プライベート検索結果が頻繁に編集されたファイルを優先する原因とは？
頻繁に編集されるファイルは、更新のたびに鮮度、チャンク、バージョン、またはインタラクションシグナルが追加され、ソースによる正規化が行われない場合、ランキング上の優位性を獲得します。
スマートホームの在宅検知モデルが来客と住人を混同する原因とは？
システムが世帯の活動パターンを観測していても、その活動を生み出している人物の安定した識別情報がない場合、来訪者が居住者のように見えることがあります。
