Наверх ▲

Про качественный поиск

Андрей Аксенов Андрей Аксенов Всю жизнь пишет низкоуровневый код, в 2018 все еще делает поисковый движок Sphinx.

Андрей Аксенов: Добрый день! Меня зовут Андрей Аксенов, я специалист по поиску в Sphinx

Сегодня я буду рассказывать про качественный поиск. Доклад будет про то, что можно сделать для улучшения качества поиска на вашем сайте в меньшей части, в большей части. Как устроена в современном мире загадочная штука под названием "релевантность", как она считается, до чего дошла (доросла) наука о веб-поиске.

Могу пока заранее ответить на вопросы какие-нибудь!

Реплика из зала: Список литературы посоветуйте.

Андрей Аксенов: Список литературы посоветуйте… Литературы для чего?

Реплика из зала: По работе с поиском...

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

Это гигантская наука. В год защищается немало диссертаций и делается немало публикаций. Есть несколько хороших книжек… Я не читал ни одну, к несчастью. Говорят, что работа Маннига "Introduction to Information Retrieval" – хорошая. 

Зачем нужен этот доклад?

Скорости растут (в смысле, скорости "железа"). Как ни удивительно, со временем выясняется, что скорость  поиска сама по себе, блин, для 99 % людей не важна. Реально не важна! Какая разница, 300 запросов в секунду с ядра или 150 запросов в секунду с ядра, если ядер все равно 16, а пользователей на сайте все равно 10 в день? Это во-первых.

Во-вторых. К несчастью, "свободные" сервисы, которые не берут с пользователей денег, чтобы делать веб-поиск (типа Google, Yandex, Bingo и так далее) приучают людей к достаточно качественному поиску. Потребность есть. 

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

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

Все началось с коротенького блиц-доклада на прошлом РИТ меньше года назад. Доклад успел вырасти до 40 с чем-то минут. Ну, поехали!

Что такое релевантность?

Многие думают, что есть некая магическая функция релевантности, которую ты посчитал, и у тебя все хорошо. Неправильно думать, что она, в принципе, в природе есть. Это не совсем так.

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

Мне глубоко неприятно, когда кто-нибудь что-то ищет и находит, потому что в этом случае необходимо работать над результатами, ранжировать их и тратить на это много ресурсов. Это не круто!

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

Но ранжировать их сложно. Попробуем разобрать один случайный запрос. Это крайне сложно – этим никто в мире не умеет заниматься: человек не так устроен. Тем не менее, попробуем поставить себя на место пользователя, который что-то искал.

Вот один случайный запрос – я выбрал вот такой. К несчастью, он на английском (может быть, наоборот – к счастью) "battle ship".

Что имел в виду человек?

Может быть, он искал вот этот корабль: информацию по поводу того, когда его, наконец, спустят на воду. Или он интересовался правилами игры "Морской бой", или может быть, искал что-то более футуристическое. Может быть, он вообще сдалал опечатку и совсем не это имел в виду… Копирайт корпорации "Google" – отличная реклама. Я очень люблю.

Шокирующая истина

Внезапно, шокирующая истина! Запрос может быть одним и тем же, но разные люди могут хотеть найти разное. Кто-то правила "Морского боя", а кто-то просто не знал, что эта штука на английском называется не "battle ship".

Что же это за шокирующая истина? 

Нет никакой релевантности! Нет никакой ложки! Нет никакой объективной релевантности, если угодно, данной нам в ощущениях, существующей как идеальный концепт в платоновском мире мета-идей.

Так называемая релевантность: это всегда "красота – в глазах смотрящего". Для разных людей одному и тому же запросу релевантно совершенно разное. Хуже того – в разные моменты времени для одного и того же человека этому запросу может быть релевантно совершенно разное. 

Семантика коротенького полнотекстового запроса меняется в зависимости от того, пьян я или не пьян, в каком городе нахожусь и что конкретно ищу. Тоска!

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


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

Часть из этих свойств – это текст документа, с одной стороны, и текст запроса, с другой стороны.

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

Все это называется по науке "полнотекстовыми факторами".

Очередная слегка шокирующая истина

Во многом всё и всегда базируется ровно на одном факторе под названием BM25. Функция ВМ25 выглядит так. Совершенно несложная для тех, кто учился на технических специальностях. Гуманитарии, поверьте, она несложная.

