Если вы пропустили другие посты из этой серии, посмотрите их:

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

Но у нас пока нет полезного продукта. Точнее, у нас его не было до сих пор.

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

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

Внимание: в этом посте мы будем использовать концепцию создания классов в Python; если он вам незнаком, мы предлагаем изучить объектно-ориентированный Python. В Интернете доступно множество бесплатных материалов, в том числе видео на YouTube.

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

API может быть общедоступным в URL-адресе в Интернете (где вы обычно управляете безопасностью с помощью ключа доступа) или в локальном порту во внутренней сети.

Благодаря своей универсальности и безопасности API — отличный инструмент для развертывания ваших моделей. Для этого мы будем использовать Kedro вместе с новым инструментом: Kedro Fast API, расширением, созданным нашей командой в Indicium.

кедро-быстро-апи

Это верно! Мы разработали плагин для создания API с использованием Fast API, чтобы сделать возможным создание с помощью нескольких дополнительных файлов конфигурации и воспользоваться всеми преимуществами, которые мы увидели в Kedro, чтобы структурировать весь этот процесс, чтобы сохранить его >организованный, устойчивый и масштабируемый.

Indicium создала расширение Kedro для создания API, и мы представим здесь этот новый подход и то, как создать ваш первый готовый к работе API. Репозиторий проекта можно найти по этой ссылке.

Далее мы покажем вам эту структуру более подробно.

Монтаж

Установку пакета можно выполнить с помощью следующей команды в терминале в той же папке, что и проект Kedro:

$ pip install kedro-fast-api

Эта установка будет подтверждена командой kedro info, и эта команда вернет в том числе kedro-fast-api:

Инициализация

После установки вам необходимо запустить плагин с помощью команды:

$ кедро fast-api init

Эта инициализация создаст файлы плагинов по умолчанию, а именно:

  • conf/api.yml
  • conf/base/api_pipeline/catalog.yml
  • src/api_pipeline/nodes.py
  • src/api_pipeline/catalog.py

Файлы nodes.py и pipeline.py будут созданы в новом конвейере Kedro под названием api_pipeline, который отвечать за сохранение предиктора (об этом мы поговорим позже).

В центре процесса находится предиктор конвейера, который представляет собой объект, фактически делающий предсказания модели.

Предсказатель

Короче говоря, предиктор — это инкапсуляция модели , которую можно хранить в памяти (используя >каталог kedroи сохранение в формате pickle) для использования с любыми входными данными в любой среде. Это подготовит модель к отправке в любую точку галактики.

Для этой цели файл узла создает класс, называемый predictor, который имеет метод predict.

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

Таким образом, предиктор (здесь он называется MLPredictor) позволяет сделать прогноз с помощью следующей команды Python:

MLPredictor.predict(inputs)

Здесь входные данные — это входные данные для модели машинного обучения, а выходные данные — результаты прогнозов, которые будут возвращены в виде >Словарь Python, т. е. в основном это ответ от API в формате JSON.

Как мы упоминали ранее, узел Kedro выполнит только одну команду для создания экземпляра класса (создаст объект с моделью внутри него) и сохранит предиктор в памяти, заставив всю структуру работать идеально.

Для ясности взгляните на структуру файла nodes.py:

import pandas as pd
class MLPredictor:
  def __init__(self, model):
    self.model = model
    def predict(self, args_API: pd.DataFrame):
      df_args = args_API
      prediction = self.model.predict(df_args) 
      return {“prediction”: prediction}
def save_predictor(model):
  predictor = MLPredictor(model)
  return predictor

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

Поэтому при сохранении модель будет внутри предиктора через объект self.model. И файл pipe.py будет таким:

from kedro.pipeline import Pipeline, node
from .nodes import save_predictor
def create_pipeline(**kwargs):
return Pipeline(
  [
    node(
    func=save_predictor,
    name=”save_predictor”,
    inputs=”model”, ### Replace with model’s name
    outputs=”MLPredictor”,
    )
  ]
  )

В этом случае входными данными является модель «модель», имя которой должно быть обновлено именем самой модели, используемой в проекте. Вы также можете видеть, что входы узла kedro не являются входами самой модели. Записи узла kedro — это файлы, необходимые для создания файла, способного делать прогнозы (параметры класса), а записи модели — это записи метода прогнозирования (параметры метода).

