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

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

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

> >
>
> В общем, это некий гибрид построения эталона и метода "общего котла".
точно

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

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