Never Give Up отдаёт вычисления трудным задачам при обучении LLM

При обучении LLM с подкреплением вычисления можно автоматически переносить с уже решённых задач на те, где модель пока не находит правильный ответ. Метод Never Give Up обошёл стандартный GRPO на сложной математике и продолжил решать трудные тесты Manufactoria там, где базовый подход остановился, хотя препринт не рецензирован и числа получили сами авторы. Для команд это превращает число ответов на один запрос из фиксированного параметра в управляемый бюджет.

Фиксированное число ответов поддерживает уже сильные навыки

Michael Noukhovitch, Hamish Ivison, Nathan Lambert и Aaron Courville называют найденную закономерность эффектом Матфея. Обучение с подкреплением (RL) сильнее улучшает результаты на заданиях, которые исходная модель уже решает, а самые трудные задания получают наименьший прирост.

Закономерность нашли у трёх открытых моделей для математики, генерации кода и работы с программными репозиториями. Задания разделили по исходной сложности на AIME, LCBv5 и SWEBenchVerified, после чего сравнили модели до и после обучения. Во всех областях прирост следовал за начальной способностью модели решить задачу.

Одна из причин скрыта в GRPO. Алгоритм генерирует одинаковое число ответов для каждого запроса и сравнивает награды внутри группы. Если все ответы неверны, запрос не даёт полезного сигнала обучения; если все верны, обновлять модель также незачем.

Простое увеличение группы проблему не решило. При неизменном размере пакета вариант с K=4 оказался лучше K=32, включая самые трудные задания. Большая группа чаще находит случайную ошибку даже в почти решённой задаче, поэтому та возвращается в обучение и отнимает вычисления у более сложных примеров.

Маленькая группа быстрее отсеивает лёгкие запросы, но редко находит правильный ответ для трудных. Значит, размер группы нельзя удачно выбрать один раз для всего набора: его нужно менять отдельно для каждого запроса по ходу обучения.

Never Give Up продолжает поиск только там, где он нужен

NGU начинает с небольшой группы ответов. Если все ответы правильные, запрос сразу покидает текущий пакет. Если все неверны, запрос возвращается в очередь, а свободный исполнитель берёт следующую задачу.

Повторный поиск продолжается с вероятностью 0,95. Поэтому трудная задача иногда получает длинную серию попыток, но обучение не зависает на примере, который текущая модель решить не может. Когда появляется правильный ответ, алгоритм объединяет его с предыдущими неудачами: редкое успешное решение получает более сильный сигнал.

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

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

NGU проверяли на моделях Qwen размером от 0,5 до 4 млрд параметров. Сначала механизм изучили на GSM8k, затем перенесли на поднабор из 10 тыс. задач Deepscaler и на Manufactoria, где программу оценивает набор тестов. Основным соперником служил GRPO с фиксированной группой ответов, поэтому результаты описывают математику и код с автоматически проверяемым итогом.

На Deepscaler NGU эффективнее расходовал вычисления и дал основной прирост на самых трудных задачах. В Manufactoria обычный GRPO застрял на частичном прохождении тестов: награда менялась за счёт заданий средней сложности, а самые тяжёлые тесты почти не давали сигнала. NGU продолжал поиск, пока модель не научилась проходить тесты целиком.

Планы меняет планировщик обучения, а не выбор модели

Работа не требует менять архитектуру LLM или заранее составлять программу от простого к сложному. Практическое изменение находится в контуре генерации данных: запросы должны возвращаться в очередь, число попыток должно зависеть от результата, а система — учитывать возраст сохранённых ответов.

Такой подход подходит задачам, где правильность можно проверить автоматически: математическим ответам, программам с тестами и другим средам с однозначной наградой. Без проверяющего механизма NGU не сможет решить, когда остановить поиск и какой из редких ответов использовать для обучения.

Командам не стоит начинать с механического увеличения числа ответов на каждый запрос. Сначала полезнее разделить метрики по исходной сложности и проверить, не растёт ли средний результат только за счёт уже освоенных примеров. Если трудные задачи стоят на месте, асинхронная очередь и адаптивное число попыток могут заменить дорогое увеличение общего пакета.

Постоянно удалять решённые задания из набора тоже не следует: в опытах модель позже теряла часть освоенных навыков. NGU сохраняет исходное распределение данных, но тратит разное количество вычислений на отдельные запросы. Это делает его изменением инфраструктуры обучения, которое можно проверять независимо от выбора базовой модели.

Источники

• Learning to Solve Hard Problems in RL for LLMs by Never Giving Up