AI[ex]Time

Все текущие успехи с RL в reasoning моделях пока были продемонстрированы в сценариях без интерактивного взаимодействия со средой. Возьмем для примера математику: помимо того, что мы в конце можем просто сравнить полученный ответ с правильным, все рассуждения и поиск наилучшего пути решения происходят за раз в контексте модели. Недавно openai писали про свои достижения в разрезе Olympiad in Informatics (IOI), где есть намеки на более сложный RL пайплайн, но деталей нет никаких. Ребята из Apple в работе Reinforcement Learning for Long-Horizon Interactive LLM Agents как раз рассматривают обучение моделей в средах, где для решения задачи с ней нужно много взаимодействовать. Статья интересна тем, что в одном месте собраны +- все текущие методы: SFT, RFT, MCTS для сбора данных + DPO, PPO/RLOO/GRPO, предлагают некоторую свою комбинацию, которая представляет из себя смесь PPO и RLOO для того, чтобы не учить отдельного критика. К сожалению, large scale экспериментами их не назовешь — учили только лору для Qwen 32B + на смешных данных. Хочется конечно увидеть, как все это работает на масштабе и на каких-то более интересных бенчах.

Давно не было рубрики интересных вопросов, которые любят спрашивать на собесах, на этот раз мне рассказали про такой: Как и почему в процессе обучения DPO меняется правдоподобие (растет/падает/не меняется) у y_chosen и y_rejected? Недавно, залипая в метрики обучения, я и сам задался таким вопросом. Ответ в комментариях. #interview_questions

Думаю для многих уже не новость — да, DeepSeek сделали хорошую модель R1. Некоторые хайлайты из статьи: 1. Чтобы завести весь процесс ризонинга использовали только RL, причем в максимально простой постановке с алгоритмом GRPO (модификация PPO). В чем проблема PPO: Для оценки Advantage состояния-действия мы используем отдельную сетку/голову с предсказанием Value. Это привносит нам дополнительные веса, новый лосс, который нужно аккуратно добавить к общему, гиперпараметры, на которые весь алгоритм реагирует довольно чувствительно, система в целом становится сложнее. Вместо этого в GRPO мы делаем много симуляций решений r из состояния и оцениваем Advantage методом Monte Carlo: A_i = (r_i - mean(r)) / std(r). Похожий алгоритм мы видели уже в статье VinePPO. 2. Награда состоит всего из двух частей: Accuracy rewards (правильный ли финальный ответ) и Format rewards (правильно ли отформатировали рассуждения, то есть разместили его между токенами <thinking> и </thinking>) 3. Интересное наблюдение: длина рассуждений растет с процессом обучения. Это не было никак не заложено эвристиками и отдельно никак не стимулируется. В какой-то момент в рассуждениях появляются рефлексия, проверка разных сценариев и тд. На выходе получили R1-Zero, мощную модель, обученную из base версии только с помощью одного RL алгоритма. Для финальной R1 использовали еще пару итераций с SFT + RL, чтобы разрешить некоторые артефакты, например, рассуждения на разных языках. Очень рад за полученные результаты, как минимум потому, что надеюсь, что активное развитие подобных методов постепенно будет двигать нас в сторону сред/задач, где нет легко верифицируемого решения. Напомню, весь прогресс с o1, R1 и другими thinking моделями делается там, где мы можем легко проверить, правильный получился ответ в конце или нет.

Demons in the Detail: On Implementing Load Balancing Loss for Training Specialized Mixture-of-Expert Models. Команда Qwen пишет о своей работе над LBL лоссом в MoE архитектуре. Во время тренировки мы хотим, чтобы токены в какой-то нормальной пропорции распределялись между экспертами, чтобы каждый из них мог выучить что-то полезное. Обычно такой лосс считается по микро-батчу на каждом шаге, а в современных реалиях с огромным контекстом это единицы последовательностей. Получается, что токены одной последовательности распределяются по разным экспертам, даже если все они имеют один и тот же смысл, например, решение задачки на код. В статье предлагают считать лосс по глобальному батчу, то есть давать модели как-то более осмысленно группировать токены для каждого эксперта. Перплексия чуть падает, бенчмарки чуть растут, дополнительная коммуникация для подсчета лосса ничтожная. Дьявол как всегда в деталях, а то мы не знали 😔