Грубо говоря, тут по всем терминам, по всем ключевым словам запроса всего-навсего суммируется некая магия, которая растет, если слово редкое, и если слово встречается в документе часто. Соответственно, если слово слишком частое, то значение меньше. Если встречается в документе мало, то показатель падает.

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

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

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

Очень важный фактор – определение того, порносайт это или нет. Очень разные результаты поиска надо показывать: особенно картиночные – вообще разные.

Предыдущий слайд – это сильное преуменьшение, потому что современный веб-поиск (подчеркиваю, именно масштаба веб) очень сложен. Люди, которые этим плотно занимаются, пользуются не десятком факторов, а реально тысячей. И все они учитываются в поиске.

Еще немаловажное отступление для тех, кто все-таки будет читать литературу. В англоязычной литературе обычно используется слово "сигнал". Не буду настаивать, что оно типичное… Может использоваться и слово "фактор", и слово "сигнал". Я мало читал или просто за статистикой не следил – определенного мнения не составил.

Итак, что мы выяснили?

У нас есть некоторое количество полнотекстовых факторов, которые мы считаем по тексту документа и запроса. У нас может быть некоторое количество нетекстовых факторов, которые мы просто знаем про документ (длина, "возраст" домена, PageRank, прочий "фарш").

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

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

Очередная небольшая (и поэтому без картинки) шокирующая истина заключается в том, что конкретные числа, которые вам выдаст функция релевантности, вообще не важны. Абсолютно! Умножь их все на 10, подели на 100 – что изменится? Ничего. Важен порядок документов, который порождается функцией релевантности. То есть, загадочная функция релевантности вообще не важна.

Значение релевантности вашей главной страницы в Yandex – 123.45 при поиске по конкретному запросу. И что? Абсолютное значение неважно совершенно – важен порождаемый порядок.

Есть и вторая вещь, которая важна, потому что надо работать с качеством. У нас есть субъективная функция непонятного вида – ничего с ней не сделать. Есть порядок, который этой функцией порождается. Но все еще непонятно, с чем работать. Непонятно, к чему применять научный подход, когда расчехлять калькулятор и что на нем считать.

А вот что. В большой науке про релевантность все начинается с человеческих оценок качества. Они субъективны и, к глубочайшему моему несчастью, никакими другими быть не могут.

Не существует, не существовало и не будет существовать программы, которая возьмет запрос и документ и скажет: "Это релевантно!"  Подчеркиваю: не просто не существует – это субъективно, это факт.

Что мы тогда делаем? Правильно: не можем написать программу, не можем построить робота – сажаем за работу миллиард китайцев. Живые люди сидят и кликают, оценивают пару "запрос-документ", ставят им оценки.

Иногда это просто бинарные числа 0 и 1. Иногда это оценки по шкале от 2 до 5, как в советской школе, или от А до F, как в американской. Для простоты давайте дальше говорить о бинарных оценках: релевантны или нет.

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

Пример. Кто-то поискал в Google слово Sphinx. Нашел вот что. Поскольку поиск открывал нормальный человек, который не интересуется этим всем – поиском и системой генерации документации Python – ему без затей подавай египетского сфинкса (два документа про это).

Второй и третий результат для него релевантны (подсвечены), а остальные нет.

Другой пример отклика, другая поисковая машина. Это придуманный пример, если что. Результаты я, правда, из Google взял, а как их "ремиксанул", не помню. Другой пример: то же самое, но результаты выше. Интуитивно понятно, что это лучше, потому что человек, который что-то искал, нашел это в первых рядах.

Еще один пример отклика. Результаты еще сильнее поменялись местами. Один совсем вверху (№ 1), а второй релевантный сполз вниз. Как быть? Как сравнивать эти три отклика, что с ними делать?

Метрики качества

Наука разобралась, что с ними делать. Вводятся так называемые метрики качества: их десяток уже точно придуман. Есть ряд совершенно примитивных метрик, которые вообще не смотрят на порядок документов: Precision и Recall – это как раз они. Это может звучать страшно, но на самом деле, когда начинаешь смотреть на формулы и вдумываться в них, ничего страшного в этом нет.

Precision

Precision – это всего-навсего количество релевантных результатов в показанном пользователю "куске" результатов поиска. Во всех этих трех случаях Precision одинаковый. Он равен 0,5. Два результата из четырех релевантны.

