AI[ex]Time

Давно не было рубрики интересных вопросов, которые любят спрашивать на собесах, на этот раз мне рассказали про такой:

Как и почему в процессе обучения DPO меняется правдоподобие (растет/падает/не меняется) у y_chosen и y_rejected?

Недавно, залипая в метрики обучения, я и сам задался таким вопросом. Ответ в комментариях.
#interview_questions

Думаю для многих уже не новость — да, DeepSeek сделали хорошую модель R1. Некоторые хайлайты из статьи:

1. Чтобы завести весь процесс ризонинга использовали только RL, причем в максимально простой постановке с алгоритмом GRPO (модификация PPO).
В чем проблема PPO: Для оценки Advantage состояния-действия мы используем отдельную сетку/голову с предсказанием Value. Это привносит нам дополнительные веса, новый лосс, который нужно аккуратно добавить к общему, гиперпараметры, на которые весь алгоритм реагирует довольно чувствительно, система в целом становится сложнее.
Вместо этого в GRPO мы делаем много симуляций решений r из состояния и оцениваем Advantage методом Monte Carlo: A_i = (r_i - mean(r)) / std(r). Похожий алгоритм мы видели уже в статье VinePPO.

2. Награда состоит всего из двух частей: Accuracy rewards (правильный ли финальный ответ) и Format rewards (правильно ли отформатировали рассуждения, то есть разместили его между токенами <thinking> и </thinking>)

3. Интересное наблюдение: длина рассуждений растет с процессом обучения. Это не было никак не заложено эвристиками и отдельно никак не стимулируется. В какой-то момент в рассуждениях появляются рефлексия, проверка разных сценариев и тд.

На выходе получили R1-Zero, мощную модель, обученную из base версии только с помощью одного RL алгоритма. Для финальной R1 использовали еще пару итераций с SFT + RL, чтобы разрешить некоторые артефакты, например, рассуждения на разных языках.

Очень рад за полученные результаты, как минимум потому, что надеюсь, что активное развитие подобных методов постепенно будет двигать нас в сторону сред/задач, где нет легко верифицируемого решения. Напомню, весь прогресс с o1, R1 и другими thinking моделями делается там, где мы можем легко проверить, правильный получился ответ в конце или нет.

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

В статье предлагают считать лосс по глобальному батчу, то есть давать модели как-то более осмысленно группировать токены для каждого эксперта. Перплексия чуть падает, бенчмарки чуть растут, дополнительная коммуникация для подсчета лосса ничтожная.

Дьявол как всегда в деталях, а то мы не знали 😔

Праздники и отпуск прошли, теперь пора и что-нибудь интересное разобрать. Впереди 9 часов в поезде и много отложенных статей — вечер обеспечен 🏃

Начнем с The Lessons of Developing Process Reward Models in Mathematical Reasoning. Исследование от команды Qwen на тему, как делать хорошие PRM (Process Reward Model) в математике, то есть модели, оценивающие промежуточные рассуждения модели. Ребята в последнее время очень часто радуют не только классными моделями, но и качественными статьями.

Для того, чтобы тренировать модель оценивать шаги рассуждений, нам нужна разметка, где каждому такому шаг присвоена некоторая метка. Вариантов тут немного:

- Использовать LLM-as-a-judge (просим другую модель оценить шаг) или ручную разметку.
- Использовать monte-carlo (MC) оценку шага, то есть для оценки шага делаем из него множество продолжений и смотрим, сколько из них завершились успехом. Метку можно определить как a) soft label — доля успешных продолжений или b) hard label — 1, если хотя бы одно продолжение успешно и 0 иначе.

Авторы делают большое кол-во экспериментов, из которых формулируют много интересных тезисов, например:

- MC методы неявно закладывают смысл value функции в оценку шага, то есть оценивают перспективность состояния для будущего решения задачи. Это может накладывать ограничения в умения модели находить неверные шаги.
- MC методы имеют меньший прирост качества от скейлинга данных по сравнению с LLM-as-a-judge и human annotation.
- Большая проблема MC методов заключается в том, что модели склонны решать задачи даже со множеством ошибок в рассуждениях. Это приводит к артефактам во время инференса.

Это только малая часть, в статье намного больше мыслей, подкрепленных обильными экспериментами, рекомендую почитать всем интересующимся реворд моделями.

Далее авторы предлагают алгоритм “консенсуса” между MC методом и LLM-as-a-judge, обученные модели показывают соту на математических бенчмарках и выложены в опенсурс (7B и 72B)

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

Мы зарелизили первый датасет для 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

