Генеративная модель персонализации ARGUS: как Яндекс переосмыслил рекомендательные системы

Рекомендательные системы зашли в тупик. И вот почему

Большинство современных рекомендательных систем (RS) — это тупая карусель из матричных разложений и градиентного бустинга. Они смотрят на историю кликов, взвешивают признаки, и выдают топ-N. Вроде работает, но есть одна мерзкая проблема: модель учится просто сравнивать объекты, а не понимать пользователя. Она не знает, почему ты кликнул на кота в сапогах — она просто запоминает, что кот в сапогах похож на других котов в сапогах. И следующие 50 часов ты видишь антропоморфных кошек.

Классика жанра — двухбашенные модели (DSSM), широко-глубокие сети (Wide & Deep), NFM, DCN. Всё это, по сути, регрессоры: score(user, item). Они прекрасно ранжируют, но не умеют генерировать. Не могут предсказать, что пользователю захочется завтра, если такого паттерна не было в train'e. А если пользователь новый — холодный старт, до свидания.

Яндекс, который кормит с ложечки рекомендациями больше половины Рунета (Поиск, Музыка, Видео, Едадил, Кинопоиск), упёрся в потолок этой парадигмы. И они решили: а давайте смотреть на задачу как на генерацию последовательности. Как GPT пишет текст, так и рекомендательная система будет генерировать цепочку будущих действий пользователя. Так родился ARGUS — генеративная модель персонализации.

Идея: закодировать историю в токены и предсказывать следующий

Базовая парадигма RS: взять историю пользователя U = {item1, item2, ..., itemN} и для каждого кандидата вычислить скор. В ARGUS подход кардинально иной: модель генерирует саму последовательность будущих сегментов потребления. То есть не скор, а набор токенов, которые затем декодируются в рекомендации.

Для этого всю историю пользователя преобразуют в последовательность токенов действий. Каждое действие — это не просто ID товара, а структурированный набор: тип действия (клик, просмотр, покупка, прослушивание), временная метка, категория, субкатегория, контекст (день недели, устройство, гео). Всё это конкатенируется в последовательность, как sentence piece в NLP.

Пример токенизации:

{
  "action_seq": [
    {"type": "view", "item_id": 4521, "cat": "electronics", "ts": 1716200000},
    {"type": "click", "item_id": 4521, "cat": "electronics", "ts": 1716201000},
    {"type": "purchase", "item_id": 8912, "cat": "books", "ts": 1716210000}
  ]
}

Каждое действие превращается в вектор эмбеддингов через многоуровневую таблицу: отдельные эмбеддинги для item_id, категории, типа, позиции во времени. Затем эти векторы склеиваются и подаются в Transformer Decoder, который обучается предсказывать следующее действие (авторегрессивно, как в causal LM).

Претрейн: учимся на миллиардах действий

В отличие от RAG-систем, где мы доклеиваем контекст из базы знаний (читайте наш гайд по RAG, чтобы сравнить подходы), ARGUS обучается на historical logs — истории действий десятков миллионов пользователей. Датасет — это последовательности токенов действий, где target — следующее действие. Модель учится минимизировать cross-entropy loss для каждого шага.

Архитектура — vanilla Transformer Decoder с 12-24 слоями и скрытой размерностью 1024. Для эффективности используют смешанную точность (bfloat16) и distributed training на TPU v5p (аренда таких мощностей — отдельная тема, если захотите повторить, понадобятся ресурсы — можно воспользоваться облачными GPU, например, Selectel Cloud GPU).

Особенность претрейна — маскирование временных промежутков. Если в NLP мы маскируем токены, то здесь модель учится предсказывать не только что, но и когда пользователь совершит следующее действие. Для этого временные метки бинаризуются (например, 0–5 минут, 5–30, 30–60, >60) и добавляются как отдельные токены.

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

Каскадная фильтрация: как не сжечь всё железо

Генерировать напрямую Transformer Decoder для каждого пользователя в real-time — утопия. Inference одной модели с сотней миллионов параметров на каждого запроса будет стоить как покупка Яndex.Такси на МКС. Поэтому Яндекc использует каскадную архитектуру (это напоминает пайплайны в гибридном RAG, только без ретривера).

1. Stage 1 — Lightweight Retriever: быстрая фильтрация на основе коллаборативного фильтра (ALS + LSH). Из 100 млн товаров остаётся 10 тысяч.
2. Stage 2 — Transformer Encoder: просчитывает приближенные скоры для всех кандидатов. Использует предтренированные эмбеддинги из ARGUS, но без декодера. Оставляет ~100 кандидатов.
3. Stage 3 — Generative Decoder (финальный этап): только здесь запускается полноценный Transformer Decoder ARGUS. Он генерирует последовательность из 5–10 токенов, которые декодируются в рекомендации. Но декодирование происходит не autoregressive (по одному токену), а за один проход с помощью специальной техники спекулятивного сэмплирования — draft-модель предлагает варианты, а target модель верифицирует.

