Как стать автором
Обновить

Yargy-парсер и библиотека Natasha. Извлечения структурированной информации из текстов на русском языке

Время на прочтение 12 мин
Количество просмотров 83K
Всего голосов 87: ↑86 и ↓1 +85
Комментарии 33

Комментарии 33

А можно с помощью этого решения искать просто слова? Например, «Занятость» во всех формах (склонения, плюс занят, занятие)? Для некоторых вариантов еще может быть приставки.

Мне для чего нужно. Я перевожу книгу, и там одно слово перевожу определенным образом. А потом понимаю, что перевод должен быть другим. И я хочу найти все старые переводы слова и заменить на новый.
Для этого подойдет лемматизация — приведение слова к нормальной форме
Можно но это overkill. Лучше просто воспользоваться pymorphy2

Аналогичную вещь реализовал на kotlin для departureBot.ru чтобы понимать запросы вроде "туры в Италию Испанию или Грецию в начале июня на 7-10 дней"
Не стал выкладывать т.к. парсер грамматик работает на выводе pymorphy (начальная форма + грамемы). Никто кст не знает живой аналогичной библиотеки с русским (и словарями) для jvm?

Томита-парсер условно доступен, когда я хотел использовать его, написал в поддержку яндекса вопрос о возможности применения в коммерческих решениях, на что получил запрос:
>> юристы просят подробностей о Вашем сервисе. Они хотят понять насколько он будет похож на Я.Новости. Например, речь идет обо всех новостях или только узко-специализированных?

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

Отличная штука, спасибо. Есть возможность обрабатывать не только слова с заглавными буквами?
Например: "петров петр петрович" не вернет ничего, в тоже время "Петров Петр Петрович" работает на ура.

Да, это можно сделать. У вас кейсы, когда это нужно?
Спасибо за классную штуку.
Однако поиск дат ложно срабатывает например на таком абзаце:
В соответствии с санитарной классификацией СанПиН 2.2.1/2.1.1.1200-03 «Санитарно-защитные зоны и санитарная классификация предприятий, сооружений и иных объектов», Объекты по обслуживанию грузовых автомобилей, относятся к 3 классу опасности с нормативной 300 метровой СЗЗ (п.3, класс 3, раздел 7.1.8).
Спасибо, надо будет поправить
Спасибо за полезный проект! А нормализацию времени скоро прикрутите?
Если у вас есть потребность в таком экстракторе, я бы посоветовал прислать примеры строк, который должны разбираться, как это было сделано, например, для адресов github.com/natasha/natasha/issues/9#issuecomment-276799414
Плохо ))image

Когда мне нужно было работать с такими именами я просто заводил словарь
'Абд Аль — Азиз Бин Мухаммад',
'Абд ар — Рахман Наср ас — Са ди',
'Абд ар — Рахман ибн Хасан',
'Абд — аль Хади ибн Али',
'Абд — уль — Кадим Заллюм',
'Абду — ль — Азиз Аль Абдуль — ли — Лятыф',

Для Абу Али аль Хусейн ибн-Абдаллах ибн-Сина будет проще и дешевле нанять людей с трехбуквенными именами, которые вручную распарсят имя Ломион Хорвэграуг Морион Норнорос Яэрэ а’Моритарнон и всех остальных его многочисленных друзей, родственников и животных :)
Авторам библиотеки — большое спасибо.

Зачем «людей с трехбуквенными именами»? Это легко лечится правилами на пост обработке.
Хорошая работа. Правда, на счет
Для текстов с русскими именами качество получается ~0.95
— сомневаюсь. Скажем, «Маша мыла Раму» — ничего не находит. Пока есть проблемы со именами собственными, совпадающие с нарицательными.
А зачем вам нормализация? Она повышает точность не более чем на 1%, а скорость съедает довольно существенно. Нормализация нужна на пост обработке: при согласовании, агрегации, кореференци.
Может быть не совсем понятно написано. В предложении «Для текстов с русскими именами качество получается ~0.95» речь идёт только про github.com/natasha/natasha-examples/blob/master/02_sad/notes.ipynb. То есть утверждается что 95% качество в примере 02_sad/notes.ipynb

