Життєвий цикл ML моделі: від ідеї до продакшену 🚀

Уявіть, що ML модель - це як домашня рослина. Спочатку ви вибираєте насіння (ідея), потім саджаєте (розробка), доглядаєте (навчання), пересаджуєте в красивий горщик (деплой), регулярно поливаєте (моніторинг) і врешті-решт… іноді доводиться викидати засохлу рослину і саджати нову (заміна моделі).

Давайте пройдемо весь шлях ML моделі - від народження ідеї до героїчної смерті в продакшені.

Етап 1: Народження ідеї - “А що якщо?..” 💡

Історія про піцерію, яка хотіла передбачати попит

Власник піцерії “Mama ML” щовечора викидав непродані піци. Одного дня він подумав: “А що якщо ШІ зможе передбачити, скільки піц замовлять завтра?”

Типові тригери для ML проєкту:

• 😤 “Набридло робити це вручну!”
• 💸 “Ми втрачаємо гроші через це!”
• 🤯 “Людина не може обробити стільки даних!”
• 🎯 “Конкуренти вже використовують ШІ!”

Перші питання, які треба задати:

1. Чи потрібен тут ML взагалі?

   • ❌ Якщо можна вирішити простими правилами - не треба ML
   • ✅ Якщо патерни складні і змінюються - welcome to ML!

2. Чи є у нас дані?

   • Без даних ML - як борщ без буряка
   • Потрібно мінімум кілька тисяч прикладів

3. Що буде, якщо модель помилиться?

   • Передбачили мало піц → втратили клієнтів
   • Передбачили багато → викинули продукти
   • Який збиток гірший?

Реальний чек-лист перед стартом:

✅ Проблема не вирішується простими правилами
✅ Є історичні дані (мінімум 6 місяців)
✅ Помилка моделі не критична для бізнесу
✅ Є бюджет на розробку та підтримку
✅ Керівництво розуміє, що ML - не магія

Етап 2: Збір даних - “Копаємо скарби” 🏴‍☠️

Де шукати дані?

Історія піцерії продовжується: Власник почав збирати дані звідусіль:

• 📱 Історія замовлень з додатку
• 🌤️ Прогноз погоди (дощ = більше доставок)
• 📅 Календар (п’ятниця = пікові замовлення)
• ⚽ Розклад футбольних матчів (матч = +40% замовлень)
• 📊 Google Trends (“дієта” = менше піц)

Типові джерела даних:

1. Внутрішні:

   • Бази даних компанії
   • Логи серверів
   • CRM системи
   • Історія транзакцій

2. Зовнішні:

   • Відкриті датасети (Kaggle, UCI)
   • API сторонніх сервісів
   • Веб-скрапінг (обережно з правами!)
   • Покупні дані

Проблеми з даними (їх завжди багато!)

1. Брудні дані - норма життя

Найбільша ілюзія в ML - думати, що дані будуть чистими. В реальності 80% часу йде на боротьбу з хаосом. Люди пишуть по-різному, роблять помилки, використовують сленг, скорочення, емодзі. Система замовлень може зберігати одну і ту ж інформацію в десятках варіантів.

Замовлення #1543: "1 піца Маргарита"
Замовлення #1544: "маргариттта 1шт"
Замовлення #1545: "MARGHERITA!!!!"
Замовлення #1546: "1 призза маргарітка"
Замовлення #1547: "margarita double cheese" (клієнт з іншої країни)
Замовлення #1548: "та сама що вчора" (а що було вчора?)

Всі це одна і та ж піца! 🤦‍♂️ Модель має зрозуміти, що “маргарита”, “маргаритка”, “margherita” і навіть “та з помідорами і моцарелою” - це все один продукт.

2. Пропущені значення

Користувачі ненавидять заповнювати форми. Вони пропускають поля, пишуть інформацію не там, де треба, або взагалі вигадують дані, щоб швидше пройти реєстрацію. А потім ваша модель має якось з цим працювати.

Клієнт: Іван
Телефон: +380501234567
Адреса: [ПУСТО]
Коментар: "3 під'їзд, 4 поверх, кв 15, домофон не працює, подзвоніть" 
Email: ivan@aaa.aa (очевидно фейковий)
Дата народження: 01.01.1900 (111 років? серйозно?)

Адреса в коментарях, фейкові email’и, неможливі дати - класика! І це ще добре, якщо взагалі щось заповнили.

3. Викиди та помилки

Іноді в даних трапляються речі, які взагалі не мають сенсу. Це можуть бути помилки введення, баги системи, тестові дані, які забули видалити, або просто хтось жартував.

Замовлення: 999 піц (весілля на 1000 осіб чи помилка?)
Час доставки: -15 хвилин (подорож у часі?)
Ціна: 0.01 грн (промокод чи баг?)
Відстань доставки: 5000 км (з Києва в Нью-Йорк?)
Рейтинг: 11 з 5 зірок (хакер?)