Блогпост с подробным описанием того, как собирали данные можно прочитать тут

На Kaggle вышло новое соревнование, описание которого начинается с I'm Andy, and I’m giving $1M to the first team that exceeds 90% on a new version of the SWE-bench benchmark. Звучит вызывающе, поэтому давайте посмотрим на это чуть подробнее. Кстати, про сам бенчмарк я немного писал в посте тут.
Итак, набор задач, на которых будет производиться финальный скоринг решений будет собираться только после дедлайна, чтобы уж точно не было никакого переобучения. При этом мы не знаем, будут ли брать репозитории, созданные так же после закрытия приема решений, без этого остается шанс, что что-то утечет в трейн.

Вообще идея скрыть тест отличная. SWE-bench сразу опубликовал все датасеты, на которых можно запускаться бесконечное число раз, смотреть на ошибки и править скаффолдинг. Это не говоря про то, чтобы вообще подлить тест в трейн. Посмотрим, что из этой затеи получится.

Однако, есть ряд вещей, который смущает:

1. На подмножестве легких задач, SWE-bench Lite, топ1 идет с 48.3%, на Verified (другое подмножество, где люди проверили, что с задачами все окей и их можно решить в принципе) — 55%. Все это скорее всего на frontier models по типу Sonnet 3.6. Скорее всего, потому что мы не знаем подробности про Amazon Agent Q и другие closed source решения.
2. Решения на текущем лидерборде SWE-bench не были никак ограничены в test-time compute и железе. Считай сколько хочешь на H100 (или ходи в апи), а потом сабмить. Здесь же у нас 24 часа на 4XL4 (всего 96GB), притом что конексты нужны огромные, вплоть до 65-128к. Видимо, нужно использовать скаффолдинги, менее требовательные к длине контекста, например, Agentless.

Все это звучит так, что цифра в 90% звучит как что-то недостижимое за 3 месяца, так еще и на os моделях. С другой стороны, сложность задач в них мы не знаем, да и приз за это отдельный в миллион. Так что поучаствовать в любом случае смысл есть.

Ну и подумываю над тем, чтобы самому попробовать что-то поделать 🙂

Test-time scaling звучит изо всех утюгов, все пытаются реплицировать o1, много спекуляций насчет методов, как это сделать. Один из углов, под которым можно на это посмотреть, — Verifiers, то есть модели, оценивающие то, что генерирует наша модель. Имея такой Verifier можно запускать алгоритмы поиска наилучшей траектории во время инференса или вообще дистиллировать этот поиск в саму модель, чтобы получился длительный CoT. Собрал небольшую подборку статей вокруг offline RL, которые могут быть полезны в этом направлении.

GLoRe: When, Where, and How to Improve LLM Reasoning via Global and Local Refinements
Здесь тренируют оценивать оптимальную Value функцию, а дальше используют эту модель для того, чтобы учить модель исправлять свои же ошибки. Понятное введение про то, как можно дистиллировать работу критика в основную модель. Все эксперименты правда сделаны на GSM8K.

Stop Regressing: Training Value Functions via Classification for Scalable Deep RL
Это просто прикольная статья про сведение задачи предсказания Value функции к классификации. Рассматривают изящные методы (2hot encoding, HL-gauss, distributional RL), которые позволяют предсказывать в итоге не скаляр, а целое дискретное распределение, что увеличивает гибкость во время инференса. Например, мы можем брать различные квантили, то есть оптимистичные/пессимистичные предсказания.

Rewarding Progress: Scaling Automated Process Verifiers for LLM Reasoning
Авторы исследуют вопрос, а какую модель лучше использовать для генерации данных, на которых обучаются критики. Должен ли это быть самый мощный prover? Спойлер: нет. Как раз пытаются ответить на этот и ряд других вопросов, например, как считать награду действий во время поиска?

IQL (Implicit Q-Learning) и CQL (Conservative Q-Learning)
Классические подходы из offline RL, в которых можно черпать идеи для применения в мире LLM. В IQL оценивают верхний экспектиль значения Value функции, а в CQL напрямую штрафует OOD действия через дополнительную регуляризацию на основе KL-дивергенции. Это довольно мощные алгоритмы в offline RL, так что рекомендую ознакомиться.

Offline RL for Natural Language Generation with Implicit Language Q Learning
Необычный и довольно интересный подход предсказания Q/V-функций на уровне каждого токена. Авторы предлагают корректировать итоговые вероятности токенов с помощью разницы Q – V (то есть Advantage), чтобы двигать генерацию в сторону оптимизации некоторой награды.

