MLOps from zero to hero. Створюємо інтелектуальну рекомендаційну систему

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

Йоу, спільното DOU!

Мене звати Анатолій Шара. Можливо, хтось з вас читав мої дописи про війну. Дійсно, ще не так давно моє життя було набагато більше пов’язане не з кодом, а з армією. Проте після вимушеного проходження ВЛК (через тяжку хронічну хворобу) відбулися зміни в характері моєї служби в ЗСУ. Ці зміни дозволили мені отримати трохи вільного часу для власного розвитку. До того ж, маючи складний досвід з попередньої ітерації російсько-української війни (2014-2016 років) я точно знав, що мені потрібно себе зайняти чимось складним і водночас цікавим, для того, щоб уникнути тяжкої форми ПТСР.

Цього разу рятівним колом для мене стала можливість навчатися на курсі «Machine Learning in Production» за кураторства Кирила Трусковського від освітньої платформи Projector. У цій статті я хочу поділитися з вами ключовою інформацією, яку взяв з цього курсу. Також сподіваюся, що ця стаття стане в нагоді тому, хто планує зайти в MLOps, але не знає, з чого почати і куди бігти. Я дуже сподіваюся на ваші коментарі щодо інформації, яка викладена в цій статті.

Декілька чесних слів про куратора та платформу: Кирило створив курс, де весь навчальний план чітко розподілений на секції. Кожна секція мала завершену структуру та список технологій, якими студент мав оволодіти під час навчання на цій секції. Постійний фідбек від Кирила не давав жодного шансу активному студенту мати якійсь прогалини в навчанні. Курс дуже насичений саме корисною та практичною інформацією. Але так, на курсі треба дійсно багато працювати та бути проактивним. Оскільки в Projector панує культ практики, то куратор створив під кожну секцію практичне завдання (таких було 15), яке не можна виконати на «абияк», користуючись винятково Cursor/ChatGPT/Claude — потрібно реально розбиратися в матеріалі. І до того ж, фіналом є захист власної курсової роботи, де студент має використати всі свої практичні знання з курсу.

Коли ти повертаєшся з середовища, де панує чіткий порядок і висока ціна помилки, ти починаєш шукати схожі принципи й у цивільній професії. Для мене таким принципом в машинному навчанні став MLOps. Багато хто з нас, ML-інженерів, захоплюється створенням елегантних моделей, які показують чудові метрики в Jupyter-ноутбуці. Але справжня магія — і справжня цінність для бізнесу — починається там, де закінчується навчання моделі. Як зробити її доступною для користувачів 24/7? Як забезпечити її стабільність, моніторинг та своєчасне оновлення? Саме на ці питання й дає відповідь культура MLOps. Це набір практик, що перетворює ізольований артефакт (модель) на надійний та масштабований продукт. І неважливо, чи ви тільки починаєте свій шлях в ML, чи вже маєте за плечима кілька успішних проектів, — без розуміння принципів виведення моделей в production, ваші найкращі розробки ризикують назавжди залишитися на вашому локальному диску.

У цій статті я не лише поділюся враженнями від курсу, а й виділю key takeaways. Крім цього, розповім про свою випускну роботу — створення рекомендаційної системи для онлайн-книгарні. Ми зануримося в деталі її реалізації, побудованої не на стандартних підходах, пройдемо шлях від ідеї до готового до розгортання сервісу, і я покажу, як принципи MLOps допомогли структурувати цей процес. Тож давайте про все по порядку.

Дані: фундамент успішного ML-проєкту

Як казав один із моїх товаришів, «80% часу в ML-проєкті йде на дані, а решта 20% — на пояснення, чому потрібно ще більше часу на дані». Ця, так би мовити, іронія відображає фундаментальну істину: без якісних даних навіть найскладніші моделі, такі як великі мовні моделі (LLM), видають лише «сміття». Тут діє універсальний принцип «garbage in — garbage out». Переконаний, що немає особливого сенсу пояснювати глибинний зміст цієї сентенції. Вміння витискати з даних максимум є гарним скілом топового ML Engineer.

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