Або тестували систему, або хтось щось наплутав. Але модель може сприйняти це серйозно і почати передбачати безглузді речі.

Як чистити дані:

• Стандартизація (всі “Маргарити” → “Margherita”)
• Заповнення пропусків (середнім, медіаною, “невідомо”)
• Видалення викидів (або позначення як аномалії)
• Перевірка на дублікати

Етап 3: Підготовка даних - “Готуємо інгредієнти” 👨‍🍳

Feature Engineering (Розробка ознак) - мистецтво створення характеристик

Що це таке? Feature Engineering - це процес перетворення сирих даних у формат, який машина може зрозуміти та ефективно використовувати. Це як готування їжі: у вас є сирі продукти (дані), але щоб отримати смачну страву (точні передбачення), потрібно їх правильно нарізати, приправити та приготувати.

Чому це критично важливо? Модель машинного навчання - це математична функція. Вона не розуміє, що таке “п’ятниця” чи “вечір”. Їй потрібні числа! Feature Engineering перетворює реальний світ на мову математики. Правильні ознаки можуть підняти точність моделі з 60% до 95%, а погані - зруйнувати навіть найкращий алгоритм.

Приклад трансформації:

Сирі дані (те, що ми маємо):

Дата: 2024-03-15 19:30
Замовлення: 2 піци
Клієнт: Петро Іваненко
Погода: Дощ
Адреса: вул. Хрещатик, 1

Після feature engineering (те, що бачить модель):

День тижня: П'ятниця → 5 (пон=1, вт=2, ..., пт=5)
Година: 19 → категорія "пікова" → 1 (так/ні)
Вихідний: Ні → 0
Вечір: Так → 1 
Сезон: Весна → [0, 1, 0, 0] (one-hot encoding)
Днів до зарплати: 5 (розрахунок від дати)
Днів з останнього замовлення: 3
Середнє замовлення клієнта: 1.5 піци
Частота замовлень: 2.3 рази/місяць
Дощова погода: 1 (так)
Відстань від ресторану: 2.7 км
Район: Центр → 3 (1=спальний, 2=офісний, 3=центр)
Історична конверсія п'ятниці о 19:00: 0.73

Одне замовлення перетворилось на 13+ числових ознак! ✨

Типи feature engineering:

1. Часові ознаки - витягуємо все корисне з дати/часу

   • День тижня, місяць, квартал
   • Робочий день vs вихідний
   • Ранок/день/вечір/ніч
   • Свята та особливі дні

2. Агрегації - статистика по історії

   • Середнє, медіана, мінімум, максимум
   • Кількість подій за період
   • Тренди (зростання/спадання)

3. Категоріальні перетворення - текст у числа

   • Label Encoding: “малий”→1, “середній”→2, “великий”→3
   • One-Hot Encoding: “піца”→[1,0,0], “паста”→[0,1,0]
   • Target Encoding: замінюємо категорію середнім значенням цілі

4. Взаємодії ознак - комбінуємо для нових інсайтів

   • П’ятниця + Вечір = П’ятничний вечір (особливо високий попит)
   • Дощ + Холодно = Погана погода (більше замовлень додому)

5. Доменні знання - використовуємо експертизу

   • Відстань до найближчого конкурента
   • Чи йде футбольний матч
   • Фаза місяця (для деяких бізнесів це важливо!)

Розділення даних - “Не можна навчатись і здавати іспит по одних шпаргалках”

Навіщо розділяти дані?

Уявіть студента, який готується до іспиту. Викладач дав йому 100 питань для підготовки. Якщо студент просто завчить відповіді на ці 100 питань, він здасть іспит? Тільки якщо на іспиті будуть ТОЧНО ті самі питання! А якщо викладач дасть нові питання по тій самій темі - студент провалиться.

Так само з ML моделлю. Якщо показати їй ВСІ дані під час навчання, вона просто запам’ятає відповіді. А коли прийдуть нові дані з реального світу - модель не знатиме, що робити.

Як правильно розділити дані:

Візьмемо наші 10,000 історичних замовлень піци:

Для чого кожна частина:

📚 Training Set (Навчальна вибірка) - 60-70%

Що це: Основні дані, на яких модель вчиться розпізнавати патерни. Це як підручник з детальними прикладами та розв’язками - модель багаторазово проходить через ці дані, вчиться на помилках, коригує свої параметри.

Конкретний приклад з піцерією:

7,000 замовлень (Січень-Липень):
- П'ятниця, 19:00, дощ → 85 піц замовлено
- Понеділок, 12:00, сонячно → 23 піци замовлено
- Субота, 20:00, футбольний матч → 127 піц замовлено
...ще 6,997 прикладів

Що відбувається:

