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 часов (человекомесяц))
Я вот подумал, что неделю для первого этапа
агломеративного построения вполне
можно разделить -- по времени: условно
говоря, одному -- понедельник-вторник,
второму -- среда-четверг, третьему -- остальное.
Сюжеты ведь в основном локализованы по времени.
Ясно, что некоторые сюжеты пересекают такие границы.
Но полного объединения сюжетов на первом этапе не
требуется, окончательное "сшивание" сюжетов
все равно будет на втором.
(В сторону: а в Новотеке вообще все режется
по суткам
)
На первом этапе всего лишь важно, чтобы все
сообщения внутри групп соответствовали одному
событию, и нет цели, чтобы группа содержала все
сообщения про событие.
С уважением
Михаил