morfix.ru
Michelangelo: ML-платформа нового поколения
Когда Uber запустила собственную платформу машинного обучения Michelangelo, компания столкнулась с классической задачей масштабирования: как обучать, развёртывать и мониторить тысячи моделей без того, чтобы каждый день тратить ресурсы на переизобретение велосипеда? Ответ получился системным и универсальным — платформа, которая стала образцом для индустрии и открыла глаза многим разработчикам на правильную архитектуру ML-систем.
Эта статья разбирает внутреннее устройство Michelangelo и объясняет, какие принципы из её конструкции полезны для любого, кто работает с машинным обучением в production-среде.
Из чего состоит Michelangelo
Michelangelo — это не просто инструмент для обучения моделей. Это целая экосистема, которая охватывает весь lifecycle машинного обучения: от сбора данных до мониторинга работающих моделей в боевых условиях.
Основные компоненты платформы:
- Data Management Layer — централизованное хранилище данных и версионирование датасетов. Команды могут легко обращаться к структурированным и неструктурированным данным без дублирования.
- Feature Store — хранилище признаков, которое позволяет переиспользовать вычисленные features между разными моделями и экспериментами. Это критически важно для скорости разработки.
- Model Training Framework — унифицированный инструмент для обучения, поддерживающий различные фреймворки: TensorFlow, scikit-learn, XGBoost и другие.
- Model Registry — центральный каталог всех моделей, версий, метаданных и истории обучения. Полная прозрачность и отслеживаемость.
- Serving Infrastructure — система развёртывания и обслуживания моделей в production с поддержкой A/B тестирования и постепенного rollout.
- Monitoring & Analytics — инструменты отслеживания дрейфа данных, performance деградации и качества предсказаний в реальном времени.
Feature Store как сердце платформы
Если выбрать из всех компонентов один, который действительно меняет игру, это будет Feature Store. В традиционных approach разработчики вычисляют признаки заново для каждой модели, что приводит к дублированию кода, несогласованности и потере времени.
Michelangelo решает это проблему элегантно: features вычисляются один раз, версионируются и хранятся централизованно. Когда нужна новая модель, достаточно выбрать нужные признаки из каталога, и система автоматически подтягивает их с правильными временными метками для обучения и inference.
Практический пример: в Uber признак «средняя оценка водителя за последние 30 дней» используется в десятках моделей: в алгоритме матчинга, в системе рекомендаций и в fraud detection. Без Feature Store это означало бы 30+ реализаций одной логики с риском ошибок и рассинхронизации.
Управление lifecycle моделей
Michelangelo вводит ясный и структурированный lifecycle для каждой модели:
- Development фаза — экспериментирование с разными архитектурами и параметрами. Все версии и результаты сохраняются в Model Registry.
- Testing & Validation — автоматическая проверка качества модели на offline тестовых наборах и backtesting на исторических данных.
- Staging deployment — развёртывание на тестовой инфраструктуре, где модель работает параллельно с production версией, но не влияет на пользователей.
- Production rollout — постепенное увеличение трафика (от 1% до 100%), с мониторингом метрик качества и бизнес-показателей.
- Monitoring & Retraining — непрерывный контроль дрейфа данных и автоматическое переобучение при деградации качества.
Это решение важно не столько технически, сколько организационно. Когда у всех моделей единый процесс, сокращается time-to-market, повышается надёжность и упрощается командная работа.
Ключевой принцип: разделение concerns
Архитектура Michelangelo построена на чистом разделении ответственности между компонентами. Data Engineers управляют Feature Store, ML Engineers — Model Training Framework, а DevOps и SRE — Serving Infrastructure и Monitoring.
Такое разделение достигается через стандартные контракты и API между слоями. Например:
- Feature Store предоставляет простой интерфейс для получения features с указанием временного окна.
- Training Framework ожидает получить X и y в определённом формате.
- Model Registry хранит артефакты в унифицированном формате ONNX или JSON с метаданными.
Результат: каждая команда может развиваться независимо, не ломая остальную систему.
Практические советы для внедрения принципов
Чеклист для начала:
- Начните с централизации данных. Даже простая таблица в PostgreSQL с версионированием — это уже Feature Store.
- Введите Model Registry. Используйте MLflow или DVC для отслеживания версий и параметров моделей.
- Автоматизируйте validation. Каждая новая модель должна проходить набор тестов перед развёртыванием.
- Мониторьте дрейф данных. Отслеживайте распределение входных данных и предсказаний в production.
- Документируйте features и модели. Метаданные — это так же важно, как и код.
Заключение
Michelangelo показала, что масштабируемая ML-система — это не просто набор инструментов, а хорошо продуманная архитектура с чёткими границами и интерфейсами между компонентами. Даже если вы не работаете в компании размером Uber, принципы платформы применимы: централизованное управление данными, переиспользование features, стандартизация lifecycle и непрерывный мониторинг.
Берите эти идеи на вооружение независимо от того, используете ли вы готовые решения или строите собственную инфраструктуру. Инвестиция в правильную архитектуру на ранних этапах экономит месяцы работы позже.