1. Модель бачить: “П’ятниця вечір + дощ = багато замовлень”
2. Робить передбачення: “Наступна п’ятниця з дощем = 80 піц”
3. Порівнює з реальністю: “Було 85, помилка = 5”
4. Коригує ваги: “Треба більше враховувати погоду”
5. Повторює тисячі разів, поки помилка не стане мінімальною

Важливо: Модель може переглядати Training Set скільки завгодно разів. Кожен прохід (епоха) робить її розумнішою.

✅ Validation Set (Валідаційна вибірка) - 15-20%

Що це: Незалежні дані для перевірки якості навчання та вибору найкращої версії моделі. Це як домашні завдання - модель не вчиться на них напряму, але ми перевіряємо, чи вона справді зрозуміла матеріал, а не просто завчила.

Конкретний приклад з піцерією:

1,500 замовлень (Серпень-Вересень):
- Модель v1 (проста): помилка 15 піц в середньому
- Модель v2 (складна): помилка 8 піц в середньому  
- Модель v3 (дуже складна): помилка 7 піц в середньому

Для чого використовується:

1. Вибір моделі: Порівнюємо 5 різних алгоритмів, вибираємо кращий
2. Налаштування гіперпараметрів:
   • Глибина дерева: 5 чи 10?
   • Кількість нейронів: 50 чи 100?
   • Learning rate: 0.01 чи 0.001?
3. Ранній стоп: Коли validation помилка почне зростати - зупиняємо навчання
4. Виявлення перенавчання: Якщо train error = 1%, а validation error = 30% - проблема!

Золоте правило: Можна дивитись скільки завгодно разів, АЛЕ не можна використовувати для прямого навчання моделі.

🎯 Test Set (Тестова вибірка) - 15-20%

Що це: Абсолютно недоторкані дані для фінальної, чесної оцінки моделі. Це як реальний іспит в іншому університеті - ніхто не знає питань заздалегідь, жодних підказок, одна спроба.

Конкретний приклад з піцерією:

1,500 замовлень (Жовтень-Листопад):
Модель ніколи їх не бачила!
Передбачення моделі: 14,500 піц за 2 місяці
Реальність: 14,850 піц
Помилка: 2.4% - чудовий результат!

Чому ТІЛЬКИ РАЗ дивимось:

Уявіть ситуацію - ви подивились на test set і побачили помилку 20%. “О, треба щось змінити!” - думаєте ви. Змінюєте модель, дивитесь знову - 15%. Ще змінюєте - 12%. Супер? НІ!

Що сталось: Ви підсвідомо “підігнали” модель під test set. Тепер це вже не незалежна перевірка. Коли модель піде в реальний світ - вона провалиться.

Коли дивимось на Test Set:

1. Модель повністю готова
2. Всі експерименти закінченіКерівництво чекає на фінальні цифри
3. Дивимось ОДИН раз
4. Якщо результат поганий - НЕ ЧІПАЄМО! Повертаємось до нових даних або іншого підходу

Що робити якщо test результат поганий:

❌ НЕ: Змінювати модель і дивитись test знову

✅ ТАК: Визнати провал, зібрати більше даних, почати заново з новим train/val/test поділом

Типи розділення залежно від даних:

1. Випадковий поділ (Random Split) - для незалежних даних

Коли використовувати: Коли кожен приклад незалежний від інших і порядок не має значення.

Реальний приклад - оцінка вартості квартир:

# Маємо 10,000 квартир з різних районів і років
всі_квартири = [
    {площа: 45, район: "Центр", рік: 2010, ціна: 80000},
    {площа: 72, район: "Спальний", рік: 2018, ціна: 95000},
    ...
]

# Випадково перемішуємо
перемішати(всі_квартири)

# Ділимо на частини
train = перші_7000  # 70%
val = наступні_1500  # 15%
test = останні_1500  # 15%

Чому працює: Квартира з 2015 року не залежить від квартири з 2020. Можемо безпечно мішати.

Переваги:

• ✅ Простий і швидкий
• ✅ Дає репрезентативні вибірки
• ✅ Кожна частина містить різноманітні приклади

Недоліки:

• ❌ Не працює для часових рядів
• ❌ Може розділити пов’язані дані

2. Стратифікований поділ (Stratified Split) - для незбалансованих класів

Проблема: У нас 9,500 звичайних клієнтів і 500 VIP (5%). Якщо розділити випадково, можемо отримати:

• Train: 7,000 звичайних, 0 VIP (катастрофа!)
• Test: 1,400 звичайних, 100 VIP (невірна пропорція)

Рішення з стратифікацією:

звичайні = 9,500 клієнтів
VIP = 500 клієнтів

# Розділяємо КОЖНУ групу окремо
train_звичайні = 6,650 (70% від 9,500)
train_VIP = 350 (70% від 500)
train = train_звичайні + train_VIP  # Зберігає 5% VIP

