Чому ML-прототипи не доходять до продакшену: сім причин

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

Жодна з них не стосується архітектури моделі. Саме цю частину більшість команд робить добре — вона цікава й добре описана в літературі. Нижче — усе інше.

1. Немає набору для оцінювання, є лише відчуття

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

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

2. Конвеєра даних із прототипу в продакшені не існує

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

3. Затримка не була вимогою, тому її ніхто не міряв

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

Названий на старті бюджет змінює вибір моделі — саме тому йому місце на початку, а не в кінці.

4. Ніхто не відповідає за те, що буде, коли модель помиляється

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

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

5. Вартість інференсу з’ясовується з рахунку

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

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

6. Немає шляху до наступної версії

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

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

7. Моніторинг стежить за серверами, а не за моделлю

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

• Дрейф розподілу вхідних даних відносно навчальної бази
• Зсув розподілу передбачень — він часто рухається раніше за точність
• Відкладена точність, виміряна після появи фактичних результатів
• Частота виправлень людиною — найдешевше раннє попередження, яке в більшості команд уже є і яке ніхто не рахує

Спільна закономірність усіх семи

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

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