Recall

Recall тоже довольно примитивная штука. Мы знаем или предполагаем, что всего в индексе есть 10 релевантных результатов, а поиск каким-то образом возвращает только 8. Значит, Recall 80 % (0,8). Ничего страшного.

Это недостаточно: никак не различаются такие результаты, где порядок разный. Чисто интуитивно пользователю всегда приятнее, когда у него нужное идет 1-м результатом, а не 10-м. Ни с помощью Precision, ни с помощью Recall отличить два таких результата нельзя. Приходится что-то еще придумывать.

Есть стандартные метрики Average Precision, DCG (Discounted cumulative gain), BPREF, pFound от Yandex.

Я не буду никого утруждать точными формулами. Кому сильно интересно, почитает сам. Полезно думать, что, по большому счету, это просто взвешенная свертка нулей и единиц. Вес результата – 0 либо 1 в первой позиции умножается на большой коэффициент. Во второй – на коэффициент поменьше, и так далее. Это примерно и будет верно.

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

Есть люди, которые пишут в Интернете: "А-а-а, я поискал это в Yandex и в Google (один запрос – прекрасно), и Google выдал сильно худший результат". Либо наоборот: "Yandex выдал мне сильно худший результат".

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

Чтобы это сделать, оценивается куча запросов! Оценивается куча документов по куче запросов. Усредняется куча откликов. Усредняется классическим образом: какую-нибудь метрику типа Average Precision считаем для одного запроса, для другого, для третьего, для миллиона. Все складываем вместе, делим.

Ура, ура! Что произошло? Только что из чудесных ноликов и единиц, которые пользователь проставил каждому документу, который мы ему отдали по запросу, мы каким-то образом получили магическую цифру.

Неважно, какую. Может быть, Mean AP, может, средний pFound, может быть, нижний доверительный 95%-ный диапазон для нормализованного DCG. Совершенно неважно, какую, но мы получили, наконец, заветную цифру (заветную для любого научного работника), которая кое-как моделирует среднее "счастье пользователя". Мы высчитали нечто, с чем можем работать, что можем оптимизировать.

Так называемая несуществующая релевантность проходит крайне извилистый путь.

Все начинается с мега-функции, которая по каким-то факторам и числам, привязанным к документу (или к документу и запросу), берет и считает магическое число. При помощи магического числа под названием "релевантность" документы, найденные в отклике, меняются местами.

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

Вот она – релевантность, будь она неладна.

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

Очередная шокирующая истина. Этот график – иллюзия… Точнее, иллюзией является, что вообще есть какой-то график. Это субъективная функция… Аналитически придумать некую волшебную формулу от двухсот аргументов для функции, которая просто существует, невозможно.

Что делают, когда формулу придумать невозможно?

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

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

От регрессии до современного машинного обучения путь очень длинный.

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

В первом приближении это хорошая ментальная модель. Можно думать, что оно так и работает. Хотя на самом деле, конечно, не так.

Что именно регрессируется?

Оптимизируем… Целевая функция… Можно оптимизировать ту самую среднюю "метрику счастья", которая имеет высоконаучный вид, но на самом деле считается, грубо говоря, в 20 строк кода Python (может быть, в 3).

Что нам известно? Что есть на входе? Где наши Х, где наши Y?

Y – это целевая функция. Тот самый MAP. Известны оценки, которые люди поставили. Известны факторы – числа, описывающие документ.

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

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

Как всегда со сложными задачами – шокирующая истина. Она в современной науке решается крайне просто.

Берем и тупо приближаемся к кусочно-линейной функции. Отличное решение! Это мне по нраву. Работать с линейными функциями всегда просто. Понятное дело, что это кусочно-линейная функция в двухсотмерном векторном пространстве, но какая разница?

Зачем все это вообще? А вот зачем!

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

Проверять качество поиска вручную становится нереально в настолько маленьких масштабах, что аж страшно. Ну, сами представьте – вы сделали какое-то изменение в формуле ранжирования. И чего? Вводим один запрос – ну, блин, на глаз вроде лучше стало. Вводим второй запрос – блин, а тут хуже. Вводим третий – так, ладно: тут чего-то улучшилось. Счет пока 2:1.

