1.1.1 · блок 1
Как устроена разработка ML-продукта
Как устроена разработка ML-продукта
Зачем это нужно
Если вы умеете обучать модель в 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: «Добавить скоринг мошенничества для платежей».
1. PM создаёт Epic с бизнес-целью: снизить потери на 15%.
2. DS получает Story «Проанализировать исторические транзакции» — работает в ноутбуке, пишет выводы в Confluence.
3. MLE создаёт Story «Пайплайн обучения модели» — код уходит в Git, запускается в CI.
4. Backend добавляет эндпоинт POST /score — PR проходит code review.
5. DevOps настраивает деплой через GitLab CI → Kubernetes.
6. QA проверяет сценарии по acceptance criteria из Jira.
7. SRE подключает алерт: если latency > 200 ms или error rate > 1% — пишем в Slack.
На C4-диаграмме (позже в курсе) этот сервис будет одним контейнером среди платёжного шлюза, базы транзакций и системы алертов.
Что сделать после занятия
- [ ] Нарисуйте RACI-таблицу для учебного проекта (например, «классификатор спама») — распределите роли между одногруппниками.
- [ ] Запишите три отличия ML-сервиса от обычного REST API своими словами.
- [ ] Найдите в открытых вакансиях (hh.ru, LinkedIn) описание роли ML Engineer и выпишите, какие навыки пересекаются с вашим Python-бэкграундом.