Wildberries technical: поиск по фото и visual search

Detection подходит, если нужен bounding box основного объекта; segmentation нужна, когда фон/соседние предметы сильно мешают эмбеддингу или важны тонкие границы.

Для visual search обычно сначала локализуют объект, затем считают embedding по crop. Bounding box дешевле, проще размечается и часто достаточен для одежды, обуви или предметов на чистом фоне. Segmentation имеет смысл, если background leakage ломает similarity, объект имеет сложную форму, нужно отделять товар от модели/интерьера или несколько объектов пересекаются.

На проде решение зависит от latency, стоимости разметки, качества retrieval после crop и доли плохих фото. Хороший ответ предлагает сравнить варианты через retrieval NDCG/Recall@K, manual error analysis и online метрики.

Считать embedding на каждое фото и агрегировать max/attention/learned pooling, сохраняя также per-photo embeddings для детализации и explainability.

Один embedding на весь товар удобен для индекса, но теряет детали. Практичный дизайн: хранить per-image embeddings, выделять main-photo embedding и агрегированный product embedding. На retrieval этапе можно искать по нескольким векторам или брать top candidates по product embedding, а затем rerank-ить по лучшему совпадению query image с конкретным фото.

Для атрибутов полезно агрегировать не только векторы, но и предсказания цвета, категории, бренда, силуэта. Нужны веса по типу фото, качеству, zoom/detail и позиции в карточке.

Совместить закрытую taxonomy для фильтров с open-vocabulary embeddings/VLM для long tail, а качество проверять на retrieval и attribute precision.

Для продовой навигации нужен нормализованный словарь цветов: черный, белый, красный, бежевый и т.п. Но реальные фото дают оттенки, паттерны и маркетинговые названия. Поэтому стоит иметь несколько слоев: CV-классификатор в базовую taxonomy, цветовые features из изображения, текстовые/VLM-теги для long tail и mapper в canonical attributes.

В visual search цвет может быть hard filter, soft feature в reranker или explanation. Риски: освещение, фон, multi-color items, разные категории и seller metadata noise.

Нужны пары/триплеты из поведенческих и каталоговых сигналов, hard negatives из близких категорий и offline evaluation на query-photo to item retrieval.

Позитивы можно брать из одинаковых SKU, вариантов одного товара, кликов/покупок после visual search, ручной разметки похожести и товарных групп. Негативы должны быть не случайными, а сложными: та же категория, похожий цвет, другой бренд/фасон, визуально близкий, но нерелевантный item.

Loss: contrastive/triplet, supervised contrastive, ArcFace-подобные варианты или dual encoder с in-batch negatives. Важно учесть category hierarchy: иногда пользователь хочет такой же товар, иногда похожий стиль. Поэтому evaluation должен иметь уровни релевантности.

Разделить cadence модели и индекса: новые товары индексировать инкрементально, модель выкатывать версионированно с backfill embeddings и shadow checks.

Пайплайн: ingest новых/измененных фото, quality checks, crop/attribute extraction, embedding, запись в feature store/vector store, инкрементальное обновление ANN. Переобучение модели может быть weekly/monthly или по drift-сигналам, но новая версия требует backfill embedding всего активного каталога или dual-index migration.

Нужны versioned embeddings, rollback, мониторинг latency/recall, доли stale items, failed image processing, distribution drift и quality на holdout queries.

VLM-теги полезны как soft semantic features и debug/explanation layer, но их надо валидировать из-за hallucinations, taxonomy drift и category leakage.

VLM может вытаскивать стиль, материал, паттерн, форму и контекст, которые плохо ловятся обычным embedding. Эти признаки можно использовать в reranker, query expansion, attribute matching или для explainability. Но в e-commerce важна точность: неверный бренд, материал или цвет приведет к плохому поиску и модерационным проблемам.

Практичный вариант: ограничить VLM structured schema, делать confidence thresholds, маппить в taxonomy, хранить source/version и сравнивать uplift относительно baseline.