Ozon: RecSys-собеседование про распределенное обучение, трансформеры и ранжирование

Data parallelism делит batch между GPU и синхронизирует градиенты. Model/tensor parallelism режет саму модель. Pipeline parallelism раскладывает слои по устройствам. FSDP/ZeRO шардуют параметры, градиенты и optimizer state, чтобы снизить память.

Если не хватает только throughput, обычно начинают с DDP: каждая GPU держит копию модели, считает градиенты на своей части batch, затем градиенты синхронизируются через all-reduce. Это просто и хорошо масштабируется, пока модель помещается на каждую GPU.

Если модель не помещается, нужны model parallel подходы. Tensor parallelism режет отдельные матричные операции, pipeline parallelism кладет разные блоки модели на разные GPU и прогоняет micro-batches конвейером. FSDP и ZeRO уменьшают память, шардуя параметры, градиенты и optimizer state между устройствами.

Дополнительно почти всегда включают mixed precision, gradient checkpointing, accumulation и аккуратную настройку batch size. Выбор зависит от узкого места: память параметров, память активаций, коммуникации или скорость загрузки данных.

Из каждого токена строятся query, key и value. Query сравнивается с key других токенов, веса проходят через softmax, а итоговое представление получается как взвешенная сумма value. Multi-head attention делает несколько таких сравнений параллельно.

Self-attention отвечает на вопрос: на какие элементы последовательности должен смотреть текущий элемент. Для каждого токена линейными слоями строятся Q, K и V. Скалярные произведения Q с K дают scores близости, softmax превращает их в веса, затем веса применяются к V.

Multi-head attention делает это несколько раз в разных подпространствах, поэтому разные головы могут ловить разные связи. После attention обычно идут residual connection, normalization и feed-forward блок. Позиционная информация нужна отдельно, потому что сам attention без нее не знает порядок токенов.

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

Offline: Precision@K/Recall@K для попадания релевантных объектов, MRR для ранга первого релевантного, NDCG@K для качества порядка с учетом позиции. Online: CTR, conversion, GMV, retention и guardrails по latency, diversity и пустым выдачам.

Precision@K отвечает, какая доля top-K релевантна. Recall@K отвечает, какую долю релевантных объектов удалось найти в top-K. MRR полезен, когда важно как можно раньше показать первый правильный результат. NDCG@K лучше подходит для ранжирования с graded relevance: релевантность дисконтируется по позиции, поэтому ошибка наверху выдачи дороже ошибки внизу.

Offline-метрики нужно считать на честном candidate set и проверять по срезам: новые пользователи, популярные/редкие товары, категории, регионы. Иначе модель может улучшить средний NDCG за счет популярных объектов и ухудшить coverage.

Online-метрики зависят от продукта: CTR, add-to-cart, purchase conversion, GMV, watch/listen time, retention. Guardrails: latency, empty results, complaints, diversity, novelty, share of repeated items and fallback rate.

Для retrieval часто используют two-tower и sequential models вроде SASRec/next-item prediction. Для реранжирования - MLP/DeepFM/DCN/transformer-ranker поверх user/item/context features. Обычно пайплайн делят на генерацию кандидатов и реранжирование.

В рекомендациях нейросети чаще всего появляются в двух местах. Первое - генерация кандидатов: two-tower модель отдельно кодирует пользователя и item, затем быстрый ANN-поиск находит близкие item embeddings. Для истории действий подходят sequential models: GRU4Rec, SASRec, BERT4Rec и похожие next-item подходы.

Второе - реранжирование: когда кандидатов уже сотни, можно использовать более тяжелую модель с user features, item features, cross features, контекстом сессии, ценой, категорией и бизнес-ограничениями. Это может быть MLP, DeepFM/DCN, transformer over sequence/context или ансамбль с бустингом.

Главный trade-off: retrieval должен быть быстрым и иметь высокий recall, реранкер может быть точнее, но работает на ограниченном наборе кандидатов. Для production еще нужны freshness embeddings, fallback, мониторинг coverage и online A/B.

Категории кодируются embedding table, числовые признаки нормализуются и проецируются через MLP, тип признака тоже можно дать отдельным embedding. Для пользователя действия идут последовательностью, для товара атрибуты можно подать как set/sequence tokens и агрегировать pooling/CLS.

Разнотипные признаки нужно привести к общей размерности. Категориальный признак получает embedding по id значения и, часто, embedding типа признака. Числовой признак нормализуется и проходит через маленький MLP или linear projection; вместе с ним можно подавать embedding имени признака. Так модель понимает не только значение, но и что это за поле.

Для товара набор атрибутов можно рассматривать как множество токенов: категория, бренд, цена, текстовые/image embeddings, статистики. Transformer или attention-блок агрегирует их в item embedding через CLS token, pooling или attention pooling. Для пользователя естественнее последовательность действий: item embedding, тип события, timestamp/позиция, давность, контекст.

После получения user и item embeddings есть два частых пути: dot product в общем пространстве для retrieval или MLP/cross network для реранжирования. Важно заранее решить, какие признаки доступны online, а какие можно считать только offline.

Начать с архитектуры: precompute item embeddings, cache user state/top-K, ограничить число кандидатов. Затем оптимизировать модель: FP16/INT8, ONNX/TensorRT/Triton, dynamic batching, autoscaling и fallback при timeout.

Первый слой оптимизации - не технический формат модели, а сокращение работы. Item embeddings и статические признаки надо считать заранее. User embeddings можно обновлять по событию, по расписанию или при входе пользователя, но желательно не строить всю историю заново на каждый запрос. Реранкер должен работать по top-N кандидатам, а не по всему каталогу.

Второй слой - inference stack. Конвертация в ONNX/TensorRT, FP16 или INT8 quantization, kernel fusion, Triton/dynamic batching и правильные batch size помогают увеличить throughput. Но batching нельзя включать без учета latency SLA: иногда он улучшает throughput и ухудшает p95.

Третий слой - надежность: cache hit rate, timeout, fallback на старый top-K или популярное, мониторинг пустых выдач, деградации качества и resource saturation. RecSys должен уметь отвечать приемлемо даже когда тяжелая модель недоступна.