Алексей Бобрешов защитил диплом по «умному дому» в 2021 году с нейросетью, показавшей точность 94,06%. Проект в коммерческую эксплуатацию не вышел — остался proof of concept, который автор проверял дома. Зато последующие годы работы над реальными ИИ-проектами дали материал для семичастной серии, последняя глава которой посвящена инфраструктуре, MLOps и масштабированию.
Центральный тезис серии: обучение модели — меньшая часть работы. Отраслевая оценка «20 на 80» (20% — разработка модели, 80% — всё остальное) подтверждается практикой. Прототип живёт в идеальных условиях: чистые данные, один пользователь, никакой нагрузки. Продакшн — это валидация входящих данных, таймауты, структурированное логирование и обработка отказов. Разница между двумя строками кода и полноценным классом с валидацией, логгером и обработкой исключений — это и есть разница между демо и системой.
| Этап | Инструменты | Проблемы | Решение |
|---|---|---|---|
| Прототип | Jupyter, Colab, локальные данные | Нет версионности и воспроизводимости | Git + DVC |
| Пилот | Docker, Flask, ручной деплой | Нет автоматизации, сложно откатывать | CI/CD |
| Продакшн | Kubernetes, MLflow, Prometheus | Мониторинг, дрейф моделей | Полноценный MLOps |
Бобрешов выделяет три ошибки, которые встречаются чаще всего. Первая — уверенность, что код, работающий на ноутбуке, заработает в проде без изменений. Вторая — игнорирование дрейфа данных: модель распознавания голосовых команд, обученная на лабораторных записях, деградирует в реальной среде из-за акцентов, фонового шума и других микрофонов. Код при этом не меняется — меняется распределение входных данных. Для измерения этого смещения используется индекс стабильности популяции (PSI): значение ниже 0,1 означает стабильное распределение, от 0,1 до 0,25 — умеренный дрейф, выше 0,25 — сигнал к переобучению. Третья ошибка — отладочный вывод print() вместо мониторинга: при единицах пользователей он ещё терпим, при масштабировании превращается в слепое пятно.
Три главные ошибки перехода: код, работающий только локально; игнорирование дрейфа данных; отладочный print() вместо полноценного мониторинга.
Архитектурный ответ на эти проблемы — паттерн «обёртки продакшена». Модель остаётся ядром системы, но перед ней и после неё выстраиваются слои: валидация входа, rate limiting, circuit breaker, контроль таймаутов, fallback-стратегия, валидация выхода, логирование и сбор метрик. Такая обёртка превращает модель из исследовательского артефакта в эксплуатируемый сервис.
MLOps-стек эволюционирует вместе с командой. На этапе прототипа — ручные бэкапы, таблицы Excel для сравнения экспериментов, деплой одной командой python deploy.py и print() как единственный инструмент наблюдаемости. В продакшне — DVC и Git LFS для версионирования данных и моделей, MLflow или Weights & Biases для трекинга экспериментов, Kubernetes с ArgoCD для автоматизированного деплоя с поддержкой откатов и A/B-тестирования, Prometheus с Grafana и ELK-стеком для мониторинга, PyTest и Great Expectations для автоматического тестирования перед деплоем.
CI/CD-пайплайн для ML отличается от стандартного бэкендного тем, что между тестами и деплоем появляется этап обучения и оценки модели. Ключевой элемент — шаг с порогом качества: если новая версия модели не достигает заданного threshold (в примере — 0,95), она автоматически блокируется и не попадает в продакшн. Это дешевле любого инцидента в эксплуатации.
Метрики мониторинга автор делит на три уровня. Инфраструктурный — CPU, память, GPU, задержки на перцентилях p50/p95/p99, частота ошибок. Уровень модели — дрейф распределения предсказаний, распределение confidence-скоров, перекос классов. Бизнес-уровень — доля успешно выполненных команд, неявная обратная связь пользователей, стоимость одного предсказания. Первый уровень показывает, что система жива; второй — что модель работает корректно; третий — что вся конструкция приносит измеримую пользу.