Логирование для ML
Тема дорожной карты · MLOps
Структурированное логирование в ML-системах выходит за рамки прикладных логов: оно фиксирует метрики обучения, события data pipeline и пары запрос/ответ при inference. В процессе обучения записывайте loss-кривые, нормы градиентов и загрузку оборудования в централизованное хранилище (ELK, Loki или Cloud Logging). При inference логируйте входные данные, предсказания и задержку для обнаружения drift и отладки — применяйте sampling и PII-скраббинг для контроля объёма и соблюдения требований по данным. Используйте структурированный JSON с консистентными полями (model_version, request_id, latency_ms) и коррелируйте логи с трейсами (OpenTelemetry) для диагностики сбоев pipeline.
Как это работает
Логирование для ML для ML: отслеживайте data drift (input distribution меняется — Evidently, NannyML, Arize), model drift (predictions distribution сдвигается — может быть drift или реальное изменение мира), performance (live accuracy vs ground truth когда доступна — обычно с задержкой), system metrics (latency, throughput, errors), business metrics (то, что модель должна улучшать). Alerting: не "model accuracy < 80%" (не узнаете неделями) а "input feature X distribution сдвинулся > N stddev" или "prediction class mix сдвинулся > 10%".
Когда применять
Постройте drift detection до запуска — как только в prod, данные начинают меняться. Статистические тесты (KS, PSI, chi-squared) с разумными thresholds. Сочетайте drift-алерты с бизнес-метриками — distribution drift без business impact = шум. Расследуйте каждый alert — silent thresholds порождают false confidence.
Типичные ошибки
Ловушки Логирование для ML: только system metrics (latency зелёная, модель сломана); alert на абсолютную accuracy (нет ground truth в realtime); слишком tight thresholds → alert fatigue; нет плана "data drift, что дальше" (alerts без runbooks = шум).