Сегодня мы открываем веса нашей новой модели AliceAI‑Foundation-80B‑A3B‑Base под лицензией Apache 2.0. Модель прошла полный цикл обучения в Яндексе с нуля: мы не использовали веса сторонних опенсорс‑моделей. Её создание — ещё один шаг к нашей единой рассуждающей модели (ЕРМ), на базе которой будут развиваться агентские возможности Алисы AI.

В претрейн‑замерах новая модель обходит более крупные DeepSeek‑V4-Flash‑Base и Nemotron-3-Super на многих задачах — от фактологических и экспертных вопросов до математики и кода, — а на сложных задачах IMO AnswerBench и LiveCodeBench лидирует среди сравниваемых открытых претрейнов. Нашу предыдущую закрытую Alice AI LLM 235B она превосходит по фактологическим знаниям, математике, программированию и работе с длинным контекстом — при почти втрое меньшем общем числе параметров и примерно в семь раз меньшем числе активных.

Недавно наши коллеги открыли претрейн Alice AI Search (кстати, он тоже обучен без применения весов опенсорс‑моделей) и рассказали, как устроена модель быстрых ответов Алисы на Поиске. Сегодня мы подхватим у них эстафетную палочку и расскажем о большом обновлении датасета, который лежал в основе обучения обеих моделей.

Также продолжим историю из декабрьского техрепорта Alice AI LLM. Тогда обучение начиналось с весов Qwen3-235B‑A22B, но в этот раз мы обучали модель полностью с нуля. Благодаря накопленному командой опыту весь путь к релизу этой модели занял около полугода. За это время мы пересобрали корпус, перебрали архитектурные решения, подобрали гиперпараметры и добавили данные для рассуждений и агентских взаимодействий.

За итоговыми скорами стоит много экспериментов, и нам хочется рассказать о них подробно. Поэтому вместе с весами мы публикуем большой технический отчёт: от пайплайнов подготовки данных и протоколов оценки до стабилизации обучения и scaling laws. Для ключевых решений приводим абляционные эксперименты и разбираем подходы, от которых пришлось отказаться. Вклад обновлённого корпуса, архитектуры и гиперпараметров проверили в серии обучений с нуля — по 2 трлн токенов каждое.

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

Некоторые результаты оказались неожиданными. Loss на отложенной части корпуса плохо предсказывал, какая модель будет сильнее на целевых бенчмарках. После пересчёта гиперпараметров по scaling laws обучение «взорвалось»: MoE‑активации начали расти, а затем резко подскочил loss. Пришлось разбираться, ошиблись ли мы с прогнозом или новые гиперпараметры выявили проблему в процессе обучения. Рецепт аугментаций, который помогал при инициализации из опенсорс‑моделей, пришлось переработать для более длинного претрейна. А обучения сложным рассуждениям оказалось недостаточно для агентских навыков: добавление взаимодействий с инструментами уже в претрейн улучшило агентские бенчмарки после посттрейна.

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

Приятного погружения! И осторожно: длительное чтение отчёта может вызвать любовь к обучению и оценке претрейнов.

---

Содержание

1. Основные результаты

   1. Знания и базовые навыки

   2. Ризонинг-претрейн-бенчмарки

   3. Где попробовать

2. Как мы оцениваем модель 

   1. Общий протокол

   2. Как мы измеряем фактологические знания 

      1. WikiWebFacts 

      2. HardMultiQA

   3. Образовательные и экспертные бенчмарки

      1. Образовательные бенчмарки

      2. Экспертные бенчмарки

   4. Reasoning-бенчмарки

      1. Общие академические и кодовые бенчмарки

      2. Как мы замеряем ризонинг в претрейне

   5. Бенчмарки длинного контекста 

   6. Агентские бенчмарки

3. Что и как мы обучали

4. Как мы выбрали архитектуру и сетап обучения

   1. Абляции ключевых изменений

   2. Архитектура и стабилизация обучения

      1. Стабилизация MoE-активаций

         1. Проверка гипотезы о роутинге и ограничение SwiGLU

         2. Gated RMSNorm

         3. Выбор Z-Loss

      2. Muon 

      3. Kimi Delta Attention

      4. Attention Residuals

   3. Scaling laws

      1. Метод 

      2. Подбор датасета для расчёта loss-функции

      3. Стабилизация активаций

5. Общий general-pretrain корпус

   1. Состав корпуса

   2. Веб

   3. Длинный контекст

   4. Математические данные

   5. Кодовые данные

6. Как мы научились строить данные для отдельных доменов

   1. Важность фактологического домена

   2. Аналитика корпуса для фактов

   3. Пайплайн сбора фактологического корпуса

   4. Аугментации фактологических документов

   5. Что мы выяснили об обучении на QA

      1. Эффект семантически неоднозначных примеров

      2. Эффект шаблонного формата ответов

      3. Эффект аугментаций

   6. Общий рецепт работы с доменом

   7. Экспертные области

      1. Юридические данные

      2. Медицинские данные

   8. Перенос на математические данные

      1. Сбор исходных документов

      2. Аугментации математического веба

   9. Перенос на кодовый веб

   10. Перенос на STEM-веб

7. Как мы добавили reasoning и агентские способности

   1. Зачем нужна отдельная reasoning-стадия

   2. Reasoning-трейсы

      1. Математика

      2. Код

   3. Почему только ризонинга недостаточно для агентов

   4. Агентские данные

      1. CRUD-сценарии

      2. Поисковые вопросы

      3. SWE

8. Какой формат данных использовать для дообучения нашей модели

9. Команда

---

1. Основные результаты

Ниже сравниваем нашу модель с открытыми претрейнами Qwen3.5–35B‑A3B‑Base, GLM-4.5-Air‑Base (106B‑A12B), Nemotron-3-Super-120B‑A12B‑Base и DeepSeek‑V4-Flash‑Base (284B-13B), а также с нашей предыдущей Alice AI LLM 235B Base релиза октября 2025 года. Мы сравниваем свой претрейн со всеми доступными претрейн‑моделями такого же класса, показывающими сильные результаты. Тем не менее у нашей модели меньше общих и активных параметров, чем у всех участников сравнения, кроме Qwen: у него меньше общих параметров и столько же активных. Все результаты нашей модели получены на финальном чекпоинте после reasoning‑стадии претрейна. Агентские навыки проверяем отдельно после SFT — об этом рассказываем в разделе 7.1.

Мы используем и привычные бенчмарки на факты, образование, математику, код и длинный контекст, и более сложные математические и кодовые задачи. Для последних используем метрики pass@k: они показывают, способна ли модель найти правильное решение хотя бы в одной из k попыток. Полную методологию оценки подробно описываем в разделе 2. Здесь приводим результаты и основные выводы по каждой группе задач.

1.1 Знания и базовые навыки

Все замеры в этом разделе проведены во внутренней инфраструктуре замеров. Инференс в фреймворке vLLM с temperature = 0 для всех моделей. Жирным выделен победитель в каждой строке, подчёркиванием — второе место.

_{Таблица 1}

Наша модель занимает первое место на 8 из 10 бенчмарков фактологических знаний, образования и экспертных навыков, хотя все участники сравнения, кроме Qwen, крупнее неё. Особенно хорошо она справляется с задачами о российской культуре, русском языке, литературе, истории, медицине и праве. На экзаменационных бенчмарках результаты сопоставимы с результатами сильных открытых моделей, а на MATH-500, университетской математике и LiveCodeBench модель показывает лучшие скоры в сравнении. В работе с длинным контекстом модель также близка к лидерам: делит первое место с DeepSeek на FinQA 128K и отстаёт от занимающего второе место Nemotron всего на 0,2 п. п. на LongMemEval.

1.2 Ризонинг-претрейн-бенчмарки

Дополнительно мы сравниваем претрейн‑модели на сложных задачах, требующих длительных рассуждений. DeepSeek‑V4-Flash‑Base не включён в эту таблицу: в наших экспериментах с разными настройками замера его результаты оставались близкими к нулю.

Все замеры в этом разделе проведены во внутренней инфраструктуре замеров. Инференс для всех моделей выполнялся с использованием фреймворка vLLM при temperature = 1 и с параметрами штрафов за повторы repetition_penalty = 1, presence_penalty = 1,5. Жирным выделен победитель в каждой строке.

_{Таблица 2}

Отдельно отметим результаты на сложных математических и кодовых задачах: наша модель лидирует на IMO AnswerBench, HMMT и LiveCodeBench и делит первое место на AIME.

1.3 Где попробовать

Финальный чекпойнт нашей претрейн‑модели можно найти на Hugging Face.

2. Как мы оцениваем модель

Рассказывает Ира Ляликова @lialikova-ia

2.1 Общий протокол

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

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

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

Важно не только выбрать хороший бенчмарк, но и правильно его замерить. Результат генеративных тестов может заметно зависеть от промпта, few‑shot‑примеров, настроек генерации и способа проверки ответа. Поэтому для новых бенчмарков мы отдельно проверяем, стабильно ли работает замер: смотрим, насколько оценки автоматической проверки совпадают с оценками людей, и проверяем, не меняются ли выводы при небольших изменениях настроек.

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

2.2 Как мы измеряем фактологические знания

Фактологические знания — одна из базовых способностей претрейн‑модели. Хорошая модель должна не только уметь рассуждать над предоставленным контекстом, но и обладать достаточно широкими знаниями о мире, людях, событиях, культуре, науке и повседневных предметных областях. В разделе 6 мы подробно расскажем об улучшениях нашего корпуса на срезе фактов, а здесь обсудим фактовые бенчмарки.

Для английского языка существует несколько широко используемых бенчмарков для оценки фактовых знаний, например TriviaQA, Natural Questions, WebQuestions и SimpleQA. Для русского языка таких открытых бенчмарков значительно меньше, при этом перевод англоязычных датасетов на русский не решает проблему. То, какие знания наиболее актуальны для пользователей, сильно зависит от страны и языка: особенно это заметно в вопросах про историю, географию и культуру. При переводе англоязычного бенчмарка эта специфика не учитывается.

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

2.2.1 WikiWebFacts

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

Первая часть датасета (Wiki) построена на основе статей русскоязычных онлайн‑энциклопедий. Вместо случайной выборки страниц мы использовали статьи, которые часто появляются в поисковой выдаче Яндекса. Такая процедура смещает распределение в сторону тематик, которые важны для пользователей, и уменьшает долю редких и малоизвестных фактов.

