# Эндрю Ын: «Развертывание модели — это не конец, а начало итерации» Источник: https://www.youtube.com/watch?v=hq_XyP9y0xg Канал: DeepLearning.AI Опубликовано: 21.04.2022 --- Внедрение модели машинного обучения в эксплуатацию — это не финальная точка, а начало нового циклического процесса. В рамках курса по MLOps от DeepLearning.AI рассматриваются лучшие практики мониторинга развернутых систем, позволяющие вовремя обнаружить деградацию точности или технические сбои. Ключевая идея лекции заключается в том, что эффективный мониторинг строится на итеративном подборе метрик, специфичных для конкретной прикладной задачи. ## 📊 Мониторинг как стратегия: от дашбордов до поиска проблем [[JUMP:0:00]] Самым распространенным инструментом контроля за состоянием ML-системы является использование визуальных дашбордов для отслеживания показателей во времени [0:13]. Однако выбор того, что именно выводить на графики, не должен быть случайным. Эндрю Ын рекомендует начинать проектирование системы мониторинга с мозгового штурма внутри команды [1:06]. Порядок действий при выборе метрик: * Собраться командой и обсудить все возможные сценарии того, что может пойти не так. * Для каждой потенциальной проблемы определить статистику или метрику, которая позволит ее обнаружить [1:19]. * На начальном этапе развертывания использовать широкий набор метрик, постепенно отсеивая те, что окажутся неинформативными [1:45]. Примером может служить резкий скачок трафика, который приведет к перегрузке сервиса. В этом случае ключевым индикатором станет загрузка сервера (server load) [1:31]. Если же речь идет о структурированных данных, критически важно отслеживать долю пропущенных значений (missing values): любое изменение в этом показателе может означать, что формат или источник входных данных изменился [0:53]. ## 🖥 Программные и статистические показатели здоровья [[JUMP:1:58]] Все метрики мониторинга можно разделить на две большие группы. Первая — это чисто программные показатели (software metrics), которые помогают следить за здоровьем инфраструктуры, на которой запущен алгоритм [1:58]. К ним относятся: * Использование памяти (Memory); * Вычислительная нагрузка (Compute); * Задержка (Latency); * Пропускная способность (Throughput); * Загрузка сервера (Server load) [2:12]. Вторая группа — это показатели статистического здоровья модели, которые Эндрю Ын разделяет на метрики входных данных ($X$) и метрики выходных данных ($Y$). ### Метрики входных данных (Input metrics) [[JUMP:2:38]] Они позволяют понять, изменилось ли распределение данных, поступающих на вход модели. В системе распознавания речи (speech recognition) лектор советует мониторить среднюю длину аудиоклипа в секундах и среднюю громкость входящего сигнала [3:05]. Если эти параметры меняются, качество работы алгоритма может снизиться. В задачах визуального контроля на производстве (visual inspection) важно следить за яркостью изображений, так как изменение условий освещения в цеху напрямую влияет на точность распознавания дефектов [3:31]. ### Метрики выходных данных (Output metrics) [[JUMP:3:45]] Эти показатели помогают косвенно оценить качество работы модели без наличия эталонной разметки в реальном времени. Примеры индикаторов проблем: * **Доля пустых результатов:** если система распознавания речи стала слишком часто возвращать пустую строку (null), это признак сбоя [3:57]. * **Повторные поисковые запросы:** если в голосовом поиске пользователь дважды подряд вводит почти один и тот же запрос, вероятно, система не поняла его в первый раз [4:11]. * **Переключение на ручной ввод:** когда пользователь начинает использовать клавиатуру после неудачной попытки голосового ввода, это явный сигнал о разочаровании в работе ИИ-сервиса [4:37]. * **CTR (Click-through rate):** общая бизнес-метрика, падение которой в веб-поиске может свидетельствовать о деградации системы в целом [4:50]. ## 🔄 Итеративный цикл развертывания [[JUMP:5:16]] Эндрю Ын подчеркивает, что процесс развертывания (deployment) так же итеративен, как и обучение модели [5:30]. В процессе обучения цикл состоит из тренировки, анализа ошибок и изменения данных/модели. В продакшене цикл выглядит иначе: запуск системы позволяет получить реальный трафик, анализ которого дает данные для обновления системы мониторинга и самой модели [6:12]. По словам лектора, на практике требуется несколько попыток, чтобы прийти к правильному набору метрик [6:38]. Нередко бывает, что спустя пару недель эксплуатации обнаруживается проблема, которую никто не предвидел — тогда команда добавляет новую метрику. И наоборот: если какой-то показатель не меняется неделями и не несет пользы, от него отказываются, чтобы не рассеивать внимание [7:06]. ## 🔔 Пороги тревоги и обслуживание моделей [[JUMP:7:20]] Выбрав метрики, необходимо установить пороги срабатывания алертов (alarms). Например, если загрузка сервера превышает 0.91, система должна уведомить команду, чтобы те могли запустить дополнительные серверы [7:20]. Аналогично выставляются границы для доли пропущенных значений или пустых выходов модели [7:46]. Если мониторинг выявил проблему, решение зависит от её природы: 1. Проблемы в программной части требуют исправления кода или настройки инфраструктуры [8:12]. 2. Проблемы с точностью предсказаний требуют обслуживания (maintenance) или переобучения модели [8:26]. ### Ручное против автоматического переобучения [[JUMP:8:54]] Существует два подхода к обновлению моделей в продакшене. Эндрю Ын отмечает, что на текущий момент ручное переобучение встречается гораздо чаще, чем полностью автоматическое [9:08]. При ручном подходе инженер переобучает модель, проводит анализ ошибок и проверяет качество новой версии перед заменой. Разработчики часто проявляют осторожность и не готовы полностью доверять алгоритмам процесс автоматического обновления «вслепую», за исключением некоторых областей в потребительском ПО и интернет-сервисах [9:22]. В завершение лектор подчеркивает, что только постоянный мониторинг позволяет вовремя заметить необходимость глубокого анализа ошибок или сбора дополнительных данных для поддержания производительности системы на должном уровне [9:47].