Wildberries RecSys Technical: money recall, DSSM и content features

Нужно показать полный ownership: постановка задачи и acceptance criteria, дизайн/согласование, сбор данных, обучение, offline validation, packaging модели, сервисный inference, canary/rolling deploy, мониторинг и продуктовая приемка.

Хороший ответ начинается не с обучения модели, а с рамки задачи: какую бизнес-проблему решаем, какой пользовательский или операционный эффект ожидаем, какие ограничения по latency, стоимости, privacy и качеству есть, кто принимает результат.

Дальше идет ML-часть: собрать данные, проверить leakage и качество разметки, построить baseline, обучить модель, провести offline validation на правильном split, выбрать метрики и error analysis. Перед выкладкой модель нужно упаковать: сохранить артефакты, зафиксировать версию фичей, при необходимости конвертировать в ONNX или другой serving format, подготовить reproducible pipeline.

Production-часть: добавить модель в сервис или отдельный endpoint, договориться о контракте входа/выхода, выставить latency/error budget, выкатить через canary или rolling update, включить мониторинг качества, latency, drift, ошибок и бизнес-метрик. Завершение задачи - не merge, а подтверждение, что результат принят продуктом и не сломал guardrails.

Precision отвечает за качество найденного, recall - за полноту найденного. Для geo-generalization нужен split по регионам/времени и проверка, что модель не запомнила локальные id.

Precision показывает, какая доля выбранных объектов действительно релевантна. Recall показывает, какую долю всех релевантных объектов мы нашли. В рекомендациях и поиске баланс зависит от этапа: candidate generation чаще оптимизирует recall, финальная выдача - top-K quality.

Если в признаках есть география, нужно проверить, не запомнила ли модель конкретные region_id, store_id или локальные паттерны. Полезны holdout по регионам, time split, cold-region slices, target encoding без leakage и fallback для новых гео-сегментов.

Обычный Recall@k можно заменить weighted recall: в числителе сумма gain по релевантным товарам, попавшим в top-k, в знаменателе сумма gain по всем релевантным товарам. gain выбирают из GMV, маржи, комиссии или сглаженной цены.

Формулировка:

money_recall@k = sum gain(item) по item из top-k, которые были релевантны / sum gain(item) по всем релевантным item.

Если релевантность - покупка, то в числителе суммируем не единицы, а ценность купленных товаров, которые модель успела показать в top-k. В знаменателе суммируем ценность всех купленных релевантных товаров в holdout. Так модель, которая нашла дорогой релевантный товар, получает больше credit, чем модель, которая нашла только дешевый товар.

Главное - выбрать корректный gain. В маркетплейсе это может быть цена, GMV, маржа, комиссия, profit или log/clip/quantile transform от цены, чтобы не дать одному дорогому товару полностью доминировать метрику. Money recall полезен как offline proxy, но его нужно проверять online и держать guardrails: конверсия, пользовательское качество, diversity и fairness к дешевым товарам.

Базовый набор: перекос в популярные товары, низкое разнообразие и новизна, cold start, feedback loops, position bias, оптимизация в кликбейт, разреженные данные, свежесть каталога, offline-online gap и latency.

Сильный ответ лучше группировать по классам проблем.

Качество рекомендаций: popularity bias, когда система крутит только популярные товары; низкая diversity внутри выдачи; низкая novelty для пользователя; плохое покрытие long-tail; clickbait-оптимизация, когда клики есть, а ценности дальше нет.

Данные и обучение: cold start для новых пользователей и товаров, data sparsity, feedback loops, position/exposure bias, leakage, устаревание каталога и сезонность. Модель учится на том, что сама раньше показывала, поэтому offline-лог может быть смещен.

Production и продукт: latency, стоимость candidate generation/reranking, свежесть признаков, правила безопасности, бизнес-guardrails и offline-online gap. Мерить можно diversity/coverage/novelty, распределение популярности показанных товаров, calibration, business metrics и A/B guardrails.

Regularization ограничивает переобучение; dropout на train случайно зануляет activations, а на inference использует всю сеть с корректным scale.

Regularization снижает способность модели запоминать train noise: L1/L2, early stopping, data augmentation, dropout, label smoothing. Dropout во время обучения случайно зануляет часть activations, заставляя модель не полагаться на отдельные нейроны.

