Додаток 1

Додаток 1.

Особливості реалізації програмного забезпечення для семантичного та семантико-синтаксичного аналізу. Програмна архітектура лінгвістичного процесора

Таблиця – Особливості реалізації програмних компонентів для лінгвістичного аналізу текстів на ПРИРОДНІЙ МОВІ та проведення експериментальних досліджень

Тип програмного компонента Мова реалізації Об'єм коду

Модулі лінгвістичного аналізу С++ понад 40 000 рядків коду

Сценарії для проведення експериментальних досліджень Python 2.7 понад 3000 рядків коду

 

Програмна архітектура лінгвістичного процесора

Введемо два поняття:

• Аналізатор – програмний компонент, який або перетворює тексти природною мовою на структуровану форму, або перетворює одне структуроване подання тексту на інше.
• Мовний ресурс – це фрагмент лінгвістичної бази знань про деякий ЕЯ: словник, тезаурус, модель машинного навчання, система правил, кінцевий автомат та ін.

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

1) Необхідна можливість використовувати мовні ресурси, призначені лише для читання, відразу у кількох аналізаторах. Аналізатори для своєї роботи, як правило, потребують різного роду мовні ресурси. Наприклад, для морфологічного аналізатора зазвичай необхідний словник, у якому зберігаються словоформи природної мови, і навіть статистична модель дозволу морфологічної омонімії; для синтаксичного аналізатора на основі системи переходів необхідна модель вибору дій аналізатора; для семантичного аналізатора, який описаний у цій дисертації, потрібен словник, в якому міститься інформація про предикатні слова та їх рольові структури, словник ролей для запитальних слів та ін. Як правило, ці ресурси займають великий обсяг оперативної пам'яті. У результаті аналізатор зазвичай здійснює лише операції читання цих ресурсів. Тому, щоб не виділяти пам'ять під кілька копій тих самих великих ресурсів для кількох аналізаторів, в яких вони потрібні, архітектура лінгвістичного процесора повинна забезпечувати можливість розділяти використання одного мовного ресурсу між кількома об'єктами-аналізаторами. Ця вимога особливо важлива для програм, які мають здійснювати обробку текстів у кілька потоків.

2) Необхідно забезпечити реентерабельність аналізаторів та потокобезпеку доступу до мовних ресурсів. Ці властивості потрібні для створення багатопотокових програмних систем. Властивість реентерабельності аналізаторів необхідне створення кілька копій аналізаторів у пам'яті, які можуть обробляти текст паралельно кількох потоках. Властивість потокобезпеки доступу до мовних ресурсів, необхідне паралельного читання цих ресурсів кількома аналізаторами, які у різних потоках.

3) Необхідно передбачити можливість обробляти тексти різних природних мов, використовуючи однакові алгоритми, але різні мовні ресурси. Необхідно також надати можливість враховувати особливості різних мов у цих алгоритмах, не допускаючи дублювання програмного коду. Часто одні й самі методи і підходи можна використовуватиме обробки текстів різними мовами. У цьому відрізняються лише невеликі елементи алгоритмів, і навіть мовні ресурси, необхідні їхньої роботи.

4) Необхідна можливість гнучкого конфігурування аналізаторів на етапі створення. Аналізатори для обробки текстів природною мовою через свою складність, як правило, мають велику кількість параметрів. Архітектура програмного забезпечення обробки тексів на ПРИРОДНІЙ МОВІповинна забезпечувати однаковий підхід завдання цих параметрів на етапі створення об'єктів-аналізаторів.

5) Необхідно передбачити можливість вибирати режим роботи аналізатора при кожному запуску функції обробки тексту без необхідності перестворювати аналізатор заново. Крім параметрів, які задаються на етапі створення аналізатора, часто виникає необхідність перемикатися між режимами роботи. Це потрібно, наприклад, коли лінгвістичний процесор працює як сервіс у розподіленій системі обробки інформації, і результати його роботи використовуються в різних додатках, які потребують дещо різних структур даних або різної лінгвістичної інформації.

6) Необхідно забезпечити просту інтеграцію кількох окремих аналізаторів у єдиному програмному модулі. Для вирішення прикладних завдань обробки текстів на природній мові високого рівня часто потрібно вирішити безліч низькорівневих підзадач їх передобробки і провести безліч видів аналізу для отримання досить глибокого структурованого представлення тексту. Для вирішення кожної окремої прикладної задачі можуть знадобитися різні види аналізу та їх комбінації. Це веде до необхідності мати безліч окремих аналізаторів, кожен з яких вирішує своє окреме невелике підзавдання, причому кожен окремий аналізатор повинен мати можливість легко інтегруватися в систему обробки тексту, що вирішує загальне прикладне завдання.