Let’s Verify Step by Step и Training Verifiers to Solve Math Word Problems
Классика от OpenAI. Исследуют Process Reward Model для того, чтобы детектить промежуточные ошибки во время генерации. Здесь же и богатый ablation study, например, рассуждают про факт, что с ростом числа кандидатов итоговое качество может начать падать с какого-то момента. Если не читали, с этого рекомендую начать.

Если знаете крутые статьи на тему, кидайте (желательно с комментариями), будем обогащать список! Думаю через недельку докину еще парочку.

Leveraging training and search for better software engineering agents

Подоспел пост от нашей команды про SWE агентов, где мы рассматриваем один из способов использовать test-time compute для улучшения перформанса.

Давайте немного расскажу про изначальную идею. Когда мы говорим про агентов, то подразумеваем 3 вещи: модель, которая видит задачу, генерирует план, действия и так далее; среду, в которой этот агент взаимодействует и прослойку между ними — scaffolding, то есть это та обвязка поверх модели, которая и превращает обычную LLM в агента. Грубо говоря, это набор промптов, инструментов, парсеров, дополнительных программ, выполняющие API вызовы и прочее. В последнее время очень много компаний фокусируется на том, чтобы улучшить именно последнюю часть, например, затюнить промпты или ввести суб-агентов, которые концентрируются на выполнении более узких задач. Здесь появляется идея 1: концентрироваться на улучшении скаффолдинга в long-term не имеет смысла. Все обвязки исходят из текущих ограничений моделей, которые могут стать неактуальными в будущем. Более того, нет оснований идти против The Bitter Lesson. Идея 2: соревноваться с frontier models в качестве основных генераторов опасно. Мы можем вложить массу компьюта и экспериментов в обучение и получить хорошую модель за счет специфических данных, но опять же в long-term проиграть Claude-4/GPT-5/Gemini-2, которые будут работать лучше просто из коробки. Отсюда возникла мысль: нужно идти в сторону того, что можно масштабировать при увеличении компьюта и при этом не ввязываться в гонку с фронтир моделями. Так появилась идея разменивать test-time compute на качество через критиков (часто в литературе их называют Verifiers), оценивающих Q/V функции. Подробнее про это уже можно почитать в посте.

Взяв только открытые модели (Llama3.1-70B и Qwen2.5-72B) и применив описанные идеи, получилось выбить 40.6% на SWE-bench Verified, что кажется лучшим результатом, основанным на опенсорс моделях. Теперь у нас есть огромное кол-во мыслей, как далее развивать подобные методы, область применения которых достаточно богатая и подходит практически для любых агентов.

В продолжение предыдущего поста поговорим о второй новизне, а именно использовании SORM для дообучения модели исправлять свои ошибки. Делать это авторы учат в двух вариантах: Global и Local Refinement.

Global Refinement — умение модели сгенерировать ответ заново, когда мы получили неправильный результат. Авторы собрали множество триплетов (вопрос, плохая генерация, хорошая генерация) и учили предсказывать правильный ответ по префиксу вида “{вопрос} [BAD] {плохая генерация}”, то есть модель может посмотреть на предыдущие свои рассуждения и уже не делать каких-то ошибок.

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

Дополнительный вывод такой: оба способа дополняют друг друга и для лучшего качества их нужно использовать вместе. На инференсе мы можем подобрать пороги для SORM/ORM, чтобы определять ситуации, когда нужно проставить метку [BAD], тем самым провоцируя модель на повторную попытку решения.

GLoRe: When, Where, and How to Improve LLM Reasoning via Global and Local Refinements

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

На выходных ездил в Париж на хакатон Alan X Mistral, посвященный healthcare, где Nebius выступал одним из спонсоров и давал всем желающим 1xH100 на эксперименты. Выступал в роли судьи и делал доклад. Несмотря на то, что конкретная тема снизила разнообразие идей и решений (все вертелось так или иначе вокруг медицинских помощников), некоторые команды показали интересные подходы. Кто-то запилил голосового помощника, которому можно по видео что-нибудь показать; кто-то столкнулся с тем, что полезные материалы находятся только в книжных версиях, нашел лекции по этим книжкам на youtube, по транскрипциям выцепили полезные куски и на них уже строили SFT. В общем, было круто общаться, знакомиться и обсуждать подходы. Многие спонсоры там же и предлагали пойти к ним на собесы. Очень классная история для студентов, ищущих стажировки и начальные позиции.

