Конвеєр CI/CD для машинного навчання: Автоматизація тестів, збірок і розгортань за допомогою GitHub Actions

Більшість проєктів машинного навчання ніколи не покидають блокнот

Опитування галузі щодо прийняття MLOps неодноразово виявляють подібну цифру: більшість проєктів машинного навчання, які починаються з обіцяючих результатів у блокноті, ніколи не перетворюються на робочу систему виробництва. Причини різняться від проєкту до проєкту, але є одна загальна тенденція — розрив між «моделью, яка показує хороші результати в Jupyter Notebook» та «сервісом, який надійно відповідає запитам, безпечно перенавчається та може оновлюватися без ручного копіювання файлів на сервер» більший, ніж здається зсередини блокнота. Заповнення цього розриву відрізняє поставку даних із науки від поставки машинного навчання інженерів, а інтегроване середовище та безперервне розгортання — CI/CD — є стандартним механізмом для цього у повторюваному вигляді.

CI/CD не є концепцією машинного навчання; вона походить із загальної практики розробки програмного забезпечення. Інтегрована середовища та безперервне розгортання означає, що будь-яка зміна, завантажена в спільний репозиторій коду, автоматично тестується та перевіряється перед об’єднанням. Безперервне розгортання (або розгортання) означає, що зміни, які проходять ці перевірки, автоматично упаковуються і, у варіанті розгортання, автоматично розгортаються в робоче середовище. Застосовано до проєкту машинного навчання, такий самий механізм обробляє скрипт навчання моделі, пов’язані з ним тести та API, який обслуговує прогнози моделі, усі через одну й ту саму конвеєрну систему.

Що насправді запускає GitHub Actions ML пайплайн

GitHub Actions визначає пайплайн як послідовність завдань, що запускаються за подію, найчастіше – це відправка до головного гілки репозиторію або відкриття pull request. Типовий пайплайн для сервісу машинного навчання проходить через фіксовану послідовність етапів, кожен з яких відкриває шлях до наступного — якщо етап завершується невдало, пайплайн зупиняється на цьому етапі замість розгортання пошкодженої версії:

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

Чому важливіший механізм керування, ніж автоматизація само по собі

Тим не менш, спокусливо думати, що цінність CI/CD полягає лише в тому, щоб заощадити ручну працю з запуску тестів і копіювання файлів вручну, і це дійсно частина справи. Однак більш важлива властивість – це те, що конвеєр забезпечує фіксований порядок і відмовляється пропускати етапи під тиском. Член команди поспіхом може обґрунтовано вирішити пропустити запуск повного набору тестів перед тим, як невеликий оновлення потрапить у виробництво. Конвеєр, який блокує розгортання при невдалому тесті, не має цієї опції – етап розгортання просто ніколи не запускається, якщо етап тестування не пройшов. Це особливо важливо для проєктів машинного навчання, оскільки режими відмов часто тихіші за звичайну помилку програмного забезпечення: функція попередньої обробки, яка мовчки видаляє стовпець, ознака, що витікає інформацію про цільову змінну в навчальні дані, або модель, яка успішно навчилася, але генерує прогнози не в правильних одиницях. Автоматизовані тести, спеціально написані для виявлення цих класів відмов, запускаються при кожному натисканні кнопки замість того, щоб запускати їх лише тоді, коли хтось пам'ятає про це, виявляють проблеми, поки вони все ще на кількох рядках змін, а не після того, як вони були впроваджені у виробництво тиждень тому. Роботи в конвеєрі GitHub Actions також можуть бути налаштовані з явними залежностями – розгортання залежить від натискання кнопки, яке залежить від побудови, яке залежить від успішного проходження тестування та перевірки коду, щоб гарантувати порядок був структурним, а не питанням інструкції, яку хтось міг пропустити крок.

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

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

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

Що відбувається після розгортання

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

Часті запитання

Спробуйте наживо

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