Привет, меня зовут Андрей Бут, я представляю команду разработки YandexGPT. Сегодня мы анонсируем новое поколение наших больших языковых моделей — YandexGPT 5.

Старшая модель — YandexGPT 5 Pro — уже применяется в чате с Алисой, а также доступна в Yandex Cloud через API. Кроме того, в чате с Алисой впервые можно переключиться на базовую версию модели, которая не использует внешнюю информацию из Поиска и не дообучалась «быть» виртуальным ассистентом.

Pretrain-версия младшей модели — YandexGPT 5 Lite Pretrain — опубликована в свободном доступе и будет полезна разработчикам, которые дообучают базовые версии моделей под свои задачи. Дообученная нами на её основе instruct-версия в ближайшее время станет доступна через API. 

Под катом — более подробно о том, как мы обучали наши модели и какой опыт накопили.

YandexGPT 5 Lite 8B Pretrain

Сегодня мы рады поделиться с сообществом pretrain-версией модели YandexGPT 5 Lite на 8B параметров с длиной контекста 32k токенов. Она уже опубликована на Hugging Face. 

Претрейн модели проходил в два этапа. На первом этапе модель инициализировалась случайными весами, т. е. без использования весов каких-либо других моделей, и обучалась преимущественно на русскоязычных и англоязычных текстах общим объёмом 15T токенов. На втором этапе, который мы назвали Powerup, модель обучалась на высококачественных данных объёмом 320B токенов. Более подробно о них поговорим ниже. 

В своей категории модель достигает паритета с мировыми SOTA по ряду ключевых бенчмарков для pretrain-моделей, а по многим другим — превосходит их:

Первый этап обучения

Один из ключевых компонентов при создании LLM — данные для обучения. В нашем корпусе около 30% токенов приходится на русскоязычные тексты. Бо́льшая часть оставшихся — английские. Структура нашего датасета может показаться вам знакомой: ≈60% — веб-документы, 15% — код, 10% — математика, остальное — специфичные данные, про которые расскажем ниже.

Исторически для отбора документов в претрейне мы используем признаки, которые полезны для ранжирования поисковой выдачи. Например, вероятность принадлежности к спаму и популярность страниц.

Недавно мы пересмотрели наш подход к сбору данных: так как наши классификаторы имеют несовершенства и отбрасывают часть полезных данных. Мы постарались убрать слишком грубые фильтрации и тем самым существенно повысили полноту знаний и, соответственно, размер датасета до 15T токенов. Так мы увеличили долю отбираемых английских веб-данных. Например, в одном из основных компонентов нашего датасета доля английского увеличилась с 14 до 30%.

Для отбора данных мы используем как классические эвристики, такие как Repetition NGrams (привет из 2021-го), так и классификаторы качества документов, обучаемые на человеческой или LLM-разметке. В предыдущих версиях наших моделей мы использовали классификаторы для фильтрации документов. В этой версии мы обучили набор моделей для оценки различных критериев документа. Примеры: насколько документ образовательный; содержит ли документ математические рассуждения и т. д. Сейчас мы используем набор правил по классификаторам для дополнительного отбора полезных документов.

Выше мы говорили про некоторые специфичные данные. Здесь хочется выделить два ключевых внедрения.

Во-первых, мы постепенно разрабатываем собственный пайплайн синтетики: на основе проверенных источников мы с помощью YandexGPT 4 генерируем вопросы — как открытые, так и с вариантами ответа — и добавляем их в претрейн. Похожими пайплайнами пользуются, например, в Phi-4.

Во-вторых, активно используем внутренние наработки. Так, в поиске Яндекса давно используется база Fact Snippet для построения быстрого ответа пользователю. Такие данные мы тоже докладываем в претрейн. Ещё один пример — новый корпус данных Переводчика.

В качестве эксперимента мы внедрили переписывание части веб-документов. Упрощённо эту работу можно объяснить так: пишем промпт в YandexGPT 4 с пожеланием переписать веб-документ, удалив всё ненужное со страницы.

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

