Пользователь
0,0
рейтинг
20 июля 2012 в 02:12

Разработка → Парсим русский язык


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

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

"Мама мыла раму":

(предложение
    (именная гр. (сущ мама))
    (глаг. гр. (глаг мыла)
        (именная гр. (сущ раму)))
    (. .)))


Это называется синтаксическим деревом предложения. В графическом виде его можно представить следующим образом (в упрощенном виде):



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


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

Проблемы и задачи


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

Немного теории


Несмотря на то, что это практическая статья, а не теоретическая, мне необходимо дать немного теории, чтобы знать, чем мы будем заниматься. Итак, пусть у нас есть простое предложение «Мама мыла раму.» Что мы хотим получить в качестве результата от парсера? Существует большое количество моделей, описывающих человеческие языки, из которых я бы выделил две наиболее популярных:

  1. Грамматика составляющих (constituency grammar)
  2. Грамматика зависимостей (dependency grammar)

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

  • разбиваем предложение на именную и глагольную группы
  • именную группу разбиваем на существительное (мама)
  • глагольную группу на глагол (мыла) и на вторую именную группу
  • вторую глагольную группу на существительное (раму)

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

В грамматике зависимостей порядок слов не важен, т.к. мы хотим лишь знать от какого слова зависит каждое слово в предложении и тип этих связей. На примере это выглядит так:


В данном предложении «мама» зависит от глагола «мыть» и является субъектом, «рама» также зависит от глагола «мыть», но является «объектом». Даже если мы поменяем порядок слов в предложении, связи все равно останутся теми же. Итак, от нашего парсера мы хотим получить список зависимостей для слов в предложении. Это может выглядеть так:

"Мама мыла раму":

субъект(мама, мыла)
объект(раму, мыла)


На этом с теорией закончим и перейдем к практике.

Существующие подходы


Существует два основных подхода при создании синтаксического парсера:

  1. Метод, основанный на правилах (rule based)
  2. Машинное обучение с учителем (supervised machine learning)

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

Метод, основанный на правилах, применяется практически во всех коммерческих системах, т.к. он дает наибольшую точность. Основная идея заключается в создании набора правил, которые определяют, как проставлять связи в предложении. Например, в нашем предложении «Мама мыла раму» мы можем применять следующие правила (допустим, что мы уже сняли все неоднозначности и точно знаем грамматические категории слов):

  1. слово («мама») в именительном падеже, женском роде и единственном числе должно зависеть от глагола («мыла») в единственном числе, прошедшем времени, женском роде и тип связи должен быть «субъект»
  2. слово («раму») в винительном падеже должно зависеть от глагола и тип связи должен быть «объект»

В системе может быть много подобных правил, а также анти-правил, которые указывают, когда НЕ нужно проставлять связи, например, если у существительного и глагола различаются род или число, то между ними нет связи. Также существуют правила третьего типа, которые указывают какую пару слов следует предпочесть, если возможны несколько вариантов. Например, в предложении «мама мыло окно»: и «мама», и «окно» могут выступать в качестве субъекта, однако, мы можем предпочесть предстоящее глаголу слово, чем последующее.
Данный подход очень ресурсоемок, т.к. для создания парсера требуется хорошая команда лингвистов, которые должны буквально описать весь русский язык. Поэтому нам более интересен второй подход — машинное обучение с учителем.

Идея в парсинге, использующем машинном обучение, как и во всех остальных задачах машинного обучения довольно таки проста: мы даем компьютеру много примеров с правильными ответами, на которых система должна обучиться самостоятельно. Чтобы обучить синтаксические парсеры — в качестве данных для обучения используют специально размеченные корпуса (treebanks), коллекции текстов, в которых размечена синтаксическая структура. Наше предложение в таком корпусе может выглядеть следующим образом:

1	Мама	сущ.им.ед.жен.	2	субъект
2	мыла	глаг.ед.жен.прош	0	-
3	раму	сущ.вин.ед.жен.	2	объект


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

  1. номер слова в предложении (1)
  2. словоформа (мама)
  3. грамматические категории (сущ.им.ед.жен.)
  4. номер главного слова (2)
  5. тип связи (субъект)

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

Обучаем парсер


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

  1. MST Parser, основанных на задаче нахождения минимального остовного дерева
  2. MaltParser, основан на машинном обучении (хотя и MST Parser тоже, но там немного другая идея)

Обучение MST-парсера занимает гораздо больше времени и он также дает худшие результаты по сравнению с MaltParser, поэтому далее мы сфокусируемся на втором из них.
Итак, для начала требуется скачать MaltParser и распаковать скачанный архив.

