About News track

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

About News track

Postby maslov70 » Tue Apr 05, 2005 8:13 pm

Коллеги,

{Прошу прощения за повтор}

В рамках проекта Яндекс.Стипендии появилась
новостная коллекция. Ее
описание можно увидеть по адресу
http://company.yandex.ru/grant/datasets_description.xml
в разделе 'Набор данных "Новости"'

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

В частности, нам интересна задача, сформулированная
примерно
так: "Разбиение потока новостных сообщений на
событийные сюжеты"

Как я понимаю, главным вопросом этой постановки
был "как размечать для
нее эталон, и как это сделать не слишком
ресурсоёмким".

В следующем письме я опишу два подхода к
этому вопросу,
с их сравнением.

С уважением
Михаил Маслов
maslov70
 
Posts: 21
Joined: Thu Mar 25, 2004 5:48 pm

Re: [romip] About News track

Postby neigor » Tue Apr 05, 2005 8:18 pm

Блиц-опрос:
согласно http://romip.narod.ru/ru/2005/participants.html,
уже есть как минимум три заявки на участие в этой дорожке
(Яндекса кстати нет :)

Вопрос: кому такая постановка задаци интересна?
или принципиально неинтересна и хочется другую (какую?)

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

Re: [romip] About News track

Postby maslov70 » Tue Apr 05, 2005 8:30 pm

Принципы построения эталона для кластеризации новостей.

Предлагается два варианта:
-- Агломеративное построение коллекции (maslov)
-- Пулинг (iseg)

Оба подхода объединяет то, что построение эталона - полуавтоматическое. т.е.
за основу берётся результат работы новостного автомата (автоматов)

Агломеративное построение (maslov)
1. Построение эталона - полуавтоматическое.
2. События размечаются, начиная с самых важных.
3. Сюжеты строятся "снизу вверх"
4. По-хорошему, каждую коллекцию должны разметить несколько асессоров
независимо

1. Построение эталона - полуавтоматическое.

Имеется структура сюжетов, построенная одним автоматом (Я.Новости).
Построение эталонной коллекции можно в той или иной степени
основывать на использовании этой структуры.
Это позволит сэкономить в объемах ручной работы.

2. События размечаются, начиная с самых важных.

Сюжеты можно размечать, начиная с самых больших и, следовательно важных.
Т.обр.
при недостатке ресурсов можно оценить не все сюжеты выборки,
а только наиболее существенное ядро. Это тоже позволяет разумно
сэкономить в объемах ручной работы. В этом случае результат работы
оцениваемых систем будет сравниваться по этому ядру, что, imo, вполне
разумно.

3. Сюжеты строятся "снизу вверх"

= 3.1 Первый снизу уровень сходства документов между собой -- дубли =
и почти-дубли. В Я.Новостях алгоритм определения дублей
разбивает документы на _непересекающиеся_ классы,
внутри каждого из которых документы объявляются почти-дублями
(ясно, что в большинстве случаев класс состоит из одного сообщения).

Доля дублей и почти-дублей в новостном потоке составляет порядка 30%.
В принципе, можно считать, что работа этого алгоритма
удовлетворительна
и не нуждается в проверке -- во всяком случае, imho, почти-дубли
одного
документа практически всегда посвящены одному событию.

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

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

= 3.3 Вторым этапом можно считать =
склейку первичных кластеров в сюжеты, и подклейку
к сюжетам отдельных сообщений, не вошедших в первичные кластеры.

Механизм склейки кластера с другими кластерами:
-- поиск по ключевым словам кластера (в Я.Новостях они есть)
-- группировка результата поиска по кластерам,
-- ранжирование групп по количеству (или доле) найденных док-тов

= 3.4 Третий этап -- образование суперсюжетов, =
т.е. групп сюжетов, объединенных ассоциативными связями типа "см.
также"

4. Каждую коллекцию должны разметить несколько асессоров независимо
(если по-хорошему)
Тогда системы будут оцениваться по нескольким вариантам разметки, и в
качестве итоговой оценки будет средняя.
Можно разветвить процесс по асессорам не с самого начала, а со второго
этапа, если считать, что на первом этаме "субъективное влияние автомата"
действительно минимально.

Пулинг (iseg)
Я воспроизвожу подход со слов Ильи, поэтому, по-видимому получится неполно и
субъективно. Прошу сделать поправку на это. Также я попрошу Илью дополнить и
"объективизировать" :-)

