GRII RED: ML System Design

Цель блока задается через add-to-cart/order/AOV, а MVP строится на item-item co-occurrence и category/popular fallback с фильтрами availability и already-in-cart.

Cart recommendations отличаются от обычной главной ленты: пользователь уже выразил intent через текущую корзину. Цель можно задать через incremental add-to-cart, order conversion, AOV/GMV, margin и отсутствие негативного UX. CTR сам по себе вторичен.

При 100 тыс. товаров полный online перебор не нужен. MVP: offline считать top-N соседей для item-item co-occurrence, хранить candidates в low-latency storage, на запросе агрегировать кандидатов товаров из корзины, фильтровать уже добавленные и недоступные, затем применять category/business rules.

Ограничения фиксируются сразу: latency budget, freshness каталога, cold start, fallback cascade, diversity, compatibility categories и мониторинг empty response/fallback share.

Online primary лучше связывать с add-to-cart, order conversion, AOV/GMV или margin. Guardrails: complaints, repeated category, returns, latency, coverage и diversity.

CTR полезен как диагностический сигнал, но для корзины он может обманывать. Пользователь может кликнуть на любопытный товар и не купить, либо купить без клика, если товар добавляется прямо из блока. Поэтому primary metric должна быть ближе к бизнес-действию: incremental add-to-cart, order conversion, items per order, AOV, GMV, margin или retention.

Offline можно считать recall@K/nDCG на co-purchase или add-to-cart labels, но важно помнить про bias старых показов и популярность. Нужны slice metrics: новые товары, long-tail, категории, регионы, price bands.

Guardrails: уже добавленные товары, unavailable items, diversity, repeated category rate, complaints/hide, returns/cancellations, latency, empty response rate, fallback share и coverage каталога.

Базовые фильтры: товары уже в корзине, unavailable/out-of-stock, несовместимые категории, запрещенные товары, price outliers и дубли. Часть фильтров hard, часть идет в rerank.

Первый обязательный фильтр - не рекомендовать товар, который уже лежит в корзине. Дальше идут availability, stock, регион доставки, возрастные/legal ограничения, несовместимость категорий, дубли вариантов одного товара и товары с плохим quality status.

Hard filters применяются до ранжирования, чтобы не тратить latency и не показать недопустимый вариант. Soft constraints можно учитывать в reranker: diversity по категориям, price compatibility, margin, novelty и business boosts. При этом boosts не должны пробивать hard constraints.

Для production нужны объяснимые counters: сколько кандидатов отброшено каждым фильтром, как часто блок пустеет после фильтров и какой fallback включается.

Baseline: считать item-item co-occurrence по заказам/сессиям, хранить top-N соседей на товар, для корзины агрегировать соседей товаров из корзины, исключать уже добавленные и сортировать по score.

Для первого решения не нужен сложный персонализированный ranker. Можно взять историю покупок и посчитать, какие товары часто встречаются вместе в одном заказе, в одной сессии или в коротком временном окне.

На offline этапе строим sparse item-item matrix или top-N neighbors per item: score может быть count, lift, PMI, cosine over item vectors или normalized co-occurrence. На online этапе берем товары из корзины, достаем соседей для каждого, агрегируем scores, выкидываем уже добавленные товары и показываем top-K.

Обязательно нужны freshness и ограничения: пересчет раз в день/несколько часов, фильтр availability, stock, price, category, business rules и fallback на popular/top sellers, если соседей мало.

Нужна cascade fallback: item-item neighbors, category-level popular, global popular, персональные favorites/history, business-curated complements, с фильтром наличия и исключением уже купленного/добавленного.

Система должна быть robust: пользователь не должен увидеть пустой блок только потому, что товар новый или редкий. Поэтому строим каскад.

Первый уровень — item-item соседи товаров из корзины. Второй — популярные товары в категориях, связанных с корзиной. Третий — глобальные top sellers или personalized popular по истории пользователя. Для нового пользователя можно использовать контекст: гео, магазин, устройство, время, текущая категория.

Если корзина большая, нужно не только набрать кандидатов, но и исключить уже присутствующие товары, дедуплицировать, ограничить повторяющиеся категории и не показывать несовместимые товары. Для каждого fallback стоит логировать причину, чтобы мониторить долю fallback traffic.

