Algolia что это

Algolia: внутренний поиск в реальном времени как услуга

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

Не нужно разрабатывать свои собственные — Algolia — это полностью размещенная поисковая служба, доступная как REST API. API (Программный интерфейс приложения) клиенты доступны для всех основных фреймворков, платформ и языков и передачи данных между клиентами и API (Программный интерфейс приложения) находится в формате JSON.

Особенности Algolia

• Высокопроизводительный — время отклика до 200 раз быстрее, чем у Elasticsearch, и до 20,000 4 раз быстрее, чем у SQLite FTSXNUMX. Индексирование является асинхронным, поэтому пользователи могут искать новые данные через несколько секунд после обновления. Они также выставляют API (Программный интерфейс приложения) для проверки статуса индексации.
• Nginx — Реализация на стороне сервера Algolia полностью написана на C ++ и встроена в виде модуля внутри высокопроизводительного HTTP-сервера Nginx.
• Аккаунт — Единый графический интерфейс для всех операций, включая использование, производительность, настройки, API (Программный интерфейс приложения) журналы, API (Программный интерфейс приложения) ключи и просмотр данных.
• поиск в базе данных — предназначен для поиска записей, а не страниц
  Идеальное решение для баз данных SQL и NoSQL с прозрачным алгоритмом ранжирования, оптимизированным для полуструктурированных данных.
• Мульти-атрибуты — принимает типы объектов и любое количество атрибутов для поиска.
• Искать по мере ввода — помимо простого автозаполнения, пользователи получают обновленные результаты поиска с каждой вводимой буквой.
• Актуальность — полностью настраиваемый и прозрачный рейтинг. Algolia предоставляет самый простой способ отсортировать результаты по популярности, сохраняя при этом актуальность.
• Мобильный телефон — разработан для мобильных… быстро, прощает опечатки и сортирует результаты по географическому расстоянию.
• Языкознание — Поиск на любом письменном языке. Например, поиск с использованием упрощенного китайского языка может найти совпадения на традиционном китайском языке.
• Исправление опечаток – Algolia понимает опечатки даже в первых буквах, поэтому пользователи все равно могут найти то, что ищут.
• Умное выделение — Выделите, какой раздел соответствует запросу пользователя, даже если раздел состоит только из первых нескольких букв слова и содержит опечатки.
• Обработка в реальном времени — единственная поисковая система, предлагающая фасеты по мере ввода, поэтому пользователи получают результаты фасетирования после первого нажатия клавиши.
• Геопоиск — отображать попадания по расстоянию, либо только те, что рядом, либо в определенной местности. Совместите с текстовыми запросами и любыми другими функциями поиска.
• Высокая доступность — 99.99% SLA (соглашение об уровне обслуживания). Все записи данных автоматически индексируются на трех различных высокопроизводительных серверах.
• Мультицентры обработки данных — сокращайте время отклика, выбирая центр обработки данных, ближайший к вашим пользователям.
• Первоклассная безопасность – API (Программный интерфейс приложения) ключи ограничивают доступ к определенному индексу и устанавливают ограничения, такие как максимальная скорость запросов для IP-адреса или время истечения срока действия ключа.

Algolia Дата обновления — 16 ноября 2021

Algolia — это enterprise-level платформа, предназначенная для настройки и персонализации внутреннего поиска и навигации веб-сайтов и мобильных приложений. Algolia является лидирующим мировым решением среди поисковых систем (по версии G2 Grid). С помощью Algolia стало возможным гибко управлять контентом на вашей площадке, совершать персонализированный поиск не только по товарам, но и по любым типам данных: статьи и обзоры, медиа-контент, файлы, поиск вакансий и идр. Stellar Labs — консалтинговая IT-компания, представитель Algolia в РФ и СНГ.
Будем рады провести для вас demo платформы Algolia. Пишите: hello@stellarlabs.ai

Ключевые клиенты

Среди клиентов Algolia (10 000+: eCommerce, Media&Gaming, Banking, Services идр):
ASOS, TWITCH, Beeline, Slack, LVMH, Decathlon, LINIO, STRIPE, Lacoste, Under Armour, l’Occitane, QuickSilver, Staples, National Geographic, Discovery, Orange Telecom, Coursera, SalesForce, Societe Generale Bank, Harvard University, weWork и многие другие.

