contract_sla:
service_uptime: 99.95%
api_latency_p99: 150ms
model_f1_score: ">= 0.85"
violation_penalty: 5000 USD / dayПосмотрите на этот кусок типичного приложения к контракту. Аптайм девятки, задержка по p99 жестко прописана, а следом идет наивная попытка натянуть бизнес-метрику на глобус машинного обучения. Любой юрист заказчика с радостью подпишет этот конфиг. Любой вменяемый техлид подрядчика должен швырнуть его обратно через стол. Ошибка здесь стоит миллионов. Формулировать SLA на ML-модель в договоре: какие метрики и штрафы вшивать, чтобы дрейф не остался безнаказанным — это не вопрос веры в алгоритм. Это вопрос управления энтропией. Модель деградирует всегда. Это закон природы.
Почему классический аптайм маскирует убытки
Обычный айтишный SLA гарантирует доступность железа и софта. Сервер отвечает кодом 200 за 150 миллисекунд. Инфраструктура зеленая, девопсы спокойны. Но если внутри крутится нейросеть, которая из-за смены сезона или новой маркетинговой акции начала отклонять 80% легальных транзакций, ваш идеальный API с аптаймом 99,95% просто с идеальной скоростью генерирует бизнесу убытки. Классический мониторинг здесь слеп. Ему плевать на смысл ответа.
| Критерий | Классический IT-SLA | ML-SLA в продакшене |
|---|---|---|
| Целевая метрика | Uptime, Latency (p90, p99), Error Rate | Precision/Recall, ROC AUC на скользящем окне |
| Триггер инцидента | 5xx ошибки, сетевые таймауты | Concept drift, Data drift, падение бизнес-метрик |
| Реакция на аварию | Перезапуск пода, откат релиза, хотфикс | Запуск MLOps-пайплайна ретрейна, shadow-режим |
| Гарантии в контракте | Жестко зафиксированы на весь срок | Действуют только при стабильном распределении данных |
Прописывать статичный F1-score или ROC AUC навсегда — юридическое самоубийство. Реальный мир меняется. Меняется поведение пользователей, макроэкономика, поставщики данных. Вы не можете гарантировать качество предикта, если заказчик выкатил новый интерфейс и сломал логирование критичной фичи. Распределение уехало. Модель выдает мусор. Кто за это платит?
Ответственность сторон: чьи данные, того и дрейф
В контракте необходимо жестко разделять ответственность за код подрядчика и данные заказчика. Базовое правило звучит так: инженеры гарантируют метрику только при условии сохранения распределения входных данных. В противном случае мы получаем ситуацию, когда клиент сменил CRM-систему, формат логов поменялся, а штрафы за падение конверсии летят в разработчиков нейросети.
Для защиты мы вшиваем в договор технические пороги дрейфа данных. На практике это вычисляется через дивергенцию Кульбака-Лейблера или расстояние Вассерштейна на ключевых признаках. Мы фиксируем слепок данных на момент приемки модели. Если отклонение входящего потока в проде превышает договорной порог, SLA на качество предикта ставится на паузу. Метрика летит в стену. Ответственность переходит на сторону процессов переобучения. Заказчик оплачивает вычислительные мощности для ретрейна, если дрейф произошел по вине внешних факторов или изменений на его стороне. Если же модель деградировала на статических данных из-за ошибки в архитектуре или переобучения (overfitting) на старте — ретрейн идет за счет исполнителя.
Изолированный мониторинг как единственный источник истины
Считать метрику в вакууме бессмысленно. Истинные значения (ground truth) всегда приходят с задержкой. Вы заблокировали транзакцию сегодня, а чарджбек от платежной системы или ручное подтверждение от службы безопасности придет через месяц. Заказчик видит падение выручки и хочет штрафовать вас сейчас. Вы требуете дождаться разметки. Конфликт.
Решение кроется в использовании прокси-метрик и жестко согласованном источнике истины. Источником истины не может быть дашборд заказчика, собранный аналитиком в Tableau по неизвестно каким правилам. Это должна быть изолированная колоночная база данных, например ClickHouse, куда синхронно сыплются сырые векторы признаков, отданные предикты и, по мере появления, отложенная разметка. Контракт фиксирует конкретный SQL-запрос. Этот запрос вычисляет метрику по скользящему окну, например, в четырнадцать дней. Окно двигается каждый час. Как только окно показывает деградацию ниже согласованного порога, включается регламент эскалации.
Штрафы за время реакции, а не за энтропию
Штрафовать за сам факт падения метрики глупо. Модели устаревают, это нормальный жизненный цикл. Штрафовать нужно за нарушение SLA на реакцию. Это единственный рабочий трейд-офф. Как только мониторинг зафиксировал пробитие порога по дрейфу или падение precision ниже критической отметки, запускается таймер.
У подрядчика появляется заранее согласованное окно. Обычно это от 24 до 72 часов на доставку переобученного кандидата по стратегии champion-challenger и запуск A/B-теста на живом трафике. Если пайплайн автоматизирован правильно, это занимает часы машинного времени. Если вы делаете это руками в Jupyter-ноутбуках, вы будете стабильно проваливать сроки и платить неустойку. Штраф начисляется за каждый час задержки сверх регламентного окна обновления. Время простоя стоит денег. Нарушение обязательств по восстановлению системы стоит денег. Все прозрачно.
Мы у себя в MoranaLabs не подписываем контракты с фиксированной точностью предсказаний на годы вперед. Мы подписываем SLA на инфраструктуру непрерывного обучения. Наш MLOps-пайплайн гарантирует, что при смещении распределения детектор дрейфа сработает автоматически, а пайплайн выкатит свежую нейросеть в shadow-режим быстрее, чем бизнес заметит просадку в деньгах. Гарантировать нужно не победу над временем, а скорость адаптации к нему.