Почему ваш ИИ-агент для браузера ломается от простого зума

Вот простой эксперимент. Откройте любой современный ИИ-агент для веб-интерфейсов, наведите его на знакомый сайт — и уменьшите масштаб браузера до 70%.

Визуально всё остаётся на месте. Кнопки на прежних позициях, вёрстка не изменилась. Только текст стал меньше.

ИИ с высокой вероятностью ошибётся.

Это не какой-то экзотический баг. Это индикатор фундаментального разрыва между тем, что измеряют бенчмарки, и тем, что реально нужно делать ИИ в продакшене. И если вы разрабатываете ассистентов для браузеров, скраперы или агенты для управления компьютером — этот разрыв касается вас напрямую.

Иллюзия бенчмарков

Цифры выглядят впечатляюще. Современные модели для графических интерфейсов показывают 90%+ на ScreenSpot-v2 и похожих тестах. Легко поверить, что задача решена и восприятие больше не узкое место.

Но давайте посмотрим, что за этими цифрами скрывается.

ScreenSpot-v2, как и большинство бенчмарков, тестирует модели на замороженных скриншотах. Одна страница, один рендер, каждый раз одинаково. Реальные сайты работают иначе. Пользователи меняют масштаб. Команды выпускают редизайны. Тёмная тема сдвигает цветовые соотношения. Разные браузеры по-разному отрисовывают один и тот же CSS.

Модель не научилась справляться с вариативностью. Она научилась узнавать конкретные скриншоты. Высокие баллы — это показатель запоминания, а не настоящего визуального понимания.

Исследователи из GUI-Perturbed (Fig, Inc.) задались целью измерить, сколько бенчмарк-производительности остаётся при столкновении с обычной изменчивостью. Их метод: систематически искажать визуальные сцены по контролируемым осям и замерять падение точности. То, что они обнаружили, должно насторожить любого, кто строит системы для реального использования.

Проблема тройного выравнивания

Прежде чем разбирать результаты, нужно понять, что требует от модели «заземление» GUI. Когда она видит скриншот и команду вроде «нажми кнопку отправки», одновременно должны совпасть три вещи:

Визуальное выравнивание — это сопоставление пиксельных паттернов с элементами интерфейса. Кнопка имеет определённую форму, цвет, размер, которые модель должна распознать.

Функциональное выравнивание — понимание того, что элемент делает. Поле ввода визуально отличается от надписи, а кликабельная кнопка — от статичной иконки, даже если у них есть общие визуальные черты.

Геометрическое выравнивание — это работа с пространственными отношениями. «Кнопка над строкой поиска» или «поле справа от подписи» требует понимания, где что находится относительно друг друга, а не просто как вещи выглядят.

Важный момент: большинство бенчмарков смешивают всё это в одну кучу. Когда модель набирает 85%, непонятно — она одинаково хороша во всём или блестяще справляется с визуалом, но совершенно не понимает геометрию. А ведь способы решения проблем разные.

Где модели реально ломаются

GUI-Perturbed тестирует каждую ось выравнивания отдельно. Результаты показывают иерархию хрупкости:

1. Пространственные инструкции катастрофически слабы

Вот главное открытие. Когда инструкция меняется с «нажми кнопку отправки» на «нажми кнопку над формой контактов», точность падает на 27–56 пунктов в зависимости от модели. Падение на 27 пунктов — это тревожно. На 56 — это приговор для любого продакшен-решения.

Модель может идентифицировать конкретную кнопку по имени. Но попросите её рассуждать о том, где эта кнопка расположена в пространстве — и всё разваливается.

Проблема усугубляется тем, что естественные языковые инструкции часто содержат пространственные ссылки. «Прокрути вниз и нажми на форму» или «выбери опцию под заголовком» — это интуитивные способы, которыми люди описывают задачи. Для текущих моделей они почти неработоспособны.

2. Визуальные возмущения бьют больно

