Backend Developer, ML
2,4
рейтинг
27 сентября 2014 в 13:07

Разработка → Новая языково-независимая NLP библиотека

Введение


Каждый, кто пришел в этот мир, проходил через путь познания языка. При этом человек обучается языку отнюдь не по правилам или грамматике. Даже, более того, каждый человек, будучи еще ребенком, сначала учит такое странное явление как язык, а уже позднее, с возрастом, начинает учить его правила (в садике и школе). Это объясняет забавный факт, каждый, кто изучает иностранный язык в зрелом возрасте, когда он уже менее склонен к изучению новых языков, знает о предмете своего изучения больше, чем большинство носителей этого языка.

Это простое наблюдение дает возможность предполагать, что для понимания языка вовсе не нужно иметь знания о нем. Достаточно лишь эмпирии (опыта), который можно почерпнуть от окружающих. Но именно об этом забывают практически все современные НЛП библиотеки, пытаясь построить все-обемлящую языковую модель.

Для более четкого понимания представьте себя слепым и глухим. И, даже родись в таком состоянии, вы бы могли взаимодействовать с миром и освоить язык. Само собой, что ваше представление о мире было бы иным, нежели у всех вокруг. Но вы могли бы все таким же образом взаимодействовать с миром. Некому бы было объяснить Вам что происходит и что такое язык ив се же, как то, тактильно анализирую шрифт Брайля Вы бы понемного сдвинулись с мертвой точки.

А это значит, что для понимания сообщения на каком-либо языке нам не нужно ничего, кроме самого сообщения. При условии, что это сообщение достаточно большое. Именно эта идея и положена в основу библиотеки под названием AIF. За деталями прошу пожаловать под кат.


Вначале совсем немного теории о том как уныло все вокруг


Есть очень хороший курс Стэнфорда посвященный NLP: www.coursera.org/course/nlp. Если еще по каким-то причинам его не видели, то очень зря. Просмотрев хотя бы первые 2 недели, становится понятно что такое вероятностная модель языка, на которой строится большая часть всех существующих НЛП решений. Если коротко, то имея огромную кучу текстов, можно прикинуть с какой вероятностью каждое слово употребляется с другим словом. Это очень грубое объяснение, но оно, как мне кажется, точно отражает суть. В результате получается строить более-менее приличные переводы (привет Google Translate). Этот подход не приближает нас к пониманию текста, а лишь пытается найти похожие предложения и на их базе построить перевод.

Но не будем о грустном, поговорим о том, что потенциально можем дать мы:

Какие функции должна будет реализовать финальная версия нашей библиотеки?


  • Поиск символов, используемых для разделения предложений в тексте.
  • Извлечение лемм из текста (с весами).
  • Построение семантического графа текста.
  • Сравнение семантических графов текстов.
  • Построение резюме текста.
  • Извлечение объектов из текстового (частичное NER).
  • Определение связи между объектами.
  • Определение темы текста.
  • В текущей версии у нас уже есть реализация некоторых пунктов из этого списка.


Почему миру нужен AIF?


Учитывая, что уже есть довольно много подобных библиотек OpenNLP, StanfordNLP, — зачем создавать ещё одну?

В большинстве существующих НЛП библиотеках есть существенные недостатки:
  • привязанность к конкретным языкам (качество результата работы может сильно варьироваться от языка к языку);
  • привязанность к точной грамматической структуре (было бы классно видеть, как каждый пишет подобно Шекспиру или Толстому, но это далеко от реальности);
  • привязанность к кодировке (так как языковые модели часто заточены под определенную кодировку).

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

Языковые модели не могут провести семантический анализ текста. Они избегают понимания текста на этапе синтаксического анализа. Модель языка может помочь разбить текст на предложения, провести извлечение сущностей (NER), feeling extraction. Тем не менее модель не может определить смысл текста, к примеру, не сможет составить приемлемое резюме текста.

Проиллюстрируем вышеуказанные пункты на примере.

