ML CI/CD: автоматичне навчання, деплой і моніторинг моделей

Чому CI/CD ML розпадається на ручні операції

Цикл навчання та введення моделі в роботу часто тримається на одному інженері та його ноутбуці. Навчання запускають вручну — скриптом, з параметрами, які пам’ятають напам’ять, і на вибірці, вивантаженій тиждень тому.

Трекер експериментів на кшталт MLflow стоїть, але частина запусків іде повз нього, і відтворюваність експериментів втрачається: порівняти дві моделі немає чим, крім уцілілого файлу з метриками.

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

Метрика на контрольній вибірці виглядає рівно, а поведінка в роботі розходиться з нею — і пов’язати це з конкретною зміною вже не вдається.

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

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

У підсумку ci/cd ml існує не як процес, а як набір ручних операцій між навчанням і робочим контуром — кожна може зламатися мовчки. Розбираємо, як цей цикл замикається і що саме автоматизується.

Що дає автоматизація навчання та випуску моделей

Ручний випуск моделі розтягнутий на дні: збір даних, навчання на локальній машині, ручне вивантаження ваг, перенесення на сервер, перевірка «на око».

Конвеєр CI/CD ML проходить цей шлях за комітом або за розкладом — від гіпотези до робочої моделі залишаються години, а не тижні, і кожен запуск відтворюваний за зафіксованими версіями даних і параметрів.

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

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

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

Відкат — це повернення вказівника на попередню стабільну версію моделі: хвилини замість годин ручного перезбирання. Разом із ручними кроками зникає цілий клас відмов: забули перенавчити, виклали не той файл ваг, не звірили метрику перед випуском.

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

Режими автоматизації: повний, гібридний і ручний

Режим автоматизації визначає, скільки кроків циклу — перенавчання, перевірка якості, викочування та відкат — проходить без участі інженера.

Різниця між варіантами не в «рівні прогресивності», а в тому, на якому кроці людина ухвалює рішення про випуск нової версії моделі в робочий контур.

Вибір диктують три речі: ціна помилки моделі, частота надходження нових даних і зрілість процесів у команді. Нижче — чим режими відрізняються за застосовністю і що кожен із них обмежує.

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

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

Впровадження CI/CD ML: етапи інженерної роботи

Завдання — перетворити навчання та викладку моделей з ручної процедури на передбачуваний конвеєр. Починаємо з аудиту циклу навчання: де живуть дані, як запускається навчання, хто викладає модель і які кроки тримаються на ручних діях.

Саме там зазвичай втрачається відтворюваність — результат не можна повторити, а відкат до минулої версії збирається вручну. Далі будуємо конвеєр так, щоб кожен перехід був автоматичним і перевірюваним.

Порядок робіт

1. Аудит циклу навчання. Фіксуємо джерела даних, точки ручного втручання й час від появи нових даних до оновлення моделі в роботі. Вузьке місце найчастіше — підготовка ознак і ручна викладка.
2. Схема конвеєра. Узгоджуємо ланцюжок: підготовка даних, навчання, перевірка якості, викладка, моніторинг. На схемі позначаємо, де стоять автоматичні перевірки і за якими правилами спрацьовує відкат.
3. Версіонування даних і моделей. Робимо знімки наборів даних і прив’язуємо кожну модель до даних, коду й метрик, на яких вона навчена: будь-яку версію можна відтворити й порівняти з попередньою.
4. Налаштування середовищ і конвеєра. Розводимо контур експериментів і робочий контур, фіксуємо залежності, запускаємо навчання за подією — нові дані або зміна коду. Викладка в роботу залишається під підтвердженням відповідального.
5. Перевірка на історичних даних. Прогоняємо конвеєр на минулих періодах і порівнюємо результат з моделлю в роботі. Задаємо пороги якості, нижче яких викладка не проходить автоматично.
6. Приймання та передача. Проводимо навчальний реліз разом із командою замовника, передаємо документацію щодо конвеєра, регламент відкату й налаштування моніторингу.

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

Артефакти проєкту: конфігурації, схеми й регламенти

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

• Конфігурації конвеєра — опис етапів навчання та випуску: підготовка даних, навчання, перевірки якості, публікація моделі. Зміни проходять через рев’ю, а не через ручні дії в інтерфейсі.
• Схема архітектури — потік даних від джерел до сервісу передбачень, місця контролю якості, сховища версій моделей і пов’язаних артефактів.
• Політики доступу — ролі інженерів, аналітиків і супроводу, права на запуск перенавчання й на випуск у продуктив, розділення середовищ, порядок роботи з ключами й секретами.
• Регламент випуску моделі — послідовність перевірок перед викочуванням, умови допуску за метриками, хто погоджує, як фіксується версія і що потрапляє в журнал змін.
• Регламент відкату моделі — як повернути попередню версію й попередню конфігурацію, хто ухвалює рішення, за якими сигналами моніторингу запускається відкат.
• Регламент моніторингу — набір метрик якості та стабільності, пороги спрацьовування, кому надходить оповіщення і в які строки очікується реакція.
• Документація щодо даних і моделі — джерела, схема ознак, правила розмітки, обмеження щодо застосування й відомі слабкі місця версії.
• Інструкції із супроводу — типові операції: перенавчання за розкладом, реакція на деградацію метрик, оновлення залежностей, розбір інцидентів.

