Новый бенчмарк Alibaba: ИИ-агенты закрывают часть требований, но не всю задачу

Alibaba вместе с Китайским университетом Гонконга, Шанхайским университетом Цзяотун и Наньянским технологическим университетом представила Co-Design Bench. Это набор задач для ИИ-агентов, которые пишут код. Модели проверяют на том, что реально просят пользователи: взять уже работающее веб-приложение и изменить его по описанию, иногда вместе со скриншотом, голосовой записью, видео или документом. Итог по десяти протестированным моделям такой. Лучшая из них выполняет заметную часть требований в среднем по задаче, но целиком закрывает лишь меньшую долю задач. Отдельные пункты она делает, а всё вместе собрать не может.

Задачи из настоящих сессий, а не из синтетики

Многие тесты для кодинг-агентов строят искусственно: ломают эталонную страницу и просят починить или выдают заранее заданный набор правок. Авторы Co-Design Bench взяли другой путь. Они взяли запросы из реальных сессий пользователей, убрали дубликаты и оставили те, где есть что проверять. Для каждой задачи восстановили запускаемое приложение «до правки», а также историю сессии и вложения.

В тесте два трека:

• Multimodal Editing (ME) — локальные правки: оформление, структура, содержимое. У агента есть страница, выделенная область и запрос, иногда с картинкой, аудио, видео или документом. Пример: в чеке указана сумма, и её нужно согласованно обновить в таблице и в итоговых сводках.
• Repository Editing (RE) — согласованные изменения во фронтенд-репозитории: компоненты, маршруты, состояние, поток данных. Пример: редактор спортивных видеоклипов, где нужно ограничить число и длительность клипов, выровнять таймлайн при масштабировании и снова включить вставку после удаления или разрезания клипа.

Задачи оценивают по трём направлениям: понимание контекста (Grounded Understanding), преобразование интерфейса (UI Transformation) и реализация функций (Functional Implementation).

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

Как проверяют без эталонного кода

Эталонного решения у задачи нет, потому что одну правку можно сделать разными способами. Поэтому критерии описывают результат: что должно появиться и как себя вести. Реализацию они не диктуют. Сравнение с исходным приложением помогает понять, что изменилось, а что нужно было сохранить.

Проверка идёт в несколько шагов:

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

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

Что показали десять моделей

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

• Доля выполненных критериев и доля полностью решённых задач заметно расходятся. Пользователь, которому реализовали большую часть просьбы, всё равно получает неработающий сценарий.
• Рейтинг моделей отличается между треками: лучшая на локальных правках не обязательно лучшая на правках репозитория.
• У всех десяти моделей полнота выполнения хуже на репозиторных задачах с тремя-четырьмя типами изменений (структура, стиль, интерактивность, содержимое), чем на задачах с одним-двумя.

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

Co-Design Bench авторы сопоставляют с другими бенчмарками. Design2Code, WebSight-Test и WebRenderBench проверяют перенос скриншота в код. IWR-Bench добавляет видео взаимодействия. WebGen-Bench и FrontendBench тестируют сайты, созданные с нуля. DesignBench, MT-Web2Code, WebCompass и FronTalk касаются правок и диалога. SWE-bench, SWE-bench Multimodal и SWE-Lancer берут задачи из GitHub и фриланса. Новизна Co-Design Bench в сочетании реальных сессий, мультимодальных вложений, запускаемого исходного состояния, проверки без эталона и состязательного верификатора.

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