Що дратує ML Engineer. 6 болів від фахівця з Universe Group

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

Богдан Зелінський, ML Engineer з Universe Group, працює над застосунком Visify. Це ШІ-редактор, який дає змогу створювати контент із фото за допомогою ШІ. Богдан працює з Computer Vision, генерацією зображень та відео. Ми поцікавилися у Богдана про типові проблеми, з якими стикаються ML-спеціалісти.

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

Ще три-чотири роки тому найпоширенішим «входом» у ML були стажування у великих корпораціях на кшталт Samsung. Формально позиції були у ніші software engineering, однак проєкти здебільшого стосувалися, наприклад, комп’ютерного зору. Після проходження інтернатури фахівці уже мали потрібний досвід та могли переходити на рівень мідла. 

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

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

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

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

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

Серед програмістів подібна кореляція поступово зменшується. Завдяки Cursor або GitHub Copilot навіть один досвідчений фулстек-розробник може швидко створити MVP. У ніші машинного навчання це можливо тільки частково. ML-інженер також може самостійно базове рішення, але тоді йому доводиться покладатися на готові API та open-source рішення, а не створювати все з нуля.

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

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

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

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

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

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

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

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

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

Ризики та наслідки помилок значно варіюються залежно від галузі. Наприклад, у військовій сфері ціна помилки може бути надзвичайно високою. Якщо система помилково розпізнає об'єкт або діє некоректно, це може призвести до реальних людських жертв. Або медицина — там навіть незначна похибка може вплинути на діагноз або лікування. Через це процес впровадження ML-рішень значно складніший: розробка моделі може тривати 6–12 місяців, після чого ще 2–3 роки йдуть на проходження формальної сертифікації. Модель має не лише показувати високу якість, але й відповідати суворим галузевим стандартам та нормативам.

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

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

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

У таких ситуаціях найкращим рішенням стає A/B-тестування, дає змогу залучити реальних користувачів до вибору найкращого варіанту. Врешті-решт, саме користувач є фінальним арбітром якості. Проте A/B-тестування потребує значного обсягу трафіку, тож навряд чи вийде провести його для кожного продукту чи гіпотези.