Object Storage, як-от Amazon S3 або MinIO для on-premise рішень, ідеально підходить для зберігання «сирих» (raw) даних: зображень, відео, логів. Завдяки масштабованій архітектурі та низькій вартості, це основа для роботи з великими датасетами. Object Storage часто є серцем Data Lake — централізованого сховища, де дані зберігаються у вихідному (або майже вихідному) форматі, перш ніж їх буде оброблено та трансформовано. Це дозволяє гнучко працювати з даними, застосовуючи різні аналітичні інструменти без необхідності попереднього структурування.
Реляційні бази даних, такі як PostgreSQL, залишаються незамінними для структурованих даних із чіткими зв’язками. Більше того, розширення (add-on) pgvector дозволяє ефективно працювати з embeddings для LLM, наприклад, у системах RAG. Проте треба також пам’ятати, що складні SQL-запити на великих датасетах обов’язково стануть bottleneck, тому їх варто оптимізувати або комбінувати з іншими рішеннями, як-от розподілені системи.
NoSQL бази, як MongoDB, ідеальні для динамічних даних з змінною структурою, наприклад, метаданих експериментів, де структура може змінюватися від запуску до запуску чи зберігання документів. NoSQL бази також чудово підходять для моніторингу та кешування даних, де вимоги до схеми є гнучкими, а швидкість запису/читання висока. Наприклад, для зберігання метрик моделі, логів інференсу. У багатьох MLOps-системах NoSQL-бази можуть використовуватися як Feature Store для кешування вже обчислених фіч, щоб прискорити процес тренування та інференсу.
Графові бази, такі як Neo4j, розкривають потенціал складних зв’язків, наприклад, у рекомендаційних системах, що аналізують соціальні мережі користувачів. Хоча це не настільки поширено, як векторні бази, графові бази можуть доповнювати LLM-проєкти, надаючи контекстні знання про сутності та їхні зв’язки. Це може бути корисним для побудови Knowledge Graphs, які потім використовуються для доповнення промптів або валідації відповідей LLM.
Векторні бази даних, як Pinecone, Weaviate чи Qdrant, стали стандартом для LLM-проєктів. Вони оптимізовані для пошуку схожості embeddings, що критично важливо, наприклад для семантичного пошуку, RAG-додатків чи персоналізованих рекомендацій. У реальних проєктах часто використовуються гібридні підходи, де векторні бази комбінуються з традиційними базами даних для зберігання метаданих, пов’язаних з векторами, або для фільтрації результатів пошуку на основі додаткових атрибутів.

Важливим етапом у роботі з даними є їх розмітка (data labeling). Якість розмітки напряму впливає на якість моделей, особливо для задач Computer Vision, NLP та рекомендаційних систем. Для цієї мети ефективно використовуються спеціалізовані фреймворки, як-от Label Studio, який дозволяє розмічати текст, зображення, аудіо та відео через зручний вебінтерфейс, а також інтегрується з MLOps-інструментами для автоматизації пайплайнів. Ще одним популярним рішенням є Argilla, який орієнтований саме на NLP та LLM-проєкти і дозволяє збирати зворотний зв’язок від користувачів (human-in-the-loop labeling), що критично для задач fine-tuning та active learning. Крім роботи з реальними даними, важливим трендом стає використання синтетичних даних. Вони створюються за допомогою генеративних моделей (наприклад, GAN чи дифузійних моделей) або за допомогою LLM. Синтетичні дані дозволяють швидко масштабувати датасети, покращувати якість тренувань та уникати витоків персональних даних. Для багатьох компаній це стало не просто зручністю, а необхідністю, особливо там, де робота з реальними даними обмежена через GDPR чи інші регуляції.

Формати даних: від CSV до сучасних стандартів

