Pull to refresh

Comments 3

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


  • делать модель итеративно, вводя новые требования постепенно, а не сразу все;
  • надо идентифицировать максимальное количество рисков до разработки;
  • максимально точно описать ожидаемую среду работы модели;
  • не прикасаться к софту пока нет модели приемлемого качества;
  • до некоторого момента работать только над качеством, а не над скоростью;
  • автоматизированный бенчмарк анализа изменения качества, скорости модели от версии к версии;
  • верно договориться, что будет считаться улучшением по методу пристального взгляда;
    ...
Что делать с моделью, которая внедрена в продакшн? Вероятно, нельзя свести ее внедрение только к коммиту кода на GitHub. На данном этапе ключевое, как мне кажется, — это создание дашборда для контроля деградации метрик качества моделей. MLOps-инженер должен организовать такой подход, при котором результатам предсказания модели можно доверять не только на модельных данных, но и на актуальных данных бизнеса.
Sign up to leave a comment.