Что должен знать о поиске каждый разработчик

Хотите внедрить или доработать функцию поиска? Вам сюда.

Спросите разработчика: «Как бы вы реализовали функцию поиска в своем продукте?» или «Как создать поисковую систему?». Вероятно, в ответ вы услышите что-нибудь такое: «Ну, мы просто запустим кластер Elasticsearch: с поиском сегодня всё просто».

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

Есть множество программных пакетов с открытым исходным кодом, проведено немало исследований, однако лишь немногие избранные понимают, как нужно делать функциональный поиск. Как ни забавно, но если поискать в Интернете связанную с реализацией поиска информацию, вы не найдете актуальных и содержательных обзоров.

Цель статьи

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

Основываясь на опыте работы с универсальными решениями и узкоспециализированными проектами самого разного масштаба (в компаниях Google, Airbnb и нескольких стартапах), я расскажу о некоторых популярных подходах, алгоритмах, методах и инструментах.

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

Переведено в Alconost

Если вам не терпится перейти к практике или вы многое по этой теме уже знаете, возможно, стоит сразу перескочить в раздел инструментов и сервисов.

Немного общих размышлений

Статья длинная. Однако большая часть материала в ней опирается на четыре основных принципа:

Поиск — очень неоднородная задача:

• Запросы бывают самые разные, а задача поиска сильно зависит от потребностей продукта.
• В сети Facebook — это поиск по графу людей.
• На сервисе YouTube — поиск отдельных видео.
• Оба эти случая сильно отличаются от поиска на сервисе Kayak: планирование авиаперелетов — очень трудоемкая задача.
• Далее — Карты Google, для которых важно «понимать» геопространственные данные.
• Pinterest — здесь можно найти фото завтрака, который вы в один прекрасный день все-таки приготовите.

Большое значение имеют качество, показатели и организация работы:

• Здесь нет никаких чудесных средств (как тот же PageRank), нет и волшебной формулы ранжирования, которая сделает все красиво. Обработка запросов — это постоянно меняющийся набор методов и процессов, которые занимаются различными аспектами задачи и улучшают работу системы — как правило, постепенно и непрерывно.
• ️ Иными словами, поиск — это не просто создание ПО, которое занимается ранжированием или выборкой (это обсудим ниже) по определенному набору данных. Обычно поисковые системы — это постоянно развивающийся конвейер налаженных компонентов, которые с течением времени меняются, а вместе составляют связанную систему.
• Так, в частности, ключ к созданию успешного поиска — это встраивание процессов оценки и подстройки в сам продукт и в цикл разработки. Архитектор поисковой системы должен думать о процессах и показателях, а не только о технологиях.

В первую очередь — существующие технологии:

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

️ Подробно ознакомьтесь с тем, что покупаете:

• Даже если вы используете существующее ПО с открытым кодом или коммерческое решение, у вас должно быть некоторое представление о сложности задачи поиска и о том, где могут быть подводные камни.

Теория. Задача поиска

У каждого продукта — свой поиск. Выбор решения зависит от множества технических характеристик и требований. Полезно определить ключевые параметры конкретной задачи поиска:

1. Размер: насколько большим будет корпус данных (полный набор документов, по которому нужно искать)? Тысячи, миллионы, миллиарды документов?
2. Носитель информации: поиск будет по тексту, изображениями, связям на графах или геопространственным данным?
3. Контроль и качество корпуса данных: находятся ли источники документов под вашим контролем — или вы получаете их от третьего лица (вероятного конкурента)? Документы полностью готовы к индексированию или их нужно подчистить и отобрать?
4. Скорость индексирования: индексирование нужно в реальном времени или хватит построения индексов в пакетном режиме?
5. Язык запросов: запросы будут структурированные — или нужно понимать и неструктурированные?
6. Структура запросов: запросы будет текстовые, в форме изображений, звуков? Может, это почтовые адреса, идентификационные записи, лица людей?
7. Учет контекста: зависят ли результаты поиска от того, кем является пользователь, какая у него история работы с продуктом, где он находится, какое у него сейчас время суток и т. д.?
8. Подсказки: нужна ли поддержка неполных запросов?
9. Задержка: какие требования к задержкам в работе сервиса? 100 миллисекунд или 100 секунд?
10. Контроль доступа: сервис полностью открытый — или пользователи должны видеть ограниченное подмножество документов?
11. Соблюдение нормативов: есть ли ограничения со стороны законодательства или организации?
12. Интернационализация: нужна ли поддержка документов с многоязычными кодировками или «Юникодом»? (Подсказка: всегда используйте UTF-8, а если не используете, вы должны точно знать, что и зачем делаете.) Понадобится ли поддерживать многоязычный корпус? А многоязычные запросы?

