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

Что такое VisualRepair

VisualRepair: это фреймворк автоматического ремонта программ (Automated Program Repair, APR), который работает не с текстовыми описаниями ошибок, а с визуальными артефактами: скриншотами интерфейса, GIF-анимациями взаимодействия, снимками IDE и терминала. Система принимает heterogeneous visual inputs: разнородные визуальные данные: из реального баг-репорта и генерирует рабочий код-исправление.

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

Результаты впечатляющие: 196 из 517 инстансов решены на бенчмарке SWE-bench Multimodal (resolve rate 37.91%), при средней стоимости $0.47 за один исправленный баг. Это превосходит все существующие подходы, как open-source (GUIRepair, SVRepair на уровне 35.98%), так и коммерческие системы (Zencoder: 158 инстансов, Globant Code Fixer Agent: 153).

Почему визуальные баги: это отдельная проблема

Традиционные системы автоматического ремонта (Defects4J, SWE-bench) работают с текстовыми баг-репортами и unit-тестами. Но современные приложения: это веб-интерфейсы, дизайн-системы, IDE-плагины. Баги в них проявляются визуально: сломанный layout, неработающая анимация, некорректное отображение данных. Unit-тест для CSS-бага написать почти невозможно: нужно именно увидеть, что не так.

SWE-bench Multimodal расширил классический SWE-bench, добавив визуальный контекст. Теперь баг-репорт может содержать не только текст, но и скриншот, GIF взаимодействия, снимок кода в редакторе. Это делает задачу реалистичнее: именно так разработчики получают баги в реальной жизни. Но это же делает задачу значительно сложнее для LLM: модель должна понять, что именно на картинке не так, сопоставить это с кодом репозитория и сгенерировать патч.

Архитектура: три ключевых компонента

VisualRepair состоит из трёх последовательных стадий, каждая решает свою подзадачу.

Image Type-aware Tool Calling (ITTC). Первый компонент классифицирует каждое входное изображение и применяет специализированный набор инструментов. Для GIF: извлечение ключевых кадров через mean absolute error между соседними фреймами: динамический порог τ = μ + k·σ отбирает только кадры, где визуально что-то изменилось. Это важно: в типичной GIF-анимации 90% кадров почти идентичны, но для понимания бага нужны именно моменты перехода. OCR-инструмент (PaddleOCR) извлекает текст из снимков IDE и терминала: стектрейсы, сообщения об ошибках, фрагменты кода. Crop-инструмент вырезает неинформативные регионы (пустые фоны, пустые canvas-области), чтобы не раздувать контекст визуальных токенов. Code Library tool находит шаблоны подсветки синтаксиса, релевантные конкретному репозиторию, и помогает воспроизвести баг.

Hierarchical Fault Localization. Второй этап сужает пространство поиска: из всего репозитория (тысячи файлов) находит релевантные файлы, а в них: конкретные code hunks. Это критически важно для эффективности: LLM не может держать в контексте весь код проекта, ей нужен целевой фрагмент в 50–200 строк.

Dynamic Test-time Region Focusing (DTRF). Третий и наиболее оригинальный компонент. После того как система определила, какой файл и какие строки потенциально дефектны, она возвращается к исходному скриншоту и применяет многоуровневый фокус на проблемную область: zoom-in (приближение к конкретному элементу), zoom-out (отдаление для контекста), горизонтальные и вертикальные срезы. Каждый вариант подачи изображения генерирует свой кандидат-патч. В итоге система отбирает лучший патч по двум критериям: компиляция проходит успешно и визуальная разница между «до» и «после» показывает, что проблема действительно устранена.

Конкретные результаты

На уровне репозиториев VisualRepair показывает особенно сильные результаты там, где другие подходы буксуют. На bpmn-js (диаграммы бизнес-процессов), 75.93% resolve rate, потому что баги там описываются через GIF взаимодействия, и инструмент извлечения ключевых кадров из GIF критически важен. На openlayers (карты), 97.47% resolve rate (77 из 79 инстансов), потому что DTRF эффективно работает с зашумлёнными скриншотами, где большая часть изображения: нерелевантная карта. На carbon (дизайн-система IBM), 21.05%.

Средняя стоимость фикса: $0.47. Для сравнения, OpenHands-Versa с Claude Sonnet 4 стоит $1.79 за инстанс, SWE-agent: от $1.52 до $3.11. При этом VisualRepair решает на 10 больше инстансов, чем ближайший конкурент среди open-source систем.

Анализ различий показывает: все топ-5 методов имеют общее ядро из 137 решённых инстансов (относительно простые баги). Но VisualRepair уникально решает ещё 10 дополнительных инстансов: больше, чем любой другой метод. Эти 10 случаев: именно те сложные визуальные баги, где комбинация ITTC + DTRF даёт преимущество.

Почему это работает: разбор ключевых решений

Абляция (покомпонентное тестирование) показывает, что каждый модуль вносит вклад. Без ITTC система теряет до 8% resolve rate: она не понимает GIF и пропускает важные детали в IDE-снимках. Без DTRF: до 5%: модель «тонет» в пикселях большого скриншота и не может локализовать конкретный элемент. Без hierarchical fault localization: до 12%: LLM получает слишком широкий контекст и генерирует патчи в неправильных файлах.

Интересный инсайт: zoom-in/zoom-out в DTRF работают не просто как crop. Приближение помогает модели увидеть мелкие детали (размер шрифта, отступы, границы элементов), а отдаление: понять, как элемент соотносится с общим layout. Эта двойная перспектива имитирует то, как разработчик смотрит на баг: сначала видит общую картину, потом приближается к проблемному месту.

