Мы просто хотели написать про Elasticsearch, потому что нас о нём спрашивали, но, как всегда, копнули глубже. Поэтому в сегодняшнем большом материале расскажем, когда и как появился поиск в интернетах, какие этапы проходит любой поисковый запрос, два сценария поиска пользователей и что умеет самый популярный движок для реализации поиска на сайте.

В конце материала — тест, чтобы закрепить прочитанное :)

Интернет появился в 1980-х благодаря Тиму Бернерсу-Ли, но чтобы найти в нём или на FTP-серверах хоть что-либо в то время, нужно было точно знать, где это лежит. Способов узнать было немного: или спросить у владельца данных напрямую, или получить ссылку по электронной почте.

В 1989 году появился первый поисковик Арчи, который решал эту проблему — он умел индексировать данные: за счёт этого их было легко находить. А в 1994-м появилась другая система — JumpStation, которая решала другую проблему: до её появления всю информацию о появлении новых сайтов в интернете создателю всемирной сети приходилось добавлять вручную. Больше сайтов становилось — больше времени тратилось. Создатель JumpStation написал программу, которая автоматически индексировала изменения в списке сайтов при появлении новых и искала информацию по актуальным страницам. По факту, это был первый поисковый робот — повсеместно использующаяся в нынешних поисковых системах технология.

С 1993 по 1996 появляются сразу несколько поисковиков: Aliweb, Yahoo, Lycos, Altavista, Excite, AskJeeves, Inktomi. Замыкает список BackRub, который в 1997 переименуют в Google. В 1998 в команду поисковых систем добавилась также MSN, которая теперь известна как Bing.

Чтобы продвигать сайты в поисковой выдаче в начале «нулевых» годов, было достаточно пару месяцев пообмениваться ссылками между сайтами, зарегистрироваться в базе каталогов и выделить бюджет на покупку 15−20 «хороших» ссылок. Но чем дальше, тем сложнее становились алгоритмы поиска и тем чаще в них стали вмешиваться коммерческие интересы самих поисковиков (Гугл регулярно обвиняют в том, что он втюхивает рекламный контент на первой странице поиска в соотношении почти 50 на 50 с полезными ссылками). Но где коммерческая выгода, там и удобство: современные поисковики ищут ответы на самые невероятные вопросы. А пользователи автоматически ждут таких же подвигов от любого поиска: хоть на сайте, хоть в приложении, хоть в сервисе.

Поиск по ключевым словам
Раньше весь поиск в интернетах был только таким — что вводишь в поисковую строку, то и получаешь (и не факт, что это то, что ты хотел). Например, на запрос «время в Санкт-Петербурге» поисковые системы выдали бы ссылки на сайты, где упоминались бы слова «время» и «Санкт-Петербург». Но мы-то хотели знать местное время, поэтому нам пригодится семантический поиск.

Семантический поиск
Семантический поиск на запрос «время в Санкт-Петербурге» покажет сайты, где указано точное время в северной столице. Его главное преимущество в том, что он опирается не на ключевые слова как таковые, а на взаимосвязи. У Гугла за это отвечает сеть Knowledge Graph (а ещё — Hummingbird, RankBrain и BERT). У Yahoo это — SearchMonkey.

Принцип работы семантического поиска — построение связей между объектами. За счёт этого вы легко сможете найти, «кто играл чувака, который застрял на острове», «штука для мытья окон с магнитом» и прочие умопомрачительные запросы.

Визуальный
Тут одной семантикой сыт не будешь: помимо чётких описаний изображений, которые соответствуют запросам пользователей, нужна самообучающаяся система на базе ИИ. Скорее всего, в будущем текстовый поиск никуда не денется, но будет повсеместно сочетаться с визуальным для более точных результатов.

Голосовой
Для распознавания голоса тоже используются искусственный интеллект и нейронные сети. А когда запрос преобразован в текст, подключается семантический поиск для выдачи результатов.

Неважно, насколько развиты поисковые системы — всё равно будут ситуации, когда предсказать результаты по запросу пользователя практически невозможно. Это связано со способами распознавания запроса, его обработкой и итоговой интерпретацией. Но как бы сложно это ни было, у процесса поиска — что в поисковой системе, что на сайте или в приложении — всегда один алгоритм:

1. Запрос
С него начинается любой поиск. Это может быть голосовой или текстовый ввод, а ещё — скриншот или фотография со смартфона, если доступен визуальный поиск. И на этом этапе вероятность ошибки особенно велика. Пользователь может напечатать неверное слово или набрать его с ошибкой, запись голоса может быть нечеткой — и результаты в итоге будут некорректны.

2. Интерпретация запроса
Запросы становятся более разговорными и сложными по своей природе, поскольку поисковые системы вроде Гугла сильно разбаловали пользователей: те уже привыкли, что даже на самый косноязычный запрос в интернете легко найти нужное.

