Архитектура

MLOps для оператора: модели в проде, а не в Jupyter

У большинства операторов десятки моделей в эксплуатации, и нет дисциплины их обновлять, мониторить, откатывать. MLOps — операционный контур моделей.

Обсудить задачу

Зачем оператору отдельный MLOps контур

Типичный оператор имеет 15-30 ML-моделей в эксплуатации: churn, propensity, fraud, credit risk, NBA, recommendation, anomaly detection. Большинство — обучены 1-3 года назад data science командой, потом «деплоены» через непонятную процедуру и теперь работают в продакшене с медленно деградирующей точностью.

MLOps — операционный контур, который превращает модели из академического артефакта в управляемый production-component с lifecycle, governance и observability.

Без MLOps:

Модели не переобучаются (никто не знает, как).
Модели не мониторятся (никто не знает, что точность упала).
При выявлении bias невозможно быстро откатить.
Каждая новая модель — заново герой-проект.

Структурные элементы

Feature store. Централизованное хранилище фичей с версионированием. Одна и та же фича доступна для training (offline) и inference (online), с гарантией консистентности.

Model registry. Хранилище моделей с версиями, метаданными (training data, hyperparameters, metrics), статусом (development, staging, production, archived).

Training pipeline. Reproducible — данные → preprocessing → training → evaluation → registry. Запускается по schedule или по trigger (data drift detected).

Deployment. Стандартизированный путь от registry в production: shadow mode → canary → full traffic. С автоматическим rollback при performance regression.

Monitoring. Live метрики: prediction distribution, feature distribution drift, model accuracy (когда есть ground truth), business KPI (uplift, conversion).

Governance. Approval workflow для деплоя в продакшен, audit trail (кто что задеплоил), explainability layer для regulator-facing моделей.

Где обычно ломается

Train-serve skew. Фичи, использованные при training, считаются по-другому в production (другая система, другая логика). Модель работает не так, как тестировалась.

Модели — в Jupyter. Data scientist обучил модель в notebook, передал «коллегам» pickle файл, никто не помнит, как воспроизвести. Через год модель устарела, нет возможности обновить.

Деплой — через ticket в IT. Каждое обновление модели — недели согласований. Команда перестает обновлять, модели стареют.

Нет monitoring. Модель в проде год, никто не смотрит на её точность. Когда замечают — точность упала на 30%, и никто не знает с какого момента.

Нет registry. Модель «вот эта в production» — это файл на каком-то сервере, который один человек знает где. Текучка кадров — модель потеряна.

Bias не проверяется. Модель отказывает в credit-offer людям из определённых регионов. Через год — претензии regulator.

Operating model

Owner — Head of ML / Head of Data Science с инфраструктурным mandate. Не отдельная data science команда, не отдельный DevOps — функция на стыке.

Команды:

ML platform (feature store, registry, deployment infra)
Data science (модели, эксперименты)
ML engineering (production-ready code, integration)
ML governance (approval, audit, fairness)

Routine — еженедельный обзор production моделей: drift, accuracy, business KPI.

Что меряется

Time from idea to production — сколько занимает путь от гипотезы до live model. Целевой показатель — недели, не месяцы.

Number of models in monitored production. Без monitoring — не считаются.

Drift incidents per quarter — сколько раз обнаружен significant drift, как быстро среагировали.

Model rollback time — сколько занимает откат деградировавшей модели.

Business uplift per model — какой бизнес-эффект конкретно эта модель приносит.

Как SamaraliSoft подключается

MLOps Blueprint — 8-10 недель. Inventory existing моделей, текущая боль, дизайн target architecture (feature store, registry, deployment), governance, choice of stack (open-source vs managed: Vertex AI, SageMaker, Databricks). Pilot — взять одну модель и провести её через full lifecycle.