что такое умный поиск
Зачем интернет-магазину «умный поиск» и как он должен работать
Сегодня востребована технология масштабируемого поиска Elasticsearch, потому что она сильно экономит ресурсы вашего сайта. Давайте разберемся, какие преимущества она открывает интернет-магазинам и как ее реализовать.
Что такое «Умный поиск»
Технология Elasticsearch была создана израильским программистом Шай Бейнонон (Shay Banon) на Java, впервые выпущена в 2010 году, а затем в 2012 году зарегистрирована как Elastiс для коммерческого распространения.
По сути, это мощный поисковик с автоматической индексацией новых объектов, с неограниченным горизонтальным масштабированием. Сейчас Elastiс используют не только мировые гиганты, такие как, Microsoft, Uber, Slack, GitHub, но и интернет-магазины с большим ассортиментов товаров.
Для чего интернет-магазину нужен «Умный поиск»
Технология Elastic использует облачное кеширование данных, которое ускоряет процесс обработки запросов пользователей. Весь индекс хранится на стороннем сервере, что позволяет интернет-магазину не тратить ресурс сервера на поисковые запросы пользователей. Это значит, что сайт с подключенным сервисом Elastic не будет требовать более дорогих тарифов хостинга.
Преимущества «Умного поиска» для магазинов на платформе PHPShop
Основным преимуществом этой технологии стало кеширование данных поиска, и хранение этого индекса данных на стороннем сервере, тем самым, обеспечивая быстроту и не нагружая интернет-магазин запросами к его основному серверу.
Важным преимуществом для владельцев интернет-магазинов с технологией Elastic является возможность настраивать свою фильтрацию и решать любые задачи поиска на сайте. Так, готовый модуль «Умный поиск Elastica» для платформы магазина PHPShop позволяет пользователю быстро находить нужные товары, используя синонимы, опечатки, который обычный поиск просто не будет учитывать, тем самым, позволит покупателю магазина покинуть сайт.
Система умного поиска: что это, как оно работает и как можно настроить
Умный поиск ча щ е используют для коммерческого сайта, который продает товары. Потому что это существенно облегчает поиск нужного товара для клиента.
Что должен уметь умный поиск для сайта
Умный поиск для сайта должен уметь:
Понимать раскладки клавиатур. Если пользователь забыл сменить язык при написании запроса — такой запрос все равно должен быть распознан и найден. Часто такую ситуацию можно наблюдать у поисковых гигантов — у Яндекса и Гугла.
Помогать вам как хозяину интернет-магазина. Если пользователи что-то не нашли на вашем сайте, то вы обязательно должны это увидеть, чтобы иметь возможность расширить ассортимент своего магазина.
анализ всего представленного сайта с целью выводить максимально релевантный результат запроса;
учет и анализ прошлого опыта остальных пользователей, уже нашедших нужный товар на вашем сайте;
внесение новых слов, по которым пользователь ищет необходимый товар, в собственную базу, тем самым обучаясь.
Как можно настроить умный поиск для сайта
Умный поиск для собственного сайта можно настроить двумя путями:
Собственноручно или при помощи сторонних программистов.
Воспользоваться уже готовыми модулями и решениями.
Если вы решитесь самостоятельно внедрить умный поиск для своего сайта, то вам нужно будет найти в сети подходящую для вас инструкцию. Потому что моменты настройки умного поиска зависят от используемой CMS сайта, а если сайт без CMS — то от языка программирования, на котором написан.
Второй путь — это поиск уже готовых решений. Из самых популярных можно предложить:
Умный поиск для вашего сайта способен улучшить ваши показатели по продажам, поэтому не нужно откладывать его внедрение в долгий ящик.
Мы будем очень благодарны
если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.
Умный поиск на сайте: преимущества, возможности и способы настройки
Поиск на сайте, фильтры, сортировки — очень значимые и полезные инструменты, которые помогают посетителям сайта быстрее ориентироваться и находить то, что им нужно. Согласитесь, введя в поисковой строке онлайн-магазина название товара, выбрав нужный цвет, размер и другие параметры с помощью фильтров, отсортировав по цене продукцию, клиент найдет нужный товар намного быстрее, чем если он будет бродить по сайту в надежде подобрать то, что он хочет. И каким же будет его разочарование, если в итоге он ничего не найдет.
Поиск на сайте сейчас стал необходимостью, в основном применяется он на коммерческих сайтах, в частности в интернет-магазинах. Но и для блогов, новостных порталов и других инфоресурсов с количеством страниц более 20 он не будет лишним.
Разберем ситуацию. Вы владелец интернет-магазина автозапчастей, посетитель зашел на сайт, чтобы найти детали Mitsubishi. Точное написание названия этой марки без подсказки повторит далеко не каждый. И вот он вводит «Mitsubisi» или вовсе решает, что на русском все проще и пишет «Мицубиси», а поиск на сайте не распознает таких названий и в результате выводит «Такого товара нет»:
А теперь на этом же сайте, введя запрос без ошибок, увидим, что такой товар есть, причем в широком ассортименте:
Я привела вам наглядный пример, когда из-за небольшой опечатки в названии владелец интернет-магазина потеряет своего клиента, хотя многие из нас часто допускают небольшие оплошности, орфографические ошибки, сокращают слова, не переходят с одной раскладки на другую. И чтобы не возникало таких проблем, разработали умный поиск, о котором мы и поговорим в этой статье.
Умный поиск: что это и в чем его преимущества
Поиск на сайте — это инструмент внутреннего индексирования сайта, который позволяет посетителям получать релевантную запросу выдачу результатов и искать нужные товары.
Умный поиск, в свою очередь, имеет расширенные возможности. За счет искусственного интеллекта он способен распознавать слова с опечатками, синонимы, транслитерации, неверно выбранную раскладку и не только.
Своим принципом умный поиск на сайте напоминает работу поисковых систем, которые так же умело распознают запросы пользователей, даже если они введены неверно.
Работает он по аналогии с тем же поиском Яндекса. Например, исправляет ошибки.
Или распознает запросы, введенные на неверно выбранной раскладке:
О том, какие запросы способен обрабатывать умный поиск, мы поговорим далее.
Преимущества умного поиска на сайте
Выделю два основных и, на мой взгляд, очень весомых плюса:
Возможности умного поиска
Как вы поняли, основная функция поиска — это считывать информацию с сайта и представлять пользователям подходящие запросу страницы. Но умный поиск на то и «умный», а значит и стандартной функцией «просто найти соответствующий запросу товар» он не ограничится. Раз уж он обладает интеллектом, то его задача — понимать пользователя лучше.
Итак, что же умеет умный поиск:
1. Распознавать слова, написанные с ошибками и опечатками
Такое встречается в интернете сплошь и рядом, кто-то случайно, торопясь, пропускает букву, а кто-то в принципе не знает, как пишется, например, словосочетание «дистиллированная вода». Задача умного поиска принимать слова, написанные с ошибкой, с пропущенной буквой, с буквой, указанной два раза, слитно или раздельно написанные слова.
Замечательно настроен умный поиск у сайта М-Видео, на его примере я покажу вам, как умеет справляться с некорректными запросами умный поиск.
Например, вот так на введенный запрос «стЕральные машины» выводятся, как и положено, карточки товаров «стИральных машин»:
Или по запросу «иригаторы», в котором пропущена одна буква Р, выдает товары с правильным названием:
2. Распознавать названия на разных языках
Далеко не все пользователи вводят название марки на нужном языке. Например, многим проще написать «Фольксваген», чем мучиться с латиницей. Это умный поиск тоже должен учитывать.
И для такого случая исправно работает умный поиск от М-Видео. По запросу «пылесосы Борк» находит нам то, что нужно:
Кстати, помимо того, что поиск должен уметь распознавать разные языки, он должен учитывать и возможные ошибки, допускаемые пользователями. Например, на практике мне встречалось разное написание марки «Xiaomi», было и «Сяоми», и «Ксиаоми», и «Ксяоми» и как только не было.
Посмотрим, возникнут ли трудности в таком случае у умного поиска от М-Видео.
Вариант 1. «Сяоми»:
Вариант 2. «Ксиаоми»:
Вариант 3. «Ксяоми».
Как видим, умный поиск в интернет-магазине М-Видео работает отменно.
3. Различать неверно включенную раскладку на клавиатуре
Такое встречается у всех, кто забыл переключиться на русский, а текст уже набрал. Умный поиск должен распознать и это, и точно так же, как поисковик Яндекс или Google, преобразовать текст.
Вот как это работает у М-Видео. Я ввела «ryjgjxyst vj,bkmyst ntktajys», что на русской раскладке значит «кнопочные мобильные телефоны», и поиск меня понял:
4. Понимать синонимы, аббревиатуры, сокращения
Многие пользователи используют привычные им названия, к примеру, аккумуляторные батареи чаще вводят просто, как АКБ, электрические щетки — электрощетки, или телевизоры вовсе называют плазмой. Все эти нюансы должен учитывать умный поиск.
В М-Видео, введя привычное нам слово «микроволновка», получим карточки с правильным полным названием «микроволновые печи»:
Хороший умный поиск поймет нашу разговорную речь. =)
5. Улавливать смысл, не заморачиваясь на грамматике
Правильно настроенный умный поиск учитывает запросы с некорректным написанием рода, числа или падежа, фразы с упущенным предлогом. В строке необязательно вводить детально верное название с правильными окончаниями — убедитесь сами.
Введем «набор посуда микроволновка» без предлогов и все в именительном падеже, но даже так умный поиск справляется на ура:
Все это умный поиск должен уметь, чтобы облегчить жизнь посетителю сайта и не потерять его заказ.
В будущем поиск поможет владельцу ресурса узнавать о предпочтениях пользователей, например, если они искали модель, которой не оказалась на сайте, это отличный повод расширить ассортимент.
Кроме того, поиск можно настроить так, чтобы при ненайденной продукции пользователь мог получить варианты аналогичных или сопутствующих товаров. Это также позволит увеличить конверсии с сайта.
Как настроить умный поиск на сайте
Чтобы внедрить на своем ресурсе умный поиск, можно использовать два варианта:
1. Сделать все своими руками
Вы можете настроить поиск самостоятельно, воспользовавшись инструкцией. Чтобы ее правильно выбрать, учитывайте CMS сайта или язык программирования вашего ресурса. Справиться с такой задачей нелегко, и доверить работы лучше стороннему специалисту, если в вашей команде нет собственного веб-разработчика.
Настройка поиска требует не только определенного уровня знаний и умений, но и времени. Потому что работу поиска нужно постоянно контролировать, анализировать и вносить коррективы, которые изначально не были учтены.
2. Воспользоваться уже готовыми решениями
Специально разработанные модули, как правило, не требуют особых усилий, а инструкции по их установке ограничиваются двумя-тремя шагами. Вам нужно только найти наиболее подходящее для вас решение по стоимости и функциональным возможностям. Благо, на рынке представлено очень много продуктов, расскажу вам про два сервиса, которые тестировала лично.
Умный поиск Multisearch.io
Поиск по сайту, который учитывает транслитерацию, опечатки, неправильно выбранную раскладку, морфологию, синонимы, историю недавних запросов. Есть несколько тарифных планов, отличающихся своими возможностями, стоимость начинается от 2900 рублей в месяц:
Установка не требует сложных настроек — вам нужно указать ссылку на Яндекс.Маркет фид, прописать Javascript строку кода и наслаждаться использованием умного поиска от Multisearch.io.
Умный и быстрый поиск от SearchBooster
Интеллектуальный поиск, который работает с фильтрами по свойствам, управляет синонимами, выводит поисковые подсказки, исправляет раскладку, опечатки, и это далеко не все его возможности. Также есть несколько тарифов, отличающихся опциями. Цены начинаются от 300 рублей в месяц по минимальному тарифу:
Процесс установки такой же простой, как и MultiSearch.io: указываете ссылку на фид Яндекс.Маркета, вставляете Javascript код в html страницы сайта или опубликуйте через GTM.
Вывод
Умный поиск — отличное решение для интернет-магазинов и других сайтов с большим количеством страниц. Он значительно упрощает работу с сайтом для пользователей, понимает их, даже если они говорят на искаженном русском, и за считанные минуты находит то, что им нужно. Для владельца сайта — это не менее важный помощник, ведь он не допустит потери продаж, заказов услуг, потери читателей блога и т.п., а, наоборот, сделает все возможное, чтобы увеличить конверсию на сайте.
После прочтения этой статьи я советую всем внимательно изучить поиск на своем сайте, способен ли он учитывать все, что я перечисляла выше, или ему пора «поумнеть». А если вам потребуется помощь в улучшении вашего сайта, мы всегда готовы вам ее оказать.
Делаем действительно умный поиск: пошаговый гайд
Поиск в корпоративной информационной системе — уже от самой этой фразы вязнет во рту. Хорошо если он вообще есть, о положительном user experience можно даже не задумываться. Как перевернуть отношение пользователей, избалованных поисковыми системами, и создать быстрый, точный, понимающий с полуслова продукт? Надо взять хороший кусок Elasticsearch, горсть интеллектуальных сервисов и замешать их по этому гайду.
Статей о том, как к существующей базе прикрутили полнотекстовый поиск на основе Elasticsearch, в интернете уже предостаточно. А вот статей, как сделать действительно умный поиск, явно не хватает.
При этом сама фраза «Умный поиск» уже превратилась в баззворд и используется к месту и нет. Что же такого должна делать поисковая система, чтобы её можно было считать умной? Ультимативно это можно описать как выдачу результата, который на самом деле нужен пользователю, даже если этот результат не совсем соответствует тексту запроса. Популярные поисковые системы вроде Google и Яндекс идут дальше и не просто находят нужную информацию, а напрямую отвечают на вопросы пользователя.
Окей, сразу на ультимативное решение замахиваться не будем, но что можно сделать чтобы приблизить обычный полнотекстовый поиск к умному?
Элементы интеллектуальности
Умный поиск — это как раз тот случай, когда количество может перейти в качество и множество небольших и достаточно простых фич может сформировать ощущение магии.
Вводная
Есть ECM DIRECTUM со множеством документов в ней. Документ состоит из карточки с метаинформацией и тела, которое может иметь несколько версий.
Цель — быстро и удобно искать информацию в этих документах в привычной для пользователя поисковых систем манере.
Индексирование
Чтобы что-то хорошо поискать, нужно это что-то вначале хорошо проиндексировать.
Документы в ECM не статичны, пользователи модифицируют текст, создают новые версии, изменяют данные в карточках; постоянно создаются новые документы и иногда удаляются старые.
Для поддержания актуальной информации в Elasticsearch документы нужно постоянно переиндексировать. К счастью, в ECM уже есть своя очередь асинхронных событий, поэтому при изменении документа достаточно добавить его в очередь для индексирования.
Отображение документов ECM на документы Elasticsearch
Тело документа в ECM может иметь несколько версий. В Elasticsearch это можно было бы представить как массив nested-объектов, но тогда с ними становится неудобно работать — усложняется написание запросов, при изменении одной из версий надо переиндексировать всё, разные версии одного документа не могут храниться в разных индексах (зачем это может понадобиться — в следующем разделе). Поэтому мы денормализуем один документ из ECM в несколько документов Elasticsearch с одинаковой карточкой, но разными телами.
Кроме карточки и тела в документ Elasticsearch добавляется разная служебная информация, в которой отдельно стоит отметить:
Состав индексов
Да, индексов во множественном числе. Обычно несколько индексов для хранения схожей по смыслу информации в Elasticsearch используются только если эта информация неизменяемая и привязана к какому-то временному отрезку, например логи. Тогда индексы создаются каждый месяц/день или чаще в зависимости от интенсивности нагрузки. В нашем случае может быть изменён любой документ, и можно было бы хранить всё в одном индексе.
Но — документы в системе могут быть на разных языках, а хранение мультиязычных данных в Elasticsearch несёт 2 проблемы:
Стемминг — нахождение основы слова. Основа не обязательно должна являться корнем слова или его нормальной формой. Обычно хватает того, чтобы связанные слова проецировались в одну основу.
Лемматизация — разновидность стемминга, в которой основой считается нормальная (словарная) форма слова.
Первую проблему можно решить для случая, когда разные языки используют разные наборы символов, (русско-английские документы используют кириллицу и латиницу) — языковые стеммеры будут обрабатывать только «свои» символы.
Как раз для решения второй проблемы мы использовали подход с отдельным индексом для каждого языка.
Комбинируя оба подхода, получим языковые индексы, которые тем не менее содержат анализаторы сразу для нескольких не пересекающихся по наборам символов языков: русско-английский (и отдельно англо-русский), польско-русский, немецко-русский, украино-английский и т.д.
Чтобы не создавать все возможные индексы заранее, использовали шаблоны индексов — Elasticsearch позволяет задать шаблон, который содержит настройки и маппинги, и указывать паттерн имени индекса. При попытке проиндексировать документ в несуществующий индекс, имя которого подходит под один из паттернов шаблона, будет не только создан новый индекс, но и к нему будут применены настройки и маппинги из соответствующего шаблона.
Структура индексов
Для индексирования используем сразу два анализатора (через multi-fields): default для поиска по точной фразе и custom для всего остального:
С фильтром lowercase всё понятно, расскажу про остальные.
Фильтры russian_morphology и english_morphology предназначены для морфологического анализа русского и английского текста соответственно. Они не входят в состав Elasticsearch и ставятся в составе отдельного плагина analysis-morphology. Это лемматизаторы, использующие словарный подход в сочетании с некоторыми эвристиками и работающие значительно, ЗНАЧИТЕЛЬНО, лучше встроенных фильтров для соответствующих языков.
Очень любопытный фильтр word_delimiter. Он, например, помогает устранять опечатки, когда после точки нет пробела. Используем следующую конфигурацию:
yo_filter позволяет игнорировать разницу между E и Ё:
ru_en_stopwords фильтр с типом stop — наш словарь стоп-слов.
Процесс индексирования
Из необычного в pipeline — игнорирование ошибок отсутствия тела (такое случается для зашифрованных документов) и определение целевого индекса, исходя из языка текста. Последнее делается в painless-скрипте, тело которого я приведу отдельно, т.к. из-за ограничений JSON его приходится записывать в одну строку. Вкупе со сложностями отладки (рекомендуемый способ — генерация исключений там и сям) он и вовсе превращается в painful.
Таким образом, мы всегда посылаем документ в index_name. Если язык не определился или не поддерживается, то в этом индексе документ и оседает, иначе попадает в index_name_language.
Само исходное тело файла мы не храним, но поле _source включено, т.к. оно требуется для частичного обновления документа и подсветки найденного.
Если с момента последней индексации изменялась только карточка, то для её обновления используем Update By Query API без pipeline. Это позволяет, во-первых, не тянуть потенциально тяжелые тела документов из ECM, а во-вторых, значительно ускоряет обновление на стороне Elasticsearch — не приходится извлекать текст документов из офисных форматов, что весьма ресурсоёмко.
Как такового обновления документа в Elasticsearch вообще нет, технически при обновлении из индекса достается старый документ, изменяется и снова полностью индексируется.
А вот если менялось тело, то старый документ вообще удаляется и индексируется с нуля. Это позволяет документам переезжать из одного языкового индекса в другой.
Поиск
Для облегчения описания приведу скриншот итогового результата
Полнотекст
Основным типом запроса у нас служит Simple Query String Query:
где .exact — это поля, проиндексированные default анализатором. Важность имени документа считаем в два раза выше остальных полей. Сочетание «default_operator»: «or» и «minimum_should_match»: «-35%» позволяет находить документы в которых нет до 35% искомых слов.
Синонимы
Вообще для индексирования и поиска используются разные анализаторы, но единственное отличие в них — это добавление фильтра для подмешивания синонимов в поисковый запрос:
Учёт прав
Для поиска с учетом прав основной запрос вложен в Bool Query, с добавлением фильтра:
Как помним из раздела про индексацию, в индексе есть поле с ИД пользователей и групп, имеющих права на документ. Если есть пересечение этого поля с переданным массивом — значит есть и права.
Тюнинг релевантности
По умолчанию Elasticsearch оценивает релевантность результатов по алгоритму BM25, используя запрос и текст документа. Мы решили, что на оценку соответствия желаемого и фактического результата должны влиять ещё три фактора:
у версий тела в ECM есть несколько возможных состояний: разрабатываемая, действующая и устаревшая. Логично, что действующая важнее остальных.
Добиться такого влияния можно с помощью Function Score Query:
В результате, при прочих равных, получается примерно такая зависимость модификатора рейтинга результата от даты его последнего изменения X и количества обращений Y:
Внешний интеллект
Для части функциональности умного поиска нам необходимо извлечь из поискового запроса различные факты: даты с указанием их применения (создания, изменения, утверждения и т.п.), названия организаций, виды искомых документов и т.п.
Также желательно классифицировать запрос в определённую категорию, например, документы по организациям, по сотрудникам, нормативные и т.п.
Эти две операции выполняются интеллектуальным модулем ECM — DIRECTUM Ario.
Процесс умного поиска
Настало время подробнее рассмотреть, какими механизмами реализуются элементы интеллектуальности.
Исправление ошибок пользователя
Определение правильности раскладки происходит на основе триграмной модели языка — для строки вычисляется, насколько вероятно встретить её трехсимвольные последовательности в текстах на английском и русском языках. Если текущая раскладка считается менее вероятной, то, во-первых, показывается подсказка с исправленной раскладкой:
а во-вторых, дальнейшие этапы поиска выполняются с исправленной раскладкой:
И уж если с исправленной раскладкой ничего не найдётся, то поиск запускается с оригинальной строкой.
Исправление опечаток реализовано с помощью Phrase Suggester. С ним есть проблема — если выполнить запрос на нескольких индексах одновременно, то suggest может ничего не вернуть, в то время как при выполнении только на одном индексе результаты есть. Это лечится установкой confidence = 0, но тогда suggest предлагает заменять слова на их нормальную форму. Согласитесь, странно будет при поиске «письма» получить ответ в духе: Возможно, вы искали письмо?
Это можно обойти, используя сразу два suggester’а в запросе:
Из общих параметров используются
Если первый suggester вернул результат, а второй нет, значит этот результат — сама исходная строка, возможно со словами в других формах, и подсказку показывать не надо. В случае, если подсказка всё-таки требуется, исходная поисковая фраза сливается с подсказкой. Это происходит путем замены только исправленных слов и только тех, которые проверка орфографии (используем Hunspell) сочтёт некорректными.
Если поиск по исходной строке вернул 0 результатов, то он заменяется полученной слиянием строкой и снова выполняется поиск:
Иначе полученная строка с подсказками возвращается только в качестве подсказки для поиска:
Классификация запросов и извлечение фактов
Как я уже упоминал, мы используем DIRECTUM Ario, а именно сервис классификации текстов и сервис извлечения фактов. Для этого мы отдали аналитикам обезличенные поисковые запросы и список фактов, которые нам интересны. На основе запросов и знаний о том, какие документы есть в системе, аналитики выделили несколько категорий и обучили сервис классификации определять категорию по тексту запроса. Исходя из получившихся категорий и списка фактов, сформулировали правила использования этих фактов. Например, фраза за прошлый год в категории Все считается датой создания документа, а в категории По организации — датой регистрации. При этом созданные в прошлом году должно в любой категории попадать в дату создания.
Со стороны поиска — сделали конфиг, в котором прописали категории, какие факты в какие фасетные фильтры применяются.
Автодополнение ввода
Кроме уже упоминавшегося исправления раскладки, в автодополнение попадают прошлые поисковые запросы пользователя и общедоступные документы.
Они реализованы с помощью другого вида Suggester’ов — Completion Suggester, но у каждого есть свои нюансы.
Автодополнение: История поисков
Пользователей в ECM гораздо меньше, чем у поисковых систем, и выделить для них достаточное количество общих запросов почему ленин гриб не представляется возможным. Показывать всё подряд тоже не стоит из-за соображений приватности. Обычный Completion Suggester умеет искать только по всему набору документов в индексе, но к нему на помощь приходит Context Suggester — способ задать для каждой подсказки некий контекст и при поиске фильтровать по этим контекстам. Если в качестве контекстов использовать имена пользователей, то каждому можно показывать только его историю.
Также нужно дать пользователю возможность удалить подсказку, за которую ему стыдно. В качестве ключа для удаления мы использовали имя пользователя и текст подсказки. В результате для индекса с подсказками получился такой, немного дублирующийся, маппинг:
Автодополнение: Документы
А вот документов и возможных комбинаций прав может быть ну очень много. Поэтому тут мы, наоборот, решили при автодополнении фильтрацию по правам не делать, но индексировать только общедоступные документы. Да и удалять отдельные подсказки из этого индекса не надо. Казалось бы, реализация во всём легче предыдущей, если бы не два момента:
Первый — Completion Suggester поддерживает только префиксный поиск, а клиенты так любят присваивать всему номенклатурные номера, и какой-нибудь ЖПА.01.01 Правила сокращения слов по мере ввода запроса Правила сокращения не найти. Тут вместе с полным именем можно индексировать и производные от него n-граммы:
С историей это было не так критично, всё же один и тот же пользователь вводит примерно одну и ту же строку, если ищет что-то повторно. Наверное.
Второй — по умолчанию все подсказки равны, но нам бы хотелось некоторые из них сделать равнее и желательно так, чтобы это было согласовано с ранжированием результатов поиска. Для этого надо примерно повторить функции gauss и field_value_factor, используемые в Function Score Query.
Получается вот такой pipeline:
со следующим скриптом:
Зачем вообще городить pipeline с painless вместо того, чтобы написать это на более удобном языке? Потому что теперь с помощью Reindex API в индекс для подсказок можно перегнать содержимое поисковых индексов (указав только нужные поля, разумеется) буквально в одну команду.
Состав действительно нужных общедоступных документов обновляется не часто, поэтому эту команду можно оставить на ручном запуске.
Отображение результатов
Категории
Категория определяет, какие фасеты будут доступны и как будет выглядеть сниппет. Может быть определена автоматически внешним интеллектом или выбрана вручную над строкой поиска.
Фасеты
Фасеты — это такая интуитивно понятная всем штука, поведение которой, тем не менее, описывается весьма нетривиальными правилами. Вот несколько из них:
Значения фасетов зависят от результатов поиска, НО и результаты поиска зависят от выбранных фасетов. Как избежать рекурсии?
Выбор значений внутри одного фасета не влияет на другие значения этого фасета, но влияет на значения в других фасетах:
В эластике фасеты реализуются через механизм агрегаций, но для соблюдения описанных правил эти агрегации приходится вкладывать друг в друга и друг другом же фильтровать.
Рассмотрим фрагменты запроса, ответственные за это:
Сниппеты
В зависимости от выбранной категории сниппет может выглядеть по-разному, например, один и тот же документ при поиске в категории
и Сотрудники:
Или помните, мы хотели видеть предмет коммерческого предложения и от кого оно поступило?
Чтобы не тащить с эластика всю карточку целиком (это замедляет поиск), используется Source filtering:
Для подсветки найденных слов в тексте документа используется Fast Vector highlighter — как генерирующий наиболее адекватные сниппеты для больших текстов, а для наименования — Unified highlighter — как наименее требовательный к ресурсам и структуре индекса:
При этом наименование подсвечивается целиком, а из текста достаем до 3 фрагментов длиной 300 символов. Текст, возвращаемый Fast Vector highlighter’ом, дополнительно сжимается самодельным алгоритмом для получения минимизированного состояния сниппета.
Коллапс
Исторически пользователи этой ECM привыкли, что поиск возвращает им документы, но на самом деле Elasticsearch ищет среди версий документов. Может получиться, что по одному и тому же запросу будут найдены несколько почти одинаковых версий. Это будет захламлять результаты и вводить пользователя в недоумение. К счастью, избежать такого поведения можно при помощи механизма Field Collapsing — некоторого облегченного варианта агрегаций, который срабатывает уже на готовых результатах (в этом он напоминает post_filter, два костыля — пара). Результатом коллапса станет самый релевантный из сворачивающихся объектов.
К сожалению, коллапс обладает рядом неприятных эффектов, например, различные численные характеристики результата поиска продолжают возвращаться такими, как будто никакого коллапса не было. То есть, число результатов, количество по значениям фасет — все будут слегка неправильные, но пользователь этого обычно не замечает, как и уставший читатель, который вряд ли дочитал до этого предложения.