Разработка серверной части системы для лингвистических исследований
Сунцев Максим Александрович
Введение
В современном мире статьи, написанные на академическом английском, становятся все важнее для распространения научных знаний. Использование английского языка как linguafranca необходимо, например, при исследованиях, проводимых международными командами. Огромное число конференций также проводятся на английском, вследствие чего исследователь, обладающих знаниями в сфере академического письма, может выступать на конференциях мирового уровня.
Однако, академическое письмо на английском остается проблематичным даже для исследователей, обладающих высоким уровнем языка. Школьные и университетские курсы английского языка как иностранного редко концентрируются на академическом письме. Эти обстоятельства приводят к тому, что обучающиеся в целом имеют меньше опыта в написании академических текстов, чем в других языковых задачах.
В настоящее время образовательный процесс практически полностью проводится вручную. Задания на письмо в образовательных курсах по иностранным языкам, как правило, затрачивают больше времени у учеников и учителей, чем задания, например, по говорению или чтению. Тексты, написанные обучающимися, должны быть досконально прочитаны и проверены преподавателем, для того чтобы обучающийся получил объективную и полную оценку своего труда. Однако, преподаватель, как правило, не в состоянии проверить одинаково тщательно работы целой группы обучающихся, что ведет к снижению качества оценки.
Частичная автоматизация процесса может быть проведена при помощи программной системы, работающей с корпусами академических текстов. Здесь корпус - набор академических текстов с их ярко выраженными особенностями. Такие особенности анализируются с помощью специальных критериев, именуемых «маркерами», которые описываются заранее группой экспертов.
Предлагаемое решение позволяет определять стиль заданного текста в автоматическом режиме с использованием корпусов академических текстов. Так как обучающиеся имеют различный уровень владения английским языком, для каждого пользователя подготавливается набор индивидуальных рекомендаций по улучшению текста с целью приближения его к академическому стилю.
Использование аналитической системы дает возможность увеличить продуктивность как учителя, так и ученика. После анализа преподаватель сможет более детально сконцентрироваться на проблемных местах в тексте обучающегося, и впоследствии дать более специфичные и точные рекомендации ученику.
Объект исследования - программное обеспечение для обработки корпусов текстов. Предмет исследования - корпусные исследования академических текстов. Цель исследования - проектирование и разработка серверной части системы, позволяющего проводить анализ академических текстов. Для решения задач применяются методы объектно-ориентированного проектирования и программирования. Каждая задача должна быть выполнена и подробно задокументирована в настоящем отчете. Задачи исследования представлены в нижеследующем списке:
1. Анализ предметной области, рассмотрение аналогов.
2. Выдвижение требований к системе и разработка ТЗ.
3. Проектирование программной системы и ее компонентов.
4. Проектирование интерфейса приложения.
5. Реализация программной системы.
6. Отладка и тестирование системы.
7. Внедрение системы.
Отчет состоит из трех частей: анализ задачи; проектирование системы; реализация системы, тестирование и внедрение. В главе «Анализ задачи» подробно рассматривается предметная область, проводится поиск аналогов, выдвигаются требования к программной системе. В главе «Проектирование системы» производится поэтапное планирование системы, создание моделей этапа проектирования для последующей реализации системы. В главе «Реализация системы…» подробно документируется процесс разработки программы, ее отладки и тестирования, отражаются этапы ее внедрения.
1. Анализ задачи разработки портала для анализа академического письма
В данной главе будет проведен анализ предметной области и литературы и рассмотрены аналоги разрабатываемой системы. После сравнения способов хранения информации для портала будут выдвинуты требования к разработке и разработано техническое задание.
Существующие библиотеки для корпусных исследований
В рамках исследования были рассмотрены несколько библиотек, открытых и бесплатных к использованию, выявлены их сильные и слабые стороны, оценены технологические детали.
GATE
Библиотека GATEнаписана на Java и поддерживается уже довольно длительный промежуток времени [1]. GATE поставляется как в виде отдельного приложения, так и в качестве библиотеки GATE Embedded с практически идентичными функциональными возможностями. GATE- расширяемая среда, расширения можно разрабатывать на Java, соблюдая определенный интерфейс плагина. Процесс разработки плагина подробно описан в документации, где приведен шаблонный код для пустого плагина.
Рисунок 1.1 - Интерфейс GATE Developer
В GATE Developer можно создавать программы-конвейеры для обработки текстов, в качестве этапов в которых можно использовать как встроенные элементы, так и сторонние плагины (см. рисунок 1.1).
GATE может работать с произвольными корпусами, в том числе созданными пользователем. Для этого в программу обработки текста включается созданный корпус, после чего GATE будет работать с ним. GATE размечает корпусы документов и сохраняет аннотации в формате XML, из-за чего при необходимости этот файл можно проанализировать внешней программой с помощью XML парсера. Данный проект основывается на предыдущих проектах Научно-учебной лаборатории, и для GATE написано множество плагинов-маркеров, размечающих текст.
Фреймворк NLTK написан на Python, и является довольно мощным средством для анализа естественных языков [2]. Фреймворк довольно прост в использовании, при установке программисту доступны свыше 50 корпусов.
Однако, в отличие от GATE, где корпуса текстов подключаются программистом, и теоретически можно создавать любые корпуса текстов, здесь добавление корпусов происходит намного сложнее: для добавления нового корпуса следует написать класс, который реализует интерфейс корпуса, далее направить его разработчикам, лишь после этого корпус может быть добавлен.Это делает использование данной библиотеки в приложении проблематичным, так как от портала ожидается быстрый отклик в плане загрузки корпусов и их обработки. Теоретически, любой администратор должен иметь возможность загрузить корпус, чтобы другие пользователи смогли начать им пользоваться.
AntConc - приложение для работы с текстовыми документами в «сыром» формате - файлы, подлежащие обработке, поставляются в виде файлов *.txt[3]. AntConc не использует БД для хранения корпусов, поэтому его возможности ограничены анализом небольших объемов информации.
Рисунок 1.2 - Интерфейс программы AntConc
Интерфейс AntConc схож по внешнему виду с интерфейсом GATE Developer (см. рисунок 1.2). В отличие от GATE, где количество корпусов произвольно, здесь корпус один и фиксированный. Здесь так же есть центральное текстовое поле для отображения аннотированного текста.
По итогам анализа наиболее предпочтительным вариантом оказывается GATE, во многом благодаря его расширяемости, гибкости, а также из-за предыдущих наработок, которые присутствуют в большом количестве, и их перенос на другую платформу потребует довольно большое количество усилий и времени. Так как GATE написан на Java, дополнительным преимуществом станет его непосредственная и простая интеграция в код портала, который также планируется быть написан на Java.
Далее будут рассмотрены несколько подходов к хранению данных корпусов текстов, и будет принят выбор в сторону оптимального. У каждого подхода будут освещены достоинства и недостатки.
Первым и самым очевидным способом хранения информации является использование дискового хранилища. Основным объектом анализа на портале будут загружаемые пользователями документы Project Proposal на английском языке, в среднем объем которых составляет 20 МиБ. Такой объем делает хранение полного текста в классической базе данных затруднительным, в то время как данный подход позволяет хранить файлы настолько большие, насколько это позволяет файловая система.
К сожалению, такой подход сводит на нет все преимущества современных БД, а также ORM, которые позволяют быстро создавать и внедрять сущности БД без лишнего шаблонного кода.
Так как выше было оговорено, что целевые файлы являются довольно большими, использование классической SQLбазы данных является несколько проблематичным в случае, если стоит задача хранить сущности полностью в базе данных. Тем не менее, если допустить, что файлы будут храниться в файловой системе, а в базе данных будут указаны лишь ссылки на них, то данный подход сработает.
Очевидным неудобством является необходимость вручную загружать внешние файлы после загрузки записей из базы данных, а также факт того, что даже небольшие файлы будут размещены не в базе данных, а в файловой системе. Для размещения небольших файлов в базе данных придется писать дополнительный шаблонный код, который будет выбирать хранилище для документов в зависимости от их размера.
Новейшие базы данных, такие как MongoDB, соревнуются в скорости с традиционными реляционными БД, а также позволяют хранить крупное содержимое прямо в записях. Записи в MongoDB можно расширять динамически - здесь нет фиксированной табличной структуры, как в реляционных БД. Согласно документации MongoDB [4], максимальный размер документа, который можно сохранить напрямую в БД, составляет 16 МиБ, что достаточно для разрабатываемого портала, так как по сравнению с этой цифрой, размеры обрабатываемых текстов на порядки меньше.
В случае, если документы становятся больше 16 МиБ, MongoDB позволяет использовать встроенную файловую систему GridFS для хранения таких документов, что потребует использования APIдля их получения. MongoDB не поддерживает многопоточный доступ в отличие от SQL баз данных.
Таким образом, недостатки данного подхода начнут проявляться лишь при загрузке экстремально больших файлов, но так как в рамках работы оценочный размер документа составляет 20 КиБ, этот недостаток не представляет опасений.
В сравнении с традиционными реляционными БД MongoDB может проигрывать в скорости на определенных операциях, но так как данный проект несет исследовательскую направленность, скорость не является решающим фактором. Благодаря тому, что MongoDB хранит документы, при написании кода каждый документ будет сохраняться как единое целое, в отличие от подхода с сохранением файлов в файловой системе. Таким образом, код станет проще и нагляднее, а транзакции будут выглядеть единообразно.
Основываясь на предположении, что исходные файлы для анализа будут небольшими, а также что требования по скорости выполнения операций отсутствуют, выбор был осуществлен в сторону MongoDB,
Обзор литературы был проведен с целью сбора информации, имеющейся в области исследований. Данный проект является частью текущего исследования, проводимого совместно с Высшей школой экономики. С предыдущих лет остались как программные наработки, так и публикации. В частности, в материалах конференции [5] подробно обсуждается развитие аналитической системы, представлены различные детали методологии оценки текста, а также некоторые функции, которые система должна выполнять. Программное обеспечение, описанное в публикации, использует маркеры академического жанра, разработанные для библиотеки GATE ранее, в качестве основного средства анализа текста. В данном проекте при разработке приложения будет использоваться библиотека GATE с теми же маркерами.
В источнике [6] утверждается, что уровень владения студентами письменностью и связанными с ней навыками обычно уступает другим коммуникативным задачам. В частности, это связано с методикой обучения, которая фокусируется на аудировании, разговорной речи, грамматике и т. д., в то время как навыки письма часто рассматриваются как дополнительные. Автор описывает несколько подходов к обучению и в заключение предлагает комбинированную методику, которая, как утверждается в тексте, работает лучше. Первый из представленных здесь подходов - продуктовый подход (англ. Productapproach), который предполагает, что для написания текста обучающемуся следует знать некоторое количество шаблонов, следуя которым он сможет произвести текст. Автор утверждает, что эффективность такого метода сомнительна, и обучающиеся способны создавать качественные тексты только при изучении большого количества текстов, написанных носителями языка. Следующий - процессный подход (англ. Processapproach), который концентрируется на том, как пишется текст, а не на конечном результате. Применяя такой подход, обучающийся оперирует не шаблонами, а определенными активностями, которые он чередует, чтобы на выходе получился текст. Далее автор описывает жанровый подход (англ. Genreapproach), который схож с продуктовым подходом, но больше акцентирует внимание на социальном контексте написанного. Наконец, в статье предлагается гибридный подход (англ. Product-Genrebasedapproach), который объединяет процессный и жанровый подходы. Такой способ мышления может помочь избавиться от часто повторяющихся шаблонов, которые встречаются в продуктовом подходе, и в то же время создать естественный поток для письма студента.