Сроки

Общие обсуждения - потенциальные будущие дорожки, использование материалов РОМИП вне семинара, очные встречи и прочие вопросы для которых нет отдельной подтемы

Re: [romip] поиск по Веб

Postby segalovich » Tue May 29, 2007 2:28 pm

Igor Kuralenok пишет:
> Кстати, как вам идея уменьшить
> глубину оценки (например до 14-15) и увеличить количество оцененных
> запросов? Было бы здорово оценить не 60 - 80 запросов а 200-300.

Maxim Gubin пишет:

>> Конечно, если мы имеем огромные коллекции с таким большим количеством
>> релевантных документов запросу, что они не помещаются ни в какие пулы, то
>> bperf - вполне разумная мера, но на текущих РОМИП коллекциях до этого пока
>> далеко. Или я не прав?

Я все про bpref.

Если мы примем предложение Игоря (к которому я присоединяюсь)
оценивать много (не менее 200?) запросов, но НЕ глубоко, при этом
выставляя максимально надежные (релевантные и нерелевантные) оценки в
небольшом колчиестве на запрос, то метрика bpref покажется существенно
более обоснованной: она меньше зависит от глубины (полноты) оценки пула,
так как опирается на отношения порядка по оцененным парам.

Дискуссия - чуть ниже.

> 1. В данном запросе все системы вернули мало релевантных документов. При
> этом, так как в пуле число релевантных документов заниженно, то мы получим
> более высокие оценки полноты, чем есть на самом деле. Это не хорошо, но так
> как любые оценки относительны коллекции, то что в этом страшного, мы все
> равно можем сравнивать алгоритмы.

А зачем нам полнота, если мы считаем bpref?

> 2. Мы сделали новый алгоритм, с лучшей полнотой. При попытке

Постараюсь описать это так, как я понимаю.

В некотором смысле "полнота" (как функция от полного
числа выданных системой "относительно" релевантных документов)
не так уж важна. В условиях веб поиска, больших коллекций etc etc.

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

В предложенной модели (много неглубоко оцененных запросов)
мы заведомо НЕ надеемся получить полный список релевантных
документов.

Зато мы аппроксимируем "умение системы находить релевантные документы" в
самом верху выдачи тем, что штрафуем запросы, в которых система ставит
заведомо нерелевантные (оцененные нами) документы над релевантными.

Это, по сути, и есть идея bpref от Buckley & Voorhees.

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

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

Ждать следующего цикла оценки - дорого и долго.

Кроме того, в классической модели (когда новые документы приравнены к
оцененным нерелевантным документам) трудно сравнивать две новые системы
между собой.

Поясню мысль.

Пусть R - релевантный, N - нерелвантный, а ? - не оцененный документ.

Система A выдала документы в таком порядке: ??RRNN???..
Система B выдала документы в таком порядке: NNRR?????..

bpref накажет систему B, традиционные метрики посчитают системы
одинаковыми. ... these measures [R-precision, MAP, and P(10)]
make no distinction in pooled collections
between documents that are explicitly judged as nonrelevant
and documents that are assumed to be nonrelevant because
they are unjudged ..

Если посмотреть на поисковые конференции, которые измеряют точность, то
можно увидеть bpref уже в 33 публикациях на ACM
google:[site:portal.acm.org bpref]

Илья
segalovich
Оргкомитет
 
Posts: 46
Joined: Fri Jan 31, 2003 1:21 pm

RE: [romip] поиск по Веб

Postby maxgubin » Wed May 30, 2007 5:46 am

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

Я согласен, что пользователю не важно, сколько есть релевантных документов
на тему, не согласен что помещение любого релевантного "вперед" -
однозначный плюс. Реально выдачу, по моему мнению, можно разделить на 3
части:
1. Vital - полная информация, авторитетные источники. То, что желательно
"засунуть" в первую 10-ку, 5-ку. При этом абсолютное место не столь важно -
они охватываются одним взглядом.
2. Relevant - группа содержащая информацию по запросу. Тут сами документы не
важны, обычно пользователь их не смотрит, важно сколько их, потому что из
этого делается вывод о популярности темы и необходимости переформулировать
вопрос. Опять же порядок не столь критичен, скорее случаен.
3. Nonrelevant - те, кто портят первые 2 списка.


Мне как раз казалось, что это деление замечательно совпадало с тем, как
оценивал РОМИП ранее. Только я собрался это поиспользовать, как времена
прошли :). Хотя в этом году с вероятностью 75% все равно не успею
поучаствовать.

Понятно, что с ростом коллекций "полные" метрики заменятся на "неполные",
что делать - раз есть такая тенденция, давайте следовать.

Максим






Re: [romip] поиск по Веб

Igor Kuralenok пишет:
> Кстати, как вам идея уменьшить
> глубину оценки (например до 14-15) и увеличить количество оцененных
> запросов? Было бы здорово оценить не 60 - 80 запросов а 200-300.

Maxim Gubin пишет:

>> Конечно, если мы имеем огромные коллекции с таким большим количеством
>> релевантных документов запросу, что они не помещаются ни в какие пулы, то
>> bperf - вполне разумная мера, но на текущих РОМИП коллекциях до этого
пока
>> далеко. Или я не прав?

