Синонимы, транслит и магия: Как заставить систему читать мысли пользователя
Поиск сопровождает практически любую информационную систему — будь то интернет-магазин, таск-трекер, CRM или что-либо другое. Заветная иконка поиска присутствует почти везде.
В зависимости от проекта к данной функции предъявляются разные требования. Например, в магазине автозапчастей поиск чаще всего осуществляется по артикулу — казалось бы, просто, но данных очень много. В интернет-магазинах требования к поиску максимально широкие.
Речь идет о транслите, учете ошибок в написании, синонимах и других тонкостях. Обычно все начинается с классического поиска в формате выборки по SQL или нечеткого поиска..
Эволюция
Штатный битрикс поиск умеет искать по названиям и описаниям. Дополнительно в него можно включить любое свойство, чтобы расширить возможности поиска. Это отличный вариант улучшения на старте. Достаточно загрузить каталог в 1С или на сайт и через запятую добавить ключи, по которым должен осуществляться поиск товаров. Функция транслита обычно присутствует, но почти всегда остается выключенной.
Далее можно рассмотреть варианты с дополнительными модулями — поиск работает лучше, но не стоит ожидать чудес.
Появляется Sphinx — довольно старая система, но ее преимущество перед стандартным решением в том, что мы сами индексируем нужные нам данные, плюс поиск становится условно быстрым.
Затем на сцену выходят мощные решения вроде Elasticsearch \+ Kibana — инструмент, который мы регулярно внедряем клиентам. Здесь можно самостоятельно настроить индексацию, синонимы, учет ошибок и аналитические дашборды, а также установить веса — просто идеально.
Мода
Для стартапов и небольших приложений подойдут Meilisearch и Typesense с их простотой использования и быстрой интеграцией. Проекты, связанные с искусственным интеллектом, оценят Weaviate и Milvus благодаря семантическому поиску. Для корпоративных решений рассмотрите Vespa или Opensearch. При необходимости встроить поиск в существующую инфраструктуру обратите внимание на RedisSearch или ZincSearch.
SaaS-сервисы: быстро, но с ограничениями
Отдельно стоит упомянуть SaaS-сервисы. Туда загружается XML или JSON с контентом для индексации, после чего возвращается готовая выдача. Практически это выглядит как установка фрейма или JS-строки поиска с последующим вызовом Vue-компонента с результатами.
Такой подход удобен, но имеет существенные ограничения: зависимость от стороннего сервиса, ежемесячные платежи и невозможность создать, например, SEO-страницу поиска. Это не самый профессиональный способ решения задачи, хотя иногда может быть оправдан срочностью.
Что важно учесть
1. Обработка ввода пользователя
- Транслитерация: Поддержка ввода на русском и английском (например, «stul» и «стул»).
- Опечатки: Распознавание и исправление ошибок (например, «стлу» → «стул»).
- Синонимы: Учет различных формулировок (например, «диван» = «софа»).
- Регистронезависимость: Поиск должен работать независимо от регистра (например, «СТУЛ» = «стул»).
- Множественное число и склонения: Поддержка форм слов (например, «стула», «стулья»).
- Префиксный поиск: Результаты при вводе части слова (например, «стул» → «стул», «стулья», «стульчик»).
2. Логика поиска
- Релевантность: Ранжирование результатов по популярности, наличию и соответствию.
- Поиск по полям: Разделение на основные (названия, категории) и дополнительные (описания, характеристики).
- Фильтры и сортировка: Поддержка фильтров по цене, наличию, категориям и т. д.
- Поиск по частям фраз: Например, «детский стул» → «стул детский», «детский стол и стул».
- Сложные запросы: Поиск по нескольким параметрам одновременно (например, «стул деревянный дешевый»).
3. Обогащение функционала
- Перевод слов: Если сайт многоязычный, поиск должен учитывать перевод (например, «chair» = «стул»).
- Популярные запросы: Отображение популярных и трендовых запросов.
- Подсказки (автокомплит): Предложение вариантов поиска во время ввода.
- История запросов: Возможность повторить предыдущие поиски.
- Семантический поиск: Понимание контекста, даже если запрос некорректен (например, «стол круглый белый»).
Как выбрать правильное решение поиска
Нередко к нам обращаются клиенты с жалобой, что поиск не работает. Это общее описание проблемы, поэтому необходимо получить конкретику, чтобы определить дальнейшие действия.
Для структуризации задачи мы высылаем клиентам опросный лист в формате таблицы, где просим описать проблемы по определенному шаблону: ключевые моменты, текущие результаты и желаемый.
По результатам заполнения таблицы становится понятно, стоит ли просто доработать штатный поиск или необходимо внедрять более тяжеловесное решение.
Пример таблицы, которую клиент сможет заполнить для анализа текущей работы поиска:
Инструкция для заполнения:
- Запрос: Впишите поисковый запрос, который пользователь может ввести.
- Что выводится сейчас: Скопируйте ссылку на текущие результаты поиска (или опишите, что выводится).
- Что должно выводиться: Опишите, как вы ожидаете, что результаты должны быть отображены.
- Ошибка, которая не обрабатывается: Укажите, какая ошибка присутствует в работе поиска (например, отсутствие фильтрации, неработающие синонимы, игнорирование опечаток и т. д.).
Этот формат поможет четко определить проблемные места и области для улучшения.
Заключение
При выборе дальнейшего решения важно помнить о производительности. Если в системе миллион товаров или торговых предложений, выбор решений становится существенно ограниченным.
Вспоминая пример с Wrike, где поиск осуществлялся по названиям, содержанию описаний проектов и задач, включая комментарии. А в Яндекс.Трекере, к примеру, общий поиск работает только по названиям задач — крайне неудобно.
Важно отметить, нужна какая то система аналитики с отслеживание самых популярных запросов и запросов на которых нет ответов. Это позволит постепенно улучшать поиск.