エージェントのコンテキスト圧縮後も成功率は変わらず、GPT-5.5の状態再取得回数はなお約3倍に

長時間稼働するエージェントは通常、sliding window、要約、retrievalによって過去の軌跡を圧縮するが、評価ではタスクが完了したかどうかだけを確認することが多い。8月17日に提出された新たな研究は、この方法では失敗に先立って発生するコストを見落とすと指摘する。エージェントが実行に必要な状態を忘れると、データを再取得するためにより多くのツール呼び出しを費やさなければならない一方、最終的な回答は依然として正しい場合がある。

研究チームは決定論的なプランニング環境を構築し、各ツール呼び出しをretrievalまたはexecutionに分類したうえで、1ラウンド当たりのインタラクションを最大24ターンに固定した。実験では、完全なコンテキスト、直近の内容だけを保持するsliding operator、同じtoken予算内で事実を保持する要約を比較した。さらに、削除された状態を再注入するoracleを用い、クエリの増加が本当に情報損失に起因するかを検証した。評価対象の3モデルはDeepSeek V4 Flash、Qwen3.7 Plus、GPT-5.5で、主要な各条件では同一seedによる対応ありテストを実施した。

モデルとタスク難易度を組み合わせた6条件すべてでretrieval呼び出しが増加し、そのうち5条件はHolm–Bonferroni補正後も有意だった。一方、execution回数はおおむね変わらなかった。最も顕著だったGPT-5.5の高retrieval需要設定では、5倍圧縮によって平均retrieval回数が21.0回から63.9回に増えたが、完了率の80%から85%への変化には統計的有意差がなかった。DeepSeekでも、完了率が有意に低下したのは10倍圧縮時になってからだった。削除された状態を復元すると追加クエリの約半分が解消され、事実を保持する要約ではコストの大部分を回避できた。

これは、エージェントプラットフォームが圧縮手法を選ぶ際にpass rateだけを見るべきではなく、再クエリ、ツールのレイテンシ、課金対象となるAPI呼び出し回数も記録すべきであることを意味する。そうしなければ、「精度を維持」できているように見えても、実際にはエージェントが失われた情報をより多くのインタラクションで補っているだけかもしれない。ただし、同じsliding operatorを第2の環境であるALFWorldに適用した場合、retrievalの急増は起きなかった。このことは、結果が状態を再取得できるかどうか、ツールインターフェース、ターン上限に左右されることを示している。また、論文で扱うインタラクションコストは、金銭的コストやwall-clock timeを直接測定したものではないため、導入チームは実際のワークフローで検証する必要がある。