Як створити успішний ML-продукт. Ключові етапи розвитку, виклики та рівні зрілості

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

Вітаю! Мене звуть Євген Краснокутський, я ML-Lead у компанії MK Consulting. Маю понад шість років досвіду у сферах Data Science, Machine Learning та Deep Learning. Очолюю команду, яка запустила першу в Україні хмарну платформу машинного навчання.

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

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

Попередній аналіз проєкту

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

Оцінка виконуваності ML-задачі

На першому етапі попереднього аналізу визначається, чи взагалі вирішувана ML-задача, яка ставиться бізнесом. Буває так, що ML-задача не може бути розв’язана, наприклад, в рамках поточних обмежень архітектур нейронних мереж, або готових сервісів та підходів тощо. На етапі попереднього аналізу може з’ясуватися, що поставлена задача — це R&D задача, бо не існує відомих способів її розв’язання. Тобто в ML-проєктах важливіше спершу оцінити виконуваність саме ML-задачі, тому що вона більш ризикована і її виконання може зазнати невдачі скоріше, ніж реалізуються ризики виконання інших частини проєкту, таких як бекенд чи фронтенд.

Належною практикою є побудова ML-проєкту навколо задач машинного навчання та даних. Всі інші пов’язані сервіси мають будуватися навколо ML-частини проєкту та з урахуванням її специфіки.

Оцінка виконуваності інженерних задач

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

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

Фаза попереднього аналізу може містити попереднє профілювання (benchmarking) для оцінки вартості експлуатації обраних моделей. Це не завжди можливо, оскільки заздалегідь може бути невідома фінальна архітектура моделі. Варто оцінювати пропускну здатність (throughput) моделі, скільки вона потребує апаратних ресурсів (CPU, GPU, RAM), дискового простору тощо.

PoC: перевірка ідеї

Будь-який ML-проєкт варто розпочинати з фази proof-of-concept (PoC). Тобто такої фази, задачею якої є відповідь на питання, чи справді виконується поставлена задача тими методами, які було запропоновано на етапі планування. Також саме на цьому етапі можна проводити профілювання обраних рішень для більш точної оцінки експлуатації в моделі та інфраструктури в цілому виробництві (production).

Як швидко зібрати PoC і що для цього потрібно? На даному етапі бажано використовувати якнайменше інструментів та інженерного часу з найбільшою користю для бізнесу для відповіді на питання виконуваності ML-задачі. Найпростіший PoC можна зібрати в Jupyter Notebook. Там легко починати з якихось маленьких чернеток, тренувань baseline-моделей, експериментів із промптами тощо. Результати (артефакти) таких швидких експериментів необхідно зберігати. Наприклад, у налаштованому хмарному сховищі S3, на Google Drive чи іншому сховищі, яке не потребує великих часових витрат на налаштування та експлуатацію. Наступний невеликий крок — показати бізнесу або потенційним користувачам, як працює розроблена модель.

Для цього в рамках PoC варто звернути увагу на прості інструменти, наприклад, Gradio, Streamlit, FastAPI та Flask. Gradio та Streamlit дозволяють швидко зробити красивий інтерфейс роботи із моделлю та надати посилання замовникам та, наприклад, тестовій групі користувачів. FastAPI та Flask дозволяють «загорнути» ваші моделі у мікросервіс та надати ендпоінт до нього. FastAPI та Flask можуть бути дуже потужними інструментами у комбінації із Docker та Kubernetes. Всі ці інструменти дозволяють швидко перевіряти гіпотези на початкових фазах розробки ML-проєкту та швидко отримувати зворотний зв’язок.

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

• репозиторій з експериментами;
• репозиторій для сервінгу;
• базове сховище моделей.

Після того, як виконуваність задачі доведено й отримано позитивний зворотний зв’язок, можна починати масштабувати проєкт до рівня MVP.

Масштабування — наступний етап після перевірки гіпотези

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

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

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

Постає питання про зберігання, маркування, версіонування та інтегрування нових даних у ML-проєкт.

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

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

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

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

