Поиск по витрине — самый коммерчески нагруженный экран интернет-магазина. Покупатель, который вводит запрос, уже знает, чего хочет: его конверсия в разы выше, чем у того, кто листает категории. Если поиск выдаёт «ничего не найдено» на опечатку, теряет товар из-за разнобоя в словах или показывает нерелевантную выдачу, магазин платит за это прямой потерей заказов. Ниже — открытый разбор того, как ритейл решает эту задачу на Elasticsearch. Это не кейс KT.Team, а обзор отраслевых практик с ссылками на первоисточники.
Почему именно Elasticsearch для каталога
Elasticsearch — распределённый поисковый движок с открытым исходным кодом, построенный на Apache Lucene. Для e-commerce он закрывает три задачи одним инструментом: полнотекстовый поиск с ранжированием, фасетную фильтрацию через агрегации и подсказки/автодополнение. В основе ранжирования лежит алгоритм BM25 — он же стоит в Elasticsearch и Apache Solr и остаётся стандартом продакшен-поиска в e-commerce: ранжирует товары по частоте вхождения терминов запроса в название, описание и атрибуты (oneuptime).
Ключевая архитектурная развилка — не форкать ядро магазина ради поиска. Зрелый подход: поднимать Elasticsearch отдельным сервисом рядом с платформой (Shopware, Magento, кастомный бэкенд), синхронизировать в него каталог и держать поисковую логику в этом сервисе. Так поиск можно развивать и отдавать другой команде без переписывания витрины — типичный пример для отдельного микросервиса вместо доработки монолита.
Фасеты: фильтры со счётчиками, которые не врут
Фасетный поиск позволяет фильтровать выдачу по бренду, цене, рейтингу и атрибутам, показывая рядом с каждым значением количество товаров. В Elasticsearch это делается агрегациями: `terms` для категориальных полей (бренд, категория) и `range` для непрерывных (цена) (oneuptime).
Главная инженерная тонкость — счётчики при мультивыборе. Если применить фильтр обычным `query`, он сузит и выдачу, и счётчики всех фасетов; пользователь, выбрав бренд, увидит обнулённые счётчики цен. Правильная схема: `post_filter` применяет фильтр после расчёта агрегаций, а для каждого фасета строится отдельная вложенная filter-агрегация, учитывающая фильтры всех остальных фасетов, кроме самого себя. Так все счётчики остаются корректными при любой комбинации выбранных значений (oneuptime). Бизнес-результат прямой: покупатель не упирается в нулевые фильтры и не бросает поиск.
Синонимы: один товар — много слов
Покупатели называют одно и то же по-разному: «женские / женская / для женщин», «телефон / смартфон / мобильник», «кеды / кроссовки». Без обработки синонимов часть запросов уходит в пустую выдачу. Elasticsearch решает это синонимическим фильтром в анализаторе: список соответствий применяется на этапе индексации или запроса и объединяет варианты в один смысл. Здесь работает правило «читай, прежде чем писать»: вместо самописного словаря разумнее опереться на готовые отраслевые тезаурусы и стандартные механизмы движка, дополняя их данными собственной поисковой аналитики (что люди реально вводят и не находят).
Исправление опечаток: fuzzy и edit distance
Опечатки — массовая причина «ничего не найдено», особенно с мобильных. Elasticsearch поддерживает нечёткий поиск на основе расстояния Левенштейна (edit distance): «adidos» находит «adidas», «iphione» — «iphone» (oneuptime). Параметр `fuzziness` задаёт допустимое число правок; на практике его комбинируют с автодополнением через edge n-grams, чтобы подсказки появлялись с первых символов и снижали саму вероятность опечатки. Каждый запрос, который раньше давал ноль результатов, а теперь ведёт на товар, — это сохранённый заказ.
Ранжирование под бизнес-метрики
Релевантности по BM25 для коммерции мало: одинаково подходящие товары надо ранжировать с учётом маржи, наличия, рейтинга и поведения пользователя. Базовый приём — `function_score` с мультипликативным бустингом: итоговый скор = BM25 × (1 + совпадение когорт × вес), что аккуратно поднимает нужные товары, не ломая текстовую релевантность (Elastic Search Labs).
Следующий уровень — Learning to Rank: модель машинного обучения переупорядочивает выдачу по выбранным метрикам. Открытый плагин Elasticsearch Learning to Rank от OpenSource Connections используется в поиске Yelp, Wikipedia и Snag. Snag сообщает о результате после внедрения LTR: «чистый прирост конверсии на 32% на исторически худших сценариях» (OpenSource Connections). Чтобы тюнинг был не на глаз, релевантность измеряют: инструмент Quepid (открытый, работает с Elasticsearch и Solr) ведёт тест-кейсы запросов, ручные оценки и автоматический расчёт NDCG, фиксируя, что каждое изменение конфигурации действительно улучшает выдачу (OpenSource Connections).
Эффект для бизнеса
Качество поиска напрямую конвертируется в деньги. По данным отраслевых обзоров, включённый поиск по сайту способен поднимать конверсию до 50%, а бренд HSE после повышения точности поиска на Elasticsearch зафиксировал рост удовлетворённости клиентов на 8% (hyperflex). Цифры зависят от исходного состояния витрины, но направление устойчивое: меньше нулевых выдач, точнее фильтры, выше товар с маржой в топе — выше конверсия поиска и средний чек.
Вывод для бизнес-процесса
Поиск по каталогу перестаёт быть «полем ввода» и становится управляемым процессом: запросы логируются, нулевые выдачи и опечатки разбираются, синонимы и бусты ведутся как живой словарь, а каждое изменение проверяется на тест-наборе через NDCG. Этот цикл — измеряй релевантность, правь конфигурацию, проверяй на метрике, выкатывай — превращает поиск из разовой настройки в постоянный драйвер конверсии и среднего чека, причём вся механика строится на open-source без форка ядра магазина.