Чтобы поисковая система понимала запросы правильно, нужен этап интерпретации (будь это поиск в интернете, в интернет-магазине или мобильном приложении какого-то бренда). Для этого есть алгоритмы, которые сначала анализируют полученный запрос по нескольким контрольным параметрам: орфография, грамматика, история успешных поисков, качество и объем результатов и т. д. Исходя из этого, система генерирует набор возможных запросов, которые потенциально мог бы искать пользователь — назовем их конкурирующими.

Если исходный запрос изначально проходит по упомянутым параметрам, система считает его наиболее подходящим для поиска. Если же запрос пользователя был «не очень», то она сравнивает конкурирующие запросы по тем же параметрам и присваивает каждому из них оценку. Побеждает тот конкурирующий запрос, у которого оценка больше.

Сложность процесса интерпретации запроса в том, что иногда запрос шире информации, которая есть в системе. Например, если вы ищете конкретный фильм на платформе с платной подпиской, а его там нет, система поиска должна показать какие-то схожие по жанру и тематике результаты. А для этого она должна быть в курсе вообще всех созданных когда-либо фильмов, чтобы предлагать какие-то похожие по нужным параметрам из своей базы данных.

3. Поиск соответствия запросу
На этом этапе у нас уже есть победивший запрос — дальше система должна найти все совпадения из репозитория (хранилища данных), ему соответствующие. А вариантов развития событий здесь миллион: система может вообще не найти совпадений, а может — найти целую тонну, да ещё и в нескольких категориях (зависит от обширности и детализации хранилища). И чтобы как-то в них разобраться, нам нужен следующий шаг.

4. Ранжирование
Ура, у нас уже есть обработанный запрос и пачка совпадений из хранилища — время ранжировать! Ведь некоторые найденные в хранилище совпадения могут подходить под запрос на 5%, а некоторые — на 98% или даже 100%. Чтобы это понять, система будет оценивать релевантность запросу. Но иногда одной релевантности бывает недостаточно — важно также и качество самих результатов.

Есть прецедент с запросом «а был ли холокост?». Надежные и достоверные сайты точь-в-точь таким вопросом не задавались, а просто рассказывали об этих событиях с позиции, что читатель и так знает, что холокост был. Поэтому были нерелевантны запросу. А вот сайты с кричащими жёлтыми заголовками вроде «Холокоста не было, это всё — величайшая мистификация» с точностью отвечали на запрос. И получалось вопиющее несоответствие действительности.

5. Показ результатов (ну наконец-то)
Разные типы запросов — разный ответ поисковой системы. Учитесь у Гугла и других интернет-гигантов: ищешь фильм — покажет карточку с рейтингом и список актеров, ищешь болячку — покажет короткую карточку с симптомами и причинами. Ну, вы поняли :)

Когда вы ищете фильм на субботний вечер под пледиком и химчистку недалеко от вашего дома — это немножко разные сценарии.

Первый — «я просто посмотреть»: не знаете, что конкретно ищете, или даже вообще не ищете, а просто листаете сайт в поисках интересного. Например:

• пялитесь на свадебные платья в Pinterest, хотя вам никто не делал предложение;
  
• рыскаете в разделе обуви в разделе «распродажа» — вроде бы, ничего не надо, «но вдруг»;
  
• пролистываете заголовки новостей — может, что-то заинтересует;
  
• скроллите Instagram, чтобы узнать, что новенького у друзей, брендов и медийных личностей;
  
• просматриваете места для отдыха в Таиланде — пока без дат и конкретных намерений, чтобы просто прикинуть цену.

Такое поведение куда более распространено, чем прицельный поиск. К нему пользователь обращается в конкретной ситуации, например:

• подбирает стоматолога в своём районе;
  
• срочно ищет новую пару кроссовок, потому что старые порвались;
  
• хочет пройти курс по садоводству;
  
• выбирает гостиницу или апартаменты так, чтобы было недалеко идти пешком до достопримечательностей, а ещё рядом были хорошие кафе.

В процессе поиска люди ожидают на страницах вполне определённых вещей — и в зависимости от сценария, разных. Например, в режиме «я просто просмотреть» им важно:

• использовать панель поиска с любой страницы сайта или приложения;
  
• видеть какой-то рандомный запрос в строке (особенно тем, кто вообще не определился, что ищет);
  
• получать чёткие результаты, несмотря на ошибки и неточности в запросах;
  
• видеть схожие результаты с теми, что соответствуют их запросу;
  
• разглядывать изображения и читать описания — акцент на визуальной части;
  
• добавлять в закладки, сохранять в избранное.

При прицельном поиске всё вышеперечисленное тоже важно, но также становится важной чёткость навигации по каталогу (хлебные крошки, подсказки, категории). А ещё пользователь хочет иметь возможность сравнивать результаты выдачи по разным характеристикам. Если это статьи, то по дате и количеству просмотров, если товары — то по рейтингу и отзывам, конкретным параметрам.

Итак, чтобы юзеры точно находили на вашем сайте или в приложении нужное, поисковая система должна уметь:

• искать по простым словам, фразам или нескольким формам слова,
  
• предлагать автозаполнение,
  