1. Берется результат работы нескольких (хотя бы двух?) новостных
автоматов на одном и том же корпусе.
2. Можно взять только самые важные сюжеты -- для экономии ручной
работы.
3. ?Для каждого автомата осуществляется привязывание сюжетов к
событиям.
Мне не очень понятен этот момент. При этом Илья, по-видимому, имеет в виду
какую-то _автоматическую_ процедуру.
4. Для каждого события объединяются версии сюжетов от разных
автоматов; из объединенного множества сообщений генерируются пары, причем,
по-видимому, не все возможные, а какая-то выборка.
5. Каждая такая пара предъявляется асессору с тем, чтобы он ответил на
вопрос, относятся ли сообщения к одному событию.
6. Чем больше в сюжете "правильных" пар, тем оценка выше

Некоторое сравнение подходов

В "своем" подходе я вижу менее серьезные недостатки и опять прошу это
учесть.

1 Недостатки подхода maslov:
-- Есть "субъективный фактор" влияния автомата, причем единственного
-- По-видимому, создание инструмента для построения этой коллекции
более ресурсоемко с т. зр. программирования (если не учитывать непонятного
п.3 в iseg)
-- Возможно, сама разметка более затратна из-за п.4. Впрочем, такого
рода затраты вполне можно редуцировать(см.). И в iseg фигурируют пары
сообщений, а пар гораздо больше, чем сообщений ...

2 Недостатки подхода iseg:
-- сейчас имеется в наличии структура сюжетов только от одного автомата
-- плохо понятен п.3
-- В больших (след-но, наиболее интересных) сюжетах регулярно
возникает "нетранзитивность", когда сообщения из начала сюжета не похожи на
сообщения из конца -- если, конечно, придерживаться определения сюжета в TDT
(см. [[http://groups.yahoo.com/group/romip/message/157]] ):
Напомню пример:
"когда самолет американских морских пехотинцев срезал кабель
фуникулера в феврале 1998 г. в Италии, неотвратимым последствием этого было
падение вагонов фуникулеров на землю и последующие повреждения;
следовательно, оба инцидента - часть одного и того же события."
Предположим, у асессора будет пара сообщений с заголовками типа:
1. Самолет американских морских пехотинцев исчез с радаров
2. Затраты на восстановление ущерба от падения фуникулера
составят 100 млн. лир
Существует опасность, что большинство асессоров _не_ посчитают их
принадлежащими одному сюжету. И для того, чтобы принять правильное решение,
им придется в той или иной степени восстановить сюжет. А это гораздо более
затратное занятие, чем просто посмотреть на пару док-тов.
maslov70
 
Posts: 21
Joined: Thu Mar 25, 2004 5:48 pm

Re: [romip] About News track

Postby segalovich » Wed Apr 06, 2005 6:14 pm

Michael Maslov wrote:
> Принципы построения эталона для кластеризации новостей.
>
> Предлагается два варианта:
> -- Агломеративное построение коллекции (maslov)
> -- Пулинг (iseg)
>

> Пулинг (iseg)
> Я воспроизвожу подход со слов Ильи, поэтому, по-видимому получится неполно и
> субъективно. Прошу сделать поправку на это. Также я попрошу Илью дополнить и
> "объективизировать" :-)

Постараюсь здесь это сделать более точно.

1. Берется результат работы всех участвующих
в дорожке новостных автоматов на одном и том же корпусе.

2. Для всех построенных автоматом сюжетов распечатываются
все пары сообщений, входящих в сюжет, вместе
с идентификатором автомата (который собственно и пометил
данную пару, как входящую в один сюжет)

3. Сливаются данные так, чтобы
каждая пара сообщений была помечена идентификаторами
всех автоматов, сведших эту пару в одном сюжете

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

5. Асессор смотрит на пару и принимает решение
входят ли эти два сообщения в один сюжет
(вариант 2: входят ли они в один сюжет, в один
надсюжет, или вообще на разную тему. Где надсюжет
соответствует Мишиному "см.-также")

6. Далее тривиально. Получаем и полноту и точность
каждой системы.

Недостатки и преимущества, как я их вижу (после
дискуссии с Михаилом).

Недостатки.

1. Это именно "пулинг". То есть мы считаем все, что
никто не склеил, как бы принципиально несклеиваемым.
Что роднит данный метод с "пуллингом" на поиске,
где мы считаем заведомо нерелевантным все, что не нашла
ни одна система.

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

2. Ассессор должен по паре сообщений быстро сообразить,
входит ли она в один сюжет или нет.

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

В любом случае качество оценок
может быть проблемой (правда мы можем получить
их относительно много и дешево)

3. Это в сущности лишь оценка качества работы функции
попарной близости. В то время как в реальности функция близости
a) не транзитивна и b) зависит не только от сообщений
(там еще и характеристики кластера играют роль, например).

