Рассмотрим более подробно сведения, которые предоставляет сервис Wunderground. Во-первых, рассмотрим вариант ответа на запрос о текущем состоянии атмосферы в конкретной точке. В качестве примера рассмотрим данные для города Сан-Франциско. Отметим, что в ответе API содержится более ста полей, однако для генерации текстового материала будет использована лишь часть из них. Так, например, помимо информации о местоположении метеостанции и времени наблюдения для работы естественного-языкового генератора потребуются данные о значении температуры воздуха, относительной влажности атмосферы, направлении и скорости ветра, максимальной скорости порывов ветра, атмосферном давлении, а также тренде атмосферного давления за прошедшие три часа, температуре точки росы, значении ощущаемой температуры (рассчитывается исходя из температуры воздуха, влажности и скорости ветра), количестве и фазе выпавших осадков. Кроме того, могут быть также интересны данные о дальности горизонтальной видимости, интенсивности солнечной радиации и значении UV-индекса. Вся эта информация предоставляется сервисом в виде ответа в формате JSON или XML.

Рис 1. Часть ответа на запрос информации о текущих погодных условиях API сервиса Weather Underground.

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

Wunderground также предоставляет исторические погодные данные по текущей дате в виде так называемого «альманаха» - он содержит сведения о максимальной и минимальной температурах, зафиксированных в конкретном городе за всю историю метеорологических наблюдений, а также информацию о средней низкой и высокой температурах. К сожалению, сведения о рекордах и относительных многолетних нормах по атмосферному давлению, скорости и направлению ветра, влажности и другим параметрам атмосферы сервис не предоставляет.

Кроме того, через API системы Wunderground можно также получить информацию о фазе Луны, проценте освещенности ее поверхности солнечным светом, времени восхода и захода Солнца и Луны.

Ответы API, как уже было сказано выше, могут быть представлены в формате XML или JSON. Первый, extensible markup language или расширяемый язык разметки, представляет собой документ, в котором содержится набор тэгов с заключенной в них информацией. Такие документы достаточно громоздки и не всегда удобны в использовании и при парсинге. В то же время JSON - JavaScript Object Notation - занимает меньший объем при схожем количестве данных, более удобен при парсинге и, несомненно, гораздо легче, нежели XML, читается человеком. По этой причине в рамках данной работы будут использоваться ответы API в формате JSON.

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

Таким образом, можно сделать вывод, что предоставляемые сервисом Weather Underground данные о метеорологической обстановке полностью подходят для создания на их основе генератора текстов на естественном языке, в задачи которого будет входить создание новостных журналистских материалов об изменении погоды. Стоит отметить, что несмотря на отсутствие некоторой информации в ответах API сервиса и относительную неполноту некоторых данных, этот факт не влияет на правильную работу текстового генератора, поскольку для целей данной работы не требуется проведения подробного анализа состояния атмосферы - достаточно лишь основных описывающих его физических параметров.

В то же время выходные данные должны быть представлены, напротив, в текстовой форме - на естественном языке, то есть, языке общения человека. Выходной текст также должен отвечать ряду требований, однако они не являются столь жесткими и однозначными как в случае с входящей информацией. Рассматриваемые требования можно разделить на те, что относятся к форме текста и те, что определяют непосредственно его содержание. Итак, во-первых, итоговый текст должен быть представлен на естественном (в данном случае русском) языке, во-вторых, он должен отвечать требованиям правил грамматики языка - не нарушать правил орфографии, пунктуации и других лингвистических предписаний, на которых строится языковая система. В-третьих, итоговый текст должен быть связанным и осмысленным, то есть, нести в себе какую-либо информацию, отвечать на вопросы конечного пользователя системы - читателя. В-четвертых, текст не должен быть слишком большим по объему, его размеры должны соответствовать стандартной короткой журналистской новости, то есть не превышать примерно тысячу знаков с пробелами. Таким образом, становится ясно, что по отношению к выходным данным, то есть результату работы всей системы, применяются менее строгие требования, нежели к информации, поступающей на вход текстового генератора. В первую очередь это обусловлено отсутствием строгой типизации и относительной свободой производимого алгоритмом текстового материала.

2.2 Методология разработки алгоритма и основные принципы его работы