Sad but true, вибір формату даних безпосередньо впливає на швидкість і ефективність ML-пайплайну. CSV, хоч і зручний для людини, є неефективним для великих обсягів через відсутність компресії та повільний доступ. Apache Parquet пропонує колонкову структуру з компресією, що ідеально для аналітичних задач, таких як обробка великих логів. Apache Arrow забезпечує zero-copy доступ до даних у пам’яті, прискорюючи обмін між процесами. Lance, новий формат, оптимізований для ML, підтримує векторні дані та швидкий доступ, що робить його особливо привабливим для LLM-завдань, таких як обробка embeddings. Трохи про фреймворки: Pandas довго був стандартом для обробки даних, але для великих датасетів Polars, написаний на Rust, пропонує 5—10-кратне прискорення завдяки lazy evaluation.

Версіонування та якість даних

Версіонування даних із DVC (Data Version Control) приносить Git-подібну семантику у світ даних. Це дозволяє повертатися до попередніх версій датасетів, порівнювати метрики між версіями та відтворювати точний набір даних для дебагінг. Наприклад, якщо модель показала аномальні результати, DVC допоможе швидко знайти, які зміни в даних могли це спричинити. Інструменти типу DataHub чи Apache Atlas, показує повну історію трансформацій: від джерела даних до фінальних фіч. Це критично для compliance у регульованих галузях, як-от фінанси чи медицина, де аудит даних є обов’язковим.

Якість даних забезпечується інструментами як Great Expectations чи Deepchecks. Вони дозволяють задавати явні очікування для даних (наприклад, «вік користувача має бути від 18 до 100») і інтегруються в CI/CD-пайплайни, блокуючи розгортання, якщо нові дані не відповідають стандартам. Це захищає production від data drift чи data poisoning, які можуть зруйнувати продуктивність моделі.

Feature Store, як Feast чи Tecton, вирішує проблему training-serving skew, коли фічі в тренуванні та production обчислюються по-різному, що призводить до невідповідності результатів. Feature Store забезпечує єдину імплементацію фіч для offline (тренування) і online (inference) сценаріїв, а також автоматичний моніторинг data drift. Наприклад, Feature Store може зберігати embeddings користувачів для рекомендаційної системи, оновлюючи їх у реальному часі через Redis для online-запитів і Parquet для offline-тренування.

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

Експерименти: мистецтво керованого хаосу в ML

Експерименти в ML — це як лабораторія середньовічного алхіміка: більшість спроб завершуються невдачею, але кожна з них наближає до епохального відкриття. Як, знову ж таки, жартує мій товариш, «якщо більше 10% ваших експериментів успішні, ви недостатньо ризикуєте». У цьому розділі як хочу поділитися своїми інсайтами з курсу, як організувати експерименти, щоб хаос залишався керованим, а результати — відтворюваними та цінними для production.

Від хаосу до структури: організація ML-проєкту

Кожен ML Engineer знайомий із хаосом в своєму проєєкті, пов’язаним з Jupyter Notebook та спробою здогадатися, що знаходиться у файлі з назвою «Untitled42.ipynb». Звичайно, Jupyter Notebook — це ідеальний старт для швидкого тестування ідей, але коли експеримент показує обнадійливі результати, настав час переходити до структуризації проєкту. Темплейти типу Cookiecutter Data Science пропонують шаблони для організації файлів, але часто це overengineering. Як на мене, ключовий принцип — починати з простої структури. Краще мати робочий прототип із мінімальною структурою, ніж ідеальну архітектуру без результатів. Типовий ML-проєкт включає директорії для даних, власне коду, моделей і конфігурацій. Наприклад, рекомендаційна система може мати скрипти для feature engineering, тренування моделей і оцінки метрик, де все чітко розділено для зручності. Така організація полегшує масштабування, коли експеримент переходить у production.

Конфігурація: від hard-coded до гнучкості

Зміна параметрів, наприклад як learning rate, прямо в коді — це швидкий шлях до плутанини. «Яке значення дало accuracy 0.94?» — питання, яке виникає перед дедлайном. Інструменти, як Hydra від Meta AI, вирішують цю проблему, дозволяючи задавати параметри декларативно через YAML-файли. Наприклад, можна запустити кілька експериментів із різними значеннями batch size чи learning rate, не змінюючи код. Hydra також підтримує override-механізми, що робить її ідеальною для автоматизації.