7) Необхідно забезпечити можливість окремих аналізаторів обмінюватись між собою результатами обробки. Кожен аналізатор має набір необхідних роботи вхідних даних і виробляє безліч вихідних. Вхідними параметрами можуть бути, наприклад, текст у вигляді рядка, список токенів або речень, морфологічна розмітка та ін; результатами роботи – синтаксична, семантична розмітка, вилучені з тексту іменовані сутності та інших. Необхідно мати можливість зберігання різнорідної інформації про тексті, але при цьому також мати можливість передати як вхідні параметри іншому аналізатору певний елементарний зріз цієї інформації. Аналізатори, у свою чергу, повинні приймати на вхід лише той елементарний зріз інформації про текст, який безпосередньо необхідний для їхньої роботи.

Для виконання цих вимог лінгвістичний процесор можна побудувати на основі однієї з відомих програмних платформ, що спеціалізуються на аналізі текстів, таких як GATE, Apache UIMA, Ellogon та ін. запуску аналізаторів у розподіленому обчислювальному середовищі, графічні інструменти для розробки та тестування лінгвістичних аналізаторів. Проте існує низка причин, через які застосування подібних платформ або неможливо, або надмірно і веде до зайвої складності розробки, або просто небажано. Серед цих причин може бути погана сумісність технологій платформи та технологій, у рамках яких ведеться основна розробка програмного забезпечення; трудомісткість створення додаткових обгорток, необхідні інтеграції розроблених аналізаторів у платформу; необхідність можливості швидко та гнучко вносити зміни при розробці аналізатора, наприклад, у ході проведення наукових досліджень; необхідність розробки аналізатора відразу під кілька платформ аналізу тексту. Таким чином, часто потрібна не всеосяжна платформа, а лише архітектура, що задає основні принципи побудови лінгвістичного процесора, яка дозволить дотриматися всіх зазначених вище вимог. У ході досліджень було розроблено подібну архітектуру, яка також може розглядатися як певний патерн проектування лінгвістичного процесора.

Введемо такі поняття:

• Аналізатор – об'єкт, який вирішує елементарне низькорівневе завдання обробки тексту. У ньому інкапсульовано алгоритми обробки тексту;
• Мовний ресурс – об'єкт, який надає доступ до мовних ресурсів, таких як словники, моделі машинного навчання та ін.
• Конвеєр – об'єкт, який формує загальне структуроване подання тексту, необхідне подальшого вирішення деякої прикладної завдання високого рівня.

Розглянемо кожний пункт вимог.

1) Можливість використання мовних ресурсів, призначених лише читання, відразу у кількох аналізаторах передбачає, що класи-аналізатори нічого не винні володіти цими ресурсами і повинні контролювати час існування ресурсів. Мовний ресурс повинен створюватися окремо, час його життя повинен контролювати об'єкт, який має клас вищого рівня, наприклад, конвеєр. Самі аналізатори повинні зберігати посилання ресурси, отримані при ініціалізації. Аналізатори повинні бути легковажними об'єктами, які допускають копіювання. Остання властивість може бути використана при розробці багатопотокових додатків: ініціалізований об'єкт-аналізатор може бути скопійований для роботи в різних потоках, як це робиться в деяких реалізаціях патерну "фабрика".

2) Реєнтерабельність класів-аналізаторів означає, що аналізатори не повинні зберігати проміжний стан між зверненнями до них у глобальних або статичних об'єктах. Щоб забезпечити безпеку потоків класів, які відповідають за доступ до лінгвістичних ресурсів, необхідно заборонити зміну цих об'єктів у часі після ініціалізації.

3) Щоб обробляти тексти різних ПРИРОДНІЙ МОВІз допомогою єдиних алгоритмів, необхідно за реалізації якнайменше прив'язувати алгоритм до конкретного ЕЯ, оформляючи все специфічні мови компоненти як лінгвістичних ресурсів. Мовні ресурси може мати загальний абстрактний інтерфейс, але специфічну кожному за мови реалізацію. Специфічні для ПРИРОДНІЙ МОВІелементи алгоритму можна інкапсулювати як віртуальних функцій. Базовий абстрактний клас реалізує алгоритмічне ядро аналізатора. Для кожного ПРИРОДНІЙ МОВІможе бути створений окремий клас, успадкований від базового абстрактного класу, в якому реалізовані віртуальні функції, специфічні для заданої мови.

