35 реальных рисков, убивающих data- и machine learning проекты
Всем привет! Эта статья — обобщение моего опыта 30+ проектов, связанных с обработкой данных и машинным обучением. Здесь не будет теории про управление рисками и общего перечня проектных рисков. Я перечислил только наиболее частые «грабли» именно из data-специфики, с которыми приходилось сталкиваться за последние 7 лет. Надеюсь, что эта статья поможет менеджеру проекта или менеджеру продукта сохранить свой цвет волос, ценное время команды и удовлетворенность заказчиков. Риски я разделил на три группы:
Нет гарантий, что удастся добиться удовлетворительного качества ML-моделей в отведенное время. Ни объективно — в сравнении с baseline, ни субъективно — по мнению заказчика. Это может быть серьезной угрозой для проекта. По возможности, всегда нужно проводить Discovery фазу или начинать с Proof of Concept, чтобы доказать реализуемость и найти baseline. Также важно ориентировать заказчика на долгосрочную стратегию постоянных улучшений. Большинство заказчиков по прежнему ожидают попадания с первого выстрела.
Нет гарантии, что качество ML-моделей будет стабильно в течение всего периода эксплуатации. Всегда необходимо держать буфер времени на «докрутку» моделей в случае непредвиденных обстоятельств.
Недостаточное количество данных может привести к недостаточной точности моделей. Нет универсального ответа на вопрос «а сколько данных надо». Все зависит от распределения классов, например, и других факторов. Идеально предоставить данные дата-саентисту хотя бы на один день для оценки.
Недостаточное качество данных может привести к недостаточному качеству ML-моделей. Перед началом разработки модели рекомендуется провести тщательное исследование данных и составить отчет для заказчика с обозначением всех находок и рекомендациями.
Регулярности в данных может и не быть. Регулярность в данных — главный фактор качества ML-моделей. Во-первых: регулярности в данных может не быть. Это сделает проект не выполнимым. Во-вторых: сильные внешние события могут кардинально поменять паттерны в данных и привести к падению качества моделей.
Например, локдаун принципиально изменил характер трафика. Настолько, что время «до» нельзя было даже использовать для обучения.
Неверно выбранный baseline для сравнения с ML-моделью. Baseline нужен, чтобы можно было посчитать добавленную ценность от внедрения ML-модели. От сравнения результатов модели и baseline может зависеть решение об успешности всего проекта. На мой взгляд наиболее честно — выбрать в качестве baseline тот подход, который использовался «до» внедрения модели. Важно Еще бывает необходимо оценить конкретную ML-модель, а не целиком внедренную систему. Тогда в качестве дополнительных baseline можно использовать, например, random-модель, dummy-модель или rule-based подход. Важно не только правильно выбрать baseline, но и сформировать правильные ожидания у заказчика. Какой процент улучшения будет считаться хорошим?
Пример из практики: Разрабатываемая платформа с системой продуктовых рекомендаций должна была заменить «ручные» рекомендации, сделанные экспертами. За бизнес-baseline выбрали текущий экспертный подход, за технический для оценки модели — случайные рекомендации. Оказалось, что случайные рекомендации работают лучше, чем экспертные