Эксперимент с зумом — не исключение. Изменение масштаба до 70% снижает точность на 2–6 пунктов у всех протестированных моделей. Не катастрофа, но задумайтесь: модель научилась распознавать элементы при одном конкретном масштабе, и изменение масштаба ломает эту калибровку.

Реальные пользователи меняют масштаб. Разные мониторы имеют разные настройки DPI. Веб-приложения рендерятся в разных физических размерах в зависимости от устройства. Это повседневные ситуации, а не экстремальные условия.

Более тревожный вывод — что это говорит о процессе обучения моделей. Они не строят инвариантные к масштабу представления, как люди. Они запоминают внешний вид в разрешениях, которые встречались при обучении.

3. Chain-of-thought имеет свою цену

Добавление шага рассуждения перед действием помогает на сложных реляционных задачах, но реально ухудшает результат на простых прямых. Модели нужно знать, когда думать, а когда просто действовать.

Это создаёт практическую проблему при деплое. Нельзя просто включить цепочку мыслей везде. Нужен либо роутер, который решает, когда думать, либо модель, которая одинаково хороша в обоих режимах. Текущие модели явно переусердствуют с размышлениями над простыми задачами.

Что реально даёт пост-обучение

Самый трезвый вывод: дополнительное пост-обучение, заточенное под GUI, не решает ни одну из этих проблем.

Три протестированные модели имели одинаковую базу, но прошли разное количество специализированного файн-тюнинга. Дополнительное обучение повысило результаты на замороженных сценах. Но не улучшило устойчивость к визуальным возмущениям, пространственному мышлению или чувствительность к масштабу.

Это означает, что прирост на бенчмарках от пост-обучения может быть частично иллюзорным. Модели становятся лучше именно на тестовом распределении, а не в самой задаче. Они точнее подгоняются под бенчмарк, не развивая обобщающие способности.

Для команд, оценивающих модели или строящих на них продукт, это критически важное различие. «Достигает 92% на ScreenSpot-v2» говорит только, что модель умеет распознавать GUI-элементы на скриншотах. Ничего не говорит о том, справится ли она с изменчивостью реального веб-сёрфинга.

Что это значит для разработчиков

Если вы строите приложения на базе агентов для управления компьютером, из этого исследования следуют практические выводы:

Ваша продуктовая среда будет жёстче, чем тестовая. Если вы проверяете систему на фиксированном наборе страниц — вы не измеряете реальную производительность. Добавьте тестирование с возмущениями в свой пайплайн: пробуйте задачи при разном зуме, с вариациями CSS, на страницах после редизайна.

Обработка пространственных инструкций требует особого внимания. Если ваше приложение использует естественные языковые команды с пространственными ссылками, текущие универсальные модели будут спотыкаться. Возможно, стоит ограничить формат инструкций, добавить запасные пути с явным предсказанием координат или использовать специализированные модели для подзадач, связанных с пространственным мышлением.

Следите за редизайнами. Когда целевые сайты меняют вёрстку, точность вашего агента может резко упасть — не потому что модель стала хуже, а потому что она столкнулась с визуальной конфигурацией, которую не видела раньше. Кешируйте стратегии определения расположения элементов и мониторьте дрейф.

Что дальше

Это исследование не означает, что агенты для управления компьютером бесполезны. Оно означает, что индустрии нужны лучшие способы измерять то, что действительно важно: устойчивость, а не бенчмарк-показатели.

Хорошая новость: проблемы теперь видны и измеримы. Методология GUI-Perturbed даёт способ тестировать модели по конкретным осям. Если вы строите или покупаете такие системы — требуйте результаты устойчивости к возмущениям, а не только статичные бенчмарки.

Проблема тройного выравнивания — визуального, функционального и геометрического — реальна. Она решаема. И её решение откроет дорогу следующему поколению надёжных ИИ-агентов, которые действительно работают в том беспорядочном, изменчивом мире, где живут ваши пользователи.

А пока — воспринимайте эти 90%+ на бенчмарках как отправную точку, а не финишную черту. Ваши пользователи оценят, когда их ИИ-ассистент без проблем справится с браузером на 70% масштаба.