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

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

Задача состояла в том, чтобы упростить использование CoDAI в качестве (очень мощной) локальной среды, чтобы поддерживать быстрые итерации разработки при создании MVP. Работа была двоякой:

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

Эта статья призвана стать первым описанием нашей платформы, рабочего процесса и набора инструментов, которые мы создали на ее основе. Должен добавить, что нас вдохновили люди, оказавшиеся в подобных ситуациях, как эта статья из TotalEnergies или эта из Intermarché и, конечно же, дизайн Microsoft. Я также большой поклонник Кедро, который все это время оказывал сильное влияние.

Что такое CoDAI

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

По сути, CoDAI позволяет пользователям запускать проект с портала с помощью простой формы запроса. Затем это запустит конвейер DevOps, который подготовит набор компонентов Azure (через шаблоны ARM), установит разрешения на доступ для указанной пользователем команды и разрешения между компонентами. Затем этот проект отображается на начальном портале. Затем пользователи могут управлять правами (добавление или удаление членов команды и т. д.), доступом или предоставлением компонентов (например, запускать новую виртуальную машину) с портала.

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

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

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

  • Внедрение общего рабочего процесса разработки, целью которого является сокращение разрыва с производством и, как следствие, сокращение времени вывода на рынок новых продуктов,
  • Единообразие в практике и, следовательно, более легкое сотрудничество, рецензирование и передача;
  • Распределение наших ресурсов в качестве поперечной команды по обработке данных для поддержки наблюдаемых проблемных мест в проектах и ​​для объективного увеличения производительности проекта, поскольку CoDAI значительно повышает наблюдаемость,
  • Использование сетевых эффектов за счет использования уже существующих продуктовдля запуска новых, даже если задействованные команды не контактируют друг с другом, или за счет ограничения избыточности в проектах.

Рабочий процесс машинного обучения и связанные компоненты

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

Давайте начнем с того, что необходимо с типичной точки зрения Data Scientist:

  • Данные: должен быть способ хранения, доступа и записи данных,
  • Обучение моделей. Должен быть способ обучать модели, передавая им наши данные о произвольных вычислительных кластерах (независимо от параллелизма, с которым может справиться пользователь, или от конкретного оборудования, которое он может использовать, например графических процессоров). и произвольные зависимости (из мира с открытым исходным кодом или внутренностей),
  • Предоставление моделей. Должен быть способ предоставить обученные модели внешнему миру максимально модульным способом (действительно, даже если модель пользователя в настоящее время используется одним приложением, мы хотим, чтобы потенциальные другие пользователи чтобы иметь возможность подписаться на него позже), что приводит к так называемой «микросервисной» архитектуре,
  • Демонстрация. Наконец, должна быть возможность продемонстрировать получившийся MVP с помощью базового веб-приложения, которое будет использовать одну или несколько моделей.

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

  • В качестве хранилища мы используем Azure Blob Storage или Denodo для виртуализации данных внутренних систем.
  • Для обучения модели и логического вывода мы используем Машинное обучение Azure (отныне AML), которое, даже если это не самый зрелый продукт из предложений Azure, позволяет легко подключаться к другим компонентам нашей экосистемы и обеспечивает необходимую абстракцию инфраструктуры. каркас, который нам нужен,
  • Для обслуживания веб-приложений мы полагаемся на веб-службы Azure и настаиваем на использовании очень легких платформ, таких как streamlit (обратите внимание, что цель этих приложений — продемонстрировать ценность, чтобы не справляться с какой-либо тяжелой нагрузкой или причудливыми фасадами).

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

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

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

  1. Интерактивное исследование данных: это начальный шаг любого проекта, просто поиграйте со своей проблемой на виртуальной машине, получая данные из хранилища BLOB-объектов. Здесь вы можете использовать свой любимый «живой» инструмент (блокноты, скрипты, RStudio, ipython repl, …),
  2. Контейнерное выполнение: как только ваше интерактивное исследование будет завершено, что приведет, например, к некоторой процедуре обучения и оценки, вы должны иметь возможность выполнять эти вычисления в контейнере. Это гарантирует, что вы сможете описать среду выполнения воспроизводимым образом. Для этого мы используем эксперименты AML для выполнения ваших вычислений как одного монолитного скрипта в каком-то вычислительном кластере без сохранения состояния.
  3. Рефакторинг: как только вы сможете контейнеризовать свои вычисления, вам необходимо провести рефакторинг кода, чтобы сохранить возможность легко вносить изменения в будущем. У нас есть два основных способа разделить монолитные вычисления последнего шага: полагаться на внутренний модуль или использовать конвейеры AML. В каждый проект CoDAI встраивается модуль в виде отдельного артефакта, куда вы можете переместить свою логику и протестировать ее. На этом этапе можно использовать конвейеры AML, чтобы выделить уровень предварительной обработки данных и объединить его с будущими экспериментами.
  4. Оценка качества: теперь у вас есть полностью автоматизированный и достаточно надежный способ создания модели и оценки ее качества путем вычисления на ее основе различных статистических данных. Вы можете предоставить эти дескрипторы качества через AML, но вам все равно нужно определить процесс для оценки глобального качества вашей модели на основе этих цифр: вам нужно иметь возможность формально сравнивать две модели-кандидаты. Несмотря на то, что я вижу много архитектурных схем, которые, кажется, подразумевают, что это легко и может быть простым сравнением между двумя действительными числами (чтобы ваш CI / CD теперь мог обрабатывать ваш поток AML), по моему опыту это редко имеет место. и процесс оценки должен разрабатываться на индивидуальной основе. Именно на основе этой оценки вы решите, нужно ли вам все еще улучшать свою модель или вы хотите перейти к развертыванию,
  5. Развертывание: как только будет создана достаточно хорошая модель, мы хотим развернуть ее как REST API, и это можно значительно упростить с помощью AML и дешевого решения, такого как развертывание Azure Container Instances. Опять же, вам нужно сосредоточиться только на одном скрипте оценки, который определяет оценку вашей модели. И вы можете добавить простой интерфейс, написав быстрое потоковое приложение. В некоторых случаях вы также можете определить конвейеры AML для запланированных заданий. CoDAI охватывает все эти основные варианты использования с помощью набора компонентов Azure.

