Неделю назад закончилось соревнование 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% участников не получили никакого места на лидерборде, тк все их решения упали по таймауту 🤯

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

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