После длительного отпуска врываемся обратно в плотный график 😊

В LLM происходит сейчас так много вещей, что эксперименты можно встретить в любом направлении. Недавно выходила модель SOLAR, где авторы увеличивали размер обученного трансформера, дублируя некоторые блоки, и модель становилась лучше. Параллельно с этим выпускаются работы в противоположном направлении, где вырезание слоев полностью сохраняет качество и позволяет таким образом прунить модели. В качестве примера - недавняя работа The Unreasonable Ineffectiveness of the Deeper Layers. Авторы смотрят на расстояние между входом и выходом, пройденного через n слоев, и, если оно небольшое, вырезают эти слои. Интуиция здесь такая, что маленькое расстояние означает, что эмбеддинг не сильно изменился за прошедшие преобразования. На практике получается, что слои-кандидаты на прунинг лежат ближе к концу модели, что кажется логичным: сначала модель сильно меняет эмбеддинги и со временем просто корректирует их для финального предсказания.

После вырезания слоев проводится процедура healing — QLoRA тюнинг на датасете C4 (сотни миллионов токенов). Такая корректировка весов позволяет выкидывать еще больше слоев без потери качества. Из замеров — MMLU и BoolQ, в обеих задачах авторы смогли выкинуть ~30% слоев LLaMA 2 70B, сохранив accuracy.

Теперь нужно объединить направления: взять 130B модель, запрунить до 70B и потом расширить опять до исходного размера, получив модель лучше 🧠

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

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 - гиперпараметр, контролирующий влияние кол-во хайлайтов.

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

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