> wget http://maltparser.org/dist/maltparser-1.7.1.tar.gz
> tar xzvf maltparser-1.7.1.tar.gz
> cd maltparser-1.7.1


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

Чтобы обучить новую языковую модель нам потребуется размеченный корпус. Для русского существует на данный момент только один синтаксически размеченный корпус — СинТагРус, который входит в состав НКРЯ. Мне удалось получить доступ к СинТагРус на условиях нераспространения и исследовательских целей. Корпус представляет собой набор текстов размеченных в формате XML:

<S ID="8">
<W DOM="2" FEAT="S ЕД МУЖ ИМ НЕОД" ID="1" LEMMA="КАБИНЕТ" LINK="предик">Кабинет</W>
<W DOM="_root" FEAT="V НЕСОВ ИЗЪЯВ ПРОШ ЕД МУЖ" ID="2" LEMMA="ОТЛИЧАТЬСЯ">отличался</W>
<W DOM="2" FEAT="S ЕД ЖЕН ТВОР НЕОД" ID="3" LEMMA="СКРОМНОСТЬ" LINK="2-компл">скромностью</W>,
<W DOM="3" FEAT="A ЕД ЖЕН ТВОР" ID="4" LEMMA="ПРИСУЩИЙ" LINK="опред">присущей</W>
<W DOM="4" FEAT="S ЕД МУЖ ДАТ ОД" ID="5" LEMMA="СЕМЕН" LINK="1-компл">Семену</W>
<W DOM="5" FEAT="S ЕД МУЖ ДАТ ОД" ID="6" LEMMA="ЕРЕМЕЕВИЧ" LINK="аппоз">Еремеевичу</W>.
</S>


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

Кабинет 		S.m.nom.sg      2       предик
отличался       	V.m.real.sg     0       ROOT
скромностью     	S.f.ins.sg      2       2-компл
присущей        	A.f.ins.sg      3       опред
Семену  		S.dat.m.sg      4       1-компл
Еремеевичу      	S.dat.m.sg      5       аппоз


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

> java -jar maltparser-1.7.1.jar -c russian -i /path/to/corpus.conll -m learn
-с название модели (на выходе получится файл russian.mco)
-i входной файл - размеченный корпус
-m режим работы, в данном случае это learn - обучение


Однако, я запускал обучение с дополнительными аргументами:

> java -Xmx8000m -jar maltparser-1.7.1.jar -c russian -i /path/to/corpus.tab -if appdata/dataformat/malttab.xml -m learn -l liblinear
-Xmx8000m увеличиваем доступную память
-if appdata/dataformat/malttab.xml изменяем формат входных данных на malttab (по умолчанию парсер использует формат CoNLL, но он сложнее)
-l liblinear используем для обучения линейные SVM вместо более медленной библиотеки LIBSVM


В итоге мы получим файл russian.mco, который содержит обученную модель и необходимые конфигурационные данные. Теперь у нас есть все (ну или почти все), что нужно, чтобы парсить русские тексты.

Парсим русский язык


Запуск парсинга производится следующим образом:

> java -jar maltparser-1.7.1.jar -c russian -i /path/to/input.tab -o out.tab -m parse
-с название нашей модели
-i входной файл, который необходимо распарсить
-o выходной файл, куда будет записан результат
-m parse режим парсинга


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

  1. Разбить текст на предложения (сегментация на предложения)
  2. Разбить каждое предложение на слова (токенизация)
  3. Определить грамматические категории для каждого слова (морфологический анализ)

Эти три задачи гораздо проще чем синтаксический анализ. И к счастью для русского существуют открытые либо бесплатные системы для морфологического анализа. В предыдущей статье мы даже этим немного занимались, там же вы можете найти отсылки к другим существующим системам. Для своих целей я написал морфологический анализатор на основе машинного обучения, который я тренировал на том же СинТагРус. Возможно, в следующий раз опишу и его.

Я произвел обучение на 1/6 части СинТагРус и получил модель для русского языка, которую вы можете попросить для личных целей. Чтобы ею воспользоваться, нужно чтобы грамматические категории совпадали с теми, которые использовал я при обучении модели.

Данная модель показала точность (accuracy) в 78,1%, что довольно таки неплохо и для большинства целей вполне подходит. Модель, обученная на всем корпусе дает точность в 79,6%.

Заключение


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

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

Я выложил простое онлайн демо, которое, пока не упало, выглядит так:


Весь код (кроме корпуса) доступен здесь: github.com/irokez/Pyrus