Сравнение с существующими подходами

Ключевое отличие VisualRepair от предшественников, в обработке разнородности визуальных данных. GUIRepair использует bidirectional pipeline (image2code → code2image), но применяет единый подход ко всем типам изображений. SVRepair фокусируется на self-verification, но не различает GIF, OCR и обычные скриншоты. OpenHands-Versa: более общий фреймворк для software engineering, но без специализации на визуальных артефактах.

VisualRepair решает эту проблему через Image Type-aware Tool Calling: каждый тип входного изображения проходит через специализированный pipeline. Это не просто оптимизация: это архитектурный сдвиг от «LLM смотрит на картинку» к «система понимает, что именно на картинке, и извлекает релевантную информацию».

Экспериментальные детали

SWE-bench Multimodal содержит 517 инстансов из реальных open-source проектов. Каждый инстанс: это реальный баг с визуальным артефактом (скриншот, GIF, IDE-снимок) и ground-truth патч из принятого pull request. Система запускалась три раза для каждого инстанса, результаты усреднялись. Дисперсия составила менее 1%, что говорит о стабильности подхода.

Репозитории в бенчмарке охватывают разные домены: визуализация данных (bpmn-js, openlayers), дизайн-системы (carbon), утилиты для разработчиков (lighthouse, prism). Это важно: VisualRepair показывает сильные результаты не на одном типе проектов, а на разнообразных задачах. На bpmn-js: 75.93% resolve rate (преимущественно GIF-баги), на openlayers: 97.47% (зашумлённые скриншоты карт), на carbon: 21.05% (дизайн-система с комплексными компонентами).

Стоимость вычислений: критический метрик для production-использования. VisualRepair в среднем тратит $0.47 на инстанс, используя o3-20250416. Это включает все API-вызовы: классификацию изображений, OCR, генерацию кандидатов, валидацию. OpenHands-Versa с Claude Sonnet 4 стоит $1.79 (в 3.8 раза дороже), SWE-agent: от $1.52 до $3.11 в зависимости от конфигурации. При этом VisualRepair решает больше инстансов, чем все конкуренты.

Архитектурные инсайты

Почему hierarchical fault localization даёт такой большой прирост (+12%)? Потому что современные репозитории содержат тысячи файлов. Даже с контекстным окном 128K токенов, LLM не может эффективно работать с 50,000 строками кода. Модуль локализации сужает пространство до 50–200 строк, которые модель может держать в рабочем контексте одновременно. Это не просто convenience: это необходимость для точной генерации патча.

DTRF (Dynamic Test-time Region Focusing) решает другую проблему: визуальное внимание. Большие скриншоты (1920×1080 и больше) содержат много нерелевантных пикселей. Модель может «отвлечься» на декоративные элементы, логотипы, соседние компоненты. Zoom-in/zoom-out не просто crop: это способ управления вниманием модели. При приближении модель видит детали (размер шрифта, отступы, границы), при отдалении: контекст (как элемент вписывается в layout). Генерация кандидатов из разных перспектив даёт разнообразие, а последующая валидация отбирает лучший.

ITTC (Image Type-aware Tool Calling) решает третью проблему: семантическое понимание разных типов изображений. GIF: это не просто «картинка, которая меняется», это последовательность состояний интерфейса. Без извлечения ключевых кадров модель видит либо один кадр (теряет динамику), либо все кадры (тонет в избыточности). OCR: это не просто «текст с картинки», это структурированная информация (стектрейс, сообщения об ошибках, фрагменты кода), которую модель может использовать как дополнительный сигнал.

Частые вопросы

Какие типы багов VisualRepair НЕ может исправить?

Система ориентирована на визуальные дефекты: layout, анимация, отображение. Логические баги (неправильный алгоритм, ошибка в бизнес-логике), которые не проявляются визуально, VisualRepair не чинит. Также система зависит от качества скриншота: если баг-репорт содержит только текстовое описание без визуальных артефактов, преимущества подхода не раскрываются.

На каких моделях это работает?

Текущие результаты получены с o3-20250416 (OpenAI) как backbone-моделью. Архитектура фреймворка модельно-независима: модули ITTC и DTRF работают с любой мультимодальной LLM, поддерживающей визуальный ввод. Ожидается, что с улучшением vision-моделей результаты будут расти.

Применимо ли это к реальным проектам?

Бенчмарк SWE-bench Multimodal построен из реальных pull request'ов популярных open-source проектов (JavaScript/TypeScript). Это не синтетические баги, а настоящие проблемы из репозиториев вроде bpmn.js, OpenLayers, Carbon Design System. Средняя стоимость $0.47 делает систему экономически целесообразной для production-использования.

Итог

VisualRepair демонстрирует, что мультимодальные LLM могут решать задачи, которые раньше требовали ручного труда дизайнеров и фронтенд-разработчиков. Ключевой вклад: не просто применение LLM к скриншотам, а специализированная обработка визуальных артефактов: разные инструменты для GIF, OCR, screenshot, и динамический фокус на проблемные регионы. 37.91% resolve rate при $0.47 за фикс: это не академический рекорд, а практический инструмент, который можно интегрировать в CI/CD и автоматически проверять визуальную корректность интерфейсов.

Для разработчиков это означает: визуальные регрессии можно ловить и чинить автоматически, без ручного QA. Для исследователей: направление multi-tool MLLM agents для software engineering только начинается, и VisualRepair показывает, что специализация инструментов под тип входных данных даёт больший прирост, чем просто более мощная модель.