Из выбранных статей с помощью языковой модели извлекались факты и формировались пары «вопрос — ответ». После автоматической генерации примеры проходили проверку AI‑тренерами: проверялась корректность вопроса, однозначность ответа и соответствие исходному источнику.

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

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

Поскольку большая часть вопросов имеет короткий и однозначный ответ, этот бенчмарк допускает достаточно надёжную автоматическую проверку с помощью LLMaJ. Качество автоматической оценки проверили на 1000 ответах с помощью более крупной модели‑аудитора, существенно более дорогой в инференсе. Несколько итераций помогли сделать промпт однозначнее, а качество работы судьи в итоге превысило 95%. При оценке претрейн‑моделей мы используем 5-shot и жадную генерацию.

Ниже несколько примеров вопросов, которые вошли в финальный датасет.

_{Таблица 3}

Этот бенчмарк не является очень сложным для последних SOTA‑моделей. Его основная задача — давать стабильный и интерпретируемый сигнал при сравнении обучений с нуля, промежуточных чекпоинтов и моделей относительно небольшого размера. Для наиболее сильных современных моделей качество на нём начинает приближаться к насыщению. Кроме того, при наличии внешнего поиска большая часть вопросов становится существенно проще.

Датасет публикуется вместе с моделью и конфигом замера — на Hugging Face. Мы также публикуем отдельные протоколы для оценки претрейн‑ и инстракт‑моделей.

2.2.2 HardMultiQA

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

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

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

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

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

• вопросы с коротким однозначным ответом, аналогичные вопросам первого фактологического бенчмарка;

• задачи с несколькими вариантами ответа, среди которых правильными могут быть один или несколько;

• вопросы на перечисление нескольких сущностей или фактов;

• задачи на поиск фактологической ошибки в коротком тексте.

Формат с несколькими правильными вариантами делает multiple‑choice‑задачи сложнее: когда число правильных ответов заранее неизвестно, модель не может просто прийти к ответу методом исключения.

В заданиях на перечисление бывают два типа вопросов. В одних есть фиксированный набор правильных ответов — например, «назовите планеты Солнечной системы». Здесь важно назвать все варианты и не добавить лишних. В других достаточно перечислить ключевые ответы — например, назвать главных героев книги: второстепенных персонажей можно добавить сколько угодно, если основные названы.

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

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

Более разнообразный формат задач потребовал и более сложной системы автоматической проверки. Так же, как в бенчмарке WikiWebFacts, качество автоматической оценки каждого типа заданий HardMultiQA проверили с помощью более крупной модели‑аудитора. После нескольких итераций улучшений промптов они стали однозначнее, а качество работы судьи для каждого среза превысило 95%.

Ниже представлена диаграмма с разбивкой на тематики и типы вопросов.

Несколько примеров вопросов, которые вошли в финальный датасет:

_{Таблица 4}

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

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

На претрейн‑моделях основной результат мы считаем в 5-shot‑режиме с жадной генерацией.

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

Мы публикуем этот бенчмарк на Hugging Face вместе с моделью и предоставляем протоколы для оценки как претрейн‑, так и инстракт‑моделей.

2.3 Образовательные и экспертные бенчмарки

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

2.3.1 Образовательные бенчмарки

Образовательные запросы составляют важную часть пользовательских сценариев Алисы, поэтому качество модели на школьных и университетских задачах мы оцениваем отдельно. Для разработки этих бенчмарков мы собрали команду AI‑тренеров с профильной экспертизой по отдельным предметам.

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

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

2.3.2 Экспертные бенчмарки

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

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

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

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

После составления вопроса его независимо решает другой эксперт, который не видел авторский ответ. Если ответы экспертов расходятся, пример передаётся третьему эксперту: он разбирает причину расхождения и уточняет формулировку вопроса или эталонный ответ. Такой процесс оказался важен даже при работе с сильными профильными специалистами. Экспертные области сложны, а при ручном составлении вопросов остаётся человеческий фактор: исходная формулировка может допускать несколько трактовок, не содержать необходимых условий или неточно фиксировать правильный ответ. Итеративная проверка несколькими экспертами позволила исправить первоначальную разметку примерно в 20% примеров.

Сейчас таким образом мы собрали отдельные бенчмарки по медицине и юриспруденции.

2.4 Reasoning-бенчмарки

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

2.4.1 Общие академические и кодовые бенчмарки

Для оценки общих академических знаний и рассуждений мы используем несколько стандартных экзаменационных бенчмарков, например MMLU‑Pro и SuperGPQA. Последний особенно полезен за счёт более широкого покрытия предметных областей. Все эти бенчмарки мы замеряем в режиме фьюшотов с примерами рассуждений. Для русского языка мы дополнительно используем собственный экзаменационный бенчмарк, собранный на основе заданий части А ЕГЭ по нескольким предметам.

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

Для программирования мы используем бенчмарки BigCodeBench и LiveCodeBench. На более простых HumanEval и MBPP модели нашего размера уже показывают высокие результаты, а итоговый скор заметно зависит от способа замера (формат промпта, количество примеров во фьюшоте).

BigCodeBench проверяет более прикладное использование Python и требует работы с библиотеками. При работе с этим бенчмарком мы обнаружили, что часть встроенных тестов недостаточно качественно проверяет корректность решений. Падения тестов разбирали профильные IT‑эксперты, после чего для части задач исправляли или расширяли тесты, чтобы они лучше соответствовали ожидаемому поведению решения. LiveCodeBench мы используем как более сложный бенчмарк по программированию. Его задачи требуют сначала найти подход к решению, а затем реализовать его в коде, поэтому мы замеряем их с примерами рассуждений во фьюшотах. Замер без рассуждений в данном случае даёт модели существенно менее естественный режим решения задачи и хуже отражает её способность справляться со сложным алгоритмическим программированием.

2.4.2 Как мы замеряем ризонинг в претрейне

Замерять ризонинг на претрейнах оказалось сложнее, чем другие навыки модели. Традиционно мы использовали фьюшот‑промпты с примерами рассуждений: модель получает несколько примеров решения задачи и затем должна продолжить в том же формате. Однако качество такого замера сильно зависит от самих фьюшотов. В наших экспериментах мы увидели, что итоговый скор может заметно меняться в зависимости от длины и качества рассуждений в примерах. Причём такой эффект наблюдается не только на наших моделях, но и на открытых претрейн‑моделях.

На примере MATH-500 в этом эксперименте мы варьировали длину ризонинга в примерах из фьюшотов. Видно, что модели ведут себя по‑разному, но общая тенденция показывает, что от более длинного ризонинга растёт скор.

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

Но в более сложных задачах фьюшоты могут ограничивать модель, задавая ей определённую длину рассуждения. Поэтому такие задачи мы даём без фьюшотов, чтобы модель могла сама выбрать, насколько подробно рассуждать. При этом претрейн‑модель часто ошибается в формате ответа, и замер по одной генерации становится слишком нестабильным. Чтобы получить полезный сигнал, мы используем pass@k с большим числом независимых генераций и считаем задачу решённой, если хотя бы одна из них оказалась правильной.

Похожий подход используется и в других работах: в Does Reinforcement Learning Really Incentivize Reasoning Capacity in LLMs Beyond the Base Model возможности базовых моделей исследуют с помощью pass@k при больших k, а для Nemotron-3-Super-120B‑A12B‑Base NVIDIA приводит результаты на AIME 2024 по pass@32.

Таким способом замера мы оцениваем олимпиадное программирование на датасете задач с Codeforces и сложную олимпиадную математику на датасетах AIME, HMMT и IMO‑AnswerBench. Особенно хорошо подход работает для оценки качества моделей после reasoning‑стадии, о которой подробно пишем в разделе 7.

Мы также проверили такой замер на нескольких открытых претрейн‑моделях. Для Nemotron-3-Super-120B‑A12B‑Base и Qwen3.5–35B‑A3B‑Base pass@k работает хорошо: модели способны решать сложные задачи без few‑shot‑примеров, хотя правильные решения появляются редко. GLM-4.5-Air и DeepSeek‑V4-Flash в zero‑shot заметно теряют качество, поэтому для них такой замер не даёт полезного сигнала.

2.5 Бенчмарки длинного контекста

Отдельно мы оцениваем работу модели с длинным контекстом, который в этой версии расширили до 128K токенов. Нам важно проверять не только способность найти отдельный факт в большом объёме текста, но и полезные сценарии, где модели действительно приходится работать с длинной историей или несколькими документами. Среди основных бенчмарков для этого мы используем LongMemEval и собственную расширенную версию FinQA.

LongMemEval — опенсорсный бенчмарк, который проверяет, как модель запоминает и использует информацию из длинной истории диалога: в том числе находит нужные факты, связывает информацию из разных частей истории и учитывает её изменения со временем. Такой формат близок к реальному сценарию использования модели в длинных диалогах. Для оценки претрейн‑моделей мы собрали few‑shot‑промпт так, чтобы один длинный диалог использовался сразу для четырёх вопросов — это позволяет сохранить примеры в промпте и при этом уложиться в доступный контекст.

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

2.6 Агентские бенчмарки

Агенты — другое сложное для оценки в претрейне направление, поэтому здесь мы в первую очередь ориентируемся на лучшие практики и бенчмарки из опенсорса. Претрейн‑модели не адаптированы к агентскому формату, поэтому перед замером все модели проходят SFT на одном и том же наборе агентских данных. После полноценного RL абсолютные результаты становятся выше, но основные различия между претрейн‑экспериментами видны уже после SFT.

Мы собрали набор бенчмарков, который покрывает разные агентские сценарии. Среди них для оценки качества взаимодействия с пользователем и внешними сервисами используем τ²‑bench и VitaBench, для планирования — DeepPlanning. Кодовых агентов отдельно оцениваем на SWE‑bench Verified в фреймворке OpenHands.

Для оценки агентских возможностей мы собрали широкий набор бенчмарков для разных сценариев. В него, в частности, входят τ²‑bench и VitaBench для оценки взаимодействия с пользователем и внешними сервисами, DeepPlanning для планирования и SWE‑bench Verified во фреймворке OpenHands для кодовых агентов. Кроме того, для оценки претрейн‑моделей мы разработали прокси‑бенчмарки: модель ещё не может пройти полноценный диалог, но уже способна сделать отдельный шаг агентской траектории, качество которого мы и оцениваем.

