Feature store, model registry и «все эти MLOps штуки» — зачем, если вы не Google

Типичная сцена. DS-лид приходит к руководству и говорит: нам нужен model registry, нормальный пайплайн переобучения, мониторинг моделей, в идеале — feature store. Руководство слушает, кивает и отвечает примерно так: «У нас три модели в проде и пять человек в DS-команде. Это всё для Google и Netflix. Давайте лучше ещё одну модель сделаем — бизнес ждёт».

Логика понятная. Feature store, CI/CD для моделей, registry — звучит как тяжёлая инфраструктура, которая оправдывает себя при сотнях моделей и тысячах инженеров. Зачем это маленькой команде?

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

MLOps нужен не для масштаба. Он нужен, чтобы не потерять контроль над тем, что уже работает. И «минимальный MLOps» — это не инфраструктура Google, а несколько конкретных практик, которые можно внедрить за недели, а не за кварталы.

Модель в проде — это не статичный артефакт. Это живой компонент, который зависит от данных, окружения, бизнес-контекста и людей. Когда вокруг модели нет инфраструктуры, деградация — вопрос не «если», а «когда».

Сценарии, которые я наблюдал десятки раз, укладываются в три категории.

Тихая деградация. Данные постепенно смещаются: меняется сезон, ассортимент, поведение пользователей. Модель формально работает, но качество падает неделю за неделей. Бизнес замечает проблему через месяцы — когда KPI уже просели и доверие к «этому вашему ML» подорвано.

Внезапный сбой. Один из источников данных перестал отвечать, поменял формат или начал отдавать пустые значения. Модель получает мусор на вход и выдаёт мусор на выход. Если нет проверки входных данных — это обнаруживается, когда клиенты начинают жаловаться или когда закупки принимают решения на основе бессмысленных прогнозов.

Организационная потеря. Человек, который строил модель, ушёл. Или перешёл на другой проект. Вместе с ним ушли знания: какие данные использовались, почему выбраны эти фичи, как именно запускать переобучение, какие есть известные ограничения. Модель превращается в чёрный ящик, к которому никто не решается прикасаться.

Общий знаменатель у всех трёх сценариев — отсутствие воспроизводимости и контроля. Не потому что команда плохая, а потому что инфраструктура для этого не была заложена.

Когда люди слышат «MLOps», в голове рисуется картинка: Kubeflow, Vertex AI, managed feature store за десятки тысяч долларов в месяц, dedicated ML platform team из десяти инженеров, Kubernetes-кластер с auto-scaling. Для большинства компаний это звучит как параллельная реальность — и справедливо.

Но MLOps — это не набор конкретных инструментов. Это набор принципов: воспроизводимость, контроль версий моделей и данных, мониторинг, автоматизация рутинных операций. И реализовать их можно на любом стеке — от managed-платформы до git-репозитория и пары bash-скриптов.

Полезно разделить всё на два уровня. Первый — то, что нужно всем, даже если у вас одна модель в проде. Это минимум, без которого вы теряете контроль: model registry, воспроизводимость обучения, базовый мониторинг. Второй — то, что становится нужным при росте: feature store, полноценный CI/CD, автоматическое переобучение, A/B-инфраструктура. Первый уровень — недели работы. Второй — месяцы, и к нему стоит переходить, когда первый уровень уже работает.

Самый простой, самый дешёвый и самый недооценённый компонент MLOps. По сути это ответ на вопрос: «какая модель сейчас в проде и что мы про неё знаем?»

Минимальный набор информации для каждой модели: версия и дата обучения, данные, на которых она обучена (или указатель на них), метрики на валидации, владелец (кто отвечает за модель в проде), известные ограничения (где модель работает хуже, на каких сегментах ей нельзя доверять), дата и план следующего переобучения.

Это можно вести хоть в Google Sheets, хоть в markdown-файле в git-репозитории, хоть в MLflow — форма не принципиальна. Принципиально, чтобы эта информация существовала и обновлялась при каждом релизе.