Но это может быть и не страшно?

4. На выходе мы "не" получаем разбиения на сюжеты.

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

Преимущества.
1. Простота, понятность и в построении и в реализации.
2. Технологичность. Не надо почти ничего программировать.
просто в окне браузера показываем попарно документы и
просим нажать на кнопку "Сюжет" или "Несюжет".

Конечно построить идеальные разбиения было бы очень интересно
по многим причинам. Мой вариант -- скорее паллиатив.
segalovich
Оргкомитет
 
Posts: 46
Joined: Fri Jan 31, 2003 1:21 pm

Re: [romip] About News track

Postby neigor » Thu Apr 07, 2005 2:15 pm

Несколько разрозненные мысли на эту тему.

0) Еще раз о постановке задачи (как это сейчас понимаю я).

Вход: набор тектов + то что описано в docDescr (то есть поисхождение и время)
Выход от системы: выявленная структура кластеров
(сколько уровней??)

Вся работа асессоров будет производится ПОСЛЕ сбора результатов,
т.е. никакой предварительной разметки.

Пожалуйста, поправьте меня, если я что-то неправильно понимаю или нечетко
сформулировал.

1) Объем работы для агломеративного построения

Сейчас набор состоит из порядка 24000 документов.
При скорости разметки 50 документов/час (взята с потолка,
но порядок так можно оценить) полная разметка
что-то около 500 человекочасов при одной оценке.
Это довольно много (в прошлом году пулы строились
из расчета 100 человекочасов на одну оценку).
Проблемы тут следующие:
- Большие неделимые куски работы
(как минимум один асессор должен смотреть всю неделю,
а это 165 часов (человекомесяц))
Это сложно контролировать, высокий риск.
- (Финансы) При малом числе участников абсолютный размер взноса в
этой дорожке будет заметно выше, чем в других.

2) Возможность предварительной подготовки эталоного разбиения

В отличие от пулинга оно не зависит от результатов систем и следовательно
его можно делать раньше (и дольше!). Однако, для чистоты эксперимента
оценивать не могут участники дорожки.

3) Альтернативный пулинг 1
(вариант сырой, пока ни с кем не обсуждался и не критиковался :)

1) Берем 1 "среднестатистическую" ленту
(я так полагаю ~50-100 сообщений в день и 400-1000 за неделю?)
2) Асессор просматривает эту ленту и сортирует сообщения по
замеченным им событиям. Так, как это делают с почтой,
раскладывая ее по папкам.

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

3) Все созданные папки с >2 документов считаем найденными "идеальными
сюжетами".

4) Для каждого такого сюжета, выбираем все
"построенные сюжеты" из прогонов участников,
которые с идеальными сильно пересекаются
(пересечение >30% от размера любого из них?).

Все сообщения из отобранных "построенных сюжетов" формируют пулы.

5) Отбираем часть (или все) пулов и оцениваем документы из них на
отношение к конкретному сюжету.

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

Недостатки:
- Зависит от качества исходной ленты, если сюжет там плохо представлен,
то его веротятно не выявят как "идеальный".
[Понятно, что крупный сюжет является сюжетом и в рамках одной ленты,
но до какого размера сюжета это сохраняется?]
- При очень большом количестве сюжетов асессору, разбивающему на
сюжеты, будет сложно принимать решение.
[А сколько сюжетов реально возникает за неделю?]
- Здесь тоже нельзя померять идеальную полноту.
- Можно иметь несколько оценок на втором этапе (проверка отношения
документа к сюжету), но можно ли на первом?
В принципе можно просто объединить множества обнаруженных идеальных
сюжетов, даже если они личь частично пересекаются.

4) Альтернативный пулинг 2

Вариация на ту же тему, но с использованием больше одной ленты.
Показываем асессору объединенную ленту за день и просим выделить 5
сюжетов как минимум по 5(?) сообщений (итого >120 тем за 24 дня).
Для каждой из тем генерируем пул как описано выше и проверяем часть
из них.

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

Re: [romip] About News track

Postby maslov70 » Thu Apr 07, 2005 3:09 pm