Математика
Для сбора математических данных мы пользуемся подходом, похожим на предложенный в DeepSeekMath. Для первоначальной разметки на «математичность» используется модель из семейства YandexGPT 4. Далее мы дообучаем поверх результатов разметки небольшую (180M) LM и размечаем ей бо́льшую часть имеющихся у нас документов, после чего дополняем потенциально полезными источниками обучающую выборку.

Такой подход широко распространён (Qwen-2.5-Math, FineMath), но мы улучшаем его за счёт использования кастомного парсера, сохраняющего структуру математических документов, например, извлекающего формулы из MathJax и удаляющего нерелевантный контент.

Кастомный парсинг применяется также для PDF-части корпуса: мы пользуемся собственным пайплайном OCR для тех PDF, где извлечение текста затруднительно, например, для математических и научных документов, которые изобилуют формулами.

Код
Для сбора корпуса кодовых веб-данных используется тот же подход, что и для математики. Другой вопрос — как оценивать качество кода, а не текстовых документов? На этапе претрейна мы пользуемся эвристиками, похожими на предложенные в работе OpenCoder. Пример такой эвристики — доля pass, assert, import в файле на языке Python.

Что интересно — мы попробовали проверить гипотезу, что код помогает обычным knowledge-бенчмаркам. На экспериментальной модели получился следующий эффект от замены 15/30% датасета с вырезанным из него кодом на starcoder:

Эффект падения обычных бенчмарков на проверку знаний рассуждений изучался в работе To Code, or Not To Code, где обнаружили, что оптимальная доля кода выше нуля — так как растёт навык в рассуждениях (например, в статье используется PIQA и не только). Это не до конца согласуется с нашим экспериментом: когда мы почистили код, падение стало меньше, но именно роста мы не обнаружили. Конечно, тут может играть роль и то, что используемые датасеты — как базовый, так и кода — отличаются от статьи. В любом случае собрать такой датасет с кодом, который будет растить качество не только кода, — наше стремление и одно из направлений будущей работы.

Второй этап обучения — Powerup

После обучения базового претрейна мы проводим Powerup — дообучение на данных более высокого качества. Состав Powerup-датасета: 25% — веб-страницы, 19% — математика, 18% — код, 18% — образовательные данные, остальное — аугментации фактовых документов, вдохновлённые физикой моделей, другая синтетика, датасеты сервисов и прочие качественные тексты. В качестве регуляризации мы сохраняем 40% распределения исходного датасета, чтобы побороть катастрофическое забывание.

На этом же этапе мы проводим расширение контекста до 32k токенов с помощью NTK-aware scaling с добавлением 5% дополнительных длинных (длина контекста > 8k) документов.

Powerup хорошо растит метрики базовой модели:

YandexGPT 5 Pro

Теперь поговорим о другой нашей модели.

Наш обычный пайплайн обучения выглядит примерно так: Pretrain из нескольких шагов и Alignment (SFT, RL разными способами). Чтобы обучить новую версию модели, которая работает существенно лучше, чем старая, требуется пройти через множество проб и неудач. И каждый такой эксперимент с большой, многомиллиардной моделью может длиться по несколько недель. Это очень много времени и ресурсов. Поэтому мы стали думать, как нам сократить подбор оптимальной конфигурации и сэкономить ресурсы. Нашли сразу несколько решений: как на уровне Pretrain, так и на уровне Alignment.

Что изменили в Pretrain

Модели никогда не обучаются с нуля. Даже если вы инициализируете обучение на случайных весах, у вас уйдёт множество циклов экспериментов и проб на то, чтобы подобрать оптимальную конфигурацию и — наконец-то! — обучить модель, которую вы сможете встроить в свой продукт или показать миру. Каждая новая попытка опирается на результаты длинного хвоста всех предыдущих опытов. И у нас, и в других компаниях уходят месяцы попыток на каждый значимый скачок в качестве. Неудивительно, что вся индустрия ищет возможности для ускорения этого процесса и экономии затрачиваемых ресурсов. Регулярно появляются новые методы оптимизации, предлагаются те или иные лайфхаки, внедряются новые алгоритмы, например YaFSDP.