После завершения этого процесса у вас остается набор артефактов Azure и процесс оценки качества (более или менее автоматизированный в зависимости от проблемы). Чтобы перенести решение в рабочую среду, вам просто нужно перестроить эти артефакты в новые среды и, возможно, изменить целевое оборудование и платформы развертывания (например, перейти с Azure Container Instances на Azure Kubernetes). Затем вам все равно придется обсудить процесс оценки качества с будущими сопровождающими, конечно.

Последняя проблема заключается в том, как сделать этот процесс максимально простым и эффективным для конечного пользователя?

Стратегии по укрощению сложности

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

Мы создаем экземпляры репозиториев проекта

При запуске проекта на CoDAI запускается конвейер создания, который будет создавать и настраивать различные компоненты, прикрепленные к проекту. Среди них, конечно же, репозиторий git, размещенный на DevOps, первоначально заполненный из шаблона, выбранного создателем проекта (по сути, чтобы указать, какой язык будет основным для его проекта, R или Python). Этот первоначальный шаблон одновременно удобен для конечного пользователя (меньше шаблонов для написания) и является благословением с нашей точки зрения, поскольку он позволяет нам установить типичную структуру проекта.

Это позволяет нам написать для пользователя базовый шаблон вокруг внутреннего модуля их проекта, им не нужно напрямую манипулировать `setup.py` своего модуля или изменять любой элемент конфигурации, кроме списка требований.txt.

В том же духе он заполняет множество элементов конфигурации, таких как учетные данные (по крайней мере, безопасные), конфигурация linter, файлы Docker для развертывания базовых веб-фреймворков и т. д.

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

Мы создаем экземпляр CI/CD

