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

Два способа «увидеть» сайт

Сегодня у моделей есть два основных способа воспринимать веб-интерфейсы:

• Чтение кода — HTML, CSS, JavaScript, бэкенд-логика (в случае ИИ-разработки).
• Анализ визуального представления — скриншоты, а в перспективе — видео или слайд-шоу с разными состояниями интерфейса.

Оба подхода неидеальны. Каждый из них вносит шум и не отражает реального состояния интерфейса после рендера.

Проблемы с кодом

Код даёт детальное описание, но не показывает, как интерфейс выглядит и ведёт себя в браузере. Например:

• Кнопка может формально существовать, но быть за пределами экрана.
• Элементы могут перекрывать друг друга.
• Выпадающее меню может быть недоступно из-за z-index.
• Верстка может быть сломана, но код — корректным.

Даже с увеличением контекста до миллиона токенов и применением сжатия, модель не получает полной картины.

Проблемы со скриншотами

Скриншоты отражают визуальное состояние, но требуют огромных вычислительных ресурсов. Чтобы понять интерфейс, нужно:

• Несколько viewport (размеров окна).
• Разные состояния: hover, focus, загрузка, модальные окна.
• Динамические изменения и, возможно, видео.

Это превращает задачу в тяжёлый анализ пикселей — хотя браузер уже хранит всю эту информацию в структурированном виде.

Человек видит иначе

Пользователь не анализирует каждый пиксель или строку кода. Он мгновенно распознаёт:

• Кнопки по форме и надписи (например, «войти»).
• Поля ввода, меню, модальные окна.
• Изменения при наведении или клике.

Это восприятие основано на структуре, а не на пикселях или тегах.

Нужен третий слой

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

Не нужно изобретать новый ИИ или отказываться от трансформеров. Но, возможно, моделям нужен постоянный модуль восприятия — не временный скрипт, а встроенный способ видеть интерфейс как структуру.

Такой модуль мог бы быть:

• Единым «глазом» для UI.
• Набором модулей на выбор с универсальным интерфейсом подключения.

Сайт для модели должен быть не просто кодом и не просто картинкой.

Нам нужен третий слой — лёгкое, точное представление интерфейса, пригодное для:

• Понимания страницы.
• Проверки вёрстки.
• Взаимодействия с UI.

С таким слоем модели останутся универсальными, но станут гораздо эффективнее в задачах с интерфейсами.

Примечание: Это не обзор реализации и не попытка продать решение. Цель — чётко обозначить проблему.

Нам нужно новое зрение для интерфейсов

Пока все в погоне за всё более универсальными ИИ-агентами пытаясь создать тот самый AGI по нашему подобию, мне кажется полезным спуститься на уровень ниже и посмотреть на более приземлённую инженерную проблему.

Мы неплохо научили модели работать с текстом, кодом, изображениями и инструментами. Мы научили их вызывать функции, научили эти ИИ писать собственные инструменты каждый раз для задач которые повторяются миллионы раз, видеть как мы(фото), думать как мы(рассуждения). Мы научились – дообучать их под новые сценарии через fine-tuning.

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

Сегодня у модели есть два типовых способа "увидеть" сайт. Первый – читать код: HTML, CSS, JS, и бэкенд (если вы используете ИИ для разработки). Второй – смотреть на скриншоты, а в более дорогом варианте – на видео(хоть и таких решений я не видел, и скорее не видео, а слайд-шоу, но считаю логичным внедрением для некоторых сценариев).

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

Но как быть с интерфейсом? Фото дает слишком много шума в виде пикселей, а код дает много лишнего шума в виде разметки, скриптов. Когда обычному пользователю: не нужно смотреть на каждый серый пиксель фона кнопки, или изучать все стили, js и html разметку сайта, он видит овал на котором написано "войти" – и понимает что это – кнопка, особенно, если при наведении или нажатии цвет фона кнопки меняется.

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

Скриншоты решают часть этих проблем, но слишком дорогой ценой. Чтобы действительно понять страницу, мало одного кадра. Нужны разные viewport (размеры окна просмотра), разные состояния, hover (наведение), focus (фокус), модалки, загрузка, динамические изменения, иногда и целые видео. В итоге задача, которую браузер внутренне уже "понимает" как структуру элементов, их геометрию и состояния, снова сводится к тяжёлому анализу пикселей. А зачем?

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

Мне кажется, здесьненужна новая глобальная архитектура ИИ. Не нужно отказываться от трансформеров и заново изобретать интеллект. Но, возможно, моделям нужен новый постоянный модуль восприятия – не очередная временная "рука",которую агент каждый раз заново пишет в виде скрипта, а встроенный способ видеть интерфейс как структуру. Но скорее новый глаз, либо целый набор на выбор с универсальным подключением (Но это уже другой вопрос).

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

Значит, и для моделей сайт (и другие интерфейсы, возможно) должны быть не просто кодом и не просто картинкой, и не нужно изобретать велосипед по типу интерпретации каждого сайта для ИИ. Нам явно не хватает третьего слоя – более лёгкого и более точного представления интерфейса, пригодного и для понимания страницы, и для проверки вёрстки, и для взаимодействия с UI.Благодаря такому слою, модель сможет лучше решать широкий спектр задач и оставаться универсальной.P.S. Статья написана человеком. Это не разбор готовой реализации и не попытка продать "почти решённую" задачу. Цель – аккуратно зафиксировать саму проблему.