3. Что и как мы обучали

Наша модель — MoE Transformer на 80B параметров, из которых 3B активных, состоящая из 48 трансформерных блоков с hidden size 2048 и одного multi‑token prediction слоя. Каждый MoE‑слой содержит 512 routed experts с top‑k 10 и один shared expert. Для роутинга используется auxiliary‑loss‑free подход из DeepSeek‑V3.

Из 48 attention‑слоёв 36 используют Kimi Delta Attention, а 12 — full attention: после каждых трёх KDA‑слоёв расположен один full‑attention‑слой. Для агрегации представлений по глубине используется Attention Residuals (AttnRes), заменяющий обычное суммирование обучаемым взвешиванием. Детали этих решений приведены в разделе «Архитектура и стабилизация обучения».

Наше обучение состоит из четырёх стадий.

_{Таблица 5}

Обучение проходило в четыре последовательные стадии, параметры которых приведены в таблице 5. Первая стадия — основной претрейн на 17,5 трлн токенов с длиной контекста 8K. Детали выбора гиперпараметров для неё описаны в разделе 4.3. На двух следующих стадиях мы последовательно увеличивали контекст до 32K, а затем до 256K, продолжая обучение с уменьшенными learning rate и размером батча. Для этих стадий гиперпараметры подбирались экспериментально. Мы не увидели значительного роста бенчмарков длинного контекста от увеличения длительности 32K‑стадии, поэтому основной вычислительный бюджет отвели на длинноконтекстную 256К стадию.

Последняя стадия была посвящена рассуждениям и агентским взаимодействиям; её мотивацию и состав данных мы подробно рассматриваем в разделе 7. На этой стадии мы уменьшили длину контекста с 256K до 128K ради экономии вычислительных ресурсов. Качественных примеров с настолько длинными рассуждениями в наших данных сравнительно мало, а самые длинные траектории чаще содержат шум и избыточные шаги. Поэтому контекста 128K было достаточно для основной части полезных данных, а освободившийся вычислительный бюджет можно было направить на обучение на большем числе примеров.

4. Как мы выбрали архитектуру и сетап обучения

4.1 Абляции ключевых изменений

В процессе разработки претрейн‑модели мы параллельно работали над тремя ключевыми направлениями: архитектурой, составом претрейн‑корпуса и scaling law. Чтобы оценить вклад основных изменений, мы сравнили четыре последовательные конфигурации: в первых двух при базовом предсказании гиперпараметров менялся корпус, затем менялась архитектура, а на последнем шаге мы перешли к гиперпараметрам, предсказанным нашим scaling law. Каждая соседняя пара показывает эффект одного изменения при уже выбранных остальных компонентах. Таким образом, мы смогли разделить эффект от наших ключевых изменений. В этом разделе мы приводим результаты этого сравнения и показываем, как каждое из трёх направлений повлияло на итоговое качество модели при large‑scale‑обучении на 2 трлн токенов. В первых двух конфигурациях использовалась архитектура Qwen3-Next, после чего она была заменена на нашу архитектуру. Для датасета в качестве бейзлайна мы использовали датасет от YandexGPT 5 Base, к которому были добавлены датасеты, собранные для Alice AI LLM 235B релиза октября 2025 года.

Чтобы отдельно оценить вклад архитектуры модели, состава претрейн‑корпуса и новых scaling laws, мы сравнили четыре конфигурации. Все эксперименты проводились на первой стадии обучения претрейн‑модели с инициализацией из случайных весов. Их подробное описание представлено в таблице ниже.

_{Таблица 6}

Такая постановка позволяет последовательно оценить вклад каждого из трёх факторов:

• Вклад данных определяется сравнением Baseline и Data reference: архитектура Qwen3-Next остаётся неизменной, меняется только предобучающий корпус.

• Вклад архитектуры определяется сравнением Architecture и Baseline: обе модели обучаются на новом корпусе по одной и той же базовой схеме.

• Вклад scaling law определяется сравнением Full model и Architecture: архитектура и данные остаются неизменными, а параметры обучения выбираются с помощью новых законов масштабирования.

Итоговые бенчмарки представлены в следующей таблице.

_{Таблица 7}

Результаты показывают, что итоговый прирост нельзя свести к одному удачному изменению: разные компоненты обучения устраняют разные ограничения модели. Новый претрейн‑корпус улучшает качество во всех четырёх группах и на каждом из 13 бенчмарков, обеспечивая модели более полный и качественный обучающий сигнал. Архитектурные изменения особенно заметно помогают в программировании и рассуждениях, а также улучшают фактологические знания. Конфигурация обучения, подобранная с помощью scaling laws, сильнее всего влияет на математику и даёт дополнительный прирост на фактологических задачах. Полная конфигурация получила лучшее макросреднее и лучший результат на 7 из 13 бенчмарков. Это показывает пользу выбранной комбинации решений в нашем эксперименте.

Далее мы подробно опишем работу над каждым из направлений.

4.2 Архитектура и стабилизация обучения

Рассказывает Максим Абрахам @fdrose

В этом разделе описаны ключевые решения в архитектуре модели и организации её обучения.

4.2.1 Стабилизация MoE‑активаций

Перед основным запуском мы провели тестовое обучение нашей архитектуры с learning rate, выбранным по нашему scaling law. Во время обучения произошёл резкий скачок лосса, сопровождавшийся быстрым ростом активаций на выходе down‑проекции MoE‑слоя.

Чтобы разобраться в причинах, мы провели дополнительные запуски. На моделях меньшей ширины нестабильность не воспроизводилась, а при сохранении ширины и top‑k — воспроизводилась даже при уменьшении числа слоёв. Поскольку часть различий относилась к выбору экспертов, сначала мы проверили гипотезы, связанные с роутингом.

4.2.1.1 Проверка гипотезы о роутинге и ограничение SwiGLU

Мы проверили две модификации роутинга. Сначала добавили Z‑Loss из работы ST‑MoE к логитам роутера, чтобы ограничить их масштаб. Затем заменили стандартный auxiliary load‑balancing loss на используемую в DeepSeek‑V3 балансировку с помощью динамически обновляемых bias.

Ни одна из модификаций не устранила нестабильность. При этом DeepSeek Routing улучшил метрики качества, поэтому мы оставили его в итоговой конфигурации.

Мы также протестировали вариант SwiGLU с hard clipping, используемый в GPT‑OSS. Для вышедших за порог компонентов производная такой операции равна нулю, поэтому эти компоненты не вносили вклад в градиент по входным проекциям MLP. В наших экспериментах этот вариант ухудшал качество, так что от этого подхода мы тоже отказались.

4.2.1.2 Gated RMSNorm

Далее попробовали идею из работы Qiu et al., где большие устойчивые компоненты residual stream рассматриваются как механизм неявного масштабирования. Такие компоненты доминируют в знаменателе RMSNorm и тем самым регулируют масштаб остальных признаков. Gated RMSNorm предоставляет модели явный покомпонентный механизм масштабирования после нормализации, снижая необходимость создавать большие значения в residual stream. Задаётся Gated RMSNorm так:

Мы применили Gated RMSNorm ко всем нормализациям, кроме QK‑нормализаций в слоях KDA (механизм обновления KDA работает при предположении, что ключи на входе слоя имеют единичную L2-норму, поэтому их нормирование менять нельзя) и full‑attention. Активации стали меньше, но выбросы всё ещё случались. Оригинальная статья также рекомендует использовать GLU вместо SwiGLU в паре с Gated RMSNorm, и хотя это действительно стабилизирует активации, в наших экспериментах такая замена ухудшила качество. А вот в связке с Attention Residuals получались стабильные активации без просадки в качестве, однако дополнительные проекции замедляли обучение примерно на 5%. Поэтому мы продолжили поиск метода с меньшими вычислительными расходами.

4.2.1.3 Выбор Z-Loss

В итоговом варианте мы перенесли идею Z‑loss с логитов роутера на выходные активации MoE. В экспериментах это позволило ограничить рост выходных активаций (рисунок 7). 

На более длинном горизонте резкий всплеск функции потерь больше не наблюдается: запуск с Z‑loss сохраняет стабильную динамику (рисунок 8) без наблюдаемого ухудшения качества, а также не замедляет обучение, в отличие от Gated RMSNorm.

Используемый нами лосс определяется следующим образом. Пусть , где  — количество токенов, а  — размерность активации. Для токена определим:

Тогда Z‑Loss имеет вид:

Лосс сначала усредняется по токенам, а затем по MoE‑слоям. Полученное значение умножается на коэффициент и добавляется к основной функции потерь:

Z‑Loss обладает одним важным свойством, а именно: он хорошо регулирует максимальные значения в выходных тензорах.

На это свойство можно посмотреть под разными углами

• Функция logsumexp является гладким приближением максимума, поэтому лосс в первую очередь реагирует на большие положительные значения активаций.

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

• Градиент по компоненте имеет вид: . Таким образом, наибольший градиент получают компоненты с наибольшими значениями softmax. Это позволяет сильнее подавлять именно те положительные выбросы, которые доминируют в logsumexp.

При этом Z‑Loss не ограничивает большие отрицательные значения напрямую: их вклад в logsumexp и softmax экспоненциально мал. Тем не менее он может влиять на них косвенно через общие веса слоя и входные активации.

Поскольку при вычислении Z‑Loss используются экспоненты, logsumexp и softmax, все связанные с ним операции выполняются в формате float32, что снижает риск потери точности при наличии больших активаций.

4.2.2 Muon

Muon (MomentUm Orthogonalized by Newton‑Schulz) — оптимизатор для двумерных матриц параметров нейронной сети. Сначала он вычисляет momentum из градиентов, а затем приближённо ортогонализует полученную матрицу методом Newton‑Schulz. В отличие от покомпонентного преобразования обновлений в AdamW, Muon учитывает матричную структуру параметра и совместно преобразует все его строки и столбцы.

Ортогонализация делает шаг оптимизатора дороже, но при этом Muon может достигать заданного качества за меньшее количество FLOPs на обучении. В экспериментах из работы Muon is Scalable for LLM Training Muon достигал сопоставимого качества примерно с половиной затрат по FLOPs относительно AdamW в compute‑optimal режиме. При этом каждый шаг Muon включает дополнительные вычисления и пересылки данных. Их неэффективная реализация может уменьшить итоговый выигрыш, поэтому распределённый шаг оптимизатора необходимо ускорять.