Каждый проект, как только он будет создан, будет наследовать базовый конвейер CI/CD (фактически один по языку, то есть — по крайней мере — один для R и один для Python на сегодняшний день). Этот CI/CD будет:

  • Внедряйте тщательный механизм проверки при каждом запросе на включение, используя набор стандартных инструментов, которые будут выполнять проверку формата (черный/изосорт), статический анализ типов (mypy), линтинг и модульное тестирование,
  • Сборка всех артефактов из исходного кода пользователя, кроме AML, сборка например docker-образов для запуска веб-приложения, колеса внутреннего модуля, html-документации проекта,…
  • Выпускайте все созданные артефакты в их целевой компонент Azure, перемещайте колесо в фид Azure DevOps, контейнеры веб-приложений в Реестр контейнеров Azure, развертывайте документацию в виде статического веб-сайта…

Опять же, этот CI/CD является предложением, которое может быть изменено опытным пользователем в определенных обстоятельствах. Еще одна вещь, на которую следует обратить внимание, это то, что мы исключаем артефакты AML при проектировании из CI/CD, главным образом потому, что эти средства автоматизации должны обсуждаться в каждом конкретном случае в зависимости от сложности процесса оценки качества модели.

Мы распространяем внутренние библиотеки

Мы используем Azure DevOps для распространения внутренних библиотек во все проекты на CoDAI. Используя их, мы можем смягчить многие углы. По сути, мы распространяем интерфейс командной строки (CLI) и абстракции вокруг компонентов AML. Мы также находимся в процессе создания универсальных библиотек на основе подходов машинного обучения, которые оказались полезными в наших задачах (которые будут обсуждаться в другом посте). Мы написали их на python, чтобы их мог легко модифицировать любой специалист по данным, и вся тяжелая работа по AML, конечно же, опирается на SDK AML python.

Помогаем пользователям пройти CI/CD

Мы думаем, что просто определить CI/CD недостаточно для реализации нашей главной цели, стоящей за этим механизмом: единообразие кода в проектах и ​​скорейшее обнаружение ошибок. В самом деле, если мы просто определим процесс проверки, не помогая пользователю, это только вызовет разочарование и приведет к тому, что часть CI/CD будет пропущена. Вот почему наш CLI здесь, чтобы помочь пользователю.

Например, поскольку мы хотим унифицировать формат кода, мы предоставляем команду `codai format`, которая запускает инструменты автоматического форматирования для пользователя. Или, если они хотят быть уверены, что их код пройдет CI/CD, не дожидаясь Azure DevOps, им просто нужно запустить `codai check`. Если они просто хотят запустить свой набор тестов, им просто нужно запустить `codai test`…

Шаблоны для динамической генерации кода

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

Поэкспериментировав с несколькими решениями, мы теперь используем cookiecutter через наш интерфейс командной строки, чтобы динамически предоставлять пользователям отправную точку для эксперимента или конвейерного кода с помощью простого codai new.

Триггеры

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

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

Абстракции AML

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

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

Заключение

Это было очень краткое введение в CoDAI, его цели и методы, которые мы используем для обеспечения лучшего взаимодействия с пользователем.

Было очень приятно создать в SUEZ такую ​​ориентированную на взаимодействие с пользователем структуру, и, в конце концов, это было почти неожиданностью, что можно, возможно, вопреки интуиции, поддерживать быстрые итерации во время разработки MVP при создании легкого для индустриализации программного обеспечения: вам нужно полагаться на доверенные ИТ-компоненты, обеспечивать с помощью общего рабочего процесса разработки управление средой выполнения во время разработки, полагаться на такой компонент, как AML, для обеспечения абстракции инфраструктуры и создайте инструменты, чтобы ускорить работу ваших пользователей в этом контексте, объективно определяя болевые точки в проектах.

Я хотел бы поблагодарить всех, кто сделал этот опыт возможным: Чафику Шеттауи, Жиля Фаи, Николя Корне, Сиру Ферраданс, Гийома Кюссонно (команда SUEZ Data Science), Николя Давио (один из инициаторов проекта), Седрика Нуро, Guillaume Pennequin и Reda Azzaoui (от нашего партнера Avanade), Vasilica Chiriac и Andrea Garcia Elescano из Microsoft за их вклад и поддержку этого замечательного проекта.