About News track

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

Re: [romip] Re: About News track

Postby neigor » Sun May 08, 2005 4:54 pm

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

Я и не предлагал рассматривать все задачи сразу.
Что хочется - хочется отталкиваться от естетственных проблем,
из них следуют естественные критерии качества, понятные асессорам.

> Например, примерно в половине случаев для пользователей я.новостей
> лицом кластера
> является _только_ заголовок -- для тех, кто кликает на них с главной
> странице яндекса, а также тех, кто кликает их из яндекс.почты и других
> -- внешних -- мест, типа http://www.novgorod.ru (правая колонка).
>
> В этом случае у задачи выбора "лица" есть ряд особенностей:
>
> а) Заголовок должен быть взят от сообщения, которое достаточно хорошо
> представляет состояние сюжета на текущий момент
> б) Заголовок должен быть взят от сообщения от "достаточно хорошего"
> агентства (оценка агентств -- отдельная история)
> в) Заголовок должен быть не слишком длинным и не слишком коротким
> г) Есть проблема "жареных" заголовков, когда редактор _намеренно_
> делает заголовок "не соответствующим содержанию документа"
> (и, след-но, кластера) Реальные примеры: 'В Норильске найден труп
> Абрамовича'
> (не губернатора Чукотки), 'Москва ждет атаки с запада'
> (сообщение об атмосферном фронте) и т.п.
> -- и т.п.
>
> Например, в последнем случае подход, основанный на "ожидаемости для
> пользователя" может сильно оштрафовать систему, которая сделала
> точный и полный кластер, но выбрала "жареный" заголовок.
> При том, что, вообще говоря, с "жареными" заголовками
> полностью автоматически бороться, imho, очень
> трудно, если вообще возможно ...
>
> Поэтому мне не нравится идея привязывать оценку разбиения новостного
> потока на сюжеты к оценке его "лица".

в описанном мною подходе "лица" использовались лишь для
отбора сообщений, на основе которых формируются пулы

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

То есть в предложенном подходе оценки это просто некое представительное
сообщение для данного сюжета.

> У я.новостей одна из основных задач -- формирование актуального
> списка 'главных событий дня'
> -- в виде топ-5 (или 15, то же самое по темам). Там потери полноты
> чреваты тем, что в топе могут оказаться
> несколько кластеров, посвященных одному событию,
> что воспринимается как серьезная ошибка системы.
>
> Но ранжирование сюжетов -- опять-таки, отдельная задача ...

согласен, в этом году это видимо нереально.
Но построить список задач заранее, чтобы можно было думать
о том как оценивать и искать заинтересованных в участии
очень полезно :)

> > По идее мерять надо как раз проблемы и соответственно задача асессорам
> > выявить эти проблемы.
> >
> > > Так все-таки есть у кого-то ясность как будет "оцениваться" новостная
> > > дорожка?
> >
> > А как насчет следующей вариации на тему пулинга:
> >
> > 1) От каждой системы берем N кластеров. У каждого кластера есть сообщение
> > "лицо", которое система выбирает сама по своим принципам.
> > 2) Для каждого отобранного "лица" строим пул -
> > объединение всех кластеров всех систем куда попало это сообщение
>
> а) Есть опасность, что будут получаться очень большие пулы.
> Причем чем больше участвует систем, тем больше пулы.
> Кроме того, опасно наличие "агрессивных склеивателей" среди
> систем-участников, типа нынешней Новотеки.
> Кроме того, опасны документы-"дайджесты": если хотя бы один алгоритм
> окажется неустойчивым к дайджестам, то получим большие и неадекватно
> склеенные пулы.

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

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

> Можно отойти от идеи объединения кластеров, и строить пулы на основе
> чего-нибудь вроде кворума. Тогда придется мириться с неполнотой ...

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

Вообще, я не против "полного эталона".
Более того, мне очень интересно сравнить выводы на основе пулинга и полного
эталона, поскольку понятно что на большие коллекции полный эталон все-таки
не масштабируется.

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

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

> б) Может получиться, что одному и тому же событию нередко будет
> соответствовать около N одинаковых пулов, где N - число систем
> (системы построили похожие кластеры, но почти все "лица" -- разные)
> Асессору в разные моменты времени может попасться несколько пулов,
> соответствующих одному и тому же событию ( и каждый раз будут разные
> версии кластера ;-) )

да конечно.
Более того, поскольку каждый пул оценивает >1 асессора обычно, то
разные версии будут все равно.

Однако, поскольку задача асессору ставится более простая, то тут
можно строить сильные/слабые версии идеального кластера на основе кворума.

Для более общей задачи - разбиения всего множества, мне не очень понятно как
делать кворумы - нет опорных точек.

