Лингвистическое и программное обеспечение систем

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

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

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

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

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

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

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

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

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

В ходе сборки словаря специальная  программа (компилятор словаря) читает текстовое представление правил и преобразует его в более  удобное бинарное представление, которое сохраняется в словарной базе. Прикладные программы и компоненты грамматического словаря при необходимости подгружают правила в память и используют их для устранения или подавления вариантов распознавания. Все это происходит автоматически, и не требует от прикладного кода никаких специальных действий, помимо вызова функции 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, все детали алгоритмов поиска по лексикону полностью скрыты. Структуры, обеспечивающие быстрый поиск, создаются движком самостоятельно при сборке словаря и не требуют какой-либо настройки.