Поисковик для программистов: Поисковик для программистов – Google вычисляет программистов, которые вводят специфические поисковые запросы / Habr

Содержание

Google вычисляет программистов, которые вводят специфические поисковые запросы / Habr

Как лучшая поисковая система в мире будет нанимать талантливых разработчиков? Конечно же, через поиск!

Оказывается, Google следит, если пользователь вводит в поисковую строку один из специфических поисковых запросов — и начинает обрабатывать потенциального кандидата в креативной манере. Для начала ему предлагают сыграть в игру. Как организован инновационный процесс поиска и найма талантливых программистов — рассказывает математик Макс Росетт (Max Rosett), который именно таким образом попал на собеседование и получил работу в Google.

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

Однажды утром, работая над проектом, Макс Росетт набрал в поисковой строке [python lambda function list comprehension]. Появился обычный список со ссылками, и математик начал искать среди них наиболее релевантную — и тут произошло нечто необычное.

Страница с результатами поиска внезапно разделилась на части и раскрылась, как створки дверей, а между ними возникло чёрное окно со словами «Ты разговариваешь на нашем языке. Готов к вызову?

«Я уставился в экран, — рассказывает Макс. — Что это? Через мгновение я решил, что да, я определённо готов к вызову».

«Я нажал на ссылку — и попал на стартовую страницу под названием foo.bar. Она напоминала UNIX-интерфейс, так что я набрал команду, чтобы вывести список файлов. Там был только один файл start_here.txt. Я открыл его и увидел два предложения:

«Введите request для вызова задачи. Введите help для получения списка команд».

Я набрал request и уже был готов увидеть фразу «Следуй за белым кроликом, Макс». Вместо этого на экране появился абзац текста с условиями задачи на программирование и инструкция, как отправить решение. Мне дали 48 часов, и таймер всё время тикал», — рассказывает Макс Росетт.

Саму задачу Макс не публикует, но говорит, что для её решения требуется знание алгоритмов. Предлагалось писать код на Python или Java.

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

После решения шестой задачи foo.bar предложил оставить свои контактные данные: номер телефона и адрес электронной почты. К большому удивлению автора, через пару дней ему пришло письмо от сотрудника отдела кадров с просьбой прислать резюме. Он выслал, а потом договорились о телефонном звонке.

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

Только придя в офис компании Google он окончательно поверил, что не стал жертвой розыгрыша. Решая задачи foo.bar, Макс Росетт спрашивал у нескольких знакомых, в том числе сотрудников Google, знают ли они что-нибудь о таком тесте. Никто не знал, но все согласились, что это была бы замечательная идея.

Хотя пришлось ждать две недели, но в конце концов компания Google прислала «долгожданный job offer.

«Foo.bar — это блестящая тактика рекрутинга, — уверен Макс Росетт. — Google вычислила меня даже до того, как я подал документы, и они заставили меня почувствовать собственную значимость, когда сделали так. В то же время, они уважали мою приватность и не выходили на контакт до тех пор, пока я недвусмысленно не дал своё согласие на это».

«Да и вообще, мне понравились их головоломки», — добавляет новоиспечённый гуглер.

4 новых поисковика для программистов, пациентов, картографов и любителей подкастов

Параллельно интеграции поисковиков в самые разные устройства будут появляться специализированные поисковые системы вроде Hackr.io, Zocdoc, Geovisual Search и Audiosear.ch

Когда речь заходит о поисковых системах, воображение рисует окно для ввода запроса и результаты поиска. Но как будут выглядеть поисковые системы в будущем?

4 новых поисковика для программистов, пациентов, картографов и любителей подкастов - Hackr.io, Zocdoc, Geovisual Search и Audiosear.ch

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


Zocdoc - новый поисковик для пациентов медиков

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

4 новых поисковика для программистов, пациентов, картографов и любителей подкастов - Hackr.io, Zocdoc, Geovisual Search и Audiosear.ch

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


Geovisual Search - новый поисковик для картографов

В данный момент поверхность Земли с орбиты фотографирует больше спутников, чем когда-либо прежде в истории нашей цивилизации. У одной только компании Planet, Inc имеется более полусотни орбитальных камер. Еще несколько стартапов планируют запустить свои собственные спутники в ближайшее время. Что нам делать с создаваемыми ими фотографиями? Как осуществлять по ним поиск?

4 новых поисковика для программистов, пациентов, картографов и любителей подкастов - Hackr.io, Zocdoc, Geovisual Search и Audiosear.ch

