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. Парень с таким подходом и взял первое место. Логика следующая:

6. Бьем весь трейн на 5 фолдов.
7. Тренируем на фолдах Llama3-70B и Qwen2-72B и размечаем весь датасет их предиктами.
8. Опять же на фолдах дистиллируем предикты больших моделей в gemma2, используя самый простой KL loss. Учим только LoRA адаптеры и в итоге получаем 5 моделей.
9. Усредняем веса всех адаптеров и получаем с помощью такого model merging финальную модель.
10. На все про все — А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.
- После тюнинга обобщающая способность модели падает: модель начинает хуже работать вне того распределения, на котором тюнили.

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

Telegram

Авторский ИИ

Dr. Борис invites you to add the folder “Авторский ИИ”, which includes 30 chats.

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

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

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

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

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

Какое-то время назад активно ходили слухи про проект Q от OpenAI. На сегодняшний момент известно мало, но высок шанс, что фокус в нем идет на reasoning, то есть умение планировать, строить цепочку рассуждений и декомпозировать сложные задачи. Это одна из важнейших проблем для текущих моделей, поэтому многие ее исследуют. На днях попалась статья от авторов из FAIR по их работе в сторону адаптации и улучшения алгоритма A для трансформеров. Для тех, кто не слышал про сам алгоритм:

1. Это модификация алгоритма Дейкстры, которая уходит от равномерного исследования в графа (с поправкой на веса ребер) в сторону проверки наиболее “перспективных” решений.
2. Огромное число задач может быть решено с помощью A*, начиная от классического поиска маршрута между двумя городами, до сборки кубика Рубика.
3. Рекомендую наглядное короткое видео с пояснениями и даже имплементацией для интересующихся. Для понимания можно посмотреть первые 10 минут.

Итак, авторы статьи сначала переводят траектории А для некоторой задачи в определенный формат, чтобы это можно было подать на вход как текстовую последовательность для нашей любимой задачи next token prediction. То есть в некотором смысле это попытка дистиллировать алгоритм в веса модели за счет тюнинга на собранный датасет (описание задачи, план, решение). Далее модель генерирует набор новых траекторий, некоторые из которых могут получиться даже лучше оригинального A, то есть быстрее решать проблему. Та часть, которая не решает задачу, выкидывается, и датасет пополняется полезной синтетикой. Такой прием в виде итеративного улучшения за счет генерации новых данных текущей моделью встречается далеко не в первый раз, вот, например, интересная работа про метод Self-Play. Модели при этом небольшие, до 757М параметров, архитектуры T5, то есть Encoder-Decoder.

В статье довольно насыщенный ablation study, но мне не хватило в табличке сравнения популярных существующих методов по типу MCTS и какой-нибудь GPT-4 с few-shot примерами.

И раз зашла речь про reasoning, на kaggle вчера объявили о новом конкурсе про решение математических олимпиадных задач с помощью LLM, следим ?

Прокатилась новость про то, как исследователи из Гугл придумали способ выяснить веса последнего слоя и внутренний размер эмбеддингов у моделей, доступных ТОЛЬКО по апи (например, ChatGPT). Стало очень интересно, а как в принципе такое возможно, поэтому сегодня попытаюсь базово объяснить на самом простом примере: как достать размер эмбеддинга h, имея на руках значения логитов для ВСЕХ токенов из словаря. Понятно, на практике мы имеем доступ (и то не всегда) к топ-к логитам, но для простоты и интуиции лучше начать с простого. Для обзора всех методов (даже для случая, когда логитов вообще нет), нужно писать отдельный лонгрид.

Итак, алгоритм действий такой:

1. Создаем матрицу n на l, где l — размер словаря, а n — число, большее h. Мы его не знаем, но можем примерно предположить и вообще хоть взять 100_000. Но чем больше этого число, тем больше запросов нужно будет сделать в апи ⇒ весь процесс выйдет дороже.
2. n раз семплируем рандомный промпт, получаем логиты и заполняем нашу матрицу.
3. С помощью какого-нибудь алгоритма (например, SVD) находим сингулярные числа матрицы λ_i.
4. Размер эмбеддинга определим как argmax_i(λ_i/λ_{i+1}).

Выглядит это довольно странным, и если возникает вопрос, почему мы вообще используем такую формулу, это нормально. Давайте опишу процесс в моем понимании (объяснение сильно грубое, в статье есть много допущений, которые тем не менее работают на практике).

1. Несмотря на то что каждый вектор логитов состоит из l чисел, все они лежат в пространстве размерности h и затем преобразуются линейной проекцией.
2. Соответсвенно, запрашивая результаты модели достаточное число раз (бОльшее h), мы будем получать новые векторы логитов, линейно зависимые от предыдущих.
3. Теперь можно сказать, что нам достаточно найти ранг матрицы, который мы и возьмем в качестве предсказания размера эмбеддинга. А ранг матрицы — это кол-во ее сингулярных чисел. Но тк значения матрицы не целочисленные, а fp16 или вообще fp8, то такое определение нам не подойдет. Именно поэтому мы находим ту точку, в которой происходит максимальный скачок до очень маленьких значений сингулярных чисел — ненулевыми они получились из-за погрешности измерений.

На основе SVD разложения, алгоритм развивается дальше, вплоть до нахождения именно весов в слое. Также в статье есть предложения о том, как противостоять подобным атакам, рекомендую почитать подробнее, если заинтересовала тема.

Дошли наконец руки разобрать давно отложенную статью про агентов: V-IRL: Grounding Virtual Intelligence in Real Life, уж очень мне нравится идея объединения различных модулей (например, LLM + Vision Model + Tools + Memory) ради решения сложных многоэтапных задач. На этот раз авторы предложили некоторый фреймворк для построения агентов, которые передвигаются в сеттинге реального мира. То есть агентам доступны апи по гео данным, гугл карты (включая визуальное передвижение по улицам), всякие апи по отзывам на заведения и так далее, то есть практически все, что есть у нас для навигации по городу. А задачи им даются в виде: “Предложи мне оптимальный маршрут в Нью-Йорке, учитывая мои пожелания A, B и ограничения в X долларов” или “Нанеси информацию о пожарных гидрантах в парке на карту”. Для последнего задания агент дает задание другому роботу-агенту сначала проехать по парку и передать данные об обнаруженных гидрантах. Также агенты могут выполнять свои задачи параллельно и если так оказалось, что один уже знает то, что нужно другому, то он этой информацией может поделиться и помочь.

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

Техническая конфигурация стандартная: гугл карты + всякие разные апи для информации о местанахождении/отзывах/маршрутах и так далее, BLIP-2 (Flan T5 XXL) в качестве Visual Question Answering Model, LLM (GPT-4/Llama2) в качестве главного процессора, то есть обработки любой текстовой информации + ризонинг. Например, LLM посылает запрос в гугл карты, получает изображение с улицы, обращается в BLIP для обнаружения гидранта, обрабатывает результат и сохраняет информацию. Но интересно здесь то, как все сплелось в единую платформу по решению задач из реального мира. А теперь представьте, если прикрутить сюда Sora и сидеть наблюдать за агентами в рамках целого набора видео. Может этим и занимаются сейчас в FigureAI? ?