Yandex Sona: как одна AI-модель заменяет весь конвейер рекомендаций

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

Такая каскадная архитектура десятилетиями была естественным способом решать задачу в больших каталогах. Однако вместе с качеством растёт и сложность: появляются независимые модели, разные представления пользователя, отдельные feature pipelines, повторные вычисления истории и несколько этапов serving.

Yandex Sona интересна именно попыткой изменить эту границу. Это не поисковый алгоритм Яндекса и не универсальный AI-сервис. Sona — single-model generative recommender для Яндекс Музыки, в котором генерация кандидатов и последующее ранжирование строятся вокруг общего представления пользователя. В финальном production-эксперименте модель заменила каскад, включавший более 15 candidate generators, pre-ranking и ranking.

Почему recommendation pipeline вообще превращается в каскад

Представим крупный интернет-магазин с миллионами товаров. Пересчитать полноценный дорогой ranking score для всего каталога при каждом открытии главной страницы практически невозможно. Поэтому задача обычно делится на уровни.

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

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

Дальше более дорогой pre-ranking сокращает список, а ranking оценивает оставшиеся объекты точнее. Иногда после него есть ещё re-ranking, который уже формирует окончательный порядок с учётом diversity, freshness и других продуктовых условий.

Условно такой процесс выглядит так:

Этап	Каскадная система	Unified-подход
Получение кандидатов	несколько отдельных генераторов	генеративная часть общей модели
Представление пользователя	может вычисляться разными компонентами	общее представление используется несколькими задачами
Pre-ranking	отдельная модель или несколько стадий	часть промежуточного каскада потенциально исчезает
Финальный ranking	отдельный ranker	Ranking Module работает с тем же user state
Оптимизация	компоненты часто развиваются раздельно	generation и ranking можно обучать более связанно
Serving	несколько сервисов и feature pipelines	потенциально более цельный serving path

Это не означает, что unified model автоматически проще во всех отношениях. Сложность может переместиться из orchestration и feature engineering в обучение, инфраструктуру модели и online serving.

Именно поэтому Sona важна не как лозунг «одна нейросеть лучше пятнадцати», а как production-проверка другого способа разделить вычисления.

Что именно Sona объединяет в одной модели

Technical report описывает Sona как генеративную рекомендательную систему с shared user representation. Encoder получает хронологическую последовательность событий пользователя и формирует hidden states. Эти состояния используются сразу двумя основными частями serving-модели: autoregressive decoder и Ranking Module.

Decoder отвечает за генерацию кандидатов. Ranking Module затем оценивает и упорядочивает полученные объекты, но ему не требуется независимо заново строить полное представление истории пользователя: оба компонента используют результат одного encoder pass. В финальной конфигурации production serving состоит из encoder, decoder, преобразования Semantic ID в элементы каталога и Ranking Module.

При обучении есть ещё Teacher Ranker. Он предоставляет ranking targets для distillation, однако в финальном serving path этого более крупного teacher нет. Поэтому формулировка «single model» не означает, что обучение обходится без дополнительных компонентов; она относится прежде всего к развернутой модели, обслуживающей рекомендации.

Shared user representation связывает generation и ranking

В каскаде разные этапы могут смотреть на пользователя через разные наборы признаков или разные модели. Sona строит общий user state из последовательности logged engagement events.

Decoder использует его, чтобы определить, какие объекты стоит сгенерировать как кандидатов. Ranking Module использует то же encoded history, чтобы решить, какие из полученных кандидатов должны оказаться выше.

При обучении оба направления также связаны: next-token prediction для генеративной части и distillation objective для Ranking Module обновляют общий encoder. Авторы technical report рассматривают это как способ связать generation и ranking не только на serving, но и на уровне обучения представления пользователя.

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

Это не отменяет различия между retrieval и ranking как задачами. Sona не просто генерирует финальный список последовательностью токенов: после генерации конкретные catalog items дополнительно упорядочиваются Ranking Module.

Зачем модели Semantic IDs

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

В Sona объект представляется последовательностью learned Semantic IDs. Decoder генерирует такие идентификаторы авторегрессионно, после чего они разрешаются в реальные элементы каталога, а Ranking Module получает конкретных кандидатов для окончательной оценки.