На здачі проходимо по кожному пункту разом із вашими інженерами: показуємо, де лежить, як змінювати і що перевіряти після зміни. Регламенти пишемо під ваш процес погодження, а не під зручний нам.

Кейс: як прибрали ручні прогони та простій моделей

До проєкту команда замовника випускала модель раз на два тижні: перенавчання запускалося вручну з ноутбука інженера, артефакти складалися в спільну папку, а версія в продакшені визначалася з пам’яті.

Кожен випуск — 12-15 ручних операцій: навчання, перевірка метрик, збирання образу, правка конфігів, деплой і контроль перших годин. Якщо якість падала, відкат робили через зупинку сервісу — 30-40 хвилин недоступності.

Що змінили

Перенавчання прив’язали до подій: оновлення навчальної вибірки або падіння метрики на контролі запускає прогін. Артефакти й параметри складаються в MLflow — у кожної моделі є версія, автор і пов’язаний набір даних, відновити стан можна однозначно.

Моніторинг моделей винесли окремо: обчислюємо розподіл вхідних ознак, частку відмов і якість на розміченому зворотному зв’язку, алерти надходять у канал чергової команди.

Перемикання трафіку зробили керованим — нова версія отримує частку запитів, при виході метрик за поріг трафік автоматично повертається попередній версії за 2-3 хвилини і без зупинки сервісу.

Стало: ручних операцій на тиждень — нуль замість дванадцяти, час випуску моделі скоротився з кількох годин до 25 хвилин, відкат перестав вимагати простою. За квартал жоден інцидент із деградацією якості не дожив до скарг користувачів.

Чим навчання моделі відрізняється від збирання звичайного ПЗ

У звичайному застосунку поведінка задана кодом: перевірка фіксує очікуваний результат, і поки вона проходить, реліз коректний.

У моделі контракту немає — той самий код навчання на інших даних дає іншу якість, а добра метрика в середньому не говорить про поведінку на окремих сегментах.

Тому версіонується не окремий коміт, а вся зв’язка: код навчання, знімок даних, параметри й середовище. Без знімка повторний запуск дає інші ваги, і порівнювати два релізи стає нічим.

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

Дрейф даних додає вимір, якого у звичайного ПЗ немає, — якість падає сама, без жодної правки в коді, і помітний він лише за моніторингом ознак і метрик.

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

Технічні сумніви перед початком робіт

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

Як перевіряється, що нова версія моделі не гірша за поточну?

Перед випуском модель проходить фіксований набір перевірок на відкладеній вибірці та на зрізах: рідкісні класи, сезонні періоди, аномальні сегменти.

Порівняння відбувається з робочою версією — при регресії за узгодженими метриками випуск блокується автоматично, а не за домовленістю в чаті. Рішення ухвалює правило, а не розробник.

Що станеться, якщо метрики впадуть після випуску?

Моніторинг стежить не лише за якістю відповідей, а й за розподілом вхідних даних — деградація видна раніше, ніж її помітить бізнес. При виході за поріг спрацьовує відкат на попередню стабільну версію: це хвилини, перезбирання не потрібне. Інцидент потрапляє в чергу розбору разом зі збереженим зрізом даних, на якому все зламалося.

Чи потрібно перенавчати модель за розкладом?

Розклад — це гігієна, а не гарантія актуальності. Перенавчання додатково запускається за тригерами: дрейф даних або накопичення нового розміченого обсягу. Якщо метрики тримаються в нормі, зайвий цикл не стартує і не витрачає ресурси контуру.

Обговоримо задачу й повернемося з оцінкою та планом

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

Чим конкретніші вхідні дані для старту, тим менше припущень у плані й тим раніше перший робочий прогін.

Що знадобиться з вашого боку:

• Опис поточного циклу навчання: за подією чи розкладом запускається, скільки триває, чим версіонуються дані та ваги моделі.
• Доступи до репозиторіїв із кодом і конфігураціями навчання — на читання для розбору, на запис в окремій гілці.
• Схема даних: де лежать навчальні вибірки, чи є розмітка й правила її перезбирання при зміні ознак.
• Устрій контуру: де працює модель, вимоги до ізоляції, що не можна виносити за периметр.
• Метрики якості та правила, за якими зараз дізнаються про деградацію моделі в промисловому середовищі.
• Відповідальний за приймання з вашого боку — той, хто підтверджує результат на кожному етапі.
• Регламентні обмеження: вікна викочування, порядок погодження змін, вимоги до зберігання логів.

Опишіть задачу у вільній формі й додайте те, що вже є. Повернемося з оцінкою та планом робіт: етапами, складом команди, точками контролю й критеріями приймання.