Праздники и отпуск прошли, теперь пора и что-нибудь интересное разобрать. Впереди 9 часов в поезде и много отложенных статей — вечер обеспечен 🏃 Начнем с The Lessons of Developing Process Reward Models in Mathematical Reasoning. Исследование от команды Qwen на тему, как делать хорошие PRM (Process Reward Model) в математике, то есть модели, оценивающие промежуточные рассуждения модели. Ребята в последнее время очень часто радуют не только классными моделями, но и качественными статьями. Для того, чтобы тренировать модель оценивать шаги рассуждений, нам нужна разметка, где каждому такому шаг присвоена некоторая метка. Вариантов тут немного: - Использовать LLM-as-a-judge (просим другую модель оценить шаг) или ручную разметку. - Использовать monte-carlo (MC) оценку шага, то есть для оценки шага делаем из него множество продолжений и смотрим, сколько из них завершились успехом. Метку можно определить как a) soft label — доля успешных продолжений или b) hard label — 1, если хотя бы одно продолжение успешно и 0 иначе. Авторы делают большое кол-во экспериментов, из которых формулируют много интересных тезисов, например: - MC методы неявно закладывают смысл value функции в оценку шага, то есть оценивают перспективность состояния для будущего решения задачи. Это может накладывать ограничения в умения модели находить неверные шаги. - MC методы имеют меньший прирост качества от скейлинга данных по сравнению с LLM-as-a-judge и human annotation. - Большая проблема MC методов заключается в том, что модели склонны решать задачи даже со множеством ошибок в рассуждениях. Это приводит к артефактам во время инференса. Это только малая часть, в статье намного больше мыслей, подкрепленных обильными экспериментами, рекомендую почитать всем интересующимся реворд моделями. Далее авторы предлагают алгоритм “консенсуса” между MC методом и LLM-as-a-judge, обученные модели показывают соту на математических бенчмарках и выложены в опенсурс (7B и 72B)

Мы зарелизили первый датасет для software engineering agents!🤖 В последние несколько месяцев наша команда активно работала над software engineering агентами. Я с частью команды отвечал за данные и эксперименты с ними. Сегодня мы выложили данные, которые собрали. Напомню, что на этих данных мы обучили модели (Llama 3.1, Qwen 2.5), которыми набрали 40.6% на SWE-Bench Verified. Про сами данные: Используя доработанную напильником методологию SWE-Bench мы собрали 6.4k пар PR+issue из 2k репозиториев на питоне. Потом сгенерировали 80к траекторий, где агент на базе SWE-agent, используя наши зафайнтюненные модели пытается решить эти issues. В каждой траектории есть инфа про то, решил ли итоговый патч issue, какая была модель, статус окончания работы агента и логи evaluation. Данные выложили на HuggingFace: 6.4 issue-PR pairs: nebius/SWE-bench-extra 80k траекторий: nebius/SWE-agent-trajectories Блогпост с подробным описанием того, как собирали данные можно прочитать тут

Вдогонку к посту выше релизим данные для разработки SWE-агентов: 6.4k GitHub issue-PR пар и ~80k траекторий от SWE-agent

