Генерация кандидатов и реранжирование в поиске маркетплейса
Как построить архитектуру поиска: от первичных кандидатов до финального ранжирования?
Ответить самому
Сначала сформулируйте ответ как на собеседовании, затем откройте разбор и оцените себя.
Короткий ответ
Первый этап достает кандидатов через lexical search, filters, synonyms, vector retrieval и popularity fallback. Второй этап реранкер сортирует top-N по query-item-user-context признакам и бизнес-ограничениям.
Полный разбор
Архитектура обычно каскадная. Retrieval должен быстро найти достаточно широкий набор кандидатов: inverted index/BM25, морфология, синонимы, фильтры, category matching, vector retrieval по тексту/изображению, популярные товары для fallback. Его цель - высокий recall и приемлемая latency.
Реранкер работает по сотням или тысячам кандидатов и может быть богаче: query text features, item attributes, price, availability, seller quality, user history, query-item match, historical CTR/CVR, margin, delivery constraints. Модель может быть бустингом, neural ranker или ансамблем.
В production важно версионировать index, фичи и модель, уметь объяснить пустую выдачу, ограничивать дорогое реранжирование и иметь fallback на lexical/popular results.
Теория
Retrieval ищет широко и быстро, реранжирование сортирует точнее и дороже.
Типичные ошибки
- Пытаться делать весь поиск только embedding retrieval.
- Пускать реранкер по всему каталогу.
- Не иметь fallback для новых или странных запросов.