Рассказывал я про outcome/process supervision в LLM агентах, совсем простыми словами, чтобы ребята могли успеть что-то запихнуть в решения к себе. Так как в последнее время на работе занимаюсь различными видами guidance в агентах, думаю сделать какой-то обзор подходов и перспективных идей, которые за этим стоят, в основном все вокруг offline reinforcement learning. Если у вас есть на примете интересные статьи на тему, накидайте плиз те, про которые вам бы хотелось увидеть пост.

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 про лик в соревновании

Хорошие слайды от одного из сотрудников DeepMind на тему LLM Reasoning, RL, Verifiers — в общем всего, что занимает умы многих последние месяцы 😅

Вкратце шаг за шагом проходят по многим популярным методам:
— ReST: генерируем синтетику, фильтруем правильные примеры (для этого у задачи должен быть правильный ответ, который нам известен) и докидываем в тренировку.
— Добавляем Verifier: во время инференса генерируем множество вариантов и выбираем один с помощью эвристики/модели.
- В качестве эвристики отлично работает Majority Voting, то есть берем генерацию с самым частым финальным ответом среди кандидатов.
- Модель же можно обучать разными способами: от бинарной классификации на правильный/неправильный ответ до DPO на генерации из ReST.
— Verifier дает нам возможность разменивать качество на объем вычислений: общая тенденция такая, что генерируя больше кандидатов и выбирая из них ответ, можно сильно растить метрики. Отличная статья на тему scaling test-time compute: https://arxiv.org/abs/2408.03314v1
— Переходим к Generative Verifier — очень популярный в последнее время метод обучения критиков. Заключается он в том, что модель мы учим так же в режиме next token prediction и можем добавить Chain of Thought, от чего качество становится еще выше.
— Еще есть всякие дополнительные топики по типу Cost-Matched Sampling, Reinforced In Context Learning (что, кстати, позволяет делать интересные штуки по типу “дообучаться на лету” под поведение пользователя)

Подоспела запись вебинара от OpenAI и Alistair Pullen (Cofounder & CEO Genie) про файн-тюнинг линейки gpt4o моделей. Напомню, Genie — лаборатория, совсем недавно показавшая лучший результат на SWE-bench verified 43.8% (тщательно отфильтрованная версия оригинального бенчмарка), взяв за основу gpt4o и дотюнив ее с OpenAI под доп задачи.

- Всего тюнили на 100М токенах, поддерживают 15 языков программирования. Правда не рассказали, какие конкретно данные были: только траектории из swe-bench или какая-то смесь из разных задач.
- Эксперименты ставились в таком формате: сначала proof of concept на маленькой модели (gpt4o-mini), потом переходят на большую. Но для “picker model” (классификатор, который выбирает лучшее действия из набора кандидатов) оставили маленькую модель.
- Alistair топит за eval-driven finetuning. Если опираться только на “vibe-checking” — все сойдется к субоптимальному результату.
- Пример работы по улучшению тренировочных данных. Была проблема: модель фейлится в решении легкой задачи если у нее не получилось с первого раза. Причиной оказалось то, что в датасете такие задачи всегда решались с первого раза. Решение: наделать синтетики, где после неудачных попыток простая задача все-таки решается (не рассказали, как делали так, чтобы эта синтетика не провоцировала вторую попытку там, где раньше была одна, но обычно это делается простым маскированием части токенов)
- Другой пример. Alistair говорит, что в обучении (видимо, имеется в виду весь цикл обучения моделей OpenAI) недостаточно представлена ошибка runtime errors, так что имеет смысл нагенерить для тюнинга сэмплов с ними и примерами, как действовать в таких случаях.
- Интересная мысль, про которую упомянул вскользь: во время валидации находить части, где у генерации модели высокий uncertainty и дальше изучать трейн, чтобы понять, почему так произошло. Таким образом итеративно можно закрывать потенциальные пробелы, которые трудно уловить визуально.
- Очевидно весь фокус направлен на данные, включая синтетику, а не настройку гиперпараметров. Учили все со значениями, предложенными OpenAI.
- После тюнинга обобщающая способность модели падает: модель начинает хуже работать вне того распределения, на котором тюнили.

Хорошая статья с разбором RingAttention - метода вычисления Attention с задействованием всех доступных карт, при этом не сильно упираясь в communication costs. Мотивация растет как всегда из того, что у Attention квадратичная сложность, и на больших контекстах потребление памяти становится огромным. Но даже с учетом оптимизаций FlashAttention (где за счет ухода от хранения полной матрицы QxK сложность памяти снижается до линейной) мы упираемся в проблемы для контекстов в сотни тысяч/миллион и больше. Поэтому хочется использовать несколько карт, чтобы распределить нагрузку на память. Собственно метод предлагает вариант реализации такого алгоритма, а в статье довольно подробно описаны все технические моменты по типу разбиения матриц Q, K, V и агрегация результатов для подсчета коэффициентов.

