Как следить за моделью в продакшене: дрейф, качество, откат

Следить за моделью нужно на четырёх слоях: работает ли сервис, не изменились ли входные данные, не изменились ли ответы и верны ли они. Первые три слоя считает машина без участия человека. Четвёртый требует правильных ответов, а они приходят поздно или не приходят вовсе, поэтому его собирают из выборочной проверки людьми и сигналов от пользователей. К каждому слою привязаны порог, адресат оповещения и готовый откат.

Что такое MLOps в целом, описано в статье «Что такое MLOps простыми словами». Здесь только эксплуатация: какие графики заводить, когда они означают беду и что делать дальше. Услуга описана на странице «MLOps и развёртывание моделей».

Четыре слоя мониторинга: что измеряем и кто смотрит

Типичная ошибка: у модели есть мониторинг сервера (процессор, память, задержка), и на этом всё. Сервер здоров, модель ошибается, и о проблеме узнают от пользователей. Слоёв четыре, и каждый отвечает на свой вопрос.

Первые два слоя дёшевы и должны быть в первый день. Третий добавляется вместе с выкаткой: достаточно сохранять выход модели и раз в сутки считать несколько чисел. Четвёртый дорог, потому что требует людей, поэтому его проектируют отдельно (см. ниже). Если бюджет ограничен, начните с выхода и с выборочной проверки: именно они ловят деградацию раньше всего.

Виды дрейфа и что с ними делать

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

Поломка источника встречается чаще, чем кажется, и дороже всего обходится, когда её принимают за дрейф и переобучают модель на сломанных данных. Поэтому порядок такой: сначала проверка входа, потом сравнение распределений, и только затем разговор о новой версии. Для сравнения распределений достаточно простых статистик по признакам: доли категорий, квантили, индекс стабильности популяции или критерий Колмогорова — Смирнова. Главное не метод, а то, что сравнение идёт с зафиксированным эталоном.

Как оценивать качество, когда правильных ответов ещё нет

Правильный ответ часто становится известен через недели: заказ состоится или нет, оборудование откажет или нет, заявка закроется с другой категорией. Ждать нельзя, поэтому качество собирают из нескольких источников, и ни один не заменяет остальных.

• Выборочная проверка людьми. Каждую неделю человек получает небольшую случайную выборку ответов и отмечает верные и неверные. Выборка достаточна, чтобы заметить сдвиг, но мала для точной оценки; её нужно брать и из уверенных ответов, и из неуверенных.
• Исправления операторов. Если оператор меняет результат модели, это бесплатная разметка. Её нужно сохранять в хранилище с первого дня, вместе с версией модели.
• Сигналы пользователей. Жалобы, повторные обращения, отмена результата. Это грубый, но быстрый признак.
• Отложенная правда. Когда приходит фактический исход (оборудование отказало, заказ выкуплен), его сопоставляют с ранее сделанным предсказанием. Для этого предсказания хранятся с идентификатором объекта и временем.
• Контрольный набор. Фиксированная размеченная выборка, на которой прогоняют каждую версию перед выкаткой. Она не заменяет живой мониторинг, но показывает, что новая версия не хуже старой.

Качество на контрольном наборе и качество в бою различаются, и это нормально: набор устаревает вместе с данными. Если разрыв растёт, контрольный набор пора обновить, а не игнорировать мониторинг. Как собрать выборку и какие метрики считать, разобрано в статье «Как измерить точность распознавания документов»; те же принципы подходят и для других моделей.

Пороги и оповещения: как не утонуть в ложных тревогах

Оповещение, на которое никто не реагирует, хуже его отсутствия: люди учатся его игнорировать. Поэтому пороги задаются по правилам, а не по настроению.

1. Эталон берётся из приёмки. Распределения входов и выходов, зафиксированные в период испытаний, служат точкой отсчёта. Эталон хранится рядом с версией модели.
2. Порог привязан к цене ошибки. Для задачи, где ошибка стоит недорого, допускается заметный дрейф; для задачи, где ошибка ведёт к простою линии или неверной отгрузке, порог строже. Его определяет владелец процесса, а не разработчик.
3. Окно усреднения шире шума. Один плохой час не повод для тревоги. Сигнал строится по скользящему окну: сутки для потоковых задач, неделя для редких.
4. Два уровня. Предупреждение уходит в отчёт, критическое оповещение — человеку. Критических сигналов должно быть мало, иначе они перестанут быть критическими.
5. У каждого сигнала есть адресат и действие. В описании оповещения записано, что делает получатель: проверяет источник, переключает на правило, собирает внеплановую выборку.

