Размышления о pfound
На РОМИП-2009 Яндекс рассказал про метрику pfound, предназначенную для оценки качества поиска. По словам Павла Карповича, эта метрика "хорошо себя зарекомендовала". Насколько я понял из ответов Павла, в Яндексе считают, что pfound лучше стандартных метрик РОМИП прогнозирует удовлетворенность живого пользователя результатами поиска.
Что же из себя представляет pfound? Рассмотрим модель, в которой пользователь последовательно просматривает выдачу сверху вниз в поисках релевантных документов. Этот просмотр прекращается в том случае, если пользователь встретил удовлетворяющий его документ, либо если ему просто надоело. Метрика pfound в этой модели оценивает вероятность найти релевантный документ.
где:
pRel - релевантность i-того документа (принимает значение 0.4, если асессор пометил документ как релевантный).
pLook - вероятность просмотра i-того документа в выдаче;
pBreak - вероятность того, что пользователь прекратит просмотр по каким-то внешним причинам. Принимается равной 0.15.
Хотя в статье об этом и не сказано, очевидно, что pLook(1) должен быть равен 1.
Далее идут уже мои размышления о том, как можно модифицировать pfound. Попробуем немного усложнить модель, лежащую в основе метрики. Прежде всего, посмотрим на константу pBreak. Вероятность того, что пользователь прекратит просмотр результатов потому что ему надоело (или у него больше нет времени, или у него кончился интернет...), считается одинаковой на протяжении всей поисковой выдачи. Но можно выдвинуть гипотезу, что при постраничном просмотре результатов это не совсем так. Переход между страницами с результатами поиска требует от пользователя больше усилий, чем перенос внимания между сниппетами на одной странице. Если это предположение справедливо, то модель можно улучшить, добавив в нее учет переходов между страницами. Для этого заменим константу pBreak на функцию pBreak:
Оператор "%" используется здесь для обозначения операции по взятию остатка от целочисленного деления. Значение константы pLineBreak должно быть меньше, чем pPageBreak. С помощью этой модификации мы можем добиться небольшого плавного уменьшения pLook для результатов, расположенных на одной странице, и скачкообразного уменьшения pLook при переходе на следующую страницу.
Далее. Давайте обратим внимание на функцию pRel. Почему для релевантных документов она принимает значение 0.4, а не 1? Значение меньше единицы позволяет учесть те случаи, когда пользователь продолжает просмотр выдачи, даже если он уже нашел документ, который асессоры пометили как релевантный. В каких же случаях пользователь будет продолжать просмотр? Дело в том, что мнение асессора не всегда совпадает с мнением пользователя. Есть некоторая вероятность, что пользователь сочтет документ нерелевантным, даже если асессор пометил его как релевантный. Но чем больше асессоров оценивало документ, тем надежнее эта оценка. Чтобы учесть "надежность" оценки асессоров, представим функцию pRel следующим образом:
где:
nAsessor - количество асессоров, оценивавших документ;
nRelAsessor - количество асессоров, пометивших документ как релевантный;
a - константа.
И еще. Исходная модель pfound предполагает, что пользователь прекращает просмотр поисковой выдачи, когда встречает документ, который он считает релевантным. Однако в реальности это не всегда так. Иногда удовлетворить поисковую потребность пользователя одним документом невозможно. Например, по коммерческим запросам пользователь скорее всего просмотрит достаточно много релевантных документов, чтобы выбрать лучшее предложение. Для навигационных же запросов достаточно одного релевантного документа. Возможно, вероятность просмотра следующего документа после релевантного как-то связана с общим количеством релевантных документов в коллекции. Было бы здорово учитывать в модели и это, но как именно это сделать - я пока не могу сказать.
Что же из себя представляет pfound? Рассмотрим модель, в которой пользователь последовательно просматривает выдачу сверху вниз в поисках релевантных документов. Этот просмотр прекращается в том случае, если пользователь встретил удовлетворяющий его документ, либо если ему просто надоело. Метрика pfound в этой модели оценивает вероятность найти релевантный документ.
где:
pRel - релевантность i-того документа (принимает значение 0.4, если асессор пометил документ как релевантный).
pLook - вероятность просмотра i-того документа в выдаче;
pBreak - вероятность того, что пользователь прекратит просмотр по каким-то внешним причинам. Принимается равной 0.15.
Хотя в статье об этом и не сказано, очевидно, что pLook(1) должен быть равен 1.
Далее идут уже мои размышления о том, как можно модифицировать pfound. Попробуем немного усложнить модель, лежащую в основе метрики. Прежде всего, посмотрим на константу pBreak. Вероятность того, что пользователь прекратит просмотр результатов потому что ему надоело (или у него больше нет времени, или у него кончился интернет...), считается одинаковой на протяжении всей поисковой выдачи. Но можно выдвинуть гипотезу, что при постраничном просмотре результатов это не совсем так. Переход между страницами с результатами поиска требует от пользователя больше усилий, чем перенос внимания между сниппетами на одной странице. Если это предположение справедливо, то модель можно улучшить, добавив в нее учет переходов между страницами. Для этого заменим константу pBreak на функцию pBreak:
Оператор "%" используется здесь для обозначения операции по взятию остатка от целочисленного деления. Значение константы pLineBreak должно быть меньше, чем pPageBreak. С помощью этой модификации мы можем добиться небольшого плавного уменьшения pLook для результатов, расположенных на одной странице, и скачкообразного уменьшения pLook при переходе на следующую страницу.
Далее. Давайте обратим внимание на функцию pRel. Почему для релевантных документов она принимает значение 0.4, а не 1? Значение меньше единицы позволяет учесть те случаи, когда пользователь продолжает просмотр выдачи, даже если он уже нашел документ, который асессоры пометили как релевантный. В каких же случаях пользователь будет продолжать просмотр? Дело в том, что мнение асессора не всегда совпадает с мнением пользователя. Есть некоторая вероятность, что пользователь сочтет документ нерелевантным, даже если асессор пометил его как релевантный. Но чем больше асессоров оценивало документ, тем надежнее эта оценка. Чтобы учесть "надежность" оценки асессоров, представим функцию pRel следующим образом:
где:
nAsessor - количество асессоров, оценивавших документ;
nRelAsessor - количество асессоров, пометивших документ как релевантный;
a - константа.
И еще. Исходная модель pfound предполагает, что пользователь прекращает просмотр поисковой выдачи, когда встречает документ, который он считает релевантным. Однако в реальности это не всегда так. Иногда удовлетворить поисковую потребность пользователя одним документом невозможно. Например, по коммерческим запросам пользователь скорее всего просмотрит достаточно много релевантных документов, чтобы выбрать лучшее предложение. Для навигационных же запросов достаточно одного релевантного документа. Возможно, вероятность просмотра следующего документа после релевантного как-то связана с общим количеством релевантных документов в коллекции. Было бы здорово учитывать в модели и это, но как именно это сделать - я пока не могу сказать.