В области опенсорсных LLM всё развивается не менее стремительно. Мы регулярно тестируем их, сравниваем с нашими решениями. Раньше при сравнении наших и опенсорс-моделей сопоставимого размера мы были в паритете или проигрывали на англоязычных бенчмарках, но на русскоязычных SbS-сравнениях на потоке реальных пользовательских задач мы преимущественно побеждали. И это логично: модели лучше раскрываются на тех же языках, знаниях и задачах, которые приоритетны в процессе обучения. И даже дообучение (SFT) опенсорсной модели на своих данных не меняет ситуацию в корне. А ещё у изначально английской (или китайской) модели будет неоптимальный словарь токенов для русского языка, а значит, она может требовать значительно больше вычислительных ресурсов при одной и той же длине контекста в сравнении с базовой русскоязычной моделью. Ещё спецэффекты чужих instruct-версий могут стрелять в ответах на ваши задачи совершенно непредсказуемым образом. И главное — для качественного понимания русского языка и локальных особенностей короткого SFT-дообучения просто мало. Требуется полноценное длительное обучение на большом корпусе качественных русскоязычных данных.

Но что, если использовать опенсорс иначе? Что, если взять обычный, полный цикл обучения модели, который включает в себя многоэтапные Pretrain, SFT, RL и в котором мы уже накопили большой опыт, а затем добавить к нему ещё одну составляющую — веса общедоступной модели? Так мы и сделали: инициализировали наш пайплайн обучения не случайными весами, а весами модели Qwen-2.5-32B-base (именно base, потому что instruct-версия показала результаты хуже). 

Чем больше токенов нашего претрейна мы использовали в обучении, тем выше были результаты модели в бенчмарках. Особенно — на знание русского языка, культуры и т. д. Более подробно о том, как мы измеряем знание культурного кода, уже писали в отдельной статье.

Чуть выше мы уже говорили о важности словаря токенов. Наглядное подтверждение этого: для русскоязычных текстов 32k токенов контекста YandexGPT 5 Pro соответствуют 48k токенов модели Qwen-2.5-32B-base.   

Совмещение весов из общедоступной модели и нашего обычного полного цикла обучения позволило нам сократить длительность экспериментов до 20 раз и сэкономить ресурсы на подбор оптимальных параметров. На создание YandexGPT 5 Pro по-прежнему ушли месяцы работы, но за это время нам удалось проверить существенно больше гипотез и датасетов. И что самое приятное: накопленный нами опыт применим и для классического обучения без использования весов открытых моделей.

Что изменили в Alignment

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

Процесс Alignment включает в себя несколько стадий. На первой стадии, которая называется SFT (Supervised Fine-Tuning), модель обучается на парах «запрос — ответ». На следующей стадии RLHF модель обучается выдавать более качественные ответы на запросы, изучая предпочтения пользователей с помощью набора преференс-пар, в которых один ответ может быть лучше другого.

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

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

1. Много заданий в одном запросе.

2. Длинный вход, короткий ответ. Модели для генерации адекватного ответа просто не хватает токенов.

3. Сложные требования к формату ответа.

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

Первая идея вдохновлена статьёй Instruction Following Difficulty, суть которой проста:

Рассмотрим лосс:

Фактически мы оцениваем способность модели генерировать подходящие ответы на основе предоставленных инструкций. Отдельно можно рассмотреть сложность следования инструкции:

Отношение этих метрик и предлагается использовать для оценки сложности следования инструкциям:

Полученный скор/оценку мы использовали для фильтрации данных.

