Аудит ML-системи перед масштабуванням: 12 запитань, які треба поставити

## Чому масштабування ML-систем провалюється Статистика невтішна: більшість ML-систем, що успішно пройшли MVP-стадію, стикаються з серйозними проблемами при масштабуванні. Причини рідко технічні в класичному розумінні: це не відсутність потужних серверів або недосконалі алгоритми. Проблеми виникають через технічний борг, накопичений при швидкій розробці, і організаційну неготовність. 12 запитань нижче — не формальний чеклист для галочки. Це карта потенційних проблем, кожна з яких при масштабуванні перетворюється на ризик простою, деградації якості або безпекового інциденту. ## Блок 1: Відтворюваність і версіонування ### Запитання 1: Чи можна відтворити будь-який production-run? Ідеальна відповідь: так, за 30 хвилин. Для цього потрібно: версіонований код у Git (включно з preprocessing pipeline), версіонований датасет (DVC або аналог), зафіксовані версії бібліотек (requirements.txt або conda environment), залоговані гіперпараметри (MLflow або W&B). Якщо відповідь «ні» або «залежить від того, хто був автором» — це перший блокер для масштабування. При збільшенні кількості моделей і команди без відтворюваності ви втратите контроль над тим, що саме деплоїться в production. ### Запитання 2: Чи версіонуються моделі? Не лише код, але й ваги моделей з метаданими: дата навчання, версія датасету, метрики на тест-вибірці, автор. MLflow Model Registry або аналог забезпечує lifecycle management: Staging → Production → Archived. При масштабуванні до десятків моделей без версіонування відкат після інциденту перетворюється на хаотичний пошук «якоїсь старої версії, що працювала». ### Запитання 3: Чи відсутній training-serving skew? Training-serving skew — ситуація, коли ознаки при навчанні обчислюються інакше, ніж при inference в production. Наприклад, при навчанні вік клієнта обраховувався відносно дати навчання, а в production — відносно поточної дати. Модель «бачить» різні дані. Feature store або документований preprocessing pipeline, що використовується як при навчанні, так і при serving — обов'язкова умова. ## Блок 2: Моніторинг і надійність ### Запитання 4: Чи моніториться якість моделі в реальному часі? Offline-метрики (accuracy на тест-вибірці) не відображають поточну якість в production. Потрібні: моніторинг розподілу вхідних даних (data drift detection), відстеження prediction distribution, бізнес-метрики (конверсія, відмови, клієнтські скарги). ### Запитання 5: Чи є алерти при деградації? Система сповіщень при перевищенні порогів — обов'язкова. Без алертів деградація якості може тривати тижнями непоміченою. PSI (Population Stability Index) понад 0.2 або падіння цільової бізнес-метрики більше ніж на 5% — типові пороги для алертів. ### Запитання 6: Чи витримує система пікове навантаження? Load testing перед масштабуванням — не опціональний. При збільшенні трафіку в 5-10 разів: чи зростає latency лінійно? Чи є механізм graceful degradation (fallback на простішу модель або cached predictions)? ## Блок 3: Безпека і compliance ### Запитання 7: Чи захищені sensitive дані в ML-pipeline? При масштабуванні ML-система обробляє більше даних і стає більш привабливою ціллю. Перевірте: шифрування даних у спокої і при передачі, обмеження доступу до training data і моделей (principle of least privilege), audit logs для всіх операцій з даними. ### Запитання 8: Чи відповідає система вимогам EU AI Act або GDPR? Для high-risk AI систем (кредитний скоринг, рекрутинг, медична діагностика) EU AI Act вимагає документації, тестування на упередженість і механізмів людського нагляду. Перевірте до масштабування, а не після. ### Запитання 9: Чи перевірена модель на bias і fairness? Дискримінація за захищеними ознаками (стать, вік, раса, географія) — юридичний і репутаційний ризик. Аудит справедливості моделі перед масштабуванням: Demographic Parity, Equal Opportunity, Calibration по підгрупах. ## Блок 4: Операційна зрілість ### Запитання 10: Чи є документований процес перенавчання? Моделі деградують. При масштабуванні потрібен чіткий процес: тригери перенавчання (drift alert, регулярний розклад, зміна бізнес-логіки), pipeline для автоматичного або напівавтоматичного перенавчання, критерії оцінки нової версії перед заміною production-моделі. ### Запитання 11: Чи є playbook для типових інцидентів? При масштабуванні зростає складність і кількість потенційних точок відмови. Задокументовані runbooks для типових сценаріїв: деградація якості моделі, data pipeline failure, API недоступний. Кожен runbook: симптоми, діагностика, рішення, ескалація. ### Запитання 12: Чи готова організація? Технічна готовність — лише половина успіху. Організаційні питання: чи є ML інженер на черговому дежурстві? Чи знають бізнес-стейкхолдери, як інтерпретувати алерти? Чи є SLA для відновлення після інциденту? ## Практичний план усунення прогалин Після проходження 12 запитань у вас буде карта проблем. Пріоритизація: Критичні (усунути до масштабування): відсутність training-serving skew контролю, відсутність моніторингу якості, незахищені sensitive дані. Важливі (усунути протягом першого місяця масштабування): відсутність automated retraining pipeline, брак incident playbooks, незафіксовані версії бібліотек. Бажані (дорожня карта наступного кварталу): повний fairness audit, feature store, automated load testing у CI/CD. Масштабування без аудиту — ризик. Але аудит без конкретного плану дій — марна витрата часу. Документуйте знахідки, пріоритизуйте і виправляйте послідовно.