Конвейер индексации в работе.

Теория. Поисковый конвейер

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

Это приводит нас к важному свойству всей экосистемы: изменив работу какой-либо подсистемы, нужно оценить, как это повлияет на следующие за ней подсистемы, и, возможно, изменить их поведение тоже.

Рассмотрим самые важные практические задачи, которые придется решать.

Выбор индекса

Берем набор документов (например, весь Интернет, все сообщения сети Twitter или фото на сервисе Instagram), выбираем потенциально меньшее подмножество документов, которые есть смысл рассматривать как результаты поиска и включаем в индекс только их, отбрасывая остальные. Это почти не зависит от выбора документов для показа пользователю и нужно для того, чтобы индекс был компактным. Не подойти для индекса могут, например, следующие классы документов.

Спам

Поисковый спам самых разных форм и размеров — это объемная тема, которая сама по себе достойна отдельного руководства. Здесь — хороший обзор таксономии интернет-спама.

Нежелательные документы

При некоторых ограничениях области поиска может потребоваться фильтрация: придется отбросить порнографию, незаконные материалы и т. д. Соответствующие методы похожи на фильтрацию спама, но могут включать в себя и специальные эвристические алгоритмы.

Копии

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

Малополезные документы

Определение полезности зависит от области работы поиска, поэтому порекомендовать конкретные подходы трудно. Пригодиться могут следующие соображения. Вероятно, для документов можно будет построить функцию полезности. Можно попробовать эвристику; или, например, изображение, содержащее только черные пиксели — как образец бесполезного документа. Полезность можно оценить, опираясь на поведение пользователя.

Построение индекса

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

• Индекс — это сопоставление поисковых терминов документам. Поисковым термином может быть слово, характеристика изображения или любое иное производное документа, пригодное для сопоставления запросов и документов. Список документов для данного термина называется предметным указателем (posting list). Его можно сортировать по показателям, например, по качеству документа.
• Выясните, нужно ли индексировать данные в реальном времени. ️ Многие компании с объемными корпусами документов, используя пакетный подход к индексированию, впоследствии приходят к тому, что этот подход не отвечает потребностям продукта: пользователи ожидают, что результаты поиска будут актуальными.
• В текстовых документах при извлечении терминов обычно используются методы обработки естественного языка (NLP), такие как список стоп-слов, выделение основы слов, а также извлечение объектов; для изображений и видео используются методы компьютерного зрения и т. д.
• Кроме того, с документов собираются метаданные и статистическая информация, например, ссылки на другие документы (что используется в известном ранжирующем сигнале PageRank), темы, количество вхождений термина, размер документа, упомянутые сущности и т. д. Эта информация может быть позже использована в построении ранжирующего сигнала или для кластеризации документов. В более крупных системах может быть несколько индексов, например, для документов разных типов.
• Форматы индексов. Фактическая структура и компоновка индекса — сложная тема, поскольку индекс можно оптимизировать по-разному. Например, есть методы сжатия предметных указателей, можно использовать отображение данных через mmap() или LSM-дерево для постоянно обновляемого индекса.

Анализ запросов и выборка документов

Самые популярные поисковые системы принимают неструктурированные запросы. Это означает, что система должна извлечь структуру из самого запроса. В случае обращенного индекса извлекать поисковые термины нужно с помощью методов NLP.

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