В inverted dropout оставшиеся activations масштабируются на train, поэтому на inference dropout выключается без дополнительного пересчета масштаба. Ошибка - включить dropout на inference в обычном deterministic предсказании или не переключить model.eval() в PyTorch.

Residual connection учит добавку F(x) к identity x, улучшает gradient flow и облегчает обучение очень глубоких сетей.

Вместо прямого обучения сложного отображения H(x) блок учит residual F(x), а выход равен x + F(x). Если оптимально почти ничего не менять, блоку проще приблизить F(x)=0, чем выучить identity с нуля.

Skip connection дает более короткий путь для градиента и снижает проблему деградации качества при увеличении глубины. Поэтому residual blocks стали базой ResNet, Transformer-блоков и многих современных архитектур.

Boosting строит ансамбль последовательно: новое дерево приближает антиградиент loss по текущим предсказаниям; для MSE это residuals.

Модель имеет вид суммы слабых моделей. На каждом шаге считаются производные loss по текущим предсказаниям. Следующее дерево обучается предсказывать направление, в котором нужно поправить prediction, то есть negative gradient.

Для squared error negative gradient совпадает с y - prediction, поэтому говорят, что дерево учится на residuals. Для logloss идея та же, но targets следующего шага уже не простые residuals, а градиенты loss.

Нормальная таксономия: popularity/rules, content-based, collaborative filtering и matrix factorization, item2vec/session embeddings, DSSM/two-tower retrieval, sequential models, graph models и learning-to-rank/rerankers.

Модели удобно описывать не списком названий, а по месту в системе.

Простые baselines: popularity, правила, персонализация по категориям. Content-based модели используют признаки товара и пользователя: текст, описание, категорию, цену, картинку, профиль пользователя. Collaborative filtering использует матрицу взаимодействий user-item; сюда входят ALS/matrix factorization и похожие latent factor models.

Для candidate generation часто используют embeddings: item2vec/word2vec по сессиям, DSSM/two-tower user-item или item-item, approximate nearest neighbors. Sequential модели, например SASRec/Transformer-like, учитывают порядок действий пользователя и next-item prediction. Graph models могут использовать связи user-item-item/category.

На стадии reranking часто применяют GBDT/NN/ranking models с pointwise, pairwise или listwise loss, например LambdaRank-подходы. В production обычно это гибрид: retrieval из нескольких источников, фильтры, reranker и business rules.

Задачу можно поставить как pairwise similarity/anomaly detection по двум объявлениям: сначала нормализовать ракурсы, затем обучить metric learning на positives и hard negatives, агрегировать photo-pair scores и дообучить reranker/heads под конкретные типы различий.

Сначала нужно определить объект сравнения: не одна фотография, а пара объявлений с набором фото. Полезно выделить ракурсы автомобиля: фронт, зад, бок, диагонали, салон. Это снижает шум, потому что сравнение "салон против кузова" бессмысленно.

Данные: positives - тот же автомобиль, то же объявление или надежно совпадающая комплектация/история; easy negatives - явно другие автомобили; hard negatives - та же марка/модель/поколение, но отличия в деталях: цвет, колеса, решетка, салон, кузов. Именно hard negatives заставляют embedding ловить мелкие визуальные различия.

Модель: encoder изображения или пары изображений, metric learning с contrastive/triplet loss, in-batch negatives, а затем агрегация расстояний по сопоставимым ракурсам. Поверх embedding-признаков можно обучить GBDT/MLP reranker или отдельные heads: цвет, салон, внешний вид. На выходе нужен score и порог для автоматического удаления или отправки на ручную проверку.

Оценка: precision/recall по "чужим" объявлениям, cost-sensitive threshold, разбор ошибок по типам отличий и guardrail на false positives, потому что ошибочное удаление настоящей истории автомобиля вредно для продукта.

Негативы бывают random, popularity-based, hard и in-batch; in-batch использует positives других примеров batch как negatives почти бесплатно.

Random negatives дешевые, но часто слишком легкие. Popularity-based negatives учат отличать популярные, но нерелевантные товары. Hard negatives близки по тексту, категории или embedding, но не являются правильным ответом, поэтому дают более сильный сигнал.

In-batch negatives берут объекты из других пар внутри batch: для anchor positive из других строк считаются negative candidates. Это эффективно, но требует аккуратности: в batch могут быть false negatives, например товар действительно релевантен пользователю, просто не был выбран в этом событии.

