ArrivalBench：一度は通るAIエージェントのデータ処理が時間で崩れる理由

導入

AIエージェントにデータ処理パイプラインを書かせ、それを一度動かすだけなら、すでに一般的な評価である。しかし実運用のデータは、きれいな一括入力として届くとは限らない。遅れて到着し、重複し、順番が入れ替わり、再試行によって再配送される。arXiv論文のArrivalBenchは、この時間的な条件を外した評価では、エージェントが作ったパイプラインの信頼性を過大評価すると指摘する。

主なポイント

• 固定スナップショットからイベント再生へ。 従来の評価は一つの入力集合を一度実行して出力を確認する。ArrivalBenchは、エージェントが残した同じ成果物を保存し、遅延、重複、順不同、再試行を含む、敵対的だが再現可能な配送順で再実行する。
• 基準はバッチ再計算。 増分処理後の最終状態を、完全なログをまとめて再計算した結果と比較する。これにより、処理がクラッシュしたケースと、完了したものの誤ったテーブルを作ったケースを分離できる。
• 単発テストは失敗を隠す。 40タスクで11モデルの成果物を調べたところ、単発評価を再現した場合は各モデルの86～100％が認証された。しかし同じ成果物を再生すると、認証済みの7.0～79.2％で静かな誤りが見つかった。
• 修正ループだけが原因ではない。 スナップショットテストを通るよう修正されたパイプラインも、最初から通過したものとほぼ同じ割合で再生に失敗した。問題は修正回数より、時間を含まない評価環境にある。
• 再処理への耐性が弱い。 すべてのモデルで、順序の問題よりも重複処理に関係する冪等性の問題の方が多く失敗を引き起こした。

意義と影響

データ処理における「正しさ」は、ある入力例に対する出力だけでは定義できない。イベントが継続的に到着するシステムでは、状態が時間とともにどう変化するかも仕様の一部である。重複書き込み、古い値による上書き、遅延イベントの扱いを誤ると、例外を出さずに誤ったテーブルを残す可能性がある。

介入の読み方にも注意が必要だ。あるモデルでは、危険性の警告によって静かな失敗が48.2％から10.5％に減った一方、クラッシュは9.0％から37.0％に増えた。両方を失敗として数えると、全体の失敗率は51.0％から44.0％への変化にとどまる。見えないデータ破損が、監視しやすいクラッシュへ変わっただけという可能性もある。11の実験条件は独立に再実行され、率の変動は最大5.9ポイントだった。

開発者には、冪等性、順序、再試行、最終状態の収束を明示的に検証することが求められる。評価設計者にとっても、配送順と時間による状態変化は、特別な負荷試験ではなく標準的な評価項目になるべきだろう。

arXiv