Comments 5
Сводная табличка получилась неплохая, а с текстом кое-где не согласен: некоторые куски из уровня 3 лучше начать применять раньше, или, например, разделение сред на дев/тест/прод может прийти само собой, если удастся сесть на хвост остальному IT/разработке в компании.
Спасибо на добром слове. А то мне как раз табличка кажется слишком поверхностной — все-таки пришлось прилично сократить, чтобы влезть в табличный формат :)
А то что некоторые куски 3-4-5 уровней имеет смысл внедрять пораньше — ну в общем грех не согласится. Все же зависит от конкретных задач, их критичности и степени онлайна. Другое дело, что браться на 1-м уровне зрелости за высококритичные бизнес-задачи с откликом в реальном времени это прямой путь либо быстро позврослеть и перепрыгнуть на пару ступенек или классно все зафакапить, когда система ляжет по какой-нибудь банальной причине.
А то что некоторые куски 3-4-5 уровней имеет смысл внедрять пораньше — ну в общем грех не согласится. Все же зависит от конкретных задач, их критичности и степени онлайна. Другое дело, что браться на 1-м уровне зрелости за высококритичные бизнес-задачи с откликом в реальном времени это прямой путь либо быстро позврослеть и перепрыгнуть на пару ступенек или классно все зафакапить, когда система ляжет по какой-нибудь банальной причине.
А почему процессы для ML вообще должны отличаться? Не, понятно что нюансы есть всегда, но на мой взгляд нужно просто смотреть на создание моделей точно так же, как на создание ПО вообще.
Да в общем никто и не говорит, что процессы в ML принципиально отличаются от любых других. Вопрос только в том уровне абстракции, на котором вы находитесь. Если вы смотрите прилично сверху, то CMMI вам в руки и уже можно работать.
Но если идти в детали, то при всем подобии подходов к разработке ПО, обучение моделей это только частично разработка. И даже можно сказать больше — конкретно обучение модели это совсем НЕ разработка, ведь на процесс обучения дата сайнтист может повлиять лишь косвенно. Вот для того чтобы учесть эту специфику (т.е. версионность данных, контроль прогноза в будущем и т.п.) мне показалось логичным систематизировать подход таким образом. Кстати если будет интересно, то по этому поводу был интересный доклад на Datafest 2020 про адаптацию подходов CI\CD под ML. Несколько затянуто, но любопытно, рекомендую.
Но если идти в детали, то при всем подобии подходов к разработке ПО, обучение моделей это только частично разработка. И даже можно сказать больше — конкретно обучение модели это совсем НЕ разработка, ведь на процесс обучения дата сайнтист может повлиять лишь косвенно. Вот для того чтобы учесть эту специфику (т.е. версионность данных, контроль прогноза в будущем и т.п.) мне показалось логичным систематизировать подход таким образом. Кстати если будет интересно, то по этому поводу был интересный доклад на Datafest 2020 про адаптацию подходов CI\CD под ML. Несколько затянуто, но любопытно, рекомендую.
>т.е. версионность данных, контроль прогноза в будущем и т.п.
Ну, я просто хочу сказать, что в отсутствие ML это (похожие нюансы) тоже может иметь место. Модели имели место давно, просто они обычно были условно, в форме вписывания полигона в имеющийся набор точек, ну или там таблицы решений. Контролировать тот факт, что любая модель все еще валидна в сегодняшних изменившихся условиях — это в общем-то тоже важно, и должен быть такой этап жизненного цикла.
Ну, я просто хочу сказать, что в отсутствие ML это (похожие нюансы) тоже может иметь место. Модели имели место давно, просто они обычно были условно, в форме вписывания полигона в имеющийся набор точек, ну или там таблицы решений. Контролировать тот факт, что любая модель все еще валидна в сегодняшних изменившихся условиях — это в общем-то тоже важно, и должен быть такой этап жизненного цикла.
Sign up to leave a comment.
Уровни зрелости ML-процессов (процессов, связанных с Машинным Обучением)