Маркування може проводитися власними силами чи делегуватися третім компаніям. Таким чином маємо наступний пайплайн, в якому:

1. Із зовнішніх джерел або внутрішніх сервісів отримуються сирі дані.
2. Сирі дані тестуються та очищаються.
3. Очищені дані необхідно у загальному випадку розмаркувати та збагатити метаданими.
4. Розмарковані та збагачені метаданими дані версіонуються та зберігаються.

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

• визначення оптимального розміру моделі;
• пошуку оптимальної архітектури;
• пошуку оптимальних гіперпараметрів.

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

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

• модуль конфігурування експерименту (всі параметри винесені у конфіг, який версіонується разом із кодом тренування);
• код тренування моделі тестується за допомогою Unit-тестів;
• натренована модель також тестується не тільки для визначення фінальної метрики якості, а й для автоматизованого збору статистик за помилками (наприклад, на яких типах вхідних даних модель помиляється найбільше; які групи можна виділити у тих даних, на яких модель помиляється; чи стійка модель до шумів у даних тощо).

Для зберігання артефактів експериментів використовують наступні системи: MLflow, Tensorboard, Weights and Bias. Насправді їх більше, але це основні, з яких, на мою думку, варто починати.

Найпростіше, що можна використати для простої візуалізації та логування експериментів, це так звана Model Card. Це невеликий документ, який розповідає все необхідне про модель: яка її архітектуру, на якому датасеті тренувалася, які метрики тренування, інформація про ваги моделі та, можливо, інформація про запуск моделі. Сам Model Card версіонується разом з експериментом. Підхід, заснований на Model Card, можна побачити на Hugging Faces.

Продукт

Сервінг

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

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

На етапі масштабування ідеї/прототипу до рівня продукту такими простими інструментами для сервінгу, як, наприклад, Gradio чи Streamlit, ми вже не можемо задовольнити наших користувачів. Під час розбудови продукту необхідно вже чітко знати, як саме буде постачатися розроблена нами модель фінальним користувачам, як вони взаємодіятимуть із нею, яким буде інтерфейс (у широкому сенсі) цієї взаємодії. Тут варто одразу зазначити наступне. Моделі в загальному випадку можна розгортати, наприклад:

• на десктопі (як частина десктопного застосунку, наприклад, як це робить Zoom);
• у браузері (як частина вебзастосунка, наприклад, як це зроблено у Google Meet);
• на edge devices:
  • на мобільному пристрої;
  • як частина прошивки роботів;
• у хмарі.

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

Далі ми зосередимо нашу увагу саме на хмарах та інструментах, які допомагають нам, ML-інженерам, розгортати та масштабувати моделі у хмарах.

Чим же такі цікаві хмари для ML-інженерів? У хмарах можна не тільки отримати обчислювальні ресурси GPU промислового рівня (наприклад, відеокарти Nvidia H100). За допомогою кількох інструментів хмари дозволяють гнучко масштабувати сервінг моделей:

• Kubernetes дозволяє налаштовувати правила горизонтального масштабування.
• Використання черг дозволяє створювати асинхронні архітектури та заощаджувати на горизонтальному масштабуванні.

ML-спільнота вже створила велику кількість інструментів для сервінгу ML-моделей на основі Kubernetes. Якщо ви плануєте розгортати та масштабувати ваші моделі у хмарах, варто звернути увагу на такі open-source інструменти:

• RayServe.
• Kserve.
• NVidia Triton.
• Seldon.

Хмарні провайдери також мають у своєму арсеналі інструменти для сервінгу моделей, зокрема:

• VertexAI від Google.
• Sagemaker від Amazon.
• Azure Machine Learning від Microsoft.

Кожен із цих інструментів має свою специфіку. Так, наприклад, Triton-у треба дати тільки вашу модель в ONNX чи torchscript-форматі, а далі він вже сам все зробить за вас. Хоча на практиці не все так просто!

RayServe, наприклад, model agnostic та framework agnostic. Він може запускати будь-які моделі та код. Щобільше, в нього можна загорнути ваш вже наявний Flask/FastAPI сервінг моделі.

