GRII RED: Техническое собеседование

Обычно используют contrastive или two-tower представления, где текст и изображение проецируются в совместимое пространство, а дальше retrieval работает по cosine/dot-product.

Единое пространство нужно, чтобы текстовый запрос, описание товара и изображение можно было сравнивать одной similarity-функцией. Базовый подход - CLIP-like contrastive pretraining или доменный two-tower: image encoder, text encoder и projection heads в общий embedding dimension.

Для продакшена важны calibration и доменная дообученность. Если текст и фото имеют разные распределения, retrieval может начать предпочитать один modality. Поэтому нужны offline пары, hard negatives, контроль категорий и online metrics по сценариям: visual search, related items, recommendations.

Offline: recall@k, nDCG/MAP, coverage и diversity. Online: CTR, add-to-cart/order, revenue, retention, complaint rate, latency и доля fallback.

Offline-метрики зависят от задачи: для retrieval важен recall@k, для ранжирования - nDCG/MAP/MRR, для каталога - coverage, diversity и cold-start slices. В мультимодальном сценарии отдельно проверяются текстовые, визуальные и смешанные запросы.

Online-метрики должны отражать продукт: CTR, add-to-cart, conversion, GMV/revenue, time-to-find, repeat usage. Guardrails: latency, error rate, жалобы, нерелевантные категории, деградация на новых товарах и доля fallback. Offline рост без online эффекта обычно означает, что proxy labels плохо отражают пользовательскую пользу.

Clicks, views, dwell, add-to-cart, purchases и co-occurrence полезны, но смещены позицией, популярностью, availability и текущей логикой ранжирования.

Implicit feedback возникает из поведения: показы, клики, dwell time, сохранения, add-to-cart, покупка, повторный просмотр, совместные покупки и пропуски. Эти сигналы можно использовать для pairwise/listwise обучения, hard negatives и item-item co-occurrence.

Риск в том, что feedback не является unbiased разметкой релевантности. Пользователь видит только то, что уже показал старый ranker; позиция, скидки, наличие товара и популярность искажают labels. Нужны position features, exploration, negative sampling из shown-but-not-clicked, debiasing и проверка slices по новым/long-tail item.

Transformer полезен для sequence/context interactions и мультимодальных признаков, но для candidate retrieval часто нужен более дешевый two-tower/ANN слой.

Transformer хорошо моделирует взаимодействия между элементами последовательности, контекстом, текстом и визуальными признаками. Он уместен в reranker, session-based recommendations, query-document matching и задачах, где важна комбинация признаков, а не независимый embedding каждого item.

Для широкого candidate generation transformer часто слишком дорог: latency и стоимость растут с числом кандидатов. Практичная архитектура обычно двухступенчатая: дешевый retrieval/two-tower/ANN дает top-K, затем transformer или cross-encoder дороже пересчитывает короткий список.

Тяжелый retrieval/precompute выносят offline, online слой читает candidates/features, делает легкий rerank, применяет business rules и имеет fallback.

Online path должен быть коротким: запрос, чтение готовых candidates, свежих user/context features, легкий rerank, business rules и ответ. Тяжелые embeddings, ANN indices, item features и популярные candidate sets лучше считать batch/streaming заранее.

Для reliability нужны timeout, circuit breaker, cache, degraded baseline и мониторинг p50/p95/p99 latency. Если используется GPU inference, добавляются batching, warmup, capacity planning и защита от head-of-line blocking. Качество модели не должно ломать UX при пиках нагрузки.

Для retrieval подходят contrastive/pairwise losses с hard negatives; для ranker - pointwise conversion/click labels или pairwise/listwise ranking losses.

Сначала фиксируется действие, которое модель оптимизирует: click, add-to-cart, purchase, long dwell, contact или composite utility. Для retrieval часто используют contrastive loss: positive пары item-query/user-item и hard negatives. Для ranker возможны pointwise classification/regression, pairwise losses или listwise objectives.

Нужно учитывать bias старого ранжирования. Негативы лучше брать из показанных, но не выбранных объектов, а не из всех непоказанных item. Для бизнес-целей labels можно взвешивать revenue, margin или downstream conversion, но guardrails должны защищать от кликового мусора и потери diversity.

MAP/NDCG оценивают порядок по размеченной релевантности, но бизнес-эффект зависит от действия: покупка, заявка, retention, revenue и качества трафика.

MAP усредняет precision на позициях релевантных объектов и хорошо работает при binary relevance. NDCG учитывает позицию и graded relevance: релевантный объект выше получает больший вклад, а идеальная выдача нормализует score.

Эти метрики полезны offline, но не заменяют product validation. Разметка может не отражать прибыль, availability, long-term satisfaction и разнообразие. Поэтому offline ranking metrics связываются с online экспериментом: CTR, conversion, revenue, complaints, latency и coverage. Разрыв между offline и online сигналом - отдельный предмет анализа.

Item embeddings индексируются в ANN, затем top-K кандидаты фильтруются и rerank-ятся. Recall повышают размером shortlist и настройками индекса, latency контролируют precompute/cache.

Для похожих item обычно считают embedding каждого item и строят ANN index: HNSW, IVF/PQ или managed vector DB. На запросе берется top-K по cosine/dot-product, затем применяются фильтры: availability, category, price, freshness, business rules и diversity.

Recall можно повышать большим candidate pool, точным search, несколькими retrieval источниками и reranking. Цена - latency, память и стоимость обновления индекса. В production полезны offline recall@K на labeled pairs, online guardrails и fallback на популярное/категорийное при пустом или слишком дорогом retrieval.