StateBenchが示す、長いcontext windowと信頼できる記憶は別物だ

Ai2は、長いcontextの中で変化する状態を追跡するbenchmark、StateBenchを公開した。課題はcode、spreadsheet、物語を読む作業に似ている。多くの更新後に、値や物体、人物が最終的にどこへ移ったかを答えなければならない。

4段階の課題が値の検索と本当の状態追跡を分ける

最初は変わらない値を扱い、次に最新値への上書き、過去の状態に基づく更新へと進む。最難関では、ある変数が別の変数の値を受け取る。モデルは最後の記述を探すだけでなく、依存関係の連鎖を追う必要がある。

Ai2はGemini 3.8 Flash、Claude Opus 5.5、GPT-6 Sol、GPT-6 Lunaを評価した。簡単な段階では良好だったが、自己参照型の更新や変数間の依存を含む長い課題では精度が急落した。最難関の最長課題では、4モデルすべてが正答率13%以下だった。

agentに必要なのは長いpromptの受理ではなく状態の維持だ

大きなcontext windowは、受け取れるtoken数を示す。すべての変更を最終状態へ正しく反映できるとは限らない。この違いは、code、長い契約書、顧客履歴、多段階の計画を扱うagentにとって重要だ。

一般的なretrieval testの弱点も見える。モデルは長文から単独の情報を見つけられても、正解が複数の操作の結果として生じると失敗し得る。製品evalでは、needle in a haystackだけでなく時間に沿った変化を試すべきだ。

合成変数は長い契約書でも実際のagentでもない

StateBenchは変数の数を固定した統制benchmarkだ。現実の文書には新しい人物、物体、規則が途中で加わる。著者も現行の枠組みがこの状況を扱わないと認めている。表現形式にも左右される。同じ簡単な課題でも、小型hybrid modelはRULER形式でほぼ満点、spreadsheet編集形式では偶然に近い成績だった。

architecture別の結果も、そのまま製品ランキングにはならない。課題に直接trainingしたGated DeltaNetとhybrid modelは、最初の3段階を64,000回の変更までほぼ完全に処理した。ただしpretrained modelにはない、課題専用のtrainingを受けている。

製品固有の状態変化をevalすれば実務上の弱点が見える

各teamは、自分たちのworkflowを具体的な変更列に変え、数十から数百step後の最終状態を確認すべきだ。coding agentならsymbol名の変更や依存関係の更新、契約書なら古い条項を上書きする追補が対象になる。

次に見るべきなのは独立した追試と、benchmark専用trainingなしで新しいhybrid architectureが改善するかどうかだ。そこで初めて、汎用能力と練習済みの手品を区別できる。

Lilithの判定

小説全体を目の前に置いても、3章前に受け渡されたナイフを見失うことはある。大きなcontext windowは舞台を広げるが、小道具までは見張らない。