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

Процесс: использование жизненного цикла аналитики

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

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

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

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

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

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

Люди

Четкое определение ролей и обязанностей в процессе ModelOps позволяет различным заинтересованным сторонам эффективно сотрудничать и продуктивно работать. Так было в случае с крупным европейским банком, который смог устранить узкие места между специалистами по данным и ИТ-операциями в процессе мониторинга своей модели. Это позволило двум группам работать вместе вручную и увеличить сотрудничество за счет автоматизации. Примеры наборов навыков для каждой группы показаны на рисунке ниже. Эти наборы навыков специфичны для организации, поэтому стоит потратить время на то, чтобы получить полное представление о ситуации в вашей организации.

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

Технологии

Последний элемент головоломки ModelOps — это то, как технология облегчает процесс и людей.

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

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

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

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

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

Не единственное решение

Важно отметить, что это не единственное решение. Многие организации очень успешно внедрили подход с другими наборами технологических инструментов, включая Netflix и Spotify. Тем не менее, инженерная нагрузка, связанная с этим, должна быть понята не в последнюю очередь потому, что она будет возрастать с уровнем сложности ModelOps. Моя следующая статья расскажет больше о влиянии уровня сложности.