Уровни зрелости ML-процессов (процессов, связанных с машинным обучением)

Машинное обучение выходит из зоны хайпа. И сложно однозначно сказать, насколько это хорошо или плохо, но что совершенно точно видно – всё больше людей задаются вопросом: «А деньги где?». Всё меньше футуристических статей про тотальную победу машины над человеком, всё больше докладов и обсуждений посвящается автоматизации и систематизации процессов работы над ML-проектами. Эта статья не будет исключением – хайп закончился, работать надо.

Уверен, что упражнение по оценке уровня зрелости мало кого обойдет стороной (как минимум тех, кто ML планирует использовать в промышленном варианте, а не чисто «чтоб было»). У нас в Банке «Санкт-Петербург» этот вопрос первый раз был поднят ещё в рамках предпроекта по строительству нового хранилища данных и платформы машинного обучения. И это совершенно логичное желание, ведь, если перед глазами есть понятная оценочная шкала, всегда можно понять, где мы находимся, и иногда даже можно сравнить показатели с лидерами рынка, а также понять, что тебя ждет впереди. И как следствие – можно определиться с приоритетами, бюджетами и планированием, чтобы заняться налаживанием нужного здесь и сейчас, а не перепрыгивать через пару уровней и устраивать революцию, изобретая велосипед в придачу — ведь он может потом и не пригодиться. В общем, полезное со всех точек зрения упражнение.

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

Как сертифицированный по CoBIT человек, я решил начать с адаптации – взял уровни зрелости из ITIL (что по сути есть ИТ-вариант CMMI, ISO/IEC 33001 и т.п.) и попробовал переложить их на ML. Вот честное слово – я несколько раз пробовал проделать это упражнение на практике, но всегда получался какой-то сферический конь в вакууме, который может и давал обобщенный ответ на вопрос as-is, и даже где-то можно было понять to-be, но вот нарисовать понятный путь с конкретными шагами и понятными точками контроля получалось с трудом. Поэтому, посмотрев по сторонам, я решил вспомнить и систематизировать свой нелегкий путь в работе над различными ML-проектами, оценить лучшие практики, используемые в зрелых компаниях, благо за последнее время появилось много интересного на эту тему. В итоге получилось более приземленное описание некоторых базовых ступеней развития работы над ML-проектами. Можно ли их назвать «уровнями зрелости» или нет – вопрос второй, но на поставленные выше вопросы они отвечают, и это самое главное.

Итак, уровни, которые у меня получились:

· Уровень 0. «Отсутствующий»

· Уровень 1. «Энтузиасты»

· Уровень 2. «НИОКР»

· Уровень 3. «Анализируй это»

· Уровень 4. «Специалитет»

· Уровень 5. «Автоматизируй это»

Единственный уровень, в котором я не придумал ничего нового и взял его из ITIL. Как говорится, если процесса нет, то его нет в любом виде, будь это про IT или про ML.

Самый творческий и где-то даже романтический (с точки зрения дата-сайентиста) уровень. В самом начале, когда перед тобой лежит нетронутая целина задач (и чаще всего они выполняются руками), открыты все дороги, и есть руководство, которое даёт спокойно работать, поскольку магия непонятных слов «Big Data» еще работает. Это когда у тебя есть верный Python (или R, или Matlab… да в общем какая разница) и желание победить все-все-все проблемы, и иногда даже что-то получается. Сплошная романтика и энтузиазм.

Хотя, если быть честным, это не всегда так – для некоторых областей работы (и банки в них входят), внедрение ML приходит с рынка. Тот же скоринг клиентов как классическая задача – стандартный тому пример. Но если ничего нет, то и скоринг зачастую начинается с ноутбука (в широком смысле этого слова) и работы «на коленке».

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

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

1. Систематизации постановки задач – может, еще нет полноценных таск-трекера, бэклога и т.п., но как минимум уже есть процесс приоритизации задач.

2. Разделения обязанностей – появляются как минимум выделенные роли специалистов по работе с данными. Всё-таки это 80% времени, да и доля успеха примерно такая же.

