Быстрый ответ Алисы AI — это самый массовый генеративный продукт Яндекса и первое соприкосновение с Алисой для пользователей Поиска. 

Даже в час пиковой нагрузки пользователь должен получить лаконичный ответ за считаные секунды. Для этого мы, команда Alice AI Search, адаптируем весь пайплайн быстрых ответов — от собственного претрейна с кастомной архитектурой до онлайн‑rl‑обучения на поведенческие сигналы пользователей.

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

Кроме того, мы выложили в открытый доступ обученную с нуля модель Alice AI‑T5-35B‑A0.6B Base с тем ограничением, что внешним пользователям доступен инференс через Hugging Face Transformers, а оптимизированный production‑инференс пока доступен только внутри Яндекса.

Как устроен быстрый ответ Алисы AI

Быстрый ответ Алисы AI строится на той же инфраструктуре, что и ответ Алисы в чате. Её устройство подробно разбирали в отдельной статье, поэтому здесь лишь кратко напомним суть:

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

• Все текстовые документы обрабатывает следующая модель, которая оставляет только релевантные запросу части текста — мы их называем инфоконтексты (далее — ИК).

• На последнем этапе ИК вместе с изображениями, видео и другими найденными материалами поступают в модель, которая формирует итоговый ответ Alice AI. 

Дальше подробнее разберём ключевые изменения на каждом из этапов.

Этап Agentic Search

Рассказывают Назар Погосский и Никита Cемёнов

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

Человек обычно открывает топ поисковой выдачи и выборочно читает нужные части найденных документов. Языковая модель работает иначе: она последовательно обрабатывает весь переданный контекст. Это, с одной стороны, помогает языковой модели собрать всю полноту информации, но с другой — требует много вычислений. Чтобы адаптировать Поиск к этим особенностям, полгода назад в Яндексе появилось направление Agentic Search. Главная задача: оптимизировать поисковые технологии для всех моделей семейства Alice AI.

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

Модель — экстрактор инфоконтекстов

Для этой задачи мы с нуля обучили «крошечную» BERT‑подобную модель на 80 млн параметров. Обучающая выборка включала 4 трлн токенов из нашего корпуса. Затем мы дообучили модель определять релевантность каждого токена в документе. Разметку для этого собрали через опенсорсные LLM. Так мы получили cold start‑версию экстрактора, которая уже неплохо решает поставленную задачу.

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

Для поиска оптимального содержания инфоконтекста для нашей модели мы собрали алгоритм на основе Cross‑Entropy RL:

Для каждого документа модель‑экстрактор оценивает вероятность релевантности каждого токена: , если , то мы считаем токен релевантным и, конкатенируя их, получаем .

Модель, которая по запросу и одному инфоконтексту даёт ответ , получает реворд .

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

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

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

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

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

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

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

Этап Pretrain

Рассказывает Антон Викторов

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

У нашей прошлой модели была Encoder‑Decoder‑архитектура, и она хорошо зарекомендовала себя на работе с текстом и на rag‑задачах. Мы хотели улучшить её, добавив MoE‑слои, которые позволяют существенно увеличить ёмкость модели и объём знаний без пропорционального увеличения вычислительных затрат.

Среди современных крупных опенсорс‑моделей мы не нашли распространённых архитектур Encoder‑Decoder MoE. Ближайшие примеры от крупных исследовательских команд — NLLB‑MoE, Switch Transformer и FLAN‑MoE — были опубликованы в 2021–2023 годах. Так родилась идея попробовать обучить современный гибрид этих архитектур.

Alice AI‑T5-35B‑A0.6B — Encoder‑Decoder‑модель с разреженной MoE‑архитектурой. 

Модель обучалась на 15T токенов собственного корпуса данных на задачу UL2-денойзинга и расширением контекста с 8K до 128K в конце обучения при помощи YaRN. Корпус был существенно улучшен относительно последнего опенсорсного релиза, но об этом коллеги расскажут в отдельном посте.

Мы использовали Muon, который ортогонализует обновления матричных весов с помощью итераций Newton — Schulz. В наших экспериментах он оказался лучше Adan и AdamW.

Для MoE‑роутинга мы сначала использовали aux‑based‑балансировку (в духе Macro‑LBL из статьи Demons in the Detail):

где: — основной лосс,  — коэффициент балансировки,  — число экспертов,  — доля токенов у эксперта ,  — total routing probability для эксперта .

Она добавляет к языковому лоссу вспомогательный штраф для балансировки экспертов.

Похожие подходы уже использовали авторы статей по обучению моделей Encoder‑Decoder MoE. Однако мы обучали модель на значительно большем объёме данных, и при таком масштабировании подход оказался нестабильным: роутинг в encoder‑части модели коллапсировал. Поэтому мы перешли на aux‑free routing из DeepSeek‑V3. 

где:  — routing score эксперта для токена ,  — балансирующий bias эксперта,  — шаг обновления bias.

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

Результаты

Для быстрых ответов Алисы AI нам важен баланс качества и стоимости инференса. В результате Alice AI‑T5-35B‑A0.6B оказывается в области лучших компромиссов между качеством и скоростью.

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

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

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

Alice AI‑T5-35B‑A0.6B превосходит все рассмотренные модели, кроме Qwen 3.5–35B‑A3B, которая значительно тяжелее в инференсе.