Я все про bpref.

Если мы примем предложение Игоря (к которому я присоединяюсь)
оценивать много (не менее 200?) запросов, но НЕ глубоко, при этом
выставляя максимально надежные (релевантные и нерелевантные) оценки в
небольшом колчиестве на запрос, то метрика bpref покажется существенно
более обоснованной: она меньше зависит от глубины (полноты) оценки пула,
так как опирается на отношения порядка по оцененным парам.

Дискуссия - чуть ниже.

> 1. В данном запросе все системы вернули мало релевантных документов. При
> этом, так как в пуле число релевантных документов заниженно, то мы получим
> более высокие оценки полноты, чем есть на самом деле. Это не хорошо, но
так
> как любые оценки относительны коллекции, то что в этом страшного, мы все
> равно можем сравнивать алгоритмы.

А зачем нам полнота, если мы считаем bpref?

> 2. Мы сделали новый алгоритм, с лучшей полнотой. При попытке

Постараюсь описать это так, как я понимаю.

В некотором смысле "полнота" (как функция от полного
числа выданных системой "относительно" релевантных документов)
не так уж важна. В условиях веб поиска, больших коллекций etc etc.

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

В предложенной модели (много неглубоко оцененных запросов)
мы заведомо НЕ надеемся получить полный список релевантных
документов.

Зато мы аппроксимируем "умение системы находить релевантные документы" в
самом верху выдачи тем, что штрафуем запросы, в которых система ставит
заведомо нерелевантные (оцененные нами) документы над релевантными.

Это, по сути, и есть идея bpref от Buckley & Voorhees.

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

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

Ждать следующего цикла оценки - дорого и долго.

Кроме того, в классической модели (когда новые документы приравнены к
оцененным нерелевантным документам) трудно сравнивать две новые системы
между собой.

Поясню мысль.

Пусть R - релевантный, N - нерелвантный, а ? - не оцененный документ.

Система A выдала документы в таком порядке: ??RRNN???..
Система B выдала документы в таком порядке: NNRR?????..

bpref накажет систему B, традиционные метрики посчитают системы
одинаковыми. ... these measures [R-precision, MAP, and P(10)]
make no distinction in pooled collections
between documents that are explicitly judged as nonrelevant
and documents that are assumed to be nonrelevant because
they are unjudged ..

Если посмотреть на поисковые конференции, которые измеряют точность, то
можно увидеть bpref уже в 33 публикациях на ACM
google:[site:portal.acm.org bpref]

Илья





Yahoo! Groups Links
maxgubin
Оргкомитет
 
Posts: 86
Joined: Fri Jul 04, 2003 3:54 am

Re: [romip] поиск по Веб

Postby igor_kuralenok » Wed May 30, 2007 3:03 pm

Привет всем!

