DROM: RecSys ML System Design

Ground truth строится из показов и downstream действий: click, contact, add-to-favorite, purchase/lead. Негативы должны быть shown-but-not-chosen, а не произвольные unseen item.

Для RecSys dataset важны request context, список показанных кандидатов, позиция, признаки на момент показа и последующие действия пользователя. Positive labels зависят от бизнеса: click, long view, favorite, contact request, purchase, revenue. Negative labels надежнее брать из объектов, которые пользователь реально видел и не выбрал.

Нельзя смешивать unseen item с негативами без поправок: пользователь мог их не видеть. Нужны time split, защита от leakage serving-time features и slice-валидация для новых item, long-tail, регионов и разных типов пользователей.

Offline-метрики проверяют качество ранжирования, а бизнес-метрики проверяют эффект на продукт. Между ними нужна гипотеза: улучшение top-K должно менять конкретное действие пользователя.

Model metrics могут быть recall@K, nDCG, MAP, calibration, coverage и diversity. Business metrics - conversion, contact request, GMV/revenue, retention, time-to-find и complaint rate. Связка между ними не автоматическая: offline labels должны соответствовать действию, которое создает бизнес-ценность.

Для запуска формулируется гипотеза: например, рост nDCG по релевантным автомобилям увеличит contacts per session без ухудшения latency и diversity. A/B test проверяет бизнес-эффект, а offline metrics остаются быстрым фильтром качества между экспериментами.

Называются user history, item attributes, context, interaction features, freshness, popularity, embeddings и serving-time features с контролем leakage.

Типовой набор: признаки пользователя и истории, признаки item, регион/устройство/время, цена и availability, свежесть объявления, популярность, seller quality, текстовые/визуальные embeddings и interaction features между пользователем и item.

Важно разделять offline-computable признаки и признаки request-time. Serving должен получать только то, что известно до показа. Для freshness нужны TTL/streaming updates, для embeddings - versioning, для user history - fallback при новом пользователе. Фичи должны логироваться вместе с показами, иначе offline training не повторит online контур.

Backend владеет продуктовым контрактом и правилами, ML-сервис возвращает scores/candidates по стабильному API, feature слой обеспечивает свежие признаки.

Практичная граница: продуктовый backend принимает request и знает UX/business rules, ML-сервис получает user/context/candidate ids и возвращает scores или ранжированный shortlist, feature store/online feature service отдает свежие признаки. Business-critical фильтры можно держать рядом с backend или в post-processing слое.

Контракт должен включать request schema, response schema, timeouts, fallback, model version, trace id и логирование candidates/features/scores. Это позволяет независимо менять модель, не ломая продуктовый API, и быстро откатываться на baseline.

Кэшируются item features, embeddings, popular candidates и precomputed user/item lists. Online слой делает только быстрый rerank и должен иметь fallback.

Кэшировать можно несколько уровней: item features и embeddings, ANN results, популярные кандидаты по сегменту, персональные top-N, результаты тяжелого retrieval и availability. TTL зависит от freshness требований: цена и наличие обновляются чаще, статические признаки реже.

Latency budget делится между backend, feature reads, model inference и post-processing. Для p95/p99 нужны timeout, circuit breaker, degraded baseline и warm cache. Кэш не должен нарушать бизнес-правила: availability, удаленные объявления и privacy constraints проверяются ближе к выдаче.

Выбор идет от требований: QPS, latency, freshness, команда, стоимость и риск. MVP обычно проще: precomputed candidates + легкий online rerank + fallback.

Архитектуры сравниваются по качеству, latency, стоимости, сложности поддержки, freshness и скорости итераций. Полностью online retrieval может дать свежесть, но дорогой и рискованный. Полностью batch проще и дешевле, но хуже реагирует на контекст. Часто устойчивый вариант - batch retrieval/precompute плюс online rerank по свежему контексту.

Решение должно включать rollout path: baseline, A/B, monitoring, fallback и ownership. Если команда маленькая, лучше система с меньшим числом moving parts, стабильным API и хорошей наблюдаемостью, чем сложный realtime stack без операционной поддержки.

Логируются request, candidates, features, scores, model version и outcome. Мониторятся latency, ошибки, фичи, drift, coverage, business metrics и fallback rate.

Для audit нужны request id, user/context, candidate ids, features или feature version, model version, scores, final rank, filtered reasons и downstream events. Без этих логов невозможно объяснить, почему объект был показан, и повторить offline разбор.

Мониторинг делится на system metrics, data/model metrics и product metrics. System: latency, error rate, timeouts. Data: missing features, distribution drift, stale embeddings. Model/product: CTR/conversion, coverage, diversity, complaints, fallback rate и slice-деградации. Алерты должны уметь быстро переводить систему на baseline.

Текст/изображения кодируются offline в embeddings, версионируются и подаются в retrieval/rerank. Online слой читает готовые признаки, а не запускает тяжелые encoders на запросе.

Текстовые описания, фото и другие multimodal данные обычно обрабатываются offline или nearline. Encoders создают embeddings и quality features, которые пишутся с model/version metadata. Дальше эти признаки используются для ANN retrieval, similarity features или reranker.

Нужно контролировать freshness: новые объявления должны быстро получать признаки или fallback. Также важны drift и качество исходных медиа: пустые описания, плохие фото, дубли и изменившиеся категории. В online request не стоит запускать тяжелые image/text encoders без отдельного latency budget.