Пространство окружающего Мира наполнено отдельными событиями и их цепочками – эти события отражаются в СМИ, в аккаунтах блогеров и обычных людей в социальных сетях.
Получить картину окружающей действительности, претендующую на некоторую степень объективности, можно только в том случае, если собрать разные точки зрения на одну и ту же проблему.
Классификатор событий — это инструмент, который сортирует собранную информацию: версии описаний событий.
Далее предоставьте пользователям доступ к информации о событиях с помощью инструментов поиска, рекомендаций и визуального представления временных последовательностей событий.
Сегодня мы поговорим о нашей системе, точнее о ее программном ядре под кодовым названием «Варя» — в честь ведущего разработчика.
Мы пока не можем назвать название нашего стартапа; по просьбе администрации Хабрахабра мы сейчас подали заявку на присвоение статуса «Стартап».
Однако о функционале и наших идеях мы можем поговорить уже сейчас.
Наша система обеспечивает актуальность информации о событиях для пользователя и грамотное управление данными – в системе каждый пользователь сам определяет, что смотреть и читать, управляет поисками и рекомендациями.
Наш проект — это стартап с командой из 8 человек, обладающих компетенциями в проектировании технически и алгоритмически сложных систем, программировании, маркетинге и менеджменте.
Вместе команда работает над проектом каждый день — уже реализованы алгоритмы категоризации, поиска и представления информации.
Впереди еще реализация алгоритмов, связанных с рекомендациями для пользователя: на основе взаимосвязи событий, людей и анализа активности и интересов пользователя.
Какие проблемы мы решаем и почему мы об этом говорим? Мы помогаем людям получить подробную информацию о событиях любого масштаба, независимо от того, где и когда они произошли.
Проект предоставляет пользователям платформу для обсуждения событий среди единомышленников и позволяет им поделиться комментарием или собственной версией произошедшего.
Социальная сеть создана для тех, кто стремится знать «выше среднего» и иметь личное мнение о главных событиях прошлого, настоящего и будущего.
Пользователи сами находят и создают полезный контент в медиапространстве и следят за его достоверностью.
Мы сохраняем память о событиях их жизни.
Сейчас проект находится на стадии MVP, мы тестируем гипотезы о функционале и работе классификатора, чтобы определить правильное направление дальнейшего развития.
В этой статье мы поговорим о технологиях, с помощью которых мы решаем поставленные перед собой задачи, и поделимся лучшими практиками.
Задачу машинной обработки текста решают поисковые системы: Яндекс, Google, Bing и др.
Идеальная система для работы с информационными потоками и выделения событий в них могла бы выглядеть так.
Для системы выстраивается инфраструктура, аналогичная Яндексу и Google, весь Интернет в режиме реального времени сканируется на наличие обновлений, а затем в информационном потоке выявляются ядра событий, вокруг которых формируются скопления их версий и связанного с ними контента.
Программная реализация сервиса основана на нейронной сети глубокого обучения и/или решении на базе библиотеки Яндекса — CatBoost. Прохладный? Однако у нас пока нет такого объема данных, и нет соответствующих вычислительных ресурсов для их усвоения.
Классификация тем — популярная проблема, и существует множество алгоритмов для ее решения: наивные классификаторы Байеса, скрытое распределение Дирихле, бустинг дерева решений и нейронные сети.
Как, наверное, и во всех задачах машинного обучения, при использовании описанных алгоритмов возникают две проблемы: Во-первых, откуда вы берете много данных? Во-вторых, как их разместить дешево и сердито?
Какой подход мы выбрали для системы, основанной на событиях?
Наш продукт работает с событиями.Мероприятия несколько отличаются от обычных статей.
Чтобы преодолеть холодный старт, мы решили использовать два проекта WikiMedia: Wikipedia и Wikinews. Одна статья в Википедии может описывать несколько событий (например, историю развития Sun Microsystems, биографию Маяковского или ход Великой Отечественной войны).
Другими источниками информации о событиях являются новостные ленты RSS. В новостях это происходит по-разному: большие аналитические статьи содержат несколько событий, как и тексты Википедии, но короткие новостные сообщения из разных источников представляют одно и то же событие.
Таким образом, статья и события образуют отношения многие-ко-многим.
Но на этапе MVP мы исходим из того, что одна статья — это одно событие.
Глядя на интерфейс Google или Яндекса, можно подумать, что поисковые системы ищут только по ключевым словам.
Это справедливо только для очень простых интернет-магазинов.
Большинство поисковых систем являются многокритериальными, и наш движок проекта не является исключением.
Однако не все параметры, учитываемые при поиске, отображаются в пользовательском интерфейсе.
В нашем проекте есть список параметров, которые выбирает пользователь: темы и ключевые слова - "Что?" ; расположение - "Где?" ; дата - "Когда?" ; Те, кто пишет поисковые системы, знают, что одни только ключевые слова вызывают массу проблем.
Ну и с остальными параметрами тоже не всё так просто.
Тема мероприятия – очень сложная вещь.
Человеческий мозг устроен так, что любит все классифицировать, а реальный мир с этим категорически не согласен.
Поступающие статьи хотят формировать свои группы тем, и они совсем не те, по которым мы и наши энтузиасты-пользователи их распределяем.
Сейчас у нас есть 15 основных тем событий, и этот список несколько раз пересматривался и, по крайней мере, будет расширяться.
Места и даты расставлены несколько более формально, но и здесь есть подводные камни.
Итак, у нас есть набор формализованных критериев и необработанные данные, которые необходимо сопоставить с этими критериями.
И вот как мы это делаем.
Паук
Задача паука — систематизировать поступающие статьи так, чтобы их можно было быстро найти.Для этого паук должен иметь возможность присваивать статьям тему, местоположение и дату, а также некоторые другие параметры, необходимые для ранжирования.
Наш паук получает на вход текстовую модель статьи, построенную сканером.
Текстовая модель — это перечень частей статьи и соответствующих им текстов.
Например, почти каждая статья имеет как минимум заголовок и основной текст. Фактически, у него также есть первый абзац, набор категорий, к которым этот текст принадлежит его источнику, и список полей инфобокса (для Википедии и источников, имеющих такие теги метаданных).
Также есть дата публикации.
Для ранжирования в поисковой системе нам будет важно знать, находится ли, например, дата в заголовке или где-то в конце текста.
На основе текстовой модели строятся тематическая модель, модель местоположения и модель даты, а затем результат компилируется в индекс.
О каждой из этих моделей можно было бы написать отдельную статью, поэтому здесь мы лишь кратко изложим подходы.
Предметы
Определение тематики документов – обычная задача.Тема может быть задана автором документа вручную или определена автоматически.
У нас, конечно, есть темы, которые новостные источники и Википедия присвоили нашим документам, но эти темы не о событиях.
Часто ли вы видите тему «Праздники» в новостных лентах? Скорее всего, вам встретится тема «Общество».
У нас это тоже было в одном из ранних изданий.
Мы не смогли определить, что к нему следует применить, и были вынуждены удалить его.
И кроме того, все источники имеют свой набор тем.
Мы хотим управлять списком тем, которые мы показываем нашим пользователям в интерфейсе, поэтому для нас задача определения темы документа — это задача нечеткой классификации.
Для задачи классификации требуются помеченные примеры, то есть список документов, которым уже присвоены желаемые темы.
Наш список похож на все подобные списки тем, но не совпадает с ними, поэтому выделенной выборки у нас не было.
Вы также можете получить его вручную или автоматически, но если наш список тем изменится (а это произойдет!), то вручную это не вариант. Если у вас нет помеченной выборки, вы можете использовать скрытое распределение Дирихле и другие алгоритмы тематического моделирования, но в итоге вы получите тот набор тем, который вы получите, а не тот, который вам нужен.
Здесь следует отметить еще один момент: наши статьи взяты из разных источников.
Все тематические модели так или иначе построены на используемой лексике.
Для новостей и Википедии по-разному, даже высокочастотные фильтры, которые отфильтровываются, разные.
Таким образом, перед нами стояли две задачи: 1. Придумать способ быстрой разметки наших документов в полуавтоматическом режиме.
2. На основе этих документов построить расширяемую модель нашей темы.
Для их решения мы создали гибридный алгоритм, содержащий автоматизированные и ручные этапы, представленный на рисунке.
- Ручная разметка категорий Википедии и получение категориальной модели тем WikiCatTopic. На этом этапе строится конфиг, который каждой нашей теме T соответствует подграф CT категорий Википедии.
Википедия — это псевдоонтология.
Это означает, что если что-то включено в категорию «Наука», то это может быть вообще не наука, например, из безобидной подкатегории «Информационные технологии» действительно можно прийти к любой статье в Википедии.
О том, как с этим жить, нужна отдельная статья.
- Автоматическое определение тем для документов Википедии на основе WikiCatTopic. Документу присваивается тема Т, если он попадает в одну из категорий графы КТ.
Обратите внимание, что этот метод применим только для статей Википедии.
Чтобы обобщить определение тем на произвольный текст, можно было для каждой темы построить мешок слов и вычислить косинусное расстояние до темы (и мы пытались, ничего хорошего), но здесь надо учитывать три момента .
- Такие темы содержат очень разнообразные статьи, поэтому изображение темы в словесном пространстве не будет связным, а значит, «уверенность» такой модели в определении темы очень низка (ведь статья аналогична одной небольшой набор статей, но не для остальных).
- Свободный текст, в первую очередь новости, по лексическому составу отличается от Википедии, это также не добавляет модели «уверенности».
Кроме того, некоторые темы невозможно построить в Википедии.
- Шаг 1 — очень кропотливая работа, и всем лень ее делать.
- Такие темы содержат очень разнообразные статьи, поэтому изображение темы в словесном пространстве не будет связным, а значит, «уверенность» такой модели в определении темы очень низка (ведь статья аналогична одной небольшой набор статей, но не для остальных).
- Кластеризация документов внутри тем по результатам шага 2 методом k-средних и получение кластерной модели темы WikiClustTopic. Достаточно простой ход, который позволил нам во многом решить две из трех задач из пункта 2. Мы строим «мешок слов» для кластеров, а принадлежность к теме определяется как максимум косинусных расстояний до ее кластеров.
Наша модель описывается конфигурационными файлами соответствия между кластерами и документами Википедии.
- Ручная очистка модели WikiClustTopic, включение/отключение/перенос кластеров.
Здесь мы также вернулись к этапу 1, когда были обнаружены совершенно неправильные кластеры.
- Автоматическое обнаружение документов Википедии и тем новостей на основе WikiClustTopic.
- Кластеризация новостей внутри тем по результатам пункта 5 методом k-средних, а также новостей, не попавших в тему, и получение кластерной модели темы NewsClustTopic. Теперь у нас есть тематическая модель, учитывающая специфику новостей (а также бесценную информацию о качестве краулера).
- Ручная очистка модели NewsClustTopic.
- Переназначение тем новостей на основе объединенной модели ClustTopic = WikiClustTopic + NewsClustTopic. На основе этой модели определяются темы новых документов.
Локации
Автоматическое определение местоположения — это частный случай проблемы поиска именованных объектов.Особенности локации следующие:
- Все списки локаций разные и плохо сочетаются друг с другом.
Мы построили свое, гибридное, учитывающее не только иерархию (в Россию входит Новосибирская область), но и исторические изменения названий (например, РСФСР стала Россией) на основе: Геонаименований, Викиданных и других открытых источников.
.
Однако нам всё равно пришлось написать конвертер геотегов из Google Maps :)
- Некоторые локации состоят из нескольких слов, например Нижний Новгород, и их нужно уметь собирать.
- Места схожи с другими словами, особенно с именами тех, в честь кого они названы: Киров, Жуков, Владимир.
Это омонимия.
Чтобы вылечить эту проблему, мы собрали статистику по статьям Википедии с описанием населенных пунктов, в каких контекстах встречаются названия локаций, а также попытались построить список таких омонимов с помощью словарей Open Corpora.
- Человечество не сильно расширило воображение, и многие места имеют одинаковые названия.
Наш любимый пример: Карасук в Казахстане и в России, под Новосибирском.
Это омонимия внутри класса местоположения.
Мы решаем эту проблему, рассматривая, какие еще местоположения встречаются вместе с этим и являются ли они родительскими или дочерними по отношению к одному из омонимов.
Эта эвристика не универсальна, но работает хорошо.
Даты
Даты — это воплощение формальности по сравнению с темами и местами.Мы сделали для них расширяемый парсер с использованием регулярных выражений, и мы можем парсить не только день-месяц-год, но и всякие более интересные вещи, такие как «конец зимы 1941 года», «в 90-х годах 19 века».
и «прошлый месяц», принимая во внимание эпоху и базовую дату документа, а также пытаясь восстановить недостающий год. О свиданиях нужно знать, что не все из них хороши.
Например, в конце статьи о каком-нибудь бою ВМВ может быть открытие мемориала спустя сорок лет, чтобы работать с такими случаями, надо разрезать статью на события, но мы этого пока не делаем .
Поэтому мы рассмотрим только самые важные даты: из заголовка и первых абзацев.
Поисковый движок
Поисковая система – это вещь, которая, во-первых, осуществляет поиск документов по запросу, а во-вторых, расставляет их по убыванию степени релевантности запросу, то есть по убыванию релевантности.Для расчета релевантности мы используем множество параметров, гораздо больше, чем просто тривиальность: Степень принадлежности документа теме.
Степень принадлежности документа локации (сколько раз и в каких частях документа встречается выбранная локация).
Степень соответствия документа дате (учитывается количество дней в пересечении интервала от запроса и дат документа, а также количество дней в пересечении за вычетом объединения).
Длина документа.
Длинные статьи должны быть выше.
Наличие изображения.
Все любят картинки, их должно быть больше! Тип статьи в Википедии.
Мы умеем разделять статьи с описаниями событий, и они должны «всплывать» в подборке.
Источник статьи.
Новости и пользовательские статьи должны быть выше Википедии.
В качестве поисковой системы мы используем Apache Lucene.
Гусеничный трактор
Задача сканера — собирать статьи для паука.В нашем случае это первичная очистка текста и построение текстовой модели документа.
Краулер заслуживает отдельной статьи.
P.S. Будем рады любым отзывам, приглашаем вас протестировать наш проект - для получения ссылки пишите в личные сообщения (опубликовать ее здесь мы не можем).
Оставляйте свои комментарии под статьей, а если попадете в наш сервис, то тут же, через форму обратной связи.
Теги: #события #поиск по событиям #категоризация #тематический поиск #история #история #новости #агрегатор новостей #Поисковые технологии #Анализ и проектирование систем #Большие данные #Разработка стартапов #поисковая оптимизация
-
Хабрафорум
19 Oct, 24 -
Ты-Ты-Ты? Мы? (Я Немного Сумасшедший)
19 Oct, 24