В распределённом обучении проблемы возникают потому, что независимое применение Newton‑Schulz к отдельным FSDP‑шардам не эквивалентно обработке полной матрицы. То есть перед Newton‑Schulz шарды momentum необходимо собрать, а после — распределить обратно между рангами.

Мы организовали распределённый шаг Muon так, чтобы сбалансировать ортогонализацию между GPU и перекрыть пересылки с вычислениями. Для этого мы разбиваем работу на стадии, распределяем матрицы между стадиями и GPU с помощью LPT и выполняем стадии конвейером. Каждая стадия проходит три шага: сборку полных матриц momentum, Newton‑Schulz и возврат обновлений (рисунок 9).

Перед формированием стадий матрицы преобразуются в work units. Тензоры MoE разбиваются вдоль оси экспертов, а остальные двумерные веса образуют по одному work unit. Для каждого work unit по размерам входящих в него матриц оценивается вычислительная стоимость ортогонализации. Затем применяется LPT: work units упорядочиваются от самых дорогих к самым дешёвым и последовательно распределяются по вычислительным группам с наименьшей текущей нагрузкой. Из этих групп формируются стадии, внутри которых работа равномерно распределяется между GPU. Это уменьшает разницу во времени выполнения между GPU и не позволяет отдельным тяжёлым матрицам задерживать весь шаг оптимизатора.

При сборке стадии каждый ранг берёт локальные FSDP‑шарды входящих в неё матриц и упаковывает их в коммуникационные буферы. После обмена GPU, назначенный для обработки, получает все части своих матриц и собирает их в исходной последовательности в полные двумерные тензоры. Сразу после этого матрицы стадии можно передать в Newton‑Schulz. Полученные обновления разрезаются по тем же границам, по которым параметры были разделены FSDP на шарды, и возвращаются исходным рангам.

Стадии образуют конвейер (рисунок 10): пока для одной стадии выполняется Newton‑Schulz, одновременно можно собирать матрицы следующей стадии и возвращать результаты предыдущей. После заполнения конвейера вычисления и коммуникации большую часть времени идут параллельно, поэтому GPU реже простаивают в ожидании пересылок. В итоговом обучении наша реализация примерно вдвое сократила время на выполнение шага оптимизатора.

4.2.3 Kimi Delta Attention

Full attention позволяет каждому токену напрямую обращаться ко всем предшествующим токенам. Однако за этот доступ приходится платить: KV-cache растёт вместе с длиной последовательности.

Чтобы уменьшить эту стоимость, мы используем Kimi Delta Attention (KDA), предложенный в работе Kimi Linear, в сочетании с full attention. Слои чередуются в соотношении 3:1: на каждые три KDA-слоя приходится один full-attention-слой. В KDA история хранится не в виде отдельных ключей и значений для каждого токена, а сворачивается в состояние фиксированного размера, поэтому память, занимаемая состоянием KDA, не растёт вместе с длиной контекста. 

При обработке нового токена KDA сначала извлекает из состояния значение, соответствующее его ключу. Затем модель сравнивает его с новым значением и записывает только поправку — разницу между ними. Благодаря этому состояние не перезаписывается целиком, а постепенно уточняется. Кроме того, модель может постепенно забывать информацию, которая перестала быть полезной. В отличие от Gated DeltaNet из Qwen3-Next, где один коэффициент затухания применяется ко всей attention-голове, KDA использует отдельный коэффициент для каждой строки матрицы состояния. Это позволяет избирательно сохранять и забывать разные части состояния.

В наших экспериментах на моделях размером 5–15B замена Gated DeltaNet на KDA снизила лосс примерно на 0,02 в абсолютном выражении и улучшила результаты в нескольких группах задач: примерно на 2–6 п. п. в математике, на 5 п. п. в MMLU Pro CoT и на 2–4 п. п. в образовательных задачах и извлечении информации. На основании этих результатов мы выбрали KDA для итоговой архитектуры.

4.2.4 Attention Residuals

Мы также используем механизм из работы Attention Residuals, который заменяет суммирование выходов предыдущих слоёв их взвешенной суммой. Веса вычисляются для каждого токена с помощью обучаемого pseudo‑query и softmax по глубине модели. Это позволяет слоям избирательно обращаться к предыдущим представлениям. Перед вычислением весов представления нормализуются с помощью RMSNorm.

В Attention Residuals RMSNorm применяется к ключам, чтобы различия в норме исходных представлений не определяли веса attention. В нашей реализации после нормализации используется обучаемый покомпонентный scale‑вектор . После такого преобразования нормы ключей могут сильнее различаться, однако дополнительная параметризация может улучшать оптимизацию, даже не увеличивая выразительность модели, как это показано в работе ByteDance. В наших экспериментах использование улучшило качество, поэтому мы оставили его в RMSNorm.

В полном варианте метода (Full AttnRes) каждый слой обращается к отдельным выходам предыдущих слоёв. Мы используем Block AttnRes с размером блока в 8 слоёв. Под слоем здесь понимается отдельный attention или MoE, поэтому один AttnRes‑блок объединяет 4 трансформерных блока. Выходы слоёв внутри AttnRes‑блока накапливаются в частичную сумму, а каждый следующий слой обращается к ней и завершённым представлениям предыдущих блоков. Это сокращает число представлений, читаемых AttnRes‑кернелом, и объём чтения из памяти.

В нашей реализации мы согласовали границы activation checkpointing с расположением AttnRes‑операций, чтобы избежать сохранения лишних активаций. За 1x примем память для сохранения входных активаций в трансформерные блоки. Промежуточные активации внутри каждого блока восстанавливаются пересчётом при backward. При наивном выборе границ Full AttnRes требует сохранять входной checkpoint и выходы attention и MoE для последующих AttnRes‑операций — три тензора на трансформерный блок, то есть 3x (рисунок 11).

Мы располагаем границу checkpointing перед AttnRes‑операцией, следующей за MoE. Тогда выход MoE одновременно служит checkpoint’ом следующего сегмента, а результат AttnRes восстанавливается пересчётом. На трансформерный блок остаются два сохраняемых тензора, что сокращает объём сохраняемых активаций до 2x (рисунок 12).

В Block AttnRes мы применяем тот же принцип: сохраняем текущую частичную сумму перед AttnRes-операцией на границе трансформерных блоков. При завершении AttnRes-блока эта сумма одновременно становится и итоговым представлением блока, поэтому отдельно сохранять её не требуется. Промежуточный выход attention восстанавливается пересчётом. В результате объём сохраняемых активаций остаётся на уровне 1x.

Увеличение AttnRes-блока дополнительно сокращает объём чтения из памяти, но при такой организации checkpointing уже не уменьшает память на сохраняемые активации. На инференсе оно также дополнительно снижает объём временно хранимых представлений во время prefill.

В наших экспериментах на моделях размером 5–15B добавление Block AttnRes снизило лосс примерно на 0,017 в абсолютном выражении и улучшило результаты в нескольких группах задач: примерно на 3 п. п. в MMLU Pro CoT на русском и английском языках, на 4,9 п. п. в GSM8K CoT на английском и на 4–5 п. п. в ряде образовательных бенчмарков. На основании этих результатов мы включили Block AttnRes в итоговую архитектуру.

4.3 Scaling laws

4.3.1 Метод

Для обучения претрейн‑моделей широко используются scaling laws. Для подбора гиперпараметров обучения используется стандартный подход с обучением зависимости и на экспериментах небольшого масштаба. Оптимальные гиперпараметры подбираются с помощью обучения зависимостей при фиксированных и с дальнейшим поиском минимума loss’а для получения оптимальных параметров при фиксированных и . Для построения этих зависимостей мы использовали модели с общим числом параметров около 5B и 10B при объёме обучения от 100B до 600B токенов.

В разделе 4.1 мы показали, что корректный подбор гиперпараметров сильно влияет на итоговое качество base‑модели. В свою очередь, на определение оптимальных гиперпараметров, помимо функциональных форм, используемых при оптимизации, сильно влияет датасет, на котором определяется сам закон. При обучении своей модели мы обнаружили, что подбор датасета, на котором считается loss‑функция, очень сильно влияет на получаемый закон.

Для внешней проверки полученного закона мы хотели сравнить наши предсказания с результатами открытых моделей. Однако среди рассмотренных технических отчётов явная формула для оптимального learning rate приведена только для Laguna. Прямое сравнение затруднено различиями в схеме обучения: Laguna использует Muon с WSD‑шедулером, тогда как мы используем Muon с линейным шедулером. Поскольку универсального пересчёта оптимального LR между этими шедулерами не существует, для оценки мы пересчитали learning rate Laguna в эквивалентное значение для линейного шедулера, умножив его на два.

_{Таблица 8}

Даже после приближённого пересчёта предсказанный нами оптимальный learning rate оказывается выше значения, полученного для Laguna. При этом переход к новому датасету заметно сдвигает оптимум, что ещё раз показывает, насколько выбор данных для расчёта функции потерь влияет на итоговые scaling laws.

4.3.2 Подбор датасета для расчёта loss-функции

Сначала мы применили подход, аналогичный канонической статье «Scaling Laws for Neural Language Models», и построили scaling law на отложенной части обучающего корпуса. Поскольку проверить правильность нашего закона прямым сравнением с известными формулами было затруднительно, мы решили напрямую проверить оптимальность полученного закона с помощью эксперимента, исходя из следующего соображения: если наше предсказание даёт оптимальный bs, то обучение модели с гиперпараметрами, пересчитанными на , не должно быть лучше при сравнении на бенчмарках. Эксперимент проводили на большом обучении в 2Т токенов.

Сравнение средних значений по бенчмаркам: 

_{Таблица 9}

Для модели с lr=5.5e-4, bs=8M относительно модели с lr=7.8e-4, bs=16M при пороге значимости без поправки на множественные сравнения мы обнаружили улучшение на 10 бенчмарках и ухудшение на одном; на остальных 48 бенчмарках значимого различия не обнаружено.

Полученный результат не совпал с нашим ожиданием: если конфигурация, предсказанная с помощью scaling law, близка к оптимальной, переход к вдвое меньшему batch size с пересчитанным learning rate не должен улучшать качество. Однако вариант с меньшим batch size оказался лучше по среднему результату и чаще выигрывал на отдельных бенчмарках. Это могло означать, что предсказанный нами batch size больше критического значения, либо предсказание learning rate не оптимально (либо сработали оба фактора одновременно). 

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

