ОБРАБОТКА ЕСТЕСТВЕННОГО ЯЗЫКА

Понимание науки о данных с полным стеком: как модель НЛП в ваших записных книжках Jupyter может действительно помочь остановить катастрофы, часть 2

Модель классификации сообщений о бедствиях от исследования до производства - автоматическая контейнеризация и развертывание модели

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

Что у нас есть на данный момент

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

  • .circleci - требуется инструментами непрерывной интеграции circleci, содержит файл circleci.config, который используется для автоматизации процесса обучения и развертывания модели.
  • cabin_messaging_classification_model - содержит пакет модели машинного обучения, который прогнозирует входящие сообщения в соответствующие классы.
  • Disaster_messaging_app - содержит API и файл докера, который может обслуживать обученную модель машинного обучения, которая будет развернута с помощью circleci.
  • Блокноты - содержит блокноты для исследовательского анализа.

Мы уже рассмотрели каталоги .circleci, бедствия_messaging_classification_model и записные книжки, теперь мы приступим к созданию внешнего и внутреннего интерфейса реагирования на стихийные бедствия. flask с файлом докера, который будет размещен в каталоге cabin_messaging_app. Мы рассмотрим содержимое этой папки в следующем разделе.

Структура каталогов

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

  • app - содержит основные определения приложения Flask.
  • журналы - автоматически генерируемые журналы для приложения Flask.
  • шаблоны - HTML-шаблоны для интерфейса приложения Flask.
  • tests - модульные тесты для приложения Flask.
  • Dockerfile - определение контейнера, в котором создается приложение Flask.
  • Makefile - важный сценарий автоматизации, который используется circleci.
  • pyproject.toml - файл определения зависимости, который используется для создания файла блокировки зависимостей (дополнительная информация здесь)
  • поэзия.lock - файл блокировки, созданный из файла pyproject.toml путем вызова poetry lock
  • run.py - скрипт, запускающий приложение flask.
  • run.sh - сценарий оболочки, запускающий run.py файл.

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

Создание окружающей среды

Помните, мы упаковали нашу модель машинного обучения в пакет, который размещен на сервере PyPI? Пришло время применить его. Создание пакета модели, как мы делали в части 1, позволяет нам установить нашу модель как зависимость пакета, когда мы пытаемся создать модель (как pandas, numpy и т. Д.). Мы снова будем использовать поэзию в качестве инструмента управления зависимостями, который обеспечивает фиксацию версий всех зависимостей. Мы создадим новую виртуальную среду, полностью отдельную от среды, которую мы создали при создании модели. Эта среда будет посвящена созданию нашего приложения. Мы определим следующие pyproject.toml в папке crash_messaging_app.

Обратите внимание, что здесь мы устанавливаемdisaster-message-classification-model как зависимость. Эта установка позволит нам использовать все модули нашей модели машинного обучения, определенные в части 1. Правильно определив среду, мы готовы определить основные магистрали для нашего веб-приложения с помощью flask.

Создание приложения Flask

Чтобы использовать предсказательную силу модели, нам нужно будет создать интерфейс, который позволит взаимодействовать нижестоящим пользователям. Обычные практики включают либо создание API, либо создание презентабельного веб-приложения. К счастью, любая из целей могла быть достигнута с помощью мощного и легкого фреймворка. Больше ресурсов о flask можно найти здесь. В нашем случае мы попытаемся создать полнофункциональное веб-приложение, которое будет размещено на Heroku.

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

Модуль app.py действительно прост, так как он создает только объект колбы и вызывает контроллер, определенный в controller.py, который показан ниже.

Модуль controller.py определяет маршрутизацию и внутренние функции приложения. В общем, это включает следующие 2 шага:

  1. Определите план и сохраните его с именем переменной
  2. Используйте переменную blueprint в качестве декоратора, определите маршрутизацию и функцию, обрабатывающую функциональность конкретного маршрута.

Например, предположим, что мы уже определили план как следующий

classification_app = Blueprint(“classification_app”, __name__)

если мы хотим перейти к URL /index, мы могли бы определить декоратор следующим образом

@classification_app.route(“/index”)

Для нашего контроллера мы определим следующие 5 маршрутов

индекс

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

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

здоровье

Этот маршрут служит для быстрой проверки состояния работоспособности веб-приложения. В нашем API маршрутизации используется метод GET.

версия

Этот маршрут служит для быстрой проверки версии веб-приложения. В нашем API маршрутизации используется метод GET.

предсказать

Маршрут определения API без внешнего интерфейса. При вызове этого маршрута прогноз входных текстов будет возвращен в виде ответа в формате JSON (очень похожего на Python dicts). Используя метод POST, мы сможем получить входные тексты из объекта ответа. Затем мы можем генерировать прогнозы с помощью метода make_prediction из нашего пакета модели машинного обучения (установленного в текущей среде). Наконец, мы можем собрать полезную нагрузку в словарь и вернуть желаемый ответ JSON.

go