Трекінг експериментів: пам’ять вашої команди

Без трекінгу експериментів команда втрачає цінні знання. Інструменти, як MLflow, Weights & Biases (W&B) і Neptune.ai, перетворюють хаотичні експерименти на систематичний процес. MLflow, наприклад, дозволяє логувати параметри, метрики (accuracy, F1-score) і артефакти (моделі). Централізований tracking server у MLflow забезпечує доступ усій команді, дозволяючи порівнювати результати та відтворювати найкращі моделі. Для LLM трекінг стає ще більш критичнішим. Наприклад, fine-tuning моделі, як LLaMA, вимагає логування не лише метрик (BLEU, ROUGE), а й prompt-дизайну чи розміру датасету. W&B пропонує інтерактивні дашборди, які полегшують аналіз таких складних експериментів, дозволяючи команді бачити, як зміни в prompts впливають на якість відповідей.

Тестування в ML: від міфу до реальності

«Як тестувати модель, якщо вона недетермінована?», — поширене питання. Але тестування в ML можливе і необхідне. Unit tests перевіряють ваші скрипти на етапі preprocessing даних: наприклад, чи токенізатор обробляє edge cases чи Scaler зберігає потрібну форму даних. Property-based testing гарантує, що модель видає правильну форму вихідних даних і не падає на різних розмірах входу. Behavioral testing оцінює стійкість моделі до помилок у тексті чи незначних змін у вході, що особливо важливо для LLM, де помилки в тексті (typos) можуть суттєво вплинути на результат. Інструменти, як Deepchecks, автоматизують ці перевірки, виявляючи проблеми, як label leakage чи data drift, ще до розгортання. Інтеграція тестів у CI/CD (наприклад, через GitHub Actions) забезпечує, що тільки перевірені моделі доходять до productionу, зменшуючи ризик помилок.

GitOps для ML: версіонування всіх артефактів

Традиційний GitOps працює з кодом, але ML-проєкти включають більше артефактів: код, дані, моделі, конфігурації. DVC версіонує дані, зберігаючи лише вказівники в Git, тоді як Model Registry у MLflow трекає моделі з їхньою метаданою. Це дозволяє відтворити будь-який експеримент, навіть через місяці. Наприклад, у проєкті з детекції фроду GitOps може виглядати так: код preprocessing у Git, датасет у DVC, модель у Model Registry, а метрики — у W&B. Такий підхід забезпечує прозорість і співпрацю в команді.

Баланс швидкості та якості

На початку проєкту швидкість важливіша за ідеальність. Jupyter Notebooks дозволяють швидко перевірити гіпотези. Але коли модель готова до productionу, потрібна якість: структурований код, тести, документація. Кожен невдалий експеримент — це не втрата часу, а інвестиція в знання. Щоб ця інвестиція окупилася, потрібна система.

Пайплайни: від експериментального хаосу до production-елегантності

Після місяців експериментів ви нарешті знайшли модель, яка хоч і не ТСН, але вражає: метрики виглядають чудово, бізнес-команда задоволена, а ваш код виглядає як шедевр. Але як перетворити цей код на систему, яка працює 24/7, не ламаючись і не вимагаючи вашої уваги? Тут на сцену виходять ML-пайплайни — автоматизовані конвеєри, що переводять машинне навчання з мистецтва в інженерію.

Анатомія ML-пайплайну: більше за послідовність кроків