В рамках данного подраздела будут рассмотрены основные принципы работы алгоритма автоматической генерации текста на естественном языке на основе данных о прогнозе погоды, выделены главные элементы архитектуры сервиса, определена его структура, а также выявлены основные этапы его разработки. Ранее в рамках данной работы упоминалось, что выходными данными для создаваемого текстового генератора является информация о текущем состоянии атмосферы, прогнозе погоды и исторических метеорологических данных, которые представлены в виде нетекстовой (нелингвистической) форме, то есть имеют вполне определенную структуру и могут быть обработаны с помощью компьютера - то есть являются машиночитаемыми. В то же время на выходе система должна предоставлять информацию, наоборот, в лингвистической форме, а именно, текстовый материал на естественном языке (в данном случае на русском языке), содержащем сведения в человекочитаемом виде. Таким образом, сам текстовый генератор выступает здесь в роли своеобразного адаптера, который умеет анализировать исходные данные и «переводить» их на язык общения людей.

Рассмотрение устройства программного алгоритма будем проводить параллельно с пояснением этапов его работы. Как уже ранее указывалось в первой главе данной работы, функционирование текстовых генераторов, как правило, принято делить на несколько основных этапов, среди которых выделяют: 1) этап сбора данных; 2) этап анализа данных; 3) этап планирования будущего текста; 4) этап генерации текстового материала. В зависимости от конкретной реализации стадии работы программы могут также включат в себя дополнительные этапы, например, публикация текста в редакционной системе, либо специализированные стадии сбора и обработки информации. Такие специализированные этапы выделяют, допустим, в том случае, когда для генерации текста необходимо проанализировать большое количество различных источников - после получения данных из первого источника их необходимо скомпоновать с информацией из второго, затем из третьего, четвертого и так далее. Кроме того, перед компоновкой зачастую требуется «адаптировать» сведения друг под друга, поскольку данные, полученные из разных мест, как правило, отличаются по формату и форме представления. По этой причине информацию сначала следует привести к единому виду для проведения дальнейшего анализа и подготовки оценок на основе поступивших данных.

Применительно же к разрабатываемому нами генератору текста на естественном языке, подготавливающему журналистские материалы о прогнозах погоды, следует, исходя из общей схемы разделения на определенные этапы времени работы подобных программ, выделить собственные стадии.

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

Второй же вариант работы текстового генератора предусматривает алгоритм, который начинает свою работу после получения специальной команды. Программа делает запрос в хранилище данных (например, базу данных или сторонний API) и начинает анализ поступившей информации только после непосредственного запуска. У такого способа есть как сильные, так и слабые стороны. Так, главный минус заключаются в первую очередь в том, что при построении текстового генератора по данной схеме практически исключается возможность анализа всей поступающей информации, а значит, растет шанс пропустить какие-либо выдающиеся и необычные данные. Впрочем, стоит отметить, что при разработке текстовых генераторов следует уделять внимание объему обрабатываемой одновременно информации. Так, например, существуют такие области, в которых постоянный анализ данных практически невозможен или сильно затруднен ввиду того, что информация представлена в виде огромных массивов данных, для обработки которых требуются большие вычислительные мощности. Таким образом, далеко не всегда необходимы алгоритмы, непрерывно следящие за изменением данных в реальном времени - зачастую программы должны предоставлять отчет и результат своей работы лишь по запросу. Подобные алгоритмы могут запускаться как вручную человеком, так и работать в полуавтоматическом режиме, начиная работу через определенные промежутки времени по таймеру.

Отметим, что в случае с текстами о прогнозах погоды далеко не всегда требуется какой-либо особый информационный повод - прогнозы изменения метеорологической обстановки уже сами по себе являются отдельным видом журналистского материала. Это говорит о том, что в подобном тексте может как присутствовать, так и отсутствовать какая-либо информация новостного характера. Так, например, в случае описания в прогнозе скорого наступления экстремальных по своему характеру погодных условий, такой текст, безусловно, будет содержать в себе новость. Примером подобного материала может являться следующее предложение: «В конце недели в Москве ожидаются рекордные температуры: столбик термометра преодолеет отметку в плюс сорок градусов». С другой стороны, в прогнозе могут описываться вполне рядовые изменения погодных условий или же вовсе не описываться никаких изменений - например, при стабильной летней погоде: «В конце недели погода в Москве не изменится: ожидаются средние температуры, солнечная погода без осадков». Несмотря на то, что в журналистском плане утверждение «погода в Москве в ближайшее время не изменится» вполне можно назвать новостью, с точки зрения данных здесь нет никакого события - характер информации никак не меняется, а значит для алгоритма оно скорее всего останется незамеченным.

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

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

