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

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

Самая большая проблема сегодня - это «не переводить науку о данных в готовый код». Хотя многие могут предложить контейнеризацию, микросервисы или флейту, это решение не работает для большинства случаев использования, особенно когда модели и поддерживающий конвейер должны реагировать со сверхнизкой задержкой или должны быть легко развернуты с бизнес-процессами / периферийными устройствами. Более того, разработка и развертывание моделей во многих случаях имеют отдельный путь кода, согласованный с тем, как он интегрируется с технологическим ландшафтом поддержки бизнес-процессов (модель разработана на Python / Spark и должна быть развернута на Java / Swift).

Data Science не всегда напрямую влияет на производство

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

  • Начните с более простых моделей и постепенно переходите к более сложной модели по мере необходимости. Баланс между производительностью модели, скоростью, объяснимостью и простотой развертывания. Не спешите сразу переходить к модным словам или модным алгоритмам
  • Разработайте простую модель конвейера и избегайте создания трубопроводных джунглей
  • Если ваша группа специалистов по анализу данных не является инженерами по программному обеспечению, привлеките группу инженеров в начале бизнеса, чтобы помочь с пониманием и моделированием. Процесс развертывания для оценки одного миллиона транзакций в день полностью отличается от того, который оценивает в 1000 транзакций.
  • Используйте сначала подход к сериализации собственной модели, а не переписывайте выходные данные модели на целевом языке, если в этом нет необходимости для бизнеса. Пример: начните с платформы моделирования (sci-kit, Apache Spark, Tensorflow и т. Д.) С функцией оценки, если необходимо преобразовать ее на целевой язык с использованием подхода PMML / PFA, и в крайнем случае рассмотрите возможность переписывания выходных данных модели (например, преобразование выходных данных модели на основе дерева в специфичный для языка оператор if / else)
  • Следуйте передовой практике соответствующего инструмента моделирования, чтобы сериализовать весь рабочий процесс модели (предварительная обработка, разработка функций и т. Д.), А не только алгоритм модели. Если вы используете Sci-kit или Apache Spark, используйте встроенную функцию конвейера для объединения трансформаторов; при моделировании на Tensorflow попробуйте использовать встроенный feature_columns и модуль данных, а не пользовательские python.

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

Эта статья изначально была размещена в моем linkedin .. https://www.linkedin.com/pulse/ml-model-deployment-considerations-srivatsan-srinivasan/