На Kaggle вышло новое соревнование, описание которого начинается с I'm Andy, and I’m giving $1M to the first team that exceeds 90% on a new version of the SWE-bench benchmark. Звучит вызывающе, поэтому давайте посмотрим на это чуть подробнее. Кстати, про сам бенчмарк я немного писал в посте тут. Итак, набор задач, на которых будет производиться финальный скоринг решений будет собираться только после дедлайна, чтобы уж точно не было никакого переобучения. При этом мы не знаем, будут ли брать репозитории, созданные так же после закрытия приема решений, без этого остается шанс, что что-то утечет в трейн. Вообще идея скрыть тест отличная. SWE-bench сразу опубликовал все датасеты, на которых можно запускаться бесконечное число раз, смотреть на ошибки и править скаффолдинг. Это не говоря про то, чтобы вообще подлить тест в трейн. Посмотрим, что из этой затеи получится. Однако, есть ряд вещей, который смущает: 1. На подмножестве легких задач, SWE-bench Lite, топ1 идет с 48.3%, на Verified (другое подмножество, где люди проверили, что с задачами все окей и их можно решить в принципе) — 55%. Все это скорее всего на frontier models по типу Sonnet 3.6. Скорее всего, потому что мы не знаем подробности про Amazon Agent Q и другие closed source решения. 2. Решения на текущем лидерборде SWE-bench не были никак ограничены в test-time compute и железе. Считай сколько хочешь на H100 (или ходи в апи), а потом сабмить. Здесь же у нас 24 часа на 4XL4 (всего 96GB), притом что конексты нужны огромные, вплоть до 65-128к. Видимо, нужно использовать скаффолдинги, менее требовательные к длине контекста, например, Agentless. Все это звучит так, что цифра в 90% звучит как что-то недостижимое за 3 месяца, так еще и на os моделях. С другой стороны, сложность задач в них мы не знаем, да и приз за это отдельный в миллион. Так что поучаствовать в любом случае смысл есть. Ну и подумываю над тем, чтобы самому попробовать что-то поделать 🙂

Test-time scaling звучит изо всех утюгов, все пытаются реплицировать o1, много спекуляций насчет методов, как это сделать. Один из углов, под которым можно на это посмотреть, — Verifiers, то есть модели, оценивающие то, что генерирует наша модель. Имея такой Verifier можно запускать алгоритмы поиска наилучшей траектории во время инференса или вообще дистиллировать этот поиск в саму модель, чтобы получился длительный CoT. Собрал небольшую подборку статей вокруг offline RL, которые могут быть полезны в этом направлении. GLoRe: When, Where, and How to Improve LLM Reasoning via Global and Local Refinements Здесь тренируют оценивать оптимальную Value функцию, а дальше используют эту модель для того, чтобы учить модель исправлять свои же ошибки. Понятное введение про то, как можно дистиллировать работу критика в основную модель. Все эксперименты правда сделаны на GSM8K. Stop Regressing: Training Value Functions via Classification for Scalable Deep RL Это просто прикольная статья про сведение задачи предсказания Value функции к классификации. Рассматривают изящные методы (2hot encoding, HL-gauss, distributional RL), которые позволяют предсказывать в итоге не скаляр, а целое дискретное распределение, что увеличивает гибкость во время инференса. Например, мы можем брать различные квантили, то есть оптимистичные/пессимистичные предсказания. Rewarding Progress: Scaling Automated Process Verifiers for LLM Reasoning Авторы исследуют вопрос, а какую модель лучше использовать для генерации данных, на которых обучаются критики. Должен ли это быть самый мощный prover? Спойлер: нет. Как раз пытаются ответить на этот и ряд других вопросов, например, как считать награду действий во время поиска? IQL (Implicit Q-Learning)иCQL (Conservative Q-Learning) Классические подходы из offline RL, в которых можно черпать идеи для применения в мире LLM. В IQL оценивают верхний экспектиль значения Value функции, а в CQL напрямую штрафует OOD действия через дополнительную регуляризацию на основе KL-дивергенции. Это довольно мощные алгоритмы в offline RL, так что рекомендую ознакомиться. Offline RL for Natural Language Generation with Implicit Language Q Learning Необычный и довольно интересный подход предсказания Q/V-функций на уровне каждого токена. Авторы предлагают корректировать итоговые вероятности токенов с помощью разницы Q – V (то есть Advantage), чтобы двигать генерацию в сторону оптимизации некоторой награды. Let’s Verify Step by StepиTraining Verifiers to Solve Math Word Problems Классика от OpenAI. Исследуют Process Reward Model для того, чтобы детектить промежуточные ошибки во время генерации. Здесь же и богатый ablation study, например, рассуждают про факт, что с ростом числа кандидатов итоговое качество может начать падать с какого-то момента. Если не читали, с этого рекомендую начать. Если знаете крутые статьи на тему, кидайте (желательно с комментариями), будем обогащать список! Думаю через недельку докину еще парочку.