val_звичайні = 1,425 (15% від 9,500)
val_VIP = 75 (15% від 500)
val = val_звичайні + val_VIP  # Зберігає 5% VIP

test_звичайні = 1,425 (15% від 9,500)
test_VIP = 75 (15% від 500)
test = test_звичайні + test_VIP  # Зберігає 5% VIP

Реальні приклади незбалансованості:

• Медицина: 99% здорових, 1% хворих на рідкісну хворобу
• Шахрайство: 99.9% чесних транзакцій, 0.1% шахрайських
• Виробництво: 98% якісних деталей, 2% браку

Чому критично важливо: Якщо модель не побачить рідкісні класи в train - вона просто завжди буде передбачати частий клас. Точність 99%, але всіх хворих пропустить!

3. Часовий поділ (Time-based Split) - для прогнозування майбутнього

Золоте правило: Ніколи не використовуйте майбутнє для передбачення минулого!

НЕПРАВИЛЬНИЙ підхід (Data Leakage):

Дані: Продажі за 2023-2024 роки
Train: Понеділки з усього періоду
Val: Вівторки з усього періоду  
Test: Середи з усього періоду

ПРОБЛЕМА: Модель знає продажі з грудня 2024, 
передбачаючи січень 2023!

ПРАВИЛЬНИЙ підхід:

Реальний приклад - прогноз продажів:

# Хронологічний порядок обов'язковий!
train = дані з 01.01.2023 по 30.06.2023  # 6 місяців
val = дані з 01.07.2023 по 30.09.2023    # 3 місяці
test = дані з 01.10.2023 по 30.11.2023   # 2 місяці
# Грудень - це майбутнє, яке ми будемо передбачати

# Модель вчиться: "Після такої весни буває таке літо"
# А НЕ: "В цей день тижня буває такий продаж"

Де обов’язково використовувати:

• 📈 Прогноз продажів
• 💹 Передбачення цін акцій
• 🌤️ Прогноз погоди
• 📊 Аналіз трендів
• 🏪 Прогноз попиту

4. Групований поділ (Group Split) - для пов’язаних даних

Проблема: У нас є дані від 100 користувачів, по 50 дій кожного. Якщо розділити випадково - дії одного користувача потраплять і в train, і в test!

Рішення:

# Розділяємо по користувачах, не по діях
всі_користувачі = [user_1, user_2, ..., user_100]

train_users = [user_1, ..., user_70]  # 70 користувачів
val_users = [user_71, ..., user_85]   # 15 користувачів  
test_users = [user_86, ..., user_100] # 15 користувачів

# Тепер всі дії користувача в одній вибірці
train = всі_дії(train_users)  # ~3,500 дій
val = всі_дії(val_users)      # ~750 дій
test = всі_дії(test_users)    # ~750 дій

Де використовується:

• Медицина: Пацієнт має багато аналізів - всі в одну вибірку
• Рекомендації: Користувач має багато покупок - не розділяти
• Текст: Документ має багато речень - тримати разом

5. K-Fold Cross-Validation - коли даних мало

Проблема: Маємо лише 1,000 прикладів. Якщо віддати 30% на val+test - залишиться лише 700 для навчання!

Рішення K-Fold (наприклад, K=5):

У кожному раунді:

• 80% даних (4 сегменти) використовуються для навчання
• 20% даних (1 сегмент) використовується для валідації
• Кожен сегмент побуває в ролі валідаційного рівно один раз

Результат: 5 різних моделей, 5 оцінок точності
Фінальна оцінка = середнє з 5 раундів ± стандартне відхилення

Переваги:

• ✅ Використовуємо ВСІ дані для навчання
• ✅ Отримуємо надійнішу оцінку (5 замірів замість 1)
• ✅ Бачимо розкид результатів

Недоліки:

• ❌ В 5 разів довше (треба навчити 5 моделей)
• ❌ Не підходить для часових рядів

Типові помилки при розділенні:

❌ Data Leakage (Витік даних) - коли інформація з test просочується в train Приклад: Нормалізували ВСІ дані разом, а потім розділили. Модель “знає” статистику test set!

❌ Використання test set для налаштування - дивились на test 10 разів, вибрали найкращу модель. Це вже не чесний тест!

❌ Занадто малий test set - 10 прикладів не покажуть реальну якість моделі

✅ Правильний підхід: Розділили → Навчили → Налаштували на validation → ОДИН РАЗ перевірили на test → Деплой

Етап 4: Вибір моделі - “Який інструмент взяти?” 🔧

Історія про надто розумну модель

Піцерія спробувала супер-складну нейронну мережу з 100 шарами. Вона ідеально передбачала продажі… на історичних даних. А на нових даних передбачала, що в понеділок продадуть -5 піц. 🤔

