Pull to refresh

Решение больших проблем небольшим семантическим анализатором

Reading time 8 min
Views 2.5K

image


Сдача проекта в опытную эксплуатацию. Комиссия наблюдает, как система распознаёт информацию из сообщений, поступающих в в режиме реального времени. Приходит первое сообщение: “Тихо.


Комиссия. Что значит “Тихо”? Они там в филиале пьяные что ли?
Система. "Тихо" = Сила ветра в пределах нормы.
Комиссия. Так это они о погоде. Система сдана в опытную эксплуатацию!


Все события в статье вымышлены. Любые совпадения с реальностью случайны.


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


У компании “Z” обширная сеть филиалов по всей нашей необъятной Родине и, пусть, она поставляет дрова для населения и предприятий. На объектах компании регулярно случаются различные происшествия, о которых необходимо знать вышестоящим управленческим структурам.


Исторически сложилось так, что информация с объектов передавалась в виде sms и email сообщений вверх по организационной структуре.
И, конечно, информация добросовестно терялась, чудесным образом видоизменялась и регулярно запаздывала при переходе с уровня на уровень. Как следствие, наверху складывалась искаженная картина о происходящем внизу.


Нам была поставлена задача, в сжатые сроки наладить доставку актуальной информации руководящему аппарату. Компания огромная, а срок — маленький. Решили включить мобильный номер и email главного центра управления во все рассылки от объектов. При этом сообщения не читать, а натравить на них умную программу, которая со всем сама разберётся.


Под “со всем сама разберётся” подразумевалось:


  1. объединение сообщений в ситуации, об одном и том же происшествии, даже если у них разные отправители;
  2. создание графических представлений ситуаций с использованием ГИС и дашбордов;
  3. создание инструмента настройки оповещений по различным параметрам:
    3.1. тип происшествия;
    3.2. приоритет происшествия;
    3.3. место и время происшествия и т.п.
  4. создание инструмента контроля и пресечения:
    4.1. нарушения сроков передачи сообщений с момента возникновения происшествия;
    4.2. искажения и замалчивания информации о происшествиях.
  5. создание инструмента сбора статистической информации и её сопоставления с отчётами от филиалов.

Изобретаем велосипед


Большинство читателей спросит: “А зачем изобретать велик, если есть готовые решения?”. Хороший вопрос, но, как и в анекдоте, есть нюанс. Точнее нюансов было много: предложения преимущественно короткие, орфография и грамматика отдельных сообщений походила на произведения выпускников церковно-приходской школы. Текст слабо структурирован с большим количеством сокращений и аббревиатур, а большая часть слов в нём — отраслевая терминология, помноженная на специфику конкретного региона. То есть одну и ту же сущность в Калининграде и в Красноярске могут назвать по-разному. В итоге, перебрав доступное на тот момент ПО и проконсультировавшись с экспертами области, были вынуждены пилить собственное решение.
С кроткой теорией об этапах извлечения фактов из текста можно ознакомиться тут.


Архитектура проекта


В основе архитектуры лежит трёхуровневый классификатор: типы ситуаций, типы событий, типы атрибутов событий. И принцип:


  • “что” — какое событие произошло
  • “где” — на каком объекте
  • “когда” — в какое время

image


Для работы алгоритма, нужен заполненный классификатор по заданной тематике.


  1. перечень событий — это все интересующие заказчика статистические данные и оповещения о происшествиях на объектах. Пример: землетрясение, несчастный случай, обрушение сооружения.
  2. атрибуты событий — это события, раздробленные на составляющие. Пример: дата и время землетрясения, факт землетрясения, объект события, количество потребителей затронутых происшествием, и т.п.
  3. типы ситуаций — обобщение схожих типов событий. Например тип “Стихийные бедствия” объединяет в себе: ураган, наводнение, сель.

Подробнее об атрибутах событий тут

Сердце атрибута — это токен (грубо говоря слово), и у нас есть два варианта их извлечения: регулярные выражения или словарь языка. Учитывая специфику проекта, мы выбрали регулярные выражения.


