Constructor ML System Design: candidate generation и ranking для e-commerce search

Начать с popularity/business baseline: продажи, клики, add-to-cart, рейтинг, availability и свежесть.

MVP не обязан требовать обучения. Можно посчитать item popularity score по свежему окну, добавить availability, категорию, регион и business boosts, затем использовать это как deterministic reranking. Такой baseline быстро лучше random, дает контрольную точку для A/B и помогает оценить, сколько value приносит сложная модель.

Важно не превращать baseline в вечный костыль: сразу логировать impressions и downstream labels, чтобы перейти к learning-to-rank.

Использовать показы как базу, positives из click/cart/purchase, покупки весить сильнее; target может быть binary, weighted или pairwise/listwise.

Единица обучения - query-user-item-impression. Негативы лучше брать из показанных, но не выбранных товаров, с поправкой на position/exposure bias. Сигналы можно взвесить: click меньше add-to-cart, add-to-cart меньше purchase, purchase можно домножать на margin или contribution profit.

После target design нужно проверить, что label доступен без leakage и что offline metric коррелирует с бизнес-целью хотя бы на исторических экспериментах.

Фичи нужно группировать по query, item, user, context и cross-сигналам; отдельно проверить availability, freshness, leakage и latency.

Единица скоринга - query-user-item в конкретном request context. Query features: нормализованный текст, tokens, intent/category, spelling, query frequency, lexical BM25 score, dense query-item similarity. Item features: category, brand, price, discount, availability, delivery SLA, rating, reviews, sales velocity, returns, margin, freshness, текстовые и image embeddings. User features: регион, устройство, сегменты интересов, история категорий, price sensitivity, средний чек, недавние действия.

Самые сильные признаки часто cross-features: query-item relevance, user-category affinity, user-brand affinity, item availability для региона, matching размера/цвета/категории, session intent, похожесть к последним viewed/cart items. Для marketplace search важно не забыть business и quality constraints: наличие, доставка, дубликаты, promoted items, diversity, adult/safety filters.

Перед добавлением признака нужно ответить: доступен ли он online в момент ранжирования, не смотрит ли в будущее, как часто обновляется, сколько стоит по latency, что делать при пропуске. Тяжелые embeddings и агрегаты лучше precompute в feature store, а online оставлять только быстрые lookups и compact scores.

Добавить reranking service: принять userId/query/itemIds, достать фичи, batch-score моделью, отсортировать и вернуть top-N.

Сервис лучше держать отдельным при ясном API и latency budget. Он должен score-ить кандидатов batch-wise, иметь feature store/cache, fallback на baseline, мониторинг качества/скорости и версионирование моделей. Для популярных товаров часть item features и scores можно precompute.

Если кандидатов много, перед реранкером нужен дешевый pre-ranking/top-K cap, иначе тяжелая модель попадет в request path на слишком большом множестве объектов.

Ввести pre-ranking/top-K cap перед реранкером: lexical/semantic score, popularity, diversity/dedup, clustering или sampling.

Pipeline должен иметь дешевый этап отбора до ML-реранкера: retrieval score, business/popularity score, availability, category constraints и dedup. Затем можно обеспечить diversity по категориям или embedding clusters и скорить только допустимый K по latency budget.

K выбирается не на глаз: он связан с latency, стоимостью модели и качеством top-N выдачи.

Включить margin/profit в objective: weight label на expected margin, использовать expected profit = P(purchase) * margin, добавить guardrails.

Можно переопределить label/value через цену, маржу или contribution profit, обучать модель на expected business value, либо делать post-ranking rerank с margin multiplier. Важно не сломать conversion, availability, customer experience и долгосрочную лояльность.

Формула expected value обычно сильнее, чем просто "добавим цену в фичи": модель должна оптимизировать ценность действия, а не только вероятность действия.