В данном случае система будет использовать как принципы и подход, применяемый в шаблонных системах, так и те, что используются в более сложных ЛМ-системах, содержащих в качестве ресурсного компонента базы данных и базы знаний. Так, создаваемый текст на естественном языке разрабатываемый алгоритм собирает из ряда различных блоков, хранящихся в базе данных и носящих универсальный характер. Следует пояснить, что информация о словах на естественном языке храниться в специальной таблице в базе данных, где она структурирована по форме «ключ-значение», то есть где каждому ключу соответствует свое уникальное слово или словосочетание на естественном языке. Например, ключу «temp_increase» соответствует выражение «ожидается потепление», а ключу «wind_dir_change» - выражение «ветер поменяет направление». При этом, несмотря на внешнюю схожесть с шаблонной системой, в действительности алгоритм устроен несколько сложнее. Ресурсы программы не содержат каких-либо единых универсальных шаблонов, в которые подставляется актуальная информация - в базе данных хранятся именно отдельные части текста, компоновка которых между собой и является основной задачей алгоритма. Таким образом итоговый текст представляет собой цепочку простых преобразований - конкатенаций различных строк между собой в зависимости от анализируемых данных.

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

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

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

В ходе проведения анализа программа во-первых, фиксирует, какая информация представлена в прогнозе, после чего сравнивает значения прогнозных метеорологических показателей с данными о текущей погоде - в случае обнаружения значимых отклонений, данная информация также фиксируется. После этого прогнозные данные сравниваются со сведениями из «альманаха» - выявляются отличия значений параметров атмосферы в прогнозе от средних многолетних, абсолютных максимальных и минимальных значений за период метеорологических наблюдений. Этап анализа информации в данном случае не содержит каких-либо массивных математических вычислений или сложной статистической оценки данных, однако подобного «взгляда» на входящие данные достаточно для создания на их основе текста не естественном языке. Впрочем, разрабатывать алгоритм следует таким образом, чтобы на этапе анализа можно было без значимого изменения кода программы, добавлять или убирать дополнительные виды анализаторов.

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

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

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

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

2.3 Структура алгоритма и используемые технологии

После рассмотрения этапов работы алгоритма следует уделить внимание структуре программы, выявить ее внутреннее устройство, выделить модули и определить их функции и зону ответственности. В целом для разработки программы была избрана модульная архитектура, которая предусматривает наличие отдельных независимых друг от друга блоков, каждый из которых выполняет четко закрепленную за ним функцию. Такой подход позволяет строго разграничить методы, которые выполняет модуль, а также очертить зону его ответственности - таким образом при проектировании алгоритма соблюдается один из главных принципов объектно-ориентированного программирования - принцип единой ответственности (single responsibility principle - SRP), согласно которому каждый из используемых объектов должен иметь одну ответственность, которая ко всему прочему инкапсулируется внутрь описывающего его класса. Благодаря использованию SRP удается значительно сократить количество ошибок в коде, связанных с непрозрачностью отношений между классами программы, поскольку разные типы ошибок указывают на неправильную работу программы в конкретном месте - внутри определенного модуля, другие же модули не имеют к данной ошибке никакого отношения, поскольку отделены от того участка программного кода, который сработал неправильно.

Приведенные выше этапы работы алгоритма очень хорошо описывают и архитектуру программы, поскольку в целом каждый этап выполняется своим отдельным модулем. Рассмотрим их более подробно. Итак, программный код разрабатываемого текстового генератора, по нашему мнению, следует разделить на следующие блоки (см. Приложение 1): 1) data access module - модуль доступа к данным; 2) analysis module - модуль, отвечающий за анализ данных; 3) text module - блок, который решает все задачи, связанные непосредственно с текстом, начиная с планирования его содержания и заканчивая самой генерацией.

Первый из представленных модулей, data access module, как следует из названия, занимается получением данных. Внутри этого блока находится кодовая база, отвечающая за взаимодействие со сторонним API - в нашем случае API сервиса Wunderground - обработку его ответов и первичную подготовку информации. Именно модуль доступа к данным начинает свою работу на первом этапе функционирования алгоритма - по запросу, пришедшему от клиента, в котором содержится информация о городе, для которого необходимо составить прогноз, программа подготавливает соответствующий запрос к API, после чего анализирует ответ сервиса и либо отправляет полученные данные на дальнейшую обработку, либо возвращает ошибку исполнения. При этом сами модули имеют и собственное внутреннее устройство, как правило, они состоят из нескольких классов, разделенных по принципу работы с данными и задачам, которые они выполняют. Так, например, в случае с data access module, можно выделить следующие его внутренние компоненты:

1) фасад (faзade) - внешняя сторона модуля, набор методов, которые скрывают за собой устройство модуля, позволяя вызывать лишь определенные публичные, то есть доступные извне, функции. Фасад представляет собой общепринятый и часто используемый при разработке программного обеспечения паттерн проектирования. Такой шаблон позволяет внешне упростить структуру модуля, скрыв сложные алгоритмы за публичной частью как за фасадом.

2) сервис (service) - класс, отвечающий за логику обработки и компоновки данных. В данном конкретном случае для генерации текстового материала требуются не только данные о самом прогнозе погоды, но также информация о текущих погодных условиях и историческая справка на день. Таким образом, полученные данные должны быть правильным образом собраны в один единый объект. Подобная логика преобразования информации содержится в алгоритмах сервиса. Публичные методы сервиса вызываются находящимся на уровень выше фасадом.

3) дата-маппер (data-mapper) - блок, в задачи которого входит непосредственно получение данных из стороннего API. В рассматриваемом случае дата-маппер формирует и выполняет HTTP-запросы к внешнему сервису, затем получает информацию, проводит первичную ее компоновку в модель и возвращает в сервис.

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

Второй модуль, отвечающий за проведения анализа полученных данных, решает задачи парсинга и «изучения» информации. В этом блоке информация о прогнозе погоды, текущем состоянии атмосферы и исторический погодный экскурс взаимно анализируются с целью выявить в составленном прогнозе необычные отклонения, которые могут стать информационным поводом для текста, который будет создан в дальнейшем. Внутреннее устройство data analysis модуля отличается от структуры модуля доступа к данным - в данном случае отсутствует компонент, работающий с внешним сервисом. Поэтому структурно модуль анализа можно разделить на фасад, сервис и модель - первый делает доступными методы для вызова из-за пределов модуля, второй занимается непосредственно анализом данных, которые по его завершении компонуются в заранее подготовленную модель.

Наконец третий, текстовый, модуль решает задачи предварительного планирования и генерации текстового материала. Данный модуль является самым большим и выполняет больше всего функций: сначала поступивший в него из аналитического модуля материал обрабатывается, на его основе создается структура на формальном языке, которая после этого преобразуется в текст на естественном языке. Примечательно, что данный модуль занимается не только обработкой информации, но и делает запросы в базу данных, где в частности хранятся блоки текста по ключам, в связи с чем в его внутреннем устройстве обязательно присутствует уровень доступа к данным. Итак, структура text module является более сложной, нежели у модулей, рассмотренных ранее, она состоит из: фасада, общего сервиса, а также дата-маппера, который один из них отвечает за взаимодействие с базой данных, где хранятся ключи на формальном язык и содержатся выражения на естественном языке, сортированные по этим ключам. Кроме того, в структуре модуля также отдельно присутствует так называемый text composer - класс, занимающийся непосредственно генерацией текста не естественном языке из блоков, представленных в базе данных - этот элемент программный конкатенирует строки в виде отдельных кусков текста в единый текстовый материал.

Важным элементом рассматриваемой системы являются и блоки, делающие возможным взаимодействие модулей. Стоит отметить, что для создания условий наиболее полного контроля за потоком данных, используемая архитектура исключает возможность прямого «общения» модулей между собой - информация из одного блока в другой может передаваться только через третий элемент, своеобразного посредника. Это позволяет четко задать потоки данных и иметь возможность контроля за исполнением программы. Таким образом, на уровень выше модулей расположен общий диспетчер (dispatcher), который направляет данные в нужный модуль, вызывая определенные методы его фасада, тем самым переключая этапы работы алгоритма. Важно понимать, что диспетчер не имеет представления о том, какие именно данные, в каком виде и формате, передаются через него - он лишь располагает информацией о том, откуда и куда эти данные должны быть переданы. Такой подход опять же реализует принцип единой ответственности - ответственность за содержание данных лежит на сгенерировавшем их модуле, ответственность же за передачу информации - на диспетчере. Кроме того, на уровень выше диспетчера находится контроллер (controller), который отвечает за взаимодействие всей системы с HTTP-сервером. Поскольку текстовый генератор должен постоянно находиться в сети, ему необходим сервер, который обеспечивает получение и обработку входящих запросов, а также отсылает в ответ результат работы алгоритма. В данном случае сервер будет обслуживать единственный адрес, принимающий параметры на GET запрос и возвращающий сгенерированный текст на естественном языке.

Также важно отметить, что модульная архитектура обладает серьезным преимуществом перед другими типами структурного строения веб-сервисов, так как может достаточно легко быть масштабирована или дополнена. Так, например, в случае перехода на API другого метеорологического сервиса, не нужно будет переписывать код всей программы, достаточно лишь поменять алгоритм в data mapper, а также модель, которые находятся внутри data access module. Схожее решение будет реализовано и в случае если при дальнейшем использовании системы решено будет вообще отказаться от получения данных через сторонний API, а вместо этого информация будет загружаться напрямую из базы данных. Аналогично в случае добавления дополнительных анализаторов, претерпит изменения лишь кодовая база аналитического модуля - другие блоки останутся неизменными.

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

Важной составляющей проектирования алгоритма также является описание стека (stack) используемых технологий. Рассмотрим этот аспект более детально. В первую очередь необходимо проанализировать язык программирования, на котором может быть реализован данный алгоритм. Примечательно, что в действительности выбор языка программирования не играет большой роли, поскольку в целом данная задача может быть решена с помощью большого множества различных языков, остается лишь вопрос удобства работы с каждым из них.

В данном случае в качестве языка для разработки серверной части приложения был выбран Python по причине удобства работы с языком, а также наличия большого количества специализированных библиотек для работы с текстом и NLP на случай дальнейшего расширения возможностей программы и подключения новых функций. Для реализации генератора используется микрофреймворк с WSGI-веб-сервером Flask.

В качестве системы управления базой данных была избрана MySQL. Данная СУБД имеет простой и понятный синтаксис языка SQL, множество сторонних программ с графическим пользовательским интерфейсом для работы с данными и надежные средства для обмена информацией с базой данных через программный код на языке Python.

Для удобства загрузки на сервер (деплоинга) и настройки окружения программный код запускается внутри docker-контейнера. Такой подход позволяет значительно сократить время, затрачиваемое на запуск алгоритма, избавляет от необходимости создавать виртуальную машину и устанавливать на ней соответствующие зависимости - при использовании docker все необходимые зависимости устанавливаются внутри закрытого контейнера с определенной операционной системой. Безусловно использование данной технологии позволяет при необходимости без труда мигрировать программный код на другой сервер. Клиентская часть приложения написана с использованием HTML, CSS и JavaScript, а также частично микрофреймворка для Python - Flask.

Стоит однако отметить, что стек используемых технологий в случае необходимости может быть изменен в зависимости от параметров системы и задач по ее оптимизации. Так, например, может быть выбран другой язык программирования, заменена СУБД - к примеру, в случае увеличения нагрузки на базу данных, MySQL может быть заменена PostgreSQL или Oracle, кроме того, возможно произвести такое изменения алгоритма, которое позволит использовать нереляционные базы данных, например, MongoDB. Клиентские расширения, которые обрабатывают и представляют обработанную на сервере информацию, могут быть реализованы не только в виде веб-интерфейса, но и в виде, например, чат-ботов для соцсетей и мессенджеров, плагинов для браузеров.

Таким образом, подытожим основные моменты, касающиеся архитектуры алгоритма и используемых для его работы алгоритмов. Во-первых, в качестве структуры программы была избрана модульная архитектура. Такая структура обладает рядом преимуществ, главными среди которых являются: гибкость приложения, возможность расширения программы, добавления новых функций и дополнительных анализаторов, разграничение ответственности модулей, высокая отказоустойчивость системы. Приложение состоит из следующих модулей: модуль доступа к данным, аналитический модуль и текстовый модуль. Во-вторых, данные между модулями передаются не напрямую, а через третью сторону - посредника, которым является вышестоящий диспетчер. Именно этот элемент архитектуры приложения отвечает за передачу информации от одного блока другому. В-третьих, поскольку программа должна постоянно находиться в сети для получения, обработки и вывода информации, приложение оснащено веб-сервером. В качестве языка программирования серверной части используется Python с микрофреймворком Flask, в качестве СУБД - MySQL, в качестве окружения и среды исполнения - docker. В-четвертых, стек используемых технологий при необходимости может быть изменен или дополнен иными сервисами без нарушений логики работы алгоритма - спроектированную структуру можно реализовать практически на любом языке программирования с использованием различных СУБД.

Заключение

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

Алгоритмы автоматической генерации текстовых материалов активно используются в крупных западных средствах массовой информации, например, в Los Angeles Times, The Washington Post, Associated Press, Forbes, ProPublica и многих других. В то же время российские издания сегодня практически не используют в своей работе роботов. По мнению исследователей, это обусловлено несколькими факторами. Во-первых, экономическими причинами - как правило, разработка и настройка роботов требуют серьезных финансовых затрат. Во-вторых, отсутствием технической возможности изданий внедрить подобные алгоритмы в работу редакции. В-третьих, роль играет и некая консервативность российских средств массовой информации.

Однако с учетом специфики и особенностей деятельности российских изданий разработка и внедрение программы автоматической генерации текстовых журналистских материалов становятся не только возможными, но и приобретают актуальность. Так, например, разрабатываемая система должна обладать некоторыми ключевыми свойствами и отвечать ряду требований. Во-первых, это простота настройки и внедрения генератора в работу редакции, возможность запуска алгоритма «из коробки». Во-вторых, высокая степень автономности программы, отсутствие необходимости постоянного контроля за ее работой. И, в-третьих, относительно невысокая стоимость разработки и внедрения алгоритма - использование подобной программы должно быть экономически выгодно изданию.

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

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

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

Список использованной литературы и источников

1. Романовский И. В. Дискретный анализ. -- 4-е изд., испр. и доп. СПб.: Невский Диалект, БХВ-Петербург, 2008. - 336 с.

2. McDonald D. Natural language generation systems / McDonald D., Bolc L. -- SpringerVerlag. 1988. -- 388 p.

3. Али А.А., Али Х.К. Проектирование интеллектуальной диалоговой обучающей системы на базе онтологий // Вестник Казанского технологического университета. 2015. №23. С.92-95.

4. Андреева Т.А. Возможность автоматизации процесса генерирования тестовых наборов // Universum: технические науки. 2017. №8 (41). С.5-7.

5. Барышникова Н.Ю. Обработка запросов на естественном языке на основе семантических сетей и шаблонов // Вестник АГТУ. Серия: Управление, вычислительная техника и информатика. 2016. №4. С. 36-45

6. Бородин Д.С., Строганов Ю.В. К задаче составления запросов к базам данных на естественном языке // Новые информационные технологии в автоматизированных системах. 2016. №19. С. 119-121.

7. Варнавская О. О. Текст как единица языка и произведение речи // Известия РГПУ им. А.И. Герцена. 2008. №58. С. 58-60.

8. Васильева И.Р. Расстановка знаков препинания между однородными членами в Интернет-запросах // Наука. Мысль: электронный периодический журнал. 2015. №9. С.23-27.

9. Гурин Н.И., Жук Я.А. Морфологический анализ текста для генерации базы знаний диалоговой информационной системы // Труды БГТУ. Серия 3: Физико-математические науки и информатика. 2016. №6 (188). С.156-159.

10. Ердесов С. Ж. Способы трансляции выборки с естественного языка на язык SQL // Научная перспектива. 2014. № 4 (50). С. 215.

11. Иванов А.Д. Роботизированная журналистика и первые алгоритмы на службе редакций международных СМИ // Знак: проблемное поле медиаобразования. 2015. №2 (16). С. 32-40.

12. Иванов А. Д. Курс на роботизированную журналистику: почему российским медиа не грозят современные мировые тенденции / А. Д. Иванов // Профессиональная культура журналиста цифровой эпохи : материалы Всероссийской научно-практической конференции с международным участием (Екатеринбург, 19 мая 2017 г.). -- Екатеринбург : Изд-во Урал. ун-та, 2017. -- С. 46-48.

13. Ильвовский, Д. А., Черняк Е. Л. Системы автоматической обработки текстов // Открытые системы. - 2014. - № 1. - С. 51-53.

14. Карамова Айгуль Айратовна Текст и дискурс: соотношение понятий // Вестник ЮУрГУ. Серия: Лингвистика. 2013. №2. С.19-23.

15. Коробова И.Л. Математическое обеспечение подсистемы синтеза текста в САПР // Вестник ТГТУ. 2011. №1. С.32-36.

16. Личаргин Дмитрий Викторович, Трушакова Анастасия Ивановна, Сафонов Константин Владимирович, Бачурина Елена Петровна Разработка системы рекурсивных порождающих грамматик для решения задачи автоматического построения интонационных шаблонов языковых выражений // Сибирский журнал науки и технологий. 2014. №5 (57). С.93-100.

17. Максимов А. А., Крапчатова Т. В., Клышинский Э. С., Визильтер Ю. В. Генерация стихов по прозаическому тексту // Новые информационные технологии в автоматизированных системах. 2012. №15. С.217-226.

18. Мочалова А.В. Алгоритм семантического анализа текста, основанный на базовых семантических шаблонах с удалением // Научно-технический вестник информационных технологий, механики и оптики. 2014. №5 (93). С.126-132.

19. Осминин П.Г. Модель автоматического реферирования на основе базы знаний, ориентированная на автоматический перевод // Вестник ЮУрГУ. Серия: Лингвистика. 2014. №2. С.65-69.

20. Осминин Павел Григорьевич Современные подходы к автоматическому реферированию и аннотированию // Вестник ЮУрГУ. Серия: Лингвистика. 2012. №25. С.134-135.

21. Письмак А.Е., Харитонова А.Е., Цопа Е.А., Клименков С.В. Оценка семантической близости предложений на естественном языке методами математической статистики // Научно-технический вестник информационных технологий, механики и оптики. 2016. №2. С.324-330

22. Пруцков А. В. Алгебраическое представление модели формообразования естественных языков // Cloud of science. 2014. №1. С.89-98

23. Пруцков А. В. Определение и генерация сложных форм слов естественных языков при морфологическом анализе и синтезе // Известия ЮФУ. Технические науки. 2006. №15. С. 10-14.

24. Розанов А.К. Быстрый алгоритм анализа словоформ естественного языка с трехуровневой моделью словаря начальных форм // Cloud of science. 2016. №1. С.115-124

25. Розанов А.К., Пруцков А.В. Алгоритмы и методы представления знаний для предсинтаксического анализа текстов на естественных языках // Cloud of science. 2017. №3. С.415-433

26. Цику Лариса Халидовна. Текст как результат речевой деятельности // Известия РГПУ им. А.И. Герцена. 2008. №86. С. 262-265.

27. А.Е., Цопа Е.А., Клименков С.В. Оценка семантической близости предложений на естественном языке методами математической статистики // Научно-технический вестник информационных технологий, механики и оптики. 2016. №2. С.324-330.

28. Adrian Muscat, Anja Belz / Learning to Generate Descriptions of Visual Data Anchored in Spatial Relations. IEEE Computational Intelligence Magazine ( Volume: 12, Issue: 3, Aug. 2017 ) p. 23-42.

29. Gkatzia, Dimitra; Lemon, Oliver; Rieser, Verena / Data-to-Text Generation Improves Decision-Making Under Uncertainty. In: IEEE Computational Intelligence Magazine, Vol. 12, No. 3, 08.2017, p. 10-17.

30. Jose M. Alonso, Alberto Bugarin, Ehud Reiter / Natural Language Generation with Computational Intelligence. IEEE Computational Intelligence Magazine ( Volume: 12, Issue: 3, Aug. 2017 ) p. 8-9.

31. Nina Dethlefs / Domain Transfer for Deep Natural Language Generation from Abstract Meaning Representations. IEEE Computational Intelligence Magazine ( Volume: 12, Issue: 3, Aug. 2017 ) p. 18-28.

32. Горбачевская Елена Николаевна, Краснов Станислав Сергеевич История развития нейронных сетей // Вестник ВУиТ. 2015. №1 (23). [Электронный ресурс]. URL: https://cyberleninka.ru/article/n/istoriya-razvitiya-neyronnyh-setey (дата обращения: 20.04.2018).

33. Замков А.В., Крашенинникова М.А., Лукина М.М., Цынарёва Н.А. Роботизированная журналистика: от научного дискурса к журналистскому образованию // Медиаскоп. 2017. Вып. 2. [Электронный ресурс]. URL: http://www.mediascope.ru/2295 (дата обращения: 16.03.2018).

34. Осминин П.Г. Построение модели реферирования и аннотирования научно-технических текстов, ориентированной на автоматический перевод [Текст]: автореф. дис. на соиск. учен. степ. канд. филолог. наук (10.02.21) / Осминин Павел Григорьевич; ФГБОУ ВПО «Южно-Уральский государственный университет» (Челябинск, 2016). [Электронный ресурс]. URL: http://www.tmnlib.ru/jirbis/files/upload/abstract/10.02.21/Osminin_P_G.pdf (дата обращения: 15.04.2018).

35. Судаков Б.Н., Маленкин А.С. Методы синтеза естественно-языковых текстов в экспертных системах // Вестник НТУ «ХПИ», 2012, №38. [Электронный ресурс]. URL: http://repository.kpi.kharkov.ua/bitstream/KhPI-Press/10379/1/vestnik_HPI_2012_38_Sudakov_Metodyi.pdf (дата обращения: 18.04.2018).

36. Шуклин Дмитрий Евгеньевич Применение семантической нейронной сети в экспертной системе, преобразующей смысл текста на естественном языке // Радиоэлектроника и информатика. 2001. №2 (15). URL: https://cyberleninka.ru/article/n/primenenie-semanticheskoy-neyronnoy-seti-v-ekspertnoy-sisteme-preobrazuyuschey-smysl-teksta-na-estestvennom-yazyke (дата обращения: 12.05.2018).

37. Alexander Fanta. Putting Europe's Robots on the Map: Automated journalism in news agencies // Reuters Institute Fellowship Paper. University of Oxford. [Электронный ресурс]. URL: https://reutersinstitute.politics.ox.ac.uk/sites/default/files/2017-09/Fanta%2C%20Putting%20Europe%E2%80%99s%20Robots%20on%20the%20Map.pdf (дата обращения: 24.03.2018).

38. Brian J Ford. Confusing the public with long words: the buzz-word generator. [Электронный ресурс]. URL: http://www.brianjford.com/anonscic.htm (дата обращения: 12.04.2018).

39. Hamilton, J. T. Accountability through algorithm: Developing the field of computational journalism [Text] / J. T. Hamilton, F. Turner // Report from the Center for Advanced Study in the Behavioral Sciences, Summer Workshop. - 2009. [Электронный ресурс]. URL: https://web.stanford.edu/~fturner/Hamilton%20Turner%20Acc%20by%20Alg%20Final.pdf (дата обращения: 20.02.2018).

40. Ian P Davy. Generating Spatio-Temporal Descriptions in Pollen Forecasts // Aerospace and Marine International, Banchory, Aberdeenshire, UK. [Электронный ресурс]. URL: http://www.aclweb.org/anthology/E06-2020 (дата обращения: 20.02.2018).

41. Recent Advances in Natural Language Generation: a Survey and Classification of the Empirical Literature // Computing and Informatics, Vol. 36, 2017, 1-32, doi: 10.4149/cai 2017 1 1. P. 1. [Электронный ресурс]. URL: http://www.cai.sk/ojs/index.php/cai/article/view/2017_1_1/810 (дата обращения: 10.03.2018).

42. Доклад «Humanity the Machine», 2016. [Электронный ресурс]. URL: http://www.mindshareworld.com/sites/default/files/MINDSHARE_HUDDLE_HUMANITY_MACHINE_2016_0.pdf (дата обращения: 17.03.2018).

43. Статья «Facebook's artificial intelligence shot down after they start talking to each other in their own language» на сайте www.independent.co.uk [Электронный ресурс}. URL: https://www.independent.co.uk/life-style/gadgets-and-tech/news/facebook-artificial-intelligence-ai-chatbot-new-language-research-openai-google-a7869706.html (дата обращения: 23.04.2018).

44. Статья «Microsoft's racist bot shows we must teach AI to play nice and police themselves» на сайте www.telegraph.co.uk[Электронный ресурс}. URL: https://www.telegraph.co.uk/technology/2016/03/25/we-must-teach-ai-machines-to-play-nice-and-police-themselves/ (дата обращения: 23.04.2018).

45. Статья «Robot writes LA Times earthquake breaking news article» на сайте www.bbc.com [Электронный ресурс}. URL: http://www.bbc.com/news/technology-26614051 (дата обращения: 23.03.2018).

46. Статья «The Washington Post leverages automated storytelling to cover high school football» на сайте www.washingtonpost.com [Электронный ресурс}. URL: https://www.washingtonpost.com/pr/wp/2017/09/01/the-washington-post-leverages-heliograf-to-cover-high-school-football/?noredirect=on&utm_term=.8457cc6630fa (дата обращения: 23.03.2018).

47. Большая Советская Энциклопедия. [Электронный ресурс]. URL: http://bse.sci-lib.com (дата обращения: 05.03.2018).

48. Толково-образовательный словарь русского языка Т.Ф. Ефремовой. [Электронный ресурс]. URL: https://www.efremova.info (дата обращения: 05.03.2018).

49. Сервис BloomSky. [Электронный ресурс]. URL: https://bloomsky.com/ (дата обращения: 20.04.2018).

50. Сервис OpenWeatherMap. [Электронный ресурс]. URL: https://openweathermap.org (дата обращения: 20.04.2018).

51. Сервис Wezzoo. [Электронный ресурс]. URL: http://www.wezzoo.com/ (дата обращения: 20.04.2018).

52. Сервис Weather.Gov. [Электронный ресурс]. URL: https://www.weather.gov/ (дата обращения: 20.04.2018).

53. Сервис Weather Underground. [Электронный ресурс]. URL: https://www.wunderground.com (дата обращения: 20.04.2018).

54. Сервис World Weather Online. [Электронный ресурс]. URL: https://www.worldweatheronline.com (дата обращения: 20.04.2018).

55. Система Kueri. [Электронный ресурс]. URL: http://kueri.me/ (дата обращения: 03.04.2018).

56. Система FrinedlyData. [Электронный ресурс]. URL: https://friendlydata.io/blog/best-nlp-apis (дата обращения: 03.04.2018).

57. Система ThatNeedle. [Электронный ресурс]. URL: http://www.thatneedle.com/nlp-api.html (дата обращения: 03.04.2018).

Приложение 1

Диаграмма классов алгоритма генерации текста на естественном языке на примере данных о прогнозе погоды.

Размещено на Allbest.ru