Kaggle соревнование lmsys chatbot arena, часть 2. Технические подходы.
В продолжение разбора соревнования обещал написать вторую часть с техническим обзором. Время пришло.
Задачу можно было решать двумя вариантами: добавить голову и учить модель на задачу классификации или же оставить предсказание следующего токена и напрямую предсказывать токен-метку. Разницы особой нет, но во втором случае можно использовать много разных фреймворков с оптимизациями обучения и инференса по типу unsloth.
Бейзлайн выглядит так:
1. Берем llama3-8B или gemma2-9B
2. Учим лору, вставляя адаптеры во все линейные слои
3. Инференсим квантизованную модель в int4/8 без мерджа весов адаптеров
Улучшить решение можно было несколькими способами:
1. Pseudo-labeling. берем какой-нибудь lmsys-1M-dataset, составляем пары ответов на один промпт и размечаем llama3.1_405B. Были попытки и с нуля генерировать синтетические данные, но докидывали они значительно меньше, все-таки распределение данных в таком случае сильно отличается от целевого.
2. External Datasets. Просто докидываем больше данных в post pre-train. Важно, что не в финальный fine-tune, тк на последнем шаге лучше использовать только данные из соревнования. Много интересных датасетов можно найти в RLHFlow. Авторы так же в свое время писали неплохую статью про RLHF.
3. Ensembling. Пришлось пробовать много разных моделей: MistralNemo, Llama3/3.1, Phi, Yi, Qwen, Gemma и тд. Лучше всего заработала gemma2-it, причем с большим отрывом по сравнению с другими моделями. На втором месте Llama3 (интересно, что 3.1 не докидывала). Удивительно, но модели от Mistral вообще не могли справиться с задачей.
Если добавить всякие оптимизации во время инференса (dynamic batch size, dataset length sorting), где-то пожертвовать длиной контекста, то можно было уместить на 2xT4 инференс gemma + llama за 9 часов. Gemma работала значительно дольше, в частности, из-за огромного словаря.
4. Inference tricks. Всякие мелкие, но важные детали. Например, если мы используем ансамбль, то в одну модель лучше отправлять question-responseA-responseB, а в другую ответы поменять местами, чтобы добавить больше разнообразия. Важно также выставить truncation left side, чтобы жертвовать токенами из начала — они меньше влияет на предикт модели. Кто-то лез совсем в детали и выключал logit soft-capping в gemma, писали, что докидывает пару тысячных на лб — типичный кегл😋
Кстати, если я не ошибаюсь, это первое соревнование, в котором завели инференс 33B моделей: vllm + квантизация AWQ + Tensor Parallel.
5. И напоследок прием, который зарешал больше всех — Distillation. Парень с таким подходом и взял первое место. Логика следующая:
1. Бьем весь трейн на 5 фолдов.
2. Тренируем на фолдах Llama3-70B и Qwen2-72B и размечаем весь датасет их предиктами.
3. Опять же на фолдах дистиллируем предикты больших моделей в gemma2, используя самый простой KL loss. Учим только LoRA адаптеры и в итоге получаем 5 моделей.
4. Усредняем веса всех адаптеров и получаем с помощью такого model merging финальную модель.
5. На все про все — А100 80G * 8 + ZeRO2
Часть 1 про лик в соревновании
В продолжение разбора соревнования обещал написать вторую часть с техническим обзором. Время пришло.
Задачу можно было решать двумя вариантами: добавить голову и учить модель на задачу классификации или же оставить предсказание следующего токена и напрямую предсказывать токен-метку. Разницы особой нет, но во втором случае можно использовать много разных фреймворков с оптимизациями обучения и инференса по типу unsloth.
Бейзлайн выглядит так:
1. Берем llama3-8B или gemma2-9B
2. Учим лору, вставляя адаптеры во все линейные слои
3. Инференсим квантизованную модель в int4/8 без мерджа весов адаптеров
Улучшить решение можно было несколькими способами:
1. Pseudo-labeling. берем какой-нибудь lmsys-1M-dataset, составляем пары ответов на один промпт и размечаем llama3.1_405B. Были попытки и с нуля генерировать синтетические данные, но докидывали они значительно меньше, все-таки распределение данных в таком случае сильно отличается от целевого.
2. External Datasets. Просто докидываем больше данных в post pre-train. Важно, что не в финальный fine-tune, тк на последнем шаге лучше использовать только данные из соревнования. Много интересных датасетов можно найти в RLHFlow. Авторы так же в свое время писали неплохую статью про RLHF.
3. Ensembling. Пришлось пробовать много разных моделей: MistralNemo, Llama3/3.1, Phi, Yi, Qwen, Gemma и тд. Лучше всего заработала gemma2-it, причем с большим отрывом по сравнению с другими моделями. На втором месте Llama3 (интересно, что 3.1 не докидывала). Удивительно, но модели от Mistral вообще не могли справиться с задачей.
Если добавить всякие оптимизации во время инференса (dynamic batch size, dataset length sorting), где-то пожертвовать длиной контекста, то можно было уместить на 2xT4 инференс gemma + llama за 9 часов. Gemma работала значительно дольше, в частности, из-за огромного словаря.
4. Inference tricks. Всякие мелкие, но важные детали. Например, если мы используем ансамбль, то в одну модель лучше отправлять question-responseA-responseB, а в другую ответы поменять местами, чтобы добавить больше разнообразия. Важно также выставить truncation left side, чтобы жертвовать токенами из начала — они меньше влияет на предикт модели. Кто-то лез совсем в детали и выключал logit soft-capping в gemma, писали, что докидывает пару тысячных на лб — типичный кегл
Кстати, если я не ошибаюсь, это первое соревнование, в котором завели инференс 33B моделей: vllm + квантизация AWQ + Tensor Parallel.
5. И напоследок прием, который зарешал больше всех — Distillation. Парень с таким подходом и взял первое место. Логика следующая:
1. Бьем весь трейн на 5 фолдов.
2. Тренируем на фолдах Llama3-70B и Qwen2-72B и размечаем весь датасет их предиктами.
3. Опять же на фолдах дистиллируем предикты больших моделей в gemma2, используя самый простой KL loss. Учим только LoRA адаптеры и в итоге получаем 5 моделей.
4. Усредняем веса всех адаптеров и получаем с помощью такого model merging финальную модель.
5. На все про все — А100 80G * 8 + ZeRO2
Часть 1 про лик в соревновании
Please open Telegram to view this post
VIEW IN TELEGRAM
На выходных ездил в Париж на хакатон Alan X Mistral, посвященный healthcare, где Nebius выступал одним из спонсоров и давал всем желающим 1xH100 на эксперименты. Выступал в роли судьи и делал доклад. Несмотря на то, что конкретная тема снизила разнообразие идей и решений (все вертелось так или иначе вокруг медицинских помощников), некоторые команды показали интересные подходы. Кто-то запилил голосового помощника, которому можно по видео что-нибудь показать; кто-то столкнулся с тем, что полезные материалы находятся только в книжных версиях, нашел лекции по этим книжкам на youtube, по транскрипциям выцепили полезные куски и на них уже строили SFT. В общем, было круто общаться, знакомиться и обсуждать подходы. Многие спонсоры там же и предлагали пойти к ним на собесы. Очень классная история для студентов, ищущих стажировки и начальные позиции.
Рассказывал я про outcome/process supervision в LLM агентах, совсем простыми словами, чтобы ребята могли успеть что-то запихнуть в решения к себе. Так как в последнее время на работе занимаюсь различными видами guidance в агентах, думаю сделать какой-то обзор подходов и перспективных идей, которые за этим стоят, в основном все вокруг offline reinforcement learning. Если у вас есть на примете интересные статьи на тему, накидайте плиз те, про которые вам бы хотелось увидеть пост.
Рассказывал я про outcome/process supervision в LLM агентах, совсем простыми словами, чтобы ребята могли успеть что-то запихнуть в решения к себе. Так как в последнее время на работе занимаюсь различными видами guidance в агентах, думаю сделать какой-то обзор подходов и перспективных идей, которые за этим стоят, в основном все вокруг offline reinforcement learning. Если у вас есть на примете интересные статьи на тему, накидайте плиз те, про которые вам бы хотелось увидеть пост.
GLoRe: When, Where, and How to Improve LLM Reasoning via Global and Local Refinements
Статья про базовые подходы к критике моделей для решения multi-step reasoning задач. Здесь в качестве простого бенчмарка рассматривался GSM8K. Для контекста, как может выглядеть задачка оттуда:
То есть это довольно простые задачи на вычисления, но требующие нескольких операций. Авторы рассматривают 3 подхода:
— Outcome Reward Model (ORM). По собранному датасету из множества запусков оцениваем вероятность, что данное решение правильное. В терминах ML это просто кросс-энтропия на 2 класса решено/нет. Это самый простой способ и для своего юзкейса работает хорошо, например, если надо выбрать одно из 5 решений. Собирать данные здесь тоже легко, так как мы заранее знаем правильный ответ.
— Process Reward Model (PRM). Учим предсказывать корректность каждого действия. В таком случае на каждом шаге размышления модели мы сможем оценить его правильность. Но в такой постановке нам нужно разметить каждое действие по отдельности, что может быть дорого и медленно, если использовать человеческую разметку.
— Stepwise Outcome Reward Model (SORM). Это собственно первая новизна в статье. Для каждого шага учимся предсказывать V-функцию оптимальной стратегии (обозначается V*). Что это значит более простыми словами: V*(S) = 1, если из этой позиции можно решить задачу и V*(S) = 0, если нельзя. Здесь есть нюанс: на самом деле оптимальная стратегия зачастую может решить задачу из любого состояния, для gsm8k уж точно, но разметка вида V*(S) = 1 везде нам полезной не будет. Так как мотивация исходит из того, чтобы далее критиком дополнить основную LLM, нам нужно уметь отличать ее хорошие действия от плохих. Поэтому в качестве аппроксимации V* авторы берут Best-of-K генераций основной модели, то есть таргет для состояния = 1, если хотя бы одно решение из него оказалось правильным, и 0 иначе. Таким образом, мы учим что-то вроде “вероятность, что какое-то решение из этого состояния будет правильным”. Все это очень сильно перекликается с недавними идеями из статьи про Advantage Verifiers, про которую возможно в другой раз.
Сравнения с PRM для критики рассуждений нет, но утверждают, что SORM работает лучше ORM, правда только для промежуточных шагов. Для финального ранжирования по всем траекториям ORM выигрывает.
Вторая новизна заключается в том, чтобы использовать SORM для прокачки ризонинга основного генератора, про это — во второй части.
Статья про базовые подходы к критике моделей для решения multi-step reasoning задач. Здесь в качестве простого бенчмарка рассматривался GSM8K. Для контекста, как может выглядеть задачка оттуда:
Мистер Санчес выяснил, что 40% учеников его 5-го класса получили итоговую оценку ниже B. Сколько учеников получили итоговую оценку B и выше, если у него 60 учеников в 5-м классе?
То есть это довольно простые задачи на вычисления, но требующие нескольких операций. Авторы рассматривают 3 подхода:
— Outcome Reward Model (ORM). По собранному датасету из множества запусков оцениваем вероятность, что данное решение правильное. В терминах ML это просто кросс-энтропия на 2 класса решено/нет. Это самый простой способ и для своего юзкейса работает хорошо, например, если надо выбрать одно из 5 решений. Собирать данные здесь тоже легко, так как мы заранее знаем правильный ответ.
— Process Reward Model (PRM). Учим предсказывать корректность каждого действия. В таком случае на каждом шаге размышления модели мы сможем оценить его правильность. Но в такой постановке нам нужно разметить каждое действие по отдельности, что может быть дорого и медленно, если использовать человеческую разметку.
— Stepwise Outcome Reward Model (SORM). Это собственно первая новизна в статье. Для каждого шага учимся предсказывать V-функцию оптимальной стратегии (обозначается V*). Что это значит более простыми словами: V*(S) = 1, если из этой позиции можно решить задачу и V*(S) = 0, если нельзя. Здесь есть нюанс: на самом деле оптимальная стратегия зачастую может решить задачу из любого состояния, для gsm8k уж точно, но разметка вида V*(S) = 1 везде нам полезной не будет. Так как мотивация исходит из того, чтобы далее критиком дополнить основную LLM, нам нужно уметь отличать ее хорошие действия от плохих. Поэтому в качестве аппроксимации V* авторы берут Best-of-K генераций основной модели, то есть таргет для состояния = 1, если хотя бы одно решение из него оказалось правильным, и 0 иначе. Таким образом, мы учим что-то вроде “вероятность, что какое-то решение из этого состояния будет правильным”. Все это очень сильно перекликается с недавними идеями из статьи про Advantage Verifiers, про которую возможно в другой раз.
Сравнения с PRM для критики рассуждений нет, но утверждают, что SORM работает лучше ORM, правда только для промежуточных шагов. Для финального ранжирования по всем траекториям ORM выигрывает.
Вторая новизна заключается в том, чтобы использовать SORM для прокачки ризонинга основного генератора, про это — во второй части.
В продолжение предыдущего поста поговорим о второй новизне, а именно использовании 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], тем самым провоцируя модель на повторную попытку решения.
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], тем самым провоцируя модель на повторную попытку решения.
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, что кажется лучшим результатом, основанным на опенсорс моделях. Теперь у нас есть огромное кол-во мыслей, как далее развивать подобные методы, область применения которых достаточно богатая и подходит практически для любых агентов.
Подоспел пост от нашей команды про 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, что кажется лучшим результатом, основанным на опенсорс моделях. Теперь у нас есть огромное кол-во мыслей, как далее развивать подобные методы, область применения которых достаточно богатая и подходит практически для любых агентов.
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, например, рассуждают про факт, что с ростом числа кандидатов итоговое качество может начать падать с какого-то момента. Если не читали, с этого рекомендую начать.
Если знаете крутые статьи на тему, кидайте (желательно с комментариями), будем обогащать список! Думаю через недельку докину еще парочку.
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, например, рассуждают про факт, что с ростом числа кандидатов итоговое качество может начать падать с какого-то момента. Если не читали, с этого рекомендую начать.
Если знаете крутые статьи на тему, кидайте (желательно с комментариями), будем обогащать список! Думаю через недельку докину еще парочку.
На Kaggle вышло новое соревнование, описание которого начинается с
Итак, набор задач, на которых будет производиться финальный скоринг решений будет собираться только после дедлайна, чтобы уж точно не было никакого переобучения. При этом мы не знаем, будут ли брать репозитории, созданные так же после закрытия приема решений, без этого остается шанс, что что-то утечет в трейн.
Вообще идея скрыть тест отличная. 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 моделях. С другой стороны, сложность задач в них мы не знаем, да и приз за это отдельный в миллион. Так что поучаствовать в любом случае смысл есть.
Ну и подумываю над тем, чтобы самому попробовать что-то поделать 🙂
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 моделях. С другой стороны, сложность задач в них мы не знаем, да и приз за это отдельный в миллион. Так что поучаствовать в любом случае смысл есть.
Ну и подумываю над тем, чтобы самому попробовать что-то поделать 🙂
Вдогонку к посту выше релизим данные для разработки SWE-агентов: 6.4k GitHub issue-PR пар и ~80k траекторий от SWE-agent
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, то это как раз она — несмещенная оценка со сниженной дисперсией. В общем, чтиво коротенькое и очень интересное, рекомендую.