Маршрут определения внешнего интерфейса. Вызывая этот маршрут, мы создадим красивый интерфейс, который выделяет класс, если наша модель предсказывает, что он равен 1. Так же, как и в маршруте API, мы можем получить входные тексты из объекта ответа. Затем мы можем генерировать прогнозы с помощью метода make_prediction из нашего пакета моделей машинного обучения. Затем мы можем вернуть обработанный шаблон go.html и использовать результат прогноза для создания красивой веб-страницы, подобной следующей. Входное сообщение: «Помогите, огонь рядом с моим домом».

Конкретное определение маршрута показано ниже.

Фантастика! Теперь мы создали основу нашего приложения для обмена сообщениями о бедствиях, мы можем просто вызвать sh run.sh в терминале и увидеть, как наше приложение запускается на https://0.0.0.0:5000. Как мы делали ранее в части 1, мы попытаемся создать некоторую автоматизацию рабочего процесса для создания этого приложения с помощью Makefile.

Автоматическая сборка веб-приложений

Помимо автоматизации установки пакетов зависимостей и тестов в Makefile (как описано в части 1), мы также сделаем следующее:

  • Установите ресурсы NLTK - наш модельный пакет имеет зависимость ресурсов NLTK, которая не будет автоматически установлена ​​с файлом требований поэзии. Этот шаг позволит нашей модели иметь эти ресурсы во время прогнозирования.
  • Создайте приложение на Heroku - автоматизируйте шаги для создания образа докера, который будет использоваться Heroku как платформа как услуга.
  • Отправить образ докера в Heroku - автоматизировать шаги по отправке созданного образа докера в Heroku.

Makefile будет выглядеть следующим образом.

Вам может быть интересно, что такое образ докера? Мы посмотрим в следующем разделе.

Сборка док-контейнера

Если вы посмотрите на формальное определение докера с официального сайта, оно гласит следующее:

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

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

Контейнеры Docker определяются с помощью dockerfiles, которые похожи на Makefiles - определяют серию шагов для создания и запуска приложения. Затем мы можем просто вызвать команду docker build, чтобы запустить автономное программное обеспечение в Docker. В нашем проекте команда выглядит следующим образом:

  1. Определите питон, используемый в пространстве докеров, с помощью команды FROM python:3.7.6
  2. Создайте пользователя с именем model-app-user, который будет запускать приложение с помощью команды RUN adduser --disabled-password --gecos '' model-app-user.
  3. Задайте рабочий каталог в контейнере Docker с помощью WORKDIR /app command
  4. Добавьте все локальные файлы, которые находятся в том же каталоге, что и этот текущий файл докеров, в каталог /app нашего контейнера Docker с помощью команды ADD . /app
  5. Добавьте ресурсы NLTK в /app/nltk_data/ directory нашего Docker-контейнера с помощью команды ADD . $NLTK_DATA
  6. Установите серию RUN команд, которые устанавливают все зависимости пакета.
  7. Установите разрешение на выполнение run.sh файла с помощью команды RUN chmod +x run.sh
  8. Измените группу владельцев пользователей на model-app-user с помощью команды RUN chown -R model-app-user:model-app-user ./
  9. Задайте пользователя и порты приложения flask с помощью команд USER model-app-user и EXPOSE 5000 соответственно
  10. Выполните команды bash, чтобы запустить run.sh скрипт для запуска приложения, с помощью команды CMD [“bash”, “./run.sh”]

Полный файл докеров показан ниже.

Примечание: сценарий run.sh выглядит следующим образом:

Как только определения докеров определены, мы готовы создать образ докера с помощью команды docker build . для локальной сборки. Поскольку мы хотели бы создать контейнер Docker на Heroku, вместо этого мы будем использовать команду docker build -t registry.heroku.com/$(NAME)/web ., как указано в Makefile из последнего раздела.

Автоматическая контейнеризация / сборка на Heroku

Помните, что в части 1 мы использовали CircleCI для автоматизации процессов обучения и упаковки моделей. Здесь мы снова попытаемся автоматизировать процесс создания веб-приложений и контейнеризации с помощью CircleCI. В дополнение к содержанию, которое существует на config.yaml, мы добавим еще 2 следующие вакансии,

  1. тестировать и создавать приложение - запускать тесты для приложения Flask.
  2. build and push to Heroku master - создайте образ докера, который будет размещать и запускать веб-приложение.

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

Чтобы Heroku функционировал должным образом, мы добавим еще 3 переменные среды в CircleCI.

  • HEROKU_API_KEY
  • HEROKU_APP_NAME
  • HEROKU_EMAIL

Примечание: ключ API heroku можно получить в разделе настроек учетной записи (показано на скриншоте ниже).

Зафиксировать, отправить, посмотреть и подтвердить

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

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

Outro

Отлично, на этом мы официально завершаем нашу серию из двух частей о том, как создать полноценный проект в области науки о данных. Мы успешно завершили весь рабочий процесс от получения данных из Kaggle до развертывания обученной модели в Heroku в качестве полнофункционального веб-приложения. Спасибо, что зашли так далеко - надеюсь, вы узнали из этого опыта столько же, сколько и я. В конце концов, я настоятельно рекомендую курс Удеми Соледад Галли, PhD и Кристофера Самиуллы по развертыванию моделей машинного обучения. Я получил много вдохновения от этого курса, и я верю, что вы многому научитесь у них. Еще раз спасибо, и увидимся в следующий раз!