Работая с ML-моделями впервые, SRE-инженер может столкнуться с новыми трудностями и даже не распознать их. Причина этих трудностей кроется в отличии традиционных, привычных систем от систем с использованием ML-моделей. Главное отличие ML-системы от обычной — вероятностный подход. В привычном алгоритмическом подходе, если алгоритм написан верно, мы получаем необходимый нам результат, а если нет — ошибку. В случае с моделью может быть не только 5XX-ошибка или задержка ответа, но и «тихие» ошибки, которые необходимо правильно отслеживать, чтобы вовремя на них реагировать.
Именно поэтому для ML-систем уже недостаточно смотреть только на классические SRE-метрики вроде availability, error rate, p95/p99 latency и saturation. Эти метрики по-прежнему нужны, потому что инференс-сервис тоже может деградировать, как обычный сервис. Но в ML-системе этого мало: сервис может отвечать быстро, без 5XX-ошибок, а качество предсказаний уже ушло вниз. На практике это означает, что наблюдаемость ML-системы должна включать как минимум четыре уровня: состояние сервиса, качество входных данных, качество предсказаний и бизнес-эффект.
Пожалуй, самая частая из таких ошибок — различие между тем, как модель работала при обучении, и тем, как модель работает в продакшене. Это может происходить по двум причинам: изменение в пайплайне подготовки данных и естественный сдвиг распределения самих данных. Поскольку ML-модель по своей сути — это просто статистическая модель, то она критически зависит от распределения данных, на которых обучается и работает. Правильно выбрать данные для обучения — это работа не SRE-, а ML-инженера. «Правильно» в данном случае означает выбрать так, чтобы тренировочная выборка отражала генеральную совокупность данных. Качество модели измеряется ML-метриками на тестовой выборке. Тестовую выборку модель «не видит» при обучении.
Но в продакшене этого уже недостаточно. Для эксплуатации важно не только то, какую метрику модель показала на тестовой выборке, но и насколько входные данные, которые в реальности приходят в модель, похожи на обучающие: не сломался ли пайплайн признаков и не изменилась ли логика подготовки данных после релиза.
Мониторинг качества поступающих данных
Если модель обучена верно и показывает хорошую метрику на тестовой выборке, это вовсе не означает, что и в реальности она будет отрабатывать так же. Проблемы могут быть как в пайплайне подготовки данных, так и в смещении распределения самих данных с течением времени. На вход ML-модели поступают признаки какого-то наблюдаемого объекта. При этом у каждого признака есть своя важность. Очевидно, что при предсказании цены на квартиру удаленность от метро будет учитываться с бо́льшим весом, нежели цвет стен, хотя и последний может вносить свою лепту в итоговое предсказание. А теперь представим, что формула расчета удаленности от метро сломалась и в модель поступает неверное значение. Даже несмотря на то, что наша модель учитывала также число комнат, ремонт, количество санузлов и даже цвет стен, из-за поломки этого важного признака мы теперь получаем совсем другие предсказания.
Чтобы такую проблему заметить, нужны конкретные метрики по входным данным.
Первая базовая метрика — доля пропусков по признаку:
missing_rate(feature) = Число объектов с пустым значением / Общее число объектов
Если у важного признака missing rate был 0.1%, а после релиза стал 7%, это уже не «шум», а инцидент.
Вторая метрика — доля значений вне допустимого диапазона:
out_of_range_rate(feature) = Число значений вне бизнес- или технически допустимого диапазона / Общее число объектов
Для той же удаленности от метро можно заранее задать допустимый диапазон. Если вдруг начинают приходить отрицательные расстояния или значения в сотни километров для городских квартир, это повод немедленно проверять расчет признака.
Третья метрика — нарушения схемы:
schema_violation_count = число объектов, у которых тип, формат или количество полей не соответствует ожидаемому
Это особенно важно для продакшен-систем, где один сервис обновился, другой нет и на вход модели начали приходить строки вместо чисел или изменился набор полей.
Четвертая метрика — свежесть данных:
freshness_lag = Текущее время − Время последнего корректного обновления данных
Даже если данные формально валидны, они могут быть устаревшими. Это критично для антифрода, динамического ценообразования, рекомендаций и логистики.
Наконец, отдельно нужно отслеживать сдвиг распределения данных. Самый простой и практичный способ — считать drift-метрики по ключевым фичам. Например, PSI:
PSI = Σ((actual_i − expected_i) × ln(actual_i / expected_i))
Эту метрику обычно считают по бинам и сравнивают текущее окно продакшен-данных с обучающей или эталонной выборкой. В прикладной эксплуатации часто используют такую грубую интерпретацию: PSI до 0.1 — слабое изменение, 0.1–0.2 — заметное, выше 0.2 — существенный сдвиг, требующий внимания. Это не универсальный закон, а удобный стартовый порог.
Для SRE здесь важна не только сама метрика, но и реакция. Например:
- если missing_rate по критичной фиче вырос более чем в пять раз относительно обычного уровня и держится 10–15 минут, это paging;
- если out_of_range_rate вышел за 1–2% по важному признаку, нужен разбор последнего релиза ETL или feature пайплайн;
- если PSI по нескольким ключевым признакам одновременно стал выше 0.2, то это повод не только смотреть на данные, но и запускать проверку качества предсказаний на ближайшем доступном окне с разметкой.
Иными словами, мониторинг данных для ML — это не абстрактное «смотреть на вход», а вполне конкретный набор сигналов: пропуски, диапазоны, схема, свежесть и drift.
Отслеживание качества предсказаний
Чтобы понимать, «хорошо» или «плохо» работает модель, необходимо подобрать такую техническую метрику, которая будет адекватна текущей задаче. Если мы предсказываем смертельное заболевание, то, конечно, минимизируем ложноотрицательные предсказания, поскольку цена ошибки высока, а сделать дополнительные анализы в таких важных случаях не составит труда. Метрика измеряет разницу между предсказанным и истинным значением, поэтому подобрать адекватную поставленной задаче метрику — это лишь полдела. Нам также придется периодически оценивать поступающие данные вручную, чтобы было с чем сравнивать. Тут большой ошибкой может стать разметка данных с помощью другой модели. Лучше всего отдать разметку эксперту в той доменной области, для которой делается модель.
Но для продакшен-эксплуатации важно сразу зафиксировать, какими именно числами это качество измерять.
Если задача классификационная, базовый набор обычно такой:
recall = TP / (TP + FN)precision = TP / (TP + FP)F1 = 2 × Precision × Recall / (Precision + Recall)
Recall особенно важен там, где нельзя пропускать опасные случаи. Precision — там, где дорого тревожить людей лишний раз. F1 полезен как компромиссная метрика, когда нужен баланс.
Если модель выдает вероятности, а не просто класс, полезно смотреть не только на итоговое решение после порога, но и на качество самих вероятностей. Здесь полезны две метрики.
Первая — Brier score:
Brier = (1 / N) × Σ(y_i − p_i)^2
Она показывает, насколько предсказанные вероятности близки к реальности.
Вторая — ECE (Expected Calibration Error). Она показывает, насколько уверенность модели совпадает с фактической точностью. Это важно, потому что две модели могут иметь одинаковый AUC, но одна из них будет честно выдавать вероятность 0.8 там, где событие реально случается примерно в 80% случаев, а другая — систематически переоценивать или недооценивать риск.
Если задача регрессионная, например прогноз спроса или цены, разумно смотреть:
- на MAE = среднее абсолютное отклонение;
- RMSE = корень из средней квадратичной ошибки;
- MAPE = среднюю абсолютную процентную ошибку, если проценты действительно интерпретируемы для бизнеса.
Здесь тоже важно помнить: одна и та же ошибка может быть приемлемой в одной задаче и критичной в другой. Ошибка прогноза на 100 рублей для дешевого товара и для автомобиля — это разные по смыслу вещи.
Отдельная сложность продакшен-эксплуатации состоит в том, что истинные ответы часто приходят не сразу. Например, сегодня мы делаем предсказание оттока, а понять, верно оно или нет, сможем только через неделю. Именно поэтому качество модели в реальности часто приходится считать на «созревшем» окне, где разметка уже доехала. Это значит, что у команды должны быть два контура мониторинга:
- первый — оперативный, где мы смотрим на состояние сервиса, данные и распределение предсказаний;
- второй — quality-контур, где мы считаем accuracy, recall, MAE, Brier score и другие метрики только тогда, когда появился ground truth.
Еще одна полезная метрика для боевой эксплуатации — это доля изменений решения модели относительно предыдущей стабильной версии:
disagreement_rate = Число объектов, где новая и старая модель приняли разное решение / Общее число объектов
Эта метрика особенно полезна в shadow-режиме, когда новая модель уже крутится на реальном трафике, но еще не влияет на пользователей. Если disagreement rate резко высокий, а причины неочевидны, выкатывать такую модель в боевой режим рискованно даже при хороших офлайн-метриках.
Отслеживание бизнес-эффекта
Обзор метрик для отслеживания мы начали с уровня технических метрик, но проектирование эффективной ML-системы начинается именно с бизнес-метрик. Что мы хотим улучшить: повысить количество продаж определенного товара? увеличить маржинальность в конкретной категории? уменьшить число возвратов в том или ином регионе? Получив ответы на эти вопросы от бизнеса, мы можем выбрать технические метрики, которые будут верно соотноситься с бизнесом, и уже затем подобрать необходимую модель, которая максимизирует техническую метрику на тех данных, что имеются. На мой взгляд, именно бизнес-метрики — это самое важное, на что нам, инженерам, стоит обращать внимание. Система может работать верно, модели — выдавать адекватные предсказания, смещений распределений не будет, но бизнес-эффект от такой системы может угасать по независимым от нее причинам.
Проблема многих ML-проектов в том, что команда начинает обсуждение с accuracy или F1, хотя бизнесу нужны совсем другие ответы. Например:
- для рекомендательной системы это может быть uplift в CTR, conversion rate, average order value;
- для модели прогнозирования спроса — снижение out-of-stock rate, уменьшение списаний, снижение ошибки закупки;
- для антифрода — предотвращенный ущерб, скорость ручной проверки, доля ложных блокировок;
- для скоринга лидов — доля качественных лидов в работе отдела продаж и итоговая выручка на менеджера.
Именно поэтому в эксплуатации ML-системы полезно связывать технические и бизнес-метрики в одну цепочку. Например, ухудшение recall на 4 процентных пункта в антифроде может означать рост пропущенного ущерба. Рост MAE в прогнозе спроса может приводить к конкретному увеличению списаний. Падение калибровки вероятностей — к тому, что downstream-правила начинают принимать слишком агрессивные или, наоборот, слишком осторожные решения.
Для SRE это важно по одной причине: инцидент в ML-системе не всегда проявляется как падение сервиса. Иногда первым сигналом становится не latency, а просадка конверсии, рост возвратов или увеличение доли ручной обработки. Именно поэтому нормальная эксплуатация ML невозможна без дашбордов, где рядом живут технические и бизнесовые показатели.
Что считать минимально необходимым контуром наблюдаемости
На практике даже для относительно простой ML-системы стоит считать как минимум следующий набор метрик.
На уровне сервиса:
- availability;
- error rate;
- p95/p99 latency;
- queue length или saturation.
На уровне входных данных:
- missing_rate;
- out_of_range_rate;
- schema_violation_count;
- freshness_lag;
- drift-метрики по ключевым признакам, например PSI.
На уровне предсказаний:
- распределение score или probability;
- disagreement_rate между текущей и эталонной моделью;
- доля fallback-решений;
- доля ручной обработки после модели.
На уровне истинного качества:
- recall/precision/F1 для классификации;
- MAE/RMSE для регрессии;
- Brier score и ECE для вероятностных моделей.
На уровне бизнеса:
- Conversion uplift, снижение возвратов, экономический эффект, скорость процесса, маржинальность или другая прикладная метрика, ради которой модель вообще была внедрена.
Такой набор уже позволяет перейти от разговоров «кажется, модель стала работать хуже» к разговору «у нас с 14:20 вырос missing rate по критичной фиче, через два часа просел recall на созревшем окне, а еще через день это выразилось в росте ручных проверок на 18%».
Сценарии реакции на деградацию
Зрелая эксплуатация ML-систем строится вокруг управления риском. Нужны понятные SLA не только на аптайм, но и на качество модели, заранее определенные пороги деградации и сценарии реакции: откат версии, отключение фичи, переход на ручную проверку.
Если проблема в инфраструктуре, то это обычный SRE-инцидент: масштабирование, разбор очередей, деградация latency, поиск узкого места.
Если проблема в данных, нужен отдельный runbook:
- Проверить последние изменения в ETL и preprocessing.
- Проверить схему, диапазоны и пропуски.
- При необходимости откатить пайплайн признаков.
- Отключить поврежденную фичу или перейти на безопасный fallback.
Если проблема в качестве модели, а сервис при этом технически здоров, сценарий другой:
- Остановить rollout новой версии.
- Включить shadow-режим или вернуть предыдущую модель.
- Временно перевести часть решений на ручную проверку.
- После прихода разметки подтвердить масштаб деградации на созревшем окне.
- Решить, нужен ли retraining, перекалибровка порога или переработка признаков.
Если деградирует бизнес-эффект, а технические и ML-метрики выглядят нормально, это не повод игнорировать проблему. Возможно, изменился сам бизнес-контекст: сезонность, поведение пользователей, канал трафика, ассортимент, правила downstream-системы. В этом случае инцидент уже нельзя решать силами только SRE- или только ML-команды.
Вывод
Конкретные практики и методы решения проблем, возникающих при эксплуатации ML-моделей, действительно описываются термином MLOps. Но для SRE в прикладном смысле важнее не сам термин, а то, что именно нужно наблюдать и как на это реагировать.
ML-система — это не просто сервис, который должен отвечать без ошибок. Это система, где одновременно могут деградировать данные, инфраструктура, предсказания и бизнес-результат. Именно поэтому зрелая эксплуатация ML-систем строится вокруг управления риском. Нужны понятные SLO не только на аптайм, но и на качество данных, качество модели и бизнес-эффект. Нужны заранее определенные пороги деградации и сценарии реакции: откат версии, отключение фичи, переход на ручную проверку, freeze risky-изменений, запуск повторного обучения или пересмотра пайплайна.
ML-система — это живой процесс, требующий постоянного контроля и ответственности. И чем раньше команда начнет измерять не только latency и 5XX-ошибки, но и missing rate, drift, recall, calibration и бизнес-эффект, тем меньше будет «тихих» инцидентов, которые формально не ломают сервис, но уже ломают результат.