Возьмем отсканированный текст https://archive.org/details/legendaryhistor00veld . Этот текст имеет ряд нестандартно закодированных символов, но мы сделаем его еще хуже, заменив символ “." на "¸". Эта замена не будет препятствовать читаемости для обычного пользователя, однако делает текст практически не обрабатываемым для библиотек NLP.

Попробуем разбить этот текст на предложения при помощи таких библиотек как: OpenNLP, StanfordNLP и AIF:

В результате библиотеки смогли выделить следующие количество предложений:
  • StanfordNLP: 13
  • OpenNLP: 3
  • AIF: 2240

Но даже более простые проблемы, чем эта, часто неразрешимы для большинства библиотек НЛП. Основная причина в том, что они не такие уж и умные. Они основаны на моделях, которые представляют собой набор статических правил и значений. Изменения в правилах или значениях зачастую требуют переобучения модели. А это довольно долго и затратно. Избежать этого (использования языковых моделей) — фундаментальная идея нашей библиотеки.

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

Так каким же образом AIF разбивает текст на предложения?


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

Результаты расчёта вероятности того, что символ используется для разделения предложений приведены ниже

Пример №1 (The Legendary History of the Cross)

archive.org/details/legendaryhistor00veld



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

Пример №2 (Punch, Or the London Charivari, Volume 107, December 8th, 1894)

www.gutenberg.org/ebooks/46816



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

Пример № 3 (William S.Burroughs. Naked lunch)

en.wikipedia.org/wiki/Naked_Lunch



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

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

Полученные результаты легко воспроизвести, воспользовавшись CLI, который использует нашу библиотеку.

Простейший CLI для AIF



Вы можете воспользоваться им следующий образом:
java -jar aif-cli.jar <key> <path_to_txt_file>

К примеру, вы можете разделить Ваш текст на предложения, используя команду:
java -jar aif-cli.jar —ssplit <path_to_txt_file>

Или же на токены:
java -jar aif-cli.jar —tsplit <path_to_txt_file>

Или же вы можете вывести символы с наибольшей вероятностью того, что они являются разделителями предложений:
java -jar aif-cli.jar —ess <path_to_txt_file>


Использование библиотеки AIF


Вы можете начать использовать нашу библиотеку версии Alpha 1 в вашем проекте. Для этого необходимо просто присоединить наш репозиторий Maven к проекту. Инструкция можно найти тут: github.com/b0noI/AIF2/wiki

На данный момент доступны лишь две функции:


Что планируется в следующей версии?


В первой Альфе мы не разделяем символы, которые являются разделитилями предложений на группы, к примеру:
  • Группа 1: .!?
  • Группа 2: “;’()
  • Группа 3: ,:

Пока мы работаем со всеми «разделителями», как если бы они все находились в группе 1. Тем не менее начиная с Альфа2 версии у нас будет разделение на группы (совершенно верно, наша библиотека может подразделять «символы-разделители» без языковой модели!)

Также в Alpha 2 мы представим модуль лемматизации, который будет извлекать леммы из текста. И вновь, этот модуль будет работать полностью независимо от языка! AIF сможет извлекать леммы из текста, к примеру:

car, cars, car's, cars' => car


Поскольку в версии Alpha 2 НЕ БУДЕТ реализована возможность семантического анализа, то это означает, что мы не сможет извлечь леммы, как эта:

am, are, is => be


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

Что планируется в следующей статье?


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


Послесловие


Само собой, текущая реализация не работает одинаково хорошо со всеми языками. Например, японский текст или языки, в которых не используют пробелы, все еще непонятный для AIF.

Наша команда


Kovalevskyi Viacheslav – algorithm developer, architecture design, team lead (viacheslav@b0noi.com / @b0noi)
Ifthikhan Nazeem – algorithm designer, architecture design, developer
Evgeniy Dolgikh(marcon@atsy.org.ua, marcon) – QA assistance, junior developer
Siarhei Varachai – QA assistance, junior developer
Balenko Aleksey (podorozhnick@gmail.com) – worked on Sentence Splitters for tests (using Stanford NLP and AIF NLP), added tokenization support for CLI, junior developer
Sviatoslav Glushchenko — REST design and implementation, developer
Oleg Kozlovskyi QA (integration and qaulity testing), developer.

