Команда дослідників представила в препринті на arXiv (вересень 2026) Headroom-Drift Replay — новий примітив контролю реплею для GRPO-навчання мовних моделей, який обмежує повторне використання застарілих rollout-ів залежно від того, наскільки далеко поточна політика вже відійшла від тієї, що їх згенерувала.

GRPO (Group Relative Policy Optimization) — популярна альтернатива PPO для RLHF-подібного дотренування: замість окремої value-мережі вона оцінює якість відповіді відносно групи інших відповідей на той самий промпт. Метод набув поширення завдяки DeepSeek і зараз лежить в основі багатьох open-source пайплайнів дотренування reasoning- та agent-моделей.

Проблема, яку вирішує нова робота, суто технічна, але напряму впливає на практику: команди, що тренують агентів через RL, часто повторно використовують (реплеять) одні й ті самі rollout-и по кілька разів заради економії обчислень — а це і є головне джерело нестабільності GRPO-тренувань, з яким регулярно стикаються AI-білдери.

Що таке replay і чому він шкодить GRPO-навчанню?

Replay у контексті RL-дотренування — це повторне використання вже згенерованих rollout-ів (пар «промпт – відповідь» із обчисленою нагородою) для кількох кроків оновлення політики, а не одноразовий прохід «згенерував → оновив → викинув».

Проблема в тому, що кожен крок оновлення трохи змінює політику, а rollout-и були згенеровані попередньою її версією. Що більше кроків реплею відбувається над тим самим набором даних, то сильніше поточна політика «дрейфує» від тієї, що фактично створила навчальні приклади, — це класична проблема off-policy-навчання, знайома ще з PPO, де її частково стримує механізм clipping.

У GRPO ця проблема гостріша, бо метод спирається на відносне ранжування відповідей усередині групи: якщо політика встигла відхилитися, груповий advantage вже не відображає реальну якість генерацій за поточної політики, і градієнт починає штовхати модель у неправильному напрямку.

Як саме Headroom-Drift Replay контролює цей дрейф?

За даними arXiv, підхід пропонує принциповий, а не суто евристичний спосіб вирішувати, коли rollout ще можна безпечно реплеїти, а коли пора генерувати нові дані.

Судячи з назви примітиву, у його основі — явний бюджет «headroom»: запас дрейфу, який ще можна витратити, перш ніж дані для реплею визнаються застарілими. Ймовірно, на практиці це означає, що система вимірює відстань між політикою, яка згенерувала батч, і поточною політикою після кожного кроку реплею, і зупиняє повторне використання батчу, щойно цей запас вичерпується, — замість того, щоб реплеїти фіксовану кількість епох наперед, як прийнято зараз.

• Менше «зайвих» кроків реплею на застарілих даних — менше ризику нестабільного оновлення чи колапсу політики.
• Явний, вимірюваний критерій замість довільно підібраного гіперпараметра «кількість епох реплею».
• Потенційно ефективніше використання вже згенерованих rollout-ів: реплей триває, поки дозволяє запас дрейфу, а не наперед зафіксовану кількість разів.

Кому і навіщо це може знадобитися вже зараз?

Найбільше від точнішого контролю реплею виграють команди, що самостійно дотреновують reasoning- чи agent-моделі через RL з верифікованими нагородами (RLVR) або RLHF-подібні пайплайни на базі GRPO — зокрема ті, хто використовує відкриті реалізації на кшталт TRL або власні форки.

Для великих лабораторій, що стоять за reasoning-моделями на кшталт DeepSeek-R1, контроль дрейфу — питання стабільності багатотижневих прогонів навчання, де одна невдала фаза реплею може відкинути тренування на кроки назад. Для менших команд, які дотреновують вузькоспеціалізованих агентів (наприклад, для роботи з кодом чи інструментами), практична вигода — менше ручного підбору гіперпараметра «скільки разів реплеїти батч», який зазвичай знаходять методом проб і помилок.

Висновок AiiN: чому цей примітив важливий для практики

За нашою оцінкою, головна цінність Headroom-Drift Replay не в рекорді на якомусь бенчмарку, а в тому, що він перетворює неявний компроміс — скільки разів безпечно реплеїти батч — на явний, вимірюваний параметр. Для команд, які будують production-агентів через RL-дотренування, це означає менше несподіванок під час довгих прогонів і потенційно швидшу ітерацію без ручного підбору кількості epoch. Якщо примітив підтвердить ефективність на практиці, його логічне місце — у стандартних бібліотеках для GRPO-дотренування, поруч із уже звичним PPO-clipping.

Чим GRPO відрізняється від PPO?

GRPO прибирає окрему value-мережу (critic), яку PPO використовує для оцінки очікуваної нагороди, і натомість обчислює advantage відносно середньої нагороди в групі відповідей на той самий промпт. Це спрощує тренувальний пайплайн і економить обчислення, але робить метод чутливішим до якості групового семплування — а отже, і до дрейфу політики під час реплею.

Чи означає це, що GRPO-тренування стане дешевшим?

Прямо в новині про це не йдеться, тож стверджувати економію обчислень як факт передчасно. Ймовірно, точніший контроль реплею дозволить видобувати більше корисних оновлень з уже згенерованих rollout-ів, перш ніж знадобиться новий раунд семплування, — а семплування зазвичай найдорожча частина RL-дотренування великих моделей.