• искать по синонимам,
  
• искать по атрибутам товара (например, именно красные футболки, а не все подряд);
  
• распознавать запросы с ошибками,
  
• фильтровать и сортировать результаты поиска,
  
• хранить историю поиска,
  
• предлагать подобные варианты по запросу.

Написать поисковый движок с нуля — очень авантюрная затея, поэтому большинство бизнесов пользуются готовыми. Их, вроде бы, много, но обычно дело сводится либо к Elasticsearch, либо к Sphinx (да, есть ещё Solr, Algolia, Xapian, но они не так распространены).

Понятно, что ещё простенькие поисковые движки, встроенные в CMS, но мы уже как-то писали, что у них достаточно ограничений (например, они могут не уметь исправлять ашипки) и маловато преимуществ на проектах, где поиск жизненно важен.

В его основе — библиотека Apache Lucene (пакет поисковой системы с открытым исходным кодом, реализованный на JAVA) и ему доверяют поиск на своих сайтах TripAdvisor, Mozilla, Github, eBay и Netflix.

Что он умеет:

• шустро индексировать новые данные (как только данные добавляются, они сразу попадают в очередь на индексацию — в других случаях индексация происходит в часы с наименьшей нагрузкой на сайте) — актуально для постоянно меняющихся баз данных;
  
  
• легко масштабироваться под увеличение базы данных (скорость поиска при увеличении базы не слишком страдает);
  
  
• хранить данные, а не только искать по ним (нам эта способность Elasticsearch очень пригодилась на одном из проектов);
  
  
• при грамотной настройке — выдавать аналитику по данным: количество посетителей, самые популярные запросы, самые запрашиваемые страницы, устройства и браузеры пользователей, трафик по времени суток и прочее;
  
  
• работать с разными типами данных: текст, даты, геометки, структурированные и неструктурированные данные;
  
  
• легко справляться с неправильными или ошибочными запросами благодаря встроенным анализаторам текста;
  
  
• при грамотной настройке — искать по синонимам (их приходится вбивать вручную: либо загружать общую базу синонимов, либо для каждого товара/документа указывать список синонимов).

А ещё этот движок отказоустойчивый: несколько копий Elasticsearch при желании объединяются в кластер, а несколько кластеров могут хранить реплицированные (синхронные) копии данных.


Проблемы Elasticsearch
За что Elasticsearch недолюбливают — он требует вдумчивой настройки.
По умолчанию при старте работы с Elasticsearch в комплекте с ним идут все возможные элементы, но не все из них обязательно пригодятся в конкретной ситуации. Это раз.

Два — Elasticsearch, вроде бы, предоставляет набор встроенных анализаторов для функции поиска, но есть риск, что под вашу задачу придётся написать свой собственный.

Настройка остальных составляющих поискового движка, помимо анализаторов, — штука часто индивидуальная и зависит от конкретной задачи. А значит, требует ресурса. Если на проекте потребуется машинное обучение (например, для визуального поиска в довесок к текстовому), бесплатной версией ElasticSearch уже не обойтись — придётся платить за пакет Platinum $ 22 ежемесячно.

Ещё одна ложечка дёгтя: у ElasticSearch нет встроенного функционала для проверки орфографии (вот это вот гугловское «Возможно, вы имели ввиду…»), и если он необходим на проекте — придётся как-то выкручиваться.

Если будете разворачивать поиск на собственном локальном сервере, готовьтесь к расходам: минимум оперативной памяти — от 2Гб, но лучше — побольше (от 4Гб и выше в зависимости от объёма информации, по которой придётся искать). Как вариант, можно использовать облачную платформу. А ещё помните о том, что у Elastic нет встроенной системы авторизации и ограничения прав доступа. Из-за этого иногда могут случаться утечки данных — поэтому будьте внимательны с паролями и доступами.

И последнее. Настроить поисковый движок — это только полдела. Дополнительно придётся подготовить наиболее подходящие поисковые запросы, а это отдельная история. Но если всё сделать правильно, вы получите шикарный быстрый поиск на сайте, которым пользуются многие компании в интернетах.

Когда-то мы уже писали о нём и рассказывали на пальцах примере аптечных препаратов принцип работы. Поэтому здесь — кратенько сравним его с Elasticsearch по ключевым параметрам:

Понимание того, как пользователи ищут на сайтах и интернетах — пока ещё штука не слишком изведанная (и вряд ли это скоро как-то изменится). Практически как Мировой океан, про который не знают на 95%. Но то, что мы уже знаем, говорит — поисковые системы всё больше подстраиваются под запросы пользователей, а пользователи всё большего ожидают от поиска на сайтах и в приложениях. Чтобы вот прям с полуслова — и не в бровь, а в глаз. Так что, если поиск в вашем интернет-проекте оставляет желать лучшего, пора призадуматься и актуализировать его с помощью мощного поискового движка — а то так и на обочине жизни остаться недолго (шутим-шутим).

Тыкать тесты в интернетах любят, кажется, все, поэтому— велкам!