ML-пайплайн — це не просто скрипти, запущені по черзі. Це оркестрована система з чіткими залежностями, обробкою помилок і моніторингом. Пайплайн складається з трьох основних компонентів. Data Pipeline забезпечує надійне надходження даних, чи це real-time stream із Kafka для аналізу соціальних мереж, чи щоденний batch processing. Ключова вимога — однакові трансформації даних для тренування та production, щоб уникнути training-serving skew, коли модель у productionі поводиться інакше, ніж під час тренування. Training Pipeline запускається за розкладом або тригером, наприклад, при виявленні data drift. Він не просто тренує модель, а валідує дані, оптимізує гіперпараметри та порівнює результати з baseline моделлю. Якщо нова модель краща, вона автоматично подається в production. Inference Pipeline — це те, що бачать користувачі: швидкі, надійні передбачення. Для чатбота на базі LLM кожна мілісекунда затримки критична, тому inference pipeline оптимізується для low latency і high availability. Помилки тут неприпустимі, тому потрібні механізми graceful degradation, як-от перехід на простішу модель у разі збою.

DAG: мислення в термінах графів

Directed Acyclic Graph (DAG) — це основа сучасних пайплайнів. Замість лінійного виконання задач, ви описуєте залежності між ними. Наприклад, обчислення фіч може відбуватися паралельно, а тренування моделі чекає завершення всіх трансформацій. Переваги DAG очевидні: паралелізм прискорює виконання, fault tolerance дозволяє продовжувати роботу при збої однієї задачі, а чітка структура спрощує дебагінг. Уявіть пайплайн для детекції фроду: одна гілка обробляє транзакційні дані, інша — поведінкові патерни, і обидві об’єднуються перед тренуванням.

Оркестрація: вибір правильного інструменту

Оркестрація — це серце пайплайну, і вибір інструменту визначає успіх проекту. Apache Airflow — класика для ETL, але не ідеал для ML. Kubeflow, побудований для Kubernetes, краще підходить для ML, інтегруючись із TensorFlow і PyTorch для розподіленного навчання. Однак його складність може відлякати невеликі команди.

Сучасні альтернативи, як Dagster і Prefect, набирають популярність. Dagster фокусується на software-defined assets, роблячи акцент на даних і артефактах, а не просто задачах. Його type hints і вбудований UI спрощують відстеження повного життєвого шляху даних (data lineage). Prefect пропонує Python-first підхід із динамічними DAGs, що полегшує дебагінг і підтримує cloud-native архітектури. Наприклад, Dagster може бути кращим для LLM-пайплайнів, де потрібно трекати embeddings як активи.

Окремо варто відзначити новий тренд в оркестрації — перехід від статичних DAG до AI-агентів. Концепція 12-Factor Agents пропонує принципи побудови інтелектуальних систем, здатних динамічно адаптуватися до змінних умов. На відміну від традиційних DAG, де граф задач визначений наперед, агенти приймають рішення на основі контексту та можуть змінювати логіку виконання «на льоту». Це особливо актуально для складних LLM-пайплайнів, де потрібна гнучкість в обробці непередбачуваних користувацьких запитів, динамічний вибір джерел даних у RAG-системах або адаптивне керування context window великих мовних моделей. Хоча цей підхід наразі перебуває на експериментальній стадії, він є природною еволюцією від детерміністичних workflows до інтелектуальної оркестрації, яка краще відповідає сучасним потребам AI-систем.

CI/CD і ML-пайплайни: співпраця, а не заміна

Поширена помилка — вважати, що CI/CD замінює ML-пайплайни. CI/CD відповідає за доставку коду: тестування, деплоймент інфраструктури, перевірку якості. ML-пайплайни фокусуються на моделях: тренування, валідація, оновлення передбачень. Вони працюють у тандемі: CI/CD деплоїть код пайплайну, який потім автономно тренує моделі. Наприклад, GitHub Actions може запускати тести для preprocessing коду, тоді як Dagster оркеструє щоденне перетренування моделей.

Production-патерни: уроки великих компаній

Для надійного розгортання моделей використовуються перевірені патерни. Shadow Mode дозволяє тестувати нову модель паралельно з поточною, не показуючи її передбачення користувачам. Це ідеально для оцінки LLM, де порівнюються відповіді двох моделей. Canary Deployment спрямовує 5% трафіку на нову модель, дозволяючи виявити проблеми на малій аудиторії. Multi-Armed Bandit автоматично розподіляє трафік між моделями, віддаючи перевагу кращій. Fallback Chain забезпечує надійність: якщо складна модель не відповідає вчасно, система переходить на простішу або rule-based логіку.