Предиктор по умолчанию не выполняет никаких операций с данными. Pandas DataFrame, полученный API (через словарь данных), передается непосредственно в метод прогнозирования. Однако нет никаких ограничений на включение, например, промежуточных шагов для разработки функций. Метод predict может изменить DataFrame, чтобы сделать его наиболее подходящим для правильного прогнозирования.

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

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

Файлы конфигурации

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

MLPredictor:
  type: pickle.PickleDataSet
  filepath: data/09_predictor/MLPredictor.pickle
  versioned: true

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

Кроме того, у нас есть файл api.yml, в котором содержится информация, необходимая для создания фактического API. Его файл по умолчанию имеет следующую структуру:

routes:
  model_API:
  # Catalog reference to .pickle model
  predictor: MLPredictor
  # Inputs passed as a python dictionary
  # allowed types int, float, str, bool and enum
  parameters:
    input_1:
    # enum type requires options (numbers as options won’t work)
      type: enum
      options:
        - some
        - options
        - here
      input_2:
        type: int
      input_3:
        type: float
      input_4:
        type: bool
      input_5:
        type: str

Давайте рассмотрим это шаг за шагом. Структура аналогична хорошо известному YAML. Файл начинается с информации о маршрутах: каждый маршрут — это отдельный API, а имя маршрута — это имя, которое появляется в URL-адресе сразу после адреса (например: localhost:8000/). model_API).

В этом примере настроен маршрут model_API. Он определяет следующие свойства:

  • predictor: имя предиктора, сохраненное в каталоге.
  • параметры: параметры представляют собой записи API, и вы должны указать их имя и тип данных, но вы также можете заранее определить допустимые значения.

Вот и все! После установки этих свойств API готов к созданию.

Создание API

Команда для создания API:

$ kedro fast-api run

Да! Вот и все.

Если все правильно, API будет создан из файла конфигурации в папке conf/api.yml.

Если вам нужно указать другой файл, используйте команду:

$ kedro fast-api run -p path_to_file/API_file_name.yml

Теперь API будет доступен для доступа и создания первых прогнозов. Доступ можно сделать по следующему URL:

localhost:8000/model_API/

Использование API

kedro-fast-api создает интерфейс для выполнения запросов вручную, где каждое из полей, подробно описанных в api.yml, отображается с соответствующими форматами и принятыми значениями. Таким образом, вы можете вручную заполнить поля в интерфейсе и сгенерировать запрос.

Вы также можете создать описание и добавить дополнительные сведения в свой API. Найденная страница будет выглядеть так:

Нажав «GET» в разделе «users», а затем «Try it out», вы можете заполнить поля и получить ответ от шаблона. Если все пойдет хорошо, ваши результаты появятся прямо ниже, а также ссылка, по которой вы сможете сделать это автоматически (например, с помощью запросов Python). Таким образом, используя ссылку по умолчанию, вы можете автоматизировать запись URL-адреса и процесс в других средах, которые имеют доступ к адресу, где находится API.

Примером результата использования проекта Pokémon (упомянутого в других постах этой серии) является предсказание типа покемона по его характеристикам.

Теперь, когда API готов, вы можете передать его команде разработчиков вашей команды, чтобы его можно было развернуть.

Лучшие практики

Задокументируйте свой код:

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

Пишите читаемый код:

  • Обратите внимание на имена переменных; включать указание того, что представляет собой каждая переменная, вместо использования таких имен, как «x» или классического «df», которые затрудняют чтение кода, используйте « клиенты» или «заказы»;
  • По возможности будьте линейны, избегайте случайного порядка функций в теле кода;
  • Используйте отдельные функции для выполнения сложных шагов в коде, чтобы облегчить чтение. Совет: если функция имеет более одного логического уровня, разбейте ее на более мелкие функции;

Никогда не повторяйте код:

  • Если вам нужно скопировать и вставить фрагмент кода, это должна быть функция, вызываемая дважды;
  • Используйте имена функций, которые уже дают вам представление о том, что происходит в функции, например: clean_data_frame(data_frame)

Попробуйте предсказать ошибки:

  • Если вы знаете, что ваша модель сломается, если столбец будет отправлен со значением, отличным от тех, которые использовались при обучении модели, включите тест в свой предиктор, который возвращает определенные словари ошибок. Например:
if error:
  return {‘error’: ‘error description’}

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

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

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

Хотите узнать больше о машинном обучении, науке о данных, аналитике и многом другом?

Подпишитесь на нашу новостную рассылку, чтобы получать весь наш контент из первых рук.