Неделю назад закончилось соревнование LMSYS - Chatbot Arena Human Preference Predictions на kaggle, где нужно было предсказать модель-победитель из чата пользователя на lmsys chatbot арене (Место, где юзер общается сразу с двумя моделями и оценивает их ответ. Из множества оценок складывается общий рейтинг ELO всех моделей). Получилась эта история очень неоднозначной: два найденных лика, один из которых зарепортили в последние 2 дня (тк некоторые люди хотели использовать его, не сообщив организаторам, и взять первые места), пересбор всего private теста после окончания, необходимость в большом кол-во железа для обучения моделей и как следствие шейкап в конце. Все соревнование держался на 1-5 месте, но на прайвате на новых собранных датасетах откатились аж до 33 😢

У этой серии будет несколько постов (описание лика, технических подходов, выводов), но пока не знаю, сколько именно. Для начала пара слов о задаче: есть чаты пользователей с арены, то есть серия вопросов, на каждый из которых имеется два ответа: от модели A и от модели B. Пообщавшись какое-то время, пользователь может поставить winner model A/B, Tie, Tie (both bad). Этот ответ и нужно было научиться предсказывать, только Tie и Tie (both bad) склеены в одну метку. Упрощая, можно сказать, что у нас задача классификации на 3 класса с финальной метрикой logloss.

Итак, часть 1. Лик за 2 дня до конца, который поставил все соревнование под угрозу

Если мы зайдем на лидерборд арены, то увидим ссылку на колаб для воспроизведения всех результатов. В этом ноутбуке скачивается файл, содержащий оценки пользователей за всю историю. Но самих чатов (промптов + ответов моделей нет), то есть казалось бы, эти данные не несут опасности. Наверное, поэтому организаторы и не стали задумываться о возможности лика в этом месте, но если посмотреть внимательно, то в колонке conv_metadata лежит информация о кол-ве токенов из промпта и ответов моделей. А токенизатор, который используется для сбора этой статистики, тоже известен. Тогда получается следующая картина: во время теста на кегле можно токенизировать вопросы/ответы и для многих случаев однозначно смапить их со строчкой из файла арены, где финальный ответ уже есть. Из-за этого в один из последних дней, когда у первого места был скор 0.879, люди проснулись и увидели 0.656, потом 0.251, а потом и вовсе ~0.1. На форуме несколько дней стоял хаос, так как до конца оставалось совсем немного, а ответа от организаторов не было. Итоговое решение было такое: продлить соревнование на 2 недели, заморозить прием сабмитов и пересобрать тестовый набор.

Интересный сайд эффект, с которым ничего не стали делать: после заморозки соревнования и сбора нового теста, ~10% участников не получили никакого места на лидерборде, тк все их решения упали по таймауту 🤯

В следующем посте расскажу про основные технические подходы.

Agent Q: Advanced Reasoning and Learning for Autonomous AI Agents. Интересная работа, объединяющая известные методы улучшения моделей для решения сложных агентских задач. Здесь и про SFT (STaR), и MCTS во время инференса, и DPO на траекториях, и AI feedback guidance: в общем хороший обзор популярного сейчас направления с агентами. Любопытным показался метод сбора данных для обучения DPO, но уже не на уровне траекторий, а на уровне каждого шага. Давайте про этот момент подробнее.

В классическом DPO у нас есть промпт x и пара y_chosen, y_rejected, для которых мы и считаем функцию ошибки. Для агентских сред все сложнее — допустим, мы решаем задачу: забронировать столик в ресторане Bougainville на 30 августа на 2 человек на 19:00. Для этого агенту нужно сделать целый ряд действий, а в итоге мы знаем лишь одно: получилось выполнить задачу или нет. И если в каком-то состоянии у агента есть n действий на выбор, то возникает вопрос, а как их сравнивать между собой, чтобы сгенерировать датасет попарок? К этой проблеме можно подойти по-разному: тренировать RM, использовать другую LLM в качестве критика или вообще не сравнивать между собой действия, а сразу целые траектории (это и есть trajectory-level DPO эксперимент из статьи).