Для ответа на этот вопрос мы посчитали accuracy ранжирования по loss’у на используемом датасете относительно ранжирования по среднему скору golden‑сета бенчмарков. Результат представлен в таблице 9. Мы увидели, что accuracy ранжирования на нашем сете документов составляет всего 42%! После этого мы сосредоточились на подборе сета документов, лосс на котором будет максимально согласован по ранжированию с ранжированием по среднему скору бенчмарков.

Мы рассмотрели несколько типов датасетов:

• Лосс на бенчмарках

• Релевантные веб‑документы для разных доменов

• Кодовые датасеты для повышения корреляции с кодовыми бенчмарками

Accuracy ранжирования на подобранных датасетах представлена в таблице 10.

_{Таблица 10}

В дальнейшем мы экспериментировали с подбором scaling laws на этих датасетах. Прогнозы, полученные на этих датасетах, давали разные предсказания. Поскольку в результате экспериментов нам не удалось однозначно выбрать лучший датасет, мы использовали усреднённое по нескольким лучшим датасетам предсказание. В таблице 8 представлено mean ± std для нашего обучения.

4.3.3 Стабилизация активаций

Первый запуск с learning rate, предсказанным по scaling law, завершился неожиданно: сначала начали расти MoE‑активации, а затем произошёл резкий скачок лосса. Естественной гипотезой была ошибка в scaling law и, как следствие, завышенный learning rate. Однако тот же эффект удалось воспроизвести на небольшой модели всего из нескольких широких слоёв. Так редкий и дорогой сбой большого обучения превратился в компактный эксперимент, на котором мы смогли перебрать способы стабилизации и найти архитектурное решение. Оно позволило вернуться к исходному прогнозу learning rate и успешно обучить итоговую модель. Подробнее этот разбор описан в разделе «Стабилизация MoE‑активаций».

5. Общий general-pretrain корпус

5.1 Состав корпуса

Модель предобучена на смеси естественных и синтетических данных. Естественная часть корпуса включает веб‑страницы, общедоступный программный код, книги, научные статьи, новости, мультиязычные материалы, специализированные источники и открытые датасеты.

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

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

За основу новой версии корпуса мы взяли корпус YandexGPT 5 Lite Base, а также наработки, полученные при подготовке более компактных корпусов дообучения для Alice AI LLM 235B релиза октября 2025 года. Однако прямой перенос датасетов, хорошо работавших в коротких циклах дообучения, не сохранял свою эффективность при увеличении продолжительности обучения. Самым ярким примером является аугментация фактологических документов, подробно описанная в разделе 6.4. Поэтому одной из основных задач при подготовке корпуса стал поиск способов масштабировать существующие методы отбора, генерации и аугментации данных на более продолжительный претрейн. Части корпуса, которые были наиболее существенно обновлены в этой версии, подробно рассмотрены в следующих разделах.

5.2 Веб

Для сбора веб‑данных мы используем собственный краулер. На первом этапе из всей скрауленной внутри Яндекса поисковой базы отбираются русскоязычные и англоязычные документы, а также страницы, ссылки на которые встречались в запросах пользователей Яндекс Поиска.

Затем документы проходят стандартный пайплайн предобработки. Сначала внутренний парсер извлекает содержимое страницы и преобразует его в Markdown. После этого качество документов оценивается каскадом моделей: легковесным DSSM‑классификатором, работающим на CPU, нейросетевой encoder‑decoder‑моделью на 0,5 млрд параметров и для отдельных срезов моделью на 8 млрд параметров, построенной на основе YandexGPT 5 Lite Base.

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

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

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

Математический и кодовый веб описаны в разделе 6. 

5.3 Длинный контекст

Мы обучаем модель работать с контекстом длиной до 256K токенов. Текстовых источников с такими длинными документами мало, поэтому значительную долю данных здесь составляет синтетика. 

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

• QA по книгам — чтобы модель училась находить информацию, разбросанную по всему документу.

• QA и задачи по Excel‑документам — для работы с длинными структурированными данными и поиска информации по таблицам.

• QA по склеенным коротким документам (например, по медицине или праву, в которых много сложных похожих терминов) — чтобы модель училась выбирать релевантную информацию среди большого количества независимых похожих источников.

• Multi‑hop поисковые задачи — вопросы строились последовательными обращениями к поиску, а найденные документы добавлялись в контекст. Такие примеры требуют объединять информацию из нескольких источников и проводить цепочку рассуждений.

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

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

Поскольку в этих документах нет полезной для ответа информации, в идеале качество в двух режимах должно быть одинаковым. Однако после добавления синтетических данных, несмотря на улучшение результатов на стандартных бенчмарках длинного контекста, отвлекающие документы снижали результат на 30–40% относительно режима без контекста. Мы добавили в обучение примеры с такими документами и сократили падение до 10%: модель стала лучше игнорировать нерелевантный текст, хотя полностью устранить эффект не удалось.

5.4 Математические данные

Наш математический корпус состоит из двух основных частей: полезных математических веб‑документов и полученных из них производных данных, а также синтетически сгенерированных решений математических задач.

При подготовке корпуса мы сравнивали его с доступными открытыми наборами данных, в том числе Ultra‑Data‑Math и Nemotron‑CC‑Math‑v1. Претрейн‑эксперименты показали, что качество на математических бенчмарках растёт как при масштабировании и улучшении математического веб‑корпуса, так и при добавлении синтетических решений.

Пайплайн отбора и аугментации математического веба описан в разделе 6.8. Для развития навыков решения математических задач мы использовали подход к генерации синтетических данных, аналогичный применённому при подготовке YandexGPT 5 Lite Base.

5.5 Кодовые данные

Пайплайн отбора и обработки кодового веба описан в разделе 6.9.

На этапе претрейна мы добавили корпус отфильтрованных репозиториев GitHub. В него вошли проекты, которые LLM‑судья оценил как особенно значимые, — например, широко используемые библиотеки и известные open‑source‑проекты. Кроме того, мы добавили решения синтетически сгенерированных задач по программированию. Рецепт их получения описан в разделе 7.2.

6. Как мы научились строить данные для отдельных доменов

Отдельные элементы этого подхода мы уже кратко описывали в техрепорте Alice AI: там мы рассказывали, как отбирали источники фактологических знаний и применяли аугментации в более компактных дообучениях. В этом отчёте мы впервые подробно разбираем весь процесс — от анализа корпуса и построения пайплайна до экспериментов с разными видами аугментаций. Главное новое здесь — перенос рецепта с дообучений на большой претрейн, где из-за масштаба корпуса и меньшей относительной частоты каждого факта те же методы нельзя было применить без изменений.

Схожий подход независимо описан в техрепорте Kimi K2: вместо многократного повторения одних и тех же документов авторы генерируют разнообразные фактологически согласованные переформулировки и проверяют их соответствие исходному тексту. По-видимому, наши команды пришли к этой идее примерно параллельно. Это даёт дополнительное независимое подтверждение основного наблюдения: для эффективного усвоения знаний важно не просто чаще показывать модели один и тот же документ, а увеличивать разнообразие представлений содержащихся в нём фактов.

6.1 Важность фактологического домена

Большая часть фактологических знаний закладывается на этапе претрейна, а восполнить оставшиеся пробелы позже при ограниченном вычислительном бюджете (что всегда верно на практике) крайне сложно. В работе «Does Fine‑Tuning LLMs on New Knowledge Encourage Hallucinations» показано, что новые факты на SFT усваиваются заметно медленнее уже известных, а их интенсивное проучивание может усиливать галлюцинации.

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

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

6.2 Аналитика корпуса для фактов

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

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

Нам было важно проверить, насколько полно корпус покрывает темы, востребованные в реальных пользовательских сценариях. Для этого мы построили пайплайн, показанный на рисунке 16: сначала небольшая модель с доступом к поиску отвечала на вопросы нашего фактологического бенчмарка. Если она находила правильный ответ в полученных документах, мы считали, что нужная информация доступна в источниках. Затем на те же вопросы отвечала наша крупная LLM без поиска — так мы проверяли, усвоила ли она эти знания при обучении.

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

Мы провели исследование: собрали полезные страницы из поиска для ответа на вопросы бенчмарка, экспериментально проверили, что их добавление в корпус улучшает результаты на нашем фактовом бенчмарке, а затем в целях аналитики прямо проверили их пересечение с нашим корпусом (в дальнейшем мы никогда не использовали эти страницы, чтобы не переобучиться под свой бенчмарк). Мы обнаружили, что более 60% полезных документов отсутствуют в нашем корпусе по двум причинам: сильное урезание множества полезных сайтов на первом этапе сбора претрейн‑корпуса и плохие фильтры отбора финальных страниц.

После этого исследования мы ввели отдельную целевую категорию в виде общего фактового веба и специально собрали корпус под него.

6.3 Пайплайн сбора фактологического корпуса

Обнаруженную проблему мы решали двумя способами: полной пересборкой претрейн‑корпуса с самых первых стадий и отдельной работой над качеством фактовых классификаторов. Мы существенно увеличили количество URL, которые обрабатываются на первой стадии пайплайна, что в конечном итоге позволило увеличить сырой претрейн‑корпус в два раза и покрыть больше полезных ресурсов. Для этого потребовалось сильно увеличить количество CPU и объём дисковых ресурсов. Затем мы сфокусировались на повышении полноты отбора полезных фактовых документов на последних стадиях пайплайна сбора данных.

В прошлых версиях пайплайна сбора данных использовались легковесные DSSM‑классификаторы. Мы отобрали несколько сотен тысяч документов из общего корпуса и разметили их по фактологической полезности с помощью большой LLM. Затем обучили классификаторы двух размеров: 8B и 0.5B. Несмотря на то что классификационные метрики двух моделей были похожи, полученное с их помощью ранжирование сильно различалось.

Мы пришли к выводу, что легковесные модели обладают слабой ранжирующей способностью в такой сложной задаче, как отбор полезных фактологических документов. При сравнении оценок двух классификаторов наибольшее расхождение наблюдалось для документов, которым классификатор 8B присваивал оценку выше 0,8. Эксперименты показали, что именно добавление таких документов давало наиболее устойчивый рост результатов на бенчмарках: классификатор 0.5B отбрасывал часть наиболее полезных документов. Однако прогон модели размера 8B стоил бы нам больше двухсот тысяч GPU‑часов, поэтому мы сосредоточились на построении многостадийного пайплайна. При его построении мы жёстко следили за полнотой отбора документов на ранних стадиях.