Потому что близость товаров берется из совместного поведения пользователей в сессиях, а не из текстов, картинок или атрибутов товара.

item2vec переносит идею word2vec на последовательности товаров: товары, которые часто встречаются рядом в сессиях или похожих user journeys, получают близкие embeddings. Это behavioral/collaborative signal: модель видит co-occurrence во взаимодействиях, а не содержание товара.

Два товара могут быть близки, даже если у них разные тексты, потому что пользователи часто рассматривают их как заменители. Content-based модель, наоборот, строит близость из описания, категории, изображения, бренда и других item attributes.

Базовый путь: взять collaborative item embedding и content embedding, нормализовать/спроецировать их, объединить через concat + MLP/gating/projection и обучать итоговый embedding тем же contrastive/triplet objective на кликах и negatives.

Нужно сначала различить сигналы. Collaborative embedding учится из поведения пользователей: товары близки, если часто встречаются рядом в сессиях или у похожих пользователей. Content embedding из LLM описывает текст товара, но сам по себе еще не знает, что именно важно для пользовательских переходов.

Простой baseline - concat collaborative embedding и content embedding. Лучше добавить projection/fusion layer: линейный слой или MLP, который приводит размерности и масштабы к общему пространству, может уменьшать размерность и учится выделять из content только то, что помогает interaction objective. Альтернативы: gated fusion, residual добавка content tower, late fusion scores или отдельный cold-start retrieval источник.

Обучение: anchor-positive-negative из сессий, triplet/contrastive loss, in-batch negatives, hard negatives, cosine/dot product в итоговом пространстве. Для production retrieval итоговые item embeddings нужно уметь индексировать в ANN.

Риски: разные нормы и распределения embedding vectors, слишком большая размерность LLM embedding, missing/dirty content, доминирование content над collaborative сигналом, leakage, stale descriptions и деградация latency. Поэтому обычно нужны normalization, projection, ablation и отдельная проверка cold-start и warm items.

Transformer строится из attention-блоков: токены превращаются в embeddings, добавляется позиционная информация, self-attention считает Q/K/V и взвешивает values, дальше идут FFN, residual connections и normalization. GPT - decoder-only, BERT - encoder-only.

Базовая схема: текст токенизируется, токены переводятся в embeddings, к ним добавляется positional information. Один transformer block обычно содержит multi-head self-attention, feed-forward network, residual connections и layer normalization.

В attention для каждого токена считаются query, key и value. Attention score - scaled dot product query с key, затем softmax по позициям, затем взвешенная сумма value. Multi-head attention делает несколько таких проекций параллельно, чтобы ловить разные типы связей.

Encoder видит всю последовательность и строит контекстные представления. Decoder для autoregressive генерации использует causal mask, чтобы токен не смотрел в будущее. В encoder-decoder архитектуре decoder также делает cross-attention к выходам encoder.

GPT - decoder-only модель для next-token prediction. BERT - encoder-only модель, исторически обучаемая через masked language modeling. Positional encoding может быть sinusoidal, learned или rotary embeddings; без него self-attention не знает порядок токенов.

dict - hash table с average O(1) для lookup/insert/delete. list - динамический массив ссылок на Python objects. NumPy ndarray - однородный typed buffer с shape/strides и векторизованными операциями в низкоуровневом коде.

Python dict хранит пары key-value в hash table. Для lookup считается hash ключа, затем структура находит слот и сравнивает ключи при коллизиях. В среднем lookup, insert и delete работают за O(1), но это amortized average: бывают resize, collisions и худшие случаи. В современных версиях CPython dict также сохраняет порядок вставки.

Python list - это динамический массив ссылок на Python objects. Он гибкий: можно хранить объекты разных типов, append обычно amortized O(1), index access O(1). Но элементы не лежат как плотный typed numeric buffer; каждый элемент - ссылка на объект, поэтому численные операции в цикле платят overhead интерпретатора и object boxing.

NumPy ndarray хранит данные в однородном typed buffer с shape, strides и dtype. Размер обычно фиксирован логически, а операции над массивами выполняются в оптимизированном низкоуровневом коде и могут использовать contiguous memory, SIMD/BLAS и broadcasting. Поэтому NumPy быстрее для больших численных массивов, но менее гибок по типам и форме.