Двухстадийная архитектура

Почему нельзя просто ранжировать весь каталог

В production у тебя могут быть миллионы или миллиарды кандидатов и десятки миллисекунд latency budget. Тяжелый ranker не может посчитать score для всего каталога. Поэтому крупные RecSys почти всегда устроены как воронка: retrieval -> ranking -> re-ranking/business rules.

Стадия 1: candidate generation / retrieval

• Цель: быстро найти сотни или тысячи потенциально релевантных айтемов из огромного каталога.
• Источники: two-tower ANN, item-to-item, popular/trending, follows/subscriptions, search/query intent, fresh content.
• Модели должны быть быстрыми: embeddings, approximate nearest neighbors, precomputed candidates.
• Recall важнее precision: лучше пропустить немного лишнего, чем потерять хороший айтем до ranker.

Стадия 2: ranking

Ranker получает уже ограниченный пул кандидатов и может использовать богатые фичи: user history, item metadata, context, cross-features, свежие агрегаты, business signals. Здесь обычно оптимизируют вероятность клика, просмотра, покупки или expected value.

Стадия 3: re-ranking

• Diversity: не показывать 10 одинаковых товаров подряд.
• Freshness: подмешивать новое, если продукт этого требует.
• Policy: запрещенный контент, availability, geo, price constraints.
• Business rules: quotas, caps, sponsored items, fairness между продавцами/авторами.
• Exploration: дать шанс новым айтемам и собрать данные.

Типовой ответ на system design interview

• Собираем события: impressions, clicks, dwell time, purchases, negatives.
• Строим feature store: user/item/context features, offline и online freshness.
• Retrieval: несколько sources, ANN index, fallback на popularity/trending.
• Ranking: GBDT/deep model с guardrails и calibration.
• Serving: latency budget, cache, monitoring, A/B, rollback.