Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Одинаковый снимок интерфейса и одно действие могут вести к разным результатам, если важная часть состояния скрыта в истории взаимодействия. На StateAliasBench восстановление такого состояния улучшило прогноз двух замороженных GUI-моделей, хотя работа не рецензирована и числа получили сами авторы. Команда может поставить отдельный модуль памяти перед существующей моделью вместо её полного переобучения.
Одинаковый снимок не означает одинаковое состояние
GUI-модели обычно получают текущий экран и предполагаемое действие, а затем строят следующий экран. Такая схема работает, пока интерфейс содержит всё, что определяет результат действия.
Но часть нужных данных остаётся за пределами экрана. Пользователь мог переместить файл, скопировать строку, изменить очередь воспроизведения или запустить таймер. После перехода в другое окно эти изменения перестают быть видны, хотя продолжают влиять на систему.
Авторы называют это слиянием состояний (state aliasing): модель видит одинаковые входные данные там, где среда фактически находится в разных состояниях. Один прогноз неизбежно окажется неверным хотя бы для одной ветки.
Простой пример — буфер обмена. Две истории заканчиваются одним пустым редактором, но перед этим в буфер скопировали разные строки. После команды вставки правильные следующие экраны должны различаться, хотя текущий экран и действие полностью совпадают.
Такая ошибка отличается от неудачной генерации изображения. Модель может правдоподобно нарисовать интерфейс, но выбрать не то будущее, потому что вход не содержит признака, который разделяет возможные исходы.
Строгие пары отделяют нехватку памяти от ошибок генерации
Для проверки авторы собрали StateAliasBench из 800 пар взаимодействий с реальными Android-приложениями. В каждой паре текущий экран и следующее действие совпадают, а скрытое состояние и проверенный результат действия различаются.
Бенчмарк охватывает четыре семейства: существование и расположение объектов, содержимое буфера обмена, порядок элементов в коллекции и срок срабатывания события. Их реализовали через 25 причинных шаблонов. Результат проверяли по смысловому признаку — например, по вставленному содержимому или наличию файла, — а не по произвольному различию снимков экрана.
Основная метрика требует, чтобы модель правильно предсказала обе ветки пары. Угадать один правдоподобный исход недостаточно: модель должна различить два состояния, которые выглядят одинаково непосредственно перед действием.
Проверка охватила замороженные Code2World-8B и gWorld-8B. В стандартном режиме обе модели систематически путали ветки. Передача полной необработанной истории помогала лишь частично, тогда как явно заданное правильное состояние возвращало большую часть потерянной способности различать исходы.
Восстановленное из истории состояние также улучшило прогноз обеих моделей и не ухудшило сходство с записанным следующим экраном по использованным авторами метрикам. На AndroidWorld его проверили вместе с двумя агентами, которым Code2World-8B помогал выбирать действия; доля выполненных задач выросла и в этом сценарии.
Границы результата заданы самим экспериментом: работа проверяет один следующий переход в Android-среде, два GUI-прогнозатора и перечисленные семейства состояния. Дополнительные испытания включают перенос между приложениями, более длинную историю и посторонние события, но не доказывают, что выбранная структура состояния достаточна для любого приложения или длинного плана.
Командам нужен слой состояния, а не более длинный запрос
Предложенная схема не меняет веса GUI-модели. Отдельный оценщик читает историю действий и экранов, а затем выдаёт структурированное состояние в JSON: где находится объект, что лежит в буфере, как упорядочена очередь или сколько времени осталось до события.
Для разных типов данных сначала обучают специализированные модели. Затем их ответы и распределения вероятностей переносят в единый оценщик на базе Qwen3.5-2B. Такой подход оставляет один модуль для рабочего контура, но сохраняет знания специалистов о разных семействах состояния.
Детерминированный адаптер превращает JSON в условия, которые понимает конкретная GUI-модель. Он вычисляет последствие предполагаемого действия и сериализует его в совместимом формате. Адаптер не читает среду напрямую: все различия между ветками должны прийти из состояния, восстановленного по истории.
Для команды, которая уже строит планирование на снимке экрана и прогнозе следующего шага, работа меняет порядок проверок. Сначала стоит выделить данные, которые переживают смену экрана: файлы, буфер обмена, очереди, фоновые операции, разрешения и сроки. Затем для каждого такого типа можно собрать строгие пары с одинаковым видимым входом и разными правильными исходами.
Если модель проваливает эти пары, увеличение окна контекста само по себе не гарантирует исправления. История содержит нужный факт, но GUI-модель должна извлечь его, сохранить в устойчивом виде и применить к конкретному действию. Эксперимент показывает, что явная структура справляется с этим лучше необработанного журнала взаимодействий.
Полное переобучение имеет смысл не как первый шаг, а когда замороженная модель не умеет использовать даже правильно переданное состояние. До этого отдельный оценщик и адаптер дают более локальное изменение архитектуры: их можно тестировать по типам состояния, заменять независимо и подключать к уже работающему прогнозатору.
Источники
Иллюстрация: рисунок из статьи «The GUI Is Not the State: Diagnosing State Aliasing in GUI World Models», Dongsheng Liu, Chao Jin, Wenkui Yang и др., CC BY 4.0
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
