Яндекс представил Sona: как одна ИИ-модель формирует персональные рекомендации

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

1 октября 2026 года Яндекс представил Sona — генеративную рекомендательную модель, которая объединяет подбор вариантов и их ранжирование. Компания проверила её в музыкальных рекомендациях умных колонок с Алисой: в недельном эксперименте время прослушивания рекомендованных треков в тестовой группе выросло на 6,3%. Эта цифра относится к музыке и конкретному сравнению с действующей системой. Переносить её на конверсию интернет-магазина или рост продаж оснований нет.

Почему рекомендация начинается раньше, чем появляется на экране

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

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

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

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

Что означает единая модель в случае Sona

В техническом отчёте команды Sona подбор и ранжирование используют общее представление истории пользователя. Рабочая модель содержит кодировщик, декодировщик и модуль ранжирования; модель-учитель участвует только в обучении. Следовательно, единство подхода сохраняет внутренние компоненты.

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

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

Объединение этапов может быть интересным направлением разработки. При этом оно не освобождает команду от обработки данных, проверки качества и управления системой. Чтобы правильно интерпретировать реакцию пользователя, всё равно нужно различать просмотр, выбор, пропуск, покупку и случайное действие. Название архитектуры не исправит неверно записанную историю.

Как читать результат музыкального эксперимента

Технический отчёт уточняет условия теста: семь дней, случайное распределение, по 15% пользователей в двух группах. Время прослушивания выросло на 6,30%, число активных пользователей — на 4,53%. Отчёт появился в августе, публичный анонс — в октябре.

Относительное изменение удобно показать на условных числах. Если сопоставимый контрольный объём составляет 100 000 минут, прибавка 6,3% соответствует 6 300 минутам. Эти значения придуманы для объяснения процента и не раскрывают фактическую аудиторию Яндекса. По одной относительной цифре нельзя узнать общий объём прослушивания, число участников или денежный эффект.

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

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

Что из этой новости полезно владельцу каталога

Готовый сервис для подключения Sona к интернет-магазину в прочитанном анонсе не заявлен. Практическая польза новости для такой компании — понять, что следует проверять в собственных рекомендациях. Начать можно с трёх разных задач: помочь выбрать альтернативу, предложить совместимое дополнение или показать материал, который снимает конкретное сомнение перед заказом.

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

Для собственного разбора можно записать несколько сценариев и проверить, какие предложения видит человек:

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

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

Сначала определить пользу, затем выбирать технологию

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

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

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