Uzum ML System Design: поиск и ранжирование на маркетплейсе

Бизнес-метрики: GMV/revenue из поиска, conversion, add-to-cart, paid orders. User-метрики: CTR, zero-result rate, reformulation, time-to-product. Offline: NDCG@K, MRR, Recall@K, query/item coverage и slice quality.

Для marketplace search нельзя ограничиться одной NDCG. Бизнес хочет деньги и полезный пользовательский опыт: GMV, revenue, purchase conversion, add-to-cart, CTR, доля успешных сессий, time-to-product. Guardrails: latency, zero-result rate, жалобы, возвраты, diversity, seller fairness, share of unavailable items.

Offline нужны judgment или implicit labels: клики, корзина, покупки, ручная разметка по запросам. Метрики: NDCG@K, MRR, Recall@K, Precision@K, coverage по категориям и хвостовым запросам. Обязательно проверять head/tail queries, новые товары, сезонные запросы и географию.

Online A/B должен смотреть не только краткосрочный CTR. Модель может поднять клики на дешевые или популярные товары, но ухудшить покупку, маржу или долгосрочное доверие к поиску.

Первый этап достает кандидатов через lexical search, filters, synonyms, vector retrieval и popularity fallback. Второй этап реранкер сортирует top-N по query-item-user-context признакам и бизнес-ограничениям.

Архитектура обычно каскадная. Retrieval должен быстро найти достаточно широкий набор кандидатов: inverted index/BM25, морфология, синонимы, фильтры, category matching, vector retrieval по тексту/изображению, популярные товары для fallback. Его цель - высокий recall и приемлемая latency.

Реранкер работает по сотням или тысячам кандидатов и может быть богаче: query text features, item attributes, price, availability, seller quality, user history, query-item match, historical CTR/CVR, margin, delivery constraints. Модель может быть бустингом, neural ranker или ансамблем.

В production важно версионировать index, фичи и модель, уметь объяснить пустую выдачу, ограничивать дорогое реранжирование и иметь fallback на lexical/popular results.

Статические item features и тяжелые агрегаты считаются offline. Свежие session/query features - online или streaming. Для каждого признака нужен freshness SLA, default, point-in-time train join и проверка offline-online consistency.

Item attributes, text/image embeddings, seller stats и долгие агрегаты лучше считать offline и хранить рядом с индексом или feature store. Они редко меняются и не должны увеличивать latency поиска. User/session features - последние клики, корзина, фильтры, query reformulations - могут требовать online или streaming обновления.

Каждая фича должна иметь контракт: где считается, как часто обновляется, что делать при null, какой TTL, доступна ли она в train на тот же момент времени. Для обучения нужен point-in-time join, иначе модель увидит будущие клики или покупки.

В online ranker нельзя добавлять дорогой запрос в DWH или тяжелую модель на каждый item. Если признак нужен срочно, лучше предварительно агрегировать его в online store или считать только для top-N кандидатов.

Сезонность ловят свежими окнами, time features, регулярным retraining и slice-метриками по категориям/запросам. A/B запускают с primary metric, guardrails, MDE, ramp-up и проверкой SRM/баланса групп.

В маркетплейсе сезонность проявляется в запросах, наличии товаров, цене, промо и поведении пользователей. Модель можно поддерживать свежими training windows, time/category features, регулярным переобучением и отдельными правилами для сезонных категорий. Важно смотреть slice-качество: зимние товары, праздники, back-to-school, локальные промо.

Перед A/B фиксируются primary metric и guardrails. Например, primary - purchase conversion или search GMV, guardrails - latency, zero-result rate, complaints, seller fairness, refunds. MDE и длительность считаются заранее, чтобы не остановить тест на шуме.

Rollout лучше делать постепенно: shadow, canary, 1-5%, затем больше. Во время теста проверяются SRM, баланс групп, стабильность логирования и отсутствие деградации на критичных категориях.