Размышления о pfound

[alsafr]

На РОМИП-2009 Яндекс рассказал про метрику pfound, предназначенную для оценки качества поиска. По словам Павла Карповича, эта метрика "хорошо себя зарекомендовала". Насколько я понял из ответов Павла, в Яндексе считают, что pfound лучше стандартных метрик РОМИП прогнозирует удовлетворенность живого пользователя результатами поиска.

Что же из себя

Comments

[n0mad_0]

У меня есть некоторые сомнения в том, что нужно "развивать" модель.

1. Зачем завязываться на размер выдачи? Многие поисковые машины разрешают запрашивать и 50 и 100 документов. Некоторые (бесконечная выдача поиска по картинкам bing, вторая страница Я.Картинок со скроллером) вообще имеют безстраничную выдачу. Мне кажется, наличие "страниц выдачи" - упячка (обусловленная технической реализацией) и лучше избавится от страничной выдачи, чем тянуть ее наличие в метрики.

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

Я, конечно, не очень в теме, но вот такие у меня соображения =)

[n0mad_0]

Хотя пункт (2) возможно неверен.
(0.85)^21 = 0.033. Похоже, результаты на 2-й странице слабо влияют и при наличии разрыва и без =)

[alsafr]

> лучше избавится от страничной выдачи, чем тянуть ее наличие в метрики

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

> более гладкие функции попроще оптимизировать

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

> У меня есть некоторые сомнения в том, что нужно "развивать" модель

У меня тоже есть сомнения) это были просто мысли вслух.

[n0mad_0]

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

Я скорее про сложность работы процедуры численной оптимизации (устойчивость результатов, скорость сходимости, etc). Хотя тут мои знания более чем поверхностны и скорее философские =)

[alsafr]

Насколько я понимаю, здесь важно различать документ, помеченный асессором как релевантный, и документ, который сочтет релевантным пользователь.
Таким образом, и мое, и ваше высказывание являются верными:
Если i-й документ помечен асессором как релевантный, то пользователь либо тоже сочтет его релевантным, либо не сочтет. Если пользователь согласится с оценкой асессора, то в модели pfound это обязательно приведет к остановке просмотра. Иначе просмотр продолжится. Таким образом, вероятность просмотра документа (i+1) действительно ниже, если i-й документ помечен асессором как релевантный.

=)

[n0mad_0]

Вот лично мне очень интересно какую метрику можно (и нужно ли отдельную?) и лучше использовать для поиска по картинкам? Вот например ее не читают сверху вниз и pfound не подходит.

Re: =)

[hr0nix]

М.б. pN? Или DCG? Привет из будущего!

Re: =)

[n0mad_0]

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

совсем не затухать (p@n) тоже как-то странно. т.е. это p@5 метрика, если у нас выдача в 5 картинок (типа колдунщик), а для самой выдачи....

С одной стороны, раз смотрят глубоко, должно быть p@200, а с другой 200 - уже много, чтобы считать, все позиции одинаково полезны. т.к. пользователь не увидит все 200 картинок сразу.

Re: =)

[hr0nix]

Ну вот DCG как раз может затухать ме-е-е-едленно-о-о-о-о.

[lpauzner]

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

[anonymous]

>Хотя в статье об этом и не сказано, очевидно, что pLook(1) должен быть равен 1.
Должен быть равен, но не может быть равен. Иначе топ1 получал бы 100% кликов от введенного запроса, а всем известно, что это не так, особенно по коммерческим запросам

[alsafr]

Дело в том, что в описанной модели не учитывается существование сниппетов. Модель предполагает, что поисковая выдача состоит из самих документов. Вначале пользователю показывается целиком самый первый документ, после чего пользователь либо переходит к следующему документу, либо самоаннигилируется.
Поэтому в такой модели вероятность просмотра первого документа равна 1. Или же 1-pBreak в зависимости от того, допускаем ли мы самоаннигиляцию пользователя до просмотра первого документа.

[anonymous]

тогда согласен....спасибо за объяснение