Здесь же авторы предложили следующее: давайте применим MCTS (Monte Carlo Tree Seach) для того чтобы для состояния и выбранного действия уметь оценивать Q(s, a) функцию. Q функция говорит о том, какую среднюю награду мы можем получить из состояния s, сделав действие а. За счет большого кол-ва симуляций в алгоритме (то есть попыток решить задачу из различных состояний) мы как раз получаем такого рода оценки. Далее в любом состоянии мы выбираем такие a_chosen, a_rejected, что разность их Q функций отличается на определенное значение. Это означает, что действие лучше не потому, что так оценил человек/модель, а потому, что с этим состоянием чаще удалось решить задачу.
Отдельно радует, что таким образом можно собирать примеры и для довольно сложных задач, достаточно, чтобы модель умела хоть изредка решать их, иначе все оценки Q функций будут нулевые. На одном из бенчмарков такой тюнинг давал существенный прирост поверх других методов. Далее еще на инференс добавить MCTS и получаем SOTA 🙂

Последние несколько дней в который раз разбирался в видах параллельного обучения: FSDP, TP/PP, Zero и так далее. По серии постов от huggingface получится скопировать и как-то запустить, но основательно понять — вряд ли. Можно конечно читать оригинальные статьи, но это не очень хороший первый шаг, когда нужно получить интуицию. Посоветовали заметки от University of Amsterdam, где неплохо описана секция Training Models at Scale, с описанием collective operations, которые применяются в каждом алгоритме, и примерами имплементации. Делюсь с вами, возможно пригодится тем, кому предстоит пилить такие вещи самому. Все примеры правда на Jax, но читается вполне нормально 😅

17 августа в Москве состоится IT-пикник — событие для IT-специалистов. Вход на мероприятие будет осуществляться по пожертвованию в один из десяти благотворительных фондов.

Программа пикника:
📚 Лекции от экспертов
🛠 Воркшопы для взрослых и детей
🔬 Научно-популярные мероприятия
🎮 Интерактивные зоны
🎵 Музыкальные выступления

Участники смогут самостоятельно выбрать, в какую благотворительную организацию направить свои взносы. Вот здесь можно почитать подробнее.

Одним из фондов, который можно поддержать, является Карельский регистр доноров костного мозга. Этот фонд помогает пациентам с лейкемией найти совместимого донора и получить шанс на выздоровление. Пожертвования позволяют оплачивать обследование новых доноров. Поддержать фонд можно по ссылке

Хорошая возможность совместить полезное с приятным: посетить тематическое мероприятие и помочь людям

Собрали небольшой компанией папку https://t.me/addlist/C_RSYpbW5mIyMjVi тг каналов про ML/DL/AI, которая покрывает сразу большой спектр тем: Илья (автор Сайги) много рассказывает про эксперименты с моделями, алайнмент, своего тг бота; Таня недавно стала менеджером в одной из команд Llama и пишет про интересные связанные темы, например, как поменялись бенчмарки для LLM; Ибрагим занимается сбором огромного кол-ва данных для претрейнов и часто делится обзорами на тему у себя (пост про FineWeb); Богдан шарит много информации про свой стартап Vibe и всякие заметки на тему LifeOps. В общем, думаю, что сможете полистать и отобрать, что приглянулось 🙂

В последние месяцы наблюдаю ажиотаж вокруг кодовых агентских бенчмарков по типу SWE-bench. Каждую неделю выходит новая работа, устанавливающая SOTA результаты на лайт версии. Напомню: в SWE-bench агенту дается описание issue, которую нужно починить. Починить означает сгенерировать правильный патч для нужного файла, после применения которого заготовленные тесты будут успешно завершаться (а до этого они падали). Первой работой, где произошел значительный прогресс в этом бенчмарке был SWE-agent на основе gpt4/claude opus. Версия с моделью от openai давала на лайт версии 18% (Последний результат - агент Aide, 43%). Но рассказать хочется не про сота подход, а недавнюю статью AGENTLESS: Demystifying LLM-based Software Engineering Agents. Это лучшее текущее опенсорс решение, осилившее 27% задач. Но интересным выглядит сам подход, тк за его простотой виден сценарий, как можно получить пользу от подобных моделей. Вместо сложных мультиагентных систем или большого числа доступных модели инструментов, здесь каждая задача решается по определенному сценарию из 2 шагов: 1) Найти классы/функции в нужных файлах, которые необходимо исправить 2) Сгенирировать изменение.

Локализация (верхний блок на картинке). Происходит итеративно путем демонстрации сначала структуры всего репозитория, потом отдельных файлов, и структур кода. Модель на каждом шаге отбирает topN кандидатов, в которые нужно углубиться на уровень ниже (папки, файлы, имплементации классов)

Генерация изменения (нижний блок). Здесь мы пользуемся вероятностным свойством LM и генерируем множество патчей на каждый блок (все эти патчи будут немного отличаться из-за семплинга токенов) и с помощью простой пост-обработки выбираем главного кандидата.

