Что было нужно в самом начале:

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

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

Сейчас, когда я пишу эту статью, сохранилась идея, но набор данных конечного результата сильно изменился:

  • выбираются не слова, а ключевые выражения и в том числе слова;
  • список ключевых выражений размечен 16-ю различными маркерами;
  • все слова текста (в том числе и не ключевые) лемматизированы – приведены в начальную форму или унифицированы под выведенный формат;
  • каждое слово в тексте имеет дополнительную аналитику, относящуюся к положению по тексту и числу повторений.

Результаты работы ПО nrlpk (Natural Russian Language Processing by the Keys) подготавливают данные для:

  • анализа текстов неограниченного круга тематик и отраслей (разработка и тестирование проводилось по материалам тематики промышленности и ВПК — Военно-Промышленного Комплекса);
  • автоматической рубрикации, классификации, каталогизации, предметизации материалов (online площадки);
  • контроля и фильтрации по содержимому с настройками реакции системы (службам и системам безопасности в замкнутых контурах или online);
  • многослойной разметки текстов (ИИ).

Качество


Чтобы не тянуть через всю статью тех, кто верит только цифрам, а не словам и тем, кто ожидает стопроцентного качества и другого не приемлет…

Качество выборки находится в интервале 95–100% при тестировании на статьях, размером не превышающих 3500 слов. Разброс связан с качеством и сложностью изложения. Вот пример одной из статей, участвовавших в тестировании, а вот результат её автоматического анализа.

Из полученного интервала качества необходимо убрать порядка 7-10%, т.е. фактический уровень качества, скорее будет 85-93%. Это связано с тем, что:

  • в процессе тестирования меняются требования к выбираемым данным, которых я ранее не замечал и полагаю, что далеко не всё замечаю и сейчас;
  • при ручной сверке присутствует мое субъективное мнение, что именно в статье можно признать ключом, а что нет – и оно с большой долей вероятности не совпадает ключ к ключу с мнением авторов статей.

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

Что конкретно повлияло на качество результата в каждой статье, можно посмотреть в файле Reasons на GitHub.

Как читать результаты


В каждой папке для конкретной анализируемой статьи лежит 5 файлов с набором данных в юникоде:

  1. words.csv — список релевантных слов, включая список неидентифицированных;
  2. keys.csv — список ключевых слов, сейчас содержит, кроме маркированных выражений ещё и слова, которые повторяются по тексту не менее заданного числа раз – в данном случае не менее 4 раз;
  3. garbage.csv — список неидентифицированных слов;
  4. descr_words.csv — описание (статистика) к списку всех слов текста;
  5. descr_keys.csv — описание (статистика) к списку ключевых слов;

И reasons_quality.txt – (необязательный) список выражений из статьи, отобранных вручную и не попавших в ключи, или попавших некорректно (по мнению автора nrlpk).

Как читать эти файлы можно узнать из файла Legend на GitHub.

nrlpk позволяет получить любой набор данных в одном из следующих форматов:

  • Pandas Dataframe (по умолчанию);
  • Python Dictionary;
  • JSON;
  • CSV файл.

Методика тестирования


  1. Программный (автоматический) анализ текста.
  2. Ручное (глазками) выявление, ручное (маркирование) ключевых выражений и сверка полученного списка ключевых выражений, со списком, полученным автоматически.
  3. Расчет процента качества: число не попавших выражений или попавших в ключи некорректно + число слов в мусоре, к общему числу слов в тексте.

Инструменты


nrlpk написан на Python 3.7.0. Уже в процессе проработки будущего ПО nrlpk появились два обязательных требования:

  • выбираем выражения, а не слова – слова в том числе;
  • наличие словаря специализированных отраслевых терминов.

Эти требования поставили под сомнение использование NLTK и pymorphy2, которые могли бы решить часть стоящих задач.

Для снятия сомнений была проведена ручная маркировка выборки текстов из СМИ, взятых с крупнейшего русскоязычного агрегатора новостей по тематике ВПК – ВПК.Name. Анализ маркировки выявил:

  • целый слой данных, которые не должны подвергаться пословной токенизации и лемматизации;
  • невозможность во многих случаях токенизации по предложениям до серьезной трансформации текста для исправления грамматических неточностей, которые допускают авторы более чем в 80% статей. Эти неточности никак не влияют на восприятие текста человеком, но очень существенно влияют на восприятие и интерпретацию такого текста машиной.

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

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

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

  • большой – вся база слов;
  • плохие слова – слова, исключаемые из анализа текста в связи с отсутствием значимости;
  • специальный – словарь специализированных (отраслевых) слов. В словарь не включены имена собственные: названия, имена, фамилии, адреса, продукция, изделия, компании, персоны и т.д. Это принципиальное и осознанное решение, поскольку в любой живой отрасли/направлении, такой подход потребовал бы постоянного контроля и ручного дополнения словарей, что губит идею облегчения труда через автоматизацию;

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