Потуги проверять качество вручную без того, чтобы считать конкретные численные метрики и усреднять их, "умирают" уже при 5-10 оцениваемых запросах. Допустим, вы пытаетесь считать качество на очень маленькой выборке запросов… Пусть вы пытаетесь считать его не по принципу "мне кажется, стало лучше", а аккуратно и с конкретными цифрами, но очень быстро наступает момент, когда ничего невозможно посчитать вручную.

Уже начиная всего лишь с 5 запросов, с 10 документов на запрос, возникают трудности: это, извините, уже 50 цифр, 50 нолей и единиц, которые надо перемножить с заранее проставленными оценками. Считать вручную невозможно. Так что метрики нужны сразу, если мы хотим этим заниматься.

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

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

Но машинного обучения тоже не стоит сильно бояться, поскольку никто в современном мире не заставит вас взять и написать 20 тысяч строк кода, которые дадут плохой результат. Современный мир устроен иначе. Уже наверняка все сделано для нас. Можно просто воспользоваться математическим или статистическим пакетом в Open Source.

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

Итоги первой части

В мире большого веб-поиска есть релевантность. В чем ее особенность? Очень много документов, высокие требования к качеству, нагрузки дикие (очень много запросов).

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

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

Не нужно реализовывать машинное обучение, которое смасштабируется на кластер из 1000 машин. Можно просто подгонять руками формулу, но при этом даже простому человеку с блогом на 1000 постов метрики качества все равно придется считать и проверять автоматически, потому что здесь сложность растет очень быстро. Считать метрики качества вручную никакой возможности нет.

Конечная цель та же самая: вводим какую-то "метрику счастья" и максимизируем ее.

Это была довольно скучная теория. Теперь будет самопиар. Я расскажу, что у нас уже есть внутри Sphinx, что мы недавно сделали и что вы можете сделать, пользуясь нашими фичами. Это самое интересное.


Подзаголовк секции: "Как все хорошо у них, как все плохо у нас".

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

В веб-поиске используется куча сигналов и факторов. Есть куча типичных оценок, которые накоплены компанией за годы работы. Элитным "state-of-the-art" решением находится магическая целевая функция релевантности – большая и очень сложная. На меньших масштабах у вас мало факторов. Зачастую оценок качества у вас просто нет.

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

Функция ранжирования в лучшем случае подобрана методом с сурово звучащим названием "ad-hoc". В переводе на русский – "методом левой пятки". Покурили, подумали: "Наверное, лучше будет. Давайте вобьем эту формулу!". – "Откуда мы знаем, что лучше будет?". – "Да мы не знаем! Просто формула нравится – давайте ее вобьем". Ну, что с них взять?

Вот и все отличия. Однако не все так плохо, как казалось. Это не значит, что "ad-hoc" – это сам по себе совершенно нерабочий метод. Подгонять параметры "левой пяткой" с оглядкой на метрики качества все же можно.

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

Живой пример

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

Тем не менее, смотрим на график. Физический смысл графика: чем выше линия, которую рисует то или иное решение, тем лучше. Это как раз точность результатов поиска, количество релевантных результатов поиска на той или иной глубине погружения в набор результатов (англ. result set). Она далеко не на первом месте, но, слава Богу, и не на последнем.

Соревновались они при этом с коммерческими решениями – с тем же Yandex, по-моему, тоже.

Как мы это делаем?

Как и положено – "левой пяткой". У нас есть несколько встроенных функций ранжирования: API-метод такой. Можно выбирать его "на лету" буквально в одну строчку. Для каждого запроса брать свой. Есть одна "наколка" техническая: метод ранжирования работает только в том случае, если вы включили режим синтаксиса запросов, поэтому через API надо вызывать еще вот такой метод.

Чего можно хотеть от Sphinx?

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

С качеством у нас связано ровно 3 ранкера – все они уже перечислены. Они, как я и говорил, "пробиты" в код (hardcode). Других встроенных ранкеров, которые вы можете включить в одну строку и которые при этом заранее есть "в коробке", может быть, уже и не будет.

Пункт № 3. Появился мега-функционал, который мы давно сделали и выпустили в релизе.

Это вещь под названием "expression ranker". Выглядит она буквально вот так. Вот синтаксис, с помощью которого ей можно воспользоваться через SphinxQL-интерфейс. Подсвечена строчка, в которую вы забиваете свою формулу для ранжирования со всеми факторами, которые вам Sphinx посчитал и показал. Считаете релевантность, как можете и хотите. 

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

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

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

