Комментарии 3
Там маленькая опечатка в одном месте: Jupyter вместо Jupiter
Проблема важна и существенна, автору респект за попытку с ней справиться. Однако, он свел процесс к этапам, что не совсем годится на практике, поскольку этапы могут легко буксовать и уходить в бесконечную "возню". Автор просто менеджерский, высокоуровневый водопад адаптировал, что большим боссам поможет говорить "где мы", но не "когда мы". Тут большую ценность имели бы "принципы", которые обеспечивают продвижение. Например, в нашем случае,
- делать модель итеративно, вводя новые требования постепенно, а не сразу все;
- надо идентифицировать максимальное количество рисков до разработки;
- максимально точно описать ожидаемую среду работы модели;
- не прикасаться к софту пока нет модели приемлемого качества;
- до некоторого момента работать только над качеством, а не над скоростью;
- автоматизированный бенчмарк анализа изменения качества, скорости модели от версии к версии;
- верно договориться, что будет считаться улучшением по методу пристального взгляда;
...
Что делать с моделью, которая внедрена в продакшн? Вероятно, нельзя свести ее внедрение только к коммиту кода на GitHub. На данном этапе ключевое, как мне кажется, — это создание дашборда для контроля деградации метрик качества моделей. MLOps-инженер должен организовать такой подход, при котором результатам предсказания модели можно доверять не только на модельных данных, но и на актуальных данных бизнеса.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как управлять проектами машинного обучения и data science