Поскольку основа для словарей в nrlpk и pymorphy2 идентична, то и обозначение частей речи (граммем) является идентичным. Число маркеров (нестандартных граммем) на данный момент составляет 16 и большинство из них, если маркированные выражения не состоят из нескольких слов, помимо маркера, имеют ещё и обозначение части речи базовой граммемы. Обозначение совпадающих маркеров (нестандартных граммем) с pymorphy2 идентично, в частности:

  • NUMB – число;
  • ROMN — римское число;
  • UNKN — токен не удалось разобрать.

К слову, для выражений, содержащих числовые данные, в nrlpk, помимо NUMB и ROMN дополнительно используются следующие маркеры:

  • NUSR – выражение содержит одно или несколько числовых данных;
  • MATH – выражение содержит математическую формулу.

Что такое ключевое выражение, состоящее из нескольких слов? На примере NUSR:

  • если в тексте стоит 25 февраля 2020 года, то и ключевое выражение будет 25 февраля 2020 года, с леммой «25.02.2020», граммемой «NUSR» и маркером NUSR;
  • однако, если в тексте стоит «25 февраля 2020 года», то ключевое выражение будет «25 февраля 2020 года», с леммой «2ф2г», граммемой «WIQM» и маркером WIQM;
  • если в тексте будет 25 тонн, то и в ключе мы увидим «25 тонн», с леммой «2т», где в качестве в качестве граммемы и маркера также будет «NUSR».

Зачем понадобились describe к словам и ключам


Сначала это было нужно для проверки работы алгоритмов nrlpk – не потерялись ли слова, не прошло ли лишнего объединения, какова доля ключей в тексте и т.д.

Но по мере отладки ПО стали проявляться некоторые «закономерности», выявление которых, как задача, перед nrlpk не ставилась:

  • выявление слов, написанных с орфографическими ошибками;
  • выявление текстов с плохой стилистикой, bad-% > 35% (практические наблюдения в результате тестирования);
  • выявление целевых (узконаправленных, четко позиционирующих) текстов — skeys-% < 5 без числовых ключей (практические наблюдения в результате тестирования);
  • выявление текстов, не подпадающих под отраслевую тематику – skeys-% < 1.

Анализ взаимного сочетания показателей статистики, может быть не менее интересен, например:

  • выявление текстов «широкого охвата» — keys-% > 45% при ukeys-% стремящемуся к keys-%.

Для чего всё это написано


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

P.S.


Метки к этому (начальному — на Хабре чуть изменен) тексту (приведены ниже) автоматически сгенерированы nrlpk со следующими параметрами:

  • не признавать ключами выражений с числовыми данными;
  • признавать ключами слова, повторяющиеся по тексту не менее 8 раз.

С детальными данными результата обработки nrlpk этой статьи, можно познакомиться на GitHub.

Автор: avl33

Комментарии (4)


  1. nikolay_karelin
    21.09.2019 23:41

    А сам код открыт?


  1. avl33 Автор
    22.09.2019 07:40

    Нет.
    Открытие кода будет препятствовать досиижению сразу двух целей:

    1. поиску стратегического инвестора или нового владельца
    2. выбранным направлениям развития продукта.


    1. nikolay_karelin
      22.09.2019 13:00

      Понятно.


      А сравнение с готовыми библиотеками (yargi/natasha, spacy) или решениями с конференций типа диалога делали?


  1. avl33 Автор
    22.09.2019 17:29

    В самом начале работы я посмотрел на существующие (наиболее известные) пакеты под python, которые позволят или помогут решить задачу. Вообще их очень много, но по большей части они разбились на группы:
    1. не поддерживают или не очень хорошо поддерживают русский язык
    2. поддерживают русский язык, но ключевая задача — качественный морфологический анализ
    3. поддерживают русский язык, но ключевая задача — выявление ключей заданной, узкой направленности, в ряде случаев, через словари.

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

    В итоге мой выбор остановился на, как мне кажется, наиболее сильных пакетах в этой области — NLTK и pymorhy2.

    NLTK отпал после токенизации предложений первых же трех текстов на русском языке.
    pymorhy2 мне понравился. НО, он решает задачи морфологии, а моя задача была выявление ключевых слов до анализа, а позже уже и не слов, а ключевых выражений. Многие слова, из признанных мной ключами получат в Pymorhy2 дополнительную гарммему UNKN — токен неидентифицирован, и это, для решаемой pymorhy задачи, абсолютно верный вывод.
    Но для моей задачи — МиГ-29 не UNKN, это однозначно ключевое слово, которое должно иметь значимую для дальнейшего анализа граммему.

    Кроме того, в этом же тексте присутствует название программы nrlpk и ещё расшифровка — Natural Russian Language Processing by the Keys. Тот, кто писал текст умышленно сделал так, чтобы читателю было очевидно, что это — значимые сущности текста, и что это одно и тоже понятие.

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

    Т.е. по сути, я просто решаю немного иную задачу.