Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 15
Этот текст имеет ряд нестандартно закодированных символов, но мы сделаем его еще хуже, заменив символ “." на "¸".
Давайте тогда заменим ещё и все пробелы на слово «грязь» и проверим, как работают NLP библиотеки. Зачем создавать дополнительные неестественные трудности, а затем пытаться решить их?
Для выделения символов, которые делят текст на предложения, мы разработали специальную формулу — для каждого символа вычисляется вероятность того, что именно он является разделителем.
Так что же это за формула, и почему она не является языковой моделью, от которых вы так стремитесь уйти?
В этой диаграмме отображены символы, которые имеют наибольшую вероятность того, что именно они используются для разделения предложений.
Мне кажется, или во всех примерах «наиболее вероятные» разделители предложений на самом деле такими не являются?
Конечно, наличия таких вероятностей не дает сам результат. Вам все еще необходимо понять, где предел, который делит эти символы на «разделители» и «остальные символы» предложений
Чем это проще обычного составления списка символов-разделителей?
Как это решает проблему контекста, когда символ может являться или не являться разделителем предложений (например, точка в аббревиатурах — С.С.С.Р.)?
Поскольку в версии Alpha 2 НЕ БУДЕТ реализована возможность семантического анализа, то это означает, что мы не сможет извлечь леммы, как эта:
am, are, is => be
Тогда это стемминг, а не лемматизация. Как этот стемминг будет реализован без статистической модели и без языкозависимых правил — тоже непонятно.
Прежде чем ответить на Ваши вопросы я хочу поблагодарить Вас за конструктивный, а главное полезный комментарий.
Как было сказано в статье, книга изначально была непригодной для обработки стандартными библиотеками. Там были использованы кавычки и еще несколько символов в нестандартной кодировке. Т.е. без дополнительных искажений использовать данную (и очень много других) книгу после OCR с указанными NLP библиотеки НЕЛЬЗЯ. Просто без изменений результат получается не таким очевидным и требует дополнительных пояснений. Так что введение доп. искаженного символа вызвано лишь ленью)
По поводу замены пробела на слово «грязь» то AIF действительно не сможет определить его как пробел. Но не потому, что алгоритм этого не может, а конкретная реализация пока не умеет искать в качестве пробела множество символов — сейчас мы подразумеваем, что это один символ (и это действительно «костыль»). А вот если заменить пробел, скажем символом «а», то алгоритм сможет определить, что это пробел. Единственное, в таком случае мы не сможем сказать, где символ «а» используется как пробел, а где как символ. Подозреваю, что ответ на это не смог бы дать и человек, который бы попытался изучить новый язык без данных о нем.
Вы правы в том, что любую формулу/эвристики можно назвать моделью. На самом деле невозможно обойтись без модели. Концептуальная разница между языково-независимым подходом и языково-зависимым в том, что первый строит модель текста непосредственно из самого входного текста. В то время как второй подход ожидает на вход текст + модель. В результате качество будет зависеть от того, насколько схожи тексты, на которых была натренирована модель с входным текстом. Этот подход накладывает серьезные ограничения на входной текст.
Как я уже сказал в Alpha1 мы еще не умеем делить символы на группы, т.е. мы выделяем подмножество «технических символов». Однако в unstable брачные уже есть код, который, имея эти данные, может разбить символы на группы и сказать, что символы "?!." делят текст на предложения, а остальные делят само предложение внутри. И, повторюсь, это мы делаем не зная какой язык во входном тексте.
Это не проще, а сложней. Однако на огромной кучи книг после OCR скачанных с того же gutenberg library символы используются в нестандартной кодировке. А, соотвественно, стандартные модели, которые идут из коробки в OpenNLP не могут их разбить. Само собой можно потренировать, но зачем это нужно, если общий алгоритм, который определяет нужные символы сразу?
По поводу С.С.С.Р., то пока эта часть не решена, и она не может быть решена до тех пор, пока мы не доделаем семантический анализатор, который умеет понимать сущности такого порядка. Для того, чтобы понять забыл человек поставить пробел или это аббревиатура можно:
— или захардкодить разные аббревиатуры и другие аномалии (что просто совсем не работает при обработке, ну, например, чатов школьников из ICQ)
— проведя семантический анализ ответить на этот вопрос
Первый вариант именно тот, что использует большая часть библиотек. И как уже сказал, когда с таким подходом начинаешь анализировать чаты — это уныние.
И вновь, вы полностью правы. Мы просто думали делать один модуль, который назвать лематизатор, так как рано или поздно он будет выполнять именно эту функцию. Однако мы пересмотрели подходи и, дабы не путаться с терминами, в Alpha2 будет именно стемминг модуль.
Давайте тогда заменим ещё и все пробелы на слово «грязь» и проверим, как работают NLP библиотеки. Зачем создавать дополнительные неестественные трудности, а затем пытаться решить их?
Как было сказано в статье, книга изначально была непригодной для обработки стандартными библиотеками. Там были использованы кавычки и еще несколько символов в нестандартной кодировке. Т.е. без дополнительных искажений использовать данную (и очень много других) книгу после OCR с указанными NLP библиотеки НЕЛЬЗЯ. Просто без изменений результат получается не таким очевидным и требует дополнительных пояснений. Так что введение доп. искаженного символа вызвано лишь ленью)
По поводу замены пробела на слово «грязь» то AIF действительно не сможет определить его как пробел. Но не потому, что алгоритм этого не может, а конкретная реализация пока не умеет искать в качестве пробела множество символов — сейчас мы подразумеваем, что это один символ (и это действительно «костыль»). А вот если заменить пробел, скажем символом «а», то алгоритм сможет определить, что это пробел. Единственное, в таком случае мы не сможем сказать, где символ «а» используется как пробел, а где как символ. Подозреваю, что ответ на это не смог бы дать и человек, который бы попытался изучить новый язык без данных о нем.
Так что же это за формула, и почему она не является языковой моделью, от которых вы так стремитесь уйти?
Вы правы в том, что любую формулу/эвристики можно назвать моделью. На самом деле невозможно обойтись без модели. Концептуальная разница между языково-независимым подходом и языково-зависимым в том, что первый строит модель текста непосредственно из самого входного текста. В то время как второй подход ожидает на вход текст + модель. В результате качество будет зависеть от того, насколько схожи тексты, на которых была натренирована модель с входным текстом. Этот подход накладывает серьезные ограничения на входной текст.
Мне кажется, или во всех примерах «наиболее вероятные» разделители предложений на самом деле такими не являются?
Как я уже сказал в Alpha1 мы еще не умеем делить символы на группы, т.е. мы выделяем подмножество «технических символов». Однако в unstable брачные уже есть код, который, имея эти данные, может разбить символы на группы и сказать, что символы "?!." делят текст на предложения, а остальные делят само предложение внутри. И, повторюсь, это мы делаем не зная какой язык во входном тексте.
Чем это проще обычного составления списка символов-разделителей?
Как это решает проблему контекста, когда символ может являться или не являться разделителем предложений (например, точка в аббревиатурах — С.С.С.Р.)?
Это не проще, а сложней. Однако на огромной кучи книг после OCR скачанных с того же gutenberg library символы используются в нестандартной кодировке. А, соотвественно, стандартные модели, которые идут из коробки в OpenNLP не могут их разбить. Само собой можно потренировать, но зачем это нужно, если общий алгоритм, который определяет нужные символы сразу?
По поводу С.С.С.Р., то пока эта часть не решена, и она не может быть решена до тех пор, пока мы не доделаем семантический анализатор, который умеет понимать сущности такого порядка. Для того, чтобы понять забыл человек поставить пробел или это аббревиатура можно:
— или захардкодить разные аббревиатуры и другие аномалии (что просто совсем не работает при обработке, ну, например, чатов школьников из ICQ)
— проведя семантический анализ ответить на этот вопрос
Первый вариант именно тот, что использует большая часть библиотек. И как уже сказал, когда с таким подходом начинаешь анализировать чаты — это уныние.
Тогда это стемминг, а не лемматизация. Как этот стемминг будет реализован без статистической модели и без языкозависимых правил — тоже непонятно.
И вновь, вы полностью правы. Мы просто думали делать один модуль, который назвать лематизатор, так как рано или поздно он будет выполнять именно эту функцию. Однако мы пересмотрели подходи и, дабы не путаться с терминами, в Alpha2 будет именно стемминг модуль.
Как было сказано в статье, книга изначально была непригодной для обработки стандартными библиотеками. Там были использованы кавычки и еще несколько символов в нестандартной кодировке. Т.е. без дополнительных искажений использовать данную (и очень много других) книгу после OCR с указанными NLP библиотеки НЕЛЬЗЯ. Просто без изменений результат получается не таким очевидным и требует дополнительных пояснений. Так что введение доп. искаженного символа вызвано лишь ленью)
Если OCR даёт неверную кодировку, то можно просто задать подходящий конвертер в юникод и дальше работать с нормализованным текстом. Складывается впечатление, что вы воюете с ветряными мельницами: вместо того, чтобы заниматься автоматическим переводом, семантическим поиском, автореферрированием и т.д. вы пытаетесь решить задачу, которая и без того уже неплохо решена на практике.
Вы правы в том, что любую формулу/эвристики можно назвать моделью. На самом деле невозможно обойтись без модели. Концептуальная разница между языково-независимым подходом и языково-зависимым в том, что первый строит модель текста непосредственно из самого входного текста. В то время как второй подход ожидает на вход текст + модель.
Модель — это любая система, которая каким-то образом отражает реальную исследуемую систему. Математическая модель — это, грубо говоря, некоторая параметрическая функция, формула. Эта формула может быть простой и топорной, как линейная регрессия, а может быть и невероятно гибкой и сложной, как полный байесовский классификатор. Но она всегда есть, вы в том числе сами про неё упоминаете. Если вы собираетесь с этим где-то защищаться, то ни в коем случае не говорите, что у вас нет модели. Вместо этого опишите свою формулу, её параметры и алгоритмы функционирования (обучения, применения, оценки, etc.).
Как я уже сказал в Alpha1 мы еще не умеем делить символы на группы, т.е. мы выделяем подмножество «технических символов». Однако в unstable брачные уже есть код, который, имея эти данные, может разбить символы на группы и сказать, что символы "?!." делят текст на предложения, а остальные делят само предложение внутри. И, повторюсь, это мы делаем не зная какой язык во входном тексте.
Вы всё равно рассчитываете на какой-то класс языков, а не на все возможные. В некоторых языках нет разделителя между словами (хороший пример — немецкий с его слитными прилагательными), в других — практически всё зависит от контекста (китайский, например), в третьих вообще нет письменности. И главное, чем более общими будут ваши модели, тем медленнее и менее точно они будут работать. Как уже сказали ниже, there's no free lunch.
Если OCR даёт неверную кодировку, то можно просто задать подходящий конвертер в юникод и дальше работать с нормализованным текстом. Складывается впечатление, что вы воюете с ветряными мельницами: вместо того, чтобы заниматься автоматическим переводом, семантическим поиском, автореферрированием и т.д. вы пытаетесь решить задачу, которая и без того уже неплохо решена на практике.
Книги на Гутенбрге уже распознаны так что распознать их заново с другими настройками нельзя. А проблему я похоже обозначил не совсем корректно. Например в книге были распознаны кавычки вот так ” а не так ". В свое время мне пришлось писать скрипт который отображал книгу на символы с которыми могла работать NLP библиотека. Упомянутые OpenNLP и StanfordNLP из коробки не работали. А маппинг получилось сделать только написав в ручную скрипт.
Модель — это любая система, которая каким-то образом отражает реальную исследуемую систему. Математическая модель — это, грубо говоря, некоторая параметрическая функция, формула. Эта формула может быть простой и топорной, как линейная регрессия, а может быть и невероятно гибкой и сложной, как полный байесовский классификатор. Но она всегда есть, вы в том числе сами про неё упоминаете. Если вы собираетесь с этим где-то защищаться, то ни в коем случае не говорите, что у вас нет модели. Вместо этого опишите свою формулу, её параметры и алгоритмы функционирования (обучения, применения, оценки, etc.).
Вы правы, конечно же модель есть. Хотя языковой модели (в значении в котором употребляют ее в НЛП) нету. Собственно из-за того что в статье не обозначены четко термины и появилась эта путаница. В следующий раз подойдем к терминам более основательно.
Вы всё равно рассчитываете на какой-то класс языков, а не на все возможные. В некоторых языках нет разделителя между словами (хороший пример — немецкий с его слитными прилагательными), в других — практически всё зависит от контекста (китайский, например), в третьих вообще нет письменности. И главное, чем более общими будут ваши модели, тем медленнее и менее точно они будут работать. Как уже сказали ниже, there's no free lunch.
Да, у AIF есть множество ограничений и условий которые накладываются на входящий тексте. Постараемся их максимально формализовать;
По поводу С.С.С.Р., то пока эта часть не решена, и она не может быть решена до тех пор, пока мы не доделаем семантический анализатор, который умеет понимать сущности такого порядка.
Так вы будете решать обратную задачу. Поясню: токенизация на предложения один из первых (а в вашем случае первый, т.к. не нужно определение языка) этапов лингвистического препроцессинга. От ее точности зависит точность работы лингвистического процесса. То есть в семантический анализатор уже будет «заложена» ошибка токенизации. Можно, конечно, сделать итеративный процесс улучшения качества: после семантики вернуть результат на токенизацию и т.д., но скорость такой обработки… думаю, в рукопашную будет быстрее.
А скорость — это один из главных факторов обработки текстовой информации. Например, ежедневный поток рунета 15-20 млн. документов. Для его обработки скорость всего конвейера должна составлять 50-150 кБайт в сек. Скорость токенизации на предложения 5-10 МБайт/с. При этом, повторяю, качество токенизации влияет на качество всей последующей обработки.
Мне кажется, можно сделать гибридный подход, подключив какие-то примитивные и частотные списки (тот же С.С.С.Р) для токенизации, но тогда вы теряете языконезависимость.
Насколько я понял основную идею проекта, реализуется «чистый эксперимент». На вход системы подаются тексты, и языковая модель выстраивается на основании их обработки, с минимумом внесённых вручную знаний.Я, в своё время, делал нечто подобное. Прогнав мегабайты текстов, получил модель, которая делала лемматизацию большинства слов — то есть, устанавливала соответствие для слов в разных грамматических формах между собой, и даже позволяла проводить вычленение знаний- что апельсин оранжевый, а огурец зелёный.
Но. Это работало настолько долго и требовало столько ресурсов, что практической значимости этот проект не имел. Заменив подобную самообучающуюся модель на лемматизацию на основе словаря и тезауруса, я получил вменяемую скорость разбора текста и, соответственно, смог сконцентрироваться на других задачах. Да, теоретически, разбор на основе словаря и тезауруса не сможет разобрать всякие особые случаи, например, детскую речь с коверканьем слов, но такое случается редко.
Мне очень интересно почитать, в чём предлагаемая NLP библиотека будет лучше имеющихся токенизаторов и синтаксических библиотек? Увы, но что она будет работать намного медленнее — я уверен.
Но. Это работало настолько долго и требовало столько ресурсов, что практической значимости этот проект не имел. Заменив подобную самообучающуюся модель на лемматизацию на основе словаря и тезауруса, я получил вменяемую скорость разбора текста и, соответственно, смог сконцентрироваться на других задачах. Да, теоретически, разбор на основе словаря и тезауруса не сможет разобрать всякие особые случаи, например, детскую речь с коверканьем слов, но такое случается редко.
Мне очень интересно почитать, в чём предлагаемая NLP библиотека будет лучше имеющихся токенизаторов и синтаксических библиотек? Увы, но что она будет работать намного медленнее — я уверен.
Вы правы, скорость — это конек библиотек, которые используют уже обученные модели. По факту, время работы обычной библиотеки также очень велико, но два факта делают это незаметным:
— модели можно тренировать до их использования;
— модели можно использовать много раз.
Само собой AIF будет работать медленней. И сели честно, первая версия было ОЧЕНЬ медленной. Помимо всего сказанного, это была еще одна причина переписать AIF, а не делать все на базе старой версии.
По поводу качества, то уже ко второй статье мы подготовим более детальное сравнение качества и скорости. Для того, чтобы понять порядки, то хочу сказать, что для обработки книг это занимает не более секунды (токинизация и разбитие на предложения). Но конкретику нужно подождать до конца Октября.
Спасибо за ссылку на вашу систему QA, — на досуге гляну. А есть код где посмотреть?
— модели можно тренировать до их использования;
— модели можно использовать много раз.
Само собой AIF будет работать медленней. И сели честно, первая версия было ОЧЕНЬ медленной. Помимо всего сказанного, это была еще одна причина переписать AIF, а не делать все на базе старой версии.
По поводу качества, то уже ко второй статье мы подготовим более детальное сравнение качества и скорости. Для того, чтобы понять порядки, то хочу сказать, что для обработки книг это занимает не более секунды (токинизация и разбитие на предложения). Но конкретику нужно подождать до конца Октября.
Спасибо за ссылку на вашу систему QA, — на досуге гляну. А есть код где посмотреть?
Не могли бы вы пояснить графики для примеров 1 и 2, почему там по оси-Y одни нули?
И ещё все примеры англоязычные, есть какой-нибудь минимальный пример разбиения текста на русском? Например, разбить саму приведенную статью на предложения.
И ещё все примеры англоязычные, есть какой-нибудь минимальный пример разбиения текста на русском? Например, разбить саму приведенную статью на предложения.
Не могли бы вы пояснить графики для примеров 1 и 2, почему там по оси-Y одни нули?
Виноват, мой косяк. В последний момент поменял тип графика и не обратил внимание, что Pages испортили ось-Y — в целом, там вероятность и суть он все еще отображает верно. Завтра постараюсь глянуть чего там сломалось.
И ещё все примеры англоязычные, есть какой-нибудь минимальный пример разбиения текста на русском? Например, разбить саму приведенную статью на предложения.
Для следующей статьи мы готовим примеры и анализ качества на разных языках, в том числе и на русском.
Рекомендую делать библиотеку под уже существующую платформу, например под GATE или UIMA. В конечном итоге будете реализовывать то, что уже там есть.
Например, для практической обработки очень полезно сохранять оригинальный текст «как есть». А слова/токены/предложения представлять в виде интервалов(спанов) + данных.
Например, для практической обработки очень полезно сохранять оригинальный текст «как есть». А слова/токены/предложения представлять в виде интервалов(спанов) + данных.
Данный вопрос у нас в команде обсуждают уже не первый день. Возможно поддержку, как минимум, спанов таки сделаем, но пока нету конкретных планов по этому поводу.
В основном причина банальна — нехватает разработчиков на все задачи, а поддержка спанов — это не такая и простая задача, как может показаться и требует инвестирования времени. А с этим в добровольных проектах всегда беда.
В основном причина банальна — нехватает разработчиков на все задачи, а поддержка спанов — это не такая и простая задача, как может показаться и требует инвестирования времени. А с этим в добровольных проектах всегда беда.
В следующей статье можете сравниться, к примеру, вот с этой моделью деления на предложения.
Спасибо большое за ссылку на статью, она очень интересна. А есть ли имплементация указанного метода? Постараемся сравнить.
Я практически уверен, что описанный в вашей статье метод покажет более лучшие результат. Моя догадка основывается на том, что в статье допускается знание о строчных и прописных буквах, т.е. на большей части текстов, большей части языков, оно будет работать корректно.
Однако допускаю, что на части случаев и языков (например с Корейским языком) AIF может показать более лучший результат. Еще мне кажется это относится и к парсингу дампов чатов. Но это лишь догадки. Нужно сравнивать. Нужно провести сравнение и это будет очень любопытно, — постараемся, но до следующей статьи не обещаем.
Я практически уверен, что описанный в вашей статье метод покажет более лучшие результат. Моя догадка основывается на том, что в статье допускается знание о строчных и прописных буквах, т.е. на большей части текстов, большей части языков, оно будет работать корректно.
Однако допускаю, что на части случаев и языков (например с Корейским языком) AIF может показать более лучший результат. Еще мне кажется это относится и к парсингу дампов чатов. Но это лишь догадки. Нужно сравнивать. Нужно провести сравнение и это будет очень любопытно, — постараемся, но до следующей статьи не обещаем.
Если коротко, то имея огромную кучу текстов, можно прикинуть с какой вероятностью каждое слово употребляется с другим словом. Это очень грубое объяснение, но оно, как мне кажется, точно отражает суть. В результате получается строить более-менее приличные переводы (привет Google Translate). Этот подход не приближает нас к пониманию текста, а лишь пытается найти похожие предложения и на их базе построить перевод.
Языковые модели не могут провести семантический анализ текста. Они избегают понимания текста на этапе синтаксического анализа. Модель языка может помочь разбить текст на предложения, провести извлечение сущностей (NER), feeling extraction. Тем не менее модель не может определить смысл текста, к примеру, не сможет составить приемлемое резюме текста.
Определение языковой модели было правильное: это P(words) и ничего более — даешь на вход набор токенов, получаешь его вероятность в данном языке. А вот дальше какая-то каша начинается. Перевод с помощью одних только языковых моделей не сделаешь (языковые модели там используются, чтобы выбирать более-менее человеческие предложения); не встречал, чтобы для задач NER или анализа тональности как-то языковые модели применялись, да и для токенизации тоже. Неправильно все статистические методы «языковой моделью» называть.
Дальше, насчет разбиения текста на предложения:
Для выделения символов, которые делят текст на предложения, мы разработали специальную формулу — для каждого символа вычисляется вероятность того, что именно он является разделителем.
Вы, по сути, решаете другую задачу — не задачу разбиения текста на предложения, а задачу нахождения символов, которые могут использоваться для разбиения текста на предложения в данном наборе текстов. Т.е. вы можете найти, что "¸" выполняет функцию точки, но не можете определить, является ли этот символ концом предложения в данном конкретном случае — например, «Бондаренко Н. В.» — первая точка — не разделитель, вторая — возможно, разделитель. Так? Все делилки текста на предложения решают именно эту задачу, а не вашу. Это не значит, что они плохие. Это также не значит, что то, что вы делаете — бессмысленно (иногда задача определения набора разделителей и правда может стоять). Но это другая задача. «Традиционная» задача сегментации выглядит сложнее и полезнее.
Есть методы языко-независимого построения делилок текста на предложения — см., например, Punkt; реализация в NLTK, например, доступна. Идея Punkt в том, чтоб по набору «сырых» текстов определить аббривеатуры / сокращения, характерные для языка, т.к. для большинства практических задач именно это является главной сложностью, а не то, что набор возможных разделителей неизвестен. Правда, не сказал бы, что работает очень уж хорошо.
привязанность к кодировке
Непонятно, причем тут кодировки. Обычно текст из исходной кодировки декодируется в юникод, и работа уже потом ведется с юникодом. Вменяемые компоненты NLP о кодировке знать, по хорошему, не должны ничего.
А это значит, что для понимания сообщения на каком-либо языке нам не нужно ничего, кроме самого сообщения. При условии, что это сообщение достаточно большое. Именно эта идея и положена в основу библиотеки под названием AIF. За деталями прошу пожаловать под кат.
Так не бывает. Если не задавать никаких ограничений на набор допустимых решений, то получится мусор. См. No Free Lunch. Кроме самого сообщения нужно еще какое-то множество предположений о структуре этого сообщения, набор каких-то ограничений. Всегдя лучше, когда эти ограничения прописаны явно.
Дальше субъективно, обратная связь, как AIF2 выглядит со стороны. Сразу скажу — я не знаю, соответствует ли впечатление тому, что на самом деле. Но все же. Звучит «понимание» больно уж рекламно, причем рекламность рассчитана на людей, не имеющих знаний в области NLP. Библиотека, как я понял, пока умеет только находить возможные разделители слов и предложений для данного набора текстов по какому-то неописанному алгоритму (совет — в документации и вики описывать алгоритмы, а не детали установки java-пакетов). Что в некоторых синтетических специально подобранных примерах позволяет разбить текст на предложения лучше, чем это делают существующие делилки текста на предложения. Авторы используют термин «языковая модель» странным образом и не ссылаются на существующие unsupervised алгоритмы разбиения текста на предложения (обычно это знак того, что о них и не знают). Куча громких слов про семантику и понимание текста, про то, как все сейчас плохо, но никаких результатов, одни намерения. Ну и вербовка под все это дело новичков в NLP (которые под сомнение подходы ставить не будут?). Еще раз повторюсь — я без понятия, так ли все это на самом деле; код я не читал, в деталях не разбирался, но просто так это выглядит.
Благодарю за столь емкий, а главное дельный комментарий.
Вы правы по поводу того, что я был очень не осторожен в использовании термина «Языковая модель» и дилетантски расширил его за пределы того, что он обозначает на самом деле. Это связанно с тем, что для многих задач библиотеки типа OpenNLP используют то, что они называют models и эти модели есть для разных языков. Однако этим модели включают в себя намного больше, чем каноническое определение языковой модели.
Например OpenNLP модель Английского текста, которая используется для разбивки текста на предложения, включает в себя набор шаблонов предложений и их статистику (по поводу второго уже не помню, давно не заглядывал под «капот» их моделек). Под шаблонами они понимают регулярные выражения, создаваемые из размеченных корпусов. Процесс простой, но для вменяемого качества модели языка требует ОЧЕНЬ большого размера корпуса для обучения и при этом все равно завязан на конкретный язык и конкретные символы, используемые в языке.
И вновь, вы правы. Мы рассматриваем разбитие текста на предложения в следующие этапы:
1. выделение символов, которые не используются для построения токенов (мы их называем техническими);
2. выделение из найденных символов группу символов, которые разбивают текст на предложения(.?!), и группу символов, которые разбивают само предложение на части(:;,);
3. определение в каких случаях первая группа символов используется для разделения текста на предложения, а в каких нет.
Третий пункт, — при условии, что алгоритм не должен зависеть от текста, — можно сделать лишь во время семантического анализа. У нас есть несколько гипотез, которые мы применим для решения этой проблемы. Но в данный момент, как было справедливо упомянуто, мы решаем лишь первые две задачи и не решаем третью. Справедливости ради скажу, что решение второй задачи, хоть уже и реализовано, но пока не выкатили далее бранча unstable.
Почему же мы, не решая все три задачи, все же начинаем проводить сравнение себя с остальными? Очень просто — есть модуль, который решает для пользователей задачу деления текста на предложения.
С таким китом как NLTK само собой сравним, но для начала пилим сравнение с Java библиотеками и после, само собой, пойдем и к NLTK. Тем более я с большим трепетом отношусь к Python'у =) По поводу ссылки и Punkt; огромное спасибо, так как я данную статью не видел и не читал.
И вновь правы на все 100. Любой подход и формула, которую мы используем, имеет в себе заложенные нами ограничения на входящее сообщение и их действительно нужно указать явно. Ну, например, текущая версия AIF совершенно не работает в случае, если в языке совсем нету пробелов.
Это лишь первая статья, целью которой было показать наши действия и понять, что именно стоит раскрывать во второй статье, которую пишем и выйдет в конце Октября. Ваш комментарий один из тех, который внес большое понимание чего необходимо в следующей статье. Во всяком случае пока план такой:
— более четко обозначить термины, которые мы используем и разделить каждый этап (например как разбитие текста на предложения) на под этапы;
— провести количественный анализ сравнивая, как минимум с одной альтернативной реализацией;
— описать уже существующую реализацию алгоритма на вики и перевод в статье;
Даже этих трех пунктов с головой хватит на статью неменьшего размера чем текущая. Спасибо!
Определение языковой модели было правильное: это 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 (которые под сомнение подходы ставить не будут?). Еще раз повторюсь — я без понятия, так ли все это на самом деле; код я не читал, в деталях не разбирался, но просто так это выглядит.
Это лишь первая статья, целью которой было показать наши действия и понять, что именно стоит раскрывать во второй статье, которую пишем и выйдет в конце Октября. Ваш комментарий один из тех, который внес большое понимание чего необходимо в следующей статье. Во всяком случае пока план такой:
— более четко обозначить термины, которые мы используем и разделить каждый этап (например как разбитие текста на предложения) на под этапы;
— провести количественный анализ сравнивая, как минимум с одной альтернативной реализацией;
— описать уже существующую реализацию алгоритма на вики и перевод в статье;
Даже этих трех пунктов с головой хватит на статью неменьшего размера чем текущая. Спасибо!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Новая языково-независимая NLP библиотека