AI[ex]Time

Интересно, что буквально за последнюю неделю вышел целый ряд работ (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” и показывают результаты лучше, чем обучение на всем.

Training superhuman coding models at Cursor Случайно наткнулся на видео, где ребята из Cursor обсуждают всякое разное про LLM. Обычно в подобных подкастах все высказывания очень поверхносные, чтобы случайно не выдать каких-нибудь секретов. А тут на удивление упомянули довольно много технических деталей. Краткий список затронутых тем: - Как делать RL, когда нет одного правильного ответа? - Что делать, если вероятность получить "правильный" ответ очень маленькая? - Как сделать, чтобы модель могла ориентироваться в большом проекте? - Как поддерживать long context? - Как делать credit assignment для memory tool? - Как cursor может обучаться на пользовательских данных. - Почему плохо смотреть на лайки/дизлайки ответов. - Какая инфра нужна для больших RL тренировок. Судя по количеству просмотров, если сам этим не занимаешься, то смотреть не очень интересно. Но мне понравилось!

Объемный и очень интересный тех репорт про модель под названием 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 страниц, там очень много познавательных замечаний, советую хотя бы бегло пробежаться.

Привет! Накопилась пара новостей, которыми буду тут плавно делиться! 👋 Первая, мы зарелизили SWE-rebench – увеличенную и улучшенную версию нашего прошлого датасета с задачами по решению issue из гихаба. Одно из узких мест в подобных датасетах, это что в них не так много задач, которые вдобавок собраны из ограниченного набора репозиториев. Например, в оригинальном SWE-bench: 2,000+ задач из 18 репозиториев. В основном, это происходит из-за того, что каждый проект исследователи устанавливали вручную и потом собирали задачи. Мы автоматизировали и заскейлили этот процесс, поэтому собрали 21,000+ задач из 3400+ репозиториев. Подробный тех репорт можно прочитать на arxiv. Сабсет этого датасета, мы использовали, чтобы сделать наш лидерборд SWE-rebench, про который писал Саша. P.S. Еще мы сегодня засабмитили статью на daily paper в HuggingFace, если вдруг у вас там есть аккаунт, буду благодарен за upvote! 🤗

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! Для борьбы с потенциальной контаминацией, мы будем регулярно обновлять лидерборд с замерами на свежих задачах. Скаффолдинг агента при этом везде фиксирован, чтобы запуски с разными моделями были сравнимы между собой. Так как наш пайплайн сбора данных позволяет автоматически контролировать сложность задач, то в будущем мы будем использовать это для борьбы с насыщением бенчмарка. Детали можно прочитать на сайте самого бенча, ну и конечно приглашаю заглянуть на текущий лидерборд. Если вы привыкли читать обзоры в Х, там тоже есть подходящий контент.

Neel Nanda, лид команды Mechanistic Interpretability в DeepMind (от него же есть крутое видео про открытые проблемы в области, советую) написал лонгрид, как писать ML статьи. Выглядит, как качественный ресурс, где собраны все: от общей интуиции и формулирования гипотез до конкретных ошибок в подаче материала. Через призму этого фреймворка смотрит на свою же работу Progress measures for grokking via mechanistic interpretability. До конца подачи на NeurIPS еще 3 дня, забираем и пользуемся?

Недавно из блога Lilian Weng (всем рекомендую, кто не знал) про RL перешел на сайт Jeremy Kun-а и обнаружил, что там есть довольно много интересных заметок. Например, одна из них посвящена вопросу, про который я хотел написать в рамках #interview_questions. Вопрос: у вас есть честная монетка (вероятность решки 1/2). Как только с ее помощью смоделировать подбрасывание нечестной монетки с любой заданной вероятностью решки p. Нужно написать функцию, принимающую на вход p и возвращающую 0/1 c этой вероятностью. Загадка, зачем спрашивать такое на собеседованиях, но решение мне кажется довольно красивым.

Давно как-то не доходили руки ничего написать в канал: то по работе дела, то статей интересных не было в моменте, то просто не хотелось. Тем не менее за месяц вышел ряд работ, которые мне показались интересными, с некоторых из них и начнем. 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, где в частности применили эти алгоритмы на последней стадии.

Есть одна популярная заметка от 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, то это как раз она — несмещенная оценка со сниженной дисперсией. В общем, чтиво коротенькое и очень интересное, рекомендую.

Соседняя команда проделала большую работу и сегодня выпустила нашу версию FlashAttention для JAX, которая поддерживает Context Parallelism (CP) и Document Masks. При работе с агентами часто встречаются траектории огромной длины вплоть до 128к+ токенов, поэтому CP становится необходимым. При этом, если дополнять каждую последовательность до max_seq_len, ресурсы будут использоваться неэффективно из-за бесполезных pad токенов, т.к. траектории все-таки могут быть и короткими. Отсюда хочется уметь паковать несколько траекторий в один ряд в батче и разделять их масками, чтобы при вычислении attention скоров они не влияли друг на друга. Все это реализовано в нашей либе, за что ребятам большое спасибо ☺️ В посте есть подробное описание, как это работает, а также сравнения с cudnn FA и FlexAttention в различных сценариях, думаю, всем причастным должно быть интересно https://x.com/hr0nix/status/1895096056570093966