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

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

Спросите разработчика: «Как бы вы реализовали функцию поиска в своем продукте?» или «Как создать поисковую систему?». Вероятно, в ответ вы услышите что-нибудь такое: «Ну, мы просто запустим кластер 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 месяцев — с учетом размера корпуса и ожидаемого числа запросов в секунду.
  
• Сервис должен выдерживать ожидаемый трафик в пределах требований к задержкам. Если поисковые запросы будут идти из приложения, убедитесь, что там, где находятся ваши пользователи, доступ к сервису достаточно быстрый.
  

2. Если размещение на сервере не отвечает требованиям проекта или на это нет средств, возможный выбор в этом случае — библиотека или инструмент с открытым кодом. На данный момент для «подключенных» приложений и веб-сайтов я бы выбрал Elasticsearch. Для встроенных систем некоторые инструменты перечислены ниже.

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.

Подробнее: https://alconost.com