Положим, хотите Вы создать веб-приложение. В современном мире создано неисчислимое множество ПО, призванного облегчить Вам жизнь. Можете воспользоваться каким-нибудь всеобъемлющим фреймворком, или подключить пару библиотек, которые решат за Вас типичные задачи вроде шаблонизации, управление базами данных, обеспечения интерактивности и тому подобное. Эти библиотеки предоставляют Вам единообразный интерфейс к решению как общих, так и исключительных задач, с которыми Вы, возможно, не были бы в состоянии сходу справиться.
Но среди этого обилия инструментов зияет значительный пробел: библиотека для работы с естественными языками.
«Но ведь таких много!» — хотите Вы возразить, — "NLTK, например, или lingpipe." Конечно, но разве Вы их используете? «Так мне в проекте, вроде как, не требуется обработка естественных языков.»
А ведь на самом деле, Вы занимаетесь обработкой естественного языка, даже не осознавая этого. Такое элементарное действие, как склеивание строк, — лишь частный случай генерации текстов на естественном языке, одной из основополагающих частей ОЕЯ1. А вот если Вам понадобится проделать более сложные операции, вроде образования множественной формы существительных, расстановки заглавных букв в предложении, изменение формы глагола, тут без применения лингвистики не обойтись2. Но когда резко понадобится получить множественную форму существительного, Вы скорее стянете пару регулярок с интернета, чем пойдёте искать подходящую ОЕЯ библиотеку. В этом частично виновата нераскрученность области ОЕЯ.
Стоит прикинуть, какие решаемые ОЕЯ задачи могу пригодиться в Вашем приложении: генерация ключевых слов, приведение к канонической форме, идентификация языка, полнотекстовый поиск, автодополнение, классификация по тематике и кластеризация, автоматическая аннотация, разбор рукописного текста или, может, какие-то ещё. Мало какому приложению всё это обилие потребуется одновременно, но многие могли бы только выиграть от внесения пары дополнительных возможностей. Блог, автоматически генерирующий теги, осуществляющий полнотекстовой поиск, автоматически аннотирующий записи для ленты новостей, определяющий временную последовательность по каким-то признакам. Но мало кто занимается реализацией таких возможностей, ибо занятие это довольно нетривиальное. Современные решения для данных задач обычно строятся на моделях, для порождения которых требуются огромные корпуса лингвистических данных. В большинстве случаев овчинка кажется не стоящей выделки, ибо вооружиться парой дюжин эвристик проще.
Оба рассмотренных примера подсказывают проблемы с областью практического применения ОЕЯ: существующие программные решения подразумевают, что пользователь хочет строить систему, занимающуюся исключительно ОЕЯ, когда ему-то всего лишь нужно прикрутить пару фишечек. Я не хочу получать докторскую степень в прикладной лингвистике, чтобы быть в состоянии быстро получить множественные формы для существительных или результат какой-то другой хорошо изученной в ОЕЯ задачи. Должно подразумеваться, что пользователь скорее будет пользоваться встроенной лингвистической моделью, чем будет тренировать свою. Хотя это и вносит некоторые ограничения, но сам принцип всё же предоставляет больше возможностей чем эвристики. А что куда важнее, воспользовавшись моделью и желая улучшить её, разработчик может просто натренировать её на текстах, специфичных для его приложения3.
Мой призыв: желаю видеть всю функциональность, на которую прикладная ОЕЯ в её нынешней младенческой форме способна, собранной в одном месте, где онa может пользоваться общими лингвистическими ресурсами и предоставлять простой интерфейс, который будет привлекать разработчиков. Желаю видеть сложные, но практически применимые технологии ОЕЯ доступными не только для лингвистов. Желаю наконец, что бы всё это создавалось на основополагающих принципах ОЕЯ, оставляя возможность улучшать первоначальные модели и алгоритмы. Инженеры области ОЕЯ очень бережно следят за собой, чтоб не поддаваться ложным ожиданиям (в отличии от громких надежд 80-ых). Где-то мы пока бессильны, и это в порядке вещей.
[1] Как область знаний, ОЕЯ конечно же не рассматривает склеивание строк как метод. Вместо этого изучаются возможности генерации текста на основе функционального описания желаемого результата. Как пример, местоименные выражения.
[2] Данная возможность (правила вывода множественной формы) собраны в папке language/ MediaWiki. Это один из самых многонациональных проектов с отрытым кодом, и поразительный источник информации о лингвистических странностях в иностранных языках.
[3] В качестве примера рассмотрим, как генерация текстов может помочь в локализации приложений. Положим, Вы хотите оповестить пользователя: «У Вас три новых сообщения». Самым простым решением было бы: printf(«Новых сообщений: %d», numMessages). Пойдя короткой дорогой мы избавлены от необходимости генерировать нужное числительное и согласующуюся форму слова «сообщение».
Если всё же хочется вывести уведомление в более естественной форме, то следующим шагом будет добавление пары функций: перевод числа в числительное и генерация нужной формы слова «сообщение». В итоге получится что-то вроде: printf(«У Вас %s новых %s», toNumeral(numMessages), pluralize(«сообщение», numMessages)). Так как большинство приложений изначально пишется на английском, бедным морфологией, простеньких велосипедов хватает, и в основном с такими проблемами сталкиваются при локализации.
Однако существует представление инвариантное для данной задачи. Рассмотрим грамматические зависимости, которые мы могли бы извлечь из нашего предложения немного попользовавшись ОЕЯ:
subj(сообщение-4, вы-1)
num(сообщение-4, три-2)
amod(сообщение-4, новый-3)
root(ROOT-0, сообщение-4)
Зададимся вопросом:«Используя эти данные, можно ли автоматически сгенерировать соответствующее сообщение на каком-нибудь языке, передающим ту же информацию и имеющим грамматически правильную структуру?» Это фундаментальный вопрос генерации текстов на естественном языке. (При том это вопрос не только машинного перевода, ибо получаемое сообщение может варьироваться в зависимости от указанного нами функционального назначения, которое вытащить непосредственно из текста довольно сложно.) Бесспорно было бы здорово получить волшебную чёрную коробку, выдающую нам грамматически правильные тексты по требованию, но и инструменты создаваемые для генерации текстов в наши дни могут заметно облегчить труд переводчикам. По моему мнению, эта тематика вполне заслуживает пристального исследования.
—
Ссылка на оригинальную статью.
Автор: VersusVoid