3. Первых регламентов применения результатов ML-моделей. Обращаю внимание — не регламенты применения моделей, а применения результатов моделей. Это принципиальная разница.

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

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

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

· И конечно же, надо контролировать экономический эффект от модели. Ведь когда хайп ушел, отчетливо ясно — если это не про деньги, то зачем оно всё?

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

· оборудования – модели уже требуют отдельной PROD-зоны и полноценного разделения DEV/TEST/PROD,

· процедур и регламентов вывода в прод, переобучения и т.п. – этот путь должен быть понятен, описан и стандартизирован,

· людей и их зон ответственности – кто-то создает новое, кто-то выводит в пром и поддерживает работающее, нужен баланс и специализация между Run the business/Change the business.

Это не более чем дальнейшее движение по выбранному пути и автоматизация работы тех людей, которые появились на 4-м уровне. Это про выстраивание полноценной практики DataOps&MLops для автоматизации и систематизации процессов разработки и вывода моделей в прод, организации DVC и Feature Store для максимально эффективной работы с данными и их быстрого реиспользования. Ну и, конечно же, постоянный и системный мониторинг всех моделей в проде со всех точек зрения.

Если свести всё к нескольким показателям, то описания уровней уложатся в следующую таблицу.

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

Также отмечу, что далеко не всегда получается выстраивать работу ровно по этим уровням (и практика нашего Банка это подтверждает). И в общем это нормально, когда какие-то части уходят вперед, а что-то догоняет. Но опять же из опыта – если у вас разрыв между разными показателями составляет больше одного уровня, то вам надо серьезно задуматься и поработать над «отстающей» сферой. В противном случае эффективность использования «выдающегося» показателя будет явно ниже среднего.

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

· Где та точка, когда имеет смысл остановится с внедрением ML? Где баланс между затратами и доходами?

· Как распределить ресурсы между поддержкой существующих моделей и разработкой новых?

· Надо ли вкладываться в инфраструктуру, когда у меня всего пара моделей и этого более чем достаточно для повышения эффективности работы предприятия?

И многие другие вопросы, ведь в бизнес-применении ML, как и везде, – переход от одного уровня зрелости к другому стоит на порядок дороже, а будет ли отдача отличаться на порядок — большой вопрос.

И еще один момент — я намеренно нигде (ну кроме первого уровня, и то больше в шутку) не делал акцентов на используемом ПО. Мой личный опыт подсказывает, что не так важно, где вы работаете над ML-проектами: в Python, R, Azure ML Studio, SPSS или SAS, базовые уровни вашей зрелости от этого не изменятся ни на йоту. И по мере движения от 1-го уровня до 5-го вам в любом случае придется обрастать теми или иными дополнительными компонентами, программными и аппаратными комплексами. И каждый для себя принимает решение – идти к вендору, делать на свободном ПО или совмещать эти подходы в разных долях. Хотя очевидно, что вендорское решение стоит своих денег зачастую не за счет качественного ПО (хотя не без этого), а больше за готовые шаблоны выстроенных процессов, за проработанную интеграцию компонент, которые с минимальными затратами можно натянуть на себя и получить готовый рабочий процесс.

Но по этому поводу есть более конкретная история внедрения той самой ML-ной платформы в нашем Банке (с которой идея по уровням зрелости и начиналась), когда мы перешагивали со 2-го уровня на 4-й в плане аппаратного обеспечения. Там будет и про железо, и увлекательная история хождения по граблям с бесплатным ПО и, конечно же, happy end про то, как у нас классно всё в конечном итоге заработало, в общем, всё как полагается по законам жанра. Это точно тема для отдельной статьи, а, учитывая текущий фокус Банка «Санкт-Петербург» на цифровизацию в общем и на data-driven подход в частности, уверен, что по теме аналитики, ML и максимально полного использования данных для принятия решений нам будет что рассказать в ближайшее время.

#machinelearning #ml #bigdata #datascience #python #deeplearning