Leveraging training and search for better software engineering agents Подоспел пост от нашей команды про SWE агентов, где мы рассматриваем один из способов использовать test-time compute для улучшения перформанса. Давайте немного расскажу про изначальную идею. Когда мы говорим про агентов, то подразумеваем 3 вещи: модель, которая видит задачу, генерирует план, действия и так далее; среду, в которой этот агент взаимодействует и прослойку между ними — scaffolding, то есть это та обвязка поверх модели, которая и превращает обычную LLM в агента. Грубо говоря, это набор промптов, инструментов, парсеров, дополнительных программ, выполняющие API вызовы и прочее. В последнее время очень много компаний фокусируется на том, чтобы улучшить именно последнюю часть, например, затюнить промпты или ввести суб-агентов, которые концентрируются на выполнении более узких задач. Здесь появляется идея 1: концентрироваться на улучшении скаффолдинга в long-term не имеет смысла. Все обвязки исходят из текущих ограничений моделей, которые могут стать неактуальными в будущем. Более того, нет оснований идти против The Bitter Lesson. Идея 2: соревноваться с frontier models в качестве основных генераторов опасно. Мы можем вложить массу компьюта и экспериментов в обучение и получить хорошую модель за счет специфических данных, но опять же в long-term проиграть Claude-4/GPT-5/Gemini-2, которые будут работать лучше просто из коробки. Отсюда возникла мысль: нужно идти в сторону того, что можно масштабировать при увеличении компьюта и при этом не ввязываться в гонку с фронтир моделями. Так появилась идея разменивать test-time compute на качество через критиков (часто в литературе их называют Verifiers), оценивающих Q/V функции. Подробнее про это уже можно почитать в посте. Взяв только открытые модели (Llama3.1-70B и Qwen2.5-72B) и применив описанные идеи, получилось выбить 40.6% на SWE-bench Verified, что кажется лучшим результатом, основанным на опенсорс моделях. Теперь у нас есть огромное кол-во мыслей, как далее развивать подобные методы, область применения которых достаточно богатая и подходит практически для любых агентов.

В продолжение предыдущего поста поговорим о второй новизне, а именно использовании SORM для дообучения модели исправлять свои ошибки. Делать это авторы учат в двух вариантах: Global и Local Refinement. Global Refinement — умение модели сгенерировать ответ заново, когда мы получили неправильный результат. Авторы собрали множество триплетов (вопрос, плохая генерация, хорошая генерация) и учили предсказывать правильный ответ по префиксу вида “{вопрос} [BAD] {плохая генерация}”, то есть модель может посмотреть на предыдущие свои рассуждения и уже не делать каких-то ошибок. Local Refinement — умение исправлять ситуацию на ходу, когда конкретное действие получило низкую оценку от SORM. Тут методика сбора данных чуть посложнее, ведь нам нужна траектория вплоть до плохого действия, а также хорошее решение из состояния до этого действия. Что нужно для этого сделать? Допустим, у нас есть траектория из нескольких шагов (S1, S2, S3, S4) с пометкой, что S3 — плохое действие. В таком случае мы делаем множество запусков из S2 до тех пор пока не получим правильное решение, берем какое-то из них, например, (S1, S2, S3*, S4*, S5*) и формируем датасет таким образом: “{вопрос} S1 S2 [BAD] S3 S3* S4* S5*”. В такой постановке мы учимся предсказывать только исправленное решение, то есть S3*, S4*, S5*. Дополнительный вывод такой: оба способа дополняют друг друга и для лучшего качества их нужно использовать вместе. На инференсе мы можем подобрать пороги для SORM/ORM, чтобы определять ситуации, когда нужно проставить метку [BAD], тем самым провоцируя модель на повторную попытку решения.