• Повторная весовая обработка терминов.
• Проверка орфографии. В качестве словарей очень удобно использовать хронологические журналы запросов.
• Поисксинонимов.
• Распознавание именованных объектов. Хорошая идея — использовать языковое моделирование на основе скрытой марковской модели (HMM).
• Классификация запросов: распределение запросов по определенным типам. Например, гугловский поиск умеет определять запросы, которые содержат географический объект, запросы порно, а также запросы чего-нибудь из новостей. Затем алгоритм выборки может принимать решение о том, какие корпусы или индексы следует просмотреть.
• Расширение посредством персонализации или локального контекста. Хорошая штука для запросов вроде «заправки около меня».

Ранжирование

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

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

Чтобы жизнь медом не казалась, многие подобные сигналы, например, PageRank и сформированные статистическими языковыми моделями сигналы, содержат параметры, которые значительно влияют на работу сигнала. И они тоже требуют ручной подстройки.

В последнее время все более популярным становится обучение ранжированию — основанные на сигналах дифференциальные подходы с учителем. Среди популярных LtR в качестве примера можно привести McRank и LambdaRank от Microsoft, а также Матрикснет от «Яндекса».

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

В таком случае при выборке нужно просто найти несколько документов, которые по некоторому показателю находятся ближе всего к вектору запроса (например, по евклидову расстоянию). Это расстояние и будет рангом. Если хорошо построить отображение и документов, и запросов, то документы будут выбираться не по наличию какого-либо простого шаблона (например, слова), а по тому, насколько близки документы к запросу по смыслу.

Управление конвейером индексации

Обычно, чтобы сохранять актуальность поискового индекса и функции поиска, все рассмотренные части конвейера должны быть под постоянным контролем.

Управление поисковым конвейером может оказаться сложной задачей, поскольку вся система состоит из множества подвижных частей. Ведь конвейер — это не только перемещение данных: с течением времени меняются также код модулей, форматы и допущения, включенные в данные.

Конвейер можно запускать в «пакетном» режиме, на регулярной, нерегулярной основе (если не нужно индексировать в реальном времени), в потоковом режиме (если без индексирования в реальном времени не обойтись) или по определенным триггерам.

Некоторые сложные поисковые системы (например, Google) используют конвейеры в несколько уровней — на разных временных масштабах: например, часто изменяющаяся страница (тот же cnn.com) индексируется чаще, чем статическая страница, которая не менялась годами.

Обслуживающие системы

Конечная цель поисковой системы — принимать запросы и посредством индекса возвращать соответствующим образом ранжированные результаты. Вопрос обслуживающих систем может быть очень сложным и включать в себя множество технических подробностей, но я все-таки упомяну несколько ключевых аспектов этой части поисковых систем.

• Скорость работы. Пользователи замечают задержки в системе, с которой они работают. ️ Компания Google провела обширное исследование и выяснила, что если задержка ответа увеличивается на 300 мс (100 → 400 мс), то количество поисковых запросов падает на 0,6%. Они рекомендуют добиться того, чтобы на большинстве запросов задержка была не более 200 мс. Есть хорошая статья по этой теме. А теперь сложная часть: система может собирать документы со многих компьютеров, объединять их в список, который может оказаться очень длинным, а затем сортировать его в порядке ранжирования. И если вам это кажется недостаточно сложным, то учтите, что ранжирование может зависеть от запросов, поэтому при сортировке система не просто сравнивает два числа, а выполняет более сложные вычисления.
• Кэширование результатов. Если нужно добиться хорошей производительности, часто без этого никак. ️ Но и с кэшем все не так-то просто. Индекс уже обновился, какие-то результаты попали в черный список — а кэш при этом может показать устаревшую выдачу. Очистка кэша — тоже та еще головоломка: система поиска, вполне вероятно, не сможет справиться со всем потоком запросов, имея пустой («холодный») кэш, поэтому прежде чем получать запросы, кэш нужно подготовить — «разогреть». В общем, кэш усложняет функциональный разрез системы, а выбор его размера и алгоритма замещения — сложная задача.
• Уровень работоспособности. Часто определяется как соотношение «время работы / (время работы + время простоя)». Если индекс находится в распределенном состоянии, то для выдачи результатов поиска системе обычно приходится запрашивать у каждого сегмента его часть общего результата. ️ А это значит, что если один сегмент недоступен, то не работает вся система. Чем больше машин задействовано в обслуживании индекса, тем выше вероятность того, что одна из них перестанет работать и остановит всю систему.
• Управление несколькими индексами. Индексы больших систем могут разделяться просто на куски (сегменты), а также по типу носителя и ритму индексации (актуальные и долгосрочные индексы). Результаты их выдачи могут объединяться.
• Слияние результатов данных разного типа. Например, Google показывает результаты из карт, новостей и т. д.