В итоге на генерацию уходит <5ms на запрос (на CPU) — благодаря оптимизации через ONNX Runtime и квантизацию до int8. Более того, модель может генерировать сразу несколько альтернативных цепочек — вы можете показать пользователю «Если вам понравилось это, попробуйте также» в стиле personlized stories.

Что внутри: детали токенизации и претрейна

Распишем ключевые технические решения, которые делают ARGUS уникальным. Их нужно знать, если вы захотите построить подобное (надеюсь, у вас есть бюджет Яндекса).

1. Иерархическая токенизация категорий

Вместо плоского one-hot используются вложенные категории. Например, товар — «iPhone 15» — кодируется как цепочка: Электроника > Смартфоны > Apple > iPhone 15. Каждый уровень имеет свой эмбеддинг, и они суммируются. Это позволяет модели обобщать: если модель не видела iPhone 15, но знает паттерны для категории «смартфоны Apple», она всё равно сможет дать релевантный прогноз.

2. Временная деформация

Вместо абсолютного таймстемпа модель использует относительные промежутки между действиями + absolute day-of-week, hour-of-day. Это делает инвариантным к конкретным датам, что важно для pretrain на данных разных лет.

3. Multi-task learning в претрейне

Кроме основной цели (predict next action), модель учится предсказывать вспомогательные признаки: пол пользователя, возрастную группу, LTV (пожизненную ценность). Это заставляет эмбеддинги аккумулировать информацию о пользователе, даже если нет действий — решение проблемы холодного старта.

По сути, ARGUS — это не просто recommendation engine, а фундаментальная модель поведения пользователя. Её можно адаптировать под конкретный сервис дообучением (fine-tune) на данных этого сервиса. Именно так Яндекс и сделал: одна pretrained модель, а затем для Музыки, Видео и Поиска свой лёгкий адаптер (LoRA + small head).

Подводные камни: с чем столкнулись инженеры

• Генерация «мусора». Когда модель не уверена, она начинает генерировать случайные токены, которые не соответствуют реальным товарам. Пришлось ввести фильтр на основе inverse frequency — чем реже встречается сгенерированная категория, тем меньше confidence. Если confidence < порога — отбрасываем.
• Петля популярности. Модель часто предсказывала самые популярные товары (рикроллинг). Решение — dynamic negative sampling: явно контролировать частоту генерации популярных категорий, добавляя penalty в loss на основе логарифма популярности.
• Холодный старт для новых пользователей. Сработал multi-task: для пользователей с 1-2 действиями модель использует контекст (гео, время, устройство) и дефолтные паттерны, усреднённые по похожим юзерам (cluster embedding).
• Стоимость хранения эмбеддингов. Для каждого пользователя пришлось хранить последние ~1000 токенов (примерно 100 Kb в сжатом виде). Для 50M пользователей — 5 Tb. В продакшене используют распределённое in-memory хранилище (аналог Faiss, но для последовательностей).

Кросс-сервисная персонализация на практике

Что это даёт пользователю? Представьте: вы искали рецепт пасты на Поиске, слушали итальянскую музыку на Яндекс Музыке, смотрели трейлер «Ешь, молись, люби» на Кинопоиске. ARGUS, обученная на всех этих действиях, сгенерирует рекомендацию: «Попробуйте уроки итальянской кухни на Яндекс.Видео» — до того, как вы сами подумали об этом. Это не кросс-сейл, а реальное прогнозирование потребностей.

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

Что дальше: прогноз на 2026–2027

Яндекс уже анонсировал, что ARGUS станет основой для нового поколения персонализации в поиске — Generative Search. Пользователь получит не просто релевантные ссылки, а сгенерированный контент, адаптированный под его стиль потребления. Представьте: вы пишете «как приготовить стейк», а поиск выводит не статьи, а короткое видео с любимым блогером, который вы уже смотрели — сгенерированное на основе вашей истории.

Другие игроки (Google, Amazon) тоже идут в эту сторону, но ARGUS — первая продакшен-система с public benchmark. Если хотите наблюдать за развитием, следите за релизами Яндекса в 2026 году. И да, все рассуждения в статье основаны на публичных докладах и исследовательских работах (SIGIR, CIKM), никакой внутренней документации у меня нет.

Часто задаваемые вопросы

Все изображения и примеры кода — схематичные и не отражают реальный код Яндекса. Дата публикации: 21.05.2026.

Подписаться на канал