50-пунктний чекліст ML-проєкту: від ідеї до production

## Навіщо потрібен чекліст ML-проєкту Кожен ML-проєкт проходить схожі стадії: дані, модель, валідація, деплой, моніторинг. Але кожного разу команди наступають на ті самі граблі — пропущена перевірка якості даних, відсутній baseline, забутий моніторинг дрейфу. Цей чекліст зібрано з реального досвіду десятків проєктів. Не обов'язково виконувати кожен пункт — але потрібно свідомо вирішити, чи пропускаєте ви його і чому. ## Блок 1: Постановка задачі (пункти 1–8) 1. Сформульована конкретна бізнес-ціль з вимірюваною метрикою успіху 2. Визначено, хто є власником результату з боку бізнесу 3. Оцінено baseline — поточний стан без ML 4. Визначено мінімально прийнятний рівень якості моделі для production 5. Узгоджено асиметрію помилок: що дорожче — false positive чи false negative 6. Оцінено ROI при досягненні цільової якості 7. Визначено горизонт проєкту та milestone-и 8. Узгоджено критерії go/no-go для PoC та MVP ## Блок 2: Дані (пункти 9–18) 9. Визначено всі джерела даних і відповідальних за них 10. Оцінено обсяг: чи достатньо даних для задачі 11. Перевірено глибину часового покриття 12. Проведено EDA (розвідувальний аналіз): розподіли, кореляції, аномалії 13. Оцінено відсоток пропущених значень у ключових полях 14. Виявлено та оброблено дублікати 15. Перевірено часову коректність: чи немає майбутніх даних у навчальному наборі 16. Перевірено баланс класів 17. Виконано анонімізацію або псевдонімізацію персональних даних 18. Документовано схему даних та бізнес-визначення кожного поля ## Блок 3: Feature Engineering (пункти 19–24) 19. Визначено ознаки на основі доменного знання 20. Виконано кодування категоріальних змінних 21. Застосовано scaling для алгоритмів, чутливих до масштабу 22. Перевірено на data leakage: жодна ознака не містить інформацію з майбутнього 23. Проведено відбір ознак (feature selection) 24. Задокументовано всі трансформації для відтворення в production ## Блок 4: Модель (пункти 25–32) 25. Вибрано baseline-модель (найпростіше можливе рішення) 26. Проведено порівняння кількох алгоритмів на валідаційній вибірці 27. Виконано підбір гіперпараметрів 28. Перевірено на overfitting: gap між train та validation метриками 29. Оцінено інтерпретованість моделі та чи потрібна explainability 30. Перевірено справедливість (fairness): чи немає дискримінації за захищеними ознаками 31. Визначено threshold для класифікаційних задач на основі бізнес-пріоритетів 32. Задокументовано архітектуру та гіперпараметри фінальної моделі ## Блок 5: Валідація (пункти 33–38) 33. Тестова вибірка відкладена до фінальної оцінки і не використовувалась для підбору 34. Для часових рядів розбиття хронологічне 35. Оцінено розподіл помилок: де модель помиляється найчастіше 36. Проведено аналіз важливості ознак 37. Валідовано на даних, максимально близьких до production-розподілу 38. Отримано підтвердження від бізнес-стейкхолдера, що результати відповідають очікуванням ## Блок 6: Деплой (пункти 39–45) 39. Модель упакована у Docker-контейнер з фіксованими версіями залежностей 40. Реалізовано REST API або інтеграцію з цільовою системою 41. Перевірено latency inference: чи відповідає вимогам 42. Налаштовано версіонування моделі (MLflow Model Registry або аналог) 43. Реалізовано процес rollback до попередньої версії 44. Проведено load-тестування при очікуваному навантаженні 45. Задокументовано API-специфікацію та параметри розгортання ## Блок 7: Моніторинг (пункти 46–50) 46. Налаштовано логування всіх вхідних запитів та відповідей моделі 47. Впроваджено моніторинг data drift та model performance drift 48. Налаштовано алерти при відхиленні метрик від baseline 49. Визначено процес перенавчання: тригери та відповідальні 50. Заплановано регулярний аудит якості моделі (щонайменше раз на квартал) ## Як використовувати чекліст Не намагайтеся виконати всі 50 пунктів однаково ретельно в кожному проєкті. На стадії PoC достатньо блоків 1–5. На стадії MVP — 1–6. Повноцінне production-рішення потребує всіх 7 блоків. Найцінніше — не галочки, а усвідомлені рішення: "пропускаємо пункт 30 (fairness), бо задача не стосується захищених категорій". Свідоме пропускання — норма. Несвідоме — ризик.