Оценка человеком. Да, такая работа в поисковых системах все еще нужна.

Качество, оценка и доработка

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

Далее нужно будет создать набор процессов непрерывной оценки и повышения качества поиска. Это на самом деле и есть основная часть работы — и самая сложная задача, которую придется решать.

Что такое качество? Во-первых, нужно определить (и заставить своего начальника или руководителя проекта согласиться), что значит «качество» в конкретном случае:

• Удовлетворенность пользователей, о которой они сообщают самостоятельно (пользовательский интерфейс учитывается).
• Субъективная релевантность возвращаемых результатов (пользовательский интерфейс не учитывается).
• Удовлетворенность по сравнению с предложениями конкурентов.
• Удовлетворенность по сравнению с работой предыдущей версии поиска (например, на прошлой неделе).
• Приверженность пользователей.

Непрерывный расчет такого показателя для своей системы (а также для конкурентов) позволяет отследить прогресс и показать начальнику, насколько хорошо вы делаете свою работу. Вот несколько классических методов количественной оценки качества, которые помогут построить собственную волшебную формулу оценки качества:

• Показатели точности и полноты измеряют, насколько хорошо полученный набор документов соответствует ожидаемому набору.
• Хорошо отражает точность и полноту F-мера (а именно F₁), которая представляет собой одно число.
• Средняя точность (MAP) позволяет количественно оценить актуальность первых результатов в выдаче.
• Приведенная суммарная эффективность релевантности (nDCG) похожа на MAP, но взвешивает релевантность результата по его порядковому номеру.
• «Длинные» и «короткие» клики позволяют количественно оценить, насколько полезны результаты реальным пользователям.
• Здесь — хороший подробный обзор показателей.

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

Обычно на первых порах разработчики сами вручную оценивают результаты. Чуть позже привлекаются оценщики, которые для просмотра возвращаемых результатов поиска и отправки своей оценки качества обычно используют специальные инструменты.

Разработчик может использовать полученные таким образом сигналы, чтобы скорректировать курс разработки, принять решение о запуске и даже передать эти данные на этап выбора индекса и в системы выборки и ранжирования.

Вот несколько иных видов «человеческой» оценки, которые могут выполняться в поисковой системе:

• Основная пользовательская оценка: пользователь оценивает общую удовлетворенность от использования.
• Сравнительная оценка: сравнение с другими результатами поиска (которые получены от предыдущих версий системы или от конкурентов).
• Оценка выборки: качество выборки и результат анализа запроса часто оцениваются с помощью собранных вручную наборов «запрос — документ». Пользователю показывается запрос и список выбранных по нему документов, в котором можно отметить документы, имеющие отношение к запросу и не относящиеся к нему. Полученные пары (запрос + соответствующие документы) называются «тестовой выборкой» и представляют собой в высшей степени полезные данные. Например, с их помощью разработчик может настроить автоматические регрессионные тесты функции выборки. Получаемый в результате сигнал выбора также можно вернуть в виде контрольных данных на повторную весовую обработку терминов и в другие модели перезаписи.
• Оценка ранжирования: оценщикам дается запрос и два документа, из которых нужно выбрать тот, что лучше соответствует запросу. Таким образом можно частично упорядочить документы по данному запросу. И такой порядок позже можно сравнить с выдачей системы ранжирования. Обычно показатели качества ранжирования — это MAP и nDCG.

Оценочные наборы данных

Об оценочных наборах данных, таких как упомянутые выше тестовые выборки, следует начинать думать на ранних этапах проектирования поиска. Как их собирать и обновлять? Как внедрять в рабочий конвейер оценки? Насколько они репрезентативны?

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

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

