Что такое StateBench и какую проблему он вскрывает
Ai2 представила StateBench 3 ноября 2026 года — бенчмарк, набор данных и код для long-context state tracking. Он проверяет, насколько точно языковая модель отслеживает информацию о сущностях в длинных документах по мере её изменения: переменная получает новое значение, персонаж передаёт предмет, статус заявки меняется в пятнадцатый раз. Вывод неприятный: фронтирные модели, включая Gemini 3.8 Flash, Claude Opus 5.5, GPT-6 Sol и GPT-6 Luna, ломаются на сложных формах state tracking, как только вход становится длинным.
Ценность бенчмарка в том, что он разводит задачи по сложности, а не сваливает их в один тест. Раньше проверки state tracking брали самые трудные случаи, и по ним нельзя было понять, где проходит граница: модель не умеет ничего или щёлкает простое и падает только на зависимостях. StateBench состоит из четырёх уровней, и на них видно, как точность падает ступеньками, а не обрывом.
Кому это важно: тем, кто грузит в модель репозитории, договоры, логи и тикеты, и тем, кто строит агентов. Если задача сводится к «найди последнее упоминание», сегодняшние модели в целом годятся. Если нужно провести цепочку зависимых изменений через весь документ, надёжность падает до случайной.
Чем state tracking отличается от обычного long-context
Длинный контекст отвечает на вопрос «сколько токенов модель принимает на вход». State tracking отвечает на другой вопрос: «умеет ли она корректно обновлять значение сущности по мере поступления новых упоминаний». Вторая способность из первой не следует.
Пример. В переписке на 40 тысяч токенов пять раз обсуждают бюджет проекта: 3 млн, потом 2,5 млн после сокращения, потом 2,8 млн с дополнительным модулем. Модель с окном 200K спокойно «увидит» все пять упоминаний. Вопрос в том, вернёт ли она 2,8 млн, а не первое число или самое эмоционально поданное. State tracking про то, чтобы финальное состояние оказалось правильным.
Разница между «нашёл последнее обновление» и «проследил цепочку изменений» принципиальна. В первом случае достаточно найти максимально позднее присваивание и выбросить остальные. Во втором каждое следующее изменение опирается на предыдущее, и один пропущенный шаг искажает итог. Чем больше шагов, тем быстрее накапливается ошибка.
Размер контекстного окна и стоимость его обработки — отдельная история: контекстное окно, KV-cache и цена длинного входа влияют на счёт за инференс, но не гарантируют, что модель правильно посчитает состояние. Можно принять миллион токенов и всё равно потерять счёт на десятом обновлении.
Четыре уровня StateBench: от let x = 4 до x = y
Уровни различаются типом присваивания, знакомого любому программисту. Описание StateBench сопоставляет каждому уровню конкретную операцию обновления:
| Уровень | Операция | Пример в коде | Что должна сделать модель |
|---|---|---|---|
| r-trivial | неизменяемое присваивание | let x = 4 | восстановить исходное значение, которое не менялось |
| aperiodic | переприсваивание по значению | x = 4, позже x = 2 | найти последнее значение, ранние можно игнорировать |
| soluble | самореферентные обновления | x = x + 5 | провести изменения через всю последовательность |
| general finite | присваивание по ссылке | x = y | отследить зависимости между переменными |
r-trivial и aperiodic: где модели пока держатся
По данным Ai2, почти все модели хорошо справлялись с задачами r-trivial. На aperiodic точность теряется по мере роста входных данных, хотя этот уровень остаётся заметно проще двух следующих. Логика простая: r-trivial требует найти первое и единственное присваивание, aperiodic — последнее из списка. По сути это усиленный needle-in-a-haystack: нужно вытащить нужный фрагмент из длинного текста и не перепутать порядок.
Успех здесь не переносится на следующие уровни. Модель, которая уверенно находит последнюю цену в договоре, не обязательно сложит десять последовательных изменений баланса. Это разные вычислительные задачи, и вторая требует пошагового обновления, а не поиска.
soluble и general finite: обрыв точности
Soluble добавляет самореферентные обновления: каждое новое значение строится на текущем. Модели нужно переносить изменения вперёд; поиск последнего присваивания здесь не работает, потому что последнее присваивание зависит от всех предыдущих. В бытовых сценариях это баланс кошелька, счётчик очков в игре, номер версии при инкрементальном обновлении. На general finite, по данным Ai2, модели показывают результаты на уровне случайного угадывания.
General finite добавляет присваивание по ссылке: одна переменная принимает текущее значение другой. Появляются зависимости между обновлениями, и ошибка расползается по цепочке. Пример: total = subtotal, следом меняется subtotal, а потом кто-то пересчитывает total ещё раз. Модель, потерявшая один шаг, дальше отвечает уверенно и неправильно, и это хуже честного «не знаю».
Как проваливаются фронтирные модели: Gemini 3.8 Flash, Claude Opus 5.5, GPT-6 Sol и Luna
Фронтирные модели не спасают. В закрытых тестах StateBench модели Gemini 3.8 Flash, Claude Opus 5.5, GPT-6 Sol и GPT-6 Luna должны были сгенерировать конечное значение каждой переменной. По данным Ai2, все четыре хорошо справлялись с задачами r-trivial и aperiodic, но при увеличении длины входа их результаты на soluble и general finite резко ухудшались; на самых длинных задачах general finite точность не превышала 13%.
13% на general finite — это фактически случайное угадывание при выборе из вариантов. Модель не деградирует плавно, она теряет саму способность решать задачу. Синтетический характер теста здесь работает на наглядность: в задаче нет ничего, кроме присваиваний, и провал нельзя списать на шумные документы или неоднозначные формулировки.
Оговорка по масштабу: речь о задачах StateBench, а не о всех сценариях использования. Модель, которая валится на цепочках зависимостей в синтетике, может нормально писать код и отвечать на вопросы по документации. Проблема проявляется там, где нужно вести состояние через длинный вход.
Claude Opus 5.5 тесты: что показывают результаты
Claude Opus 5.5 в материалах Ai2 попадает в список фронтирных моделей, которые ломаются на более сложных формах state tracking при росте длины входа. Отдельных цифр именно по этой модели в опубликованном описании не приводится, поэтому корректный вывод такой: деградация подтверждена на уровне группы, а точный профиль падения стоит смотреть в таблицах самого бенчмарка.
Практическая интерпретация простая. Для задач с цепочками зависимостей на длинных входах нельзя полагаться на «сырую» модель без внешней проверки: нужен либо инструмент, который считает состояние детерминированно, либо тест на собственных примерах с известным правильным ответом. Один удачный ответ на длинном документе ничего не доказывает.
Почему трансформеры упираются в потолок, а Gated DeltaNet и Olmo Hybrid обобщают
У трансформеров есть задокументированные теоретические ограничения на сложные варианты state tracking с длинными цепочками зависимостей; именно это мотивирует рекуррентные и гибридные архитектуры вроде Gated DeltaNet, которые несут рабочую память вперёд (разбор Ai2). Одно из таких ограничений сформулировано в работе Chain and Causal Attention for Efficient Entity Tracking: для отслеживания сущностей с изменениями состояния трансформеру требуется число слоёв внимания, растущее логарифмически с числом переходов состояния из-за структуры графа зависимостей.
Механика attention: на каждом шаге модель заново взвешивает, на какие токены смотреть. При 100 тысячах токенов и пятидесяти обновлениях нужный сигнал тонет в шуме, а вычисление состояния превращается в поиск похожего фрагмента. Модель решает задачу «где об этом говорилось», а не «чему это равно сейчас».
Полезно разделить память в весах и память в контексте. Веса хранят общие закономерности языка и кода, контекст хранит конкретные данные текущей задачи. Обновление состояния происходит над конкретными данными, и выполнять его надо пошагово, а не выводить из общих закономерностей.
Что такое Gated DeltaNet простыми словами
Gated DeltaNet — рекуррентная архитектура, которая несёт компактное рабочее состояние через всю последовательность и обновляет его на каждом шаге. Это ближе к тому, как работает присваивание в программе: новое значение зависит от старого, и цепочка сохраняется. Математику трогать не нужно, достаточно интуиции: состояние обновляется инкрементально, поэтому длинные цепочки изменений не размываются по десяткам слоёв внимания.
Почему обобщение за пределы длины обучения важно
При прямом обучении на задачах StateBench рекуррентные и гибридные модели обобщают гораздо дальше трансформеров. В эксперименте Ai2 обучали с нуля шесть моделей с 275 млн параметров на последовательностях не длиннее 256 присваиваний, а тестовые последовательности были в 250 раз длиннее. Gated DeltaNet и гибридные модели почти безупречно обобщали результаты на r-trivial, aperiodic и soluble вплоть до самых длинных протестированных последовательностей. Трансформеры осваивали более простые уровни, но деградировали за пределами обучающего распределения, а general finite не освоили даже в его пределах.
Отдельный нюанс — конфигурация Gated DeltaNet. На general finite вариант с положительными и отрицательными собственными значениями сохранял почти безупречные результаты при длине последовательностей примерно в 10 раз больше максимальной длины в обучающей выборке, тогда как вариант с неотрицательными собственными значениями начинал хуже справляться сразу за пределами максимальной длины, использованной при обучении.
Выход за длину обучения — сильный сигнал. Модель, которая видела последовательности одной длины, а работает на нескольких таких длинах, выучила правило обновления, а не запомнила шаблон. Для практики это намёк: архитектуры с явным состоянием потенциально лучше тянутся на документы длиннее тех, что были в обучении. Но это вывод из контролируемого эксперимента с прямым обучением, а не свойство готовых продуктов.
Что это значит на практике: код, документы, агенты и RAG
Где именно проходит граница возможностей
Правило работает так. Если задача сводится к поиску последнего упоминания в тексте, текущие модели в целом справляются. Если нужно провести цепочку зависимых изменений через длинный вход, надёжность падает до случайной, и фронтирные модели тут не исключение.
Найдите актуальную цену в переписке — простая задача, уровень aperiodic. Отследите состояние заказа через 40 статусов, где возврат меняет статус оплаты, а частичная отмена влияет на доставку — сложная, ближе к general finite. Второй сценарий нельзя закрыть одной длинной инструкцией «внимательно следи за обновлениями».
Код. Переприсваивание переменных, ссылки, цепочки зависимостей — именно то, на чём модели ломаются. Для ревью и рефакторинга опирайтесь на AST и статический анализ, а LLM подключайте как второй слой: объяснить, предложить правку, найти подозрительное место. Как устроены современные бенчмарки для кодинга и почему их цифры нельзя читать буквально, разбирали в материале про Program-Bench, SRE-Bench и Code Migration.
Документы. Поиск последнего значения (aperiodic) даётся моделям лучше, чем накопительные изменения (soluble). Для договоров, логов и финансовых таблиц проверяйте финальное состояние отдельно: пересчитайте итог скриптом, сверьте с первоисточником. Модель хорошо пишет резюме, но плохо работает регистром учёта.
Агенты и RAG. Если агент ведёт состояние задачи в контексте, ошибки накапливаются с каждым шагом. Надёжнее хранить состояние во внешней структуре: БД, JSON, файл памяти агента. Модель получает актуальный срез и не обязана помнить историю всех изменений. В RAG есть отдельная ловушка: чанк с устаревшим значением может попасть в топ выдачи рядом с актуальным, и модель выберет любой из них. Версии, таймстемпы и фильтр по актуальности помогают, но требуют инженерии.
Ограничения StateBench и как читать его результаты
StateBench — синтетический бенчмарк с формализованными операциями присваивания. Реальные документы содержат неоднозначности, отсылки и неявные обновления: «как мы обсуждали в письме от 12 марта», «ставка та же, что и в прошлом квартале». Такие конструкции сложнее любого x = y, и результаты на синтетике их не описывают.
Результаты на general finite показывают архитектурный потолок, а не качество модели в целом. Провал на цепочках зависимостей не отменяет нормальную работу с текстом, кодом и таблицами в коротком контексте.
Прямое обучение на задаче — не то же самое, что поведение готовой фронтирной модели из коробки. Вывод про Gated DeltaNet и гибриды относится к эксперименту, где модели целенаправленно тренировали на этих задачах. Переносить его на продакшн-модели без оговорок нельзя.
Публичное описание приводит примеры уровней, но не заменяет спецификации: конкретные форматы задач, длины и метрики стоит смотреть в самом бенчмарке, прежде чем делать выводы о собственных сценариях. Дата публикации (3 ноября 2026 года) и описание бенчмарка в этом материале опираются на публикацию Ai2 и её пересказ; более поздние обновления результатов и версии бенчмарка здесь не проверялись.
Практический чек-лист: как выбрать модель для длинных зависимостей
- Разберите задачу по типу обновлений. Поиск последнего значения или цепочка зависимых изменений? От ответа зависит, можно ли обойтись текущей моделью.
- Вынесите состояние наружу. Если в задаче есть цепочки, держите актуальные значения в БД, JSON или памяти агента и передавайте модели готовый срез.
- Проверьте модель на своих примерах. Соберите 20–30 задач с известным правильным ответом и разной длиной входа. Общие бенчмарки показывают класс, а не ваш сценарий; логику собственного теста разбирали в сравнении MiMo 2.6 Flash и GLM 5.3 Flash.
- Для кода добавьте инструменты. AST, линтеры, статический анализ и тесты дают детерминированную проверку, LLM ускоряет разбор.
- Следите за архитектурами с явным состоянием. Gated DeltaNet и гибриды выглядят перспективно на state tracking, но оценивайте зрелость инструментов и поддержку в вашем стеке, а не только цифры из статьи.
Начните с одного сценария, где вы уже знаете правильный ответ, и прогоните его через модель на реальной длине документов. Если ошибки появляются на цепочках изменений, переносите состояние в код до того, как доверите модели финальное решение.