Исправление ошибок поиска по каталогу товаров
Содержание 16 разделов
Поиск может вернуть двадцать товаров и всё равно не решить задачу покупателя. Вверху окажутся аксессуары вместо основного товара, точный артикул потеряется среди похожих кодов, запрос с опечаткой даст пустую страницу, а отсутствующий товар не приведёт к подходящей замене. Поэтому исправление поиска начинается с реальных запросов и критериев релевантности, а не с установки нового движка.
Задача качественного поиска — быстро показать доступный и подходящий товар, объяснить пустой результат и дать следующий шаг. Для этого нужны данные каталога, правила обработки текста, ранжирование, понятный интерфейс и регулярная оценка результата.
Какие ошибки встречаются в поиске
Нулевая выдача при наличии товара
Покупатель вводит разговорное название, словоформу, опечатку, старый артикул или текст в другой раскладке. Товар существует, но индекс и запрос используют разные представления. Это наиболее заметная ошибка, однако пустая страница составляет только часть проблем.
Нерелевантный верх выдачи
Нужный товар найден, но находится ниже расходников, архивных позиций или совпадений в длинном описании. Причина обычно в одинаковом весе полей, отсутствии точного приоритета для названия и артикула либо в бизнес-правилах, которые перекрывают текстовую релевантность.
Слишком широкая выдача
Запрос «насос 12 В» показывает все насосы и все товары с числом 12. Числа, единицы измерения, модели и технические характеристики требуют отдельной нормализации и поиска по структурированным полям.
Точный код не находится
Артикулы различаются дефисом, пробелом, регистром, кириллическими и латинскими буквами. Для них нужен точный нормализованный индекс, а не только морфологический анализ обычного текста.
Автодополнение ведёт не туда
Подсказки повторяют популярные запросы, но не учитывают наличие, категорию и текущий ввод. Они могут предлагать товары, которые затем отсутствуют в выдаче. Подсказка и поиск должны опираться на согласованные правила и обновляться вместе с каталогом.
Поиск работает медленно или нестабильно
Запрос блокирует базу, индекс обновляется с задержкой, часть узлов возвращает старые цены, а при недоступности движка пользователь получает ошибку. Производительность и свежесть данных входят в качество поиска наравне с релевантностью.
Какие данные собрать до доработки
Яндекс Метрика умеет отслеживать использование внутреннего поиска и поисковые фразы по параметру URL; для нестандартного параметра его можно указать в настройке цели.[1] В GA4 запрос доступен в параметре search_term события view_search_results.[2] Если поиск отправляется POST-запросом или работает без смены URL, событие передают вручную.
Для каждого запроса полезно записывать:
- исходный запрос и его технически нормализованную форму;
- число результатов и идентификаторы верхних позиций;
- время ответа и код ошибки;
- клик по результату, позицию клика и применённый фильтр;
- добавление в корзину и покупку после поиска;
- версию индекса или конфигурации поиска;
- тип устройства и раздел, из которого начат поиск.
Телефон, имя, адрес и содержимое других полей заказа для анализа поискового запроса не нужны. Технический идентификатор сессии помогает связать события без копирования лишних данных в журнал.
Метрики качества поиска
Одна «конверсия пользователей поиска» смешивает качество поиска и более высокое намерение человека, который уже знает, что ему нужно. Рабочий набор включает несколько показателей:
- нулевая выдача — доля запросов без результата;
- выдача без клика — результаты были, но ни один не выбран;
- переформулировка — новый запрос вскоре после предыдущего;
- CTR результата и распределение позиций клика;
- добавление в корзину после поиска;
- время ответа по медиане и верхним перцентилям;
- свежесть индекса — задержка между изменением товара и появлением в поиске.
Для контрольного набора с экспертной разметкой используют технические метрики Recall@k, MRR или nDCG. Они полезны только при заранее согласованном ответе на вопрос, какие товары релевантны запросу и в каком порядке.
Классификация запросов
Перед настройкой правил запросы делят по намерению:
- точный идентификатор: артикул, SKU, модель, штрихкод;
- категория: «офисные кресла»;
- атрибуты: «кабель USB-C 2 м белый»;
- бренд и серия: производитель плюс линейка;
- задача: «средство от накипи»;
- разговорное название или синоним;
- ошибка ввода: опечатка, раскладка, транслитерация;
- информационный запрос: доставка, гарантия, инструкция.
Каждый тип требует своего маршрута. Точный артикул получает приоритет точного совпадения; запрос категории может вести в листинг с фильтрами; информационный запрос — в подходящий материал или справочный раздел, если товары не отвечают на него.
Как устроена обработка запроса
Полнотекстовые движки разбивают текст на токены и применяют анализаторы при индексации и поиске. OpenSearch описывает цепочку из символьных фильтров, токенизатора и фильтров токенов; одинаковая логика анализа на стороне документа и запроса помогает получить сопоставимые термы.[3]
Базовая нормализация
Обычно безопасно убрать лишние пробелы, привести регистр, нормализовать типографские дефисы и согласовать написание единиц измерения. Замены кириллицы на похожую латиницу и наоборот выполняют осторожно: для обычного слова это может быть ошибкой, а для артикула — обязательным правилом.
Русская морфология
Языковой анализатор приводит словоформы к общему представлению. Встроенный русский анализатор OpenSearch использует нижний регистр, список стоп-слов и русский стеммер.[4] На каталоге его проверяют отдельно: агрессивное приведение основы может объединить разные технические термины, бренды и модели. Для защищённых слов применяют исключения.
Синонимы
Синонимы связывают лексику покупателя с каталогом: «шуруповёрт» и «дрель-шуруповёрт», старое и новое название линейки, профессиональный и бытовой термин. Правила составляют из запросов, поддержки и товарной экспертизы. Документация Elasticsearch показывает два вида правил: эквивалентные группы и направленные замены.[5] Направленная связь полезна, когда слова близки только в контексте каталога.
Словарь хранится как управляемые данные: у правила есть автор, дата, причина и тестовые запросы. Массовое добавление «похожих слов» без проверки расширяет выдачу и ухудшает первые позиции.
Опечатки
Fuzzy-поиск находит термы в пределах редакционного расстояния. OpenSearch предупреждает, что большое число расширений и нулевой неизменяемый префикс могут ухудшить производительность.[6] Поэтому опечатки разрешают с ограничениями: для достаточно длинных слов, после попытки точного поиска, с меньшим весом и отдельными правилами для артикулов.
Раскладка и транслитерация
Преобразование «cjrf» в «сока» или латинского названия бренда в кириллицу запускают только при уверенном сценарии. Сначала выполняют исходный запрос, затем допустимое преобразование и сравнивают качество. Автоматическая замена исходного текста без возможности вернуться может скрыть корректный бренд или модель.
Индексировать поля отдельно
Название, артикул, бренд, категория, характеристики и описание несут разный смысл. Их индексируют отдельными полями и задают вес:
- точное совпадение артикула — самый сильный сигнал;
- точная фраза в названии — выше отдельного слова;
- бренд и категория — выше совпадения в длинном описании;
- характеристики участвуют вместе с единицами измерения;
- служебный и SEO-текст получает небольшой вес или исключается.
Для небольшого каталога возможностей полнотекстового индекса СУБД может быть достаточно. MySQL поддерживает FULLTEXT-поиск в естественном, булевом режиме и с расширением запроса.[7] При сложной морфологии, большом количестве полей, подсказках и отдельных правилах ранжирования специализированный движок даёт больше контроля.
Ранжирование и бизнес-правила
Текстовая релевантность отвечает на вопрос «насколько товар соответствует запросу». Наличие, регион, цена, маржинальность и популярность — дополнительные сигналы. Их соединяют так, чтобы бизнес-правило не делало нерелевантный товар первым.
Практический порядок:
- отсечь недопустимые для продажи позиции или явно обозначить их статус;
- рассчитать текстовую релевантность;
- применить умеренные коэффициенты наличия, популярности и персональных условий;
- проверить верх выдачи на контрольных запросах.
Ручное поднятие товара должно иметь срок и владельца. Иначе временная акция навсегда останется выше точного результата.
Автодополнение и подсказки
Автодополнение помогает сформулировать запрос, но не заменяет основной поиск. В подсказках можно показывать категории, популярные формулировки, товары и точные артикулы разными типами строк. Результат обновляют с задержкой после ввода и отменяют устаревший сетевой запрос, чтобы более медленный ответ не перезаписал новый.
Подсказки учитывают наличие и права пользователя, если каталог зависит от региона или договора. Клавиатурная навигация, выделение текущего пункта и понятное закрытие списка входят в приёмку.
Что показать при нулевой выдаче
Пустая страница должна помочь продолжить:
- сохранить исходный запрос в поле;
- предложить исправление, если оно уверенное;
- показать близкую категорию или проверенные синонимы;
- дать снять слишком строгие фильтры;
- предложить связаться с магазином или оставить запрос на товар.
Случайные популярные товары без связи с запросом маскируют нулевую выдачу в аналитике. Технический результат должен оставаться нулевым, даже если интерфейс показывает полезные альтернативы.
Выбор уровня решения
- Настройка текущего поиска: поля, веса, индекс, обновление и исправление явных ошибок.
- Словари и нормализация: синонимы, артикулы, единицы, раскладка, опечатки.
- Специализированный движок: отдельный индекс, анализаторы, подсказки и масштабирование.
- Гибридный поиск: текстовые сигналы дополняются семантическими для запросов по задаче. Точный артикул и фильтры сохраняют приоритет.
Переход на следующий уровень оправдан измеримой проблемой. Семантическая модель не исправит неверные остатки, пустые характеристики и отсутствующие связи между вариантами товара.
План исправления
- Собрать запросы, клики, нулевую выдачу, ошибки и время ответа.
- Подготовить контрольный набор из частых, важных и проблемных запросов.
- Разметить ожидаемые товары и допустимые альтернативы.
- Исправить качество каталога: названия, артикулы, характеристики, категории.
- Настроить анализаторы, поля, веса, словари и обработку опечаток.
- Прогнать автоматическую оценку и ручную проверку верхних результатов.
- Запустить новую конфигурацию на части трафика или за переключаемым флагом.
- Контролировать релевантность, скорость, ошибки и бизнес-показатели.
Как подготовить контрольный набор запросов
Набор должен отражать реальную нагрузку и важные исключения. Его собирают из четырёх частей:
- частые запросы за несколько месяцев;
- запросы с нулевой выдачей или без клика;
- важные для бизнеса категории и точные артикулы;
- специальные случаи: опечатки, единицы измерения, раскладка, длинные модели и синонимы.
Для каждого запроса эксперт отмечает обязательные результаты, допустимые результаты и явно нерелевантные позиции. Если возможны разные намерения, это фиксируют: запрос «мышь» может означать устройство или товар для животных в зависимости от ассортимента. Разметку пересматривают при изменении каталога.
Автоматический прогон сравнивает старую и новую конфигурации. Отдельный отчёт показывает запросы, где верх выдачи изменился сильнее всего. Именно их проверяют вручную до переключения индекса. Такой подход защищает от ситуации, когда исправление десяти популярных опечаток незаметно ломает поиск по артикулам.
Ограничения и защита поискового API
Поисковая строка принимает пользовательский ввод, поэтому запросы ограничивают по длине, времени выполнения и числу расширений. Символы специального синтаксиса экранируют либо передают через безопасный API, не собирая SQL или DSL строковой конкатенацией. Частые запросы кэшируют там, где это не создаёт устаревшие цены и остатки.
Пустой, чрезвычайно общий или заведомо дорогой запрос получает предсказуемый ответ. Система ограничивает количество результатов и глубину пагинации. Журналы ошибок не содержат секретов конфигурации, а внешнему посетителю показывается понятное сообщение.
Если поиск зависит от персональных цен или закрытого B2B-ассортимента, фильтрация прав выполняется до выдачи результата и подсказок. Скрытый товар не должен появляться в количестве, автодополнении или кэше другого пользователя.
Безопасный выпуск и откат
Новый индекс строят отдельно, проверяют количество документов и только затем переключают поиск через alias или конфигурацию. Предыдущий индекс сохраняют на период наблюдения. Если внешняя поисковая система недоступна, сайт должен вернуть понятное сообщение или ограниченный резервный поиск, а не зависнуть вместе с каталогом.
После выпуска проверяют частые запросы, точные артикулы, пустой ввод, очень длинные строки, специальные символы, параллельное обновление цен и наличие. Отдельно измеряют 95-й и 99-й перцентили времени ответа: среднее значение скрывает редкие, но заметные задержки.
Итог
Хороший поиск строится на реальных запросах и контрольном наборе, а технология выбирается под выявленные ошибки. Сначала устраняют качество данных и событий, затем настраивают поля, анализаторы, синонимы, опечатки и ранжирование. Результат подтверждают не числом внедрённых функций, а тем, насколько чаще покупатель видит нужный товар в верхней части выдачи и продолжает путь без технических сбоев.
Источники
- Яндекс Метрика: поиск по сайту и статистика поисковых фраз.
- Google Analytics: параметр search_term.
- OpenSearch: анализ текста при индексации и поиске.
- OpenSearch: русский языковой анализатор.
- Elasticsearch: правила синонимов.
- OpenSearch: fuzzy query и ограничения расширений.
- MySQL: функции полнотекстового поиска.