Сколько понадобится времени, чтобы внести изменения и дождаться результатов: дни, часы, минуты или секунды? ️ Кроме прочего, процедура запуска оценки должна быть максимально простой и не должна отнимать слишком много времени.

Как все это сделать НА ПРАКТИКЕ?

Эта статья не задумывалась как руководство. Тем не менее, я кратко опишу, как я сам подошел бы к разработке функции поиска сегодня:

1. Как уже говорилось, если можете себе позволить — просто купите один из предлагаемых на рынке SaaS (ниже — пару хороших вариантов). Но есть несколько условий:

• У вас «подключенная» система (сервис или приложение подключены к Интернету).
• Выбранное решение должно поддерживать необходимую функциональность «из коробки». Эта статья дает неплохое представление о том, какие функции могут понадобиться. К примеру, я бы подумал о следующих требованиях: поддержка носителей, по которым вы будете искать; поддержка индексирования в режиме реального времени; универсальность обрабатываемых запросов, в том числе учет контекста.
• У вас должно хватить бюджета на оплату обслуживания в течение следующих 12 месяцев — с учетом размера корпуса и ожидаемого числа запросов в секунду.
• Сервис должен выдерживать ожидаемый трафик в пределах требований к задержкам. Если поисковые запросы будут идти из приложения, убедитесь, что там, где находятся ваши пользователи, доступ к сервису достаточно быстрый.

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

Инструментов много не бывает.

SaaS

Algolia — проприетарный SaaS, который индексирует веб-сайт клиента и дает API для поиска по его страницам. У них есть API для отправки документов клиента, поддержка контекстно-зависимых запросов, да и работает их система очень быстро. Если внедрять сегодня веб-поиск, сначала я бы использовал Algolia (если это по карману) — так можно было бы выиграть время на создание собственного аналогичного поиска.

• Различные провайдеры Elasticsearch: AWS (️Elasticsearch Cloud), ️elastic.co и решение от компании ️ Qbox.
• ️Поиск Azure — решение от Microsoft. Доступ через REST API, может масштабироваться и обрабатывать миллиарды документов. Есть интерфейс запросов Lucene, который упрощает переход с решений на основе соответствующей библиотеки (см. ниже).
• ️Swiftype— корпоративный SaaS, который индексирует внутренние сервисы компании, такие как Salesforce, G Suite, Dropbox и сайт интрасети.

Инструменты и библиотеки

Lucene — самая популярная библиотека информационного поиска. Умеет анализировать запросы, делать ранжирование и выборку по индексу. Любой из компонентов можно заменить на альтернативную реализацию. Есть также порт на C — Lucy.

• Solr— полноценный поисковый сервер на основе библиотек Lucene. Входит в экосистему инструментов Hadoop.
• Hadoop — наиболее широко используемая система MapReduce с открытым кодом, первоначально разработанная как инфраструктура конвейера индексации для сервера Solr. Постепенно сдает свои позиции фреймворку пакетной обработки данных Spark, который используется для индексирования. ️EMR — проприетарная реализация MapReduce на платформе AWS.
• Elasticsearch— также работает на библиотеках Lucene (здесь можно сравнить Elasticsearch и Solr). В последнее время этому решению уделяется все больше внимания, поэтому когда речь заходит о поиске, на ум сразу же приходит ES, и не без причины: у сервиса хорошая поддержка, функциональный API, его можно интегрировать в Hadoop, он хорошо масштабируется. Есть версия с открытым кодом и версия Enterprise. ES можно использовать как SaaS: он умеет масштабироваться на миллиарды документов, однако реализовать такое масштабирование может быть очень сложно, поэтому обычно используется ряд корпусов меньшего размера.
• Xapian — библиотека информационного поиска на C++: относительно компактная, хороша для встраивания в классические и мобильные приложения.
• Sphinx — сервер полнотекстового поиска. Использует SQL-подобный язык запросов. Может работать как подсистема хранилища для MySQL или применяться как библиотека.
• Nutch — модуль веб-поиска. Может применяться в связке с сервером Solr. Используется в проекте Common Crawl.
• Lunr — компактная встраиваемая поисковая библиотека для веб-приложений на стороне клиента.
• SearchKit— библиотека компонентов веб-интерфейса для использования вместе с сервисом Elasticsearch.
• Norch— поисковая библиотека для Node.js на основе LevelDB.
• Whoosh— быстрая полнофункциональная поисковая библиотека, использует чистый Python.
• У проекта OpenStreetMap есть собственный набор поискового ПО.

