Опубликовано 20 июня 2026 г.
Куррикулум по неуверенности критика: как учить веб-агента на одной видеокарте
Ограничение как постановка задачи
Обучение веб-агента через RL обходится дорого, потому что среда медленная, эпизоды длинные, а награда разреженная. Обычно эту проблему решают кластером. В этой работе условие было обратным: одна потребительская видеокарта на 16 ГБ. Из этого ограничения следует вся остальная архитектура.
Иерархия: замороженный планировщик и обучаемый исполнитель
Qwen3-8B (frozen, 4-bit NF4) ← планировщик, ставит подцель
↓ подцель (JSON)
DeBERTa-v3-small (frozen)
→ Transformer (2 слоя, 4 головы) → GRU(256)
→ тип действия + pointer attention (какой элемент страницы)
↓ CLICK / TYPE / SCROLL / SELECT
BrowserGym / MiniWoB++
Обучается только исполнитель, у которого несколько миллионов параметров против восьми миллиардов у планировщика. Планировщик и энкодер заморожены и работают в 4-битной квантизации. Элемент страницы выбирается через pointer attention, потому что число элементов на странице заранее неизвестно и обычная классификация здесь не подходит.
Идея 1: куррикулум по дисперсии value-функции
Классический куррикулум ведёт агента от простых задач к сложным в заранее заданном порядке. При этом сложность задач определяет автор, и она может не совпадать с тем, что на самом деле трудно для агента.
Здесь порядок задаёт критик. Для каждой задачи хранится дисперсия его оценок, и чем она выше, тем чаще выбирается задача. Высокая дисперсия означает, что агент плохо понимает ценность своих действий в этой задаче, поэтому обучение на ней даст больше всего.
Разброс дисперсии между задачами достиг 2740 раз, от нуля на click-link, где агенту уже всё понятно, до 0.00274 на social-media. Значит, механизм действительно перераспределял бюджет обучения между задачами.
Идея 2: Reward Fusion вместо бинарного успеха
На длинных эпизодах бинарная награда почти всегда равна нулю, и градиенту не за что зацепиться. Поэтому награда собирается из четырёх слагаемых:
R = 0.5·ORM + 0.3·R_DOM + 0.2·R_waypoint − штрафы
- ORM: оценка модели-судьи по итоговому состоянию;
- R_DOM: программная проверка DOM, например заполнено ли поле, закрыт ли диалог, отмечен ли чекбокс;
- R_waypoint: промежуточные вехи внутри эпизода;
- штрафы: за лишние действия и недопустимые переходы.
В логах прогона встречается 100 различных значений награды в диапазоне от −8.4 до +0.92. Это подтверждает, что награда действительно градуированная и работает как задумано.
Результаты
| Метрика | Значение |
|---|---|
| Средний SR (фаза 3) | 42% |
| Финальный SR (последние 10 итераций) | 61,7% |
| Задач с ненулевым SR | 20 из 25 |
| Шагов среды | 50 000 |
Лучшие результаты показали задачи click-dialog и focus-text (100%), а также click-button (60%).
Что не получилось
Неудачи в этой работе стоит разобрать так же подробно, как результаты.
- choose-date / book-flight: jQuery-датапикер при перерисовке DOM накапливает идентификаторы элементов, из-за чего длинная навигация становится ненадёжной.
- enter-date / enter-time: три поля ввода используют один идентификатор, и штатный
fill()в текущей версии среды не срабатывает. - email-inbox / search-engine: эти задачи требуют рассуждения, выбора элемента для них недостаточно, и здесь pointer-политика упирается в свой потолок.
- PopArt: статистики нормализации value не сохраняются в чекпойнт и пересчитываются при возобновлении обучения.
Первые две проблемы связаны с дрейфом версий среды и к самому методу отношения не имеют. Две последние отражают реальные ограничения архитектуры, и именно они определяют направление следующей работы.