За счет ограниченного сценария, у модели нет проблем с долгосрочным планированием, ошибками в рефлексии или использованием инструментов. И более того в каждый этап хорошо встраивается подход human-in-the-loop: человек может добавить доп файл для рассмотрения или выбрать лучший патч. Помимо того, что метод дешевле того же swe-agent в 8-10 раз с текущими моделями, возможно с современными моделями подобные подходы более перспективны с точки зрения построения продукта. Остается вопрос, поменяется ли кардинально ситуация с выходом моделей нового поколения, например, gpt-5. Если нужен пост про более подробный обзор swe-bench/swe-agent как основ того, что сейчас активно обсуждают в твиттере, ставьте лайк 🙂

OpenAI за долгое время наконец опубликовали статью: LLM Critics Help Catch LLM Bugs. Идея тянется еще с давних пор: давайте сделаем LLM, которая будет находить слабые места и ошибки при генерации другой LLM. В этом направлении мне очень нравится работа Let’s Verify Step by Step, где авторы учили модель численно оценивать каждый шаг модели-генератора на задачах математики: как только был сделан неправильный переход, LLM-критик давала низкую оценку. Более того, если у нас есть подобная модель, мы можем объединять ее с алгоритмами по типу параллельного поиска или Monte Carlo Tree Search, то есть делать поиск по потенциально полезным состояниям и выбирать наиболее перспективные (как это было сделано в свое время для алгоритмов игры в шахматы и го). Эффективность этого значительно выше, чем у обычной генерации, что понятно: вместо одного продолжения мы генерируем целое множество. Это своего рода дополнительная ручка для размена вычислительных ресурсов на качество.

В этой же работе критик учится давать не численный, а текстовый фидбек для задач написания кода, таким образом генератор получает больше сигнала для последующих действий. Особенно много внимания уделяется совместной работе человека и модели для еще более качественной разметки: в этой связке человек + AI добивается наилучших результатов, но мы ведь все и так это давно знали? 🙃 В статье также много деталей по сбору данных и различным методикам Human Inserted Bugs и Human Detected Bugs – стоит почитать в общем. Еще авторы упоминают, что в RLHF брали PPO; видимо, OpenAI – единственная компания, которая продолжает его использовать, остальные уже съехали на DPO/KTO/you name it.