Моніторинг пайплайнів: що може піти не так

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

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

Розгортання: мистецтво подачі моделей у реальний світ

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

Патерни сервінгу: вибір стратегії для вашого випадку

Не існує універсального способу розгортання моделей — вибір залежить від задачі, вимог до затримки та масштабу. Batch Serving — це робочий кінь ML. Він ідеальний для задач, де відповіді потрібні не миттєво, наприклад, щоденне оновлення рекомендацій для мільйонів користувачів або скоринг транзакцій для виявлення фроду. Результати зберігаються в базі, як-от PostgreSQL, і використовуються протягом дня. Latency не критична, але throughput має значення.

Online Serving потрібен, коли користувач чекає відповіді в реальному часі: чатботи на базі LLM, fraud detection під час оплати чи переклад тексту. Кожна мілісекунда важлива, тому моделі оптимізуються для швидкості.

Streaming Serving балансує між batch і online, обробляючи мікробатчі даних, наприклад, для IoT-сенсорів або стрімінгу соціальних мереж.

Edge Serving — найскладніший виклик, коли модель працює на пристрої користувача, як-от смартфон чи smart home assistant, з обмеженнями по пам’яті, енергії та відсутності інтернету.

Інфраструктурні патерни: від монолітів до мікросервісів

Monolithic deployment — простий старт: один Docker-контейнер із FastAPI, де модель завантажується при запуску. Це підходить для MVP, але масштабування ускладнене через downtime під час оновлень. Мікросервісна архітектура розділяє задачі: окремі сервіси для кожної моделі, API Gateway для маршрутизації, Kubernetes для оркестрації. Redis може кешувати часті передбачення, підвищуючи ефективність. Наприклад, у системі рекомендацій один мікросервіс може обробляти embeddings користувачів, а інший — ранжування. Serverless deployment із AWS Lambda чи Google Cloud Functions ідеальний для нерівномірного трафіку, коли ви платите лише за використані ресурси. Однак cold start може додавати секунди до першого запиту, що проблематично для low-latency задач, як-от чат-боти.

Стратегії розгортання: як не зламати production

Щоб уникнути збоїв, використовуються перевірені стратегії. Blue-Green Deployment тримає дві ідентичні системи: одна активна (Blue), інша — резервна (Green). Нова модель розгортається на Green, тестується, і трафік перемикається без простоїв.

Canary Deployment спрямовує 5% трафіку на нову модель, дозволяючи оцінити її на малій аудиторії перед повним розгортанням.

Shadow Mode тестує нову модель на копії production-трафіку, не впливаючи на користувачів, що ідеально для LLM, де порівнюються відповіді двох моделей. Усі ці стратегії підтримуються feature flags і routing rules для гнучкості.

Фреймворки для сервінгу: не винаходьте колесо

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

TorchServe, хоч і залишається популярним у PyTorch-спільноті, офіційно перейшов у статус «Limited Maintenance», що робить його менш привабливим для нових проєктів, де необхідна активна підтримка та швидкий розвиток. Сьогодні в центрі уваги перебувають фреймворки, оптимізовані саме для роботи з великими мовними моделями (LLM), наприклад, vLLM. vLLM забезпечує дуже високу швидкість інференсу, автоматичне кешування та ефективне управління GPU-пам’яттю, що дозволяє обслуговувати десятки одночасних запитів із мінімальною затримкою.

Також серед універсальних рішень для сервінгу варто згадати Triton Inference Server від NVIDIA, який підтримує різні фреймворки, model ensemble та оптимізований для GPU-інференсу. Іншим цікавим рішенням є KServe, побудований на Kubernetes, який пропонує зручні інструменти для autoscaling, canary rollouts і підтримує сучасні cloud-native підходи до розгортання моделей у продакшені.

Edge Deployment: коли хмара не варіант

