Поиск по русскоязычным синонимам брендов
Магазин люксовой оптики
Введение
Наблюдения показали, что пользователи вводили в поиск “Гуччи”, “Диор”, “Версаче”, а система, ожидавшая строгое соответствие латинскому написанию, не находила совпадений. Это напрямую влияло на конверсию и пользовательский опыт: часть аудитории просто не доходила до карточки товара.
Для бизнеса появилась задача распознавать русскоязычные формы названий брендов и возвращать релевантные товары.
Однако опыт нашей команды позволил посмотреть на задачу шире. Мы понимали, что добавить поиск по синонимам — это лишь половина решения. Важно было сделать его масштабируемым, быстрым и технологически устойчивым при любом трафике. Именно поэтому, помимо бизнес-ожиданий, мы сразу подняли вопрос архитектуры, производительности и надёжности.
Описание системы
Речь идёт о современной e-commerce платформе, построенной на Laravel. В каталоге — 194 бренда и 34000 товаров. Изначально система была организована по классической схеме: у товаров есть связь с брендом, всё соединено через pivot-таблицы. Система масштабировалась по товарным позициям, но не была готова к работе с гибкими языковыми формами и массовыми текстовыми фильтрами.
При попытке внедрить русскоязычные синонимы в существующую структуру, стало ясно: каждый запрос начинает инициировать тяжёлые JOIN'ы. Для 100 поисковых операций выполнялось до 1500 SQL-запросов. При высокой нагрузке это приводило к заметному снижению отклика системы.
Кроме того, отсутствовал централизованный способ наполнения синонимов. Ручное внесение данных через административную панель было непрактичным и не позволяло контролировать качество.
Проблема №1: Пользователи ищут как им удобно!
При вводе “гуччи” пользователь должен получить товары бренда Gucci. Это очевидное поведение для любой современной e-commerce платформы.
Мы внедрили полноценную работу с синонимами брендов. На первом этапе — с помощью языковой модели ИИ, которая сгенерировала список транслитераций, разговорных и распространённых форм. На втором этапе — через ручную верификацию и доработку этих списков командой контента. Это обеспечило полноту и точность результатов.
Импорт синонимов был реализован через CSV-файлы, что позволило администраторам легко пополнять базу — быстро, централизованно и без участия программистов.
Проблема №2: Архитектура поиска создает нагрузку на БД
Мы понимали, что наращивание объёма данных при сохранении текущей структуры неизбежно приведёт к снижению производительности.
Было принято стратегическое решение провести денормализацию. Мы перенесли синонимы бренда напрямую в модель товара. Поиск начал выполняться в основной таблице товаров. Это позволило отказаться от JOIN-запросов, сократив нагрузку на базу данных в десятки раз.
Кроме того, синхронизация синонимов между брендами и товарами организована асинхронно — через события и очереди Laravel. Это гарантирует устойчивость системы даже в периоды пиковых нагрузок.
Проблема №3: Любые массовые обновления должны быть безопасны для продакшена
Обновление синонимов не должно останавливать или замедлять сайт. Всё должно происходить прозрачно для конечного пользователя.
Обновления выполняются в фоне. При изменении синонимов бренда срабатывает событие, которое инициирует очередь на обновление всех связанных товаров. Вся нагрузка распределяется без влияния на производительность.
| Показатель | До оптимизации | После оптимизации |
|---|---|---|
| SQL-запросов на 100 поисков | ~1500 | ~100 |
| Среднее время отклика поиска | ~800 мс | <120 мс |
| Конверсия с поиска | ~2.5% | >4.1% |
| Масштабируемость | Ограниченная | Высокая |
SQL-запросов на 100 поисков
~1500
~100
Среднее время отклика поиска
~800 мс
<120 мс
Конверсия с поиска
~2.5%
>4.1%
Масштабируемость
Ограниченная
Высокая
Мы не просто реализовали поиск по синонимам. Мы сделали его устойчивым, быстрым и готовым к масштабированию. Этот подход позволил клиенту не только решить текущую бизнес-проблему, но и создать технологическую базу для дальнейшего роста.
Заключение
Проект продемонстрировал, как правильная постановка задачи в сочетании с инициативой со стороны технической команды приводит к решению, превосходящему изначальные ожидания.
Следующий этап — предиктивный поиск и расширение логики обработки пользовательских запросов.
Результат: поиск стал точнее, платформа — стабильнее, а команда клиента — независимее в управлении данными.