Зачем это нужно на практике? Когда модель начинает вести себя странно, первый вопрос — «что изменилось?». Без registry ответ на этот вопрос — детективный квест по Slack-переписке и git blame. С registry — 30 секунд: смотрим версию, дату, данные, метрики. Когда нужно откатиться — знаем, на что. Когда приходит аудит или новый человек в команде — есть от чего оттолкнуться.

Вопрос, который убивает проекты через шесть месяцев после запуска. Модель нужно обновить: сменился сезон, добавились данные, изменился ассортимент. Кто-то открывает ноутбук, в котором модель обучалась, и обнаруживает, что: библиотеки обновились и код не запускается, данные были скачаны «откуда-то» и этот «откуда-то» уже не доступен, часть предобработки делалась руками в Excel и не задокументирована, окружение было настроено на конкретной машине, которую с тех пор переформатировали.

Переобучение, которое должно занять час, превращается в двухнедельный квест по восстановлению утраченных знаний. Иногда квест заканчивается выводом «проще обучить с нуля» — но и с нуля непонятно как, потому что постановка задачи тоже была в голове у одного человека.

Что нужно минимально. Зафиксированный код обучения в git (не ноутбук с пометкой «final_v3_LAST», а нормальный скрипт). Зафиксированные данные или указатель на них (версия датасета, snapshot, запрос в хранилище). Зафиксированное окружение: Docker-образ, requirements.txt, или хотя бы README с инструкцией «как воспроизвести обучение на чистой машине». Это не идеал, но это разница между «переобучили за день» и «разбирались два месяца».

Feature store — это, пожалуй, самый «пугающий» компонент MLOps для небольших команд. Звучит как тяжёлая инфраструктура, которая нужна только при масштабах Spotify или Uber. И в каком-то смысле это правда: если у вас одна модель с десятью фичами, feature store — это overkill.

Но момент, когда он становится нужен, наступает раньше, чем обычно думают. Вот типичные сигналы: две или больше моделей используют одни и те же фичи, но каждая считает их по-своему (и результаты слегка расходятся). Фичи на обучении считаются из одного источника, а на инференсе — из другого, и между ними есть тонкие расхождения (training-serving skew). Подготовка фичей занимает столько времени, что новый эксперимент — это неделя работы вместо дня.

Минимальная реализация feature store — это не managed-платформа. Это общая витрина или таблица, из которой все модели берут фичи, с версионированием и документацией: что каждая фича означает, как считается и из каких данных. Это может быть таблица в ClickHouse, view в PostgreSQL, или даже набор SQL-запросов в git-репозитории с понятной структурой. Суть не в инструменте, а в принципе: единый источник правды для фичей.

Мониторинг моделей — это то, про что все знают, но почти никто не делает нормально. В лучшем случае — кто-то раз в месяц запускает ноутбук и смотрит AUC на свежих данных. В худшем — мониторинга нет вообще, и деградация обнаруживается только через жалобы бизнеса.

Работающий мониторинг — это три слоя, каждый из которых отвечает на свой вопрос.

Уровень данных: «то, что приходит на вход, ещё нормальное?» Проверки: данные вообще пришли вовремя? Нет ли новых пропусков, аномалий, изменений в распределении признаков? Не сломался ли формат? Это самый базовый уровень, и именно он ловит проблемы раньше всего. Если данные сломались — всё дальше бессмысленно.

Уровень модели: «модель ведёт себя так же, как при запуске?» Проверки: не сместилось ли распределение предсказаний? Не изменился ли калибровочный профиль? Нет ли систематического bias по сегментам? Здесь полезны метрики вроде PSI (Population Stability Index) или просто сравнение гистограмм скоров за текущий и базовый периоды.

Уровень бизнеса: «модель по-прежнему приносит пользу?» Проверки: конверсия, потери, SLA, время обработки — метрики, ради которых модель создавалась. Этот уровень ловит проблемы, которые невидимы на уровне модели: например, модель технически работает нормально, но бизнес-процесс вокруг неё изменился и результат больше не используется.