Edge Deployment — це виклик для обмежених пристроїв. Для iOS використовується CoreML, для Android — TensorFlow Lite або NNAPI. У браузері WebAssembly і WebGL дозволяють запускати моделі для face filters чи NLP без відправки даних на сервер. Для IoT-пристроїв TinyML, як TensorFlow Lite Micro, робить можливим keyword spotting на мікроконтролерах із мінімальним споживанням енергії.

Успішне розгортання — це не лише технічне рішення, а продукт із власними користувачами (розробниками) і SLA (99.9% uptime).

Моніторинг: як не дати ML-системі жити своїм життям

У production ML-система нагадує дитину: без постійного нагляду вона може накоїти лиха. Якщо дитину розіб’є вазу, то її вартість не стане тягарем для сімейного бюджету, то ML-модель із непоміченим data drift може коштувати компанії мільйони. Моніторинг — це не просто набір інструментів, а культура, яка забезпечує надійність і передбачуваність ML-систем.

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

Infrastructure Monitoring — базовий рівень. Інструменти, як Prometheus, збирають метрики CPU, пам’яті, затримок відповідей (latency), а Grafana візуалізує їх у дашбордах. Наприклад, якщо inference-сервер для чат-бота на базі LLM починає затримувати відповіді, це сигнал для розширення ресурсів.

Data Monitoring фокусується на якості та стабільності даних. Дані постійно змінюються, і модель, натренована на вчорашніх реаліях, може не працювати на сьогоднішніх. Схема даних може змінитися, з’являються пропущені значення чи аномалії. Інструменти, як Great Expectations, дозволяють задавати правила валідації, наприклад, «жоден запис не має пропущених полів».

Model Monitoring перевіряє продуктивність моделі. У production true labels часто приходять із затримкою або взагалі відсутні, що ускладнює оцінку accuracy. Для LLM, наприклад, можна моніторити perplexity чи human feedback score. Business Metrics — це кінцева правда. Якщо модель чат-бота видає точні відповіді, але conversion rate падає, щось пішло не так. Alignment між ML-метриками та бізнес-KPI, як-от retention rate, є критичним.

Data Drift: невидимий ворог

Data drift — це коли production-дані відрізняються від тренувальних. Уявіть модель розпізнавання котів, натреновану на Instagram-фото, яка не працює на нічній камері спостереження. Існує три основні типи дрейфу.

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

Prior Probability Shift трапляється, коли змінюється розподіл цільової змінної, як у fraud detection після зміни поведінки користувачів під час пандемії.

Concept Drift — найпідступніший, коли сам зв’язок між фічами та цільовою змінною змінюється через еволюцію поведінки користувачів чи нові регуляції.

Інструменти, як Evidently AI чи WhyLabs, автоматизують виявлення дрейфу, порівнюючи production-дані з тренувальними. Наприклад, якщо розподіл віку користувачів змінився, система надсилає alert. Але важливо визначити, який дрейф критичний: невелика зміна в демографії може бути нормальною, тоді як зміна географії користувачів вимагає негайного аналізу.

Для великих мовних моделей моніторинг ускладнюється через їхню складність. Крім стандартних метрик, як latency чи error rate, потрібно оцінювати якість відповідей. Наприклад, у чат-боті можна відстежувати coherence score або toxicity detection, щоб уникнути некоректних відповідей. Human-in-the-loop feedback дозволяє користувачам оцінювати відповіді, які потім використовуються для fine-tuning. Інструменти, як Argilla, полегшують збір такого фідбеку, інтегруючись із пайплайнами.

Автоматизація та культура моніторингу

Хороший моніторинг — це не лише дашборди, а й автоматизація. Alerting rules у Prometheus можуть сповіщати про data drift чи падіння метрик. Наприклад, якщо F1-score моделі падає нижче порогу, система автоматично запускає retraining. Feedback loops дозволяють моделі вчитися на production-даних, особливо для LLM, де нові запити користувачів стають джерелом даних для покращення. Культура моніторингу передбачає прозорість: кожен член команди знає ключові метрики свого компонента, а дашборди відкриті для всіх. Post-mortems без blame culture допомагають аналізувати збої, як-от коли модель рекомендацій почала пропонувати нерелевантні продукти через зміну поведінки користувачів. Моніторинг перетворює ML із чорної магії на керований процес. Він виявляє тиху деградацію, коли модель поступово втрачає якість, але ніхто цього не помічає.

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

