официальный http://company.yandex.ru/news/press_releases/2010/1215/index.xml
в блоге http://clubs.ya.ru/company/replies.xml?item_no=32028
Общие мысли:
1. в метрике pfound не заложено никакого “разнообразия” для оценки качества выдачи. т.е. то, что она разнообразная, эту метрику не повысит.
Следовательно, есть другая метрика, по которой меряется качество. Логично, что в яндексе есть несколько групп людей, каждая из которых продвигает в мозг начальства свою метрику. Для того, чтобы выглядеть длиннее, нужно выбрать удобных попугаев.
Видимо, происходит отказ от метрики pfound, пока что в виде навешивания сверху рюшечек (разнообразия).
Частные:
1. по набору однословников (а там каждый достоин своего спектра) навскидку около 20-30% “оспектрены”, остальная масса – нет. Т.е., еще грядут большие перемены.
2. отдельные потребности в спектре не пересекаются, но иногда явно разные потребности слеплены в одну. Например, в ноутбуках продажа и б.у. – не пересекаются, а в автомобилях – все свалено в одну кучу (б.у., продажа, отзывы, фото, характеристики, т.д.) Обидно оптимизировать – их разделят ведь потом, а выдачу надо сейчас 🙂
3. есть несколько разных видов расширения запроса – олдовые переформулировки, которые можно вычислить исключением слов, и спектровые, которые исчезают при малом изменении запроса.
4. спектр подсвечивает только в топ10 и нумдоком не обманывается. Подсвечивает в топ10, но работает и глубже.
5. надыбал десяток оспектренных запросов, по которым мониторю выдачу – потом посмотрю, не спектр ли начал выкатываться 20-го ноября. Наверное, он, вряд ли тут две сущности ))
6. есть ли спрос на пробивку и поставку в народ разбиения спектровых тематик? 🙂
7. встречаются явно дурацкие спекторвые слова – типа: “википедия”, “что такое”. Да, явно берется не из текстов, а из запросов.
Твое "следовательно" не катит.
Во-первых, оптимизировать можно точно так же по pFound, какая разница, разнообразная выдача, или нет?
Во-вторых, pFound можно легко доработать до pFound+, учитывая еще вероятности, с которыми ищется тот или иной вариант ответа и аналогично откалибровав обучающую выборку. Только тут скорее всего получится облом, т.к. обучалово строилось годами без таких намеков и скорее всего полнота по вариантам на сегодня совсем херовая.
На самом деле ты не учел того факта, что яндексоиды очень любят все пересчитывать, потому они считают не только pFound, но и еще дохрена других, стандартных метрик. Тот же афтар "Спектра" Плахов написал в "Моем круге":
По pFound они оптимизируют подгонку ("машинное обучение"), но считают качество по многим метрикам, и не только свое качество. 🙂
-нет, нельзя. разница такая, что любое изменение "оптимальной" по метрике pfound выдачи – будет уменьшать этот pfound.
-это и будет другая метрика, которая совсем не pfound, а как ты ее назовешь – твое личное дело :).
Нихрена, если подмешанные размечены теми же оценками, что и те, вместо которых они влезли, то pFound не изменится.
Это будет именно pFound, просто вероятности в формуле другие. Они и сейчас там другие, т.е. pFound, применяемый в Яндексе отличается от pFound, описанный в метриках РОМИПа-2010.
-ага, а если у бабушки будет хуй, то она будет дедушкой. Чисто случайно размечены. Т.е. мы оптимизируем по метрике pfound, но смотрим на какое-то другое качество, которых много. Мы его так хитро оптимизируем, чтобы он еще не изменялся.
-А!!! любая метрика является на самом деле pfound, только данные используются другие и арифметические знаки расставлены не в том порядке.
Бабушкин хуй тут ни при чем.
На самом деле документов в обучающей и тестовой выборках, размеченных так же, как и те, которые попали в топ-10 на обучении или на тесте – значительно больше, чем 10. И среди них вполне могут быть документы с разными вариантами ответов на вопрос юзера. Если такие попадают в топ – pFound не ухудшится.
Не, не любая. pFound вычисляет качество выдачи, исходя из вероятностей того, что юзер посмотрит на документ, кончит на нем довольный или уйдет кончать в гугл. 🙂
Т.е. 3 вероятности для документа, которые как-то рассчитываются для каждой позиции в топе, на самом деле пох, как. И если мы берем и немного изменяем форму расчета вероятностей для документа (а не метрики!), то получаем тот же pFound, по сути. А вероятности мы изменяем потому, что вместо одного юзера по запросу мы теперь привели в выдачу несколько юзеров, с разными хотелками ответа. 🙂
-это как будто бы ты говоришь – дважды два равно девять! А потом уточняешь: ну ведь два вполне может быть равно трем? Если два равно трем – то действительно будет девять. что и требовалось доказать ))
А в общем случае, без "если" – ухудшится.
-а если мы заменим плюсики на минусики и умножить на разделить, мы получим тот же самый pfound, по сути, так ведь?
Другое нужно и называть другим, а не тем же самым, но чуток скособоченным.
Но, и вообще – тебе никакими выкрутасами не удастся пристегнуть pfound, который основан на pointwise подходе, к СПЕКТРу, который должен быть listwise.
А в общем случае – хз, может и улучшится. 😀
Ну вот смотри, давай предположим, что если матрикснет вычисляет для документа релевантность 1.0 + х, то при х больше некоторого значения документ реально релевантен запросу с большой вероятностью, например 98%. Мы берем тестовое множество, на котором все ответы размечены и смотрим, сколько у нас ответов с релевантностью > 1.х. Если их больше 10, то раньше нам было важно, чтобы часть из них тупо заполнила первую десятку выдачи, а теперь задача немного усложнилась – нам нужно разнообразить. Разнообразие размечается автоматом. Теперь, уже после матрикснета, мы смотрим на все такие документы с релевантностью >1.х, и пытаемся построить из них разнообразную выдачу какими-то финтами. Т.к. что раньше, что сейчас, документы у нас релевантны на 98% в среднем, то качество выдачи будет примерно на том же уровне, плюс/минус. Если релевантных-разнообразных не нашлось – значит и не втыкаем ничего, не зависимо от хотелок юзеров.
В итоге, если считать качество по прежней метрике pFound, то все останется более-менее так же.
Ну бля, тебе видимо лениво было прочитать описание метрики? Придется скопировать:
Дык вот – это формула, применявшаяся в этом году на РОМИПе. Заметь, что PLook вычисляется, а PRel определяется заранее. На РОМИПе его определили по простецки, потому что иначе было никак. В Яндексе оно определяется гораздо более хитро, т.к. есть огромная качественная стата, а задавая разные вопросы пользователи ведут себя по разному. Где-то они просматривают в среднем много документов по-любому, а где-то им достаточно первого релевантного. Т.е. PRel в Яндексе уже давно зависит от запроса (якобы).
Теперь мы усложняем задачу оценщика качества – у нас вопрос задает уже не один юзер, а скажем два, их вероятности р1 и р2 (р1+р2=1). И им нужны разные варианты ответа. Как для этого переделать ромиповский вариант PRel – разберется даже студент младших курсов. 🙂
Мы получим тот же самый pFound, с измененной формулой расчета PRel.
тупку продолжаем тут