Почніть з простого!

1. Лінійна регресія - як лінійка, проста але часто працює
2. Дерева рішень - як блок-схема “якщо-то”
3. Random Forest - багато дерев голосують
4. Gradient Boosting - дерева вчаться на помилках попередників
5. Нейронні мережі - коли попереднє не працює

Як вибрати модель:

Правильний підхід - почати з найпростішої моделі, яка може вирішити задачу:

Етап 5: Навчання моделі - “Виховання розумного помічника” 🏋️‍♂️

Що відбувається під час навчання?

Уявіть, що ви навчаєте нового працівника піцерії прогнозувати попит. Спочатку він нічого не знає про ваш бізнес, але з кожним днем стає розумнішим.

Історія навчання моделі піцерії:

Взяли ми модель Random Forest і почали показувати їй історичні дані. Кожна “епоха” навчання - це як тиждень стажування для нового працівника.

Тиждень 1 (Епоха 1-5): "Я взагалі не розумію цей бізнес"
- Бачить: П'ятниця вечір, дощ, 85 піц замовлено
- Думає: "Може, завжди замовляють 85 піц?"
- Передбачає на наступну п'ятницю: 85 піц
- Реальність: 45 піц (був сонячний день)
- Помилка: 40 піц 😱

Тиждень 2 (Епоха 6-15): "О, погода впливає!"
- Навчилась: Дощ = більше доставок
- Навчилась: Сонце = люди йдуть в парк, менше замовлень
- Помилка зменшилась до 20 піц

Тиждень 3 (Епоха 16-30): "Є патерни за днями тижня!"
- Відкриття: П'ятниця завжди топ
- Відкриття: Понеділок завжди слабкий
- Помилка: 10 піц

Тиждень 4 (Епоха 31-50): "Я майстер прогнозів!"
- Враховує: День тижня + погода + свята + події
- Помилка: 3-5 піц
- Готова до роботи! 🎉

Як модель вчиться на помилках

Механізм навчання (спрощено):

1. Передбачення: Модель дивиться на п’ятницю, дощ, футбол → каже “75 піц”
2. Реальність: Насправді замовили 92 піци
3. Помилка: 17 піц недооцінила
4. Корекція: “Ага, футбол + дощ = набагато більше замовлень!”
5. Оновлення: Змінює внутрішні ваги, щоб наступного разу передбачити більше

Це як досвідчений менеджер, який помітив: “Коли грає Динамо і йде дощ, люди замовляють на 30% більше”.

Два головних ворога навчання

1. Перенавчання - коли модель стає занадто “розумною”

Піцерія має унікальну ситуацію: одного разу під час концерту Океану Ельзи замовили 500 піц. Модель запам’ятала точну дату, температуру, вологість того дня. Тепер щоразу, коли така сама температура і вологість - передбачає 500 піц. Але ж концерту немає!

Як це виглядає в даних:

# Модель запам'ятала окремі приклади замість патернів
if date == "2023-06-15" and temp == 22.5 and humidity == 65:
    return 500  # Бо одного разу так було!

Рішення:

• Не давати моделі занадто довго вчитися на одних даних
• Додати “шум” (dropout) - випадково ігнорувати частину даних
• Штрафувати за надмірну складність (regularization)

2. Недонавчання - коли модель занадто “проста”

Модель вивчила лише одне правило: “Завжди передбачай середнє - 30 піц”. Все. Байдуже, що за день, яка погода, які події.

Як це виглядає:

def predict(any_data):
    return 30  # Завжди повертаю середнє 🤷‍♂️

Рішення:

• Дати моделі більше часу на навчання
• Використати складнішу архітектуру
• Додати більше корисних ознак

Як зрозуміти, що модель готова?

Дивимось на метрики як на оцінки студента:

Іспит 1 - MAE (Mean Absolute Error):
"В середньому помиляєшся на скільки піц?"
Оцінка: 5 піц ✅ (прийнятно для бізнесу)

Іспит 2 - MAPE (Percentage Error):
"На скільки відсотків помиляєшся?"
Оцінка: 8% ✅ (чудово!)

Іспит 3 - Validation Loss:
"Чи покращуються результати?"
Останні 10 епох: без змін ⚠️ (час зупинятись)

Іспит 4 - Бізнес-метрика:
"Скільки грошей економимо?"
1000 грн/тиждень замість втрат 3000 грн ✅

Модель готова, коли:

• Помилка на валідації перестала зменшуватись (плато)
• Досягнуто бізнес-цілі (наприклад, < 10% відходів)
• Модель стабільно працює на різних даних
• Час навчання vs покращення не окупається

Етап 6: Валідація та тестування - “Іспит для моделі” 📝

A/B тестування - битва моделей

Піцерія вирішила протестувати модель в реальності:

• Понеділок-Середа: Готують за старою системою (досвід менеджера)
• Четвер-Субота: Готують за передбаченнями ML

Результати через місяць:

• Стара система: 15% непроданих піц
• ML модель: 7% непроданих піц
• Економія: 5000 грн/місяць! 💰

Крос-валідація - “Екзамен з різними білетами”

Проблема звичайної валідації:

Уявіть, що у вас є дані за 12 місяців роботи піцерії. Ви випадково поділили: 10 місяців на навчання, 2 на тест. А що якщо в тест потрапили два найспокійніші місяці (серпень-вересень, коли всі у відпустках)? Модель здасться чудовою на тесті, але в грудні (свята!) - повний провал.

Рішення - крос-валідація:

Замість одного поділу, перевіряємо модель багато разів з різними комбінаціями даних. Це як студент, який складає не один іспит, а п’ять - з різними білетами.

5-Fold крос-валідація на прикладі піцерії:

Результати кожного раунду:

Раунд 1: Тест на січ-лют → Точність: 87%
Раунд 2: Тест на лют-бер → Точність: 91%  
Раунд 3: Тест на бер-трав → Точність: 85%
Раунд 4: Тест на трав-лип → Точність: 89%
Раунд 5: Тест на лип-вер → Точність: 83% (літній спад!)

Фінальна оцінка: 87% ± 3%

Що це нам дає:

1. Надійність: Не один результат, а середнє з 5 спроб
2. Розуміння варіативності: Бачимо, що влітку модель працює гірше (83%)
3. Виявлення проблем: Якби один раунд показав 50% - є проблема з даними
4. Використання всіх даних: Кожен приклад побував і в навчанні, і в тесті

Коли використовувати:

• ✅ Мало даних (< 10,000 прикладів)
• ✅ Хочемо надійну оцінку
• ✅ Підозрюємо нерівномірність даних
• ❌ Дуже великі дані (занадто довго)
• ❌ Часові ряди (не можна мішати минуле з майбутнім)

Етап 7: Деплой у продакшен - “Модель починає реальну роботу” 🦁

Що означає “запустити модель у продакшен”?

Це момент, коли ваша модель переходить від експериментів до реальної роботи. Як випускник університету, який закінчив навчання і йде на першу роботу.

Історія запуску моделі в піцерії:

Протягом трьох місяців ми навчали модель на історичних даних. Вона показала 90% точність на тестах. Настав час довірити їй реальні замовлення!

Але як це зробити? Не можна ж просто сказати: “З понеділка всі слухають робота!” Потрібен плавний перехід.

Три підходи до запуску

1. “Щоденний прогноз” - для тих, хто не поспішає

Кожен вечір модель аналізує день і робить прогноз на завтра. Як метеопрогноз - раз на день, без поспіху.

Приклад піцерії:
Вечір неділі → Модель каже "завтра буде 45 піц"
Менеджер бачить прогноз вранці
Готує інгредієнти на 45 піц
Якщо щось не так - може скорегувати

Плюси: Безпечно, є час перевірити Мінуси: Не враховує раптові зміни протягом дня

2. “Миттєві рішення” - для швидких реакцій

Модель працює постійно і миттєво реагує на кожну подію. Як GPS, який перераховує маршрут щосекунди.

Приклад піцерії:
11:30 - Вже 20 замовлень (норма 10)
Модель: "Сьогодні буде rush! Готуйте ще тісто!"
14:00 - Почався дощ
Модель: "Буде +30% доставок, викликайте кур'єрів!"

Плюси: Швидка адаптація Мінуси: Потрібна постійна увага

3. “Локальний помічник” - модель на кожному пристрої

Модель встановлена прямо в додаток чи касу. Працює без інтернету, як калькулятор.

Приклад піцерії:
Касир вводить: "П'ятниця, дощ, футбол"
Модель на касі: "Очікуйте 80-90 замовлень"
Все розраховується локально
Дані клієнтів нікуди не йдуть

Плюси: Швидко, приватно Мінуси: Складно оновлювати

Поступовий запуск - не все одразу!

Тиждень 1-2: “Тіньовий режим”

• Модель працює паралельно з людиною
• Порівнюємо: що каже модель vs що робить менеджер
• Нічого не ламається, якщо модель помиляється

Тиждень 3-4: “Помічник”

• Модель дає поради, менеджер приймає рішення
• “Модель каже 50 піц, але це ваше рішення”
• Вчимося довіряти

Тиждень 5+: “Автопілот з контролем”

• Модель приймає рішення
• Менеджер контролює і може втрутитись
• Поступово передаємо більше відповідальності

Версії моделі - як оновлення додатків

Модель не залишається незмінною. Як додаток на телефоні, вона отримує оновлення:

Версія 1.0: Базовий прогноз (тільки день тижня)
Версія 1.1: Виправили помилку з вихідними
Версія 2.0: Додали врахування погоди (точність +15%!)
Версія 2.1: Екстрене оновлення після концерту (не передбачили)
Версія 3.0: Врахування спортивних подій

Золоте правило: Завжди зберігайте попередню версію! Якщо нова модель “з’їхала з глузду” - можна швидко повернутись назад.

Етап 8: Моніторинг - “Няньчимо модель” 👶

Що може піти не так? (Спойлер: все!)

Data Drift - світ змінився

Модель навчалась до пандемії. Під час локдауну всі замовляли додому, модель передбачає натовп в ресторані. Fail!

Ознаки проблем:

🚨 Точність впала з 90% до 60%
🚨 Розподіл вхідних даних змінився
🚨 Користувачі скаржаться
🚨 Бізнес-метрики погіршились

Система моніторингу:

# Що моніторимо щодня
metrics = {
    "accuracy": 0.89,  # Має бути > 0.85
    "latency": 45,     # мс, має бути < 100
    "requests": 1543,   # запитів за день
    "errors": 3,        # має бути < 10
    "drift_score": 0.12 # має бути < 0.2
}

if metrics["accuracy"] < 0.85:
    send_alert("🚨 Модель деградує!")

Фідбек від користувачів

Історія про бунт кур’єрів: Модель передбачила 20 піц на дощовий вечір. Замовили 60. Кур’єри працювали до 2 ночі. Виявилось - був фінал Ліги Чемпіонів, модель не знала!

Збираємо фідбек:

• Кнопка “Передбачення було точним?” в інтерфейсі
• Щотижневі опитування менеджерів
• Аналіз скарг клієнтів
• Метрики бізнесу (прибуток, відходи)

Етап 9: Оновлення моделі - “Апгрейд або смерть” 🔄

Коли час оновлювати?

Червоні прапорці:

• Точність впала на 10%+ 📉
• З’явились нові типи даних (нове меню)
• Конкуренти запустили кращу модель
• Пройшло 6+ місяців від останнього оновлення

Стратегії оновлення

1. Fine-tuning (донавчання) - “Навчаємо старі трюки”

Беремо існуючу модель і показуємо їй тільки нові дані. Як досвідченого працівника, якому пояснюють нові правила - він вже все вміє, просто треба трохи адаптуватись.

Приклад піцерії:
Стара модель знає все про звичайні дні
Донавчаємо на даних з новим меню (веганські піци)
Модель вчиться: "П'ятниця + веганське меню = +20% замовлень"
Результат: Модель зберігає старі знання + вчить нове

2. Повне перенавчання - “Почати з чистого листа”

Викидаємо стару модель і навчаємо нову з нуля на всіх даних (старих і нових). Як найняти нового працівника замість старого - довше, але іноді треба свіжий погляд.

Приклад піцерії:
Беремо ВСІ дані за 2 роки + нові за 3 місяці
Навчаємо модель з нуля (3-5 днів)
Модель вчить все заново, без старих упереджень
Результат: Часто точніша, але забуває старі "хитрощі"

3. Ансамбль моделей - “Рада експертів”

Використовуємо кілька моделей одночасно і усереднюємо їх думки. Як рада з досвідченого менеджера і молодого аналітика - кожен дає свою пораду, а ви приймаєте зважене рішення.

Приклад піцерії:
Стара модель: "Буде 50 піц" (знає історію)
Нова модель: "Буде 70 піц" (знає тренди)
Фінальне рішення: 0.3×50 + 0.7×70 = 64 піци
Результат: Баланс між стабільністю і новизною

Rollback - план Б

Історія катастрофи: Нова модель v3.0 передбачила на Новий Рік… 5 піц. Менеджер не повірив, приготували 200. Продали 195. Модель відкотили за 5 хвилин до v2.8.

Правила безпечного деплою:

1. Завжди тримай попередню версію готовою
2. Canary deployment - спочатку 5% трафіку
3. Якщо метрики падають - автоматичний rollback
4. “Kill switch” - кнопка аварійного вимкнення ML

Етап 10: Відставка моделі - “Героїчна смерть” ⚰️

Коли модель пора на пенсію?

Ознаки старіння:

• Нові моделі працюють на 30%+ краще
• Підтримка коштує більше, ніж користь
• Технології застаріли (Python 2.7? Серйозно?)
• Бізнес-логіка кардинально змінилась

Як правильно “поховати” модель

Чек-лист виводу з експлуатації:

✅ Зберегти всі артефакти (код, дані, ваги)
✅ Задокументувати причини відставки
✅ Провести ретроспективу (що вийшло, що ні)
✅ Перенести знання в нову модель
✅ Повідомити всіх користувачів
✅ Поступово перевести трафік
✅ Моніторити нову модель подвійно уважно

