[БЕЗ_ЗВУКА] Итак, мы с вами создали информационный поиск. Теперь мы с вами должны оценить, насколько хорошо он работает. В первую очередь мы должны протестировать работу всех компонентов поиска. Для этого мы должны проверить, что они действительно выполняют ту работу, которую они должны выполнять. Далее мы собираем все компоненты вместе в итоговый продукт и должны оценить, насколько хорошо он работает. Прежде чем оценивать качество информационного поиска, давайте вспомним, что же такое информационный поиск. Как вы помните, информационный поиск- это процесс поиска информации, который должен удовлетворить некую информационную потребность пользователя. Итак, у нас есть пользователь, у него есть информационная потребность. Чтобы удовлетворить ее, мы предоставляем в качестве ответа на запрос пользователя некий набор документов, которые должны потребнуть удовлетворить. И в случае, если это происходит, то пользователь уходит после того, как он воспользовался нашим информационным поиском, счастливым. То есть можно сказать, что качество поиска- это счастье пользователя, который им пользуется. Однако, очевидно мы не можем померить уровень счастья пользователя. Или на самом деле можем. Мы можем, по крайней мере, попытаться. Давайте произведем небольшую подмену понятий. Итак, у пользователя есть некая потребность информационная. Он формирует из нее запрос, который посылает в нашу поисковую систему. В ответ он получает набор документов. В случае, если эти документы релевантны его запросу, то мы считаем, что его потребность была удовлетворена. Значит, пользователь становится счастливым. Но к чему же может привести подобная подмена понятий? Во-первых, мы считаем, что пользователь правильно преобразует свою информационную потребность в запрос. Однако, здесь следует привести очень популярный пример, который приводится по этому счету. Например, у нас есть пользователь, который хочет найти, где находится ночной клуб «Рай». Однако, в ходе формирования запроса он вводит в поисковую строку просто слово «рай». Очевидно, что поисковая система просто выдаст ему ответ, который будет релевантен запросу, однако не будет удовлетворять информационную потребность этого пользователя. Это первое допущение, с которым мы сталкиваемся. И второе- правильно ли мы понимаем сам по себе запрос пользователя? Например, пользователь задал запрос, который выглядит как «птичье молоко». Что же он хотел на самом деле узнать? То есть хотел ли он узнал происхождение этого десерта? Хотел ли он узнать, как его готовить? Либо он хотел узнать что-то не про торт «Птичье молоко», а про конфеты, и хотел купить их оптом. То есть все эти допущения мы должны каким-то образом учитывать. Однако, в большинстве случаев понятно, что запросы будут трактоваться более-менее однозначно. Итак, в конечном счете мы будем оценивать, насколько релевантные в итоге документы мы нашли для каждого запроса пользователя. Зачем же нам вообще нужно оценивать качество поиска? В первую очередь, мы должны понять, что наш поиск действительно работает. И в случае, если пользователь вводит запрос «Александр Сергеевич Пушкин», он получает именно информацию о великом русском поэте. Далее, мы должны понять, что он работает хорошо, что он находит действительно ту информацию, которую пользователь ищет, что эта информация полностью его удовлетворяет. И так как поиск не является каким-то статическим программным продуктом, он постоянно меняется, изменяется, всегда можно что-то доработать, что-то улучшить, то с помощью оценки качества мы можем понять, что все наши улучшения действительно улучшают поиск, что мы ничего не испортили, что в итоге качество будет расти. Что же мы можем оценить кроме релевантности документов? Например, мы можем оценить скорость работы всей системы. Исследования говорят, что если пользователь веб-поиска ждет ответа более одной секунды, то скорее всего он уйдет и больше не будет пользоваться этой поисковой системой. Таким образом, скорость ответа очень важна. Для того чтобы оценить ее, чаще всего используется такой подход. Все время работы системы разбивается на небольшие промежутки в зависимости от того, какой общий поток запросов идет на систему, и оценивается самый долгий ответ в этот промежуток, самый быстрый и средний показатель. И соответственно мы смотрим, чтобы самый долгий ответ системы не вызывал неудовольствие пользователя. Далее, мы можем также оценить доступность нашей системы. То есть мы знаем, что наша система должна работать 24/7, однако вполне могут быть ситуации, когда наша система не доступна в случае, если это онлайн-поиск, в течении нескольких секунд, минут, а, может быть, даже часов. Соответственно, мы должны как можно лучше минимизировать эти промежутки простоя либо полностью исключить их. Также мы можем оценить эргономичность выдачи. Пользователю ничего не должно мешать получать ту информацию, за которой он пришел, из результатов выдачи. Ничто не должно отвлекать его. Он не должен пробираться через дебри нашего дизайна, чтобы найти то, за чем он пришел. Далее, мы должны оценить, выполняет ли наша поисковая система свои цели. Перед тем как мы создавали поисковую систему, мы ставили определенные цели, то есть для чего именно она делалась. Либо это был поиск похожих картинок, которые должны были соответствовать каким-то критериям. Либо, например, это был поиск по правовым документам. В таком случае нам поисковая система должна выдавать полный список документов, который соответствует тому или иному прецеденту. Либо это может быть веб-поиск, который должен выдавать не просто те документы, которые соответствует запросу, но при этом выдавать самые лучшие, самые популярные и самые релевантный из них. Также мы можем оценивать, например, скорость обновления данных. Это важно не для всех систем. Например, это важно для веб-поиска. То есть в случае, если у нас появляются какие-то свежие новости, происходят какие-то события в мире, то пользователь очевидно придет в поисковую систему, для того чтобы узнать, где он может узнать об этих событиях поподробнее. И то, как быстро мы предоставим ему ответ, напрямую влияет на то, насколько довольным будет пользователь нашей системы. Однако, если мы вернемся к поиску по правовым документам, очевидно, что здесь скорость обновления данных может быть не слишком большой и мы можем эту метрику вообще не использовать. Также нам стоит оценить два параметра, которые напрямую не видны пользователю, однако очень важны для нас как для создателей системы. Во-первых, это затраты на индексацию и переиндексацию, если таковая будет. Так как это, в общем-то, часть компонент поисковой системы, которая стоит несколько в стороне от основного процесса и затраты на нее должны обсчитываться отдельно. Ну и кроме того, нужно учитывать затраты на поддержание всей нашей системы, так как система должна постоянно совершенствоваться, чтобы отвечать все новым и новым требованиям пользователя, расширяться и улучшаться. [БЕЗ_ЗВУКА]