И самое главное: у каждого алерта должно быть действие. Дрейф данных — ускоренное переобучение. Деградация бизнес-метрик — откат на предыдущую версию или переход в «безопасный режим». Мониторинг без playbook — это просто логирование, от которого никому не легче.

В обычной разработке CI/CD стал стандартом давно: код проходит автотесты, проверяется линтером, деплоится автоматически. Никому не приходит в голову выкатывать фронтенд руками по пятницам через SSH.

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

Минимальный CI/CD для модели — это не Kubernetes с ArgoCD. Это три вещи. Первая: автоматическая проверка данных перед обучением (не пустые ли, не сломан ли формат, нет ли аномалий). Вторая: автоматическая проверка модели после обучения (метрики не хуже порога, предсказания в разумном диапазоне, нет явного bias). Третья: автоматический откат, если после деплоя бизнес-метрики упали ниже порога.

Это может быть реализовано хоть bash-скриптом в cron, хоть GitHub Actions, хоть Airflow. Инструмент вторичен. Важно, что деплой модели перестаёт быть «ручной операцией, которая зависит от настроения и внимательности одного человека в пятницу вечером».

Типичная ошибка — пытаться внедрить всё сразу. Feature store, model registry, мониторинг, CI/CD, автоматическое переобучение, A/B-платформу — в одном квартале. Результат предсказуем: ничего не доделано, всё «на 60%», команда выгорела.

Порядок, который я считаю рабочим, выглядит так.

Первые 2 недели: model registry. Просто зафиксируйте, что у вас есть: какие модели в проде, какие версии, на чём обучены, кто владелец. Это займёт буквально часы, а пользу принесёт сразу.

Недели 3–4: воспроизводимость обучения. Переведите пайплайны из ноутбуков в нормальные скрипты. Зафиксируйте окружение. Проверьте, что любой человек в команде может переобучить любую модель с нуля за разумное время.

Недели 5–8: мониторинг. Настройте три уровня: данные, модель, бизнес. Определите пороги и действия. Даже простой скрипт, который раз в день считает основные метрики и шлёт алерт в Slack — это уже мониторинг, и он в десятки раз лучше, чем ничего.

Недели 9–12: CI/CD. Автоматизируйте проверки перед деплоем и настройте откат. После этого обновление модели перестаёт быть стрессовым событием и становится рутиной.

Дальше (по необходимости): feature store. Когда у вас появляется несколько моделей с общими фичами и проблема training-serving skew становится реальной — тогда feature store оправдывает инвестиции.

Каждый следующий шаг имеет смысл только если предыдущий работает. Нет смысла строить CI/CD, если непонятно, какая модель в проде. Нет смысла строить feature store, если модели нельзя воспроизвести.

Инструменты MLOps меняются каждый год. То, что сегодня кажется стандартом, через два года будет legacy. MLflow уступит место чему-то новому, managed-платформы будут появляться и закрываться, модные аббревиатуры сменятся ещё более модными.

Принципы при этом останутся те же: воспроизводимость, контроль версий моделей и данных, мониторинг качества, понятное владение, автоматизация рутины. Это не «инфраструктура для Google». Это инженерная дисциплина, которая позволяет держать модели живыми, а не переписывать их с нуля каждые полгода.

Компании, которые это понимают, запускают модели в прод и поддерживают их годами — с предсказуемым качеством, управляемыми рисками и понятной стоимостью владения. Остальные — каждые полгода начинают «новый ML-проект», потому что предыдущий «как-то не взлетел».

Разница между первыми и вторыми — не в бюджете и не в крутости алгоритмов. Разница — в том, есть ли вокруг модели инфраструктура, которая позволяет ей жить. И начать строить эту инфраструктуру можно с model registry за 30 минут, а не с Kubernetes-кластера за полмиллиона.