Важно не воспринимать слово semantic слишком буквально. Это не текстовые категории вроде «рок», «джаз» или «популярное». Это обученные дискретные представления объектов. Technical report отдельно описывает их построение, однако для понимания общей системы достаточно ключевой идеи: decoder работает с компактным learned representation каталога, а финальное ранжирование происходит уже на уровне конкретных items.

Подобное направление развивалось у Яндекса и до Sona. Например, Gryphon также объединял Semantic-ID generation с item-level scoring и использовал общее представление пользователя. В его production-эксперименте модель смогла заменить более 15 candidate generators и отдельный pre-ranking, но ещё не весь финальный recommendation cascade.

Sona делает следующий шаг: в заявленном финальном эксперименте одной served model заменены candidate generation, pre-ranking и ranking.

Что показал live A/B experiment

Самая сильная часть истории Sona — не offline benchmark, а production A/B experiment.

В финальном эксперименте модель работала на live traffic «Моей волны» на умных колонках — одном из recommendation surfaces Яндекс Музыки. Для test group Sona заменила production cascade, состоявший более чем из 15 candidate generators и последующих pre-ranking и ranking models.

Technical report приводит следующие относительные изменения по сравнению с control:

• Active Users: +4.53%;
• Total Listening Time: +6.30%;
• Likes: +11.42%;
• Repeat Commands: +17.99%;
• Deeply Engaged Users: +7.37%.

Все перечисленные изменения в финальном эксперименте авторы paper описывают как статистически значимые. Primary metric — Active Users. Её uplift +4.53% оказался в 2.35 раза выше прироста +1.93%, который ранее дал Argus на том же recommendation surface.

Официальная публикация Яндекса от 2 октября 2026 года сообщает об этом же production experiment и описывает его как семидневный тест. В пресс-релизе часть значений округлена — например, listening time до 6.3% и active listeners до 4.5%; для технического разбора корректнее использовать точные значения из paper.

Здесь особенно важна граница интерпретации.

Результат показывает, что на конкретном production surface Яндекс Музыки single jointly trained model смогла заменить зрелый многоступенчатый каскад и одновременно улучшить измеряемые engagement metrics.

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

Почему такая архитектура интересна интернет-магазинам

Для e-commerce Sona важна прежде всего не своими музыкальными метриками, а архитектурной идеей.

Представим магазин, у которого сегодня работает цепочка:

candidate retrieval → business rules → pre-ranking → ranking → re-ranking.

Retrieval обслуживается несколькими моделями. Pre-ranking имеет собственный набор признаков. Ranking ещё раз обрабатывает историю пользователя, а поверх результатов работает отдельный слой правил.

Unified generative recommender предлагает другую точку сборки: получить единое представление поведения пользователя, использовать его для генерации кандидатов и одновременно дать ranking-компоненту доступ к тому же состоянию.

Потенциальные преимущества понятны.

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

Во-вторых, generation и ranking могут обучаться более согласованно. Ошибку ранжирования не обязательно рассматривать исключительно как проблему последней стадии: общий encoder получает сигнал от обеих задач.

В-третьих, исчезает часть повторной обработки user history. В Sona encoder states используются decoder и Ranking Module совместно.

В-четвёртых, pipeline потенциально становится цельнее с точки зрения serving и экспериментов.

Но отсюда не следует, что интернет-магазину достаточно «поставить Sona вместо рекомендательной системы». Sona не заявлена как готовый e-commerce-продукт, а результаты Яндекс Музыки не являются прогнозом для CTR, add-to-cart или conversion rate магазина.

Цена объединения: какие trade-offs остаются

Уменьшение количества serving stages не означает исчезновения архитектурных компромиссов.

Training complexity

Joint training generation и ranking сложнее, чем обучение одной небольшой retrieval model. В случае Sona используется distillation от Teacher Ranker, совместные training objectives и отдельная инфраструктура подготовки learned representations. Это другая форма сложности, а не её полное исчезновение.

Serving cost

Одна deployed model может сократить orchestration между сервисами, но сама generative architecture способна быть вычислительно тяжёлой. Для реального продукта необходимо считать latency, GPU cost, throughput и стоимость одного recommendation request, а не только количество моделей на архитектурной диаграмме.

Data requirements

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