Co-occurrence усиливает популярные товары, плохо покрывает новые/редкие items и может снижать novelty. Нужны normalization, category fallback, exploration и content features.

Item-item baseline использует исторические совместные покупки, поэтому он естественно отдает преимущество товарам с большим числом взаимодействий. Новые и редкие товары получают мало соседей, а популярные товары могут появляться почти в каждой корзине, даже если они не самые релевантные.

Снижение проблем: использовать lift/PMI/cosine вместо raw counts, ограничивать dominant popular items, добавлять category-level и content-based candidates, учитывать availability, вводить diversity/novelty reranking и оставлять exploration traffic для long-tail.

Метрики должны смотреть не только общий CTR, но и coverage каталога, долю long-tail показов, novelty, repeated category rate и качество на cold-start товарах.

ALS может дать item/user embeddings и candidates, но cart surface требует score от текущей корзины: aggregation item vectors, user context и фильтры complements/availability.

ALS обычно учит user и item factors по implicit feedback. Для корзины есть два варианта использования. Первый - item-to-item: похожесть item embeddings помогает находить соседей товаров из корзины. Второй - персональный слой: user embedding добавляет предпочтения пользователя поверх текущего cart intent.

Граница постановки важна. Если просто показывать top items для пользователя, система может игнорировать текущую корзину. Для cart recommendations score должен учитывать товары в корзине: агрегировать их embeddings, взвешивать последние добавления, применять category complementarity и фильтровать already-in-cart.

ALS стоит сравнивать с co-occurrence baseline по offline labels и online uplift, отдельно контролируя latency, freshness и cold-start, где content/category fallback часто надежнее.

В корзине intent уже зафиксирован, поэтому часто ценнее complements: серьги, подвеска, уход или аксессуар. Substitutes могут конкурировать с выбранным товаром.

Похожий товар не всегда полезен. Если пользователь уже положил кольцо с рубином, второе похожее кольцо может не увеличить заказ, а лишь создать сомнение или каннибализацию. Для cart surface часто важнее дополнить покупку совместимыми категориями.

Модель должна различать similarity и complementarity. Источники сигнала: co-purchase pairs, category compatibility matrix, правила мерчандайзинга, price ratio, стиль, материал, occasion и последовательность добавления товаров. В ранжировании можно штрафовать повтор уже представленной категории и поднимать совместимые категории.

Проверка идет online: add-to-cart/order uplift, AOV, repeated category rate, diversity, returns и complaints. Offline co-occurrence без категории может смешивать substitutes и complements, поэтому нужна доменная интерпретация.

Item-to-item использует текущую корзину как главный context; персонализация добавляет user history как дополнительный сигнал, но не заменяет cart intent.

Item-to-item слой отвечает на вопрос: какие товары обычно полезны рядом с товарами из текущей корзины. Его можно построить без user profile: co-occurrence, item embeddings, category complements и бизнес-правила.

Персонализация добавляет информацию о пользователе: любимые категории, price sensitivity, brands, sizes, регион, прошлые покупки и recent views. Но если персональный top-N игнорирует текущую корзину, это уже другая поверхность рекомендаций.

Практичная архитектура разделяет слои: cart-based candidate generation, optional user-aware reranking и constraints. В логах и метриках стоит отдельно измерять вклад cart signal и user signal, чтобы не потерять основной use case.

Для корзины часто нужны complements, а не substitutes. Нужно добавить category/business constraints: не повторять уже представленную категорию, рекомендовать совместимые категории и контролировать diversity.

Цель блока в корзине обычно не "показать похожее", а увеличить чек и полезность заказа. Поэтому если в корзине кольцо, второе кольцо может быть менее полезно, чем серьги, браслет или уходовый аксессуар, в зависимости от домена.

Это можно учесть на candidate generation или reranking. В генерации строим item-to-item neighbors с учетом complementary categories. В ранжировании добавляем признаки: category of cart items, candidate category, category compatibility, price ratio, material, style, occasion. После ранжирования применяем diversity constraints.

Важно обсуждать business rules и availability: нельзя рекомендовать отсутствующие товары, несовместимые пары, слишком дорогие/дешевые outliers без причины. Метрики: add-to-cart, conversion, AOV/GMV, diversity, repeated category rate, complaints/negative feedback.

