Дрейф даних проти Дрейфу Концепцій: Як Моделі Машинного Навчання Припиняють Працювати Безшумно

Модель не падає гучно — вона падає тихо

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

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

Зміщення даних: форми входів змінилися

Зміщення даних виникає, коли статистичне розподілення однієї або кількох ознак вхідних даних у робочому режимі відхиляється від розподілу, на якому було навчено модель — наприклад, ознака "вік клієнта", яка раніше була зосереджена навколо 35 років, тепер зосереджена навколо 50 років через зміну маркетингової стратегії продукту або зміну валюти/цін у оновленні ціноутворення. Сама модель не змінювалася, і справжня основна залежність між ознаками та цільовою змін не відбулася, але модель тепер запитується на екстраполяцію в області простору ознак, в якій вона ніколи не була навчена, що зазвичай погіршує якість прогнозування навіть тоді, коли нічого не зламано у взаємозв’язку між цільовими змінними. Стандартним статистичним інструментом для виявлення цього є тест розподілів двох зразків, застосований до ознак по одній — порівнюється посилання (зазвичай дані навчання) з нещодавнім робочим вікном. Тест Колмогорова–Смілнова – це часто використовуваний варіант для числових ознак, оскільки він не робить жодних припущень щодо форми розподілу — він вимірює максимальну відстань між кумулятивними функціями розподілу посилання та робочого вікна і повертає p-значення. Низьке p-значення (зазвичай нижче 0,05) для певної ознаки сигналізує про те, що ознака зміщена, а виконання цього тесту для всіх ознак за розкладом (щоденно або щотижня) генерує звіт про зміщення, який можна автоматично переглядати або людиною перед прийняттям рішення щодо необхідності вжиття заходів.

Зсув концепції: сама взаємозв’язність змінилася”, “paragraphs”: [

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

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

Перетворення виявлення відхилень на тригер автоматичного перезатренування

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

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

Який сенс має інфраструктура моніторингу

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

Часті запитання

Спробуйте наживо

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