4) Для конфігурування аналізаторів на етапі створення та ініціалізації, пропонується передавати або в конструктор, або в функцію initialize покажчики на об'єкти, що управляють мовними ресурсами, та об'єкт підкласу Configuration, який містить інші параметри аналізатора.

5) Для вибору режиму роботи аналізатора під час запуску функції обробки тексту пропонується, крім інших параметрів, використовувати об'єкт підкласу Options. У цьому об'єкті повинні зберігатися всі параметри,

що вказують на режим роботи аналізатора.

6) Інтеграцію кількох аналізаторів пропонується здійснювати у конвеєрі. Цей конвеєр повинен забезпечувати створення та ініціалізацію необхідних для його роботи аналізаторів, а також створення та ініціалізацію мовних ресурсів, необхідних для їх роботи. Конвеєр керує часом життя об'єктів-аналізаторів та об'єктів, які відповідають за доступ до мовних ресурсів. Він також керує потоками даних та забезпечує виконання аналізаторів у правильному порядку. Для кожної прикладної високорівневої задачі обробки текстів природною мовою (або групи завдань) рекомендується створювати окремий клас конвеєр, який інтегрує у собі всі необхідні аналізатори та ресурси для її вирішення.

7) Структури даних, якими обмінюються аналізатори, повинні являти собою набір шарів, кожен з яких створюється окремим аналізатором і може бути переданий іншому аналізатору як вхідний параметр окремо від усіх інших. Наприклад, при проведенні морфологічного, синтаксичного та семантичного аналізу, варто передбачити як мінімум три класи, які забезпечують зберігання результатів кожного аналізу відповідно. Окремо варто відзначити патерн анотацій, запропонований в рамках проекту TIPSTER. Анотації є універсальною графовою моделлю подання лінгвістичної інформації. У сучасних реалізаціях платформ обробки текстової інформації анотації є список відрізків тексту, з кожним з яких пов'язана деяка інформація. Це може бути рядок, число, посилання на іншу інструкцію. При використанні цієї моделі кожен аналізатор у конвеєрі повинен створювати новий список анотацій, який може бути використаний наступним аналізатором вищого рівня.

На UML-діаграмі класів нижче схематично проілюстровано

архітектури лінгвістичного процесора. Методи та члени класу описані мовою С++. ProcessorTypeBase1 – позначає одне із базових абстрактних класів аналізаторів; ProcessorTypeLanguageSpec1 - позначає класаналізатор, що реалізує специфічні для конкретного ПРИРОДНІЙ МОВІелементи алгоритму; PipelineType – означає клас-конвеєр; LangIndepResource - позначає клас, що представляє доступ до мовного ресурсу, реалізація якого не залежить від ЕЯ; LangDepResource1 – означає клас, що надає доступ до мовного ресурсу, реалізація якого залежить від ЕЯ.

 

PipelineType

LangDepResource1 m_res1;

LangDepResource2 m_res2; LangDepResource3 m_res3;

LangIndepResource1 m_res4; LangIndepResource2 m_res5;

ProcessorTypeLanguageSpec1 m_proc1; ProcessorTypeLanguageSpec2 m_proc2; ProcessorTypeLanguageSpec3 m_proc3;

+ void initialize (const

PipelineType::Configuration&conf);

+ void process(const std::string&text, Language lang, FinalAnnotations& annots, const PipelineType::Options& opts);

LangIndepResource1

Data m_data;

+ virtual const Elem&getResourceElem() const = 0;

ILangDepResource1

Data m_data;

+ virtual const Elem&getResourceElem() const = 0;

LangDepResource1

+ const Elem& getResouceElem() const override;

ProcessorTypeBase1

const LangIndepResource1* m_readOnlyRes1;

const LangIndepResource2* m_readOnlyRes2;

const ILangDepResource1* m_readOnlyRes3;

+ void initialize (const

LangIndepResourcePtrs&res, const

ProcessorTypeBase1::Configuration&conf);

+ void process(const InputAnnotations& input, OutputAnnotations& output, const ProcessorTypeBase1::Options& opts);

# virtual Res1 languageSpecific1(const Params1& param) = 0;

# virtual Res2 languageSpecific2(const Params2& param)= 0;

ProcessorTypeLanguageSpec1

const LangDepResource1* m_readOnlyLr1; const LangDepResource2* m_readOnlyLr2;

+ initialize(const LangDepResourcePtrs& lr, const

ProcessorTypeLanguageSpec1::Configuration & conf);

# Res1 languageSpecific1(const Params1& param) override;

# Res2 langaugeSpecific2(const Params2& param) override;

 

 

Малюнок – Архітектура лінгвістичного процесора