Работающий сервис повторно вычислял длинные входные контексты, стоил дороже облачного API и требовал длительной доводки новых моделей.
Начать с профиля реального трафика, переиспользовать KV-cache между GPU, учитывать расположение кеша при маршрутизации и настраивать среду выполнения под очереди. Отдельно организовать проверку качества и производительности моделей.
По докладу, стоимость токена снизилась более чем вчетверо и достигла паритета с историческими предложениями OpenRouter; выпуск модели занимал около недели, хотя достижение экономичного режима могло потребовать больше времени.
Нужно быстро и устойчиво обрабатывать обращения, но развитие автоматизации ограничивают не только вычисления: создание агентов требует ручной работы и согласований между несколькими командами.
Сохранить работающие графы и классификаторы, распределить задачи между моделями разной сложности, организовать общий доступ к вычислениям и передать подготовку сценариев продуктовым менеджерам через Conclave AI.
При нагрузке 10 запросов в секунду задержка ответа составляет около 2 секунд по P50 и 5 секунд по P90. Около 12% обращений уходят в решения без участия человека, а примерно в 34% обращений участвуют LLM.
Прежняя DeepCVR опиралась преимущественно на агрегированные статистики и вручную подготовленные признаки. Они описывали устойчивые свойства пользователя и магазина, но хуже передавали хронологию действий и быстро меняющееся намерение внутри текущей сессии. Дополнительная проблема была инфраструктурной: пакетно рассчитанные признаки могли отставать от реального поведения на сутки и больше.
Uber развивает систему в несколько связанных этапов: сохраняет сильные табличные признаки в DCNv2, добавляет target-aware трансформер для истории поведения, переводит признаки на near-real-time UserContext, а затем отказывается от двух параллельных ветвей в пользу transformer-centered архитектуры, где сразу оценивается список магазинов. Одновременно команда перестраивает обучение и serving: PyTorch v2, BF16, multi-hash embeddings, заранее выполняемая ONNX-to-TensorRT оптимизация и раздельные CPU/GPU ресурсы.
По данным Uber, задержка обновления признаков сократилась с дней до нескольких секунд; предварительная ONNX-to-TensorRT конвертация устранила прежние 10–60 секунд задержки запуска и приблизила cold-start модели к нулю; разделение CPU-предобработки и GPU-инференса дало до двузначного прироста пропускной способности на узел при небольшой дополнительной задержке. Для listwise-подхода авторы оценивают вычислительную сложность на один магазин примерно как 1/T от pointwise-варианта при T одновременно оцениваемых магазинах. Источник не приводит CVR, CTR, GMV, A/B uplift или доверительные интервалы и не позволяет утверждать, что transformer-centered GenRec уже полностью заменил рекомендации Uber Eats на всём трафике.
Последовательную модель нужно было встроить в живую ленту с быстро меняющимися публикациями, социальными связями и ограничением задержки; дорогой текстовый 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 событий.
Лучший следующий кейс, если хочется понять, как использовать длинную историю без полного тяжёлого внимания ко всем событиям.
Прежние модули взаимодействия признаков плохо загружали GPU; увеличение модели повышало стоимость и не давало соразмерного улучшения качества.
Сгруппировать признаки в небольшое число смысловых токенов, смешивать части их представлений и обрабатывать токены независимыми FFN; затем оптимизировать точность вычислений и GPU-операции.
Таблица 6: 15,8 млн → 1,1 млрд плотных параметров при задержке 14,5 → 14,3 мс. Таблица 4: Douyin overall +0,2908% активных дней и +1,0836% времени по обновлённому длительному A/B-наблюдению.
Читайте после Feed SR: здесь главный вопрос — не устройство истории, а взаимодействия разнородных признаков и реальная стоимость крупного ранжировщика.
История порядка 100 событий ограничивает память о пользователе, а прямое добавление десятков тысяч событий делает хранение, передачу и инференс слишком дорогими.
Найти релевантные события в нескольких историях, гарантированно сохранить самые свежие, обучать дополнительное предсказание действия и убрать повторную передачу общей истории между кандидатами.
Против TransAct в онлайн-тесте: +6,35% сохранений, −12,80% скрытий, +0,45% разнообразия и +1,41% времени. Офлайн +13,31% HIT@3/repin имеет другую базу — модель без последовательностей.
Читайте после исходного TransAct: здесь особенно хорошо разобраны негативные показы, общая история запроса и влияние очередей на хвост задержки.
Независимые стадии каскада ограничивают друг друга, а генеративный отбор одного объекта ещё не создаёт качественный согласованный список рекомендаций.
Кодировать видео семантическими ID, генерировать целую сессию encoder-decoder-моделью и улучшать её на парах собственных выдач, оценённых персонализированной моделью награды.
В таблице 2 OneRec-1B+IPA даёт +1,68% общего времени просмотра и +6,56% средней длительности просмотра относительно текущего каскада; эксперимент проводится на 1% основного трафика. Офлайн-таблица оценивает предсказания модели награды.
Читайте после LUM: OneRec предлагает объединить выбор списка, тогда как LUM намеренно сохраняет отдельный прикладной ранжировщик.
Генеративное обучение истории не совпадает с задачей калиброванного CTR-прогноза; крупная модель может не выдерживать поток обучения и задержку зрелой промышленной системы.
Разделить обучение модели пользователя, получение признаков интереса под структурированные условия и их использование в обычном ранжировщике, сохранив признаки, параметры и быстрые обновления последнего.
В §5.6 версии v2 авторы сообщают +2,9% CTR и +1,2% RPM в sponsored search Taobao. Приведённые сравнения задержки охватывают LUM-Step3, а не полную стоимость всех трёх стадий.
Читайте как альтернативу полной генеративной замене каскада: LUM усиливает существующий ранжировщик и сохраняет его самостоятельную роль.
Разнородные ручные признаки и повторная обработка истории затрудняют масштабирование модели на постоянно меняющемся словаре и огромном потоке взаимодействий.
Объединить признаки в последовательность, использовать специализированные блоки HSTU, учить много целевых позиций совместно и обслуживать кандидатов микропакетами с общими вычислениями.
Таблица 7: +12,4% по неназванной engagement-задаче E-Task и +4,4% по C-Task в онлайн-ранжировании. +65,8% NDCG относится к Books, а множители скорости — к отдельным стендам.
Читайте в связке с Feed SR: HSTU объясняет исходную формулировку, а LinkedIn показывает, какие решения оказались полезными или неудачными в другой ленте.
Пакетный профиль интересов обновляется недостаточно быстро, но независимая подробная обработка истории для каждого кандидата резко увеличивает стоимость ранжирования.
Объединить долгосрочный пакетный профиль с короткой историей действий, рано добавить в историю представление кандидата и сжать выход трансформера перед общей сетью ранжирования.
В таблице 5: +11% сохранений в Homefeed, −10% скрытий и +2% общего времени в продукте. Контроль — Pinnability без realtime-последовательности; по 1,5% посетителей в группе.
Начните с этой главы перед TransAct V2: она объясняет исходную гибридную модель и проблемы, которые следующая версия развивает дальше.
Сетка сервисов теряет время на передачу данных, рассинхронизирует модель и индекс и ограничивает сложность раннего отбора.
Представить индекс, фильтры, ANN, башню пользователя и оценивание как тензоры и операции одной PyTorch-модели, затем перепроектировать их под GPU.
На нагрузке с 80 млн объектов Meta сообщает 23,7× больше RPS против сильной многосервисной системы той же архитектуры и 20,9× оценённую эффективность вычислительных затрат против FAISS-CPU.