В конечном итоге нам удалось построить пайплайн, который сохранял около 95% полезных документов и в десятки раз сокращал необходимые вычисления. Схема пайплайна представлена на рисунке 18.

6.4 Аугментации фактологических документов

Отдельной задачей при работе над фактовым срезом было улучшение запоминания фактовых знаний. При работе над этим срезом мы значительно опирались на статью Physics of Language Models и поставили себе целью найти наиболее эффективное преобразование, которое улучшает результаты на QA‑бенчмарках.

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

При работе мы исследовали много различных видов аугментаций, которые можно получить как нейронными, так и rule‑based‑методами. Некоторые модельные примеры приведены в таблице 11.

_{Таблица 11}

В модельных экспериментах удавалось получить приросты от большей части вариантов, хотя и сильно различающиеся по величине, однако при переносе их в продовый сетап, использовании разных сочетаний аугментаций и масштабировании количества данных многие приросты становились статистически незначимыми. В конечном итоге мы остановились на 3 вариантах аугментаций фактовых знаний: рерайтах, переформулировках и QA. Приросты от этих аугментаций в модельных экспериментах представлены в таблице 12. Рерайты со сложными дистракторами в экспериментах не участвовали, поскольку были дальнейшим развитием метода рерайтов и начали применяться в обучении позже.

_{Таблица 12}

Первоначально мы использовали этот рецепт в продовых дообучениях, где аугментированные данные составляли около 5–10% всех токенов. Чтобы сократить вычислительные затраты, мы точечно аугментировали наиболее полезные источники — в частности, русскоязычные онлайн‑энциклопедии и фактологическую базу, собранную с помощью поиска. Общий полезный фактологический веб на этом этапе мы не обрабатывали. В коротком приёмочном эксперименте добавление таких данных дало прирост около 6 п. п. на HardMultiQA по сравнению с корпусом YandexGPT 5 Lite Base.

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

Причину мы связали с относительной частотой полезных данных. Продолжительный претрейн содержит во много раз больше токенов, поэтому каждый отдельный факт встречается в обучающей смеси относительно реже, чем при компактном дообучении. Эта гипотеза согласуется с выводами работы How Do Large Language Models Acquire Factual Knowledge During Pretraining: для усвоения факта важно не только его присутствие в корпусе, но и частота повторения. При этом, согласно этой работе и нашим экспериментам, простое увеличение числа эпох не решало проблему.

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

Поскольку каждый пример требовал генерации целого текста, такая обработка оказалась вычислительно дорогой. В рамках доступного бюджета нам удалось аугментировать около 30% собранного фактологического веба. Масштабирование аугментаций дало около 3 п. п. на HardMultiQA в коротком приёмочном эксперименте. В длинном эксперименте, где все изменения корпуса проверялись совместно, суммарный прирост составил около 5 п. п.; при этом именно аугментации внесли основной вклад в улучшение фактологических ответов финальной модели.

6.5 Что мы выяснили об обучении на QA

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

Для повышения качества ответов на сгенерированные вопросы мы использовали специализированную LLM с доступом к поиску Яндекса. Тем не менее при анализе полученного корпуса были обнаружены два основных типа искажений: семантически неоднозначные обучающие примеры и систематическое воспроизведение шаблонных ответов.

_{Таблица 13}

6.5.1 Эффект семантически неоднозначных примеров

Мы добавили сгенерированные RAG‑пайплайном QA‑данные в претрейн и исследовали ответы модели в zero‑shot‑ и few‑shot‑режимах. Неоднозначный обучающий пример сформировал устойчивую ассоциацию между словами запроса и конкретным ответом. В рассматриваемом случае одна дополнительная демонстрация не устранила ошибку, а корректная интерпретация появилась только после двух демонстраций.

_{Таблица 14}

Таким образом, few-shot-контекст способен компенсировать ошибочную ассоциацию, однако сама необходимость такой коррекции является нежелательной характеристикой претрейна: корректный смысл запроса должен восстанавливаться без дополнительных демонстраций.

6.5.2 Эффект шаблонного формата ответов

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

_{Таблица 15}

Результаты показывают, что модель усваивает не только факты, но и корреляцию между форматом ответа и классом объекта. Для живых людей она извлекает возраст, а для умерших — год рождения или даты жизни. Более того, даже одна демонстрация способна неявно задать формат извлекаемого знания. Чтобы избежать этого эффекта, мы применили аугментации по типу переформулировок и переписываний к самим QA, что описано в секции 6.5.3.

6.5.3 Эффект аугментаций

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

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

6.6 Общий рецепт работы с доменом

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

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

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

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

В дальнейшем мы использовали этот подход для фокусных экспертных фактологических срезов, сочетая его со специализированными методами обработки данных. Эти эксперименты описаны в разделе 6.7. В разделах 6.8–6.10 мы показываем, как тот же общий рецепт — независимая оценка полноты, масштабируемый отбор и доменные аугментации — переносится на домены, существенно отличающиеся от фактологического домена: математику, код и STEM.

6.7 Экспертные области

Рассказывает Дмитрий Лунин @lunin

6.7.1 Юридические данные

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

Во‑первых, для расширения корпуса мы подготовили пайплайн с фильтрацией документов на основе данных веба. С помощью 235B‑модели и 8B‑классификаторов мы проклассифицировали документы по ряду признаков: относится ли он к праву, к какому типу источников и к какой укрупнённой области права он относится; каковы юрисдикция и уровень нормативного материала; насколько документ полезен; каково качество текста.

Для работы с кодексами РФ был разработан другой пайплайн: сначала мы с помощью эвристик доставали все веб‑документы, принадлежащие конкретному кодексу, затем с помощью модели выделяли статью кодекса и делали дедупликацию на основе этой информации. На этом же этапе удавалось находить статьи, утратившие силу. Далее тексты кодексов дополнительно переписывались.

Каждый тип данных мы проверяли в отдельных контрастных экспериментах. Наиболее устойчивый прирост на фактологических юридических бенчмарках дали QA‑данные и первичные правовые источники из ссылочного пайплайна. Учебные тексты и диалоги улучшали отдельные показатели, однако эффект зависел от состава данных и их доли в обучении. Скриптовые рерайты не дали стабильного прироста, поэтому от этого направления мы отказались. В таблице 16 представлены примеры юридических аугментаций.

_{Таблица 16. Примеры аугментаций юридических документов}

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

В итоге добавление собранных юридических документов вместе с их аугментациями привело к росту результатов на экспертном бенчмарке по праву на 5 п. п. уже на небольшом приёмочном эксперименте.

6.7.2 Медицинские данные

Для улучшения знаний модели в области медицины мы собрали отдельный корпус из нескольких типов источников. В него вошли статьи из PubMed Central, материалы Cochrane Library и ВОЗ, клинические рекомендации Минздрава, медицинские учебники, русскоязычные сайты, энциклопедии и форумы. PDF‑ и DjVu‑документы проходили OCR и преобразовывались в текстовый формат. 

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

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

_{Таблица 17}

Пример диалоговой аугментации

Место действия: небольшая комната отдыха с кофемашиной и окном во внутренний двор больницы. Доктор Петрова и доктор Иванова сидят с кружками. К ним присоединяется Алексей с распечатанной статьёй.

Алексей: Я читал о роли железа в ферментах. Оно содержится не только в гемоглобине и цитохромах?

Доктор Петрова: Нет. Например, каталаза и пероксидазы — это гемсодержащие ферменты, расщепляющие перекись водорода. Железо в их активном центре помогает нейтрализовать активные формы кислорода.

Доктор Иванова: А медь участвует в обмене железа.

Доктор Петрова: Именно. Церулоплазмин окисляет Fe²⁺ до Fe³⁺, благодаря чему железо может связаться с трансферрином. При дефиците меди оно накапливается в клетках и хуже поступает в кровоток.

Алексей: Получается, дефицит меди может быть похож на дефицит железа?

Доктор Петрова: Клинически — да: могут появляться анемия и усталость. Но механизмы различаются, поэтому нельзя назначать железо каждому пациенту с такими симптомами. […]

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

В конечном итоге в претрейн‑корпус мы положили большой набор медицинских документов и аугментаций к ним. На небольшом приёмочном эксперименте мы наблюдали рост результатов на образовательном бенчмарке по медицине на 2,7 п. п., а в более длинном эксперименте уже рост результатов на экспертном бенчмарке на 4 п. п.

6.8 Перенос на математические данные

6.8.1 Сбор исходных документов

При сборе веб‑данных мы используем пайплайн, аналогичный тому, что описан в разделе сбора корпуса фактологически полезного веба. Для фильтрации данных мы используем две стадии фильтрации: на первой лёгким 0.5B‑классификатором отсеиваем большинство мусорных документов, обеспечивая полноту отбора, а на второй стадии используем мультиклассовый 8B‑классификатор, который определяет уровень качества данных по l1/l2/l3-тирам. 

Для контроля качества классификатора мы собрали тестовый сет на основе математических документов, размеченных с помощью LLM, а также документов open‑source‑корпусов. В прошлых версиях пайплайна для скорости отбора использовался компактный 180M‑классификатор. Однако после детального исследования мы отказались от его использования, поскольку он обеспечивал высокую точность отбора, но при этом отсеивал много полезных документов. 

В таблице 18 приведено прямое сравнение размеров нашего отфильтрованного веб‑корпуса с опенсорс‑корпусами при подсчёте с помощью нашего внутреннего токенизатора.

_{Таблица 18}

6.8.2 Аугментации математического веба

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

При разработке аугментаций мы опирались на подходы из работ Nemotron и UltraData‑Math и адаптировали их для русскоязычных данных. Чтобы снизить риск переобучения на отдельный шаблон, мы использовали пул из 19 форматов, собранных как из опубликованных работ, так и из наших экспериментов с фактологическими данными. Они охватывают четыре группы преобразований: генерацию задач, диалоги, стилевые рерайты и извлечение знаний. Полный список приведён в таблице 19.

_{Таблица 19}

