4.1.1 · блок 4

Задача 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.

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

Открыть интерактивную версию