Если у вас есть интересный проект NLP, свяжитесь с нами ;)

Ссылки на проект и подробности




Послесловие ^2


Честно говоря, библиотека не является полной новинкой. В начале пути своей кандидатской я уже выкладывал часть алгоритмов в сыром виде и даже написал об этом статью на Хабр. Однако с тех пор много воды утекло, множество гипотез подтвердились, много было отвергнуто. Стала острая необходимость написать новую реализацию, которая воплощает накопленные и проверенные гипотезы в области НЛП.

Только в этот раз получилось привлечь к проекту больше разработчиков и мы пытаемся подойти к разработке более последовательно, нежели было в прошлый раз. Плюс получился очень неплохой проект на котором слушатели моего курса Java на Хекслет могут получить реальный опыт разработки проекта на Java в команде;)
Viacheslav V Kovalevskyi @b0noII
карма
44,2
рейтинг 2,4
Backend Developer, ML
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

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

  • +8
    Этот текст имеет ряд нестандартно закодированных символов, но мы сделаем его еще хуже, заменив символ “." на "¸".

    Давайте тогда заменим ещё и все пробелы на слово «грязь» и проверим, как работают NLP библиотеки. Зачем создавать дополнительные неестественные трудности, а затем пытаться решить их?

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

    Так что же это за формула, и почему она не является языковой моделью, от которых вы так стремитесь уйти?

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

    Мне кажется, или во всех примерах «наиболее вероятные» разделители предложений на самом деле такими не являются?

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

    Чем это проще обычного составления списка символов-разделителей?
    Как это решает проблему контекста, когда символ может являться или не являться разделителем предложений (например, точка в аббревиатурах — С.С.С.Р.)?

    Поскольку в версии Alpha 2 НЕ БУДЕТ реализована возможность семантического анализа, то это означает, что мы не сможет извлечь леммы, как эта:

    am, are, is => be

    Тогда это стемминг, а не лемматизация. Как этот стемминг будет реализован без статистической модели и без языкозависимых правил — тоже непонятно.
    • +1
      Прежде чем ответить на Ваши вопросы я хочу поблагодарить Вас за конструктивный, а главное полезный комментарий.

      Давайте тогда заменим ещё и все пробелы на слово «грязь» и проверим, как работают NLP библиотеки. Зачем создавать дополнительные неестественные трудности, а затем пытаться решить их?


      Как было сказано в статье, книга изначально была непригодной для обработки стандартными библиотеками. Там были использованы кавычки и еще несколько символов в нестандартной кодировке. Т.е. без дополнительных искажений использовать данную (и очень много других) книгу после OCR с указанными NLP библиотеки НЕЛЬЗЯ. Просто без изменений результат получается не таким очевидным и требует дополнительных пояснений. Так что введение доп. искаженного символа вызвано лишь ленью)

      По поводу замены пробела на слово «грязь» то AIF действительно не сможет определить его как пробел. Но не потому, что алгоритм этого не может, а конкретная реализация пока не умеет искать в качестве пробела множество символов — сейчас мы подразумеваем, что это один символ (и это действительно «костыль»). А вот если заменить пробел, скажем символом «а», то алгоритм сможет определить, что это пробел. Единственное, в таком случае мы не сможем сказать, где символ «а» используется как пробел, а где как символ. Подозреваю, что ответ на это не смог бы дать и человек, который бы попытался изучить новый язык без данных о нем.

      Так что же это за формула, и почему она не является языковой моделью, от которых вы так стремитесь уйти?


      Вы правы в том, что любую формулу/эвристики можно назвать моделью. На самом деле невозможно обойтись без модели. Концептуальная разница между языково-независимым подходом и языково-зависимым в том, что первый строит модель текста непосредственно из самого входного текста. В то время как второй подход ожидает на вход текст + модель. В результате качество будет зависеть от того, насколько схожи тексты, на которых была натренирована модель с входным текстом. Этот подход накладывает серьезные ограничения на входной текст.

      Мне кажется, или во всех примерах «наиболее вероятные» разделители предложений на самом деле такими не являются?


      Как я уже сказал в Alpha1 мы еще не умеем делить символы на группы, т.е. мы выделяем подмножество «технических символов». Однако в unstable брачные уже есть код, который, имея эти данные, может разбить символы на группы и сказать, что символы "?!." делят текст на предложения, а остальные делят само предложение внутри. И, повторюсь, это мы делаем не зная какой язык во входном тексте.

      Чем это проще обычного составления списка символов-разделителей?
      Как это решает проблему контекста, когда символ может являться или не являться разделителем предложений (например, точка в аббревиатурах — С.С.С.Р.)?


      Это не проще, а сложней. Однако на огромной кучи книг после OCR скачанных с того же gutenberg library символы используются в нестандартной кодировке. А, соотвественно, стандартные модели, которые идут из коробки в OpenNLP не могут их разбить. Само собой можно потренировать, но зачем это нужно, если общий алгоритм, который определяет нужные символы сразу?

      По поводу С.С.С.Р., то пока эта часть не решена, и она не может быть решена до тех пор, пока мы не доделаем семантический анализатор, который умеет понимать сущности такого порядка. Для того, чтобы понять забыл человек поставить пробел или это аббревиатура можно:
      — или захардкодить разные аббревиатуры и другие аномалии (что просто совсем не работает при обработке, ну, например, чатов школьников из ICQ)
      — проведя семантический анализ ответить на этот вопрос

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

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


      И вновь, вы полностью правы. Мы просто думали делать один модуль, который назвать лематизатор, так как рано или поздно он будет выполнять именно эту функцию. Однако мы пересмотрели подходи и, дабы не путаться с терминами, в Alpha2 будет именно стемминг модуль.
      • 0
        Как было сказано в статье, книга изначально была непригодной для обработки стандартными библиотеками. Там были использованы кавычки и еще несколько символов в нестандартной кодировке. Т.е. без дополнительных искажений использовать данную (и очень много других) книгу после OCR с указанными NLP библиотеки НЕЛЬЗЯ. Просто без изменений результат получается не таким очевидным и требует дополнительных пояснений. Так что введение доп. искаженного символа вызвано лишь ленью)

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

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

        Модель — это любая система, которая каким-то образом отражает реальную исследуемую систему. Математическая модель — это, грубо говоря, некоторая параметрическая функция, формула. Эта формула может быть простой и топорной, как линейная регрессия, а может быть и невероятно гибкой и сложной, как полный байесовский классификатор. Но она всегда есть, вы в том числе сами про неё упоминаете. Если вы собираетесь с этим где-то защищаться, то ни в коем случае не говорите, что у вас нет модели. Вместо этого опишите свою формулу, её параметры и алгоритмы функционирования (обучения, применения, оценки, etc.).

        Как я уже сказал в Alpha1 мы еще не умеем делить символы на группы, т.е. мы выделяем подмножество «технических символов». Однако в unstable брачные уже есть код, который, имея эти данные, может разбить символы на группы и сказать, что символы "?!." делят текст на предложения, а остальные делят само предложение внутри. И, повторюсь, это мы делаем не зная какой язык во входном тексте.

        Вы всё равно рассчитываете на какой-то класс языков, а не на все возможные. В некоторых языках нет разделителя между словами (хороший пример — немецкий с его слитными прилагательными), в других — практически всё зависит от контекста (китайский, например), в третьих вообще нет письменности. И главное, чем более общими будут ваши модели, тем медленнее и менее точно они будут работать. Как уже сказали ниже, there's no free lunch.

        • 0
          Если OCR даёт неверную кодировку, то можно просто задать подходящий конвертер в юникод и дальше работать с нормализованным текстом. Складывается впечатление, что вы воюете с ветряными мельницами: вместо того, чтобы заниматься автоматическим переводом, семантическим поиском, автореферрированием и т.д. вы пытаетесь решить задачу, которая и без того уже неплохо решена на практике.


          Книги на Гутенбрге уже распознаны так что распознать их заново с другими настройками нельзя. А проблему я похоже обозначил не совсем корректно. Например в книге были распознаны кавычки вот так ” а не так ". В свое время мне пришлось писать скрипт который отображал книгу на символы с которыми могла работать NLP библиотека. Упомянутые OpenNLP и StanfordNLP из коробки не работали. А маппинг получилось сделать только написав в ручную скрипт.

          Модель — это любая система, которая каким-то образом отражает реальную исследуемую систему. Математическая модель — это, грубо говоря, некоторая параметрическая функция, формула. Эта формула может быть простой и топорной, как линейная регрессия, а может быть и невероятно гибкой и сложной, как полный байесовский классификатор. Но она всегда есть, вы в том числе сами про неё упоминаете. Если вы собираетесь с этим где-то защищаться, то ни в коем случае не говорите, что у вас нет модели. Вместо этого опишите свою формулу, её параметры и алгоритмы функционирования (обучения, применения, оценки, etc.).


          Вы правы, конечно же модель есть. Хотя языковой модели (в значении в котором употребляют ее в НЛП) нету. Собственно из-за того что в статье не обозначены четко термины и появилась эта путаница. В следующий раз подойдем к терминам более основательно.

          Вы всё равно рассчитываете на какой-то класс языков, а не на все возможные. В некоторых языках нет разделителя между словами (хороший пример — немецкий с его слитными прилагательными), в других — практически всё зависит от контекста (китайский, например), в третьих вообще нет письменности. И главное, чем более общими будут ваши модели, тем медленнее и менее точно они будут работать. Как уже сказали ниже, there's no free lunch.


          Да, у AIF есть множество ограничений и условий которые накладываются на входящий тексте. Постараемся их максимально формализовать;
      • 0
        По поводу С.С.С.Р., то пока эта часть не решена, и она не может быть решена до тех пор, пока мы не доделаем семантический анализатор, который умеет понимать сущности такого порядка.

        Так вы будете решать обратную задачу. Поясню: токенизация на предложения один из первых (а в вашем случае первый, т.к. не нужно определение языка) этапов лингвистического препроцессинга. От ее точности зависит точность работы лингвистического процесса. То есть в семантический анализатор уже будет «заложена» ошибка токенизации. Можно, конечно, сделать итеративный процесс улучшения качества: после семантики вернуть результат на токенизацию и т.д., но скорость такой обработки… думаю, в рукопашную будет быстрее.
        А скорость — это один из главных факторов обработки текстовой информации. Например, ежедневный поток рунета 15-20 млн. документов. Для его обработки скорость всего конвейера должна составлять 50-150 кБайт в сек. Скорость токенизации на предложения 5-10 МБайт/с. При этом, повторяю, качество токенизации влияет на качество всей последующей обработки.
        Мне кажется, можно сделать гибридный подход, подключив какие-то примитивные и частотные списки (тот же С.С.С.Р) для токенизации, но тогда вы теряете языконезависимость.
  • +4
    Насколько я понял основную идею проекта, реализуется «чистый эксперимент». На вход системы подаются тексты, и языковая модель выстраивается на основании их обработки, с минимумом внесённых вручную знаний.Я, в своё время, делал нечто подобное. Прогнав мегабайты текстов, получил модель, которая делала лемматизацию большинства слов — то есть, устанавливала соответствие для слов в разных грамматических формах между собой, и даже позволяла проводить вычленение знаний- что апельсин оранжевый, а огурец зелёный.

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

    Мне очень интересно почитать, в чём предлагаемая NLP библиотека будет лучше имеющихся токенизаторов и синтаксических библиотек? Увы, но что она будет работать намного медленнее — я уверен.
    • 0
      Вы правы, скорость — это конек библиотек, которые используют уже обученные модели. По факту, время работы обычной библиотеки также очень велико, но два факта делают это незаметным:

      — модели можно тренировать до их использования;
      — модели можно использовать много раз.

      Само собой AIF будет работать медленней. И сели честно, первая версия было ОЧЕНЬ медленной. Помимо всего сказанного, это была еще одна причина переписать AIF, а не делать все на базе старой версии.

      По поводу качества, то уже ко второй статье мы подготовим более детальное сравнение качества и скорости. Для того, чтобы понять порядки, то хочу сказать, что для обработки книг это занимает не более секунды (токинизация и разбитие на предложения). Но конкретику нужно подождать до конца Октября.

      Спасибо за ссылку на вашу систему QA, — на досуге гляну. А есть код где посмотреть?
  • +3
    Не могли бы вы пояснить графики для примеров 1 и 2, почему там по оси-Y одни нули?

    И ещё все примеры англоязычные, есть какой-нибудь минимальный пример разбиения текста на русском? Например, разбить саму приведенную статью на предложения.
    • +1
      Не могли бы вы пояснить графики для примеров 1 и 2, почему там по оси-Y одни нули?


      Виноват, мой косяк. В последний момент поменял тип графика и не обратил внимание, что Pages испортили ось-Y — в целом, там вероятность и суть он все еще отображает верно. Завтра постараюсь глянуть чего там сломалось.

      И ещё все примеры англоязычные, есть какой-нибудь минимальный пример разбиения текста на русском? Например, разбить саму приведенную статью на предложения.


      Для следующей статьи мы готовим примеры и анализ качества на разных языках, в том числе и на русском.
  • +1
    Рекомендую делать библиотеку под уже существующую платформу, например под GATE или UIMA. В конечном итоге будете реализовывать то, что уже там есть.

    Например, для практической обработки очень полезно сохранять оригинальный текст «как есть». А слова/токены/предложения представлять в виде интервалов(спанов) + данных.
    • 0
      Данный вопрос у нас в команде обсуждают уже не первый день. Возможно поддержку, как минимум, спанов таки сделаем, но пока нету конкретных планов по этому поводу.

      В основном причина банальна — нехватает разработчиков на все задачи, а поддержка спанов — это не такая и простая задача, как может показаться и требует инвестирования времени. А с этим в добровольных проектах всегда беда.
  • +2
    В следующей статье можете сравниться, к примеру, вот с этой моделью деления на предложения.
    • 0
      Спасибо большое за ссылку на статью, она очень интересна. А есть ли имплементация указанного метода? Постараемся сравнить.

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

      Однако допускаю, что на части случаев и языков (например с Корейским языком) AIF может показать более лучший результат. Еще мне кажется это относится и к парсингу дампов чатов. Но это лишь догадки. Нужно сравнивать. Нужно провести сравнение и это будет очень любопытно, — постараемся, но до следующей статьи не обещаем.
  • +6
    Если коротко, то имея огромную кучу текстов, можно прикинуть с какой вероятностью каждое слово употребляется с другим словом. Это очень грубое объяснение, но оно, как мне кажется, точно отражает суть. В результате получается строить более-менее приличные переводы (привет Google Translate). Этот подход не приближает нас к пониманию текста, а лишь пытается найти похожие предложения и на их базе построить перевод.

    Языковые модели не могут провести семантический анализ текста. Они избегают понимания текста на этапе синтаксического анализа. Модель языка может помочь разбить текст на предложения, провести извлечение сущностей (NER), feeling extraction. Тем не менее модель не может определить смысл текста, к примеру, не сможет составить приемлемое резюме текста.


    Определение языковой модели было правильное: это P(words) и ничего более — даешь на вход набор токенов, получаешь его вероятность в данном языке. А вот дальше какая-то каша начинается. Перевод с помощью одних только языковых моделей не сделаешь (языковые модели там используются, чтобы выбирать более-менее человеческие предложения); не встречал, чтобы для задач NER или анализа тональности как-то языковые модели применялись, да и для токенизации тоже. Неправильно все статистические методы «языковой моделью» называть.

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

    Вы, по сути, решаете другую задачу — не задачу разбиения текста на предложения, а задачу нахождения символов, которые могут использоваться для разбиения текста на предложения в данном наборе текстов. Т.е. вы можете найти, что "¸" выполняет функцию точки, но не можете определить, является ли этот символ концом предложения в данном конкретном случае — например, «Бондаренко Н. В.» — первая точка — не разделитель, вторая — возможно, разделитель. Так? Все делилки текста на предложения решают именно эту задачу, а не вашу. Это не значит, что они плохие. Это также не значит, что то, что вы делаете — бессмысленно (иногда задача определения набора разделителей и правда может стоять). Но это другая задача. «Традиционная» задача сегментации выглядит сложнее и полезнее.

    Есть методы языко-независимого построения делилок текста на предложения — см., например, Punkt; реализация в NLTK, например, доступна. Идея Punkt в том, чтоб по набору «сырых» текстов определить аббривеатуры / сокращения, характерные для языка, т.к. для большинства практических задач именно это является главной сложностью, а не то, что набор возможных разделителей неизвестен. Правда, не сказал бы, что работает очень уж хорошо.

    привязанность к кодировке

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

    А это значит, что для понимания сообщения на каком-либо языке нам не нужно ничего, кроме самого сообщения. При условии, что это сообщение достаточно большое. Именно эта идея и положена в основу библиотеки под названием AIF. За деталями прошу пожаловать под кат.

    Так не бывает. Если не задавать никаких ограничений на набор допустимых решений, то получится мусор. См. No Free Lunch. Кроме самого сообщения нужно еще какое-то множество предположений о структуре этого сообщения, набор каких-то ограничений. Всегдя лучше, когда эти ограничения прописаны явно.

    Дальше субъективно, обратная связь, как AIF2 выглядит со стороны. Сразу скажу — я не знаю, соответствует ли впечатление тому, что на самом деле. Но все же. Звучит «понимание» больно уж рекламно, причем рекламность рассчитана на людей, не имеющих знаний в области NLP. Библиотека, как я понял, пока умеет только находить возможные разделители слов и предложений для данного набора текстов по какому-то неописанному алгоритму (совет — в документации и вики описывать алгоритмы, а не детали установки java-пакетов). Что в некоторых синтетических специально подобранных примерах позволяет разбить текст на предложения лучше, чем это делают существующие делилки текста на предложения. Авторы используют термин «языковая модель» странным образом и не ссылаются на существующие unsupervised алгоритмы разбиения текста на предложения (обычно это знак того, что о них и не знают). Куча громких слов про семантику и понимание текста, про то, как все сейчас плохо, но никаких результатов, одни намерения. Ну и вербовка под все это дело новичков в NLP (которые под сомнение подходы ставить не будут?). Еще раз повторюсь — я без понятия, так ли все это на самом деле; код я не читал, в деталях не разбирался, но просто так это выглядит.
    • 0
      Благодарю за столь емкий, а главное дельный комментарий.

      Определение языковой модели было правильное: это P(words) и ничего более — даешь на вход набор токенов, получаешь его вероятность в данном языке. А вот дальше какая-то каша начинается. Перевод с помощью одних только языковых моделей не сделаешь (языковые модели там используются, чтобы выбирать более-менее человеческие предложения); не встречал, чтобы для задач NER или анализа тональности как-то языковые модели применялись, да и для токенизации тоже. Неправильно все статистические методы «языковой моделью» называть.


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

      Например OpenNLP модель Английского текста, которая используется для разбивки текста на предложения, включает в себя набор шаблонов предложений и их статистику (по поводу второго уже не помню, давно не заглядывал под «капот» их моделек). Под шаблонами они понимают регулярные выражения, создаваемые из размеченных корпусов. Процесс простой, но для вменяемого качества модели языка требует ОЧЕНЬ большого размера корпуса для обучения и при этом все равно завязан на конкретный язык и конкретные символы, используемые в языке.

      Вы, по сути, решаете другую задачу — не задачу разбиения текста на предложения, а задачу нахождения символов, которые могут использоваться для разбиения текста на предложения в данном наборе текстов. Т.е. вы можете найти, что "¸" выполняет функцию точки, но не можете определить, является ли этот символ концом предложения в данном конкретном случае — например, «Бондаренко Н. В.» — первая точка — не разделитель, вторая — возможно, разделитель. Так? Все делилки текста на предложения решают именно эту задачу, а не вашу. Это не значит, что они плохие. Это также не значит, что то, что вы делаете — бессмысленно (иногда задача определения набора разделителей и правда может стоять). Но это другая задача. «Традиционная» задача сегментации выглядит сложнее и полезнее.


      И вновь, вы правы. Мы рассматриваем разбитие текста на предложения в следующие этапы:
      1. выделение символов, которые не используются для построения токенов (мы их называем техническими);
      2. выделение из найденных символов группу символов, которые разбивают текст на предложения(.?!), и группу символов, которые разбивают само предложение на части(:;,);
      3. определение в каких случаях первая группа символов используется для разделения текста на предложения, а в каких нет.

      Третий пункт, — при условии, что алгоритм не должен зависеть от текста, — можно сделать лишь во время семантического анализа. У нас есть несколько гипотез, которые мы применим для решения этой проблемы. Но в данный момент, как было справедливо упомянуто, мы решаем лишь первые две задачи и не решаем третью. Справедливости ради скажу, что решение второй задачи, хоть уже и реализовано, но пока не выкатили далее бранча unstable.

      Почему же мы, не решая все три задачи, все же начинаем проводить сравнение себя с остальными? Очень просто — есть модуль, который решает для пользователей задачу деления текста на предложения.

      Есть методы языко-независимого построения делилок текста на предложения — см., например, Punkt; реализация в NLTK, например, доступна. Идея Punkt в том, чтоб по набору «сырых» текстов определить аббривеатуры / сокращения, характерные для языка, т.к. для большинства практических задач именно это является главной сложностью, а не то, что набор возможных разделителей неизвестен. Правда, не сказал бы, что работает очень уж хорошо.


      С таким китом как NLTK само собой сравним, но для начала пилим сравнение с Java библиотеками и после, само собой, пойдем и к NLTK. Тем более я с большим трепетом отношусь к Python'у =) По поводу ссылки и Punkt; огромное спасибо, так как я данную статью не видел и не читал.

      Так не бывает. Если не задавать никаких ограничений на набор допустимых решений, то получится мусор. См. No Free Lunch. Кроме самого сообщения нужно еще какое-то множество предположений о структуре этого сообщения, набор каких-то ограничений. Всегдя лучше, когда эти ограничения прописаны явно.


      И вновь правы на все 100. Любой подход и формула, которую мы используем, имеет в себе заложенные нами ограничения на входящее сообщение и их действительно нужно указать явно. Ну, например, текущая версия AIF совершенно не работает в случае, если в языке совсем нету пробелов.

      Дальше субъективно, обратная связь, как AIF2 выглядит со стороны. Сразу скажу — я не знаю, соответствует ли впечатление тому, что на самом деле. Но все же. Звучит «понимание» больно уж рекламно, причем рекламность рассчитана на людей, не имеющих знаний в области NLP. Библиотека, как я понял, пока умеет только находить возможные разделители слов и предложений для данного набора текстов по какому-то неописанному алгоритму (совет — в документации и вики описывать алгоритмы, а не детали установки java-пакетов). Что в некоторых синтетических специально подобранных примерах позволяет разбить текст на предложения лучше, чем это делают существующие делилки текста на предложения. Авторы используют термин «языковая модель» странным образом и не ссылаются на существующие unsupervised алгоритмы разбиения текста на предложения (обычно это знак того, что о них и не знают). Куча громких слов про семантику и понимание текста, про то, как все сейчас плохо, но никаких результатов, одни намерения. Ну и вербовка под все это дело новичков в NLP (которые под сомнение подходы ставить не будут?). Еще раз повторюсь — я без понятия, так ли все это на самом деле; код я не читал, в деталях не разбирался, но просто так это выглядит.


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

      — более четко обозначить термины, которые мы используем и разделить каждый этап (например как разбитие текста на предложения) на под этапы;
      — провести количественный анализ сравнивая, как минимум с одной альтернативной реализацией;
      — описать уже существующую реализацию алгоритма на вики и перевод в статье;

      Даже этих трех пунктов с головой хватит на статью неменьшего размера чем текущая. Спасибо!

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.