CC BY
29
СПИСОК ЛИТЕРАТУРЫ
1. Clusker М., Hogan D., Vass P. The ternary calculating machine of Thomas Fowler // IEEE Annals of the History of Computing. 2005. 27. N 3. P. 4-22.
2. http://www.mortati.com/glusker/fowler/ternary.htm
3. Брусенцов H. П. Алгоритмы деления для троичного кода с цифрами 0, 1, — 1 // Вычислительная техника и вопросы кибернетики. Вып. 10. JL: Изд-во ЛГУ, 1974. С. 39-44.
4. Брусенцов Н. П., Маслов С. П. и др. Малая цифровая вычислительная машина "Сетунь". М.: Изд-во МГУ, 1965.
5. Гусев В. А., Мордкович А. Г. Математика: Справочные материалы. М.: Просвещение, 1990.
6. Карцев М. А. Арифметика цифровых машин. М.: Наука, 1969.
Поступила в редакцию 10.09.07
УДК 519.6
А.В. Чередниченко
ИНСТРУМЕНТАЛЬНАЯ СИСТЕМА ДЛЯ ИНТЕГРАЦИИ КОМПОНЕНТОВ ЛИНГВИСТИЧЕСКОГО ПРОЦЕССОРА. ОПИСАНИЕ И СПОСОБЫ ПРИМЕНЕНИЯ
(кафедра алгоритмических языков факультета ВМиК, e-mail: [email protected])
В данной статье рассмотрены основные механизмы работы реализованной инструментальной системы для интеграции компонентов лингвистического процессора. Описываемая в данной статье реализованная инструментальная система позволяет использовать уже существующие компоненты лингвистических процессоров в рамках целевой системы автоматической обработки текстов. Также данная инструментальная система дает возможность сравнить уже подключенные компоненты на одинаковых наборах текстов на естественном языке. После проведения сравнительного анализа компонентов можно определить точный состав модулей и словарей, которые можно будет наиболее эффективно использовать для создания отдельной системы автоматической обработки текстов для решения конкретной специфической задачи.
1. Введение. В настоящее время создание различных систем автоматической обработки текстов на естественном языке (АОТ-систем) является актуальной практической задачей. Исследованием различных аспектов (теоретических, алгоритмических, программистских), связанных с реализацией АОТ-систем, занимается одна из компьютерных наук — компьютерная лингвистика.
Как правило, АОТ-система в той или иной степени включает в свой состав лингвистический процессор (ЛП) — комплекс программ, осуществляющих автоматический анализ и синтез входного текста на естественном языке. Традиционно ЛП, построенный по модульному принципу, состоит из следующих компонент: морфологического, синтаксического, семантического и прагматического. С каждым компонентом связана своя лингвистическая база знаний (словари, грамматики, таблицы), имеющая определенную структуру [1].
При создании АОТ-систем необходимо определить, какие конкретно компоненты ЛП будут использоваться в качестве внешних, какими структурами данных будет оперировать система, какой подход будет выбран для решения поставленной задачи. Важными факторами являются как язык реализации системы, так и механизмы для хранения обрабатываемых данных и результатов обработки.
Несмотря на большое количество реализаций аналогичных компонентов лингвистического процессора, при попытке подключения какого-либо из них к реализуемой системе возникают следующие проблемы:
• несоответствие структур данных, используемых в системе и в подключаемом компоненте;
• отсутствие поддержки со стороны разработчика компонента;
• возможное несоответствие решаемой задаче лексического состава словаря, которым оперирует внешний компонент;
• проблемы, связанные с особенностями реализации внешнего компонента.
В том случае, когда не удается подобрать компонент ЛП из уже имеющихся или процесс интеграции оказывается слишком трудоемким, необходимо соответствующий компонент писать самим, что, конечно же, отвлекает от основной решаемой задачи.
Таким образом, решение задач из области компьютерной лингвистики в определенных случаях может быть крайне неэффективным из-за большого количества накладных расходов. Описываемая в данной статье реализованная инструментальная система позволяет минимизировать эти расходы и использовать уже существующие компоненты лингвистических процессоров в рамках целевой системы автоматической обработки текстов. Также данная инструментальная система дает возможность сравнить на одинаковых наборах текстов на естественном языке уже подключенные компоненты. После проведения сравнительного анализа компонентов можно определить точный состав модулей и словарей, которые можно будет наиболее эффективно использовать для создания отдельной системы автоматической обработки текстов для решения конкретной специфической задачи.
2. Требования к инструментальной системе интеграции компонентов лингвистического процессора. Система должна выполнять следующие действия:
• работу с разнородными внешними подключаемыми компонентами лингвистического процессора;
• объединение работы специалистов из различных областей (лингвистов, программистов, администраторов ресурсов);
• интеграцию с постоянно изменяющимися внешними по отношению к системе компонентами;
• ввод данных в систему как в автоматическом, так и в ручном режиме;
• поддержку многопользовательского режима работы с лингвистическим процессором;
• управление ресурсами системы в рамках самой системы;
• отсутствие ограничений на размещение компонентов системы в элементах вычислительной сети — возможность работы автоматизированных рабочих мест с сервером приложений в рамках глобальной сети; возможность размещения базы данных системы на отдельном сервере.
Требование интеграции с внешними компонентами обусловлено тем фактом, что закрытая система неспособна активно развиваться без должной коммерческой поддержки. Реализация системы должна содержать необходимый для работы минимум в виде уже подключенных компонентов (внешних или реализованных внутри системы), однако при условии легкой интеграции с другими существующими лингвистическими процессорами (или отдельно взятыми компонентами) интерес конкретных пользователей к системе будет выше, чем к закрытой системе, заведомо не удовлетворяющей всем пользовательским требованиям. Система не должна быть обычной библиотекой компонентов — для эффективного решения задач компьютерной лингвистики требуется объединять усилия специалистов из различных областей: программисты должны интегрировать необходимые компоненты в систему, лингвисты должны оценить эффективность и адекватность алгоритмов, подключаемых к системе. Все эти задачи должны решаться в рамках единой системы для наиболее эффективного использования ресурсов при решении поставленной задачи.
Предлагаемая система должна поддерживать многопользовательский режим работы с интегрированными компонентами ЛП. Это относится как к механизму хранения данных (для обеспечения доступа к данным для нескольких пользователей одновременно), так и к механизму управления ресурсами самой системы. Администрирование ресурсов системы должно удовлетворять принципу многопользовательских систем (т. е. ресурсы должны изменяться только теми пользователями, которые обладают соответствующими правами). Данное требование позволит построить иерархическую структуру, которая будет воспроизводить административные структуры, в рамках которых будет использоваться система. Например, для вуза необходимо разделение ресурсов системы по группам учащихся, по кафедрам и по факультетам. Соответственно подобная гибкость в настройках позволит использовать один механизм разделения прав доступа к ресурсам в различных случаях при внедрении системы. Отсутствие ограничений на размещение компонентов системы в элементах вычислительной сети подразумевает ее использование как в рамках локальной сети, так и при работе в Интернете. Таким образом, система не должна ориентироваться на наличие в сети каких-либо серверов, кроме сервера приложений и сервера базы данных. В классической трехзвенной схеме с пользовательских мест к
серверу базы данных доступа, конечно же, не существует, однако в данном случае это требование не реализовано.
3. Описание принципов построения и работы системы
3.1. Пользователи системы. В системе выделены три различных типа пользователей, обладающих специфическими знаниями и решающих различные задачи.
Интегратор обеспечивает возможность использования компонента ЛП в рамках системы. Он должен понимать то, каким образом можно работать с внешним компонентом ЛП, для того чтобы создать интеграционный модуль, являющийся частью системы. Также интегратор определяет структуры данных, которые будут использоваться в системе при работе с подключаемым компонентом.
Администратор сценариев обеспечивает возможность обращения к внешнему компоненту через интеграционный модуль в рамках сценариев. Также он изменяет существующие сценарии или добавляет новые для демонстрации возможностей подключаемого компонента.
Конечные пользователи системы (операторы и аналитики) выполняют существующие сценарии для того, чтобы обработать корпус текстов с применением уже подключенных компонентов ЛП. Также выполнение сценариев может осуществляться для сбора статистической информации при проведении сравнительного анализа нескольких компонентов ЛП, выполняющих аналогичные функции.
3.2. Механизм обработки текстов. При обработке текстов предлагается использовать последовательность действий, объединенных общей идеей обработки исходного текста на естественном языке. Будем называть такую последовательность действий сценарием.
Сценарии состоят из шагов — определенного типа действий с заранее заданными алгоритмами поведения сервера. Параметры шагов создаются и редактируются администратором сценариев. В зависимости от выбранного типа действий, производимых сервером на конкретном шаге анализа текста, соответствующим образом будет осуществлена операция по изменению текущего состояния исходного текста или базы данных. В момент выполнения сценария допускается обращение к результатам выполнения предыдущих шагов. Самым удобным представляется способ адресации, позволяющий создавать внутри сценария отдельные группы шагов, которые возможно перемещать без изменения описания выполняемых действий. Например, во время морфологического анализа можно получать различные словоформы различными способами, независимыми друг от друга, имея возможность изменять порядок генерации словоформ.
Существующие внутренние именованные переменные позволяют обращаться к результатам выполнения определенных шагов с использованием числового уникального идентификатора. Такое обращение несколько более громоздко, чем указание "адреса" значения (номера шага, абсолютного или относительного), однако обладает и рядом преимуществ: обращение ко всем внутренним переменным возможно из нескольких сценариев, что делает их удобным механизмом передачи данных между выполняемыми сценариями. При завершении работы сценария можно описать набор "выходных" переменных, в которых будет храниться результат выполнения компонента ЛП (подобный механизм можно использовать для компонентов из одного "семейства" для обеспечения единообразного интерфейса для последующих компонентов).
При выполнении шага сценария система предоставляет возможность указать условия выполнения данного шага, что позволяет создать схему, в которой задействованные сценарии или их части будут выполняться в зависимости от некоторых определенных условий. Условия выполнения могут быть определены администратором сценариев как заранее (при создании или редактировании сценария), так и в процессе выполнения анализа (например, выполнение шага может зависеть от состояния определенной внутренней переменной либо от значения, полученного на каком-либо шаге в процессе выполнения сценария).
Допускается объединение сценариев в цепочки, которые могут быть применены циклически к одному и тому же тексту (или каким-то конкретным предложениям), могут осуществлять вызовы друг друга с передачей параметров в любой момент выполнения. Подобная схема позволяет обработать различные участки текста с применением различных сценариев. Например, при обработке текста из интернет-источников (статьи с новостных сайтов, результаты поисковых запросов, результаты голосований) требуется общий предварительный морфологический и конкретный синтаксический анализ.
Анализ подобных текстов требует различных подходов, однако должен предваряться одинаковым морфологическим анализом [2], т.е. после выполнения одного общего сценария администратор сценариев может описать вызовы различных сценариев, осуществляющих синтаксический анализ. Поскольку под сценарием понимается лишь последовательность действий, а не конкретная реализация какой-либо модели анализа, то он является независимым от этой реализации. При обработке и анализе сценариев в качестве интерфейса для работы с пользователем допускается применение экранных форм (для простоты называемых экранами), сформированных администраторами сценариев при создании сценариев. Экраны создаются с использованием языка разметки НТМЬ. Они могут содержать так называемые макросы — обрабатываемые сервером синонимы внутренних нумерованных буферов, содержащих какие-либо данные. Механизм макросов в совокупности с использованием языка разметки НТМЬ позволяет администратору сценариев реализовать практически любые интерфейсы на стороне клиента. Данное решение также предоставляет возможность подключения АсМуеХ-компонентов, исполнения ЛАУА-скриптов в коде НТМЬ-страниц, а использование последних технологий в области создания динамически формируемых страниц позволяет реализовать интерфейсы с большим количеством элементов и сложной логикой.
3.3. Результаты выполнения сценариев. После окончания работы всех сценариев исходный текст может быть представлен в виде семантически связанных объектов, обладающих некоторыми свойствами, связями, характеристиками этих связей, либо в виде реферата, либо в промежуточном виде, необходимом для синтеза текста на естественном языке, отличном от исходного. Способы преобразования и анализа исходного текста зависят лишь от администратора сценариев, который настраивает цепочку сценариев, и определяются поставленной задачей. По сути, весь набор сценариев может быть представлен графом, который создается и редактируется администратором. Каждая вершина графа — это отдельный шаг конкретного сценария, имеющий свою логику работы. Это шаг, на котором выполняется запрос к базе данных или к хранилищу текстов, либо это шаг ветвления, на котором в зависимости от состояния определенных внутренних переменных, состояния исходного текста или рассматриваемой логической единицы исходного текста принимается решение о следующем шаге анализа и т. д. Таким образом, сценарии не являются жестко закодированными, могут требовать ввода текста или принятия решения пользователем, могут целиком выполняться автономно, сохраняя результаты своей работы либо в базе данных, либо во внутренних переменных сервера анализа. Реализованная схема позволяет комбинировать виды анализа (описанные в виде сценариев) в необходимой последовательности. При тщательном выделении различных альтернатив анализа возможно создание динамически изменяющихся схем работы с текстами, которые будут использовать различные компоненты сценариев (либо различные сценарии) для различных групп текстов.
3.4. Работа системы. Для выполнения анализа текста была реализована следующая схема подключения внешних компонентов ЛП: компонент ЛП вызывается из динамически подключаемой библиотеки, входящей в состав системы. Интерфейс библиотеки для связи с системой остается неизменным. С другой стороны, интерфейс для вызова внешнего компонента реализуется с учетом особенностей этого компонента. Таким образом, внешняя подключаемая библиотека является адаптером, изменение которого не приведет к изменению ядра системы.
Структуры данных, используемые для решения поставленной задачи, могут быть либо интегрированы в систему из подключаемых компонентов, либо выбраны из уже существующих в системе структур. В качестве демонстрационных данных в работе рассматриваются два примера: для анализа текстов на естественном языке и выделения информации из этих текстов в автоматическом режиме. Система выполняет обработку информации в применении к некоторому набору предметных областей, и соответственно использование системы (или отдельных сценариев анализа) осуществляется в рамках определенной предметной области. Необходимо отметить, что настройка на конкретные структуры данных при начальном описании системы в процессе постановки задачи анализа не должна быть жестко заданной. Это позволяет сформировать начальный пакет настроек и производить адаптацию системы в процессе эксплуатации с учетом изменяющихся требований как к структурам данных, так и к результату обработки данных.
Для подключения внешнего компонента к системе необходимо учитывать определенные требования, предъявляемые к реализации данного компонента: • компонент должен быть оформлен в виде динамически подключаемой библиотеки (сШ);
• необходимо иметь возможность представления входных параметров и результатов работы компонента в виде строки;
• подключаемый компонент не должен обращаться к контексту выполнения подключенных к системе модулей, кроме интеграционного модуля;
• подключаемый модуль после завершения работы не должен сохранять внутренние переменные, поскольку он может быть заново проинициализирован при повторном обращении (политика инициализации компонента является настраиваемой).
В системе жестко задан интерфейс для вызова интеграционного модуля. Данный модуль разрабатывается интегратором — работником, в чью обязанность входит задача подключения внешних компонентов. Интегратор должен обладать знаниями о том, каким образом можно вызвать внешний компонент и в каком виде передать ему входные параметры. Интеграционный модуль является динамически подключаемой библиотекой, и добавление методов с определенным интерфейсом не потребует изменения или повторной компиляции сервера приложений [3]. Описание и пример реализации интеграционного модуля поставляется вместе с эксплуатационной документацией системы. Для обработки текстов и вызова компонентов ЛП опосредованно через интеграционный модуль используются сценарии, которые создаются в рамках системы на специально созданном скриптовом языке.
3.5. Скриптовый язык. Язык создания сценариев является достаточно простым. Он был задуман и реализован для решения конкретных задач, а именно для обеспечения интеграции компонентов ЛП и для предоставления доступа к базе данных во время выполнения сценариев. Также в языке предусмотрены средства ввода данных пользователем и вывод информации пользователю в текстовом виде. Сценарии на этом языке могут быть представлены в XML-подобном виде либо могут создаваться и редактироваться посредством автоматизированного рабочего места, входящего в состав системы.
4. Системы, решающие поставленную задачу. В настоящее время существует некоторое количество инструментальных систем, позволяющих решать задачу интеграции компонентов ЛП для изучения и использования этих компонентов при решении задачи автоматической обработки текстов.
Системы UIMA, GATE достаточно близкие по архитектуре и идеям, на которых они основаны, за небольшим исключением: GATE является однопользовательским приложением, осуществляющим чтение исходных данных из локально-доступного файлового ресурса. Существует принципиальная возможность организации единого хранилища результатов обработки текстов, однако идеология системы не подразумевает наличия единого выделенного сервера базы данных. С другой стороны, UIMA изначально позиционировалась как система, осуществляющая вызов удаленных процедур с клиентских мест. Однако в случае использования UIMA необходимо, по сути, программировать логику поведения системы каждый раз заново при подключении нового компонента. Также основной особенностью обозначенных систем является то, что сценарий использования компонентов ЛП является жестко фиксированным и представляется в виде последовательности вызовов различных компонентов ЛП, при этом очередной элемент в цепочке зависит от результатов работы предыдущего компонента.
Коммерческие продукты ClaraBridge, RetrievalWare, Ontos Miner — системы, решающие задачи выделения фактов из исходных текстов на естественном языке. Данные системы не предоставляют доступа к методам анализа данных и используемым компонентам ЛП. Каждая из этих систем ориентирована на применение в организациях с централизованным хранилищем и предоставляет возможность ввода данных в различных форматах, список которых содержит такие распространенные форматы, как RTF, DOC, HTML. Закрытость этих систем не позволяет самостоятельно дорабатывать либо полностью заменять алгоритмы анализа текстов.
5. Заключение. Предлагаемая система реализована как платформа, которая позволяет интегрировать и проверять работу нескольких реализаций различных компонентов ЛП одновременно.
Основные возможности созданной системы:
• интеграция программных модулей и словарей в состав системы для осуществления выбора и использование наиболее подходящих компонентов ЛП из всех подключенных к системе для решения конкретных задач из области компьютерной лингвистики;
• создание и изменение сценариев, которые описывают последовательность действий, выполняемых с исходными данными;
• поддержка иерархической организационной структуры пользователей, возможность параллельной работы как разработчиков для проверки разрабатываемых компонентов ЛП, так и конечных пользователей, осуществляющих анализ текстов на естественном языке при помощи ЛП;
• автоматическое выполнение заданного набора сценариев для осуществления автоматического анализа текстов;
• возможность запуска на одном или различных компьютерах нескольких копий сервера приложений для балансировки загрузки;
• возможность создания полностью автоматизированной системы по обработке текстов за счет использования сторонних приложений для доставки исходных текстов для анализа;
• возможность подключения внешних компонентов ЛП без необходимости проведения компиляции ядра системы.
В качестве проведенных экспериментов к системе были подключены морфологический и синтаксический компоненты [4]. Также были разработаны экспериментальные сценарии, позволяющие с помощью указанных подключенных компонентов создать АОТ-системы, решающие определенные задачи обработки текстов на русском языке (система анализа текстовых сообщений о пробках на дорогах; вопросо-ответная система, имитирующая сбор анкетных данных).
Проведенные эксперименты показывают, что наибольшая эффективность системы достигается при использовании нескольких подключенных компонентов. Применение системы гарантирует выполнение работы по интеграции компонента один раз при подключении его к системе. Система содержит необходимые механизмы администрирования ресурсов, что позволяет использовать ее как средство интеграции различных компонентов с минимальными доработками.
Описанная система интеграции компонентов лингвистического процессора при дальнейшем развитии представленных идей может быть доработана до полноценного коммерческого продукта, способного стать платформой для решения широкого спектра задач из области компьютерной лингвистики.
СПИСОК ЛИТЕРАТУРЫ
1. Волкова И. А. Введение в компьютерную лингвистику. Практические аспекты создания лингвистических процессоров. М.: Изд. отдел ф-та ВМиК МГУ, 2006.
2. Крылов С. А., Старостин С. А. Интегрированная информационная среда STARLING и ее использование в сфере корпусной лингвистики // Труды Международной конференции "Диалог 2006". М.: Изд-во РГГУ, 2007. С. 303-308.
3. Страуструп Б. Язык программирования С++. М.: Бином, 2002.
4. Сокирко A.B. Семантические словари в автоматической обработке текста (по материалам системы ДИА-ЛИНГ): Дис. ... канд. физ.-мат. наук. М., 2001.
Поступила в редакцию 07.05.07