Controllability

У e-commerce есть ограничения, которых нет в чистой постановке ranking quality: остатки, маржинальность, юридические ограничения, sponsored placements, diversity продавцов, сроки доставки и contractual rules.

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

Cold start

Semantic representations могут помогать использовать сходство между объектами, но проблема cold start не исчезает магически. Новый товар, новый пользователь или новая категория всё равно требуют стратегии работы с недостаточной историей.

Explainability

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

В традиционном каскаде это иногда проще локализовать: retrieval дал кандидата, pre-ranker пропустил, ranker поднял. В unified architecture границы могут быть менее очевидны.

Online experiments

Offline-метрика не отвечает на главный продуктовый вопрос. Это хорошо видно и по развитию генеративных recommenders Яндекса.

Предшествующий Gryphon в семидневном production A/B test смог заменить более 15 candidate generators и pre-ranking, но изменение Total Listening Time +0.25% не было статистически значимым. Позже Gryphon-v2 уже заменил более широкий каскад и дал +1.41% Active Users на тестируемом recommendation surface. Финальная Sona показала следующий результат на том же общем направлении развития архитектуры.

Поэтому архитектурное упрощение само по себе не равно продуктовому выигрышу. Его всё равно приходится доказывать online.

Что Sona действительно меняет в разговоре о recommender systems

Главная ценность Sona — не в том, что теперь всем компаниям нужно срочно отказаться от retrieval, feature stores и отдельных ranking models.

Важнее сам production precedent: генеративная модель перестала быть только механизмом candidate generation и смогла взять на себя полноценную цепочку generation + ranking в зрелой рекомендательной системе.

Яндекс формулирует заявление ещё сильнее и называет Sona первой публично документированной рекомендательной системой, которая в live production продемонстрировала замену полного многоступенчатого recommendation cascade одной моделью без hand-engineered features с одновременным статистически значимым улучшением пользовательских метрик. Это именно формулировка компании, и её корректно сохранять только в таком узком контексте.

Не менее важно уточнение про hand-engineered features. Technical report утверждает, что Sona и её Teacher Ranker работают с logged event fields и learned item representations, не используя вручную сконструированные признаки. Из этого нельзя выводить универсальное правило, будто feature engineering больше не нужен рекомендательным системам как классу.

Для архитектора продукта вывод более практичный: граница между retrieval и ranking становится предметом выбора, а не неизбежным свойством recommender stack.

Команде, которая сегодня поддерживает пять генераторов кандидатов, два уровня ranking, несколько независимых representations пользователя и тяжёлый feature pipeline, уже имеет смысл задавать вопрос: какие этапы действительно должны оставаться независимыми?

Что проверять перед переходом к unified recommender

Начинать стоит не с выбора конкретной нейросетевой архитектуры, а с карты текущей системы.

Нужно понять:

• сколько раз за один request независимо кодируется история пользователя;
• сколько candidate generators реально дают уникальный incremental recall;
• какие признаки используются одновременно несколькими стадиями;
• где находятся основные latency и инфраструктурные затраты;
• какие business rules нельзя безопасно перенести внутрь обучаемой модели;
• как будут измеряться retrieval quality, ranking quality и итоговый product uplift;
• можно ли безопасно провести ограниченный online A/B experiment;
• есть ли rollback path, если единая система ухудшит важную вторичную метрику.

Для интернет-магазина эксперимент разумно начинать не с обещания заменить весь stack, а с конкретной проверяемой гипотезы. Например: общий encoder и совместное обучение generation/ranking способны сохранить или улучшить ключевые метрики при меньшем количестве отдельных serving components.

Только после этого имеет смысл измерять latency, стоимость, stability, conversion, revenue per session, diversity, coverage и влияние business constraints.

История Sona хорошо показывает разницу между технологической идеей и доказательством. Идея unified recommendation выглядит привлекательной на схеме. Доказательством она становится только тогда, когда одна модель выходит на реальный трафик и выдерживает сравнение с зрелым production cascade.

При этом Sona остаётся примером из Яндекс Музыки, а не готовым рецептом для любого digital-продукта. Именно эта оговорка делает результат полезнее: архитекторы получают не очередное обещание «AI заменит всё», а проверенный production case с чёткими границами применимости.

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