ecom.tech сравнила эволюционное дообучение Qwen3-4B с SFT и GRPO для тестов на Kotlin

Команда ecom.tech проверила, можно ли заставить небольшую модель Qwen3-4B-Instruct писать полезные unit-тесты для Kotlin-бэкенда не обычным SFT, а через эволюционный алгоритм Evolution Strategies. Практический результат оказался сильным: в задаче генерации тестов такой подход обошел и supervised fine-tuning, и GRPO по итоговому reward и coverage.

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

Чтобы оценить, можно ли это исправить дообучением, исследователи собрали датасет из 1500 примеров: 1300 для обучения и 200 для теста. На вход модель получала не только тестируемый класс, но и полный контекст вокруг него, собранный агентом на базе qwen-code, а на выходе должна была сгенерировать готовый файл с unit-тестами. Для оценки использовали две метрики.

Первая — Coverage, но не в привычном смысле покрытия строк, а как functional coverage: насколько сгенерированный тест вообще попадает в тот же публичный функционал, что и эталонный. Вторая — CodeBLEU, метрика, которая смотрит не только на совпадение токенов, но и на синтаксис и поток данных в коде. Поскольку стандартный CodeBLEU не поддерживает Kotlin, команде пришлось добавить эту поддержку отдельно через tree-sitter-kotlin и собственный набор ключевых слов.

Reward-функцию сделали простой: 0,6 веса отдали CodeBLEU и 0,4 — Coverage, чтобы одновременно учитывать и форму кода, и его практическую полезность. Суть Evolution Strategies в этом эксперименте была такой: вместо градиентного обновления брали около 30 возмущенных копий базовой модели, добавляя к весам гауссов шум, затем заставляли каждую копию генерировать ответ в детерминированном режиме и оценивали его наградой. После этого базовые веса сдвигались в сторону тех изменений, которые дали лучший результат.

Такой подход проще распараллеливать, он не требует хранить тяжелые градиенты и, по мнению авторов, меньше склонен к reward hacking. За основу взяли открытый проект Evolution Strategies at Scale с ускорением на vLLM и обучали модель на кластере из 8 H100. Из-за дороговизны полного прохода по датасету на каждой итерации ввели батчинг: случайно выбирали по 32 примера.

Эксперимент дал заметный прирост уже после 500 итераций. К концу обучения CodeBLEU вырос на 21,3% относительно базовой модели, а Coverage — на 18,6%. Лучший результат у ES дал coverage 0,7381 и максимальный итоговый reward; по выбранным метрикам он обошел не только SFT и GRPO, но даже более крупный Qwen3-Coder-480B.

При этом картина у конкурирующих методов оказалась показательной: SFT выдавал синтаксически аккуратные тесты, но слабо попадал в нужную логику, а GRPO в этом сетапе вообще деградировал по обеим метрикам. Для узкой инженерной задачи вывод выглядит прямолинейно: эволюционное дообучение действительно может быть рабочим инструментом даже для относительно небольшой модели. Но дальше началась менее приятная часть.

На фоне свежих работ о catastrophic forgetting команда отдельно проверила, что происходит с общими знаниями дообученной модели. Для этого ES-версию Qwen3-4B-Instruct прогнали через GPQA — сложный научный бенчмарк. Падение accuracy составило в среднем 2,1% в zero-shot и 5,3% в five-shot chain-of-thought.

Особенно заметно просела способность использовать контекстные подсказки: польза от few-shot примеров сократилась на 41–72%. Гипотеза совпадает с тем, что показывают и другие исследования: ES вносит плотные изменения почти во все веса модели, из-за чего она лучше решает целевую задачу, но сильнее отклоняется от базового состояния и забывает часть прежних навыков. Что это значит на практике?

Evolution Strategies выглядит не как универсальная замена RL, а как мощный специализированный инструмент для компаний, которым важнее локально выжать максимум из модели под конкретный pipeline. Если есть понятная reward-функция, достаточно вычислительных ресурсов и допустим компромисс по общим способностям, ES уже сейчас может дать ощутимый выигрыш. Но для продуктовых команд это еще и напоминание: повышение качества на одной задаче не бесплатно, и дальше борьба пойдет не только за новые метрики, но и за способы дообучать модели без потери их базовой гибкости.