Для каждого исходного документа мы использовали все форматы из этого пула. В результате аугментациями было покрыто около 10% математического веб‑корпуса. Полученный датасет содержит 115 млрд токенов и по объёму сопоставим с крупнейшими открытыми корпусами математических аугментаций.

_{Таблица 20}

Добавление этих данных давало статистически значимый прирост на небольших экспериментальных обучениях, причём рост наблюдался на некоторых претрейн‑бенчмарках, однако более показательным был монотонный рост результатов на всех математических бенчмарках после SFT. Прирост сохранился на всём диапазоне задач — от учебной и университетской математики до сложных задач на рассуждение и олимпиадных бенчмарков — и составил 3–10 п. п.

6.9 Перенос на кодовый веб

Для кодового веба мы применили подход, аналогичный работе с математическим вебом, и собрали 245B токенов сырого веба с 200B аугментаций. 

В отличие от математического среза здесь мы стремились сохранить полное техническое содержание исходного документа, поэтому использовали только смену стилей. В сгенерированном тексте должны были быть сохранены программные сущности, API, команды, зависимости, примеры, граничные случаи и семантика кода. Описание использованных стилей представлено в таблице 21. 

_{Таблица 21}

В аналогичном математическому срезу эксперименте после одинакового SFT добавление кодовых данных в претрейн улучшило большинство бенчмарков. Наиболее заметный рост наблюдался на FixEval (+14,7 п. п.) и LiveCode pass@5 (+6,5 п. п.); на MBPP и EvalPlus прирост составил 2–3,5 п. п.

6.10 Перенос на STEM-веб

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

В конечном итоге мы дополнительно дофильтровали этот корпус по двум принципам: оставили документы, содержащие «специальные знания», и фокусно отобрали все документы по физике. Так нам удалось оставить несколько сотен миллиардов полезных токенов.

Поскольку STEM‑срез во многом аналогичен математике по содержанию, мы применили здесь те же самые аугментации, что и в математическом срезе. На небольших приёмочных экспериментах мы увидели как рост результатов на STEM‑ и инженерных бенчмарках, так и рост результатов на математических бенчмарках после SFT.

7. Как мы добавили reasoning и агентские способности

7.1 Зачем нужна отдельная reasoning-стадия

Традиционные математические и кодовые бенчмарки (такие как MATH-500, HumanEval, MBPP) постепенно насыщаются: сильные претрейн‑модели решают значительную часть задач, и различия между новыми рецептами обучения на них всё труднее различить. Поэтому мы перешли к более сложным reasoning‑задачам и метрике pass@k. От претрейн‑модели здесь не требуется стабильно находить ответ с первой попытки — важно, существует ли правильная траектория решения среди нескольких генераций. Если модель уже способна её построить, последующий RL может повысить вероятность такой траектории и превратить редкий успех в устойчивое поведение. Такую связь между reasoning‑данными на ранних этапах и потенциалом дальнейшего обучения, например, наблюдают авторы OctoThinker и Front‑Loading Reasoning.

Такой подход встречается и в публичных моделях: в Nemotron 3 Super в претрейн добавляют данные с рассуждениями и оценивают модель в том числе по AIME pass@32. Авторы Qwen3.5 также сообщают об увеличении доли STEM‑ и reasoning‑данных, а по собственным замерам мы видим высокое качество их претрейн‑модели на сложных задачах.

Первые эксперименты показали, что добавление примеров рассуждений в общую претрейн‑смесь уже повышает pass@k. Однако эффект оказался заметно сильнее, когда те же данные были сконцентрированы в отдельной стадии. Поэтому обучение рассуждениям и агентским взаимодействиям мы перенесли в конец претрейна — к этому моменту модель уже обладает высоким базовым качеством и лучше извлекает сигнал из сложных данных.

В таблице 22 сравниваются чекпойнты до и после reasoning‑стадии. На сложной математике, олимпиадных задачах и коде приросты составляют десятки процентных пунктов. На традиционных CoT‑бенчмарках они значительно скромнее — около 2–5 п. п., отчасти из‑за уже высокого качества исходной модели. Это показывает, что для сравнения сильных претрейнов нужны более сложные задачи и чувствительные к появлению новых траекторий метрики pass@k.

_{Таблица 22}

^{* — Эти бенчмарки мы собрали самостоятельно из задач широкого набора существующих олимпиад на английском языке.}

Следующий вопрос — сохраняется ли преимущество после SFT, когда обе модели явно доучиваются следовать длинным рассуждениям? Для проверки мы провели одинаковый полноценный SFT, специально ориентированный на рассуждения, для обоих чекпойнтов. Даже после такого SFT преимущество сохранилось: на HMMT 2026 прирост pass@1 составил 3,8 п. п., а на Codeforces — 6,6 п. п. Это указывает на то, что эффект reasoning‑стадии не сводится к освоению формата ответа: его не удалось восполнить одним SFT.

Аналогичное сравнение мы провели для агентских задач. Результаты приведены в таблице 23.

_{Таблица 23}

Прирост есть на всех представленных агентских бенчмарках. При этом растёт не только pass@1, но и pass@4: преимущество сохраняется, даже когда моделям даётся несколько попыток. Это хороший сигнал для последующего RL — модель уже способна находить успешные траектории для большего числа задач, а дальнейшее обучение может повысить вероятность их генерации. Более подробно влияние на RL обсуждается в секции 7.3.

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

7.2 Reasoning-трейсы

7.2.1 Математика

Рассказывает Ермек Капушев @yeahrmek

Состав математической части. Основу математики в корпусе составляют открытые посттрейн‑датасеты, а также математика, извлечённая из нашего веб‑корпуса и отфильтрованная классификатором математического контента. Часть таблиц использовалась вместе с исходными рассуждениями, для остальных рассуждения генерировались нами. Сюда же добавились задачи, извлечённые из PDF — 45 тысяч на русском и 6 тысяч на английском. В отличие от подхода, описанного в разделе 6.8, здесь мы искали задачи, требующие сложных рассуждений, и особенно тщательно проверяли корректность условий и решений.

Второй источник сложной математики — MaRS (Mathematical Reasoning Set), датасет, который мы собрали сами из внутренней базы интернет‑документов. Он позволил увеличить разнообразие задач и решений и отмасштабировать датасет.

MaRS. Для обучения математическим рассуждениям мы собрали корпус MaRS (Mathematical Reasoning Set) объёмом 27 млрд токенов. Его основу составили математические задачи, извлечённые из интернет‑документов внутренней базы данных.

Исходные данные проходили многоступенчатую воронку. Внутренняя база интернет‑документов содержит порядка 330–370 млрд документов; после базового парсинга и предфильтрации остаётся около 140 млрд — от этого объёма и считаем дальше. К ним мы применяем многоступенчатый пайплайн, который постепенно сужает воронку: каждый следующий шаг делает более сложную фильтрацию и повышает качество либо сложность данных.

1. Классификатор математического контента с намеренно низким порогом 0,3 — задача этого шага не потерять потенциально полезный документ. 140 млрд → ≈1,4 млрд документов (−99%).

2. Нарезка на чанки, извлечение задач и дедупликация. ≈1,6 млрд чанков подаётся на вход экстрактору; задачи извлекаются языковой моделью, дедуплицируются и проходят базовую фильтрацию по длине условия (порог 10 слов) и регулярными выражениями. На выходе ≈980 млн задач — с заметной долей мусора. Все проценты ниже считаются от этого объёма.

3. Дополнительный фильтр на математичность: выбрасываем нематематические материалы, задачи с недостающими данными и теоретические вопросы, в которых ничего не требуется сделать, — то есть всё, что похоже на математику, но задачей не является. Остаётся примерно 70% (≈685 млн задач).

4. Отбор олимпиадных задач. Классификация по уровню сложности на четыре академических уровня — Basic School; Core High School / Early College; Advanced Undergraduate / Graduate; Olympiad / Competition Math — и отбор олимпиадного уровня. Школьные, типовые и абстрактно‑теоретические материалы уходят: остаётся 8% (≈78 млн задач).

5. Отбор вычислительных задач. Классификация по типу: вычисление, доказательство, построение, проверка существования. В основной корпус идут вычислительные, остальные типы выделяются в отдельные ветки: остаётся 4% (≈39 млн задач).

6. Проверка условий тяжёлой моделью: отсев задач с дефектами — ошибки парсинга, неявные ссылки на внешние объекты, отсутствие конкретного вопроса. Мотивация — на таких условиях модель уходит рассуждать про интерпретацию условия вместо решения. Остаётся 3% (≈29 млн задач).

7. Генерация решений и финальный отбор. Восемь генераций на задачу, majority voting с порогом 0.5, вычистка кодовых задач, отбор по языку и дедупликация. −97%, остаётся ≈0,1% (≈1 млн задач).

Итоговая конверсия воронки — 140 млрд исходных документов в ≈1 млн задач с решениями: примерно один документ из ста сорока тысяч.

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

Фильтрация решений. Для каждой задачи мы генерировали 8 независимых решений и определяли итоговый ответ с помощью majority voting. Ответ из решения извлекался отдельной LLM (модель далеко не всегда оформляет его как \boxed{}), после чего строился список ответов и выбирался самый частый. В корпус включались решения с majority score не ниже 0,5, у которых ответ совпал с мажоритарным. Задачи, для которых majority score < 0,5, выбрасывались целиком. Это, с одной стороны, позволило выбросить решения, которые с большей вероятностью неверные. С другой стороны, это сработало как дополнительный фильтр битых задач: сюда часто попадали задачи с неполными условиями, двусмысленными формулировками и так далее. Таким образом, в обучающую выборку для каждой задачи попадает несколько различных решений.

Эксперименты показали, что длинные цепочки рассуждений особенно важны для сложной математики: обучение только на коротких решениях (CoT < 8 тыс. токенов) заметно ухудшало качество, тогда как выбрасывание коротких решений было нейтральным или слегка положительным. Поэтому в релизной конфигурации мы оставляли решения длиной более 8 тысяч токенов.

Перед обучением из корпуса дополнительно вычищались кодовые задачи (LLM по условиям и регулярками после генерации, ≈600 млн токенов) и зацикливания.

Наши приёмочные эксперименты показали рост результатов на математических бенчмарках (AIME, HMMT, IMO) как после претрейна, так и после алайнмента. Кроме того, мы проверили, что при масштабировании обучения приросты увеличиваются, и все наши выводы и результаты перенеслись и на релизное обучение.