Вторая идея — про специальное тегирование данных. Несмотря на то что мы старались использовать качественные данные, по определённым признакам они всё ещё могут иметь проблемы (вред, ложь, полезность ответа и т. д.). При этом наши эксперименты показали, что убирать их из обучения строго хуже, поэтому для таких данных мы ввели отдельный тег, чтобы «подсветить» модели возможные проблемы при обучении на них (на этапе инференса этот тег не нужен). Такой подход дал рост в качестве по SbS-оценке.

В контексте обучения с подкреплением не утихает холивар о том, что эффективнее: онлайн RL или офлайн. Мы стараемся использовать лучшее из двух миров и комбинируем разные подходы к RL, что позволяет растить качество.

После публикации статьи про DPO многие разработчики и компании решили пересесть именно на него, потому что он прост в использовании и не так требователен к гиперпараметрам, как PPO. Однако с DPO не всё так гладко. 

Посмотрим на графики.

На наших данных DPO-модель стала «разучиваться» генерировать и хорошие, и плохие примеры из датасета. Дело в том, что не все пары оказались одинаково полезны. Что занятно — в зависимости от количества дублей в вашем датасете вы можете получить абсолютно разный результат. Например, полные дубли лучше фильтровать, а вот частичные стоит оставлять. Когда у вас один и тот же инстракт и разные ответы, это даже полезно.

Ещё надо упомянуть регуляризацию. В свежих работах можно найти всё больше указаний на то, что DPO обучается нестабильно, и наша практика это подтверждает. А вот если добавить NLL loss, то обучение станет более робастным. 

Мы пошли дальше и сделали свою модификацию DPO, которую назвали LogDPO. Перед тем как выписать новый лосс, давайте сначала поймём, откуда в DPO берётся проблема «разучивания». Вообще существует несколько механизмов, из-за которых может происходить «разучивание», и ещё больше гипотез, как именно лосс DPO их активирует. Мы ограничимся лишь тем наблюдением, что каждый раз в этой проблеме виновата часть лосса DPO, отвечающая за вероятность менее предпочтительного ответа в ранжированной паре.

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

Решить эту проблему можно многими способами, мы избрали следующий:

Тут мы добавляем экспоненту в лосс DPO для того, чтобы за счёт уменьшения одной лишь вероятности менее предпочтительного ответа нельзя было достигнуть оптимума.

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

На самом деле вместо экспоненты можно использовать любую монотонную функцию с затухающим градиентом на (для ограничения влияния «разучивания» менее предпочтительного ответа). Наши эксперименты, однако, показывают, что именно экспонента даёт лучший результат (хотя, скажем, версия с softplus вместо экспоненты имеет намного меньшую дисперсию градиентов).

Last but not least — онлайн RL. Мы очень долго поднимали у себя PPO для YandexGPT, но все наши мучения были вознаграждены. Во время наших попыток мы выявили ряд интересных нюансов.

1. Использование advantage normalization очень важно. 

2. Потокенный KL-штраф за отклонение от SFT-модели. Важно: во многих работах используется оценка Монте-Карло по одному токену, а мы выбрали именно честно посчитанный KL, и результаты получились куда лучше.

3. Добавлять KL-штраф за отклонение от SFT-модели не к награде, а прямиком к лоссу. Этот трюк был предложен в GRPO, это упрощает оптимизацию, даёт рост качества. 

4. Использование более одной эпохи PPO. При обучении модели можно для уже сгенерированных текстов сделать не один шаг градиентного спуска, а два. Это тоже хорошо скажется на качестве обучения. 

5. Всё чаще советуют использовать большой батч. Есть одна тонкость. Мы заметили, что иногда полезнее не увеличивать число разных запросов в батче, а вместо этого генерировать несколько разных ответов на один промпт (4–8 показывают себя хорошо).

6. Много эпох. PPO хорошо раскрывается, когда видел датасет много раз — награда растёт и на валидации, и на обучении, классического переобучения мы не наблюдаем практически никогда. Важно лишь остановиться до того, как произойдёт классический гудхартинг — когда высокая награда за ответы перестанет коррелировать с высокой оценкой асессоров. Обучение на 6–8 эпох показывает неплохие результаты.