> > 3) Асессор оценивает этот пул на предмет "выбора подмножества сообщений
> > относящихся к этому же сюжету что и заданное заглавное".
> > Оценка по шкале как предлагал Илья -
> > входят ли они в один сюжет, в один надсюжет, или вообще на разную
> тему
> > Но производится она не для пар сообщений, а асессору дается список,
> > который надо рассортировать.
> >
> > Оценки - сравнение эталонных кластеров с кластерами в ответе.
> >
> > Мы не получим полного эталона
> > но получим несколько "эталонных кластеров" для каждого из лиц.
> > рассхождения между асессорами конечно будут, но есть надежда что
> > в таком случае разные варианты будут сильно пересекаться
> > (ну и всегда можно вспомнить про сильные/слабые требования :)
> >
>
> В общем, это некий гибрид построения эталона и метода "общего котла".

точно :)

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

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

> Во-вторых,
> привносят недостаток -- опасность потери полноты, если все
> системы ошибутся по полноте (в рассматриваемой задаче это, imo,
> вполне реально)

согласен, проблемы с полнотой могут возникнуть везде где оценка частична

> б) Кроме того, Борис опять скажет, что неполный эталон легко накрутить ;-)

не совсем понятно как,
ведь заранее неизвестно что будет оцениваться.
При повторном использовании готовых оценок - конечно, но это верно и для
полного эталона.

про недостатки пулинга мне надо еще подумать,

-igor
neigor
Оргкомитет
 
Posts: 331
Joined: Sat Feb 08, 2003 2:06 pm

Re: [romip] Re: About News track

Postby igor_kuralenok » Thu Jun 23, 2005 7:44 pm

Доброе всем время суток!

Мне хотелось бы возобновить обсуждение по оценке новостной дорожки, так
как остается совсем немного времени до того как эту самую оценку надо
будет проводить. Просмотрев ваши предложения я решил тоже поизобретать
велосипед, который далее и привожу:

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

Вторая же часть мне представляется следующей.
Упорядочим события по времени (временем события обзовем время первого
сообщения о нем). Известно, что это время может не соответствовать
реальности, но это, при небольшой доле таких случаев, не повлияет на
эффективность алгоритма.
Будем предлагать события пользователю в этом порядке последовательно.
Для каждого сообщения пользователь сможет связать текущее событие с
любым уже произошедшим, с нашей точки зрения. При этом ему в качестве
вариантов для рассмотрения будут автоматически предложены некоторые
связи. Варианты будут выбираться из следующих условий:
-- пренадлежности текущего события и предлагаемого или связанного с ним
к одному кластеру в результатах какой либо из систем
-- не связанности предлагаемых событий в имеющихся результатах (которые
пользователь задает указывая связи)
-- из всех возможных вариантов выбираются наиболее близкие по времени.
Результатом такой работы будут являтся комопоненты связности полученного
графа.

Я понимаю, что это объяснение достаточно путано, поэтому попытаюсь
пояснить на примерах.

пусть есть ответ одной системы, который связывает события следующим образом:
1 4
2
3 5 8
6 7 9 10

номера событий представляют собой номера в упорядочивание

для 1 события пользователю предлагать нечего,
для 2-го 3-го тоже
пускай пользователь не согласился и связал 3 с 1
для 4 предлагаем 3, так как 4 с 1пренадлежат одному кластеру,
пользователь связал 3 и 1, 3 ближе к 4-м.
в этом случае положим, что пользователь согласился с предлагаемой связью
5: 4, так как 1 3 4 связаны, 4 - ближайшая
не согласился. Имеем кластеры: (1 3 4) (2) (5)
6: нет вариантов
связал с 2, кластеры (1 3 4) (2 6) (5)
7: 6
связал с 1, кластеры (1 3 4 7) (2 6) (5)
8: 7, 5
связал с 7, кластеры (1 3 4 7 8) (2 6) (5)
9: 8, 6
оставил без связей, кластеры (1 3 4 7 8) (2 6) (5) (9)
10: 9, 8, 6

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

К слабостям отнесу следующее:
-- не все связи, установленные системами попадают на оценку пользователя;
-- при перерыве в работе вероятность установления непредложенных связей
мала, что приводит к неоднородности оценки;
-- надеюсь вы этот список продолжите

Немного длинно, но если вы добрались до сюда, то, надеюсь, меня поняли :).

С уважением,
IK
igor_kuralenok
Оргкомитет
 
Posts: 21
Joined: Fri Oct 03, 2003 7:24 am

Previous

Return to Экспериментальные дорожки

Who is online

Users browsing this forum: No registered users and 0 guests

cron