Наш самый сложный встроенный ранкер выглядит так. Концепт при этом все равно прост, как дрова. Но формула немного мутная. Смысл – точное совпадение полей – мы "бустим" на самый верх. Более точное совпадение фразы мы "бустим" в связи со степенью совпадения фразы. В самом конце используем стандартный фактор ВМ25, потому что нельзя игнорировать 30 лет истории. 

Я совершенно уверен, что теперь вы можете сделать поиск значительно лучше, чем в Lucene. Ранжирование значительно лучше, чем встроенное в Lucene в Sphinx, неважно где. Интерфейс доступен, факторы описаны, экскурс в теорию был. Дерзайте! Те, кому интересно этим заниматься, имеют все возможности и удобства.

Что еще можно делать с качеством поиска, кроме расчета релевантности?

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

Чудесной релевантностью дело же не ограничивается. Еще желательно корректировать опечатки. Еще есть такое понятие, как "занудность" поиска. Классическая ошибка любой поисковой формы: "А давайте поищем все слова, гы-гы". – "Ой, ничего не нашлось". – "Ну, давайте покажем 0 результатов". Прекрасно!

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

Ничего не мешало, но это мало кто это делает. Amazon делает, и у них все в жизни хорошо.

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

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

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

Очередная шокирующая истина. Придется немного поработать руками, как ни печально это для веб-разработчиков. Но реализовать все это можно – технологии позволяют: и Sphinx, и, думаю, Lucene и Solr, и новомодный Elastix. Любая другая вменяемая технология позволит вам это все сделать с тем или иным количество ручной работы. Скорее всего, как ни странно, много работать не придется.

Как бороться с опечатками? У нас есть демонстрация по этой теме.

Бороться с занудностью можно с помощью оператора кворума. В переводе на русский: взяли запрос в кавычки, дописали некоторое количество слов. Все. Запрос из "давайте поищем все слова" стал куда менее нудным, и найдется что-то более интересное.

Можно всячески анализировать запросы. Для этого у нас есть полезные и удобные инструменты. Образно говоря, это кубики, из которых вы можете уже что-то свое построить.

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

Вот, в общем-то, и все. Лимит времени совсем исчерпан, поэтому подробности уже точно будут в кулуарах.

У нас кое-что есть про релевантность, с одной стороны, и про нерелевантность, с другой стороны. Пользоваться можно вот так. Дерзайте!

Времени уже нет, наверное, даже на полвопроса. Или на полвопроса есть?

Вопросы и ответы

Реплика из зала: В формуле ранжирования можно использовать атрибуты документов?

Андрей Аксенов: Конечно. Любые и сколько угодно – и математические функции, и даже UDF можно написать и подгрузить "на лету". 

Это мое проклятье!

Реплика из зала: Привет, Андрей. Как размечать данные хорошо?

Андрей Аксенов: В смысле?

Реплика из зала: В выборке поиска.

Андрей Аксенов: Как хорошо размечать данные в выборке поиска… Проблема не в том…

Реплика из зала: Как пользователя заставить проставить оценки?

Андрей Аксенов: Ты никак не заставишь пользователя проставить оценки.

Реплика из зала: А ты не думал, что ты нерелевантен со своими оценками?

Андрей Аксенов: Ты этим должен начать хоть как-то заниматься сам. Пользователя ты можешь заставить (это, кстати, интересная тема) хоть как-то размечать, когда это пользователю зачем-то нужно.

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

Комментарии

0
# 4 ноября 2013 22:48
Доклад великолепен

Только пользователи могут оставлять комментарии

Возможно, вам будет интересно:

Участники: Сергей Рыжиков ("1С-Битрикс"), Илья Бублик ("СКБ Контур"), Дмитрий Сысоев (2ГИС), Тимур Амирханов ("Лаборатория Касперского"). Ведущий – Максим Спиридонов ("Рунетология").

Евгения Фирсова

Евгения Фирсова

Руководитель отдела веб-интерфейсов, Яндекс.Деньги.

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

Александр Тищенко

Александр Тищенко

Александр Тищенко, со-основатель и управляющий партнер компании «Злые марсиане», специализирующейся на гибкой заказной разработке сложных веб-проектов на Ruby on Rails.

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