Skip to main content
RLHFpost-trainingLLM

Чому RL-посттренінг місцями «тупить» модель

RL-посттренінг для мовних моделей часто підвищує цільові метрики, але ризикує звузити поведінку поза цільовим сценарієм. Для бізнесу це критично: впровадження ШІ може дати чудову автоматизацію на основних задачах, але може зламати рідкісні кейси та знизити загальну надійність системи. Важливо ретельно оцінити компроміси.

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

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

Якщо говорити приземлено, це звичайна ціна за впровадження ШІ під зрозумілий KPI. Я оптимізую систему на слідування інструкціям, preference win-rate, математичну точність або безпечний стиль відповіді, і модель починає щільніше жити всередині цього коридору. У популярних сценаріях це дає приріст. У рідкісних, дивних, неврахованих завданнях починаються дрібні просідання.

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

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

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

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

Другий момент щодо архітектури. Я б не ставив один і той самий посттренінг на всі ролі одразу. Десь потрібен «вилізаний» RL-варіант, а десь краще залишити ширшу базову модель і обв’язати її правилами, валідацією та маршрутизацією.

Саме такі компроміси ми в Nahornyi AI Lab зазвичай і розкладаємо по поличках для клієнтів: де доречна агресивна AI integration, а де краще не душити модель заради красивої метрики. Якщо ваша автоматизація вже стала поводитися надто «правильно», але перестала справлятися з живими кейсами, давайте подивимося на ваш пайплайн і зберемо AI solution development без цієї пастки.

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

Поділитися статтею