Машинное обучение выходит из зоны хайпа. И сложно однозначно сказать насколько это хорошо или плохо, но что совершенно точно видно - все больше людей задаются вопросами «а деньги где?», все меньше футуристических статей про тотальную победу машины над человеком, все больше докладов и обсуждений посвящается автоматизации и систематизации процессов работы над ML-проектами. И эта статья не будет исключением – хайп закончился, работать надо.
Если говорить про выстраивание каких-либо процессов, то лично я очень люблю оперировать термином «уровень зрелости». Ведь если перед глазами есть понятная оценочная шкала, всегда можно понять где ты находишься, что тебя ждет впереди, можно определиться с приоритетами и заняться налаживанием того что нужно здесь и сейчас, а не перепрыгивать через пару уровней и устраивать революцию, изобретая велосипед в придачу… а он ведь может потом и не пригодиться. В общем полезное со всех точек зрения упражнение.
Чисто теоретически можно взять стандартные уровни зрелости процессов, описанные в CMMI, ISO/IEC 33001 или их более ИТ-приземленное описание из ITIL и переложить их на ML. Я несколько раз пробовал проделать это упражнение на практике, но получался какой-то сферический конь в вакууме, который может и давал ответ на вопрос as-is и to-be, но вот нарисовать понятный путь получалось с трудом. Поэтому посмотрев по сторонам я решил вспомнить и систематизировать свой нелегкий путь в работе над различными ML-проектами, ведь CММI это хорошо, но для реальной работы нужно что-то более конкретное и приземленное. В общем в результате родилось описание некоторых базовых ступеней развития работы над ML проектами. Можно ли их назвать «уровнями зрелости» или нет – вопрос второй, но на поставленные выше вопросы отвечает и это самое главное.
Итак, приступим к конкретике. Наверное, единственный уровень в котором я не придумал ничего нового и взял его из ITIL — это уровень «0» или «отсутствующий». Как говориться если процесса нет, то его нет в любом виде будь то про IT или про ML. Ну а если серьезно, то мои 5 уровней/ступенек следующие:
Уровень 1. «Энтузиасты»
Уровень 2. «НИОКР»
Уровень 3. «Анализируй это»
Уровень 4. «Специалитет»
Уровень 5 «Автоматизируй это»
Уровень 1 «Энтузиасты»
Это самый творческий и где-то даже романтический (с точки зрения дата сайнтиста) уровень. Это самое начало, когда перед тобой лежит нетронутая целина задач (и всего они выполняются руками), открыты все дороги куда пойти, и есть руководство, которое дает спокойно работать, поскольку магия непонятных слов «Big Data» еще работает. Это когда у тебя есть верный Python (или R или Matlab … да в общем какая разница) и желание победить все-все-все проблемы и иногда даже что-то получается. В общем сплошная романтика и энтузиазм.
Но кроме шуток — это та самая отправная точка, откуда стартовали очень и очень многие. Благо доступность инструментария, данных и вычислительных ресурсов творит чудеса.
Уровень 2 «НИОКР»
Спустя какое-то время чистый энтузиазм понемногу заканчивается и приходит понимание, что борьба за идею это хорошо, но если нужен повторяемый и регулярный результат, то надо подходить к вопросу более системно. И начинается процесс первичной систематизации, который на этом уровне состоит как минимум из:
Систематизации постановки задач – может еще нет полноценной таск-трекера, бэклога и т.п., но как минимум уже есть процесс приоритезации задач.
Разделения обязанностей – появляются как минимум выделенные роли специалистов по работе с данными. Все-таки это 80% времени, да и доли успеха примерно столько же.
Появляются первые регламенты применения результатов ML моделей. Обращаю внимание — не регламенты применения моделей, а применения результатов моделей. Это принципиальная разница.
Уровень 3 «Анализируй это»
Когда первые модели не просто обучены и протестированы, а уже появляется регулярность их запуска и может даже написан регламент применения результатов, то приходит понимание, что все это счастье надо контролировать и анализировать на постоянной основе. Причем со всех сторон:
Надо оценивать данные на входе. И оценивать их как с точки зрения качества данных (пустые поля, ошибочные переменные), так и оценивать распределение величин. Ведь если данные на предикте будут иметь распределение отличное от обучения, то релевантность нашего прогноза под вопросом и имеет смысл задуматься о переобучении модели.
Контролировать точность модели, т.е. иметь процесс сравнения прогноза на выходе с пост-фактом. Да тут могут быть сложности для моделей с длинным горизонтом прогнозирования, с влиянием прогноза на факт и все такое прочее. Но эта проблематика известна и пути решения тоже понятны. Было бы понимание, что это необходимо.
И конечно же надо контролировать экономический эффект от модели. Ведь когда хайп ушел, то приходит понимание — если это не про деньги, то зачем оно все?
Уровень 4. «Специалитет»
По мере вывода все большего количества моделей в работу, если все делается по правилам (как минимум с мониторингом, регламентами использования и т.п.), то в какой-то момент времени модели становятся бизнес критической частью рабочего процесса с понятным экономическим выхлопом и стоимостью одного дня простоя. И в этот момент приходит понимание, что нужна дальнейшая специализация как минимум в части:
Оборудования - модели уже требуют отдельной PROD-зоны и полноценного разделения DEV/TEST/PROD
Процедур и регламентов вывода в прод, переобучения и т.п. – этот путь должен быть понятен, описан и стандартизирован.
Людей и их зон ответственности – кто-то создает новое, кто-то выводит в пром и поддерживает работающее. В общем нужен баланс и специализация между Run the business/Change the business.
Уровень 5 «Автоматизируй это»
Это не более чем дальнейшее движение по выбранному пути и автоматизация работы тех людей, которые появились на 4-м уровне. Это про выстраивание полноценной практики DataOps&MLops для автоматизации и систематизации процессов разработки и вывода моделей в прод. Организации DVC и Feature Store для максимально эффективной работы с данными и их быстрого реиспользования. Ну и конечно же постоянный и системный мониторинг всех моделей в проде со всех точек зрения.
Если обобщать эти уровни, то можно свести их описание в таблицу:
Уровень 1 | Уровень 2 | Уровень 3 | Уровень 4 | Уровень 5 | |
Описание процессов | Процессы непредсказуемые. Контроль слабый. Повторяемость результата другим специалистом сильно ограничена | Процессы определяются на этапе работы над конкретной задачей. Контроль только результата Результат может быть повторен с некоторой погрешностью | Основные процессы определены Точки контроля присутствуют Результат может быть повторен с высокой степенью точности | Процессы определены. Четко сформированы ответственные за этапы процесса Полный контроль над работой Результат повторяется с высокой степенью точности | Фокус на автоматизации и постоянной оптимизации процессов Результат повторяется на 100% |
Аппаратное обеспечение | Обычный рабочий PC/ноутбук (может +GPU) | PC или сервер (облачный или on-prem) | Выделенные сервера для ML-задач и БД для данных. | Выделенные сервера Разделение на PROD и DEV/TEST зоны. Резервирование ключевых компонент. | Выделенные сервера с разделением на PROD и DEV/TEST зоны. Обеспечена отказоустойчивость ключевых компонент. |
Размер команды и основные роли | 1-2 специалиста (Data Scientists - DS) | 3-5 специалиста:2-3 DS 1-2 DE (Data Engineers) | 5-10 специалистов: 3-6 DS 2-4 DE | 10+ специалистов. Вводится дополнительная роль «ML-ops». Распределение зависит от специфики предприятия | 25+ Распределение зависит от специфики предприятия |
Кол-во моделей | 1-2 модели | 2-4 модели | 5+ моделей | 10+ | 50+ |
Цифры взяты из личного опыта и не являются догмой (хотя бы потому, что модели бывают разные). Но в любом случае очевидно, что с ростом количества решаемых задач и повышению их критичности, все больше времени и ресурсов надо выделять на инфраструктуру в широком смысле этого слова. С другой стороны, если у вас десяток моделей в проде и вы хотите продолжать, то скорее всего они приносят достаточно чтобы окупить и инфраструктуру и ресурсы и дальнейшие проекты в этой области.
И как я говорил в начале, посмотрев на эту таблицу с уровнями, каждый руководитель может оценить и ответить на вопросы:
А где та точка, когда имеет смысл остановится с внедрением ML? Где баланс между затратами и доходами?
А как распределить ресурсы между поддержкой существующих моделей и разработкой новых?
А надо ли вкладываться в инфраструктуру, когда у меня всего пару моделей и этого более чем достаточно для повышения эффективности работы предприятия?
И многих других, ведь в бизнес применении ML как и везде - переход от одного уровня зрелости к другому стоит на порядок дороже, а будет ли отдача отличаться на порядок — это большой вопрос.
И еще один момент — я намеренно нигде (ну кроме первого уровня и то больше в шутку) не делал акцентов на используемом ПО. Мой личный опыт подсказывает, что не так важно где вы работаете над ML проектами — в Python, R, Azure ML Studio, SPSS или SAS, базовые уровни вашей зрелости от этого не изменятся ни на йоту. И по мере движения от 1-го уровня до 5-го вам в любом случае придется обрастать теми или иными дополнительными компонентами. Да есть попытки объять необъятное и закрыть большую часть потребностей одним вендорским комплектом ПО. Но в принципе ровно тоже самое можно сделать на сочетании бесплатных или значительно более дешевых компонент. Хотя это очевидно, что вендорское решение стоит своих денег зачастую не за счет качественного ПО (хотя не без этого), а за готовые шаблоны выстроенных процессов, которые с минимальными затратами можно натянуть на себя.
Но на самом деле это отдельная тема для обсуждения (или еще одной статьи, если будет вдохновение) — выбор оптимального пути от одного уровня к другому и от чего он зависит, когда и какое ПО необходимо, какая экспертиза нужна, а где здесь место аутсорсу и конечно же — а как определить точку, когда надо остановиться.
