[БЕЗ_ЗВУКА] [БЕЗ_ЗВУКА] Итак, давайте обсудим с вами различные оффлайн-метрики. Первый вид оффлайн-метрик, которые мы рассмотрим, — это маркерная оценка. У нас с вами есть набор маркеров, то есть пар «запрос–документ», и мы уверены, что они должны обязательно находиться, то есть поэтому запросу обязательно должен подниматься этот документ. Отличным примером здесь является запрос ВКонтакте, по которому, очевидно, веб-поиск должен поднять главную страницу социальной сети ВКонтакте vk.com. Что же мы можем померить с помощью маркерных оценок? Например, мы можем иметь какой-то определенный базовый набор пар «запрос–документ», для того чтобы проверить, что наш поиск продолжает работать в штатном режиме нормально. Дальше, мы можем проверять навигационные запросы. Например, по запросу «Большой театр» очевидно, что веб-поиск должен найти главную страницу сайта Большого театра. Далее, многозначные запросы. Каноническим примером здесь является запрос «ягуар», на который поисковая система должна найти как информацию о большой пятнистой кошке, так и информацию о спортивной машине. Дальше есть такая интересная метрика, которая называется «полнота индекса». Эту метрику замеряет в частности независимый анализатор компании «Ашманов и партнеры». Так как компания не имеет доступа непосредственно к тем корпусам, которые используют разные веб-поиски для построения своих индексов, то для оценки полноты индекса используются очень редкие запросы. Соответственно, в случае если индекс достаточно полный, он содержит в себе очень разнообразные документы, то вероятность того, что в нем найдется документ, который удовлетворяет какому-то крайне редкому запросу, также очень велика. Соответственно, эта величина показывает разнообразие документов в индексе. Также можно придумать другие метрики, которые можно померить с помощью маркерной оценки. Давайте вернемся в самое начало нашего курса. Как вы помните, первое, с чего мы начали знакомство с информационным поиском — это был булев поиск. И именно тогда мы упомянули такие метрики качества булева поиска, как полнота и точность. Итак, у нас с вами есть некий корпус документов, в которых мы производим поиск. Есть запрос, который мы посылаем в этот корпус документов. Соответственно, у нас есть какое-то множество документов, которое наша поисковая система нашла по этому запросу, и какое-то множество, которое она должна была найти. В лучшем случае эти множества совпадают, в реальности они чаще всего просто пересекаются. Для того чтобы оценить, насколько хорошо они пересекаются между собой, как раз и используется полнота и точность. Давайте рассмотрим, как мы их можем посчитать. Итак, первый показатель — это полнота. Это оценка, которая показывает нам, сколько документов из всех, что релевантны запросу пользователя, смогла найти наша поисковая система. Для этого мы должны оценить соотношение пересечения этих двух множеств, о которых мы с вами говорили, с множеством всех релевантных документов к этому запросу. И второй показатель, который нас интересует, — это точность. Это сколько документов из тех, что смогла найти поисковая система, были действительно релевантны. То есть в этом случае мы пересечение этих множеств сравниваем с общим количеством найденных документов. Итак, у нас с вами для оценки булева поиска есть две величины. Но оперировать одновременно двумя величинами очень сложно, поэтому чаще всего делается переход к некой общей метрике, которая объединяет в себе знания об обеих этих величинах, это F мера или мера Ван Ризбергена. Это среднее гармоническое, которое объединяет информацию и о полноте, и о точности в одно число, с помощью которого мы можем оценить, насколько хорошо наш поиск ответил на тот или иной запрос. Итак, давайте посмотрим на примере, как это будет работать. Вот у нас с вами есть некий запрос, на который во всем нашем корпусе нашлось всего 60 релевантных документов. Однако наша поисковая система в выдаче нашла 150 документов, из которых только 30 действительно релеватные. В таком случае полнота, точность и F мера будут иметь следующие значения. Итак, как мы можем оценить полноту и точность, если мы будем работать не с булевым поиском, а с более сложной конструкций, например в случае в веб-поиском? Самая главная проблема, с которой мы здесь сталкиваемся, заключается в том, что нам требуются знания о релевантности документов. Первый подход к оценке полноты можно сделать, например, если использовать какой-то корпус, который размечен заранее. То есть у нас есть корпус документов и набор запросов, и мы точно знаем, какие именно документы какому запросу будут релевантны. В таком случае мы можем по выдаче нашей системы оценить, насколько полную выдачу она составляет. Однако этот подход имеет достаточно крупные недостатки. Во-первых, нам нужна разметка. Добыть хорошо размеченный корпус очень сложно, подготовить его долго и дорого. Ну и кроме того, данные получаются не настоящие, мы не можем использовать весь объем данных, который мы потенциально можем проиндексировать и использовать для поиска, а используем такой небольшой игрушечный набор, который может не показать какие-то крайние случаи. Для того чтобы измерить точность, тут все намного проще, потому что нам нужно оценить качество непосредственно выдачи. То есть насколько релевантна наша выдача запросу пользователя. Нам не нужно знание обо всем корпусе документов. Так, для того чтобы найти релевантные докумены в выдаче, мы можем точно так же воспользоваться заранее размеченными множествами, где мы знаем, какие именно документы релевантны были нашему запросу, либо мы можем призвать на помощь экспертов, которые разметят эти документы за нас и скажут, насколько именно выдача была релевантна запросу. Ну и кроме того, нам следует принять сэмплирование. Совсем необязательно заставлять экспертов оценивать все запросы и все документы, это излишне. Нам достаточно собрать, во-первых, сэмпл запросов. Так как нам не нужны все запросы, мы будем выбирать максимально случайным образом из логов нашей системы. Желательно, чтобы это были логи за несколько дней. Как вы помните, даже в соседние дни запросы могут абсолютно разными. Дальше в этих логах за достаточно большой период времени мы случайным образом выбираем набор запросов. Таким образом, так как запросы выбраны случайно, в случае если запросы были очень популярны, то они много раз встречались в логах и много раз встретятся в нашей выборке. Кроме того, если нарузка на систему у нас была неравномерна, как в случае в веб-поиском, например, нагрузка ночью значительно ниже, чем нагрузка в конце рабочего дня, то, соответственно, ночных запросов в выборке будет намного меньше, чем вечерних. Итак, мы строим сэмпл случайным образом. Теперь у нас есть набор запросов и мы знаем, какие именно документы поднимала система по этим запросам. Нам не обязательно использовать весь корпус документов, мы можем использовать только те документы, которые поднимала система, и даже из них, в случае с веб-поиском, мы можем использовать не все документы, а только первые 15. Так как клики в документы, то есть то, насколько пользователи реагируют на последующие документы, начиная с первого, падают катастрофически. То есть на самом деле больше всего пользователь реагирует на первый документ, в крайнем случае, на второй, на третий. До десятого доходят буквально единицы. Соответственно, до пятнадцатого будут доходить какие-то очень малые доли процентов пользователей, поэтому 15 документов на каждый запрос будет нам достаточно. Однако это не подходит в случае, если мы используем другую поисковую систему, строим ее. Например, все тот же пример с правовыми документами, когда мы должны поднимать все документы. В этом случае ограничивать ту выдачу, которая соответствует тому или иному запросу для тестирования мы не имеем права. Мы должны тестировать всю выдачу, которая была поднята. Итак, у нас с вами в конечном счете собрался сэмпл запросов, собрался сэмпл документов. Теперь мы можем сформировать из всего этого множества пары «запрос–документ». И каждую эту пару мы должны оценить на то, насколько релевантен этот документ этому запросу. Для этого мы наконец-таки призываем на помощь экспертов. Они должны решить, насколько релевантен этот документ, и, используя именно эти знания, мы можем оценить точность нашего поиска. Но оценка через полноту и точность имеет несколько минусов. Давайте покритикуем такой подход. Итак, во-первых, такой подход хорошо применим в случае, если мы хотим оценить систему, которая требует полной выдачи. Однако в случае, если система каким-то образом ограничивает результирующую выдачу, то в результаты, которые мы получим при использовании такого подхода, будет вноситься лишний шум. Кроме того, для того чтобы оценить информационный поиск через точность и полноту, нам нужна либо предварительная разметка корпуса документов, либо помощь экспертов. Ну и наконец, в своем базовом представлении оценка через релевантность дает нам бинарную оценку, то есть документ либо соответствует запросу, либо нет. Однако, к счастью, в реальном мире все обстоит не так. Во-первых, документ может быть не полностью релевантен запросу. А во-вторых, пользователь работает у нас не с одним конкретным документом, а с целой выдачей, которую он получает от поисковой системы. Тут нам на помощь приходит ранжирование, и его мы тоже должны оценить. Итак, как вы помните, ранжирование — это компонент информационного поиска, который позволяет нам, во-первых, оценить качество документов — то, насколько они соответствуют запросу пользователей, насколько они релевантны, и решить, в каком порядке мы будем эти документы пользователю показывать в итоговой выдаче. Итак, как же мы будем оценивать ранжирование? В этом случае, очевидно, мы должны оценивать также и порядок. В общем случае мы можем для этой оценки использовать все те же точность и полноту. Итак, у нас с вами есть какой-то запрос, на который мы получили набор документов. Давайте ограничимся первыми десятью. Будем считать, что мы хотим видеть все десять релевантных документов в выдаче на этот запрос. Однако очевидно, что в выдачу могут закрасться какие-то нерелевантные документы. Поэтому для того чтобы оценить наш результат, который мы показываем на этот запрос, давайте будем итеративно переходить от одного документа к другому в выдаче и оценивать, как будет меняться полнота и точность нашей выдачи. Итак, первый документ, который у нас есть в выдаче по этому запросу, он абсолютно релевантен. Однако он всего один из тех десяти, которые мы хотели получить. Соответственно, полнота и точность имеют соответствующие значения. Дальше. Следующий документ у нас не релевантен. Таким образом, мы получаем два документа, из которых только один релевантен, и однако все так же, это тот самый один документ из десяти, который мы хотели найти релевантными. Таким образом мы переходим от одного документа к другому, пока не построим набор значений для полноты и точности для ответа нашей системы на этот конкретный запрос. Итак, мы можем нанести полученные значения на график. Получим примерно такое изображение. Но одного запроса и ответа нашей системы на него нам не достаточно. Давайте возьмем следующий запрос. Тут все намного хуже. Как вы видите, релевантных документов очень мало, соответственно, показатели будут совершенно другими и график тоже будет отличаться. Так мы можем перебирать все запросы из того сэмпла, что у нас есть, и строить графики по тому, как наша система отвечает на эти запросы. Теперь как мы можем оценить, какая система лучше или нет, если мы построим такие графики для одной системы и для другой. Мы, во-первых, должны перейти к интерполированной точности, то есть мы должны сгладить те просадки, которые у нас есть на графике точности. Теперь мы можем усреднить эти значения для всех запросов, которые мы рассматриваем в рамках сэмпла. Ну здесь на примере вы видите, мы используем всего два запроса, однако в реальном мире, естественно, запросов будет больше. И показателем качества нашего ранжирования, качества итоговой выдачи нашей системы будет площадь под итоговым средним графиком. Ну и кроме того, как я уже говорила, нам очень важно, как пользователь реагирует на самый первый документ, так как дальше первых трех пользователь редко уходит, то мы можем использовать не данные по первым десяти запросам, а делать срез, например, по первым пяти. То есть такой точный срез, одноточечную оценку, которая будет достаточно точно характеризовать качество нашего поиска. [БЕЗ_ЗВУКА]