> При скорости разметки 50 документов/час (взята с потолка,
> но порядок так можно оценить) полная разметка
> что-то около 500 человекочасов при одной оценке.

Важный момент. Единицей оценки документ _не_является _. В случае пулинга это
пара документов. В случае агломеративного построения эталона это группа
документов.

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

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

Я предполагаю, что при достаточно высоком пороге близости число
ошибок "первого рода" будет невелико, переносов и делений будет немного, и
поэтому первичная оценка будет не очень ресурсоемкой (см. п 3.2 в описании
агломеративного построения эталона)

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

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

> Сейчас набор состоит из порядка 24000 документов.

Мое предложение было таким:

В потоке новостей 30% дублей, определенных механизмом Яндекса(см поле #8 в
docDescr, обозначенное ) . Imho, их целесообразно
_не_предъявлять_ асессорам. Правда 30% - это в полном потоке , а в
усеченном, видимо, меньше ...

Прошу прощения, ответить на предложения из остальной части письма я пока не
могу ...

С уважением
Михаил
maslov70
 
Posts: 21
Joined: Thu Mar 25, 2004 5:48 pm

RE: [romip] About News track

Postby vladimir_pleshko » Thu Apr 07, 2005 4:34 pm

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

1. Для оценки сравнения разбиений объектов на кластера с эталонным самым
очевидным способом является оценка пар объектов из разбиения - входят/не входят
в один эталонный кластер. При этом можно оценивать полноту и точность даже для
разбиений на пересекающиеся кластера. Можно также считать корреляцию - но для
случая пересечающихся кластеров, равенство ее 1 не означает совпадения
разбиений.

Что не очень приятно - штраф за ошибки на больших кластерах будет выше, чем на
маленьких. Т.е., если объект не попал в кластер, то появятся ошибки в количестве
(размер_кластера - 1). Для кластера размером 2 - будет всего одна ошибка. У меня
не было времени подумать, как это обойти, и стоит ли обходить.

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

Таким же образом можно давать системам устанавливать и затем оценивать отдельно
два типа связей: "сюжет", "см.также".
Или связь "см.также" устанавливается между кластерами?

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

2. Насколько я понимаю, основной вопрос сейчас - не выбор меры для оценки, а
способ подсчета оценки.
Самое простое - что предложил Илья.
+предсказуемый результат - так работает ОТК на заводах
+в любой момент можно остановиться и получить приближение оценки
-пар будет много
-сравнивать два документа тяжело
-результаты будут частично оцененными и, как мне кажется, мало пригодными для
повторного использования

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

3. К вопросу транзитивности...
В каком виде мы будем получать от систем результат?
Скорее всего как (docID, clusterID).
В этом случае система сама делает транзитивное замыкание всех пар, даже если
функция сравнения документов не транзитивна.
Будем ли допускать принадлежность документа нескольким кластерам? Тогда
транзитивности в ответе системы действительно не будет.

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

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

Сюда в обоих можно добавить и тип связи.

4. Интересно также как-то попытаться оценить ранжирование сюжетов по важности. В
случае наличия эталонного разбиения можно субъективно упорядочить
кластера-сюжеты по важности, или формально по частоте, числу перепечаток или еще
бог знает чему. Тоже самое предлагать делать системам при построении кластеров.
При этом каждое сообщение получит число - важность (или несколько чисел - для
пересекающихся кластеров). Есть такие вещи, как ранговые корреляции, порядковые
статистики и т.п. Если посмотреть повнимательней - может получится, что-нибудь
подобрать или адаптировать.

С уважением,
Владимир Плешко
vladimir_pleshko
Оргкомитет
 
Posts: 71
Joined: Fri May 23, 2003 8:26 am

Re: [romip] About News track

Postby maslov70 » Thu Apr 07, 2005 5:42 pm

> Что не очень приятно - штраф за ошибки на больших кластерах будет выше,
чем на маленьких. Т.е., если объект не попал в кластер, то появятся ошибки в
количестве (размер_кластера - 1). Для кластера размером 2 - будет всего одна
ошибка. У меня не было времени подумать, как это обойти, и стоит ли
обходить.

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


Yahoo! Groups Links
maslov70
 
Posts: 21
Joined: Thu Mar 25, 2004 5:48 pm

Re: [romip] About News track

Postby neigor » Thu Apr 07, 2005 7:32 pm

On Thu, 7 Apr 2005, Michael Maslov wrote:

>
> > При скорости разметки 50 документов/час (взята с потолка,
> > но порядок так можно оценить) полная разметка
> > что-то около 500 человекочасов при одной оценке.
>
> Важный момент. Единицей оценки документ _не_является _. В случае пулинга это
> пара документов. В случае агломеративного построения эталона это группа
> документов.

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

то есть все таки O(число документов без учета дубликатов)

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

Re: [romip] Re: About News track

Postby maslov70 » Fri Apr 08, 2005 12:42 am

Re: [romip] Re: About News track

[Прошу прощения за мусор, опять через веб-интерфейс послал]

Igor > При скорости разметки 50 документов/час (взята
> с потолка, но порядок так можно оценить) полная
> разметкачто-то около 500 человекочасов при одной
> оценке.


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

Кстати, может быть, станет понятно, почему я не в восторге
от идеи "попарного" пулинга.

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

Если большинство сообщений небольшие и примерно
одинаковой длины (характерный размер сообщения в коллекции,
кстати, ~150 слов, ~10 предложений),
то при оценке очередного собщения неплохо работает
приблизительно такая стратегия:
-- прочитать заголовок, понять, есть ли topic drift
относительно первых сообщений
-- выхватить фрагмент из начала, середины, конца; нередко
происходит узнавание того, что _только_что_
(несколько сообщений назад) прочитал

Довольно часто встречаются сообщения, сделанные из
оригинала примерно по такому рецепту:
-- переписать заголовок
-- вставить в начало ссылку на первоисточник,
типа 'как сообщают РИА Новости'
-- вставить одно-два предложения от
себя (необязательно)
-- разбить предложение на два или объединить
два соседних в одно; переставить пару слов;
заменить эпитет и т.п.
Для небольшого сообщения в 100-150 слов этого оказывается
вполне достаточно, чтобы "обмануть" алгоритм обнаружения
дубликатов (доля измененного текста немаленькая).
Но читатель при этом, сканируя, почти не видит разницы.
Конечно, нужен определенный навык сканирования, но он
вырабатывается, imho, достаточно быстро.

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

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

Об альтернативном пулинге.
Igor > 1) Берем 1 "среднестатистическую" ленту (я так полагаю
> ~50-100 сообщений в день и 400-1000 за неделю?)

Если я правильно понял, лентой называется поток сообщений
от одного агентства.

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

Потом, самое хорошее агентство в этой коллекции --
это Регнум, который дает половину всего потока.
Не спорю, экономия заметная. Но Регнум имеет специфику --
уклон в региональные новости.

Следующий -- 20% -- Росбалт. Тоже не очень типичный --
северо-западный регион + много аналитики.

Остальные еще более специфические, и по ним
я бы уж точно не стал ...

Igor > 2) Асессор просматривает эту ленту и сортирует сообщения по
> замеченным им событиям. Так, как это делают с почтой,
> раскладывая ее по папкам.

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

Igor > 3) Все созданные папки с >2 документов считаем найденными
> "идеальными сюжетами".

Imho, все-таки не хватает еще одного этапа -- объединить
некоторые сюжеты в более крупные -- если принять
за основу определение события из TDT.

Еще комментарии.

Igor > 1) Объем работы для агломеративного построения
> При скорости разметки 50 документов/час (взята с потолка,
> но порядок так можно оценить) полная разметка
> что-то около 500 человекочасов при одной оценке.

Выше я попытался уменьшить пессимизм этой оценки :-)

Кроме этого, я говорил, что можно ограничить
объем работы, оценивая только самые важные события.
Но об этом, с вашего позволения, несколько позже.

Igor > Проблемы тут следующие:
> - Большие неделимые куски работы
> (как минимум один асессор должен смотреть всю неделю,
> а это 165 часов (человекомесяц))

Я вот подумал, что неделю для первого этапа
агломеративного построения вполне
можно разделить -- по времени: условно
говоря, одному -- понедельник-вторник,
второму -- среда-четверг, третьему -- остальное.
Сюжеты ведь в основном локализованы по времени.
Ясно, что некоторые сюжеты пересекают такие границы.

Но полного объединения сюжетов на первом этапе не
требуется, окончательное "сшивание" сюжетов
все равно будет на втором.

(В сторону: а в Новотеке вообще все режется
по суткам ;-) )

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

С уважением
Михаил
maslov70
 
Posts: 21
Joined: Thu Mar 25, 2004 5:48 pm

Next

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

Who is online

Users browsing this forum: No registered users and 9 guests

cron