Uzum: RecSys, признаки и сервис ранжирования

Смешать несколько источников: co-visitation/co-purchase, item-to-item embeddings, content embeddings, popularity/recency, category constraints и business rules. Retrieval оценивается по Recall@K, coverage, diversity и downstream uplift после реранжирования.

Для товарных рекомендаций один источник кандидатов редко покрывает все случаи. Collaborative signals дают товары, которые пользователи смотрели или покупали вместе. Content-based embeddings помогают новым и редким товарам: текст, категория, бренд, изображение, атрибуты. Popularity/recency и curated rules нужны как fallback.

После retrieval кандидаты чистятся бизнес-правилами: наличие, регион, цена, запрещенные пары, уже купленные или просмотренные товары. Дальше реранкер сортирует ограниченный список по вероятности клика, покупки, GMV или другой продуктовой цели.

Метрики retrieval: Recall@K по известным позитивам, catalog/category coverage, доля новых товаров, diversity и latency. Важно не радоваться только CTR: модель может начать показывать популярное и ухудшить discovery.

Для деревьев часто работают one-hot, count/frequency и target encoding с защитой от leakage. Для нейросетей - embeddings. Для high-cardinality признаков нужны smoothing, rare buckets, hashing или регуляризация.

Выбор кодирования зависит от модели. Для бустинга можно использовать one-hot для малой кардинальности, count/frequency encoding, target encoding или встроенную обработку категорий, если библиотека ее поддерживает. Target encoding обязательно делается out-of-fold или по прошлым данным, иначе модель увидит таргет.

Для нейросетевых ранкеров обычно используют embedding table: id категории превращается в плотный вектор. Для редких значений нужен unknown/rare bucket, hashing trick, регуляризация и мониторинг новых категорий в проде. Иногда полезно добавить hierarchy: category, subcategory, brand, seller.

Риск в RecSys - popularity leakage и переобучение на частые категории. Поэтому кодирование надо проверять по time split и срезам: новые товары, новые продавцы, редкие категории, long tail.

Offline смотреть метрики ранжирования или классификации по задаче: Recall@K, NDCG, pairwise accuracy, ROC AUC, PR AUC, precision/recall по порогу. Online - CTR, conversion, revenue/GMV, add-to-cart и guardrails по latency, diversity, coverage.

Если модель ранжирует список, нужны метрики порядка: NDCG@K, MRR, Recall@K, Precision@K или pairwise accuracy. Если модель предсказывает вероятность действия, полезны ROC AUC, PR AUC, logloss, calibration и precision/recall при рабочем пороге. При дисбалансе PR AUC и slice-метрики часто информативнее ROC AUC.

Offline-метрика должна считаться на данных, похожих на прод: правильный candidate set, time split, срезы по категориям, новым товарам и новым пользователям. После этого нужен online A/B, потому что offline relevance не равна бизнес-эффекту.

Online primary metric выбирается по месту продукта: CTR, add-to-cart, conversion, GMV, revenue, retention. Guardrails: latency, empty results, complaints, diversity, novelty, long-tail exposure, share of unavailable items.

Нужны feature contracts, offline backfill, online freshness checks, shadow/canary, A/B и мониторинг latency/error/empty results. Новая фича не должна ломать старую модель, если она пустая или запаздывает.

Сначала фиксируется контракт признака: тип, диапазон, default, freshness, источник, кто владелец и как выглядит backfill. Offline-датасет и online serving должны считать одно и то же, иначе модель пройдет offline и сломается в проде.

Перед полным rollout полезны shadow scoring и canary: посчитать фичу и score без влияния на выдачу, затем включить малый процент трафика. Мониторинг должен ловить latency, error rate, долю null/default, свежесть, распределение признака и изменение top-K.

Для A/B нужно держать версионирование модели и признаков, возможность rollback и fallback на старую модель. Если новая фича недоступна, сервис должен отдавать нормальный ответ, а не падать или возвращать пустую выдачу.