Machine learning workflow

Інтуїція

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

Найкраще прогнозує розвиток подій рамка не «проєкту», а боргу. Побудувати систему прогнозування швидко; тримати її коректною — ні. Стандартна праця на цю тему стверджує, що «небезпечно вважати ці швидкі перемоги безкоштовними» і що «поширеною є ситуація, коли реальні ML-системи спричиняють величезні поточні витрати на підтримку» [2, abstract].

Робочий процес існує, щоб зробити ці витрати видимими, поки їх ще дешево змінити, — а це переважно означає рано.

Формальне визначення

Теореми тут немає: робочий процес — це інженерна дисципліна, і найкориснішим формальним твердженням про нього є той порядок фаз, до якого сходиться досвідчена практика. Версія Google має три фази й передумову, і саме передумова вражає: правило 1 — «не бійтеся запустити продукт без машинного навчання», бо «машинне навчання — це круто, але воно потребує даних» [1, Rule 1].

Далі фази йдуть так: Ваш перший конвеєр, Інженерія ознак, а потім Сповільнене зростання, доопрацювання оптимізації та складні моделі [1, ML Phase I–III]. Зверніть увагу, що стверджує цей порядок: складна модель — це остання фаза, після того, як інфраструктура й колонки вже правильні. Фаза I відкривається словами «тримайте першу модель простою і зробіть інфраструктуру правильно» [1, Rule 4].

Як це працює

Формулювання. Вирішіть, що прогнозується і що робитимуть із прогнозом. Настанова — «спроєктувати й реалізувати метрики» ще до того, як з’явиться модель [1, Rule 2], і взяти «просту, спостережну й атрибутовну метрику для першої цілі» [1, Rule 13].

Дані й поділи. Усе нижче за течією успадковує це. Відкладіть тестовий набір і тримайте його закритим, бо налаштування під нього призводить до просочування: «знання про тестовий набір може “просочитися” в модель, і метрики оцінювання більше не звітують про якість узагальнення» [3, §3.1].

Ознаки. Щойно є робочий конвеєр, саме тут «багато легкої здобичі», тому Google і робить це другою фазою [1, ML Phase II].

Навчання. Той крок, який усі й уявляють, і той, що найменше змінюється від проєкту до проєкту.

Оцінювання. За метрикою з першого кроку, на даних із другого, з крос-валідацією там, де один поділ надто шумний, щоб щось вирішувати [3, §3.1].

Експлуатація і ребро назад. Пунктирний зворотний шлях — це і є робочий процес, а не додаток до нього. Продакшен змінює дані: через контури зворотного зв’язку, через зміни в зовнішньому світі, через споживачів, про яких ви не знали. Аналіз технічного боргу називає це точно: «розмивання меж, заплутаність, приховані контури зворотного зв’язку, незадекларовані споживачі, залежності від даних, проблеми конфігурації, зміни в зовнішньому світі й різноманітні системні антипатерни» [2, abstract].

Два правила існують суто для того, щоб дві половини цього циклу лишалися узгодженими: зберігайте набір ознак, використаний під час обслуговування, і навчайтеся з нього [1, Rule 29], а розбіжність між навчанням і обслуговуванням вимірюйте як повноцінну метрику [1, Rule 37].

Де застосовується

• Будь-яка модель, що виходить у світ. Моделі в блокноті потрібна ліва половина; моделі, яка ухвалює рішення, потрібен цикл.
• Регульовані сфери — кредитування, страхування, медицина, — де питання аудиту стосується походження й версіонування, а не точності.
• Рекомендації та ранжування, де ребро зворотного зв’язку не метафора: вихід моделі стає завтрашніми навчальними даними, і це і є прихований контур зворотного зв’язку [2, abstract].
• Передавання роботи в команді. Робочий процес — це ще й контракт інтерфейсу: він визначає, за що відповідають аналітики, інженери й рецензенти.
• Розбори інцидентів. Коли розгорнута модель деградує, робочий процес — це впорядкований перелік місць, куди дивитися.

Чому і коли

Дотримуйтесь порядку фаз, особливо коли він видається повільним. Спокуса — почати з моделі, бо ця частина цікава й наочна. Правило 4 пояснює чому: перша модель «дає продуктові найбільший приріст, тож їй не треба бути вишуканою», але «ви натрапите на значно більше проблем з інфраструктурою, ніж очікуєте» [1, Rule 4].

Обирайте просту спостережну ціль на початку. Легше покращувати метрику, яку можна атрибутувати, ніж сперечатися про метрику, яку не можна [1, Rule 13].

Тестуйте інфраструктуру окремо від навчання [1, Rule 5]. Більшість збоїв — це сантехніка, а сантехнічні збої, діагностовані як проблеми моделювання, коштують тижнів.

Знайте, коли не робити нічого з цього. Якщо задачу розв’язує евристика — викочуйте евристику [1, Rule 1]. Робочий процес дорогий і окуповується лише за певного масштабу наслідків.

Практичний приклад

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

import numpy as np

rng = np.random.default_rng(3)
n_cust, per_cust = 300, 6

home = rng.normal(0, 1, (n_cust, 2))                    # де розташований кожен клієнт
quirk = rng.random(n_cust) < 0.25                       # чверть поводиться нетипово
label = (home[:, 0] + home[:, 1] > 0) ^ quirk           # узагальнювана частина + примха

customer = np.repeat(np.arange(n_cust), per_cust)
X = home[customer] + rng.normal(0, 0.05, (n_cust * per_cust, 2))
y = label[customer].astype(int)

def nearest_neighbour(train, test):
    d = ((X[test][:, None, :] - X[train][None, :, :]) ** 2).sum(-1)
    return np.mean(y[train][d.argmin(1)] == y[test])

rows = rng.permutation(len(customer))
random_split = np.zeros(len(customer), bool)
random_split[rows[:360]] = True                         # 20% рядків, урозкид

held_out = np.isin(customer, np.arange(240, 300))       # 20% клієнтів, цілком

print(f"random row split      accuracy {nearest_neighbour(~random_split, random_split):.3f}")
print(f"grouped by customer   accuracy {nearest_neighbour(~held_out, held_out):.3f}")

random row split      accuracy 0.808
grouped by customer   accuracy 0.631

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

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

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

Типові помилки

Оптимізація метрики, яку ніхто не обирав свідомо. Класика — точність на незбалансованій задачі: модель може бути чудовою за цією мірою й непридатною. Обирайте метрику на етапі формулювання [1, Rule 2].

Розбіжність навчання й обслуговування. Ознака, обчислена в блокноті, і ознака, обчислена в сервісі, тихо розходяться, і модель деградує без жодної помилки [1, Rule 37].

Незадекларовані споживачі. Хтось будує на виході вашої моделі, не сказавши вам, — і тепер ви не можете її змінити. Названо прямо серед механізмів боргу [2, abstract].

Сприймати розгортання як фініш. Світ, який описували навчальні дані, рухається далі; «зміни в зовнішньому світі» стоять у переліку ризиків саме тому [2, abstract]. Модель без моніторингу — це модель, про збій якої ви дізнаєтесь від користувача.

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