Ограничения можно применять pre-filter в индексе, post-filter после retrieval или category-aware reranking. Обычно комбинируют shortlist побольше и hard/soft constraints.

ANN возвращает ближайшие embeddings, но близость не гарантирует допустимую категорию или complementarity. Есть несколько уровней контроля. Pre-filter применяет category/availability constraints внутри индекса или через отдельные per-category indices. Это быстрее после retrieval, но может снизить recall, если фильтр слишком жесткий.

Post-filter берет shortlist больше K, удаляет недоступные и неподходящие категории, затем reranker выбирает top-K. Category-aware reranker добавляет признаки cart category, candidate category, compatibility score, price ratio и diversity penalties. Для важных hard rules нужен deterministic слой, который нельзя перебить model score.

Мониторинг: доля кандидатов, удаленных фильтрами, empty results после constraints, latency, coverage категорий и online uplift по complements.

Нужны category hierarchy, attributes, brand, price, availability, stock, images/text embeddings, style/material и quality flags. Проблемы: шумные категории, дубли и stale catalog.

Каталог задает большую часть ограничений для cart recommendations. Полезны category hierarchy, brand, model, material, style, size, color, price, discount, margin, stock, delivery availability, seasonality, text/image embeddings, popularity и quality flags.

Категории часто шумные: разные уровни иерархии, неправильная разметка, дубли SKU, новые товары без атрибутов, устаревший stock и локальные бизнес-исключения. Поэтому pipeline должен иметь validation, default categories, confidence атрибутов и правила для missing values.

Для обучения важно хранить признаки на момент показа. Если использовать текущий каталог для старых impressions, можно получить leakage: товар мог сменить категорию, цену, availability или фото после события.

Строка ranker обычно описывает candidate в контексте корзины и пользователя: item features, cart aggregate, user history, cross-features и business constraints.

Для cart ranker единица скоринга - candidate item в конкретном cart/user context. Item features описывают сам candidate: category, price, brand, availability, margin, embeddings, popularity. Cart features агрегируют текущую корзину: категории, сумма, последние добавленные товары, price range, embeddings и уже покрытые needs.

User features добавляют персонализацию: история категорий, брендов, средний чек, price sensitivity, регион, размеры, recent views. Самые сильные признаки часто cross-level: candidate-category compatibility with cart, candidate price vs cart price, user affinity to candidate category и item already bought recently.

Модель может быть MLP, GBDT или two-stage ranker, но train/serving parity важнее типа модели. Все признаки должны быть доступны на момент показа и иметь latency/freshness budget.

Offline считаем item-item neighbors, item/user/category features и обучаем ranker. Online при изменении корзины достаем candidates, обогащаем cached features, скорим ranker и возвращаем top-K с throttling/cache.

Архитектура обычно двухконтурная. Offline: ETL собирает события, заказы, каталог и availability; считает item-item candidates, popular lists, user/item/category features; обучает ranker и публикует артефакты.

Online: cart service вызывает recommendation service при значимом изменении корзины. Сервис берет товары корзины, достает candidates из low-latency storage, фильтрует unavailable/already-in-cart, обогащает признаками из feature store/cache, скорит ranker и возвращает top-K.

Нужны latency budget, throttling и cache: не пересчитывать каждую секунду, а пересчитывать на add/remove item, смену магазина/адреса или через короткий TTL. Мониторинг: latency, empty response rate, fallback share, CTR, conversion, revenue, drift фичей и freshness каталога.

Recommendation service пересчитывает candidates на значимые изменения корзины, использует short TTL/cache, валидирует актуальный cart state и имеет degraded fallback.

Cart state является частью запроса, поэтому рекомендации должны меняться при add/remove item, смене адреса/магазина, промо или availability. При каждом событии не обязательно запускать тяжелую модель с нуля: item candidates и features можно хранить offline, а online слой быстро агрегирует по текущей корзине и rerank-ит shortlist.

Cache должен учитывать cart signature: sorted item ids, quantities, store/region, user segment и experiment arm. TTL короткий, а перед ответом применяются фильтры already-in-cart и availability. Если сервис не успел ответить, включается fallback: category popular, curated complements или скрытие блока.

Мониторинг: p95/p99 latency, stale response rate, cache hit, empty response, fallback share, invalid recommendations и mismatch между cart state на запросе и в ответе.