Курсова робота: рекомендаційна система для книжкового магазину

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

Ітерація 1: Перші кроки та перші розчарування

Роботу я почав зі збору даних: спарсив близько 10 000 описів книг з сайту однієї з українських книгарень. Кожен запис містив назву, автора, жанр та опис. Далі, за допомогою sentence-transformers, я перетворив текстову інформацію на векторні представлення (embeddings) і поклав їх у векторну базу FAISS. Перший підхід був простим — звичайний векторний пошук. І результати, чесно кажучи, були слабкими. Система часто не вловлювала нюанси: на запит про «детектив у вікторіанському стилі» могла видати сучасний трилер лише тому, що в описі випадково згадувався Лондон. Метрики на контрольному датасеті підтверджували проблему.

Ітерація 2: Інженерний підхід та гібридна сила

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

Файн-тюнінг моделі: Я донавчив sentence-transformers на власному датасеті, приділяючи особливу увагу жанровим відмінностям та іншим важливим деталям. Це дозволило моделі краще розуміти специфіку саме книжкового світу.
Hybrid Search: Я об’єднав найкраще з двох світів: класичний пошук BM25, який чудово працює з ключовими словами (назви, автори), та вдосконалений векторний пошук для розуміння семантики.
Re-ranking з CrossEncoder: Попередні результати від гібридного пошуку я передавав на RRF, а вже відранжовані результати на точнішу модель CrossEncoder. Вона повторно оцінювала релевантність пари «запит-книга» і видавала фінальний, відсортований за якістю список.

Результат перевершив усі очікування. Усі ключові метрики — Precision@5, Recall@5, MRR, NDCG@5 — суттєво зросли. Навіть суб’єктивно пошук став на порядок якіснішим.

Ітерація 3: Додавання магії з LLM

На цьому етапі я вирішив додати інтелектуальну надбудову за допомогою Gemini від Google. Я використав її не як заміну пошуку, а як доповнення. Коли користувач отримував список книг від гібридної системи, він міг поставити уточнюючі питання у форматі діалогу, наприклад: «А яка з цих книг найбільше сподобається фанату „Дюни“?» або «Зроби коротке порівняння перших трьох книг». Gemini, отримавши контекст з результатів пошуку, генерувала змістовні та персоналізовані відповіді, перетворюючи простий пошук на інтерактивного книжкового консультанта.

Фундамент MLOps: як перетворити проєкт на систему

Створити хорошу модель — це лише половина справи. Щоб система була надійною та готовою до реального життя, я одразу закладав у неї принципи MLOps.

Оркестрація процесів з Dagster: Щоб перетворити цей набір скриптів на відтворюваний та надійний процес, я використав оркестратор Dagster. З його допомогою я побудував єдиний пайплайн, що автоматизував ключові задачі:

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

Від демо на ноутбуці до production: для демонстраційних цілей через Gradio інференс моделі відбувається локально. Однак у MLOps-контексті наступним логічним кроком було б загортання всієї системи (векторна база, модель, API) у Docker-контейнер та розгортання її як REST API-ендпоінту (наприклад, з FastAPI) у хмарному середовищі. Це дозволило б інтегрувати рекомендаційну систему в будь-який реальний вебсайт книгарні, забезпечити її масштабування та налаштувати централізований моніторинг запитів і швидкодії за допомогою інструментів на кшталт Prometheus/Grafana. Весь код, звісно, версіонувався в Github, а для повного циклу MLOps до цього процесу можна було б додати автоматичне тестування якості моделі після кожного оновлення та підключення реєстру моделей на кшталт MLflow.

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

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

Моно: 4441114463303287
Приватбанк: 5168745018225596

Теми: AI, DevOps, ML, MLOps