Компания Descartes Labs, которая использует машинное обучение для оценки состояния сельскохозяйственных культур и других экономических показателей с помощью спутниковых изображений, создала инструмент для эффективного индексирования спутниковых фото и поиска по ним. Он называется Geovisual Search.

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


Hackr.io - новый поисковик для программистов

Еще один новичок в лице поисковой системы Hackr.io был разработан специально для помощи программистам в поиске онлайн-курсов и учебников по написанию кода практически на любом языке программирования из числа существующих. Да, можете использовать любую поисковую систему, чтобы найти множество курсов и учебных пособий. Можно воспользоваться видеохостингом вроде YouTube для поиска подобного контента. Но поисковик Hackr.io ориентирован исключительно на программистов, что делает его выдачу более качественной.

4 новых поисковика для программистов, пациентов, картографов и любителей подкастов - Hackr.io, Zocdoc, Geovisual Search и Audiosear.ch

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


Audiosear.ch – новый поисковик для любителей подкастов

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

4 новых поисковика для программистов, пациентов, картографов и любителей подкастов - Hackr.io, Zocdoc, Geovisual Search и Audiosear.ch

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

Поисковик для начинающих программистов

Современный интернет развивается неимоверными темпами. Размер информации в глобальной сети уже более 500 миллиардов гигабайт по данным компании IDC, и он удваивается ежегодно. Все мы привыкли искать нужную нам информацию с помощью мощных поисковых машин, таких как Google, Yandex, Bing, Yahoo и др., но среди такого количества данных становится всё труднее отыскать то, что действительно полезно и нужно. Большое влияние на поисковую выдачу (то, что мы находим по своим запросам) имеют и контекстная реклама, и войны SEO оптимизаторов и множество других факторов.
На помощь к нам приходят нишевые поисковики, то есть те поисковые машины, которые ищут информацию строго по заданной тематике. Довольно давно мы уже рассказывали о поисковике по документам PDF, Excel, Doc, Power Point, сегодня мы расскажем о

поисковике для программистов.

Современные программисты, особенно вебдевелоперы, должны знать и понимать не один, а сразу несколько языков программирования, разбираться в плагинах и CMS, использовать скрипты Javascript и разметку HTML. Естественно, помнить все функции и знать все нужные плагины просто невозможно, но и изобретать велосипед тоже не хочется, например известный «Hello World!».

Для чего нужен поисковик для программистов?

Допустим,  мы хотим написать программу «Hello World!» на JavaScript. Вводим запрос — получаем ответ:

На рисунке выше мы показали часть поисковой выдачи этого поисковика.

Таким же образом, мы сможем найти:

  • плагины jquery
  • код рекурсивного обхода графа на Borland Delphi
  • описание любой функции php
  • множество сниппетов и даже готовых маленьких программ

Воспользоваться поисковиком для программистов можно по ссылкам ниже:

Сейчас другие читают

Удобный для программиста поисковик? - CodeRoad

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

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

вот документация для makefiles http://www.gnu.org/software/make/manual/make.html

Удобно, что вся документация находится на одной гигантской странице html. В firefox нажмите control+f (command+f на компьютерах Mac), чтобы вызвать поиск в виджете страницы. В поле поиска firefox введите искомый символ. Он сообщает о 37 матчах, которые вы можете просмотреть в отдельности.

Иногда, однако, последовательность символов является идиоматической, и ее нет в документации для языка. Откуда постороннему человеку знать, например, что $ in javascript обычно ссылается на jquery, или прототип, или какую-то другую включенную библиотеку?

В этом случае, вероятно, где-то есть вопрос о переполнении стека, который объяснил бы это. Однако поиск stackoverflow для символа $ не работает. Вы можете просто задать вопрос, и вы, вероятно, получите ответ. (как и вы в данном случае).

Я думаю, что мы, возможно, должны сделать запрос функции stackoverflow? Это не общий веб-поиск, но stackoverflow имеет уникальную возможность ответить на подобные проблемы так, как это не делает общий веб.

edit: посмотрев на meta.stackoverflow.com, я обнаружил, что запрос на это уже существует : https://meta.stackexchange.com/questions/19870/we-need-to-be-able-to-search-for-punctuation-symbols

Казалось бы, если нажать "ask a question" и написать

What does the symbol [symbol] in [language] mean?

в заголовке, а затем переместите курсор в тело, SO предложит кучу вопросов, которые уже были заданы,что намного лучше, чем использование "search". Скорее всего, вы найдете там ответ на любой запрос, связанный с символами. А если вы этого не сделаете, продолжайте и опубликуйте свой вопрос. Я уверен, что есть около 10 чересчур нетерпеливых ботаников, которые будут рады сообщить вам, что вопрос уже был задан, и указать вам, где находятся дублирующие вопросы, и только ценой нескольких потенциальных понижений!