Если вы введёте полное предложение, например «придя с работы Маша мыла Раму» «Маша» найдётся. Такая специфика работы NamesExtractor сейчас
Тогда вам есть куда расти. Нужно снимать частиречную омонимию (система должна понимать, что «маша» это noun, а не verb) и проверять по словарю имен собственных для работы с регистром (потому, как, например, «Путина» в начале предложения может быть и имя (в род. или вин. падеже) и слово нарицательное (в именительном)) — и таких примеров много. Хорошо бы еще снимать омонимию по морфо признакам. Но это уже чуть сложнее.
Про нормализацию не понял вопрос. Нормализация делается после применения грамматик
Если у вас приоритет в скорости обработки, то нет смысла использовать нормализацию (даже больше: морфологию). Т.е. работать с плоским текстом. Нормализация почти не дает выигрыша. Ну а если качество — то да, лучше использовать. Иначе согласование и агрегацию одинаковых сущностей будет сделать сложно.
Вы пробовали оценить количество правил, необходимое для корректного извлечения адресов? Типовой адрес в РФ имеет 3-6 уровней адресации (например: область, район, город, улица, дом). Если просто предусмотреть для каждого уровня по 10 частных правил (правила для каждого уровня свои), то общее число правил для пяти-шести уровней достигнет 10^5-10^6. Есть ли какие-то варианты сократить число правил, необходимое для извлечения адреса?
Интересная вещь. Но вот некоторые комментарии в статье я бы подправил. Томита-парсеры для питона есть, и были. Например, Parglare, хотя под python 2.7 у него есть баг с обработкой unicode, возможно, будет исправлено позднее (под python 3 прекрасно работает) (подозреваю, что не только он, скорее всего любой GLR-парсер (или PEG) работающий под python3 не будет иметь проблем с русским языком).
Другое дело, не было инструмента с комплектом правил, заточенных под парсинг русских ФИО/дат/адресов — с этим спорить не буду (сам не сталкивался). В любом случае, хорошая статья, спасибо.
Я плохо знаю Parglare, но я бы не назвал его аналогом Томита-парсера. Вопрос в том как туда встроить работу с морфологией, нормализацией, согласованием.
Давайте определимся. Томита-парсером называется всего лишь ЛЮБОЙ GLR парсер. Обратитесь к ru.wikipedia.org/wiki/GLR-%D0%BF%D0%B0%D1%80%D1%81%D0%B5%D1%80. Называется он Томита-парсером из-за того, что сам GLR предложен Масару Томита, а вовсе не за работу с морфологией и т.п.
Томита-парсер яндекса — одна из реализаций GLR, с некоторыми встроенными плюшками (как и Наташа, хотя в плане последней не уверен).
Давайте отделять алгоритмы от реализаций :)
То, о чем говорили вы, это парсер КСГ с продвинутыми механизмами работы с морфологией, нормализацией, согласованием. А не GLR(Томита) парсер :)
Ой, я думал под словосочетание «Томита-парсер» вы подразумевали github.com/yandex/tomita-parser, про Масару Томита мало кто знает. Тогда «Я плохо знаю Parglare, но я бы не назвал его аналогом yandex/tomita-parser». Просто эти плюшки на практике 50% всей реализации: морфология, нормализаций, специальная процедура интерпретации, согласование, газеттир
Так кто же спорит. Я же не говорю, что статья или упомянутый инструмент плохи — ровно наоборот, просто не стоит вводить людей в заблуждение и мир (к счастью) не ограничивается Yandex'ом
Спасибо за опенсорс! Несколько лет назад действительно дико не хватало подобного открытого и рабочего решения для русского языка.

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

Пара вопросов:
1. Код еще не смотрел, но планируется ли возможноть писать, или использовать кастомные правила для английского языка? Например в тексте встретится английская имя фамилия которые хотелось бы получать вместе с русскими.
2. Это совсем далекое будущее но тем не менее… RCO и Abbyy помимо сущностей позволяют извлекать собственно факты как действия. То есть связывать сущности в тексте между собой, в основном через глаголы. Нечто подобное хотя бы в далеких планах имеется или основным направлением будет именно извлечение фактов сущностей?
1. Если будут конкретные задачи для английских текстов, думаю поддержка появится. Пока конкретных планов нет. Сейчас все задачи для русских текстов. Проблем с реализацией вроде не должно быть. Надо сделать или найти аналог pymorphy2 для английского.
2. Опять же, если появятся задачи про это, то да. Пока планов нет. Теоретически, парсер такое поддерживает.
Вы спрашивали какие темы стоит раскрыть в последующих статьях. Думаю, было бы здорово написать подробнее про комбинирование ручных правил и машинного обучения
Есть готовое решение по анализу текста и поиску некоторых элементов (дат, чисел, имён, E-mail'ов, ссылок, географических названий и т.п.). Правда возможности очень сильно ограничены и это лишь второстепенная функция программы.
Заголовок спойлера
image
«Конвертор C#.NET => Python 3» ничего себе. Кажется, этого не было, когда я последний раз смотрел на Pullenti.

Спасибо! Надо будет попробовать.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории