Морфологический анализатор и Part-Of-Speech Tagger

Назначение морфологического анализатора

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

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

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

На крутом (предложный, ед., муж.) берегу (локатив,ед.,муж.)

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

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

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

Языки, для которых реализован морфологический анализ

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

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

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

Для текущей версии грамматического движка доступны варианты морфологических модулей для русского и английского языков. При этом русский вариант морфологического анализатора, включая Part-Of-Speech Tagging алгоритм, является основным.

Отличия в морфологическом анализе слов и предложений: POS Tagging и распознавание словоформ.

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

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

Автоматическая частеречная разметка текста обычно называется Part-Of-Speech Tagging. В этом случае анализатор учитывает контекст слов в словосочетании и предложении - ближайшие соседние слова, далекие грамматически связанные фрагменты и даже общий контекст, задаваемый через тематику текста. Из этого краткого описания уже понятно, что POS tagging требует намного больше ресурсов для выполнения, но это окупается исключением из результатов множества невозможных вариантов анализа отдельных слов. Существует множество алгоритмических подходов в реализации POS tagger'а, из которых в грамматическом сорваре выбраны два взаимодополняющих. Во-первых, набор вручную заданных правил, учитывающих различные невозможные или маловероятные варианты распознавания, например - после предлога не может идти деепричастие. Во-вторых, обучаемая по размеченному корпусу текстов вероятностная модель морфологии, которая находит статистические закономерности в эталонной частеречной разметке и затем применяет их. Далее будут подробно описаны правила и техники обучения, с помощью которых можно настраивать анализатор для своих задач.

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

На самом верху

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

США планируют возродить лунную программу.

Cуществительное США, если рассматривать его вне контекста, не позволяет однозначно назвать его падеж. Соответствующая словарная статья имеет парадигму из 6 падежных форм множественного числа, совпадающих лексически. Попробуем использовать соседние слова. Следующий за США глагол, казалось бы, однозначно указывает на то, что мы имеем дело с именительным падежом подлежащего США. Но в русском языке порядок следования подлежащего и глагольного сказуемого достаточно свободен, поэтому формула S+V+O зачастую инвертируется:

Возобновление лунной программы будет рассматривать Конгресс США.

Более того, некоторые сообщения носители русского языка категорически предпочитают выражать с порядком слов Object+Verb+Subject, чтобы выделить нужную часть фразы:

На атолл надвигается тропический ливень

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

API для морфологического анализа

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

Это процедурный API, поэтому он легко интегрируется с языками программирования, в которых предусмотрен вызов функций с C-интерфейсом. По умолчанию предполагается, что прикладная программа будет использовать solarix_grammar_engine.dll в комплекте в lib-файлом. Такое раннее связывание упрощает использование API. Например, для программ на C и C++ достаточно включить в проект lib-файл и заголовочный файл solarix_grammar_engine.h, в котором объявлены экспортируемые функции API. После этого можно писать так:

#include <lem/solarix/solarix_grammar_engine.h>

int main( int argc, char *argv[] )
{
 HGREN hEngine = sol_CreateGrammarEngineEx8( "..\\..\\..\\..\\..\\bin-windows\\dictionary.xml", SOL_GREN_LAZY_LEXICON );

 char sentence[] = "Кошки ели мой корм";

 HGREN_STR hWords = sol_Tokenize8( hEngine, sentence, -1 );
 int nword = sol_CountStrings(hWords); // http://www.solarix.ru/api/sol_CountStrings.shtml
 for( int i=0; i<nword; ++i )
 {
  sol_GetString8( hWords, i, Word );
  // ...
 }

 sol_DeleteStrings(hWords);
 sol_DeleteGrammarEngine(hEngine);

 return 0;
}

Более сложный подход требуется, если используемая платформа не позволяет использовать lib-файлы, собранные в MS VisualStudio. Например, Qt в среде MS Windows использует gcc, который имеет свои средства для работы с dll. В таких случаях приходится довольствоваться поздним связыванием, добавляя вспомогательный код. Обычно это выражается в явной загрузке динамической библиотеки с помощью вызова LoadLibrary и получении адресов вызова функций с помощью GetProcAddress. В рамках фреймворка Qt данные средства реализуются через методы класса QLibrary. Именно так реализовано использование грамматического движка в программе Morphology.

Для программ, написанных на Delphi, написан специальный интерфейсный модуль SolarixGrammarEngine.pas. Включение его в проект делает возможным вызов функций API. Соответствующие примеры с исходниками можно найти в SDK грамматического словаря.

Для программ на PHP вся работа с API словаря выполняется через модуль расширения. Он написан на C и реализует описанный выше путь, то есть явно загружает динамическую библиотеку, определяет адреса вызова процедур. С точки зрения прикладного PHP кода этот модуль добавляет множество функций с соответствующими именами, к примеру sol_CreateGrammarEngine.

Для программ на платформе .NET доступны два варианта. Основной, доступный по умолчанию вариант - сборка gren_fx.dll, содержащая обертки для вызова процедур API движка из управляемого кода. Этот интерфейс полностью повторяет процедурный API словаря. Более удобным вариантом может быть другая сборка gren_fx2.dll, содержащая дополнительный C#-код для объектно-ориентированной парадигмы работы со словарем. Загрузка словаря и отдельные грамматические операции выполняются как вызов методов соответствующих классов:

GrammarEngine2 gren = new GrammarEngine2();
gren.Load( "dictionary.xml", true );

using( WordProjections projs = gren.FindWordForm( "проверка" ) )
{
 for( int i = 0; i<projs.Count; ++i )
 {
  int id_entry = projs.GetEntryKey( i );
  int id_class = gren.GetEntryClass( id_entry );
  ...
 }
}

Распознаватель как часть лексера

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

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

Результаты распознавания

Результатом морфологического анализа слова является набор из следующих данных.

К какой части речи может относиться слово.

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

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

Для нечеткой проекции вычисляется также достоверность распознавания.

При работе с морфологическим анализатором прикладной код обязательно будет сталкиваться с неоднозначным распознаванием слов. Далее мы подробно остановимся на вопросах возникновения и снятия омонимии. А пока отметим следующее пркатическое следствие.

Если слово распознается неоднозначно, то у словоформы появляются альтернативные версии. Самый достоверный вариант распознавания становится основной версией. Именно он виден при вызове таких процедур API, как sol_GetNodeIEntry, а также выводится первым в листингах в консольных утилитах. Все остальные варианты, если они не отсеиваются алгоритмами снятия омонимии, также доступны для прикладного кода с помощью таких процедур API, как sol_GetNodeVerIEntry. Количество вариантов распознавания можно получить с помощью процедур sol_GetNodeVersionCount и sol_CountProjections.

Словарная морфология

На этом этапе для распознавания грамматических свойств слова используется информация в лексиконе.

Лексикон - это часть словарной БД, хранящая словарные статьи и парадигмы. Другими словами, для каждого слова можно определить, к какой словарной статье оно относится в качестве грамматической формы.

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

Если в качестве хранилища лексикона используется реляционная БД, то применяются стандартные средства баз данных - индексирование таблиц.

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

склонение русского существительного

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

словарная морфология

Можно заметить, что распознаватель нашел два варианта - форму родительного падежа единственного числа и форму именительного падежа множественного числа.

Несловарная морфология и алгоритмы распознавания

Словарная морфология хороша тем, что обеспечивает высоконадежные результаты очень быстро, просто и точно. Главный ее недостаток - априори ограниченный набор распознаваемых слов. Если взять большой текстовый корпус и построить частотную гистаграмму для слов в нем, то получится весь примечательное распределение - острый пик для небольшого количества высокочастотных слов и очень длинный хвост из слов с частотностью около 1. В логарифмической шкале это выглядит так, по оси Y отложена частота слова, по X - отсортированные в порядке убывания частоты слова:

Местоимения обеспечивают примерно 15% общего числа форм.

Словарная морфология для русского словаря с 3 миллионами форм успешно распознаёт в среднем примерно ~97% для обычного (не узкоспециализированного) текста.

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

Распознавание чисел как части речи num_word

Один из очевидных источников большого количества редко употребляющихся слов - числа. Их количество вообще ограничено только техническим пределом на длину одного слова. Так как перечислить их в словаре невозможно, то в распознаватель зашито одно из немногих безусловных правил - числа распознаются как часть речи с именем num_word, и любое число считается формой словарной статьи num_word:number_{}. Это позволяет создавать правила синтаксического разбора и фильтрации, учитывающие числа наравне с другими словарными лексемами.

Регулярное распознавание несловарных лексем

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

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

Как создавать эти правила? И можно ли создать свои правила?

Создать свои правила можно с помощью простого текстового редактора. Затем компилятор словаря преобразует текстовое описание правил во внутренний формат и сохранит в словарной базе. В SDK Грамматического Словаря входит как сам компилятор, так и пример файла с правилами. В подкаталоге …\dictionary.src можно найти файл tiny-russian-syntax.sol, а в нем - одно правило, распознающее именительный падеж некоторых прилагательных типа “сильный”. Это правило выглядит так:

recognition ПервыйИм1 language=Russian
{
 if ".+ЫЙ" then ПРИЛАГАТЕЛЬНОЕ:"???" { СТЕПЕНЬ:АТРИБ ~КРАТКИЙ ЧИСЛО:ЕД ПАДЕЖ:ИМ РОД:МУЖ }
}

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

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

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

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

Нераспознанные слова и словарная статья UnknownEntry

Если слово не удалось распознать ни одним из разрешенных алгоритмов, то распознаватель создает словоформу из словарной статьи UnknownEntries:UnknownEntry{}. К примеру, латинские названия в русском предложении нет возможности и необходимости распознавать как русские части речи, поэтому распознаватель ограничивается такой специальной словоформой.

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

Устранимая и неустранимая неоднозначность распознавания

Тут будет добавлено описание для: Внутренние и внешние омонимы. Омонимы в пределах одной части речи и гетерогенные омонимы. Учет порядка слов для снятия неоднозначности. ...

Относительные частоты словарных статей и словоформ

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

В словаре хранится частота для словарных статей и частоты для отдельных словоформ. Приоритетом при сортировке распознавания является частоты словоформ.

Рассмотрим такой практический пример. Если запустить консольную программу Lexicon и в режиме распознавания слов (1 в стартовом меню) ввести слово “времени”, то увидим следующую картину:

То, что формы существительного “время” выведены первыми, а форма глагола “временить” последней, не случайно. Распознаватель учел информацию о том, что в среднем появление формы глагола намного менее вероятно, нежели появление формы существительного, и отсортировал результаты.

Запись слова с буквой ё в русском языке

Распознавание слов с буквой ё реализовано с учётом двух важнейших особенностей этой буквы в русском письме.

Во-первых, очень немного слов различаются в букве е/ё. К примеру, “белый мел” и “мёл пол”, или пара “полёт на Марс” и “дедушка полет траву”.

Во-вторых, обычно буква ё на письме редуцируется до е. Более-менее систематически буква ё употребляется только в детской литературе.

В силу двух этих особенностей учет буквы ё не дает какого-то значимого эффекта в плане улучшения качества распознавания русского текста.

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

Для иллюстрации работы этого алгоритма можно взять утилиту Lexicon и посмотреть в ней результаты поиска для слов “полет” и “полёт”:

Информация о том, когда слово может быть записано через ё, берется распознавателем из специальных таблиц в лексиконе. Эти таблицы заполняюится при сборке словаря, когда компилятор читает определение словоформы и встречает директиву aux stress. Подробнее об этом можно прочитать в главе с описанием словарных статей.

Нечеткое распознавание

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

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

Недостаток данного подхода заключается в том, что множество исправляемых им ошибок закрыто по определению. Алгоритм будет исправлять только те слова, для которых у него есть однозначные правила. Несколько других алгоритмов устраняют или ослабляют это ограничение, то есть могут исправлять множество ошибок, не запрограммированных в явном виде. Ценой этой гибкости будет меньшая скорость работы. Посмотрим на практике, как это работает. Запускаем утилиту Lexicon, и после выбора режима поиска в лексиконе включаем нечеткое распознавание директивой #fuzzyon. Затем вводим слова кощка и сабака.

Оба эти случая объединяет то, что допущенные опечатки меняют близкие в произношении буквы. В одном случае подставлен мягкий вариант согласной, в другом безударная о заменена на а. Правила таких замен вносятся в определение грамматики вручную, поэтому они опять-таки охватывают некоторое подмножество ошибок, хотя и намного более мощное в сравнении с известными опечатками. Если присмотреться к результатам, то можно заметить одно важное отличие от первого случая с известными опечатками - наличие оценки достоверности. Алгоритм обнаруживает близкие словарные лексемы, но итоговый результат достоверен только отчасти. Значение этих достоверностей хорошо видно, если попробовать распознать слово собка:

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

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

Ассоциации как механизм снятия внешней омонимии

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

Ассоциации - это способ задания обычного употребления слова. В качестве примера рассмотрим предложение “Храните деньги в банке”. В нем есть неоднозначно распознаваемое слово “банке”. Оно может быть либо формой существительного женского рода “банка”, либо формой существительного мужского рода “банк”. Оба варианта представлены предложным падежом. В итоге у нас нет никаких грамматических критерием для снятия такой омонимии. На помощь может придти статистика употребления слов в контексте. В данном случае достаточно знать, что рядом обычно находятся “банк” и “деньги”. Если взять похожее предложение “Засаливайте огурцы в банке”, то выявляется аналогичный способ выбрать “банку” - так как она употребляется рядом с “огурцами”.

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

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

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

Можно заметить, что ассоциации могут быть очень похожи на другой алгоритм “tree scorer”, который мы рассмотрим отдельно. Это не случайно, так как по сути это два варианта одного и того же приема, оптимизированные под разные случаи. Возьмем такое предложение:

Она засолила их в стеклянных банках.

Можно использовать либо ассоциацию “стеклянная-банка”, либо tree scorer “банка(стеклянная)”. Оба способа работают одинаково хорошо, поскольку прилагательное и существительное соединены ребром непосредственно. Но механизм tree scorer окажется бессильным, если группа прилагательного будет построена как союзный паттерн:

Она засолила их в фарфоровых и стеклянных банках.

Лексикон в SQL словаре

При работе со словарем в виде бинарных файлов доступ к словарным статьям возможен только через процедурный API или с помощью программ Lexicon, WDebugger и Грамматический Словарь. Для SQL варианта словарной базы появляется дополнительный, очень удобный способ - с помощью SQL запросов. SQL словарь дает унифицированный доступ к грамматических признакам слов и позволяет выполнять такие операции, как распознавание грамматической формы слова, склонение существительных, спряжение глаголов, склонение прилагательных и причастий, лемматизацию. Подробнее об этом можно почитать в главе с описанием SQL словаря.

Стандартный SQL не содержит необходимых императивных средств, чтобы реализовать все сложные алгоритмы несловарной морфологии. Но для базового уровня словарной морфологии вполне достаточно минимума в виде оператора SELECT. Вот такой запрос выполнит распознавание морфологических характеристик слова 'кошки':

SELECT E.name, C.name, P.str_pairs
 FROM  sg_entry E, sg_class C, sg_form F, sg_lexem L, coord_pairs P
 WHERE L.name='КОШКИ' AND F.id_lexem=L.id AND E.id=F.id_entry AND C.id=E.id_class
       AND P.id=F.id_dims

Результаты выполнения этого запроса:

кошкаСУЩЕСТВИТЕЛЬНОЕ ЧИСЛО:ЕД ПАДЕЖ:РОД
кошкаСУЩЕСТВИТЕЛЬНОЕ ЧИСЛО:МН ПАДЕЖ:ИМ

Проверка морфологического разбора с помощью утилиты Syntax

Входящая в состав SDK консольная утилита syntax позволяет увидеть работу морфологического анализатора (Part-Of-Speech Tagger'а) с разными настройками. В действительности данная утилита является отладчиком морфологического анализатора и парсера, то есть позволяет выполнять просмотр потока выполнения правил и промежуточных результатов, а также интерактивную отладку. Но для нас сейчас она послужит только готовым инструментом для проверки морфологического анализатора SDK.

В подкаталоге ...\scripts\syntax есть файл console-morphology.cmd, который запускает утилиту с необходимыми параметрами, так что после запуска можно вводить словосочетания и видеть результаты их морфологического разбора.

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

Итак, запускаем console-morphology.cmd. Программа будет выполнять морфологический разбор вводимых в консоли предложений, используя большой набор правил, написанных вручную. Эти правила учитывают очень большое количество различных синтаксических ограничений, благодаря чему снимаются многие неоднозначности распознавания грамматической формы отдельных слов. Введите "кошки спят", и после выполнения разбора наберите директиву #show. На распечатке будет видно, что для слова кошки остался единственный вариант распознавания - форма именительного падежа множественного числа, а альтернативный вариант в виде формы родительного падежа единственного числа полностью исключен из результата.

Теперь введем две директивы #allow_model и #filter, которые включают вероятностную модель морфологии и отключают ручные правила разбора. После исполнения команды #allow_model вы должны увидеть подтверждение от движка о доступности модели. После ввода того же предложения "кошки спят" набираем команду #show, и видим, что у слова кошки остались оба варианта морфологического разбора, но вариант именительного падежа стоит на первом месте. Именно в этом заключается работа вероятностной модели - она ставит на первое место в списке распознаваний для каждого слова тот вариант, который наиболее вероятен в данном контексте. Так как этап Part-of-Speech Tagging обычно только готовит данные для последующего этапа синтаксического разбора, то наличие в результатах всех вариантов распознавания форм, отсортированных по вероятности, позволяет на стадии парсинга с одной стороны в первую очередь проверять наиболее достоверные варианты, а сдругой не отказываться от рассмотрения и менее достверных, если заданный параметр beam search оставляет для этого возможность.

Вероятностная модель морфологии использует в своей работе большой объем статистической информации, накопленной в ходе обучения по эталонной частеречной разметке. Эта информация подгружается POS tagger'ом при необходимости из файлов classifier.* или sequence_labeler.* в папке со словарной базой. В конфигурационном файле словаря можно указать другое размещение файлов вероятностной модели, отредактировав текст в узле <models>. Так как в некоторых случаях объем данных вероятностной модели может превышать размер файлов данных русского лексикона, то разработчик может отказаться от использования вероятностной модели вообще, исключив узел <models> из конфигурационного файла dictionary.xml. В этом случае движок будет игнорировать все попытки включить морфологическую модель, в частности флаг SOL_GREN_MODEL при вызове sol_MorphologyAnalysis.

Чтобы увидеть все команды, обрабатываемые в интерактивном режиме утилиты Syntax, введите #help. Далее приведен краткий перечень основных, наиболее полезных команд.

#show - детальная распечатка всех вариантов распознавания грамматических форм слов по итогам этапа Part-of-Speech Tagging.

#maxalt NN - задание величины beam size в алгоритмах, которые выполняют перебор вариантов разбора. Задаваемое число NN ограничивает максимальное число просматриваемых на каждом шаге альтернатив. Благодаря этому существенно снижается общее количество перебираемых вариантов. Разумеется, ограничение на просматриваемые варианты предполагает, что на первых местах попадаются наиболее достверные варианты. В некоторых случаях это может быть трудно обеспечить, поэтому задаваемое значение NN в общем случае влияет на общий процент правильных разборов.

#allow_model - включается вероятностная морфологическая модель. Как уже было показано выше, она в рамках этапа POS Tagging сортирует варианты распознавания грамматических форм слов так, чтобы на первых местах находились наиболее достоверные в контексте. Вместе с командой #maxalt они позволяют достичь одновременно высокой скорости разбора и высокого качества.

#disallow_model - отключение вероятностной морфологии.

#allow_incomplete - данная команда позволяет анализатору, работающему с ручными правилами, не фиксировать ошибку, если не удалось выполнить полный синтаксический анализ введенного предложения. По умолчанию утилита Syntax включает специальный "особо строгий" режим, в котором невозможность построения синтаксического графа всего предложения хорошо видна. Это облегчает отладку, но в прикладных задачах более полезен другой режим, в котором анализатор строит синтаксическое дерево для максимально возможного набора слов, а если этот набор не исчерпывает введенное предложение, то начинается разбор остатка, и так далее.

#maxskiptoken NN - в режиме неполного разбора эта команда задает максимальное количество слов, которое анализатор может пропустить, если они мешают ему выполнить разбор. Это позволяет в некоторых случаях пропускать "непонятные" участки. Крайне рекомендуется использовать эту команду только с заданием beam size директивой #maxalt, иначе время разбора вырастет очень сильно даже для коротких предложений.

Дополнительные материалы

Алгоритмы русской морфологии

Морфологический анализатор в виде программы

API морфологического анализатора

Многопоточность в морфологическом анализаторе

Ключевые особенности морфологического анализатора

Словарные статьи

Грамматические классы

Грамматические координаты

Лексикон

Словарь

Внутренний язык грамматической машины

Грамматический Словарь

Утилита LEXICON

Сегментатор и токенизатор

Синтаксический анализатор

  © Elijah Koziev 2010
прикладные проекты на основе грамматического словаря API грамматической машины компоненты для доступа к грамматическому словарю условия получения SDK токенизатор и сегментатор морфологический анализ и синтез лемматизатор база N-грамм синтаксический анализатор словоформы морфология и синтаксис русского языка падеж число род совершенный и несовершенный вид экспорт в SQL формат экспорт в XML формат скрипт SQL словаря структура SQL словаря структура XML словаря компоненты для доступа к грамматическому словарю ORM Persistent Dictionary Library лемматизация стемминг примеры использования грамматического словаря склонение существительных в русском языке склонение русских прилагательных спряжение глаголов в русском языке поиск текста с учетом морфологии OCR подсистема расширенные регулярные выражения генератор текста генератор случайного текста и имитатор рандомизатор синонимизатор перефразировщик Статистика буквенных паттернов

Грамматический словарь русского языка



Грамматический словарь
склонение и спряжение глаголов, существительных, прилагательных

В состав входит русский и английский словарь.

платформа:  Windows 2000 ... Windows 7
требования: 512 Mb свободной памяти, 300 Мб на диске
размер:         34 Мб

  скачать грамматический словарь купить грамматический словарь SDK грамматического словаря
грамматический словарь русского языка



SDK Грамматического словаря



SDK Грамматического Словаря
склонение и спряжение глаголов, существительных, прилагательных

В состав входит русский и английский словарь.

платформа:  Windows 2000 ... Windows 7
размер:         13 Мб

SQL словарь (демо):
sqlite mysql oracle firebird mssql

скачать демо-версию SDK купить SDK API грамматического словаря



Поисковая система



Integra
настольная и сетевая поисковая система 

платформа:  Windows XP ... Windows 7
требования: 512 Mb свободной памяти
размер:         21 Мб

Дополнительные компоненты:
MySQL поисковый сервер 13.5 Мб
Integra.Premium MySQL 3.9 Мб

скачать поисковую систему SDK поисковой системыописание поисковой системы



SDK Поисковой системы



SDK Поискового движка
API для настольной и сетевой поисковая система 

платформа:  Windows XP ... Windows 7
размер:         17 Мб

Дополнительные компоненты:

MySQL поисковый сервер 13.5 Мб
Integra.Premium MySQL 3.9 Мб

скачать SDK SDK поисковой системы



Экранный переводчик



Translator
экранный переводчик

платформа:  Windows XP ... Windows 7
требования: 256 Mb свободной памяти
размер:         4.4 Мб

Дополнительные компоненты:
расширенный англо-русский словарь 6.4 Мб


скачать экранный переводчикописание экранного переводчика



изменено 30-Sep-13