Машинне навчання (Machine learning, ML) — це наука, яка допомагає штучному інтелекту навчатися та вдосконалюватись без застосування принципів традиційного програмування. Детальніше про те, які фахівці будуть потрібні в цій сфері, чи потрібен Python для роботи в Machine Learning та які тренди врахувати, розповів Дмитро Войтех — Lead ML Engineer у компанії Proxet (проєкт GIPHY).

Як порівняти штучний інтелект та машинне навчання зі звичайним програмуванням? На прикладі

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

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

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

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

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

Як переформатувати розв’язання задачі під принципи машинного навчання? Для кожного типу активності треба збирати тренувальну вибірку. Вона буде представлена у зручному для ML-алгоритму вигляді. Це буде певний масив чисел, які відповідають (у цьому випадку) за сенсорні покази.

Як зібрати ці дані? Частину з них нададуть користувачі. Наприклад, під час активності девайс ставитиме питання: «Чи ви зараз біжите?», «Ви їдете на велосипеді?» і т.п.

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

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

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

Є питання: яку книгу варто прочитати ML інженеру?

«Deep Learning» (Ian Goodfellow, Yoshua Bengio, Aaron Courville). Книга дає доволі фундаментальний бекграунд щодо того, що відбувається всередині моделей. Ще є видавництво O’Reilly, на якому дуже багато літератури по ML на різноманітні теми.

ML Lifecycle — невід’ємна частина продукту

Життєвий цикл ML моделей включає такі етапи:

• отримання і трансформація даних;
• навчання і валідація моделі;
• впровадження моделі;
• відстеження артефактів, отриманих після тренування;
• моніторинг.

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

Роль Python в Machine learning

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

Звичайно, Python — не найбільш оптимальне рішення з точки зору продуктивності: в ньому є така проблема як GIL (глобальне блокування інтерпретатора), яка унеможливлює нормальне існування багатопоточності (яка є у мовах типу C++, JAVA). Якщо ми маємо якусь продуктивну багатопоточну програму, то у випадку з Python доведеться перемикати контекст між ними. Тобто кожен потік матиме певне часове вікно, в яке він буде виконуватися, а далі буде блокування системи через GIL і передача виконання іншому потоку.

Але в той же самий час за допомогою бібліотек з нативними розширеннями (cython, numpy, pandas і так далі) мова Python стає надзвичайно актуальною для машинного навчання. Сенс у тому, що на рівні нативних бібліотек продуктивність буде наближена до програми, реалізованої аналогічною мовою (наприклад, С++).

Переваги Python:

• має найпотужніші ML фреймворки: PyTorch, Tensorflow (Keras), Jax, Theano;
• забезпечує як тренування, так і serving;
• здійснює конвертацію та оптимізацію моделей під будь-які платформи (мобайл, браузер тощо).

Найближчий курс за напрямом: Python з нуля

Як інженеру, який знає Python та має базові знання у ML, почати працювати в індустрії?

Найбільш прийнятний варіант — почати з прикладних курсів. Серед них:

• Practical Deep Learning for Coders від fast.ai;
• Computer Vision від pjreddie.com;
• Natural Language Processing від huggingface.co. 

Також популярний шлях — Kaggle-змагання. 

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

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

Є питання: чи є можливість стати MLE за відсутності комерційного досвіду? Якщо так, то яким чином?

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

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

Що варто знати інженеру, який хоче бути конкурентним на ринку праці?

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

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

І як надбудова до Docker, найбільш популярним рішенням для оркестрації (поєднання контейнерів у одну систему) є Kubernetes. 

Розширенням для Kubernetes з ML-специфікою є платформа Kubeflow. Це система для побудови ML конвеєрів, оркестрації, експериментів, тренувань тощо. Серед систем з відкритим кодом вона найбільш популярна.

Мастхев для ML-інженерів — працювати з даними. Це може бути просто здатність обробити великий обсяг інформації: наприклад, щоб порахувати якісь метрики або зробити базову аналітику. Для цього є доволі багато засобів. Наприклад: Pandas, Dask, Spark.

ML: тренди і тенденції

За даними Linkedin job openings report, в останні роки впала кількість посад Data scientist і водночас підвищилась кількість Data engineer та ML engineer. Що це значить? Бізнес стає більш продуктово-орієнтованим. Потрібні люди, які не просто опрацьовуватимуть дані, а створюватимуть конкретні продукти.

Є питання: ML та Data Science — це різні професії?

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

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

Ще є тенденція на датацентричний ML. Коли все відштовхується не від моделі, а від даних. Уявіть собі ресторан, в якому готують їжу. Скільки часу потрібно на пошуки інгредієнтів та їх підготовку? Приблизно 80%. 20% займає безпосередньо приготування їжі у духовці чи на пательні. 

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

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

Як модель може вивчати такі залежності?

1. На першому графіку дуже мало даних. Скоріше за все модель не зможе узагальнитися для досягнення нормальної точності
2. Другий графік показує велику кількість даних бех обмежень. Це реалії сучасного ML. А якщо ми приберемо дві третини цих даних і залишимо тільки найякісніші? Для цього треба мати певні метрики, які й визначатимуть якість даних. В принципі, визначити критерії якості не так складно для конкретно взятої задачі.
3. Якби ми залишили тільки якісні дані, модель давала б приблизно такі самі точні результати як і у попередній ситуації. Це демонструє третій графік.

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

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

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

Citizen ML Engineer. Це людина, яка не має глибокого знання комп’ютерних наук, але вона дуже добре розуміється на конкретній предметній області. Наприклад, це лікар. Він знає сферу, розуміє дані і усвідомлює, що саме хоче отримати від алгоритму. Використовуючи доступний високорівневий no-code/low-code інструментарій для ML, він може розв’язувати прикладні задачі: наприклад, знаходити на знімках ракові пухлини.

Є питання: Citizen ML — це розвиток концепції AutoML? (ред.: AutoML — системи, які автоматизують процес навчання моделей та підбору оптимальної архітектури і гіперпараметрів)

Чи можливо, що через кілька років вакансії спеціалістів ML Reseacher чи ML Engineer стануть менш актуальними або зникнуть?

Думаю, що все одно буде багато доменів і продуктів, де знадобляться кваліфіковані ML спеціалісти. Це все одно існуватиме і займатиме пропорційну роль у ніші. Я не вважаю, що Citizen Engineer — це розвиток AutoML. Правильніше сказати, що Citizen Engineer може користуватися AutoML продуктами.

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

Люди вже усвідомили, що це ML  — це не «чарівна паличка». Ми опускатимемося ще нижче за графіком, що зображає відомий “цикл хайпу” Гартнера. Але все одно прийдемо до ML середовища, в якому будуть загальноприйняті практики й стандарти та, як наслідок, процеси стануть більш прозорими й стабільними.

Неструктуровані дані. Їх в ML більше за 90%. Переважно це інформація, отримана з інтернету. Часто це просто набір текстів, картинок. І тому є потреба в масштабованому сховищі під них та засобах для їх обробки. В останній час саме завдяки неструктурованим даним відбуваються найбільші прориви в ML індустрії – взяти наприклад величезні Language Models навчені на тектових корпусах отриманих з інтернету.

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

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

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