> Что мне пока не совсем понятно - это планируемые характеристики коллекции
> - количество сообщений, средний объем текста, структура сообщения
> (это временная метка, заголовок и текст?).
Мы сейчас имеем 10-15 тыс. сообщений в будний день. По-видимому, в течение
года нам реально договориться о формировании коллекции примерно с 20-30
агентствами, которые дадут ~50% всего потока сообщений.
За пару месяцев реально договориться с пятью-семью агентствами.
Желаемый временной интервал - дней 20-25 (причем не непрерывный, а разбитый
на несколько периодов, интересных с точки зрения событий - выборы, теракты,
стихийные бедствия и т.п.)
Итого, размер итоговой коллекции - порядка 100 тыс. собщений. Я предполагал,
что коллекция д.б. разбита на 4-6 частей, относящихся к разным временным
интервалам длиной по 3-7 дней.
Средний размер документа - порядка 1К. Документы больше 10К бывают редко. С
др. стороны, нередки короткие сообщения длиной меньше 0.3К.
О временных метках. У нас есть две метки:
- дата-время скачивания новостным роботом Яндекса (интервал скачивания -
10 минут)
- дата-время сообщения, указанная новостным агентством
Мы склонны больше доверять первой метке, поскольку, как показывает опыт, у
второй весьма возможны разные отклонения - как спорадические, так и
регулярные(типа не-перехода на летнее/зимнее время или даже перевода стрелок
на час вперед вместо часа назад); как ненамеренные , так и, возможно,
намеренные (с целью, например, дольше светиться в Яндекс.Новостях). Хотя,
конечно, и первая метка не лишена недостатков ...
MM > > Краткая формулировка основной задачи: "Построение иерархически
> > организованных кластеров".
IgN > То есть на вход участники получают набор небольших текстовых
документов с
> временными метками. В качестве выдачи выдают иерархию кластеров
> (кластер состоит либо из документов либо из подкластеров или можно и то и
> другое? может ли один документ быть в разных кластерах?)
Imho, большой нужды в отнесении документов ко многим кластерам нет (с
пользовательской точки зрения, во всяком случае).
С другой стороны, возможность относить докуметны к разным уровням иерархии
кажется полезной.
Типичная ситуация: сначала идут относительно короткие "исходное" сообщение и
сообщения о "новых поворотах" события, потом возникают документы типа
"газетной статьи" обо всем событии в целом. Документы из первой группы
целесообразно сгруппировать в субкластеры, а статьи и аналитику относить,
как правило, к "корню".
IgN > ... аннотирование всех документов в рамках РОМИП - это выглядит
слишком
> трудоемко.
Да, это трудоемкая задача. Но, imho, выполнимая - если ее автоматизировать и
правильно расставить приоритеты.
IgN > Или мы будем просить оценщика структурировать их вручную и назовем это
> эталоном?
Да, я имею в виду "эталонную" структуру событий.
MM > > понятие "эталонного
> > кластера" - imho, более неопределенное и произвольное, чем
> > понятие "эталонного ответа поисковой системы"; поэтому и есть желание
> > ввести третий (верхний) уровень кластеризации.
> > ...
>
IgN > Что-то мне это плохо понятно.
> можно об этом поподробнее?
ММ > > Если я что-то потерял
> > (с т. зр. "эталона"), не включив в основной сюжет, то я имею шанс
> > частично исправиться, дав ссылку в блоке "см. также".
Здесь я имел в виду текущий интерфейс сервиса news.yandex.ru и блок ссылок
"другие сюжеты на эту тему" в низу страниц сюжета.
> > На самом деле,
> > связи "см. также" не обязаны быть симметричными, т.е. это уже не
> > обязательно иерархия.
Т.е. из одного сюжета в другой связь "см. также" может присутствовать, но
подобной обратной ссылки может не быть.
Попробую пояснить свою мысль в терминах функции оценки качества алгоритмов.
На нижних уровнях иерархии неоднозначностей, по-видимому, должно быть
относительно мало (самые близкие док-ты - нечеткие дубли, на этом уровне
вообще все ясно). Поэтому можно надеяться на возможность _адекватной_
простановки соответствий между субкластерами тестируемой и эталонной
структуры.
Далее, допустим, мы согласились с вышеописанной схемой построения структуры
и есть двухуровневая иерархия кластеров + связи типа "см. также"
Пусть С - субкластер из тестируемой структуры, CE - соответствующий ему
субкластер эталонной структуры, D - документ из C.
Функция сравнения с эталоном с т. зр. точности может выглядеть, например,
так:
Penalty(D, С) = 0, если D принадлежит СЕ
Penalty(D, C) = 2 если D принадлежит родителю СE
Penalty(D, C) = 5 если D принадлежит кластеру, который связан с СE линком
"см. также"
Penalty(D, C) = 10 иначе
Аналогично - оценка полноты.
IgN > Имеет ли смысл делать честный новостной поиск? Как его тогда можно
> организовать (откуда взять запросы и т.п.)
Мне кажется, что поиск для новостного сервиса - это всего лишь
вспомогательная задача.
Процитирую Кришну Бхарата (
http://www.russ.ru/netcult/gateway/20031013.html ):
"Имея дело с новостями, было бы глупо ждать запроса - потому что это
новости. Они новые. Люди могут не знать, что такого важного и интересного
произошло, и задача оповестить их об этом лежит, собственно, на нас" (в
смысле Google News - MM)
С уважением
Михаил Маслов