RE-TRAC: REcursive TRAjectory Compression for Deep Search Agents
Сейчас очень много агентов работает в ReAct парадигме (последовательные reasoning + acting). Авторы считают, что такой подход с длинными линейными цепочками плохо подходит для сложных задач, потому что deep search больше похож на дерево гипотез: модель может наметить несколько веток, но потом забыть часть из них, застрять в локальном направлении или зациклиться.
Re-Trac отличается от ReAct: после каждой траектории собирают compressed_state, в котором хранят лучший ответ на текущий момент, список проверенных фактов, логические выводы и список того, что осталось неизвестным. На следующих траекториях авторы стартуют с этого состояния. Благодаря этому авторы получили 53 пункта на BrowseComp с 8 rollout’ами.
Прочитав статью, я нашёл подвох: init для sft — это Tongyi-DeepResearch 3A30B, у которого и так 43 пункта на BrowseComp, а замера pass@8 — бейзлайна за схожий compute — для него нет. То есть идея интересная, но реальный эффект Re-Trac для лучшей модели из статьи не указан.
Training-Trajectory-Aware Token Selection
Исследователи изучают дистилляцию ризонящих моделей. Обычно SFT или дистилляция на reasoning-траекториях не улучшает модель, а иногда даже ухудшает её. Во время обучения loss монотонно падает, а реальные метрики сначала резко проседают (Imitation Shock), но затем постепенно восстанавливаются, при этом не всегда до конца. Авторы заметили расслоение токенов во время обучения на две группы, «полезные» и «вредные», причем одни подавляются другими. Поэтому стандартная дистилляция тратит ранние градиенты на токены, которые мешают обучению более полезных токенов.
Как решили проблему: замаскировали «вредные» токены и не добавляют их в loss. Чтобы понять, какие токены маскировать, придумали алгоритм T3S — Training-Trajectory-Aware Token Selection. Сначала модель проходит короткую фазу дистилляции, по ней находят Imitation Shock и затем сравнивают влияние токенов между началом и на чекпоинте, где всё взорвалось.
Least-Loaded Expert Parallelism: Load Balancing An Imbalanced Mixture-of-Experts
В MoE-модели каждый токен не проходит через весь FFN-блок, вместо этого роутер выбирает для него несколько экспертов. В Expert Parallelism эксперты распределены по GPU: условно, GPU-0 хранит экспертов 0–3, GPU-1 хранит 4–7 и так далее. Проблема возникает, когда роутер выбирает экспертов неравномерно. Например, на math/code данных один эксперт может стать очень популярным, потому что он специализировался на таких токенах. Тогда GPU, на которой лежит этот эксперт, получает слишком много токенов, считает дольше всех и определяет latency всего MoE-слоя.
LLEP решает это не изменением роутера, а изменением исполнения. Перед MoE-слоем система смотрит, сколько токенов попало в каждого эксперта и насколько загружена каждая GPU. Если дисбаланс маленький, используется обычный Expert Parallelism. Если дисбаланс большой, LLEP выбирает наименее загруженные GPU и отправляет туда не только токены, как в EP, но и веса перегруженного эксперта.
Smaller Models are Natural Explorers for Policy-Level Diversity in GRPO
Авторы говорят, что GRPO живёт за счёт разнообразных rollout’ов, но по ходу обучения они становятся однородными, advantage-сигнал слабеет, а прогресс встаёт. Вывели инсайт: GRPO нужно policy-level diversity — когда целые траектории структурно разные, но при этом логически связаны.
Обнаружили, что меньшие модели из этого же семейства дают гораздо больше policy-level разнообразия и предложили на ранней стадии обучения часть rollout’ов для большой модели генерировать маленькой замороженной моделью — так можно получить структурно разнообразные траектории на старте. Затем долю маленькой модели постепенно снижали, плавно возвращаясь к стабильному on-policy режиму большой модели. Результаты: на AIME24/25 получили выигрыш 23.8/22.5 против GRPO-базы 15.0/12.1.
Увидели и записали полезное для вас
#YaICML2026
Душный NLP