Maxim Gubin пишет:
> Да, если делать много неглубоких запросов - придется мерять bperf.
p1, p3, р10 и прочие MAP никто не отменял для систем участниц, а для
сторонних участников проблема и так стоит в полный рост.. Тут думаю
практики со мной согласятся.
> Я не
> против, можно попробовать, посмотрим результаты.
> Я только не согласен с "возможность переиспользовать", потому что
> неоцененными окажется больше документов. Если я имею результаты нового
> прогона вне конференции, я с большой вероятностью не могу уже посчитать
> bperf, потому что могут оказаться неоцененные документы.
>
Я когда-то считал среднюю вероятность релевантности документа на позиции
n в выдаче, так там, кажись, почти экспонента на РОМИП'03. Так что если
выдача не содержит релевантных оцененных документов вовсе то вероятность
их нахрждения в "хвосте" систем участниц - минимальна. Собственно
поэтому я против глубокой оценки. Другой довод - пулы ростут нелинейно
от глубины, что приводит к бОльшей доле нерелевантных оценок от
асессоров, которые для нас практически бесполезны (для большинства
запросов "фоновая" вероятность релевантности ~0, поэтому отсудствие
оценки обычно принимается за "нерелевантно").
> Я согласен, что пользователю не важно, сколько есть релевантных документов
> на тему, не согласен что помещение любого релевантного "вперед" -
> однозначный плюс. Реально выдачу, по моему мнению, можно разделить на 3
> части:
> 1. Vital - полная информация, авторитетные источники. То, что желательно
> "засунуть" в первую 10-ку, 5-ку. При этом абсолютное место не столь важно -
> они охватываются одним взглядом.
>
См. GGT. - первая тройка. 3 документа это мало, так что место - важно.
> 2. Relevant - группа содержащая информацию по запросу. Тут сами документы не
> важны, обычно пользователь их не смотрит, важно сколько их, потому что из
> этого делается вывод о популярности темы и необходимости переформулировать
> вопрос. Опять же порядок не столь критичен, скорее случаен.
>
Неправда твоя. По моим наблюдениям пользователь в основном исходит не из
положительных, а из отрицательных примеров для создания
переформулировки, хотя этот вопрос требует дополнительного исследования,
да и вообще из области сниппетов :). Более того, по распределению
релевантности внутри первой десятки пользователь принимает решение о
переходе на следующую страницу или переформулировке. С точки зрения
скорости интерактивного поиска это очень важный параметр. Поэтому,
кстати, в менее "разумном" ответе пользователь зачастую ходит глубже,
чем в более "разумном" с четким убыванием релевантности. Этот эффект
приводит к тому, что поиск с более контрастной выдаче часто быстрее чем
в более релевантной, но менее контрастной. Короче, по моим наблюдениям
порядок - рулит. Я бы вообще начал контрастность мерить.
> 3. Nonrelevant - те, кто портят первые 2 списка.
>
>
> Мне как раз казалось, что это деление замечательно совпадало с тем, как
> оценивал РОМИП ранее. Только я собрался это поиспользовать, как времена
> прошли :). Хотя в этом году с вероятностью 75% все равно не успею
> поучаствовать.
>
Жаль :(.

IK
igor_kuralenok
Оргкомитет
 
Posts: 21
Joined: Fri Oct 03, 2003 7:24 am

RE: [romip] поиск по Веб

Postby maxgubin » Thu May 31, 2007 6:57 am

Igor Kuralenok пишет:
>Я когда-то считал среднюю вероятность релевантности документа на позиции
>n в выдаче, так там, кажись, почти экспонента на РОМИП'03. Так что если
>выдача не содержит релевантных оцененных документов вовсе то вероятность
>их нахрждения в "хвосте" систем участниц - минимальна. Собственно

Наверное ты прав. Я из своего старого опыта больше, когда по запросу
"подоходный налог" длиннющий хвост релевантных, но не важных документов.
Хотя когда ищу, например, товары в Webe точно так же получается.

Igor Kuralenok пишет:
>См. GGT. - первая тройка. 3 документа это мало, так что место - важно.
Я читал, очень спорно. Это от поисковика зависит, GGT - скорее особенность
конкретного интерфейса и набора запросов, чем общий факт. См. в исходной
статье, у других систем и запросов не совсем так
http://www.checkit.nl/pdf/eyetracking_research.pdf

В любом случае, туда должен попасть vital документы для хорошей системы.


Igor Kuralenok пишет:
> 2. Relevant - группа содержащая информацию по запросу. Тут сами документы
не
> важны, обычно пользователь их не смотрит, важно сколько их, потому что из
> этого делается вывод о популярности темы и необходимости переформулировать
> вопрос. Опять же порядок не столь критичен, скорее случаен.

Не, я не очень точно выразился. Я хотел сказать, что их порядок абсолютно не
важен, все равно как их ранковать. Пользователь ввел "Britney Spears" увидел
сверху статью в wikipedia, биографию в IMDB, смотрит а там еще 15 миллионов
старниц про нее, ага, говорит - про нее много написано как, добавлю-ка
"naked" :), а является ли сайт с фотками в оригинальной выдаче 4 или 155 -
абсолютно все равно.

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

Максим
maxgubin
Оргкомитет
 
Posts: 86
Joined: Fri Jul 04, 2003 3:54 am

семинар в Яндексе

Postby pb » Wed Jun 13, 2007 11:51 am

21 июня 2007 г. (четверг), 17:00-18:30

Douglas W. Oard (http://www.glue.umd.edu/~oard/)
Associate Dean for Research
College of Information Studies
University of Maryland, USA

Title:

Supporting Search in a Multilingual World

Abstract:

The Internet is a vast multilingual commons, and the past decade has
seen a dramatic acceleration of research on the construction of
systems to support multilingual information access. In this talk, I
will describe the key advances in cross-language information retrieval
and machine translation that now enable us to build systems that span
language barriers to some degree for some purposes. With that as
background, I will then step back and look at the problem from the
perspective of an application developer to identify critical gaps in
the present technology that could inhibit adoption in Web and
enterprise search applications.

About the Speaker:

Douglas Oard is Associate Dean for Research at the College of
Information Studies of the University of Maryland, College Park, where
he holds joint appointments as Associate Professor in the College of
Information Studies and in the Institute for Advanced Computer
Studies. He earned his Ph.D. in Electrical Engineering from the
University of Maryland, and his research interests center around the
use of emerging technologies to support information seeking by end
users. Dr. Oard's recent work has focused on interactive techniques
for cross-language information retrieval, searching conversational
media, and leveraging observable behavior to improve user modeling.
Additional information is available at http://www.glue.umd.edu/~oard/.

Язык - английский.

Если вы хотите посетить семинар, пожалуйста, предварительно
зарегистрируйтесь по тел. +7 495 739-7000. Количество мест ограничено.

Место: Яндекс, Москва, ул. Самокатная, дом 1, стр. 21
Как добраться: см. http://company.yandex.ru/inside/contacts.xml

Запись семинара будет выложена в открытый доступ.
pb
Оргкомитет
 
Posts: 72
Joined: Mon Feb 10, 2003 11:52 am

Previous

Return to Общие вопросы

Who is online

Users browsing this forum: No registered users and 11 guests

cron