Почему RL-посттрейн местами «тупит» модель

Технический контекст

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

Если говорить приземленно, это обычная цена за AI implementation под понятный KPI. Я оптимизирую систему на instruction-following, preference win-rate, math accuracy или безопасный стиль ответа, и модель начинает плотнее жить внутри этого коридора. В популярных сценариях это дает прирост. В редких, странных, неучтенных задачах начинаются мелкие просадки.

Я копался в таких пайплайнах не раз, и самые частые побочки тут знакомые: reward hacking, entropy collapse, переобучение на прокси-метрику. Модель учится делать не то, что я имел в виду, а то, что лучше оплачивается функцией награды. Поэтому она может выглядеть аккуратнее, увереннее и послушнее, но при этом чуть хуже держать неожиданные повороты запроса.

Особенно забавно это видно на reasoning-моделях. Я могу поднять пошаговую корректность на математике или коде, но одновременно ухудшить калибровку, разнообразие решений или поведение вне узкого формата ответа. Не катастрофа, скорее смерть от тысячи мелочей, но в продукте именно такие мелочи потом и вылезают.

Влияние на бизнес и автоматизацию

Для AI automation вывод простой: не путайте рост benchmark score с ростом надежности системы. Если ваш агент делает саппорт, продажи или внутренний поиск, он может стать лучше в 80% частых диалогов и хуже в дорогих редких кейсах, где ошибка реально стоит денег.

Второй момент про архитектуру. Я бы не ставил один и тот же посттрейн на все роли сразу. Где-то нужен «вылизанный» RL-вариант, а где-то лучше оставить более широкую базовую модель и обвязать ее правилами, валидацией и маршрутизацией.

Именно такие компромиссы мы в Nahornyi AI Lab обычно и раскладываем по полочкам для клиентов: где уместна агрессивная AI integration, а где лучше не душить модель ради красивой метрики. Если у вас автоматизация уже стала вести себя слишком «правильно», но перестала справляться с живыми кейсами, давайте посмотрим на ваш пайплайн и соберем AI solution development без этой ловушки.

Мы ранее рассматривали метод Simple Self-Distillation, который улучшает генерацию кода без сложного RL и верификаторов. Этот подход становится особенно уместен, когда мы видим, как RL-постренин может ухудшать выполнение непопулярных задач.