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

Представьте типичную картину: ваш AI-агент листает веб-интерфейс безупречно. Кликает куда надо, заполняет формы, выполняет задачи с почти сверхчеловеческой точностью. А потом пользователь выставляет зум браузера на 110%, и модель начинает тыкать не туда — или вообще сдаётся.

Это не гипотетическая крайность. Это системная проблема, которая годами пряталась на виду.

Что на самом деле показывают цифры

Модели с результатами 90%+ на стандартных бенчмарках измеряют одну конкретную вещь — пиковую производительность в идеальных, заранее подготовленных условиях. Фиксированные скриншоты, фиксированные инструкции — ровно тот сценарий, под который модель и обучалась.

Но реальный мир устроен иначе. Сайты меняют темы оформления. Пользователи ставят разный зум. Тёмная тема переворачивает цветовые соотношения. Одну и ту же кнопку люди описывают десятками способов.

Модель с 90% на бенчмарке может показывать 40%, если хоть что-то изменится.

Решение из робототехники

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

Их решением стал domain randomization. Вместо тренировки в одной симуляции роботов забрасывали тысячами вариаций: случайные текстуры, углы освещения, цвета объектов, положения камеры. Цель — заставить политику выучить признаки, которые реально важны: структурные связи, функциональные свойства. А не поверхностные шаблоны, которые заучиваются наизусть.

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

Перенос на GUI-модели

Параллель с GUI-агентами поразительная. Современные модели определяют элементы по визуальным примитивам — форме, положению, цвету — а не по функциональной семантике. Белая прямоугольная область в верхней части экрана классифицируется как «поле ввода», хотя это может быть поиск, формула или адресная строка. Модель усвоила корреляции, которые работают в определённых условиях, но не распространяются на другие.

Проблема в том, что GUI-среды не дают той программной управляемости, которая есть у робототехнических симуляторов. Нельзя просто взять и подкрутить визуальные параметры десктопного приложения или поменять рендеринг сайта.

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

Почему это касается ваших деплоев

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

Когда вы деплоите GUI-контролирующего агента, вы не деплоите в лабораторию. Вы деплоите в хаотичный, изменчивый мир, где у пользователей разные браузеры, разные настройки, разные способы объяснить, чего они хотят.

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

Куда двигаться

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

Пробел между демо и продакшеном — это не ограничение текущих моделей. Это артефакт измерений. Мы меряли не то.

Так что когда увидите красивые цифры бенчмарков — caveat emptor.