Круглосуточной смены у нас нет, и если ваш процесс требует реакции ночью, это решается на вашей стороне: оповещение уходит дежурному у вас, а откат запускается одной командой по инструкции. Пакеты сопровождения описаны на странице «Сопровождение ПО».

Откат: четыре способа вернуться к рабочему состоянию

Откат готовят до выкатки. Если он впервые проверяется в момент аварии, это лотерея. Нужны версии модели, версии данных обработки и переключатель между ними.

Откат должен быть проверен вместе с данными, которые модель получает на входе. Версия модели, которой нужна другая обработка признаков, не заработает на текущем входе, если обработка тоже не откатилась. Поэтому версии модели и обработки хранятся вместе. Правило об откате записывается заранее: при каком сигнале и кто принимает решение, чтобы в аварии не искали ответственного. Почему многие пилоты не доходят до эксплуатации именно из-за отсутствия такого регламента, разобрано в статье «Почему ИИ-пилоты не доходят до продакшена».

Чем отличается мониторинг языковой модели

У приложения на языковой модели (ассистент, поиск по документам, извлечение полей) нет привычной метрики точности. Вместо неё используются другие измерения.

• Набор контрольных вопросов. Размеченный список запросов с ожидаемыми ответами или критериями. Его прогоняют при каждом изменении промпта, модели или базы знаний и сравнивают с предыдущим результатом.
• Качество поиска отдельно от качества ответа. Если система ищет фрагменты и по ним отвечает, нужно измерять, нашлись ли нужные фрагменты, и только потом, верно ли ответила модель. Ошибка чаще сидит в поиске. Устройство описано в статье «Архитектура LLM-приложения».
• Версия внешней модели. Если используется внешний программный интерфейс, провайдер может обновить модель, и ответы изменятся без вашего участия. Для данных ограниченного доступа такие модели чаще не подходят по требованиям заказчика, а у модели на вашем сервере версия зафиксирована вами.
• Журнал запросов и ответов. Он нужен для разбора спорных случаев, но содержит данные пользователей, поэтому хранится на ваших серверах с ограничением доступа и сроком хранения.
• Доля ответов «не знаю». Резкий рост означает, что база знаний устарела или поиск сломан; резкое падение — что модель стала отвечать на всё подряд.

Порог уверенности и поведение при незнании разобраны в статье «Порог уверенности модели», а защита от вредных запросов — в статье «Чек-лист безопасности LLM перед запуском».

Мониторинг только на бумаге: признаки

Мониторинг можно нарисовать на схеме и не получить пользы. Вот признаки, что именно это произошло:

Минимум на первую неделю после запуска

Полноценная платформа нужна не всем. Для одной-двух моделей достаточно набора, который собирается за несколько дней:

1. Сохранять каждый запрос и ответ вместе с версией модели и временем.
2. Проверять вход: обязательные поля, диапазоны, формат; при нарушении отказывать с понятным сообщением.
3. Раз в сутки считать несколько чисел: размер потока, доля пропусков, распределение предсказаний, доля неуверенных ответов.
4. Раз в неделю отправлять человеку случайную выборку ответов на проверку и считать долю верных.
5. Сохранять исправления операторов в отдельную таблицу с версией модели.
6. Хранить предыдущую версию модели и инструкцию возврата на неё; один раз проверить возврат на тестовом стенде.
7. Записать пороги и адресатов оповещений на одной странице вместе с эталоном приёмки.

Это не заменяет MLOps-платформу, но закрывает самые частые причины молчаливой деградации. Расширять набор имеет смысл, когда моделей больше пяти или они обновляются регулярно; о том, когда нужна платформа, сказано в статье про MLOps. Вопрос о том, когда модель стоит остановить, а не чинить, разобран в статье «Когда останавливать ИИ-пилот».

Что делаем мы и с чего начать

Начинаем с обследования: 200 000 ₽ и 2–3 недели за один-два процесса, 350 000 ₽ и 3–4 недели, если моделей и систем несколько. На выходе документ с метриками качества и порогами, схемой сбора правильных ответов, регламентом отката и списком того, что нужно собрать за первую неделю. Стоимость вычитается из первого этапа, если продолжаете с нами, а документом можно пользоваться и без нас.

Мониторинг строим в вашем контуре и передаём вместе с исходниками. Мы не продаём готовую платформу, не дежурим круглосуточно и не проводим аттестацию. Сопровождение помесячное: 20 000, 60 000 или 120 000 ₽ в месяц, сверх пакета 5 000 ₽ в час. Вывод пилота в эксплуатацию описан на странице «Вывод ИИ-пилота в продуктив», услуга — на странице «MLOps и развёртывание моделей». Все цены и сроки — на странице «Тарифы».