Последовательную модель нужно было встроить в живую ленту с быстро меняющимися публикациями, социальными связями и ограничением задержки; дорогой текстовый LLM-ранкер не улучшил онлайн-результат.
Чередовать представления публикаций и действий, добавлять числовой контекст после трансформера и оценивать множество кандидатов с общей историей за один проход.
В таблице 5 авторы сообщают о +2,10% времени в продукте относительно прежнего ранжировщика. Для новых участников эффект статистически незначим; результаты A/B не включают инкрементальное обучение.
Начните здесь, если хотите связать модель, данные, A/B-тест и систему обслуживания в одном промышленном кейсе.
ID редких и старых товаров плохо обучены, а полный анализ истории до 100 тысяч действий создаёт вычислительные и сетевые расходы.
Отбирать небольшую часть истории по замороженным мультимодальным векторам, затем объединять распределение семантических сходств с вниманием по ID; длинную историю загружать параллельно с подбором кандидатов.
MUSE-100K против промышленного SIM-5K: авторы сообщают +12,6% CTR, +5,1% RPM и +11,4% ROI. Это суммарное изменение системы и длины истории; отдельное офлайн-сравнение ограничено 5K и 1K событий.
Лучший следующий кейс, если хочется понять, как использовать длинную историю без полного тяжёлого внимания ко всем событиям.
Пакетный профиль интересов обновляется недостаточно быстро, но независимая подробная обработка истории для каждого кандидата резко увеличивает стоимость ранжирования.
Объединить долгосрочный пакетный профиль с короткой историей действий, рано добавить в историю представление кандидата и сжать выход трансформера перед общей сетью ранжирования.
В таблице 5: +11% сохранений в Homefeed, −10% скрытий и +2% общего времени в продукте. Контроль — Pinnability без realtime-последовательности; по 1,5% посетителей в группе.
Начните с этой главы перед TransAct V2: она объясняет исходную гибридную модель и проблемы, которые следующая версия развивает дальше.
История порядка 100 событий ограничивает память о пользователе, а прямое добавление десятков тысяч событий делает хранение, передачу и инференс слишком дорогими.
Найти релевантные события в нескольких историях, гарантированно сохранить самые свежие, обучать дополнительное предсказание действия и убрать повторную передачу общей истории между кандидатами.
Против TransAct в онлайн-тесте: +6,35% сохранений, −12,80% скрытий, +0,45% разнообразия и +1,41% времени. Офлайн +13,31% HIT@3/repin имеет другую базу — модель без последовательностей.
Читайте после исходного TransAct: здесь особенно хорошо разобраны негативные показы, общая история запроса и влияние очередей на хвост задержки.
Разнородные ручные признаки и повторная обработка истории затрудняют масштабирование модели на постоянно меняющемся словаре и огромном потоке взаимодействий.
Объединить признаки в последовательность, использовать специализированные блоки HSTU, учить много целевых позиций совместно и обслуживать кандидатов микропакетами с общими вычислениями.
Таблица 7: +12,4% по неназванной engagement-задаче E-Task и +4,4% по C-Task в онлайн-ранжировании. +65,8% NDCG относится к Books, а множители скорости — к отдельным стендам.
Читайте в связке с Feed SR: HSTU объясняет исходную формулировку, а LinkedIn показывает, какие решения оказались полезными или неудачными в другой ленте.
Предварительная модель должна оценивать намного больше кандидатов, чем финальная, но обучается на смещённой выборке показов и не всегда сохраняет объекты, важные следующей стадии.
Передавать ранней модели порядок, численные оценки и представления дорогого ранжировщика, затем совместно выбирать признаки и структуру сети с учётом качества и ожидаемой задержки.
Последовательные опыты дают разные прибавки Recall@150 в процентных пунктах и небольшие изменения CTR. Финальный NAS-опыт: +11 п.п. Recall@150 и +0,12% CTR без роста онлайн-задержки; общая сумма эффектов не вычисляется.
Читайте как противовес идее обязательной замены всего каскада: ранние и поздние стадии можно согласовать, сохраняя их разные вычислительные бюджеты.
Прежние модули взаимодействия признаков плохо загружали GPU; увеличение модели повышало стоимость и не давало соразмерного улучшения качества.
Сгруппировать признаки в небольшое число смысловых токенов, смешивать части их представлений и обрабатывать токены независимыми FFN; затем оптимизировать точность вычислений и GPU-операции.
Таблица 6: 15,8 млн → 1,1 млрд плотных параметров при задержке 14,5 → 14,3 мс. Таблица 4: Douyin overall +0,2908% активных дней и +1,0836% времени по обновлённому длительному A/B-наблюдению.
Читайте после Feed SR: здесь главный вопрос — не устройство истории, а взаимодействия разнородных признаков и реальная стоимость крупного ранжировщика.
Генеративное обучение истории не совпадает с задачей калиброванного CTR-прогноза; крупная модель может не выдерживать поток обучения и задержку зрелой промышленной системы.
Разделить обучение модели пользователя, получение признаков интереса под структурированные условия и их использование в обычном ранжировщике, сохранив признаки, параметры и быстрые обновления последнего.
В §5.6 версии v2 авторы сообщают +2,9% CTR и +1,2% RPM в sponsored search Taobao. Приведённые сравнения задержки охватывают LUM-Step3, а не полную стоимость всех трёх стадий.
Читайте как альтернативу полной генеративной замене каскада: LUM усиливает существующий ранжировщик и сохраняет его самостоятельную роль.
Независимые стадии каскада ограничивают друг друга, а генеративный отбор одного объекта ещё не создаёт качественный согласованный список рекомендаций.
Кодировать видео семантическими ID, генерировать целую сессию encoder-decoder-моделью и улучшать её на парах собственных выдач, оценённых персонализированной моделью награды.
В таблице 2 OneRec-1B+IPA даёт +1,68% общего времени просмотра и +6,56% средней длительности просмотра относительно текущего каскада; эксперимент проводится на 1% основного трафика. Офлайн-таблица оценивает предсказания модели награды.
Читайте после LUM: OneRec предлагает объединить выбор списка, тогда как LUM намеренно сохраняет отдельный прикладной ранжировщик.
Множество независимых рекомендательных моделей дорого поддерживать, сложно переиспользовать их улучшения, а короткая история пользователя ограничивает понимание долгосрочных предпочтений.
Обучить общую последовательную foundation model на масштабной истории взаимодействий и контентных признаках, а затем использовать её прогнозы, веса и эмбеддинги в разных рекомендательных задачах.
Netflix сообщает о стабильном улучшении относительного качества при увеличении объёма данных и размера модели и о многообещающих downstream-интеграциях, но статья не приводит численного uplift или результатов A/B-теста.
Показывает, зачем объединять обучение моделей, которые решают разные задачи в одном продукте.