Зачем это нужно
Если вы умеете обучать модель в Jupyter Notebook, это ещё не значит, что вы умеете делать продукт. В реальной компании над одной задачей работают люди с разными навыками: кто-то формулирует бизнес-цель, кто-то пишет API, кто-то следит, чтобы сервис не падал ночью. Без понимания ролей и процессов легко «сломать» соседнюю команду: залить секреты в Git, выкатить модель без мониторинга или потратить месяц на эксперимент, который никому не нужен.
Этот урок — карта местности. Вы узнаете, кто за что отвечает, как идея превращается в работающий сервис и почему ML-проекты требуют особого подхода.
Основные идеи
Роли в команде. В типичном ML-продукте участвуют:
Product Manager (PM) — определяет зачем мы делаем фичу, приоритизирует задачи, общается с заказчиком.
Data Scientist (DS) — исследует данные, обучает модели, проверяет гипотезы.
ML Engineer (MLE) — переводит эксперимент DS в воспроизводимый пайплайн: обучение, валидация, деплой модели.
Backend Developer — пишет сервисный код: API, бизнес-логику, интеграции с базами данных.
DevOps / Platform Engineer — автоматизирует сборку, тестирование и выкладку; настраивает инфраструктуру.
QA Engineer — проверяет, что продукт работает по требованиям; пишет и запускает тесты.
SRE (Site Reliability Engineer) — следит за надёжностью в продакшене: алерты, инциденты, SLA.
Один человек может совмещать роли (особенно в стартапе), но ответственность за каждую область должна быть явной.
RACI — кто что делает. RACI — простая матрица ответственности:
R (Responsible) — выполняет работу.
A (Accountable) — принимает итоговое решение (один человек на задачу).
C (Consulted) — консультирует до решения.
I (Informed) — получает информацию о результате.
Пример для задачи «запустить рекомендательную систему в прод»:
| Этап | PM | DS | MLE | Backend | DevOps | QA | SRE |
|---|---|---|---|---|---|---|---|
| Формулировка метрики | A | C | I | I | I | I | I |
| Обучение модели | I | R | C | I | I | I | I |
| Сервис inference | I | C | R | R | C | C | I |
| Деплой и мониторинг | I | I | C | C | R | I | A |
Почему ML отличается от обычного сервиса. Классический веб-сервис: написал код → протестировал → выкатил. Поведение предсказуемо. ML-сервис добавляет слой неопределённости:
Данные меняются — модель, обученная на прошлом месяце, может деградировать (data drift).
Код и артефакт — вместе с бинарником выкладывается файл весов модели; версионировать нужно оба.
Эксперименты — DS может неделями пробовать подходы; процесс должен отделять «исследование» от «продакшена».
Метрики офлайн ≠ метрики онлайн — высокий AUC в ноутбуке не гарантирует рост бизнес-показателя.
Поэтому в ML-командах чётко разделяют research (быстрые эксперименты, ноутбуки) и engineering (код в репозитории, CI/CD, тесты).
Как это выглядит на практике
Представьте задачу в Jira: «Добавить скоринг мошенничества для платежей».
PM создаёт Epic с бизнес-целью: снизить потери на 15%.
DS получает Story «Проанализировать исторические транзакции» — работает в ноутбуке, пишет выводы в Confluence.
MLE создаёт Story «Пайплайн обучения модели» — код уходит в Git, запускается в CI.
Backend добавляет эндпоинт
POST /score— PR проходит code review.DevOps настраивает деплой через GitLab CI → Kubernetes.
QA проверяет сценарии по acceptance criteria из Jira.
SRE подключает алерт: если latency > 200 ms или error rate > 1% — пишем в Slack.
На C4-диаграмме (позже в курсе) этот сервис будет одним контейнером среди платёжного шлюза, базы транзакций и системы алертов.
Что сделать после занятия
Нарисуйте RACI-таблицу для учебного проекта (например, «классификатор спама») — распределите роли между одногруппниками.
Запишите три отличия ML-сервиса от обычного REST API своими словами.
Найдите в открытых вакансиях (hh.ru, LinkedIn) описание роли ML Engineer и выпишите, какие навыки пересекаются с вашим Python-бэкграундом.