Мы выяснили ещё несколько моментов.

Более сложные способы фильтрации — попробовали другие методы фильтрации сложных/качественных решений, и ни один из них не вошёл в финальный пайплайн:

• Отбор сложных задач по прокси‑метрикам сложности. Идея — заглянуть в ризонинг и посчитать количество паттернов рассуждений — бэктрекинг, верификация, постановка промежуточных целей, число «полезных» шагов. Все метрики сильно коррелировали с длиной CoT. Отбор по наличию бэктрекинга давал маргинальный прирост поверх фильтрации по длине, по верификации и subgoal setting — не давал ничего; при этом подсчёт паттернов дорог.

• Фильтрация правильных решений по ответу, извлечённому из исходного документа — эксперимент получился красным, вероятно, из‑за низкого качества извлечённых ответов и/или парсинга условий. Анализ показал, что в заметной доле документов ответ не соответствует условию (например, из задачи пропала часть условия), в итоге модель решает задачу правильно, но отфильтровывается, что роняет качество.

При этом сама по себе фильтрация по majority score полезна, а её отсутствие ухудшает бенчмарки. Сам же порог majority score (перебирали значения 0,375 / 0,5 / 0,75 и интервалы) не так важен и слабо влияет на результаты.

Сложность самих задач важна не меньше, чем длина трейса. Ухудшающий эксперимент — простые задачи из обычного паверапа с рассуждениями сильной модели — получился красным. То есть качественные reasoning‑трейсы поверх лёгких условий не дают роста на сложной математике.

7.2.2 Код

Рассказывает Дмитрий Лунин @lunin

Для обучения кодовым рассуждениям мы собрали синтетический корпус сложных задач на олимпиадное программирование. 

В синтетических данных по коду прежде всего необходимо было добиться высокой сложности задач, а также использовать сильные модели для их решения. Задачи создавались двумя способами. В первом подходе модель брала идеи из научных статей по Computer Science и на их основе формулировала полноценную задачу: писала условие, задавала ограничения, приводила примеры и генерировала код для создания и проверки тестов. Во втором подходе мы сгенерировали список из тысячи алгоритмов и генерировали задачи, в которых они должны применяться. Дальше в обоих подходах мы скрещивали задачи, чтобы повысить их сложность: подавали на вход LLM пары задач с решениями и запрос на составление задачи, которая объединяет в себе две исходные.

Для каждой задачи мы генерировали подробное рассуждение, решение на Python и набор тестов. Поскольку корректность кода можно проверить исполнением, значительную часть фильтрации удалось автоматизировать. Мы запускали сгенерированные решения на эталонных тестах, а сгенерированные тесты — на известных правильных решениях. Такой подход позволял отсеивать неработающий код, некорректные тесты и задачи с противоречиями между условием и примерами.

7.3 Почему только ризонинга недостаточно для агентов

На раннем этапе работы над reasoning‑корпусом мы в основном фокусировались на примерах решения сложных задач. Чтобы проверить, насколько такое обучение развивает агентские навыки, мы провели контролируемый эксперимент: взяли одну и ту же раннюю версию SFT с примерами агентских взаимодействий и применили её к нашей первой версии модели и к Qwen3A-35B‑Base.

Модель, обученная только на reasoning‑данных, заметно уступала Qwen на большинстве агентских бенчмарков. Это показало, что одних примеров сложных рассуждений недостаточно для формирования устойчивых навыков работы с инструментами и средами. После добавления в предобучающий корпус первых версий AWM‑ и GEM‑данных разрыв существенно сократился: на части бенчмарков наша модель сравнялась с Qwen или превзошла её. 

Кроме того, мы сравнили RLVR‑обучение двух версий претрейн‑модели: reasoning‑only и версии, в претрейн которой были добавлены примеры агентских взаимодействий. Перед RLVR обе модели прошли одинаковый этап SFT. Модель, обученная на агентских взаимодействиях ещё во время претрейна, вела себя стабильнее на этапе RLVR и выходила на более высокое плато качества по бенчмаркам.

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

7.4 Агентские данные

Для обучения модели работе с инструментами мы используем несколько типов данных. Первый тип — многошаговые тексты из предобучающего корпуса, преобразованные в последовательности вызовов инструментов по аналогии с подходом из статьи Unlocking Implicit Experience: Synthesizing Tool‑Use Trajectories from Text (GEM‑данные). Второй — траектории, собранные во время собственного RL‑обучения; похожий подход применялся, например, при улучшении DeepSearch‑моделей Alibaba в работе Scaling Agents via Continual Pre‑training. Третий тип — взаимодействия с синтетическими средами, которые мы генерируем в масштабе предобучения с помощью AWM‑подобного пайплайна. Наконец, мы отдельно готовим данные для специализированных сценариев, в том числе поиска и решения задач программной инженерии.

7.4.1 CRUD-сценарии

Значительная часть продуктовых агентных сценариев сводится к работе с изменяемым состоянием: модель должна находить и создавать объекты, обновлять их поля, удалять записи и проверять результат выполненных действий. Такие задачи требуют не только корректно выбрать инструмент, но и спланировать последовательность вызовов, передать между ними необходимые данные и сохранить согласованность состояния. Поэтому CRUD‑сценарии занимают важное место в нашем агентном корпусе.

Эффективный способ масштабировать такие данные был предложен в работе Agent World Model (AWM). Для генерации собственных данных и сред для обучения команда посттрейна Alice AI LLM построила похожий пайплайн и расширила его генерацией заданий разных уровней сложности, а также рубриками для автоматической оценки их выполнения. Схема пайплайна представлена на рисунке 20.

При генерации получаются среды с большим количеством таблиц и тулов, однако они получаются сравнительно простыми: с плоской структурой и небольшим количеством параметров. На рисунке 21 представлены гистограммы распределения количества тулов и таблиц в среде при генерации данным пайплайном.

Тем не менее, даже при плоской структуре тулов задачи получаются достаточно сложными: в таблице 24 приведены средние характеристики траекторий GLM-5.2 на простых и сложных заданиях. Мы использовали длину траектории как косвенный показатель сложности задания; ручная проверка подтвердила, что новые среды действительно требуют более длинной и содержательной последовательности действий.

_{Таблица 24}

Исходные среды и задания AWM мы не включали в обучение, а использовали для построения отложенного бенчмарка. Чтобы ускорить оценку, из полного набора мы выбрали 600 заданий с наибольшей дисперсией результатов между пятью внутренними и внешними моделями. Такой отбор оставляет примеры, которые лучше всего различают модели по качеству. Ручная проверка выявила в исходном наборе сломанные среды и шумные задания, поэтому абсолютные значения метрик на этом бенчмарке следует интерпретировать с осторожностью. Тем не менее он оказался чувствительным к изменениям в обучающих данных и давал полезный сигнал при сравнении экспериментов. В таблице 25 представлены скоры открытых и закрытых моделей на нашем бенчмарке.

_{Таблица 25}

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

Для каждого задания мы запускали четыре независимые траектории взаимодействия модели со средой. В результате был собран агентный корпус общим объёмом 7 млрд токенов.

7.4.2 Поисковые вопросы

Для развития поисковых навыков мы генерируем сложные многошаговые вопросы на основе веб‑документов, на основе которых затем получаем примеры долгих поисковых сессий. Пайплайн начинает с исходной страницы, извлекает из неё фактологический вопрос с коротким ответом‑сущностью, а затем использует этот ответ для поиска следующего документа. Из найденного документа выбирается новая сущность, связанная с предыдущей, и процесс повторяется, формируя цепочку до десяти переходов. После этого цепочка разворачивается: на её основе создаётся единый вопрос, для ответа на который необходимо последовательно восстановить промежуточные связи и выполнить не менее восьми поисковых шагов. Готовые примеры дополнительно проходят автоматическую критику, доработку и проверки на однозначность, отвечаемость, отсутствие прямых подсказок и поисковых сокращений. Алгоритм генерации вопросов представлен на рисунке 22.

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

_{Таблица 26}

Для корпуса reasoning‑этапа мы подготовили 10 тысяч таких вопросов и сгенерировали на их основе около 1 млрд токенов поисковых траекторий.

В результате добавления таких данных в претрейн в экспериментах мы наблюдали рост результатов на бенчмарке BrowseCompPlus на ~3 п. п.

7.4.3 SWE

Для улучшения качества SWE‑сценариев мы использовали подход, предложенный в daVinci‑Dev: Agent‑native Mid‑training for Software Engineering: сочетание сгенерированных траекторий и agentless‑данных.

В результате добавления таких данных в экспериментах мы наблюдали значительный рост результатов на внутреннем бенчмарке SweProxy на 7 п. п. и рост результатов на SWE на 3 п. п.

8. Какой формат данных использовать для дообучения нашей модели

Для подготовки агентских данных мы использовали стандартный формат OpenAI Messages. В нём траектория представлена последовательностью сообщений с ролями system, user, assistant, tool и meta; определения доступных инструментов передаются отдельно в поле tools.

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

Если модель требуется дополнительно обучать — как с помощью supervised fine‑tuning, так и с помощью RL, — мы рекомендуем хранить данные в формате OpenAI Messages и рендерить их с помощью Jinja‑шаблона, который также доступен на Hugging Face. Это обеспечивает совпадение формата новых данных с форматом, который модель видела во время претрейна.

9. Команда

Аналитики: Ира Ляликова, Татьяна Таекина, Анастасия Волотова, Ассоль Кубаева, Кирилл Алексеев, Павел Отливанчик, Мухаммадфирдавс Косимов, Влад Негодин.

ML‑качество: Скачков Николай, Екатерина Редина, Максим Коноплев, Евгений Усков, Вероника Зыкова, Иван Цариков, Артемий Захаров, Мария Годунова, Дмитрий Лунин, Мария Никифорова, Антон Кальсин, Даниил Пантелеев, Алексей Герасев, Илья Копытин, Ермек Капушев, Егор Ляхов.

ML‑архитектура: Максим Абрахам, Иван Виноградов, Антон Андрющенко, Максим Никитин, Даниил Сухой, Александр Мазитов, Филипп Змушко, Максим Игнатов.

Инфраструктура инференса: Иван Сапожков, Тимофей Бызов, Эдгар Шмавонян.

Отдельное спасибо за вычитку и правки Александру Боймелю, Петру Ермакову и Тимуру Гаскарову.