В заключение я хотел бы поблагодарить НКРЯ, а в частности ИППИ РАН за предоставление доступа к СинТагРус.
Александр Пак @Irokez
карма
151,8
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

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

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

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

  • +2
    А почему корпус недоступен для простых смертных, если не секрет?
    • 0
      мне и самому невдомёк
    • 0
      Вроде потому что собран из текстов с нерешенными лицензионными вопросами + первоначальная разметка выполнялась коммерческими закрытыми программами.
      • +2
        Так его, получается, и использовать нельзя? Раз там все ужасно с авторскими правами и лицензиями. Ну, а с точки зрения закона, свободное и «выборочное» распространения чем-то различаются? Если нет, то тогда в чем смысл?
        • 0
          Права на тексты и права на разметку — немного разные вещи. Даже если бы НКРЯ захотел распространять разметку, встал бы сложный впрос: как ее распространять, не распространяя сами тексты. Сейчас выкрутились так: дают скачать случайную выборку предложений с морфологической разметкой (т.е. вроде как сами тексты как цельные произведения не распространяют, только предложения из них). Но условия распространения этой выборки тоже очень мутные (похоже, что использовать можно только в исследовательских целях, т.е. «в стол», хотя написано «свободно»), а на письма с просьбами уточнить не отвечают никому ничего.

          Как и что это все значит с точки зрения закона — это только суд сказать может, как мне кажется. Короче, вопрос мутный уже много лет, и, похоже, таким и останется, уж извините за пессимизм. В OpenCorpora очень правильно сделали, что только лицензионно «чистые» тексты в корпус добавляют изначально, чтоб похожая проблема не возникла.
  • +15
    Круто!

    Дальше сугубо IMHO. Расстраивает одно — непонятно, как и зачем серьезно заниматься NLP (и синтаксисом в частности) простому смертному. Писать правила — это нужна команда лингвистов, чтоб использовать машинное обучение — нужны корпусы, а тут НКРЯ вне конкуренции сейчас. Доступ к НКРЯ (применительно к задачам машинного обучения) не свободный (хоть корпус вроде же национальный — но понятно, причины на это есть, наверное), а потом еще и результаты обучения использовать свободно нельзя (для себя все делать, в стол, как другим-то людям результатами пользоваться?). По слухам — на изменение ситуации надежды почти нет. И при этом именно в НКРЯ вкладывают свои усилия РАН, университеты и т.д.

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

    Такой открытый корпус есть, и довольно активно развивается: opencorpora.org/ — пользуясь случаем, приглашаю всех, кто может, присоединиться к его развитию, без краудсорсинга тут не справиться.
    • +3
      Полностью с вами согласен. Я пытался поднимать этот вопрос на последнем Диалоге. Удалось лишь получить добро на свободное распространение обученного парсера. Надеюсь, довести его до ума, чтобы им можно было реально пользоваться.

      Проект Opencorpora мне безумно нравится. Жду не дождусь, когда они начнут синтаксическую разметку.
      • +1
        Добро на распространение парсера — это хорошо, с хорошим свободным парсером будет проще забутстрапить treebank на основе opencorpora.
    • 0
      > непонятно, как и зачем серьезно заниматься NLP (и синтаксисом в частности) простому смертному.

      Личное ощущение (возможно, неверное), что это смотря какие задачи перед собой ставить. Некоторые можно решить, некоторые нет.

      > потом еще и результаты обучения использовать свободно нельзя

      Опа. Как нельзя?!
      • 0
        Есть такая проблема. Берёте корпус, обучаете на нём систему, а потом оказывается, что корпус «for research purposes only», а если вы хотите встроить систему в коммерческий продукт, платите большие деньги.
  • +3
    1) > Метод, основанный на правилах, применяется практически во всех коммерческих системах
    Есть какой-нибудь пруф? Мне казалось, что как раз наоборот, сейчас всё на статистике работает.

    2) Чем ваш эксперимент отличается от описанного в статье Parsing the Syntagrus?

    3) > Данная модель показала точность (accuracy) в 78,1%, что довольно таки неплохо и для большинства целей вполне подходит.
    Это state-of-the-art, но на самом деле это ничерта не подходит. Это означает ошибку практически в КАЖДОМ предложении, т.к. измеряется правильность присоединения слова.

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

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

    б) Алгоритмы машинного обучения вероятностны, язык сложен. Шаг вправо-шаг влево от обучающего корпуса — и возникают глупейшие ошибки образования связей. Я уверен, что машинное обучение должно совмещаться с лингвистическим знанием, т.е. надо не просто учиться на корпусе, но и генерировать в результате процесса некую формальную грамматику языка.

    в) Не учитывается семантика (пока что). Если два слова можно совместить синтаксически, ещё не значит, что их можно совместить семантически. Эти вещи тоже учатся из корпуса, в теории.

    • 0
      3. Кстати не совсем. Примерно 10-15% структур будут построены правильно.
      • 0
        Ну, что тут говорить… ура, товарищи! Это великое достижение научной мысли :)
    • –1
      1. Возможно, я не прав. Я почему-то думал что Stanford и Berkeley парсеры основаны на правилах. ЭТАП в частности rule-based: www.dialog-21.ru/digests/dialog2012/materials/pdf/Iomdin.pdf

      2. Думаю, ничем.

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

      Не думаю, что проблема заключается в разметке частей речи. Если не ошибаюсь, state-of-the-art тэггеры достигают точность в 99%. Конечно, проблемы возникают, если текст нестандартный (твиты, например). Основные проблемы, которые я заметил, это предложные группы, словосочетания, определение сущностей (даты, имена, названия организаций).
      • +1
        Stanford и Berkeley точно так же на статистике основаны, как и прочие («Q: Can I train the parser? A: Yes, you can train a parser»). ЭТАП — это, насколько знаю, довольно древняя махина, разрабатывающаяся с давних пор, и в этом смысле может быть уподоблена системам вроде Systran. Да, существуют, да, развиваются, но идеология там заложена очень давно и не менялась.

        По поводу прилагательных, существительных и подлежащих — да бросьте, тут и парсер не нужен. Ближайшее к существительному прилагательное слева — искомое; первое существительное фразы — подлежащее. Такой простейший алгоритм уже даст вам хорошую точность. А если хоть немного улучшить, получится вполне сносно.

        По поводу теггеров — моё личное мнение, что эта цифра в 99% крайне лукава. Мне самому не удавалось для английского выйти за пределы 97%, при этом baseline performance теггера (т.е. если всегда тупо приписывать слову самый вероятный тег) составляет 85% или около того. Если обращать внимание только на те слова, для которых производится хоть какой-нибудь выбор, качество моментально падает.

        Кроме того, лукава разметка Penn Treebank, на которой обычно теггеры и тестируют. Например, в сочетаниях вроде «computer software» слово «computer» считается существительным, модифицирующим другое существительное, а не прилагательным, как сказал бы лингвист. Конечно, если делать такие допущения, можно добиться и 99%, да толку-то…
        • 0
          Для нового проекта парсинга английского языка ищем возможности 98% теггеринга.
          Если кто отзовётся, буду премного благодарен.
          • 0
            Язык программирования важен?

            Любая современная система (SVMTool, например) вам даст в районе 98%, проблемы возникнут, когда вам потребуется конкретный язык и/или лицензионная чистота в случае коммерческого использования.
          • 0
            Да, и как я сказал, смотря как измерять. Если «в лоб» (что обычно и делают) около 97-98% получите.
            • 0
              Мы двигаемся в направлении надлингвистических технологий обработки текстов с использованием Модели Мироздания.

              Считаем, что за этим будущее.

              Однако, приходится сталкиваться с проблемами BigData и ограниченностью машинных ресурсов. Как выход — частичное использование традиционных методов парсинга текстов — попытка совместить преимущества двух подходов: простота лингвистического графа и мощные возможности эвристико-смысловой обработки…
  • +1
    А почему «да» — это подузел глагола «съешьте»? Тут же вроде сложносочинённое предложениие, и «да» должно быть в корне и иметь «съешьте» и «выпейте» в качестве подузлов (так же, как когда вы парсите математическое выражение, операнды являются детьми узла с оператором "+").
    • 0
      Такое соглашение :)

      В СинТагРусе нет фиктивной вершины.
      Вершина предложения — слово «съешьте», от него идет сочинительная связь к «да».

      Другой такой пример «Я купил овощи, фрукты и хлеб».
      будет купил -> овощи -> фрукты -> и -> хлеб. Это в том числе связано с моделью языка.
      У «купить» есть актант, который отвечает на вопрос что — купить [объект]. В этом случае [объект] — это фактически группа «овощи, фрукты и хлеб», которая обозначается вот так с соответвующими именами связей.
  • 0
    ха ха попробуйте Йоду распарсить вы
    • +3
      В грамматике зависимостей порядок слов не важен, т.к. мы хотим лишь знать от какого слова зависит каждое слово в предложении и тип этих связей.
  • +1
    Тут хорошо бы еще сказать, что для того, чтобы все это заработало, необходим POS-теггер и лемматизация, соответствующая корпусу. Работать с неразрешенной морфологической омонимией MaltParser не умеет. Да, еще нужна и морфология в формате морф.данных СинТагРуса — ковертация из АОТ проходит не так гладко, насколько я понимаю.

    Ну и для тех, кто не очень в теме: создание корпуса — ОЧЕНЬ дорогая процедура.
    СинТагРус размечается с 2003 года, сейчас в нем ок. 49 тыс. предложений. Первоначальная разметка делается автоматически и дает ок. 80% правильных связей. Потом структуры корректируются двумя независимым лингвистами. Когда корпус становится достаточно большим, то уже надо следить за единообразием разметки.
    • 0
      В корпусе от НКРЯ 30 миллионов предложений и 330 тысяч текстов, вы ошиблись на 3 порядка. Пруф.

      50 тысяч — это opencorpora.
      • +1
        Все верно, только СинТагРус — подкорпус НКРЯ. И там 50 тыс. предложений.
        подкорпус НКРЯ со снятой морфологической омонимией — ок. 8 млн. словоформ.
      • 0
        да, и пруф, если очень нужно.
  • 0
    А может ли данная система парсить предложения с необычным порядком слов, к примеру «Дайте мне копию пиратскую пиратов моря Карибского»?
    • 0
      а проверьте :)

      по-моему, это фейл.

      что, впрочем, нисколько не умаляет заслуг автора, который проделал отличную работу и написал хорошую, внятную статью. решпект!
    • 0
      Да легко. Проблемы обычно в другом. Например «Моих друзей звали Иван и Петр». имена моих друзей Иван и Петр. Или Петр и Иван звали(окликали) моих друзей?
      • 0
        Самый разумный метод, который я видел — это генерация всех допустимых комбинаций с последующим ранжированием (т.е. оценкой качества графа). В данном случае применяется правило «существительное раньше дополнения», повышающее оценку первого варианта.

        Мы ведь так и делаем — см., «добро побеждает зло».

        А компьютер — он такой шалунишка… среди самых забавных трактовок, с которыми сталкивался — «он увидел её перед своими глазами» и «он имел помощником экономиста». Распарсьте-ка в уме :)
        • 0
          Профессионалы такое на раз видят, да. Обычным людям значительно сложнее :)
  • 0
    А я просто приведу один пример предложения на голландском:
    «ik Cecilia Henk de nijlpaarden zag helpen voeren»
    досл: я Цецилья Хэнк этих бегемотов видел кормить помогала.
    пер: я видел как Цецилла помогала Хэнку кормить бегемотов.

    И предложу автору классифицировать грамматику по хомскому :)
    • +2
      А по Хомскому незачем, Хомский свою систему разрабатывал для английского, где важен порядок слов. Для европейских языков dependency grammars уже, можно сказать, победили.
  • 0
    очень интересно. вы прям описали 20 лет развития компьютерной лингвистики. :)

    но «парсер — лох», увы… даже 78% точности дают грубые ошибки в построении синтаксического дерева, которые человек не допустил бы.

    всё это грустно.
    • 0
      Ошибок много, согласен. Но это не грустно, это просто нужно улучшать. Главное, что основа есть.
  • 0
    Кстати, для русского очень полезно создавать фичи на основе морф. характеристик.
    Я не уверен, что MaltParser это делает. В русском POS-тег(если так можно назвать) составной, а не атомарный.
    Скажем если использовать признак падежа, то можно улучшить модель за счет согласования падежей.
    • 0
      Maltparser'у можно подать на вход любой набор тегов. Т.е. можно спокойно составить теги вида «сущ-ед.ч.-родит» и тренировать парсер на них.
      • 0
        Можно, да. Использовал ли это автор, вот в чем вопрос.
        • 0
          В статье Parsing Syntagrus, на которую я ссылался, написано, что не просто «можно» использовать морфологические данные, а просто необходимо, иначе вообще ничего не выйдет.
          • 0
            Да, но я вот не помню, морф. данные считались атомарным тегом или составным.
    • 0
      MaltParser использует морф. характеристики. Но я при обучении задавал составные теги (типа «сущ.ед.муж»), т.е. морфология как бы учитывается, но наверное не так, как вы предлагаете. В принципе, я с вами согласен. Для русского нужно учитывать морфологию более искусным путем.
      • 0
        Кстати. Немного офтопика. Вы на Диалоге рассказывали про анализ тональности. В частности, был конвеер обучение POS-теггера на снятнике НКРЯ и maltparser на СинТагРусе. Как конвертировались морф. признаки? Как в вашем Pyrus? Т.е. простое 1:1 соответствие?

        Была ли еще привязка к АОТ?
        • 0
          Там был немного запутанный конвеер. Тексты сначала прогонялись через TreeTagger (http://corpus.leeds.ac.uk/mocky/)? затем теги конвертировались в теги НКРЯ (писал скрипт для конвертации) и прогонялись через MaltParser. Собственный POS-тэггер не использовал, т.к. не успел сделать сегментацию на предложения и слова. АОТ пробовал использовать для лемматизации, но там почти никакого эффекта не было для классификации тональности.
          • 0
            Спасибо за пояснения. А как конвертировлись НКРЯ -> СинТагРус? Это же ведь было нужно для обучения?

            Тут еще вопрос — формат НКРЯ это формат снятника(части, в которой снята морф. омонимия), или формат СинТагРуса?
            • 0
              Теги СинТагРус конвертировались в англ. версию (S ЕД МУЖ ИМ НЕОД -> S.m.nom.sg) (это было необязательно. но мне почему-то было так удобнее) примерно так: github.com/irokez/Pyrus/blob/master/src/syntagrus.py

              Теги TreeTagger конвертировались тоже в англ. версию (Ncmsnn -> S.m.nom.sg) так: gist.github.com/cc9db95069b267a1d79f

              НКРЯ в СинТагРус не конвертил. Собственно из всего НКРЯ я использовал только СинТагРус.
              • 0
                Спасибо :)
        • +1
          Кстати, урывками пилю github.com/kmike/russian-tagsets — библиотечку для преобразования между различными форматами морф. признаков. Там внутри простой движок для цепочек преобразований (например, если библиотека знает, как из формата A перевести в формат B, и как из B в C, то A->C тоже как-то заработает без явного указания). Сейчас готова более-менее поддержка преобразований туда-сюда между тегами aot, "rutags" и ДИАЛОГ-2010. Начал добавлять туда opencorpora, но моя «урывка» закончилась и не доделал по-нормальному.

          Я это к чему — если делаете преобразование между тегами любых 2 форматов, рассмотрите возможность сделать это в рамках russian-tagsets в виде pull-request'а. В качестве бонуса — заработает преобразование в другие форматы, если получается цепочка.
          • +1
            Спасибо. Буду иметь в виду. Я начинал делать преобразование AOT -> ЭТАП (СинТагРус).
            Как будет свободное время, попробую сделать это для russian-tagsets. Я просто на Java пишу :)
            Собственно, компилятор словарей АОТ и построение минимального КА есть у меня на гитхабе :)
            • 0
              Спасибо)

              Кстати, в планах — обязательно добавить в russian-tagsets консольную утилиту, чтоб можно было библиотеку использовать без написания питоньих скриптов.
          • +2
            могу добавить преобразование из тегов MULTEXT :)
            • 0
              Было бы здорово) Мельком глянул, они вроде довольно похожи на rutags, и в авторах Anna Feldman тоже — это я к тому, что, возможно, проще всего будет multext <-> positional сделать, multext <-> aot тогда само заработает.

              Но если есть готовый код уже для multext <-> aot, то он совсем не помешает, т.к. явное преобразование может помочь избежать потерь информации при преобразовании через посредника.

              Там сейчас README нет, если какие-то вопросы по реализации — пиши.

  • –1
    В университете мы подобное(в несколько упрощенном виде) писали на прологе. Он хорошо подходит для решения подобных задач.
    • 0
      Дьявол в деталях.
      Проблема в написании правил :)
    • +3
      «в несколько упрощённом виде» :)
    • 0
      К сожалению, никогда не пробовал писать на прологе. Но скорее всего вы делали пытались формализовать естественный язык на прологе, что эквивалентно написанию правил. Я здесь описываю статистический подход — парсер сам обучается на основе уже размеченных данных.
  • 0
    Ограничение на распространение накладывается также и на построенную модель?
    • 0
      Мне дали добро на распространение обученной модели для некоммерческих целей. Единственная загвоздка — модель бесполезна без морфологического анализатора. Как только приведу в порядок исходный код, то смогу распространять модель.
      • +2
        Я потихонечку-помаленечку для собственных нужд пилю довольно примитивный морфологический анализатор на Ruby, который умеет работать со словарём и выдавать грамматическую информацию в замечательном формате MULTEXT-East. Также он доступен в виде Web-сервиса. Если интересно, буду рад обратной связи.

        Сейчас есть много важных вещей, которые нужно доделать: формирование гипотез для неизвестных слов (как в mystem от Яндекса), реализовать SQL-бэкэнд вместо Tokyo Cabinet, но для каких-то несложных задач его можно использовать уже сейчас.
        • 0
          неплохо! на основе АОТ?
          • 0
            Используется морфологический словарь проекта АОТ, но схема данных своя. Для этого написан соответствующий конвертор Myasorubka на который я ради прикола даже свидетельство о госрегистрации получил.

            Мне нравится pymorphy от kmike, но мне очень не нравится Python (пожалуйста, давайте не будем это обсуждать). Более того, мне кажется, что алгоритм в анализаторе mystem гораздо разумнее, чем подход АОТ на основе генерации словаря окончаний.

            Сейчас в планах воспользоваться словарём OpenCorpora, но я пока не могу выделить время на изучение их XML-фарша.
            • 0
              В mystem и aot подходы почти одинаковые — по паре автоматов для поиска/итерации по словам спереди и сзади. Отличие, как я понял (судя по бумагам — исходников mystem нет) — в словарях (видимо, в mystem они актуальнее), в эвристике + в aot автоматы вручную строится, а в mystem, судя по бумаге, пара trie.
              • 0
                Судя по статьям, trie используется потому, что в нём удобно представлять большое количество строк, по которым выдётся поиск. Очень приятно, что метод mystem не предполагает построение автомата, а это довольно долгий (хоть и однократный) процесс. Хранение всех этих окончаний с привязанными правилами мне кажется лишней избыточностью.

                Да, исходников mystem у меня тоже нет.
                • 0
                  Внутри trie — тоже автомат, он тоже строится (при заполнении trie), другое дело что дополнительно не минимизируется. В итоге довольно похоже получается, если на конкретные действия смотреть, которые программы выполняют при поиске (взяли букву, перешли к следующей и т.д.) Плюс иногда trie еще в DAWG минимизируют, там еще более похоже выйдет.

                  Окончания с привязанными правилами в mystem, судя по бумаге, тоже хранятся, но не для всех слов («The boundary between stem and suffix is taken either from the input file if it is explicitly presented or computed automatically as the length of the common part of all word forms in the paradigm.») — информация о том, как бить слово на 2 части — это и есть аналог правил из aot (если я все правильно понял). Там, где размеченного вручную (лингвистически осмысленного) разбиения слов нет, работает автоматика.

                  По всей видимости, ручное указание разбиения необходимо, чтоб предсказание неизвестных слов работало лучше. Но это я, понятно, только гадать могу, т.к. mystem не делал и тонкостей не знаю.
  • 0
    Ссылка

    Вася прич., вин. падеж, жен. род, страд., ед. число

    :)
  • 0
    Например, в предложении «мама мыло окно»: и «мама», и «окно» могут выступать в качестве субъекта
    И мыло, кстати, тоже. :)
    • +1
      Это если омонимия не снята.
      • 0
        Да. Хотя «мама» в качестве объекта тут выступать не может. «Окно мыло мама»?
  • –1
    1. Разбить текст на предложения (сегментация на предложения)
    2. Разбить каждое предложение на слова (токенизация)
    3. Определить грамматические категории для каждого слова (морфологический анализ)
    Язык ведь не так устроен. Он не по нисходящей должен исследоваться, а в комплексе. Простейший пример: «Я купил мороженное» и «Я купил мороженное мясо» — здесь слово «мороженное» является разными частями речи, и без предложения целиком вы не поймете, что имеется в виду.

    Более того, предложения тоже нельзя рассматривать отдельно. Почти такой же пример: «Я пришел в магазин, но охлажденного мяса там не было. Подумав, я все-таки купил мороженное.» Здесь без первого предложения не понять, что во втором слово «мясо» опущено, а «мороженное» — ни разу не существительное.

    Мне кажется, тут может частично спасти недетерминированность: предлагать несколько вариантов, и протаскивать на следующий уровень все. Или более правдоподобные, а в случае возникновения несостыковок — спускаться назад и брать еще. Но это уже гораздо более сложная система.
    • +2
      Спасибо, посмеялся!
      А потом такие неграмотные становятся учителями русского языка.

      Урок русского языка в грузинской школе. Учитель говорит: «Дети, запомните: слова сол, фасол, вермишел пишутся с мягким знаком, а слова вилька, булька, тарелька – без мягкого знака. Дети, запомните, потому что понять это невозможно!»
      • 0
        Да, я ошибся. Там должно быть «мороженое» и «мороженое мясо». Сути моего комментария это не меняет, и я ожидал высказываний по существу, а не придирок к орфографии. А уж учителем русского языка я точно уже не буду.
  • 0
    А вы не хотите про этот эксперимент рассказать у нас на семинаре: nlpseminar.ru?
    Мне кажется, что отличный кейс про то, что можно сделать руками.
    • 0
      Я бы с удовольствием, но, к сожалению, я не в России.
      • 0
        Ну если будете проезжать мимо Питера, то мы Вас с удовольствием пригласим на семинар.
  • 0
    goo.gl/LO5pP

    Почти угадал :)
  • 0
    Очень рад увидеть подобные статьи на Хабре.
    К сожалению не могу разделить мнения по поводу статистических методов, так как дальше простейших предложений они уйти не могут. Гляньте конкурсные предложения диалога, статистикой их не осилить. По-моему мнению статистические словари могут быть полезны как замена или помощник при разрешении сложных зависимостей. Насколько я понимаю, парсер Abbyy и именно так их использует.
    • 0
      Всё зависит от языка, с которым работает система. Многие западноевропейские языки (тот же английский) прекрасно обрабатываются статистическими парсерами. Нельзя исключать статистические методы только потому, что они внешне могут казаться игрой в кости.

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

      Где-то недавно пробегала ссылка на тот же «Диалог», речь шла как раз о синтаксическом анализе.
      • 0
        Слово «прекрасно» ненаучное. «Прекрасно» — это 70%, 80%, 90% или сколько? Меня абсолютно не удовлетворяет качество разбора современных парсеров, и выше я объяснял, почему. Ошибки возникают в каждом втором предложении.
        • 0
          Абсолютно поддерживаю этот Ваш тезис.
      • 0
        >>>Всё зависит от языка, с которым работает система. Многие западноевропейские языки (тот же английский) прекрасно обрабатываются статистическими парсерами.>>>

        А не могли бы Вы подсказать, существуют ли работы, в которых анализируются особенности обработки языков разных семей? За ссылки также буду очень признателен.
        • 0
          Штука в том, что сейчас всеми силами стараются этот процесс унифицировать. Например, берётся размеченный корпус языка, далее на нём учится POS tagger и парсер, производится замер. В этом есть свой смысл, но особенности стараются как можно раньше формализовать (в виде морфологических атрибутов слова, например), а дальше применить стандартную модель.

          Для сравнительного анализа результатов погуглите «CoNLL-X Shared Task on Multilingual Dependency Parsing», например. Но всё это тоже лукавая статистика, т.к. качество инструментария для разных языков разное. Начиная прямо с размеченных корпусов.
        • 0
          Я не интересовался работами, посвящёнными непосредственно сравнению методов обработки языков различных семей. Однако из всего, что я видел, сходу могу посоветовать несколько ссылочек:


          Вообще, нынешний RuSSIR как раз посвящён многоязычному информационному поиску. Вероятно, в материалах конференции будет что-то интересное именно по данному вопросу.
          • 0
            Спасибо, почитаю.
  • 0
    Хочу напомнить автору, что данный велосипед изобретается с 50х годов прошлого века Хомским и еще много кем. Читал ли автор хоть что-нибудь о структуре языка как об абстрактной системе, о проблеме контекстуально-свободных «порождающих» грамматик?
    Если не игнорировать опыт предшественников, наверняка удастся избежать многих заплаток и костылей в своем продукте.
  • 0
    «Данный велосипед» даже если и изобретается с 50х годов, но даже и его нет для русского языка в свободном доступе. Хотя я тут описывал не грамматику составляющих, которая вписывается в модель Хомского, а грамматику связей, которая больше вписывается в теорию Мельчука и ко.
    • 0
      В этом и вся беда отечественного NLP (которое не пикап): ни словарей, ни программного обеспечения, ни моделей обученных, ничего.

      Особенно досадно, что машиночитаемые корпусы текстов и тезаурусы русского языка разрабатываются на наши же с вами налоги, но при этом доступны только узкому кругу разработчиков и паре-тройке «своих» организаций.
      • 0
        Ну и фиг с ними. Команда «Айноу» сейчас разрабатывает парсер русского языка по новой (не лингвистической) технологии. Он будет доступен всем желающим.
        • 0
          Замечательно. Можно где-то о вас почитать? Опубликованные статьи, патенты, сведения о продуктах?
          • 0
            Постепенно выкладываем на сайт «Айноу».
            • 0
              Вероятно, я плохо ищу: по запросу «Айноу» получаю только компанию из Тюмени, которая занимается маркетинговыми исследованиями. Можно прямую ссылку?
              • 0
                Вот здесь: iknowww.ru
                • 0
                  Клёво, спасибо. Странно, но переводчик будто не переводит вовсе, а дописывает к исходному тексту слово “Sample”.
                  • 0
                    Да, к сожалению, в силу новых обстоятельств переводчик будет перенесен в систему DUDU.com Поэтому его демонстрация приостановлена.

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

    «Я звиняюся», Вы не указали мою статью (возможно не увидев её по моей вине), тоже про синтаксический анализ предложений: habrahabr.ru/post/126675/
  • 0
    а что, все? сайт уже не фурычит? я не успел?

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