Forwarded from commit history
Мы зарелизили первый датасет для 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
Блогпост с подробным описанием того, как собирали данные можно прочитать тут
В последние несколько месяцев наша команда активно работала над 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
Блогпост с подробным описанием того, как собирали данные можно прочитать тут
huggingface.co
nebius/SWE-bench-extra · Datasets at Hugging Face
We’re on a journey to advance and democratize artificial intelligence through open source and open science.
Праздники и отпуск прошли, теперь пора и что-нибудь интересное разобрать. Впереди 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)
Начнем с 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)
Please open Telegram to view this post
VIEW IN TELEGRAM
Demons in the Detail: On Implementing Load Balancing Loss for Training Specialized Mixture-of-Expert Models. Команда Qwen пишет о своей работе над LBL лоссом в MoE архитектуре. Во время тренировки мы хотим, чтобы токены в какой-то нормальной пропорции распределялись между экспертами, чтобы каждый из них мог выучить что-то полезное. Обычно такой лосс считается по микро-батчу на каждом шаге, а в современных реалиях с огромным контекстом это единицы последовательностей. Получается, что токены одной последовательности распределяются по разным экспертам, даже если все они имеют один и тот же смысл, например, решение задачки на код.
В статье предлагают считать лосс по глобальному батчу, то есть давать модели как-то более осмысленно группировать токены для каждого эксперта. Перплексия чуть падает, бенчмарки чуть растут, дополнительная коммуникация для подсчета лосса ничтожная.
Дьявол как всегда в деталях, а то мы не знали😔
В статье предлагают считать лосс по глобальному батчу, то есть давать модели как-то более осмысленно группировать токены для каждого эксперта. Перплексия чуть падает, бенчмарки чуть растут, дополнительная коммуникация для подсчета лосса ничтожная.
Дьявол как всегда в деталях, а то мы не знали
Please open Telegram to view this post
VIEW IN TELEGRAM
Думаю для многих уже не новость — да, 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 моделями делается там, где мы можем легко проверить, правильный получился ответ в конце или нет.
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 моделями делается там, где мы можем легко проверить, правильный получился ответ в конце или нет.
Давно не было рубрики интересных вопросов, которые любят спрашивать на собесах, на этот раз мне рассказали про такой:
Как и почему в процессе обучения DPO меняется правдоподобие (растет/падает/не меняется) у y_chosen и y_rejected?
Недавно, залипая в метрики обучения, я и сам задался таким вопросом. Ответ в комментариях.
#interview_questions
Как и почему в процессе обучения DPO меняется правдоподобие (растет/падает/не меняется) у y_chosen и y_rejected?
Недавно, залипая в метрики обучения, я и сам задался таким вопросом. Ответ в комментариях.
#interview_questions
Все текущие успехи с 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 + на смешных данных. Хочется конечно увидеть, как все это работает на масштабе и на каких-то более интересных бенчах.
Ребята из Apple в работе Reinforcement Learning for Long-Horizon Interactive LLM Agents как раз рассматривают обучение моделей в средах, где для решения задачи с ней нужно много взаимодействовать. Статья интересна тем, что в одном месте собраны +- все текущие методы: SFT, RFT, MCTS для сбора данных + DPO, PPO/RLOO/GRPO, предлагают некоторую свою комбинацию, которая представляет из себя смесь PPO и RLOO для того, чтобы не учить отдельного критика.
К сожалению, large scale экспериментами их не назовешь — учили только лору для Qwen 32B + на смешных данных. Хочется конечно увидеть, как все это работает на масштабе и на каких-то более интересных бенчах.
Соседняя команда проделала большую работу и сегодня выпустила нашу версию FlashAttention для JAX, которая поддерживает Context Parallelism (CP) и Document Masks. При работе с агентами часто встречаются траектории огромной длины вплоть до 128к+ токенов, поэтому CP становится необходимым. При этом, если дополнять каждую последовательность до max_seq_len, ресурсы будут использоваться неэффективно из-за бесполезных pad токенов, т.к. траектории все-таки могут быть и короткими. Отсюда хочется уметь паковать несколько траекторий в один ряд в батче и разделять их масками, чтобы при вычислении attention скоров они не влияли друг на друга. Все это реализовано в нашей либе, за что ребятам большое спасибо ☺️
В посте есть подробное описание, как это работает, а также сравнения с cudnn FA и FlexAttention в различных сценариях, думаю, всем причастным должно быть интересно
https://x.com/hr0nix/status/1895096056570093966
В посте есть подробное описание, как это работает, а также сравнения с cudnn FA и FlexAttention в различных сценариях, думаю, всем причастным должно быть интересно
https://x.com/hr0nix/status/1895096056570093966
Please open Telegram to view this post
VIEW IN TELEGRAM
Есть одна популярная заметка от John Schulman, написанная еще в 2020 и посвященная Monte Carlo оценке KL дивергенции. Только недавно наткнулся на нее, и показалось, что там очень хорошо описана проблематика и сами методы оценок.
KL-дивергенция используется в качестве меры удаленности двух распределений друг от друга и часто используется как регуляризация в обучении. Например, мы хотим максимизировать награду, которую наша модель получает в среде, но для борьбы с reward hacking-ом и для повышения стабильности обучения добавляем в лосс еще одно слагаемое, которое будет штрафовать нас за то, что мы отходим от изначальных весов модели слишком далеко. Лосс в таком случае выглядит как Loss = RewardObjective + KLTerm.
Возникает вопрос, а как посчитать KL-дивергенцию? Если следовать определению, то нужно посчитать сумму по всем возможным x: sum_x p(x) * log(p(x) / q(x), то есть сумму по всем токенам из словаря. На практике это может быть не всегда возможно (из-за ограничений по памяти/времени, или, например, если мы заранее посчитали p(x) для получившихся последовательностей).
Можно заметить, что написанная сумма — это на самом деле матожидание E_{x~p(x)} log(p(x) / q(x)), которое легко оценить через Монте Карло по последовательностям в нашем батче. Проблема в том, что такая оценка будет иметь огромную дисперсию.
Отсюда вытекает следующий вопрос: можно ли как-то сохранить несмещенность, но снизить дисперсию? Общий метод для таких процедур — попытаться найти и вычесть контрольную переменную (control variate), то есть случайную величину с матожиданием 0, но большой ковариацией, чтобы вычитание забрало часть дисперсии. На этом основывается огромное число алгоритмов: от CUPED в AB тестировании до использования Advantage в Reinforcement Learning. В статье как раз идут рассуждения на эту тему, показывается, откуда взять улучшенную оценку и еще много интересных замечаний.
Если при чтении статьи от deepseek про R1, у вас возникал вопрос, откуда такое выражение для KL, то это как раз она — несмещенная оценка со сниженной дисперсией. В общем, чтиво коротенькое и очень интересное, рекомендую.
KL-дивергенция используется в качестве меры удаленности двух распределений друг от друга и часто используется как регуляризация в обучении. Например, мы хотим максимизировать награду, которую наша модель получает в среде, но для борьбы с reward hacking-ом и для повышения стабильности обучения добавляем в лосс еще одно слагаемое, которое будет штрафовать нас за то, что мы отходим от изначальных весов модели слишком далеко. Лосс в таком случае выглядит как Loss = RewardObjective + KLTerm.
Возникает вопрос, а как посчитать KL-дивергенцию? Если следовать определению, то нужно посчитать сумму по всем возможным x: sum_x p(x) * log(p(x) / q(x), то есть сумму по всем токенам из словаря. На практике это может быть не всегда возможно (из-за ограничений по памяти/времени, или, например, если мы заранее посчитали p(x) для получившихся последовательностей).
Можно заметить, что написанная сумма — это на самом деле матожидание E_{x~p(x)} log(p(x) / q(x)), которое легко оценить через Монте Карло по последовательностям в нашем батче. Проблема в том, что такая оценка будет иметь огромную дисперсию.
Отсюда вытекает следующий вопрос: можно ли как-то сохранить несмещенность, но снизить дисперсию? Общий метод для таких процедур — попытаться найти и вычесть контрольную переменную (control variate), то есть случайную величину с матожиданием 0, но большой ковариацией, чтобы вычитание забрало часть дисперсии. На этом основывается огромное число алгоритмов: от CUPED в AB тестировании до использования Advantage в Reinforcement Learning. В статье как раз идут рассуждения на эту тему, показывается, откуда взять улучшенную оценку и еще много интересных замечаний.
Если при чтении статьи от deepseek про R1, у вас возникал вопрос, откуда такое выражение для KL, то это как раз она — несмещенная оценка со сниженной дисперсией. В общем, чтиво коротенькое и очень интересное, рекомендую.
Давно как-то не доходили руки ничего написать в канал: то по работе дела, то статей интересных не было в моменте, то просто не хотелось. Тем не менее за месяц вышел ряд работ, которые мне показались интересными, с некоторых из них и начнем.
ByteDance (TikTok) представила две статьи по RL тюнингу моделей, а именно вариации GRPO: DAPO и VAPO. Интересны они тем, что авторы детально рассматривают детали реализации GRPO и смотрят на моменты, которые можно улучшить, например:
- Известно, что если делать большое кол-во шагов подитераций в PPO мы быстро начнем выходить за 1+eps (eps = 0.2 по дефолту), из-за чего градиент на данных семплах будет зануляться ⇒ обучение становится менее эффективным. Авторы поизучали этот вопрос и советуют клипать значения с двух сторон с разными epsilon. На эту тему есть еще одна интересная работа, где авторы смотрели на сценарий очень большого кол-во подтиреций внутри PPO-like лосса: TOPR.
- Рассматривается вопрос о том, в каком порядке лучше усреднять лосс внутри батча, тк это может повлиять на вклад траекторий разной длины. Это очень важный вопрос в агентских системах, когда есть траектории, содержащие в себе длинные шаги, ошибки, дебаг, а есть те, которые решают задачу буквально за несколько шагов.
- В VAPO главным моментом изучения стала модель-критик для оценки Advantage с помощью GAE. В GRPO и прочих методах одним из приятных преимуществ перед PPO было то, что не приходится учить отдельную модель, а Advantage мы оценивали как r_i - mean(r) по группе, где r_{1..n} - решения одной конкретной задачки. VAPO делает шаг назад и смотрит на то, как все-таки использовать критика для более эффективного обучения. Немного про это писал в посте про сам GRPO.
Все это замеряется на Qwen2.5-32B на задаче AIME 2024 и сравнивается с DeepSeek-R1-Zero-Qwen-32B.
В общем, это чисто технические статьи, которые будут интересны довольно узкому кругу. Совсем недавно ByteDance выпустил собственную 200B модель Seed-Thinking-v1.5, где в частности применили эти алгоритмы на последней стадии.
ByteDance (TikTok) представила две статьи по RL тюнингу моделей, а именно вариации GRPO: DAPO и VAPO. Интересны они тем, что авторы детально рассматривают детали реализации GRPO и смотрят на моменты, которые можно улучшить, например:
- Известно, что если делать большое кол-во шагов подитераций в PPO мы быстро начнем выходить за 1+eps (eps = 0.2 по дефолту), из-за чего градиент на данных семплах будет зануляться ⇒ обучение становится менее эффективным. Авторы поизучали этот вопрос и советуют клипать значения с двух сторон с разными epsilon. На эту тему есть еще одна интересная работа, где авторы смотрели на сценарий очень большого кол-во подтиреций внутри PPO-like лосса: TOPR.
- Рассматривается вопрос о том, в каком порядке лучше усреднять лосс внутри батча, тк это может повлиять на вклад траекторий разной длины. Это очень важный вопрос в агентских системах, когда есть траектории, содержащие в себе длинные шаги, ошибки, дебаг, а есть те, которые решают задачу буквально за несколько шагов.
- В VAPO главным моментом изучения стала модель-критик для оценки Advantage с помощью GAE. В GRPO и прочих методах одним из приятных преимуществ перед PPO было то, что не приходится учить отдельную модель, а Advantage мы оценивали как r_i - mean(r) по группе, где r_{1..n} - решения одной конкретной задачки. VAPO делает шаг назад и смотрит на то, как все-таки использовать критика для более эффективного обучения. Немного про это писал в посте про сам GRPO.
Все это замеряется на Qwen2.5-32B на задаче AIME 2024 и сравнивается с DeepSeek-R1-Zero-Qwen-32B.
В общем, это чисто технические статьи, которые будут интересны довольно узкому кругу. Совсем недавно ByteDance выпустил собственную 200B модель Seed-Thinking-v1.5, где в частности применили эти алгоритмы на последней стадии.
Недавно из блога Lilian Weng (всем рекомендую, кто не знал) про RL перешел на сайт Jeremy Kun-а и обнаружил, что там есть довольно много интересных заметок. Например, одна из них посвящена вопросу, про который я хотел написать в рамках #interview_questions.
Вопрос: у вас есть честная монетка (вероятность решки 1/2). Как только с ее помощью смоделировать подбрасывание нечестной монетки с любой заданной вероятностью решки p. Нужно написать функцию, принимающую на вход p и возвращающую 0/1 c этой вероятностью.
Загадка, зачем спрашивать такое на собеседованиях, но решение мне кажется довольно красивым.
Вопрос: у вас есть честная монетка (вероятность решки 1/2). Как только с ее помощью смоделировать подбрасывание нечестной монетки с любой заданной вероятностью решки p. Нужно написать функцию, принимающую на вход p и возвращающую 0/1 c этой вероятностью.
Загадка, зачем спрашивать такое на собеседованиях, но решение мне кажется довольно красивым.
Neel Nanda, лид команды Mechanistic Interpretability в DeepMind (от него же есть крутое видео про открытые проблемы в области, советую) написал лонгрид, как писать ML статьи. Выглядит, как качественный ресурс, где собраны все: от общей интуиции и формулирования гипотез до конкретных ошибок в подаче материала. Через призму этого фреймворка смотрит на свою же работу Progress measures for grokking via mechanistic interpretability. До конца подачи на NeurIPS еще 3 дня, забираем и пользуемся?
SWE-rebench: A Continuously Evolving and Decontaminated Benchmark for Software Engineering LLMs
Сегодня стандартом для оценки SWE агентов является SWE-bench Verified. Его задумка очень понятная и как-то приближена к разработке чего-то большего, чем генерация кода: мы запускаем агента на настоящих задачках из GitHub, проверяем в конце прохождение отложенных тестов и смотрим на их результат. Но с SWE-bench Verified есть несколько проблем:
- Изначальный датасет был публично выложен в конце 2023 года. Последние модели может и неявно, но с очень высокой вероятностью захватили все эти данные в обучении, отчего рост чисел на бенче на какую-то часть связан с контаминацией. Да и без этого многие используют Verified как валидацию для экспериментов с агентом, неявно переобучаясь под него. По этой же причине в свое время появился LiveCodeBench для решения обычных задач для кодинга.
- Самые первые релизы на лидерборде хорошо описывали структуру агента и параметры запуска так, что было понятно, что вот это решение докинуло за счет перевода с gpt4o на sonnet-3.5, а вот это — просто промпты потюнили или тулы сделали лучше. Сейчас же лидерборд превратился в солянку, по которой просто непонятно, что происходит: best-of-N запуски, верификация доп тестами, MCTS, миллион разных скаффолдингов, уже даже непонятно, какая модель используется внутри, тк многие сабмиты на лидерборде — это закрытые решения компаний.
Мы попробовали закрыть часть этих пробелов и сегодня релизим SWE-rebench! Для борьбы с потенциальной контаминацией, мы будем регулярно обновлять лидерборд с замерами на свежих задачах. Скаффолдинг агента при этом везде фиксирован, чтобы запуски с разными моделями были сравнимы между собой. Так как наш пайплайн сбора данных позволяет автоматически контролировать сложность задач, то в будущем мы будем использовать это для борьбы с насыщением бенчмарка.
Детали можно прочитать на сайте самого бенча, ну и конечно приглашаю заглянуть на текущий лидерборд. Если вы привыкли читать обзоры в Х, там тоже есть подходящий контент.
Сегодня стандартом для оценки SWE агентов является SWE-bench Verified. Его задумка очень понятная и как-то приближена к разработке чего-то большего, чем генерация кода: мы запускаем агента на настоящих задачках из GitHub, проверяем в конце прохождение отложенных тестов и смотрим на их результат. Но с SWE-bench Verified есть несколько проблем:
- Изначальный датасет был публично выложен в конце 2023 года. Последние модели может и неявно, но с очень высокой вероятностью захватили все эти данные в обучении, отчего рост чисел на бенче на какую-то часть связан с контаминацией. Да и без этого многие используют Verified как валидацию для экспериментов с агентом, неявно переобучаясь под него. По этой же причине в свое время появился LiveCodeBench для решения обычных задач для кодинга.
- Самые первые релизы на лидерборде хорошо описывали структуру агента и параметры запуска так, что было понятно, что вот это решение докинуло за счет перевода с gpt4o на sonnet-3.5, а вот это — просто промпты потюнили или тулы сделали лучше. Сейчас же лидерборд превратился в солянку, по которой просто непонятно, что происходит: best-of-N запуски, верификация доп тестами, MCTS, миллион разных скаффолдингов, уже даже непонятно, какая модель используется внутри, тк многие сабмиты на лидерборде — это закрытые решения компаний.
Мы попробовали закрыть часть этих пробелов и сегодня релизим SWE-rebench! Для борьбы с потенциальной контаминацией, мы будем регулярно обновлять лидерборд с замерами на свежих задачах. Скаффолдинг агента при этом везде фиксирован, чтобы запуски с разными моделями были сравнимы между собой. Так как наш пайплайн сбора данных позволяет автоматически контролировать сложность задач, то в будущем мы будем использовать это для борьбы с насыщением бенчмарка.
Детали можно прочитать на сайте самого бенча, ну и конечно приглашаю заглянуть на текущий лидерборд. Если вы привыкли читать обзоры в Х, там тоже есть подходящий контент.
Forwarded from commit history
Привет! Накопилась пара новостей, которыми буду тут плавно делиться! 👋
Первая, мы зарелизили SWE-rebench – увеличенную и улучшенную версию нашего прошлого датасета с задачами по решению issue из гихаба.
Одно из узких мест в подобных датасетах, это что в них не так много задач, которые вдобавок собраны из ограниченного набора репозиториев. Например, в оригинальном SWE-bench: 2,000+ задач из 18 репозиториев. В основном, это происходит из-за того, что каждый проект исследователи устанавливали вручную и потом собирали задачи. Мы автоматизировали и заскейлили этот процесс, поэтому собрали 21,000+ задач из 3400+ репозиториев.
Подробный тех репорт можно прочитать на arxiv. Сабсет этого датасета, мы использовали, чтобы сделать наш лидерборд SWE-rebench, про который писал Саша.
P.S. Еще мы сегодня засабмитили статью на daily paper в HuggingFace, если вдруг у вас там есть аккаунт, буду благодарен за upvote! 🤗
Первая, мы зарелизили SWE-rebench – увеличенную и улучшенную версию нашего прошлого датасета с задачами по решению issue из гихаба.
Одно из узких мест в подобных датасетах, это что в них не так много задач, которые вдобавок собраны из ограниченного набора репозиториев. Например, в оригинальном SWE-bench: 2,000+ задач из 18 репозиториев. В основном, это происходит из-за того, что каждый проект исследователи устанавливали вручную и потом собирали задачи. Мы автоматизировали и заскейлили этот процесс, поэтому собрали 21,000+ задач из 3400+ репозиториев.
Подробный тех репорт можно прочитать на arxiv. Сабсет этого датасета, мы использовали, чтобы сделать наш лидерборд SWE-rebench, про который писал Саша.
P.S. Еще мы сегодня засабмитили статью на daily paper в HuggingFace, если вдруг у вас там есть аккаунт, буду благодарен за upvote! 🤗
arXiv.org
SWE-rebench: An Automated Pipeline for Task Collection and...
LLM-based agents have shown promising capabilities in a growing range of software engineering (SWE) tasks. However, advancing this field faces two critical challenges. First, high-quality training...
Объемный и очень интересный тех репорт про модель под названием Skywork Open Reasoner 1. Может показаться, что это очередной RL тюн на математические задачи, который обгоняет модели по типу R1-distil, но на самом деле это первый (по крайней мере я не встречал раньше подобных работ) ablation на огромное число факторов, влияющих на процесс обучения с GRPO-like методами. Фильтрация данных, on/off policy trade off, температура при генерации решений, несимметричное клиппирование, token-wise усреднение в лоссе, KL регуляризация и много чего еще — раньше все это встречалось по отдельности в разных работах, а здесь собрано воедино, так еще и со сравнением в одинаковых сетапах.
Но. Помимо этого, авторы заметили следующее: когда модель входит в состоянии низкой энтропии, разнообразие генераций и эффективность обучения снижается. Если такое коллапсирование происходит рано, то прогресс быстро упирается в потолок. Чтобы контролировать этот процесс, предлагается ввести дополнительное слагаемое в лосс, которое будет штрафовать за слишком низкие значения, причем делать это нужно с адаптивным весом, тк энтропия зависит от данных и шага обучения (по этой же причине часто очень тяжело подобрать единый вес для KL-регуляризации). Вообще это супер стандартный подход в классическом RL для поддержания exploration на определенном уровне, но в RL для LLM такое особо не использовали. Ablation на многие факторы проводится как раз с оглядкой на то, как они влияют на динамику энтропии. В общем, репорт на 40 страниц, там очень много познавательных замечаний, советую хотя бы бегло пробежаться.
Но. Помимо этого, авторы заметили следующее: когда модель входит в состоянии низкой энтропии, разнообразие генераций и эффективность обучения снижается. Если такое коллапсирование происходит рано, то прогресс быстро упирается в потолок. Чтобы контролировать этот процесс, предлагается ввести дополнительное слагаемое в лосс, которое будет штрафовать за слишком низкие значения, причем делать это нужно с адаптивным весом, тк энтропия зависит от данных и шага обучения (по этой же причине часто очень тяжело подобрать единый вес для KL-регуляризации). Вообще это супер стандартный подход в классическом RL для поддержания exploration на определенном уровне, но в RL для LLM такое особо не использовали. Ablation на многие факторы проводится как раз с оглядкой на то, как они влияют на динамику энтропии. В общем, репорт на 40 страниц, там очень много познавательных замечаний, советую хотя бы бегло пробежаться.
Forwarded from Боря программирует
Training superhuman coding models at Cursor
Случайно наткнулся на видео, где ребята из Cursor обсуждают всякое разное про LLM. Обычно в подобных подкастах все высказывания очень поверхносные, чтобы случайно не выдать каких-нибудь секретов. А тут на удивление упомянули довольно много технических деталей.
Краткий список затронутых тем:
- Как делать RL, когда нет одного правильного ответа?
- Что делать, если вероятность получить "правильный" ответ очень маленькая?
- Как сделать, чтобы модель могла ориентироваться в большом проекте?
- Как поддерживать long context?
- Как делать credit assignment для memory tool?
- Как cursor может обучаться на пользовательских данных.
- Почему плохо смотреть на лайки/дизлайки ответов.
- Какая инфра нужна для больших RL тренировок.
Судя по количеству просмотров, если сам этим не занимаешься, то смотреть не очень интересно. Но мне понравилось!
Случайно наткнулся на видео, где ребята из Cursor обсуждают всякое разное про LLM. Обычно в подобных подкастах все высказывания очень поверхносные, чтобы случайно не выдать каких-нибудь секретов. А тут на удивление упомянули довольно много технических деталей.
Краткий список затронутых тем:
- Как делать RL, когда нет одного правильного ответа?
- Что делать, если вероятность получить "правильный" ответ очень маленькая?
- Как сделать, чтобы модель могла ориентироваться в большом проекте?
- Как поддерживать long context?
- Как делать credit assignment для memory tool?
- Как cursor может обучаться на пользовательских данных.
- Почему плохо смотреть на лайки/дизлайки ответов.
- Какая инфра нужна для больших RL тренировок.
Судя по количеству просмотров, если сам этим не занимаешься, то смотреть не очень интересно. Но мне понравилось!
Интересно, что буквально за последнюю неделю вышел целый ряд работ (https://arxiv.org/abs/2505.24864, https://arxiv.org/abs/2506.01939, https://arxiv.org/abs/2505.22617), посвященный поведению энтропии в процессе RL обучения моделей. Все они утверждают +- одно и то же: нужно очень внимательно отслеживать значения энтропии и не допускать ее коллапсирования на начальных стадиях тренировки. Для этого есть множество трюков, от KL/Entropy бонуса до тонкостей клиппирования в GRPO-like лоссе. В сегодняшней статье про Magistral авторы, например, пишут: We adopt the Clip-Higher strategy to address entropy collapse.
Все статьи выше любопытные, но в Beyond the 80/20 Rule авторы из Qwen посмотрели не просто на среднюю энтропию модели, но еще и на ее значения в разрезе отдельных токенов и пришли к выводу, что только в малой части всего контекста сосредоточены высокие значения. В этих токенах происходят самые главные “развилки” в рассуждениях модели, то есть именно здесь идет семплирование токена, который определит суть следующих предложений или абзаца. Довольно интересное наблюдение, которое заставляет задуматься над потенциальными альтернативными методами поддержания exploration в RL или обучения в целом. Например, авторы делают эксперимент с обучением только на таких “forking tokens” и показывают результаты лучше, чем обучение на всем.
Все статьи выше любопытные, но в Beyond the 80/20 Rule авторы из Qwen посмотрели не просто на среднюю энтропию модели, но еще и на ее значения в разрезе отдельных токенов и пришли к выводу, что только в малой части всего контекста сосредоточены высокие значения. В этих токенах происходят самые главные “развилки” в рассуждениях модели, то есть именно здесь идет семплирование токена, который определит суть следующих предложений или абзаца. Довольно интересное наблюдение, которое заставляет задуматься над потенциальными альтернативными методами поддержания exploration в RL или обучения в целом. Например, авторы делают эксперимент с обучением только на таких “forking tokens” и показывают результаты лучше, чем обучение на всем.
Большое обновление SWE-rebench: Tool Usage, Claude Sonnet 3.5/4, OpenAI o3 и данные за май.
Сегодня выпустили довольно крупное обновление бенчмарка, спасибо всем, кто приходил с фидбеком в личку и писал в комментариях. Основные фичи:
- Поддержка Tool Usage. Агент теперь может бежать в двух режимах взаимодействия со средой, с тулами и без. Мы заметили, что даже у самых сильных моделей были сложности с форматированием действий, поэтому добавили инструмент терминала, в который модель отправляет доступные команды.
- Теперь на лидерборде есть фронтир модели Claude Sonnet 3.5/4 и OpenAI o3, большинство запросов было именно по поводу них.
Вскоре надеемся добавить и Gemini 2.5 Pro.
- Майские данные. Намайнили нашим пайплайном данных за май и докинули результаты для всех моделей.
Продолжаем принимать запросы, чего не хватает, какие модели хотелось бы видеть и любой другой фидбек 🙂
Лидерборд: https://swe-rebench.com/leaderboard
Сегодня выпустили довольно крупное обновление бенчмарка, спасибо всем, кто приходил с фидбеком в личку и писал в комментариях. Основные фичи:
- Поддержка Tool Usage. Агент теперь может бежать в двух режимах взаимодействия со средой, с тулами и без. Мы заметили, что даже у самых сильных моделей были сложности с форматированием действий, поэтому добавили инструмент терминала, в который модель отправляет доступные команды.
- Теперь на лидерборде есть фронтир модели Claude Sonnet 3.5/4 и OpenAI o3, большинство запросов было именно по поводу них.
Вскоре надеемся добавить и Gemini 2.5 Pro.
- Майские данные. Намайнили нашим пайплайном данных за май и докинули результаты для всех моделей.
Продолжаем принимать запросы, чего не хватает, какие модели хотелось бы видеть и любой другой фидбек 🙂
Лидерборд: https://swe-rebench.com/leaderboard