Правдоподобный кадр может показывать провал
Агент нажал кнопку сохранения, окно закрылось, а итоговый снимок выглядит спокойно. Это еще не означает, что файл записан на диск. Приложение могло показать уведомление об ошибке и сразу скрыть его, отрисовать промежуточное состояние или сохранить данные в другой профиль.
Большинство испытаний экранных агентов долго опиралось на последовательность снимков и итоговое мнение модели с компьютерным зрением. Такая проверка оценивает внешний вид. Рабочая задача обычно сформулирована через состояние: существует файл, включена настройка, создана запись, отправлено сообщение.
Interactive Reward Agent сначала превращает задание в набор условий успеха, затем сам собирает доказательства через системные, прикладные и экранные инструменты. Он может проверить файл, настройку программы и состояние окружения вместо того, чтобы судить по последнему кадру.
На GUI-RewardBench из 321 траектории система получила 86,9% точности. Использование ее в качестве сигнала обучения с подкреплением дало 34% успешности на OSWorld. Выборка небольшая, а проверяющий агент сам способен ошибиться. Сильная часть подхода - порядок работы: сначала записать условия, потом запросить фактическое состояние.
Проверяющие модели склонны засчитывать успех
OSReward собрал траектории экранных агентов с проверкой людьми на нескольких платформах. Сильные зрительно-языковые модели систематически проявляли снисходительность: принимали неудачные выполнения за успешные.
Авторы открыли 100 тысяч размеченных решений OS-Shepherd-100K и модели проверки на 9 и 35 млрд параметров. Они заявляют качество на уровне коммерческих проверяющих при снижении стоимости на 30-60%. Пока это сравнение авторов, но открытые данные позволяют перепроверить его на другом контуре.
Смежный аудит пяти популярных наборов задач вручную рассмотрел 150 траекторий, помеченных как неудачные. Для 15,3% итоговая отметка была неверной: 10,7% составляли ошибки проверяющего, еще 4,7% приходились на сломанные задания.
Ошибки в обе стороны портят обучение. Ложный успех учит агента повторять нерабочее действие. Ложный провал отбрасывает правильную траекторию. Общая доля успешных задач скрывает оба случая.
Последовательность снимков не равна последовательности событий
Экран обновляется асинхронно. После щелчка часть окна меняется сразу, другая ждет сеть, а снимок может быть сделан до завершения отрисовки. Если кадры переданы модели в определенном порядке, она склонна принять этот порядок за причинный.
Desktop-Delta содержит 2 013 проверенных переходов в программах Linux. Модель должна определить, какое изменение вызвано действием, отклонить устаревший или посторонний снимок и восстановить временной порядок.
Лучший результат точного совпадения составил 65,1-65,7%. Модели часто доверяли предложенному порядку кадров. Щелчок распознавался заметно лучше перетаскивания: показатель F1 равнялся 0,96 против 0,76.
Это объясняет знакомый отказ экранного агента. Он видит кадр, похожий на ожидаемый, и продолжает процесс, хотя приложение еще не завершило переход. Следующее действие попадает не в то окно или изменяет не тот объект.
Проверять изменение, а не картинку
Для каждого действия стоит заранее определить ожидаемую разницу между состояниями. После сохранения должен появиться файл с известным путем и содержимым. После изменения настройки значение должно читаться через интерфейс приложения, конфигурацию или системный запрос. После отправки сообщения нужен идентификатор на стороне сервиса.
Снимок остается полезным доказательством, особенно если другого интерфейса нет. Но он должен сопровождаться временем создания, идентификатором окна и проверкой устойчивости: состояние сохраняется после ожидания, повторного открытия или обновления.
Если программа предоставляет программный интерфейс или базу данных, проверяющий должен читать их напрямую. Желательно использовать канал, отличный от того, которым действовал агент. Иначе одна ошибка приложения способна одновременно создать ложное состояние и подтвердить его.
Для необратимых операций полезна двухступенчатая схема. Сначала агент готовит изменение и показывает ожидаемую разницу состояния. Затем контроллер выполняет действие один раз с уникальным идентификатором и проверяет ответ сервиса. Повтор после задержки не должен создавать второе сообщение, второй заказ или второй платеж. Умение безопасно повторить проверку особенно важно, когда экран замер, а результат вызова неизвестен.
Если прямого канала проверки нет, можно использовать несколько слабых сигналов: устойчивый снимок после ожидания, повторное открытие объекта, поиск его по уникальному признаку и отсутствие сообщения об ошибке. Такой набор не превращает картинку в факт, но делает ложное подтверждение менее вероятным и оставляет понятную причину для передачи человеку.
Разметить ошибки самого испытания
При ручном аудите недостаточно меток "успех" и "провал". Нужны как минимум четыре причины: ошибка агента, ложное решение проверяющего, сломанное задание и неопределенный случай. Иначе улучшение проверяющей модели может выглядеть как ухудшение агента, а ремонт задания - как рост его способности.
Небольшую выборку успешных и неуспешных траекторий стоит пересматривать людьми после каждого крупного изменения оценки. Особое внимание нужно уделять действиям с задержкой, перетаскиванию, нескольким окнам и состояниям, которые нельзя увидеть на экране.
Проверяющую систему тоже нужно версионировать. Старые траектории следует прогонять новой и предыдущей версиями параллельно. Любое изменение доли успеха тогда раскладывается на три части: агент стал действовать иначе, проверяющий поменял решение или само задание было исправлено.
Экран показывает наблюдение. Успех задачи является утверждением о системе. Между ними нужен явный проверяющий переход.
Без него красивый финальный кадр остается только правдоподобной иллюстрацией.