Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Zhiwei Zhang и соавторы предложили TGOPD — вариант дистилляции с проверкой модели-учителя для каждого запроса; работа опубликована как препринт, не проходивший рецензирования. По замерам авторов, TGOPD обошёл обычную OPD во всех шести сочетаниях предметной области и масштаба модели. Это важно командам, которые дообучают LLM на ответах ученика и располагают автоматической проверкой результата.
Что сделали
Дистилляция на ответах ученика (on-policy distillation, OPD) устроена так: модель-ученик генерирует ответ, а замороженная модель-учитель оценивает каждый его токен. Ученик получает плотный обучающий сигнал — не одну итоговую оценку за весь ответ, а указание на каждом шаге генерации.
Для сближения распределений используется обратная дивергенция Кульбака — Лейблера. Такая функция потерь концентрирует вероятность ученика на вариантах, которым учитель уже назначает высокую вероятность. Это ускоряет обучение, когда учитель прав, но с тем же усилием закрепляет его уверенные ошибки. Обычная OPD не проверяет правильность ответа учителя перед обновлением весов.
TGOPD добавляет перед дистилляцией шлюз надёжности. Для текущего запроса учитель генерирует три пробных ответа, после чего автоматический проверяющий модуль оценивает результат. Если проходят хотя бы два ответа, запрос получает обычный плотный сигнал OPD. В противном случае сигнал учителя полностью отключается, а ученик обучается по проверяемому результату через групповую относительную оптимизацию политики (GRPO).
Ветка GRPO сравнивает итоговые оценки нескольких ответов ученика внутри одной группы. Ответы выше среднего получают положительное направление обновления, ниже среднего — отрицательное. Если проверка дала одинаковый результат для всей группы, обновления не происходит. Авторы принципиально не смешивают OPD и GRPO на одном запросе: шлюз выбирает только одну ветку.
Пробные ответы учителя генерируются параллельно с ответами ученика. В асинхронной OPD узел учителя обычно ждёт, пока ученик закончит генерацию, поскольку основная работа учителя — один проход по уже готовым токенам. TGOPD пытается занять это окно проверочными генерациями, не меняя саму модель ученика или архитектуру последующего вывода.
Что показали
Авторы обучали модели на математике, программном коде и следовании инструкциям. В многопредметном режиме средний результат по набору бенчмарков вырос относительно обычной OPD на 1,14 пункта для меньшей модели и на 0,95 пункта для большей. Наиболее заметное преимущество получилось в задачах по коду, где уверенность учителя хуже отражала правильность его ответа.
Отдельный результат относится к загрузке инфраструктуры. В измеренном запуске средняя загрузка GPU на узле учителя поднялась с 9,8% до 78,9%, поскольку проверочные генерации заняли периоды ожидания. Полностью бесплатными эти проверки не стали: в сопоставимом запуске на коде среднее время шага увеличилось на 5,9%.
Дополнительное сравнение показало, что основная часть улучшения возникала уже при простом исключении ненадёжного сигнала учителя. Замена этого сигнала на GRPO давала меньшую добавку и не была лучшим вариантом в каждом режиме обучения.
Ограничения
Метод требует автоматического проверяющего модуля, способного оценить законченный ответ. В экспериментах использовались модульные тесты для кода и проверки по правилам для математики и следования инструкциям. Работа поэтому не показывает, сохранится ли результат в открытых задачах, где правильность нельзя надёжно свести к двоичной оценке.
Проверка охватывает модели семейства Qwen двух масштабов — 4B и 35B — и три предметные области. Сравнения проводились с общей инициализацией ученика, теми же учителями, корпусами и конвейером обучения. Это уменьшает различия между экспериментами, но не отвечает на вопрос о переносе результата на другие семейства моделей, типы учителей и проверяющие модули.
Системный выигрыш также измерен на отдельных конфигурациях, а не на произвольных кластерах. Он зависит от того, простаивает ли узел учителя и помещаются ли пробные генерации в период работы ученика. Авторы не провели контролируемое сравнение с вариантом GRPO, где оценки нормируются по стандартному отклонению, и не указали, как часто резервная ветка давала нулевое обновление из-за одинаковых результатов всей группы.
Что это значит
Для команд, уже использующих OPD в задачах с проверяемым результатом, работа предлагает локальное изменение обучающего конвейера, а не смену базовой модели. Понадобятся генерация нескольких проб учителя, их проверка и маршрутизация функции потерь. Архитектуру рабочего вывода после обучения менять не требуется.
Практический смысл TGOPD состоит не только в выборе между двумя способами обучения. Авторы показывают, что уверенность учителя сама по себе плохо заменяет проверку правильности, особенно в коде. Если конвейер безусловно переносит распределение учителя на каждый запрос, добавление шлюза стоит проверить до увеличения бюджета обучения или размера учителя.
Планы существенно меняются только при совпадении двух условий: для задачи уже существует недорогая автоматическая проверка, а узел учителя простаивает во время генерации ученика. Тогда эксперимент с TGOPD можно провести как вариант текущего этапа дообучения и отдельно измерить качество, время шага и загрузку всего кластера. Для продуктов с открытыми ответами и оценкой человеком работа пока не даёт основания перестраивать обучение: именно необходимый для шлюза сигнал там не исследован.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
