У меня складывается впечатление, что процесс обсуждения
правил оценки задачи "разбиения на сюжеты" сходится,
но я пока не понимаю, сколько у нас желающих на эту постановку?
Желание участвовать в дорожке новостного поиска было высказано в заявках:
- RCO
- SearchInform
- Поиск@Mail.ru
Но интересна ли эта постановка или нет мне пока непонятно.
Прошу уточнить этот момент (как и высказаться других потенциальных желающих).
> Например, когда оцениваешь группу, скажем, из 10 достаточно
> близких новостных сообщений, то одну-две из первых --
> от первоисточников -- действительно прочитываешь.
> Но дальше нередко происходит не "чтение", а "сканирование"
> на предмет обнаружения сходства с первыми прочитанными.
Безусловно, процесс принятия решения убыстряется, но не до 0.
Но все равно просмотреть надо все и следовательно
есть среднее время на документ (все равно численная оценка скорости была с
потолка :).
> Об альтернативном пулинге.
> Igor > 1) Берем 1 "среднестатистическую" ленту (я так полагаю
> > ~50-100 сообщений в день и 400-1000 за неделю?)
>
> Если я правильно понял, лентой называется поток сообщений
> от одного агентства.
>
> Этой идея правильная - хорошее агентство дает
> более-менее полную картину,
> и мы можем зафиксировать все значимые события.
> Но из дальнейшего следует, что только
> этой лентой при построении эталона мы и ограничиваемся.
> Это как-то неправильно --
> зачем тогда оставшаяся часть коллекции?
При выделении сюжетов/событий, вообщем да.
А потом мы проверяем как сообщения из других потоков
"отображаются" на выделенные события.
Конечно так могут быть выделены не все события.
Это конечно минус, но может быть пропущено будет не так много?
В конце концов если останется много выделенных системами
событий, которые не пересекаются с "эталонными", то
эти события можно отдельно доценить.
Плюс:
мы делим оценку на два шага:
- выделение эталонного множества событий
- проверка качества классификации новостей по эталонным событиям
При использовании одного и того же эталона понятно как сливать оценки разных
асессоров (сильная/слабая релевантность).
А для того, чтобы построить единый эталон можно получить
его независимые варианты от двух асессоров,
потом их слить и попросить их же оценить разницу для разрешения конфликтов.
Кстати интересноб насколько субъективно разные люди выделяют события ...
> Потом, самое хорошее агентство в этой коллекции --
> это Регнум, который дает половину всего потока.
> Не спорю, экономия заметная. Но Регнум имеет специфику --
> уклон в региональные новости.
>
> Следующий -- 20% -- Росбалт. Тоже не очень типичный --
> северо-западный регион + много аналитики.
>
> Остальные еще более специфические, и по ним
> я бы уж точно не стал ...
Выбор хорошего потока действительно проблема.
> Igor > 2) Асессор просматривает эту ленту и сортирует сообщения по
> > замеченным им событиям. Так, как это делают с почтой,
> > раскладывая ее по папкам.
>
> Здесь наверное, тоже будет происходить "потеря контекста",
> поскольку сообщения
> не сгруппированы по сходству, просто отсортированы
> по времени, видимо. Но, конечно, эта потеря меньше,
> чем при попарном пулинге.
согласен.
поскольку задача ставится как "рассортировать", то можно пользователю
предложить несколько разных вариантов группировки (как это делает почтовый
клиент) - по времени, по "тематической схожести", ...
> Igor > 3) Все созданные папки с >2 документов считаем найденными
> > "идеальными сюжетами".
>
> Imho, все-таки не хватает еще одного этапа -- объединить
> некоторые сюжеты в более крупные -- если принять
> за основу определение события из TDT.
ok, папки могут быть вложенными.
В принципе асессор может сам решать когда заводить второй уровень
- сразу или потом. (больше двух уровней нам ведь не надо?)
Откладывание этого "на потом" может привезти к появлению слишком широких
папок первого уровня - когда пользователь заводит их для сюжета, а не
события.
> Кроме этого, я говорил, что можно ограничить
> объем работы, оценивая только самые важные события.
Кстати, получая эталонные события из одной ленты,
мы скорее всего не пропустим самые важные события,
но также захватим и какое-то количество менее важных.
> Igor > Проблемы тут следующие:
> > - Большие неделимые куски работы
> > (как минимум один асессор должен смотреть всю неделю,
> > а это 165 часов (человекомесяц))
>
> Я вот подумал, что неделю для первого этапа
> агломеративного построения вполне
> можно разделить -- по времени: условно
> говоря, одному -- понедельник-вторник,
> второму -- среда-четверг, третьему -- остальное.
> Сюжеты ведь в основном локализованы по времени.
> Ясно, что некоторые сюжеты пересекают такие границы.
>
> Но полного объединения сюжетов на первом этапе не
> требуется, окончательное "сшивание" сюжетов
> все равно будет на втором.
да, это может сработать если
выделение событий окажется не слишком субъективным и разные асессоры не
будут их выделять сильно по разному.
Кстати, сшивание событий может оказаться дорогим,
ведь тому кто будет их сшивать придется познакомиться
с событиями за другие дни (=> прочесть сколько-то сообщений из каждого
кластера)
-igor