MLOps Pathmlopspath.ru

04 · MLOps-цикл и реестры4.1–4.2 · ML для инженера и lifecycle4.1.1лёгкий

Задача ML глазами инженера

Зачем это нужно

Data Scientist смотрит на задачу через метрики качества: accuracy, F1, ROC-AUC. Инженер (MLE / MLOps) смотрит на то же решение через вопросы эксплуатации: как оно попадёт в prod, кто будет обновлять веса, что произойдёт при падении GPU, как откатить версию?

Без «инженерного взгляда» модель остаётся в ноутбуке или выкатывается «как получилось» — без контрактов на вход/выход, без лимитов ресурсов, без мониторинга. Этот урок учит переводить ML-задачу на язык сервиса, который можно поддерживать командой.

Основные идеи

ML как продукт, а не эксперимент. В prod модель — это не .pkl на диске, а контракт:

  • формат входа (схема фич, типы, nullable);

  • формат выхода (score, class, embedding);

  • SLA: latency p95, доступность, пропускная способность;

  • политика обновления: как часто переобучаем, кто утверждает релиз.

Три роли в одной истории.

Роль Фокус Типичный артефакт
DS Качество на hold-out Notebook, отчёт метрик
MLE Serving, пайплайн, тесты API, Dockerfile, Jenkinsfile
SRE / Platform Кластер, observability, инциденты Helm, Grafana, runbook

Инженер не «чинит GPU вместо DS». Он снимает трение между исследованием и эксплуатацией.

Входные данные vs inference. DS думает «какая модель лучше». Инженер добавляет:

  • откуда фичи приходят в runtime (API, Feature Store, кэш);

  • что делать при пропуске фичи или out-of-range значения;

  • cold start: модель грузится 30 секунд — readiness probe должен это учесть.

Версионирование — не опция. Одновременно в prod могут жить две версии (canary). Клиент должен знать, какую версию вызывает. Без явной версии откат превращается в угадайку.

Fail-safe поведение. Если модель недоступна — fallback: правило по умолчанию, кэш последнего score, graceful degradation. Это архитектурное решение, не «потом добавим».

Definition of Ready для ML-фичи в backlog. Прежде чем таск идёт в спринт, полезно иметь:

  • пример входа/выхода (JSON или protobuf);

  • ожидаемый RPS и latency;

  • требования к данным (PII, retention);

  • критерий «готово к prod» (не только «метрика выросла на 0.5%»).

Как это выглядит на практике

Epic в Jira: «Скоринг оттока клиентов v1». DS закончил эксперимент: LightGBM, F1 = 0.78 на тесте.

MLE открывает refinement-сессию и задаёт вопросы:

  1. Inference online или batch? PM: online, p95 < 200 ms → нужен лёгкий сервис в Kubernetes, не Spark job раз в сутки.

  2. 12 фичей из CRM — откуда в runtime? Решение: Feature API с SLA 50 ms; контракт в OpenAPI.

  3. Модель 40 MB — образ inference + model artifact в registry; initContainer или volume mount.

  4. Обновление раз в месяц — нужен pipeline обучения (Argo Workflows позже) и approval в MMS (корпоративный реестр моделей).

Story breakdown:

  • ML-101 — REST /predict с валидацией входа (pydantic).

  • ML-102 — Dockerfile + health/readiness probes.

  • ML-103 — smoke-тест: фикстура JSON → ожидаемый диапазон score.

DS передаёт не только model.pkl, но и model card: обучающая выборка, ограничения, известные bias. Инженер кладёт card в репозиторий рядом с кодом serving.

Что сделать после занятия

  • Возьмите учебный ML-проект и опишите контракт API: поля входа/выхода, коды ошибок.

  • Составьте чеклист «Definition of Ready» из 5 пунктов для ML-стори в вашей команде.

  • Нарисуйте схему: DS → артефакты → MLE → что попадает в prod.

Официальные материалы