Мультимодальные модели – грубый и дорогой инструмент

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

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

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

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

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

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

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

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

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

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

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

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

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

Благодаря такому слою, модель сможет лучше решать широкий спектр задач и оставаться универсальной.

P.S. Статья написана человеком. Это не разбор готовой реализации и не попытка продать «почти решённую» задачу. Цель – аккуратно зафиксировать саму проблему.