Моніторинг

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

• розподіл ознак, які подаються у модель;
• розподіл цільової змінної, які отримуються як результат роботи моделі.

Моніторинг дозволяє ML-інженеру відстежувати такі важливі характеристики:

• data drift;
• concept drift;
• training-serving skew;
• виявлення викидів.

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

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

Що ми врешті-решт зібрали

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

Таку загальну структуру проєкту вже розробили та проаналізували у Google.

Детальніше з підходами Google можна ознайомитися тут

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

Якщо у вас не ML-проєкт, розрахований на користувачів, а невелика Research Lab, швидше за все, ви обмежитеся саме «ML Code». Бо ваша основна задача — розробка нового типу моделі на якомусь стандартизованому датасеті.

Оцінка зрілості ML-проєкту

The ML Test Score: A Rubric for ML Production Readiness and Technical Debt Reduction

Також у Google розробили підхід для оцінки зрілості ML-проєктів. В основі підходу лежить оцінка відповідності проєкту певним критеріям. Ці критерії покривають підходи та технології, які ми вже встигли з вами розглянути вище. Втім, основна увага приділяється тестуванню, автоматизації та моніторингу.

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

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

Власний ML-стек

Ми вже розглянули з вами еволюцію ML-проєктів від Jupyter Notebook експеримента до зрілого та масштабованого ML-продукту. А також розуміємо, як оцінити ML-проєкт.

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

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

The MLOps Stack Template

Джерело 1, 2

На сайті представлено простий шаблон, в який можна вписати їх вписати. Але, на жаль, не надається список інструментів, які можна використати для тих чи інших блоків шаблону.

MyMLOps

Джерело

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

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

Готовий стек. ML Platform

Чому варто звернути увагу на пропозиції готових ML-стеків? По-перше, вони вже розгорнуті на налаштовані. По-друге, використання готових рішень це зручно. Особливо коли у вас обмежений бюджет та бракує фахівців для розгортання, конфігурування й підтримки власного стека. По-третє, ви відразу матимете доступ до сучасних обчислювальних ресурсів.

Наприклад, готовий стек пропонує хмарний провайдер De Novo. Нижче наведено спрощену схему стека:

Вся інфраструктура збудована навколо відеокарт NVIDIA H100 / L40S / L4, технологій віртуалізації VMWare та Kubernetes.

Раніше ми вже обговорювали етапи ML-проєктів. Тепер подивімось, які технології та підходи можна використати на ML Platform для реалізації цих етапів.

Для розгортання PoC (proof-of-concept) платформа надає такі технології, як, наприклад:

• Jupyter Notebook для швидких експериментів;
• MinIO як об’єктне сховище для датасетів, вагів моделей та інших артефактів;
• для швидких демо можна використати Gradio.

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

• Tensorboard для відстежування ходу тренування;
• MLFlow для відстежування ходу тренування та версіонування моделей;
• CVAT для маркування CV датасетів;
• doccano для маркування текстових датасетів.

На етапі переходу проєкту у фазу повноцінного продукту можна використовувати:

• Ray для сервінгу (насправді, не тільки для сервінгу, а й для тренування та підбору гіперпараметрів);
• KServe для сервінгу;
• Katib для підбирання гіперпараметрів;
• Kubeflow pipelines для автоматизації процесу тренування та інших задач оркестрації;
• Grafana для розв’язання задач моніторингу та сповіщення.

Резюме

Розробка та впровадження ML-проєкту — це багатостадійний процес, який сильно відрізняється від розробки «звичайних» не-ML-проєктів. Характерними рисами ML-проєктів є наявність вагомої дослідної складової (R&D), великої кількості ризиків та невизначеностей, а також складність утримання проєкту у консистентному стані.

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

За допомогою розробленої нами ML Platform ми намагаємося розв’язати цю проблему наданням готового робочого місця ML-інженера, в якому вже розгорнуті та інтегровані відомі open source рішення.