Бенчмарки и SbS

По результатам внутреннего слепого попарного сравнения (side-by-side) для широкого потока запросов YandexGPT 5 Pro превосходит YandexGPT 4 Pro в 67% случаев и не уступает GPT-4o.

С большинством типовых задач и выполнением стандартизированных тестов (бенчмарков) YandexGPT 5 Pro справляется на уровне аналогичных по мощности моделей — лидеров рынка, а в некоторых категориях превосходит их.

Несколько слов о том, почему в этом списке отсутствует LLM Arena. Пользователи Арены — это разработчики, энтузиасты в ИИ и технические специалисты. Их запросы сильно смещены по тематике в сторону IT, кода, задач на логику и житейских вопросов. Среди всех запросов доминирует формат «вопрос — ответ» на оценку знаний модели. Да ещё и сами оценки тоже могут быть смещены в сторону более длинных, форматированных текстов. В результате оценка по рейтингу Арены является не самым лучшим способом предсказывать, насколько модель будет полезна в рамках задач бизнес-пользователей. Так, например, если модель используется для автоматизации работы службы поддержки, то нужно тестировать её на способность написать корректный ответ на основе информации из базы знаний саппорта. Причём сделать его таким, чтобы он проходил по критериям качества службы контроля поддержки. В рамках подобных, ориентированных на практическое применение задач качество ответа модели оценивается не просто по тому, насколько он нравится человеку, а по тому, насколько корректно он решил поставленную задачу. Чуть подробнее мы уже рассказывали об этом в отдельной статье.

Как попробовать YandexGPT 5 Pro

Традиционно наша новая мощная модель доступна пользователям Yandex Cloud через API. Также её можно использовать для создания ассистентов с RAG через AI Assistant API или во few-shot классификаторе. 

Кроме того, впервые в чате с Алисой появился выбор модели. Можно общаться как с моделью, которая дообучена «быть» Алисой и умеет обращаться в Поиск за информацией, так и с исходной моделью YandexGPT 5 Pro. Этот выбор уже доступен на alice.yandex.ru с опцией Про и скоро появится в приложении «Алиса».

Мы будем продолжать добавлять в чат с Алисой новые модели, чтобы пользователи могли их протестировать. В ближайшее время в чате появится ещё одна языковая модель нового семейства, попробовать которую можно будет в чистом виде, без возможностей ассистента.

Заключение

Сегодня мы впервые за три года опубликовали нашу модель в свободном доступе. На сегодняшний день YandexGPT 5 Lite 8B Pretrain в ряде ключевых для нас англоязычных и русскоязычных бенчмарков опережает сопоставимые base-версии моделей Llama и Qwen. Наша модель будет полезна тем разработчикам, у которых есть потребность в дообучении небольшой, изначально русскоязычной модели под свои задачи.

Наша мощная модель нового поколения — YandexGPT 5 Pro — уже используется в чате с Алисой и доступна для внедрения через API в Yandex Cloud. Существенный буст в качестве её ответов обусловлен большим количеством изменений в процессе обучения: например, мы пересобрали датасет для претрейна, добавили веса опенсорс-модели, предложили свою модификацию метода DPO — LogDPO — для преодоления проблемы «разучивания» и перепробовали множество других оптимизаций в течение нескольких месяцев активной разработки. 

На этой конфигурации мы не остановимся. Наша цель — как можно быстрее и экономичнее создавать всё более полезные решения для наших пользователей и партнёров. Поэтому мы продолжаем экспериментировать с добавлением в «котёл» обучения наших моделей разнообразных компонентов, в том числе опенсорсных, будем пробовать и другие методы, идеи и хаки. В том числе — в направлении «рассуждающих» моделей. При этом мы, конечно же, будем и дальше делиться опытом со всем сообществом.