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

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

Чтобы модели науки о данных работали и продолжали работать, организациям требуются обширные ИТ-возможности и опыт, а также их команда по анализу данных. Эту ИТ-емкость часто называют DevOps. DevOps - это набор практик, сочетающий разработку программного обеспечения (Dev) и ИТ-операции (Ops). Иногда DevOps, применяемый к машинному обучению, называют «MLOps». Практика, в которой вы комбинируете разработку машинного обучения с операциями машинного обучения.

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

Мы говорим на разных языках

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

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

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

Мария и Джон

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

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

Джону 43 года, и он почти 10 лет работает в компании X. Ему нравится предсказуемость, а его любимые языки - C ++ и Pascal. Джон любит создавать прототипы, но только в свободное время с Raspberry Pi. Он следит за тем, чтобы операции DevOps в компании X работали без сбоев. Поскольку данные компании очень конфиденциальны, руководство решило хранить все данные локально, на локальных серверах.

Войдя в ИТ-отдел в среду утром, Мария задает Джону вопрос. Услышав ее рассказ, Джон спрашивает Марию: «Вы уверены, что модель устойчива, надежна и готова к производству?». Мария отвечает, что не знает, потому что это эксперимент. Она хочет узнать, как модель действует в более реальной обстановке. Джон говорит, что обычно ему требуется одобрение руководства, чтобы тратить ресурсы DevOps на проекты, готовые к производству и приносящие пользу компании.

Джон сочувствует Марии и говорит, что видит, что он может для нее сделать. Однако Джону нужны другие ответы. «Можете ли вы сказать мне, сколько памяти и вычислительной мощности требуется модели?» Мария говорит ему, что он будет потреблять 100 ГБ данных в неделю. Джону не нравится ответ. «Какой язык и программные пакеты вы использовали?». Мария отвечает, что использует Python, Scikit Learn, Pytorch и Jupyter Notebooks. Джон молча кивает. Мария начинает нервничать и говорит Джону: «Я посмотрела, чем могу помочь, и посмотрела в Интернете, есть ли у вас опыт работы с контейнерами Docker и Kubernetes?» Глаза Джона заглядывают.

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

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

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

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

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

· Какая последняя версия модели (контроль версий)?

· На каком конкретном наборе данных была обучена эта модель (метаданные)?

· Каковы были конкретные результаты этой модели (показатели и ведение журнала)?

· Работает ли он лучше, чем предыдущий (A / B-тестирование)?

· Можем ли мы легко отслеживать и сравнивать производительность наших моделей (мониторинг производительности)?

· Если он работает недостаточно хорошо, можем ли мы легко вернуться к предыдущему (откаты)?

· Кто отвечает за последнюю версию модели и кто имеет право вносить изменения в производственный процесс (Пользователи и разрешения)?

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

Как с этим бороться?

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

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

Хотите быть в курсе схожих тем? Следите за нашим блогом на Medium или сайте.