Наборы данных

Несколько интересных и полезных наборов данных, которые помогут построить поисковую систему или оценить ее качество:

• Common Crawl — регулярно обновляемые открытые данные сканирования Интернета. На сервисе AWS есть зеркало — бесплатное в рамках самого сервиса.
• Дамп данных OpenStreetMap — очень полезный источник данных, если нужно построить систему геопространственного поиска.
• N-граммы Google Книг — могут пригодиться при создании языковых моделей.
• Дампы «Википедии»— образцовый источник, на котором можно построить, среди прочего, и граф объектов. Есть и множество соответствующих вспомогательных инструментов.
• Дампы IMDb — любопытный набор данных для построения небольшой поисковой системы для экспериментов.

Литература

• Modern Information Retrieval («Современный информационный поиск»), авторы R. Baeza-Yates и B. Ribeiro-Neto — хорошее, основательное учебное пособие по теме и отличный обзор для новичков.
• Information Retrieval («Информационный поиск»), авторы S. Büttcher, C. Clarke и G. Cormack — еще один учебник с широким охватом, но чуть более актуальный. Охватывает обучение ранжированию и неплохо излагает теорию оценки поисковых систем. Может также послужить хорошим обзором.
• Learning to Rank («Обучение ранжированию»), автор Tie-Yan Liu — лучшее теоретическое рассмотрение LtR. Практики не очень много. Если кто-то хочет построить LtR-систему — стоит ознакомиться.
• Managing Gigabytes («Управление гигабайтами») — книга опубликована в 1999 г., но по-прежнему остается исчерпывающим источником для тех, кто приступает к созданию эффективного индекса значительных размеров.
• Text Retrieval and Search Engines («Поиск текста и поисковые системы») — массовый открытый онлайн-курс на платформе Coursera. Достойный внимания обзор основных тем.
• Indexing the World Wide Web: The Journey So Far («Индексирование Интернета: где мы сейчас», здесь — в формате PDF) — обзор веб-поиска по состоянию на 2012 г., авторы Ankit Jain и Abhishek Das из компании Google.
• Why Writing Your Own Search Engine is Hard («Почему написать собственную поисковую систему — сложно?») — классическая статья 2004 г., автор Анна Паттерсон.
• https://github.com/harpribot/awesome-information-retrieval — список связанных с поисковыми системами ресурсов, который ведет Harshal Priyadarshi.
• Отличный блог о всяком разном в информационном поиске, автор — Daniel Tunkelang.
• Пару десятков хороших слайдов об оценке поисковой системы.

О переводчике

Перевод статьи выполнен в Alconost.

Alconost занимается локализацией игр, приложений и сайтов на 68 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.

Мы также делаем рекламные и обучающие видеоролики — для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.

• Alconost
• поиск
• поисковая система
• разработка
• информационный поиск
• Elasticsearch
• функция поиска
• индексирование
• запросы
• индекс
• ранжирование поиска
• семантический поиск

• Блог компании Alconost
• Поисковые технологии
• Алгоритмы
• Big Data
• Машинное обучение

Facebook

Algolia is a hosted search platform with unique differentiators for all important aspects of search.

*User Experience: Algolia is designed from the ground up to maximize the speed of search and solve the pain of relevance tuning. Accessing the right piece of content on websites and apps has never been faster or more intuitive.

*Developer Experience: Algolia is an API-centric company with comprehensive documentation and support provided by software engineers. We love to work with developers to push the search experience beyond its traditional limits.

*Infrastructure: With 36 data centers in 15 regions, Algolia serves billions of queries weekly in under 50 ms for more than 1300 customers, including many Fortune 500 companies. Algolia is highly scalable and reliable, with a 99.99% SLA and both server and provider redundancy.