Епітафія моделі піцерії v1.0:

Pizza Predictor v1.0
2023-2024
"Передбачила 50,000 піц,
зекономила 100,000 грн,
навчила нас важливості даних про погоду"
R.I.P. 🍕

Типові помилки (вчимось на чужих граблях) 🎯

1. “Давайте одразу нейронку!” - Синдром крутого інструменту

Реальна історія: Стартап вирішив передбачати ціни на квартири. Одразу взяли 50-шарову нейронну мережу, навчали тиждень на потужних серверах. Результат: гірше, ніж проста лінійна регресія за 5 хвилин.

Чому це відбувається:

• Всі говорять про нейронки = здається, що це єдине рішення
• Хочеться використати “найкрутіші” технології
• Ніхто не перевірив, чи проблема взагалі складна

Як правильно:

1. Почніть з найпростішої моделі (лінійна регресія, дерево рішень)
2. Це буде ваш baseline - мінімальна планка якості
3. Якщо проста модель дає 85% точності - навіщо нейронка?
4. Ускладнюйте тільки якщо простіше не працює

2. “У нас Big Data!” - Коли 1000 рядків здається океаном

Реальна історія: Компанія з 5000 клієнтами побудувала інфраструктуру для мільярдів записів. Витратили $50k на сервери. Все працювало б на ноутбуці.

Чому це відбувається:

• Неправильна оцінка масштабу даних
• Страх “а що якщо виростемо”
• Маркетинг хмарних сервісів переконує, що всім потрібен Spark

Реальні масштаби:

< 1 GB: Excel/Pandas на ноутбуці
1-10 GB: Pandas на хорошому ноутбуці
10-100 GB: Один сервер з достатньою RAM
100GB-1TB: Кластер або хмарні рішення
> 1TB: Справжній Big Data

3. “Модель готова, деплоїмо!” - Запуск наосліп

Реальна історія: Банк запустив модель кредитного скорингу. Через тиждень виявили - вона відхиляє 95% заявок. Причина: модель “зламалась” на нових даних, але ніхто не слідкував.

Чому це відбувається:

• Думають, що модель - це як звичайний код: працює = готово
• Не розуміють, що модель може “деградувати”
• Економлять на моніторингу

Що моніторити з першого дня:

Обов'язково:
- Кількість запитів на годину
- Час відповіді (має бути < 1 сек)
- Розподіл передбачень (раптом всі однакові?)
- Помилки виконання

Бажано:
- Точність на свіжих даних (якщо є)
- Data drift (чи змінились вхідні дані)
- Feedback від користувачів

4. “99% точності!” - Занадто добре, щоб бути правдою

Реальна історія: Модель виявлення шахрайства показала 99.9% точності. Радість! Запустили - ловить 0% шахраїв. Причина: в тесті випадково були дати транзакцій, модель просто запам’ятала “майбутні транзакції = не шахрайство”.

Типові причини “неймовірної” точності:

1. Data Leakage - в навчальні дані потрапила інформація з майбутнього
2. Дисбаланс класів - 99% нормальних транзакцій, модель каже “все норм” = 99% точності
3. Перенавчання - модель запам’ятала навчальні дані
4. Неправильні метрики - дивляться тільки на accuracy

Як перевірити:

Червоні прапорці:
- Точність > 95% на складній задачі
- Train accuracy = 100%, Test accuracy = 100%
- Модель ідеально працює на старих даних, жахливо на нових
- Одна фіча дає 90%+ важливості

5. “ML вирішить всі проблеми” - Магічне мислення

Реальна історія: Ресторан витратив $100k на ML для передбачення попиту. Проблема: їх головна біда була в поганому сервісі, не в прогнозах. Клієнти не поверталися, ніякий ML не допоможе.

Коли ML НЕ допоможе:

• Проблема в процесах, не в даних
• Немає достатньо даних (< 1000 прикладів)
• Правила прості і зрозумілі (if-then вистачить)
• Рішення вже прийняте, шукають підтвердження

Питання перед стартом ML проєкту:

1. Чи вирішить проста формула цю проблему? → Використайте формулу
2. Чи є у нас дані? → Спочатку зберіть
3. Чи готові ми діяти за рекомендаціями моделі? → Якщо ні, не починайте
4. Що буде, якщо модель помилиться? → Якщо катастрофа, подумайте двічі

Ключові висновки 📝

✅ ML проєкт - це марафон, а не спринт

✅ 80% часу - робота з даними, 20% - модель

✅ Починайте з простого, ускладнюйте поступово

✅ Моніторинг так само важливий, як і розробка

✅ Модель без продакшену - просто цікавий експеримент

✅ ML потребує постійної підтримки та оновлень

Пам’ятайте: кожна велика ML система почалась з простого Python скрипта та CSV файлу. Не бійтесь починати! 🚀