ainews
PIRL/PIPO: как научить ИИ проверять, помогло ли ему последнее обновление
Исследователи предложили PIRL — подход к обучению с подкреплением, при котором модель после каждого обновления проверяет, стала ли она реально лучше. Практическая реализация PIPO добавляет двухфазный цикл: сначала обновление по стандартному алгоритму (PPO, GRPO и др.), затем ретроспективная проверка — если шаг помог, его закрепляют, если навредил — корректируют. Эксперименты показали рост точности и стабильности на задачах математики, кода и использования инструментов.
Проблема нестабильности и дрейфа при RL post-training — больное место современных LLM. PIPO предлагает системное решение: проверять, помогло ли обновление, и корректировать курс на лету — это актуально для всех, кто занимается файнтюном и RLHF.
PIRL/PIPO: замкнутая петля обучения с подкреплением
Большинство современных алгоритмов обучения с подкреплением (RL post-training) — PPO, GRPO, DAPO — работают по схеме «обновился и забыл»: взяли батч, вычислили награду, обновили политику, двинулись дальше. Локальная функция потерь может улучшиться, но означает ли это, что модель стала реально лучше? Конечные выборки, шумные сигналы награды и несовершенная локальная атрибуция легко толкают обучение не туда. Авторы называют это open-loop RL — оптимизацией без проверки результата.
PIRL: политика улучшения как цель
Исследователи из проекта PIRL предложили добавить недостающий сигнал: измеряемое улучшение между последовательными версиями политики. Вместо вопроса «выросла ли локальная функция потерь?» задаётся вопрос «действительно ли новая политика лучше предыдущей на практике?». Совокупная цель остаётся выровненной с финальной производительностью, замыкая петлю обратной связи.
PIPO: двухфазная проверка обновлений
Практическая реализация — алгоритм PIPO (Policy Improvement Policy Optimization) — работает в два этапа:
Фаза 1 — исследование: базовый алгоритм (PPO, GRPO и др.) работает как обычно, делая обновление на основе локальной атрибуции. Модель совершает «разведывательный шаг».
Фаза 2 — ретроспективная проверка: в следующей итерации PIPO оценивает производительность обновлённой политики относительно исторического окна. Если улучшение есть — шаг закрепляется и усиливается. Если производительность упала — направление обучения подавляется или корректируется.
Важно: PIPO не заменяет локальную атрибуцию базового алгоритма, а добавляет второй слой обратной связи, проверяющий эмпирический эффект предыдущего обновления.
Результаты
Эксперименты на математическом рассуждении, генерации кода, использовании инструментов и самодистилляции показали стабильный рост точности при добавлении PIPO поверх PPO и групповых методов. Обучение стало стабильнее по random seed'ам, итоговая точность выше при сопоставимом или умеренно увеличенном времени.
PIPO позиционируется как универсальный plug-and-play слой, совместимый с любым базовым RL-алгоритмом.
Ключевые выводы
- Традиционные RL-алгоритмы (PPO, GRPO) оптимизируют локальные цели, не проверяя, улучшилась ли модель реально — это «open-loop обучение»
- PIRL предлагает измерять эмпирическое улучшение политики между итерациями и использовать его как дополнительный сигнал обучения
- PIPO работает в два этапа: сначала стандартное обновление, затем проверка — если шаг помог, его усиливают, если навредил — корректируют
- Подход показал рост точности и стабильности на задачах математики, кода и инструментов, работает как plug-and-play надстройка
- PIPO не заменяет базовый алгоритм, а добавляет слой ретроспективной обратной связи, замыкая петлю обучения
Автор: Артём Ковалёв · Источник: reddit.com
Это одна из тех работ, что бьют в самое болезненное место RLHF — нестабильность обучения. Все мы видели, как модель после десятка итераций PPO вдруг начинает нести чушь, хотя локальная функция потерь росла как надо. PIPO предлагает здравую идею: не верь слепо градиентам, проверяй эмпирически — стала ли модель реально умнее.
Подход элегантный: добавить второй слой обратной связи, который смотрит не на локальную атрибуцию, а на измеримое улучшение производительности. Если шаг помог — закрепи, если навредил — откати или исправь. Звучит просто, но в RL это нетривиально: нужно аккуратно работать с историческим окном, не переобучиться на проверке и не сломать exploration. Код выложен, эксперименты убедительные — стоит попробовать на практике, особенно если файнтюните на сложных задачах вроде math reasoning. Главный вопрос: насколько это масштабируется на большие модели и не съест ли ретроспективная проверка слишком много compute.
Комментарии