Однако переполнение стека действительно должно добавить эту функцию. Это смешно, что это не так. Повторяющиеся вопросы-это всего лишь стоимость, Что сайте StackOverflow будет принять для не имеющих этой функции.

Шпаргалка для программистов или «мы погуглим за вас» / Habr

Введение, которое можно не читать

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


Собственно, сама суть

Итак, представляю вам сервис «cheat.sh». Написан он на Python, так что питонисты могут заинтересоваться. Существует несколько его реализаций:


  • Через «curl» в командной строке;
  • Через браузер.
  • Через редакторы кода: Emacs, Vim, Sublime Text, VSCode.

Как использовать


Используя «curl»

Здесь нужно иметь утилиту «curl». В дистрибутивах Linux она уже есть, для Windows её нужно устанавливать отдельно. Проблем на Windows у меня не возникло.

Заходим в консоль и отправляем запрос такого типа:
curl cht.sh/[язык]/[запрос-с-дефисом-вместо-пробела]
Получаем ответ:

$ curl cht.sh/python/how-to-read-text-file
#  How to read a text file into a list or an array with Python ...
#
#  You will have to split your string into a list of values using split()
#
#  So,

lines = text_file.read().split(',')

#  [Achrome] [so/q/14676265] [cc by-sa 3.0]

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

$  curl cheat.sh/tar
$  curl cht.sh/curl
$  curl https://cheat.sh/rsync
$  curl https://cht.sh/tr

Ещё можно установить консольную утилиту:

$   curl https://cht.sh/:cht.sh > ~/bin/cht.sh
$   chmod +x ~/bin/cht.sh

Пример использования здесь.
Для Windows таких команд нет, поэтому есть вариант использовать Cygwin, Git bash и так далее.
На ваш страх и риск.


Используя браузер

Просто переходим по нужной ссылке в браузере.
На примере www.cht.sh/python/how-to-read-text-file

Ссылку можно отправить в качестве ответа на Stackoverflow, к примеру.


Используя редакторы кода

Зачем? Чтобы не выходя из редактора получить копипастом код решения.

Плагин для Emacs,
Плагин для Sublime Text,
Плагин для Vim,
Плагин для VSCode.


Интересности


Авто-дополнение на Tab

Установка для Bash:

    $ curl https://cheat.sh/:bash_completion > ~/.bash.d/cht.sh
    $ . ~/.bash.d/cht.sh
    $ # and add . ~/.bash.d/cht.sh to ~/.bashrc

Установка для ZSH:

    $ curl https://cheat.sh/:zsh > ~/.zsh.d/_cht
    $ echo 'fpath=(~/.zsh.d/ $fpath)' >> ~/.zshrc
    $ # Open a new shell to load the plugin

Параметры ответа

Если вам не нужна подсветка синтаксиса в ответе:
curl cht.sh/python/open-file?T

Если вам нужен только код без комментариев:
curl cht.sh/python/open-file?Q

Вы можете это комбинировать:
curl cht.sh/python/open-file?QT


Стелс-режим

Открываем клиентскую версию с параметром «--shell» и используем:
$ cht.sh --shell [язык программирования]
$ stealth [параметры]
Зачем? Чтобы быстро получить ответ. Автор предлагает использовать такое на дистанционных собеседованиях. Тут лишь вопрос вашей собственной совести.


One-line решения

curl cht.sh/[язык]/1line

Тут даже для Python есть. Да-да, для языка, где разделением блоков кода является перевод строки.


Странности языков программирования

curl cht.sh/[язык]/weirdness


Посмотреть другой ответ

Если вас не устроил текущий ответ на ваш запрос, можете посмотреть другой:
curl cht.sh/[язык]/[запрос]/[номер ответа]


И что, с помощью одной утилиты можно выучить основы языка?

$ curl cht.sh/[язык]/:learn


Заключение

В общем-то, всё. Возможно, кто-то уже знает о «cht.sh» и использует, но на русском я не нашёл нормальных материалов о нём. На GitHub есть таблица полноты «cht.sh» по языкам, ссылки на плагины для редакторов и полное руководство, если кого-то не устроило моё. Спасибо, что прочли.

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

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



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

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


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

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

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

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

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

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

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

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


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

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

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

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

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


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


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

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


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

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

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

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

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

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


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

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

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

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

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

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

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


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

Литература


  • 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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *