АРХИТЕКТУРА ПРОГРАММНОГО КОМПЛЕКСА ДЛЯ ПРОВЕДЕНИЯ ПОЛНОГО ЦИКЛА ИССЛЕДОВАНИЯ В ОБЛАСТИ МАШИННОГО ОБУЧЕНИЯ

ARCHITECTURE OF THE SOFTWARE COMPLEX FOR FULL CYCLE OF RESEARCH IN THE FIELD OF MACHINE LEARNING

Petr Vetrtakov

Student, National Research Nuclear University MEPhI (Moscow Engineering Physics Institute)

Russia, Moscow

Ivan Lisenkov

Researcher scientist, National Research Nuclear University MEPhI (Moscow Engineering Physics Institute)

Russia, Moscow

АННОТАЦИЯ

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

ABSTRACT

Detailed review of the workflow of researching and developing machine learning models was done.  Every step associated with the functional module, which processes tasks of that step. General principles of modules interaction were proposed. Simultaneously with principles there were developed a general architecture of the program solution.

Ключевые слова: машинное обучение, архитектура приложения, цикл исследования, разработка моделей, хранение данных

Keywords: machine learning, application architecture, research cycle, model development, data warehousing

Введение

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

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

В данной статье приводится общая концепция построения подобной системы и ее архитектура.

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

Описание всех модулей приводится последовательно, согласно рабочему процессу исследования (Приложение 1). Каждому шагу исследования ставится в соответствие отдельный модуль, ключевые особенности которого будут продемонстрированы в ходе описания процесса.

Сбор данных

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

Основным архитектурным подходом к интеграции системы с источниками данных является написание адаптеров. Задача адаптеров — подключиться к заданному источнику, получить необходимую информацию, преобразовать во внутренний формат хранения и сохранить в СУБД. Здесь и далее говорится об использовании СУБД в качестве общего хранилища информации.

В рамках первой версии прототипа были разработаны адаптеры к следующим источникам:

• загрузка данных из Excel-файла заданного формата о фьючерсных контрактах и опционах Korea Stock Performance Index (KOSPI),
• загрузка данных, публикуемых ЦБ РФ с помощью подключения к SOAP-серверу,
• загрузка обучающей выборки задачи классификации ирисов Фишера из текстового CSV-файла,
• загрузка текстового слоя из PDF-файлов.

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

Для сохранения данных в СУБД (или любое другое хранилище) был разработан специальный класс DBManager, который строго инкапсулирован в остальные части системы. С одной стороны, это позволяет достигнуть общего подхода обращения с данными (загрузки и получения); с другой стороны, это дает возможность с легкостью подменить механизм, лежащий в основе хранения информации, то есть сменить СУБД, провести обновление ПО или вовсе отказаться от сохранения в СУБД в пользу другого подхода.

С точки зрения Экспериментатора (роль конечного пользователя в системе), все адаптеры уже написаны, и он может вызывать их для загрузки либо настроить загрузку по расписанию. Предполагается, что разработка адаптеров должна быть выполнена Разработчиком (отдельная роль в системе), который владеет навыками программирования на Python 3.5 [3] — именно этот язык используется в качестве основного языка для сбора и трансформации данных.

Трансформация данных

Следующим шагом после загрузки является обработка загруженных «сырых данных». Под обработкой подразумевается:

• фильтрация,
• трансформация,
• обогащение,
• получение производной информации.

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

• Экспериментатор формулирует новые метрики, алгоритмы фильтрации и обработки данных, которые необходимо доработать для проведения эксперимента;
• На основании функциональных требований формируется (совместно с Разработчиком) техническое задание (ТЗ) на разработку;
• Разработчик реализует эти требования в системе согласно ТЗ.

Выбор модели

Самый важный этап в исследовании — это выбор модели, калибровка ее параметров и дальнейшее применение.

В систему включены виды моделей, которые построены на основе алгоритмов машинного обучения. Также в системе будут доступны модели, построенные на основе классических детерминированных алгоритмов, различные методы оптимизации и модели, определяемые математической формулой (например, модель CAPM [4]).

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

В рамках первой версии прототипа были разработаны следующие модели:

1. Многослойный персептрон,

2. Персептрон с одним скрытым слоем,

3. Рекуррентная нейронная сеть,

4. Линейная регрессия (на примере модели CAPM),

5. Скользящая средняя.

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

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

Построение обучающей выборки

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

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

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

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

Еще одно важное свойство Python — возможность динамически исполнять код, дополненный Разработчиком, в режиме работы системы. Все процессы будут существовать в рамках одной системы и находиться во взаимосвязи, при этом постоянно динамически дополняясь и изменяясь. Это позволяет организовать достаточно простое администрирование системы.

Обучение модели

Как только была завершена настройка формирования обучающей выборки, Экспериментатор приступает к обучению модели. Как было сказано выше, в системе включены виды моделей, не требующих данного шага, в этом случае Экспериментатор может сразу переходить к шагу «тестирование». В случае необходимости обучения модели в данный модуль должна быть передана обучающая выборка, сформированная на предыдущем шаге либо загруженная из базы данных СУБД. Экспериментатор настраивает соотношение, в котором необходимо разделить исходную обучающую выборку на части для обучения и тестирования.

Для вызова процесса обучения в общем программном интерфейсе предусмотрен метод fit. В метод fit передается следующая информация:

●обучающая выборка,

●тестовая выборка,

●условия остановки обучения,

●предельная ошибка на обучающей выборке,

●предельная ошибка на тестовой выборке,

●максимальное число эпох,

●детектирование переобучения.

Шаг обучения

Помимо вышеуказанных данных, в метод могут быть переданы дополнительные параметры, характерные для определенных алгоритмов.

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

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

Тестирование

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

Эксперимент

Завершающей стадией исследования является постановка эксперимента. Отличительная особенность проведения эксперимента — предполагаемое отсутствие «желаемого» отклика модели.

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

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

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

Наличие в системе возможности применять несколько видов моделей (алгоритмов) к одним и тем же данным при проведении эксперимента позволяет проводить сравнительный анализ эффективности применения выбранных видов моделей (алгоритмов) для решения поставленной задачи.

Отчет

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

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

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

Архитектура решения

Система представляет из себя клиент-серверное приложение, взаимодействующее с экспериментатором через веб-браузер.

Такое решение было выбрано по ряду причин:

• позволяет хранить и делиться данными между всеми пользователями данной системы;
• возможность удаленной работы с системой;
• низкие аппаратные требования, предъявляемые к рабочему месту Экспериментатора (клиент).

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

Заключение

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

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

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

Список литературы:

1. Neuromorphic Chips // MIT Technology Review. Available at:   https://www.technologyreview.com/s/526506/neuromorphic-chips/ (accessed: 10.05.2017).
2. ETL (Extract-Transform-Load) // Data Integration Info. Quick view on world of data. Available at: http://www.dataintegration.info/etl (accessed: 12.05.2017).
3. Python 3.6.1 documentation // Python documentation. Available at:   https://docs.python.org/3/ (accessed: 12.05.2017).
4. Capital Asset Pricing Model - CAPM // Investopedia. Available at:     http://www.investopedia.com/terms/c/capm.asp (accessed: 14.05.2017).

Приложение 1. Workflow

Приложение 2. Модули системы и их взаимодействие