Рассмотренная нами архитектура T5 MoE хорошо справляется с поставленной перед ней задачей — быстро давать умные ответы, опираясь на результаты Поиска. Именно в таком режиме особенно проявляются преимущества Encoder‑Decoder‑ и разреженной MoE‑архитектуры. В других сценариях баланс между качеством и скоростью может быть иным, особенно по мере дальнейшего ускорения инференса decoder‑only LLM.

Этап Alignment

Рассказывает Дмитрий Калашников

SFT: Закладываем базовые паттерны ответа

На этапе SFT мы учим модель разнообразным паттернам, задаём структуру ответов и базовые принципы поведения на разных типах запросов. Именно здесь формируются специфичные навыки и поведенческие паттерны, которые позже можно дополнительно усилить на стадии RLHF.

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

Как мы получаем ответы для SFT

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

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

Но здесь возникает вопрос: как выбрать лучший ответ? Для оценки кандидатов в нашем распоряжении есть десяток rule‑based‑ и model‑based‑сигналов качества. Есть как универсальные критерии — например, полезность и фактологическая точность, — так и специфичные для отдельных срезов и продуктовых сценариев. Скажем, на еком‑срезе одним из таких критериев была практическая применимость ответа, а на срезе образования может быть проверка rule‑based‑корректности ответа.

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

Однако Rejection Sampling работает хорошо до тех пор, пока достаточно качественный ответ вообще присутствует среди сгенерированных кандидатов. Но на сложных срезах или на «выбраковке» (дизлайках от пользователей) это происходит не всегда. 

В таких случаях мы используем отдельный пайплайн Critique & Revision.

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

RLHF: двигаем верхнюю границу качества

Сердце нашего RLHF‑пайплайна — алгоритм GRPO, а точнее, его модификация GSPO. 

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

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

VeRL и Encoder‑Decoder

Ещё год назад основным нашим алгоритмом RLHF был DPO, реализованный на внутреннем фреймворке обучения Яндекса. Но стандартом в LLM становился GRPO. VeRL был одним из популярных фреймворков обучения. Однако он рассчитан преимущественно на decoder‑only‑архитектуры: на этапе роллаута фреймворк использует специализированные движки инференса, в частности vLLM. Поэтому для нашей Encoder‑Decoder‑архитектуры коллеги доработали внутреннюю версию VeRL, сделав кастомный роллаут на внутренней библиотеке инференса. 

Переход на online‑RL в несколько раз сократил время одного цикла RL‑эксперимента, а модель после перехода почти сразу превзошла предыдущую с winrate 60%. После добавления пайплайна генерации и переписывания ответов новая модель превзошла предыдущую с winrate > 70%.

Онлайн‑сигналы

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

Сколько времени пользователь читал ответ Алисы? Хватило ли ему полученной информации, или после ответа он продолжил поиск? Эти и многие другие сигналы помогают оценить, насколько хорошо Поиск решил задачу пользователя. Их совокупность учитывается в метрике Профицит — одной из ключевых онлайн‑метрик, по которым мы оцениваем, насколько успешно Поиск решил задачу пользователя.

Для оптимизации ответов на Профицит мы моделируем этот сигнал, обучая отдельную реворд‑модель. Дальше используем её как один из сигналов в RLHF наряду с офлайн‑ревордами. Ключевая проблема в этой задаче — онлайн‑сигналы от реальных пользователей зачастую очень шумные, так как пользователи могут взаимодействовать с продуктом хаотично. Из‑за этого обучающая выборка в виде простого семпла «запрос — ответ — значение Профицита» не позволяет обучить качественный реворд. Для борьбы с шумом мы используем агрегацию (нас интересуют ответы, показанные на один и тот же запрос несколько раз), фильтрацию и pairwise‑постановку обучения, а также стратифицируем пары по устройству пользователя (поведение пользователя за компьютером и на мобильных устройствах отличается).

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

где ,  — разброс Профицита, а ,  — количество показов двух ответов.

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

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

Посмотрим на примере запроса «разбаловка английский огэ»:

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

Если пользователь успешно решил задачу, он с большей вероятностью вернётся в Поиск с новой. Эту связь мы видим в A/B‑экспериментах с крупными обновлениями Алисы: вместе с ростом доли успешно решённых задач растёт и количество новых поисковых сессий пользователей. 

В итоге в абляционном A/B‑эксперименте обученная реворд‑модель дала статистически значимый рост Профицита и SPU — числа сессий на пользователя.

Заключение

Мы разобрали весь путь генеративного ответа Алисы в Поиске — от сбора и фильтрации контекста до претрейна собственной модели и обучения на пользовательских сигналах. Впервые раскрыли параметры Alice AI‑T5-35B‑A0.6B и выложили в открытый доступ претрейн‑модель, которую обучили с нуля и используем в продакшене. Модель показывает хорошие результаты на бенчмарках фактологичности и работы с контекстом, а также может быть полезна исследователям в области LLM‑архитектуры.

Новая модель показала значительный прирост качества — достаточный, чтобы успешно решать задачи пользователя даже на таких сложных срезах, как закон и медицина, а также лучше помогать в еком‑сценариях. Реальный эффект подтверждён как офлайн‑SbS с прямым конкурентом Google AI Overview, так и онлайн в A/B‑тестировании на реальных пользователях:

В конце хочется отметить, что такого результата мы достигли через коллаборацию разных команд Яндекса — аналитики, инфраструктуры, фронтенда, и в том числе команд, отвечающих за более крупные версии модели Алисы, — мы очень им благодарны за помощь!

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

А если хотите узнать ещё больше подробностей про Alice AI Search и как формируются быстрые ответы на Поиске, приходите на Practical ML Conf 2026 19 сентября.