Из интересных моментов хочется рассказать про способ инференса CriticGPT Force Sampling Beam Search (FSBS). Очевидно, мы хотим, чтобы модель находила как можно больше багов в примерах (назовем это recall). Оптимизируя эту метрику, LLM будет стремиться генерировать все больше и больше замечаний, среди которых будут и галлюцинации (ложные срабатывания), то есть precision будет низким. Если в задаче классификации мы можем двигать пороги алгоритма, выбирая оптимальную для нас точку, то с генерацией текста в данной постановке дела сложнее. FSBS позволяет как-то решать эту проблему: CriticGPT принимает на вход пару (вопрос-ответ) и в каком-то месте может дать фидбек в определенном markdown-формате, начинающемся с трех кавычек. С помощью constrained generation мы можем заставить модель генерировать такой фидбек (highlight) в разных местах. Constrained generation в данном контексте означает, что мы вручную ставим ```, и далее LLM из-за формата обучения думает, что дальше должна последовать критика, и начинает ее генерировать. Причем генерировать мы можем множество различных вариантов параллельно (после такой операции у авторов получалось 28 штук), в итоге имея целый список потенциальных ответов от критика. Наилучший мы выбираем по формуле rm_score + LENGTH_MODIFIER * num_highlights, на этом этапе и происходит контроль precision/recall tradeoff. Подробно этот шаг описан в секции 7.1. Rm_score - оценка Reward модели, LENGTH_MODIFIER - гиперпараметр, контролирующий влияние кол-во хайлайтов.

Andrej Karpathy продолжает радовать контентом и 2 недели назад выпустил крутой выпуск по обучению GPT-2 на 124M с нуля, покрыв очень много тем (еще бы, за 4 часа). По меркам ML это уже прошлый век, но, пусть и с запозданием, хочется отдельно выделить некоторые кусочки, которые, на мой взгляд, могут быть особенно полезны многим изучающим NLP/LLM.

1. Быстрое преобразование тензора токенов из датасета, чтобы получить таргет для обучения: ведь для каждой последовательности токенов нам нужно учиться предсказывать следующий. И там же имплементация DataLoader с этим трюком.
2. Объединение матрицы начальных эмбеддингов и последнего слоя lm_head, предсказывающего следующий токен: мотивация, inductive bias и прочее.
3. Есть такой частый вопрос на собеседованиях: а зачем в attention произведение Q*K делить на sqrt(d)? Похожая история есть с нормализацией весов слоев, где есть residual paths. Здесь Andrej как раз модифицирует их инициализацию для контроля дисперсии.
4. Секцию 1:22 — 2:15 вообще советую посмотреть всю: очень много тем покрыто, пусть и по верхам, но это уже дает какую-то интуицию: разные типы данных для обучения, кернелы в гпу, на что уходит время в attention, почему flash attention так сильно ускоряет операцию и так далее. TLDR: с throughput 16k tokens/sec получили 170k tokens/sec.
5. Важный, хотя кажущийся простым момент с gradient accumulation: зачем нужно дополнительно делить loss на grad_accum_steps. Почему-то этот вопрос тоже часто встречался на собесах.
6. Разные способы оценивать модели в рамках языковых бенчмарков: считать вероятность генерации, напрямую генерировать токен-ответ и т.д.

Алгоритмов алайнмента выходит уже десяток в месяц, и все их даже бегло смотреть нет ни времени, ни желания 😕
Но из последнего приглянулась работа от Salesforce AI, “RLHF Workflow: From Reward Modeling to Online RLHF”. В рамках нее авторы выпустили тюн модели llama3-8b с отличными метриками, которая в частности хорошо показала себя на русском языке.

Идея в следующем (рассмотрим на примере алгоритмов по типу DPO, но в статье есть обобщение на общий случай, где мы оптимизируем награду напрямую, например, с PPO): по мере обучения модель улучшается и генерирует все более качественные ответы. Эту возможность хочется использовать для обогащения датасета, чтобы не ограничиваться только сбором данных в оффлайне. Для добавления такого онлайн exploration нам нужны две вещи:

1. Модель, отличная от основной, способная генерировать ответы из отличающегося распределения. Возникает вопрос, откуда такую модель получить — это классическая дилемма exploitation vs exploration.
2. Preference модель, которая сможет ранжировать новые ответы и добавлять их в датасет для следующей итерации.

Существует множество способов решить эти вопросы, и в статье описаны некоторые из них. Авторы выбрали следующую конфигурацию:

1. Для exploration (то есть для создания новых пар в датасете) используется rejection sampling из текущей модели: генерируется 8 ответов для одного промпта, затем выбирается пара с самой высокой и самой низкой оценками.
2. Preference/Reward Model обучается на большом количестве различных датасетов либо в pointwise постановке (каждому ответу ставится оценка), либо в pairwise постановке (оцениваем сразу пару ответов).

Такие итерации можно повторять многократно, что является отдельным гиперпараметром. Крутое приложение метода: прокачивать модели на математике, коде и всем остальном, где результат можно четко измерить без специальной Reward модели, вот пример похожей работы для gsm8k и math.

В процессе финального тюнинга модели часто в том или ином виде используется фидбек человека. Условно для очень популярного DPO нам нужны пары (y1, y2), где явно указано, что один из ответов лучше другого. Чтобы собрать такой датасет, можно использовать разметчиков или другие модели, которые будут выступать в роли критиков (RM, LLM as a judge) и оценивать предложенные пары. В обоих случаях есть свои подводные камни (например, position bias, когда модель склонна отдавать предпочтение первому ответу), но решение с использованием модели-критика открывает пространство для универсального сбора большого кол-ва данных

В начале мая вышла интересная работа Prometheus-2 (модель + датасет) с лицензией Apache2.0. Авторы обучили две независимые модели под pointwise (оцениваем один ответ от 1 до 10) и pairwise (выбираем победителя из пары) задачи, причем не просто выдавая число, а генерируя до этого feedback как объяснение ответа. Такой прием улучшает общее качество, так как модель генерирует цепочку рассуждений, на которую потом может посмотреть прежде чем дать финальный ответ, по сути смысл как в Chain of Thought

Далее две модели объединяются в одну просто с помощью взвешивания их весов: w = a * w_pointiwse + (1-a) * w_pairwise. Пробовали и другие методы, но самый простой дал лучшие результаты. Подробнее про model merging можно почитать пост на HF. В результате получилась довольная высокая корреляция с человеческой оценкой и моделями GPT4/Claude3. Попробовал модельку для оценки пар в новом соревновании на kaggle по обучению RM для lmsys chatbot arena, и на глаз результаты выглядят неплохо. Правда такую модель по крайней мере в исходном формате применить не получится, тк просто не уложиться в ограничение времени на инференс 😕️️