Добрый день еще раз.
> 1) весьма вероятно "эталонные разбиения" будут сильно различаться
> 2) по идее все-таки важно оценивать, насколько пользователю удобно
> 3) что у агломеративной модели есть ряд недостатков
пп 1-3 -- см. ответ Борису
http://groups.yahoo.com/group/romip/message/488О "ряде недостатков". Imho, по большому счету их два:
1. Затратность построения инструментария для оценок (Маслов,
http://groups.yahoo.com/group/romip/message/408 , первый из раздела
"Недостатки подхода maslov")
2. Проблема обучения асессоров (Добров,
http://groups.yahoo.com/group/romip/message/483 , частично п.1)
> 4) что пока непонятно насколько недостаточно материала в текущей коллекции
Что ж, мы будем продолжать работу по заключению соглашений с новыми
агентствами ...
>
> я не согласен, что из-за этого стоит отказаться от использования человека
> при оценке вообще.
>
> Вообщем-то мне кажется полезной идея про "лицо кластера", ведь
> это то, что пользователь видит прежде чем решает лезть ли дальше в эту
тему.
>
> Какие вообще возникают проблемы у пользователя? Что приходит в голову:
> - польстился на "лицо", а содержимое ему не соответствует
Давайте все-таки разделим задачи -- у формирования "лица" очень много разной
специфики.
Например, примерно в половине случаев для пользователей я.новостей
лицом кластера
является _только_ заголовок -- для тех, кто кликает на них с главной
странице яндекса, а также тех, кто кликает их из яндекс.почты и других
-- внешних -- мест, типа
http://www.novgorod.ru (правая колонка).
В этом случае у задачи выбора "лица" есть ряд особенностей:
а) Заголовок должен быть взят от сообщения, которое достаточно хорошо
представляет состояние сюжета на текущий момент
б) Заголовок должен быть взят от сообщения от "достаточно хорошего"
агентства (оценка агентств -- отдельная история)
в) Заголовок должен быть не слишком длинным и не слишком коротким
г) Есть проблема "жареных" заголовков, когда редактор _намеренно_
делает заголовок "не соответствующим содержанию документа"
(и, след-но, кластера) Реальные примеры: 'В Норильске найден труп
Абрамовича'
(не губернатора Чукотки), 'Москва ждет атаки с запада'
(сообщение об атмосферном фронте) и т.п.
-- и т.п.
Например, в последнем случае подход, основанный на "ожидаемости для
пользователя" может сильно оштрафовать систему, которая сделала
точный и полный кластер, но выбрала "жареный" заголовок.
При том, что, вообще говоря, с "жареными" заголовками
полностью автоматически бороться, imho, очень
трудно, если вообще возможно ...
Поэтому мне не нравится идея привязывать оценку разбиения новостного
потока на сюжеты к оценке его "лица".
> - часть кластера не относится к этому сюжету (точность)
> - не получить полной картины так как
> потеряны связи с другими близкими сообщениями (полнота)
> что-нибудь еще?
У я.новостей одна из основных задач -- формирование актуального
списка 'главных событий дня'
-- в виде топ-5 (или 15, то же самое по темам). Там потери полноты
чреваты тем, что в топе могут оказаться
несколько кластеров, посвященных одному событию,
что воспринимается как серьезная ошибка системы.
Но ранжирование сюжетов -- опять-таки, отдельная задача ...
>
> По идее мерять надо как раз проблемы и соответственно задача асессорам
> выявить эти проблемы.
>
> > Так все-таки есть у кого-то ясность как будет "оцениваться" новостная
> > дорожка?
>
> А как насчет следующей вариации на тему пулинга:
>
> 1) От каждой системы берем N кластеров. У каждого кластера есть сообщение
> "лицо", которое система выбирает сама по своим принципам.
> 2) Для каждого отобранного "лица" строим пул -
> объединение всех кластеров всех систем куда попало это сообщение
а) Есть опасность, что будут получаться очень большие пулы.
Причем чем больше участвует систем, тем больше пулы.
Кроме того, опасно наличие "агрессивных склеивателей" среди
систем-участников,
типа нынешней Новотеки.
Кроме того, опасны документы-"дайджесты": если хотя бы один алгоритм
окажется неустойчивым к дайджестам, то получим большие и неадекватно
склеенные пулы.
Можно отойти от идеи объединения кластеров,
и строить пулы на основе чего-нибудь вроде кворума.
Тогда придется мириться с неполнотой ...
б) Может получиться, что одному и тому же событию нередко будет
соответствовать около N одинаковых пулов, где N - число систем
(системы построили похожие кластеры, но почти все "лица" -- разные)
Асессору в разные моменты времени может попасться несколько пулов,
соответствующих одному и тому же событию ( и каждый раз будут разные
версии кластера
)
> 3) Асессор оценивает этот пул на предмет "выбора подмножества сообщений
> относящихся к этому же сюжету что и заданное заглавное".
> Оценка по шкале как предлагал Илья -
> входят ли они в один сюжет, в один надсюжет, или вообще на разную
тему
> Но производится она не для пар сообщений, а асессору дается список,
> который надо рассортировать.
>
> Оценки - сравнение эталонных кластеров с кластерами в ответе.
>
> Мы не получим полного эталона
> но получим несколько "эталонных кластеров" для каждого из лиц.
> рассхождения между асессорами конечно будут, но есть надежда что
> в таком случае разные варианты будут сильно пересекаться
> (ну и всегда можно вспомнить про сильные/слабые требования
>
В общем, это некий гибрид построения эталона и метода "общего котла".
а) Но мне кажется, что элементы подхода "общего котла", во-первых,
не дают особых преимуществ -- пул _не_сильно_ меньше
по сравнением с множеством документов в коллекции. Во-вторых,
привносят недостаток -- опасность потери полноты, если все
системы ошибутся по полноте (в рассматриваемой задаче это, imo,
вполне реально)
б) Кроме того, Борис опять скажет, что неполный эталон легко накрутить
====================================
Теперь моя очередь порассуждать на тему "у метода общего котла есть ряд
недостатков"
Imho, их три основных.
1) Метод "общего котла" предполагает, что объединение результатов ответов
всех систем содержит идеальный ответ. Что может привести к потере полноты
На основе усечения по пулу строится процедура
построения оценок -- асессорам предлагается только элементы этого
подмножества.
Для задачи оценки поиска это подход
а) вроде бы безальтернативный
б) приемлемый, т.к. ответы поисковых систем велики и проблема полноты не
стоит остро
Но в "непоисковых дорожках" -- типа классификации документов,
разбиения новостей на сюжеты, аннотирования,
он, imo, не является бесспорным.
Во-вервых, корпус относительно невелик и усечение по пулу не дает такого
"прорывного" сокращения объема анализируемого материала.
Во-вторых, ответы автоматических систем могут _значительно_
отличаться от суждений людей, т.е. ответы всех систем могут быть более
похожи друг на друга, чем на суждение любого из асессоров.
Поэтому, возможно, применение метода "общего котла" чревато существенной
потерей полноты.
В качестве примера сошлюсь на (довольно старую) статью по сравнению
автоматических рефератов с ручными:
The Formation of Abstracts by the Selection of Sentences, G.J. Rath e.a.,
1961 (American Documentation, 12(2):139--143, April 1961)
2) Метод "общего котла" трудно повторно использовать, во всяком случае,
делать это "честно".
Если же делать "честно", то возрастает трудоемкость для асессоров.
Насколько мне известно, в поисковых дорожках РОМИПа
для нового участника не проводится
дополнительной оценки результата. Используются оценки
по "общему котлу" оценок по
уже существующим участникам, что, вообще говоря, ведёт к
дискриминации новых участников.
В случае "непоисковых дорожек" дискриминация новичков, возможно,
сильно увеличивается. Т.е. нетрудно представить ситуацию,
когда в компанию "средних" систем приходит "сильный" новичок,
привнесший полноту, но его более хорошая
полнота будет штрафоваться, за счет чего он
проиграет "средним" участникам.
3) Создателям систем "непонятно, к чему стремиться", результат метода
"общего котла" не является ориентиром.
Если в поисковой задаче из метода "общего котла" в форме, принятой в РОМИПе,
можно извлечь некий неплохой эталон, то,
скажем, из "попарного пулинга" ничего понять нельзя.
Методы, предложенные Борисом и Игорем
в этом отношении лучше. Но мне больше нравится полный эталон
С уважением
Михаил Маслов