У одного токена может быть несколько регулярных выражений для решения проблемы синонимов и опечаток. Сущности вроде: объекты компаний, организационные структуры, административное-территориальное деление, должны опираться на соответствующие базы данных. Для выделения количественных характеристик, выделили особые токены — строгие связи, у которых в регулярных выражениях есть специальные метки — “группы”.


Для управления классификаторами и сущностями был создан конфигуратор, в котором велась вся настройка. Например, у каждого токена указывалось, является ли он субъектом или предикатом.


Алгоритм разделён на этапы:


  1. подготовка текста;
  2. разбиение текста на предложения;
  3. выделение: токенов, сущностей, знаков препинания;
  4. выделение атрибутов событий на основе этапа 3;
  5. определение событий на основе этапа 4;
  6. отнесение событий к уже существующей ситуации или регистрация новой;
  7. определение типов ситуаций о каждом этапе.

Рассмотрим пример поступившего сообщения:


“10.02.15” ориентировочно в десять вечера, на участке ’Южного филиала’ СК, ↲АЗ станций с 15 по 17. Нет соц. знач. Затронуты н.п. Иваново и Петрово. 500 чел..

Этап 1: Подготовка текста


Чистим текст от “мусора”, а схожие по предназначению символы приводим к единому виду. Одних только “тире”не менее четырёх видов (— – − -), да и кавычек не меньше (“ ‘ ` « „).


На выходе получаем:


10.02.15 ориентировочно в десять вечера, на участке Южного филиала СК, АЗ станций с 15 по 17. Нет соц. знач. Затронуты н.п. Иваново и Петрово. 500 чел.

Этап 2: Разбиение на предложения


Чем короче сегмент текста, тем проще с ним работать. Считаем символы “!?. …” концом предложения, и делов-то, если бы не сокращения в тексте. Ключ к решению — словарь сокращений и токены у которых в регулярном выражении есть точка.


Сообщение теперь имеет вид массива предложений:


10.02.15 ориентировочно в десять вечера, на участке Южного филиала СК, АЗ станций с 15 по 17.
Нет соц. знач.
Затронуты н.п. Иваново и Петрово.
500 чел.

Этап 3: Выделение: токенов, сущностей, знаков препинания


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


Примеры:


  • токен — “Отключено”;
  • строгая связь — “{количество} человек”;
  • сущность — “Сургутский филиал”.

В конце этапа предложения представляют собой массив токенов и знаков препинания, все неизвестные слова будут выкинуты:


image


10.02.15 токен “числовая дата” в токен “предлог” ориентировочно десять токен “словесное число” вечера токен “отсылка ко времени”, токен “запятая” на токен “предлог” участке Южного филиала СК сущность “организационная структура”, токен “запятая” АЗ токен “аварийное закрытие” станций токен “станция” с 15 по 17 строгая связь “перечисление”.
Нет токен “отрицательная частица" соц. знач. токен “социально значимый объект”
Затронуты токен “воздействие” н.п. токен “населенный пункт” Иваново сущность “населенный пункт” и токен “союз” Петрово сущность “населенный пункт”.
500 чел строгая связь “количество человек”.

Этап 4: Определение атрибутов событий


Для каждого атрибута события в конфигураторе задан алгоритм и входные данные: токены и строгие связи. А также настроек, позволяющих корректировать работу алгоритма. Например флаг “важна последовательность токенов” означает, что алгоритму нужно не просто найти токены в тексте, но и проверить, что порядок их следования соответствует порядку, указанному в конфигураторе.


image


Основной алгоритм, использующийся в подавляющем количестве атрибутов — это определение связей между субъектами и предикатами. Алгоритм опирается на синтаксические правила и “заглядывает” в соседние предложения.


Пример:


10.02.15 дата в связь даты и времени десять вечера время, на Южного филиала СК организационная структура, АЗ предикат 1 станций субъект 1 для предиката 1 с 15 по 17 уточнение для субъекта 1.
Нет соц. знач. отрицание с субъектом (нет социально значимых потребителей)
Затронуты предикат 2 н.п. субъект 2 для предиката 2 (населенные пункты) Иваново субъект для предиката 2, уточнение для “н.п.” и Петрово субъект для предиката 2, уточнение для “н.п.”.
500 чел субъект 3 для предиката 2, предикат взят из соседнего предложения.

Этап 5: Определение событий


На данном этапе атрибуты событий образуют события. У каждого события в конфигураторе перечислен перечень его атрибутов и настроек, самая важная — отметка основного атрибута. Без основного атрибута событие не состоится. Например у события “Попытка хищения” следующие атрибуты: “Факт попытки хищения” (основной атрибут), “Время возникновения”, “Организационная структура”.


image


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


Формирование событий происходит с учётом данных из соседних предложений. Например, если в предыдущем предложении упоминается, что авария устранена, а в последующих идёт перечисление затронутых потребителей, значит перечисление — это факт восстановления от урона, а не факта урона.


Пример:


10.02.15 16:35 Юж. филиал СК. Авария полностью устранена. Обездровленные потребители: 500 человек.

Этап 6: Объединение событий в ситуации


Основная информация из сообщения получена, теперь её нужно приобщить к существующей ситуации или зарегистрировать новую.


За основу объединения взят принцип “Что? Где? Когда?”. То есть сообщение относится к ситуации если они одинаково отвечают на все 3 вопроса.


Итого, для каждого сообщения проводим сверку на наличие схожих объектов (“Где”) с совместимыми событиями (“Что”), накладывая ограничение по дельте времени (“Когда”).


Например, землетрясение произошло на трёх объектах нижнего уровня, каждый из которых передал сообщение на следующий уровень и копию на самый верх. В свою очередь “следующий уровень” обобщил информацию и передал её на самый верх. В итоге наверху 4 сообщения, которые система объединит в одну ситуацию. То, что объекты “Где”находятся рядом, мы узнаём из справочника объектов компании.
image


Этап 7: Определение типа ситуации


Исходя из состава событий в ситуации, определяется её тип. Типы ситуаций очень важны для принятия решения при оперативном управлении.


Например, в ситуации есть следующий набор событий: потеря телеметрии, обрушение части здания, прекращения снабжения потребителей, сход лавины. Тип ситуации будет определен как “обрушение здания или сооружения”.


Использование данных


Помимо статистики и отчётов, извлекаемые данные были использованы в следующих инструментах:


  1. Система оповещений оперативного персонала по значимым событиям.
    В рамках реализации системы оповещения, был создан конфигуратор условий, работающий с данными событий и их атрибутами.
    Пример оповещений:
    1.1. “Замерзаем”: “авария затронула — более 50 000 человек”, “текущий сезон — зима”, “местоположение — Сибирь”.
    1.2 “Засуха”: “авария затронула социально значимый объект — водонапорная башня”, “длительность — более двух часов”.
  2. Контроль движения информации.
    Раз у системы есть все сообщения по ситуации, то она сама может следить за выполнением регламента по передаче данных: где прерывается цепочка сообщений, кто нарушает хронометраж, кто искажает факты. Инструмент автономно направляет SMS предупреждения нарушителям.
  3. Автоматическое формирование сообщений для отчётов и рассылок.
    Благодаря текстовым шаблонам, значимые ситуации автоматически упаковываются в краткие тексты и далее попадают в рассылки и отчёты.

Итоги


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


Преимущества подхода:


  1. точность распознавания в условиях эксплуатации — 95%;
  2. быстрая настройка алгоритма на новую предметную область, так как основные трудозатраты — это таксономия и массив токенов;
  3. относительная простота и скорость реализации подхода.

Недостатки подхода:


  1. для каждой предметной области необходимо писать регулярные выражения для новых токенов;
  2. снижение точности распознавания на сложных предложениях;
  3. проблемы с опечатками: их нужно закладывать в регулярные выражения, а при работе со словарём приходится использовать “расстояние Левенштейна” (при этом эффективность его работы напрямую зависит от количества букв в слове);
  4. разбиение на предложения требует пополнения словаря сокращений.

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


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


Или случай на совещании головного офиса с филиалами по видеоконференцсвязи, когда руководитель Компании, глядя в дашборд нашей системы, спросил руководителя филиала: “Почему за полтора часа не потушен пожар на объекте”, на что получил ответ: “Какой пожар?”. Информация о пожаре, по старым каналам, дошла до руководителя филиала только через полчаса после совещания.

Tags:
Hubs:
+3
Comments 2
Comments Comments 2

Articles