Всем привет! Эта статья - обобщение моего опыта 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 выбрали текущий экспертный подход, за технический для оценки модели - случайные рекомендации. Оказалось, что случайные рекомендации работают лучше, чем экспертные
Интересные статьи
Интересные статьи
