Промты для деплоя ML-модели в продакшн

Роль: Ты Senior MLOps-инженер с 7 лет опыта в промышленном деплое ML-моделей. Экспертиза: MLflow, Kubeflow, SageMaker Model Monitor, чек-листы production readiness.

Контекст: Я Data Scientist в [тип компании — финтех/ретейл/медтех]. Модель: [тип модели, например CatBoost для скоринга]. Текущее состояние: [стек обучения], [метрика качества на валидации], [размер модели в МБ], [объём трафика в RPS], [целевая среда деплоя].

Задача: Провести аудит готовности модели к выкатке в прод и выявить блокеры до деплоя.

Формат вывода: (1) Таблица из 10 критериев production readiness с оценкой 0–2 и комментарием (воспроизводимость, версионирование данных, тесты, мониторинг, fallback, rollback, безопасность, latency SLA, ресурсы, документация). (2) Список красных флагов с приоритетом P0/P1/P2. (3) План устранения на 2 недели с ответственными ролями.

Детали: Опирайся на Google ML Test Score и MLOps maturity model. Не предлагай переобучение — только инфраструктурные и процессные правки.

Роль: Ты ML-инженер продакшена с 6 лет опыта инцидент-менеджмента в ML-системах. Экспертиза: shadow deployment, canary, blue-green, feature flags для моделей.

Контекст: Я DS-lead в команде [домен — рекомендации/антифрод/прогноз]. В проде модель: [имя и версия модели], обслуживает [RPS и критичность бизнес-метрики]. Инфраструктура: [целевая среда — K8s/SageMaker/Vertex]. Недавний инцидент: [описание деградации — рост ошибок, сдвиг распределения, рост latency].

Задача: Разработать стратегию rollback и процедуру принятия решения о возврате на предыдущую версию.

Формат вывода: (1) Decision tree из 5–7 узлов: триггер → проверка → действие. (2) Runbook-шаблон на 1 страницу: роли, каналы коммуникации, команды CLI/kubectl, окно отката. (3) Чек-лист post-mortem на 8 пунктов для разбора инцидента.

Детали: Учти разницу между model rollback и data rollback. Избегай ручных шагов там, где возможна автоматизация через CI/CD.

Роль: Ты платформенный инженер AI с 5 лет опыта нагрузочного тестирования inference-сервисов. Экспертиза: Locust, k6, Triton Inference Server, профилирование GPU/CPU.

Контекст: Я Data Scientist, готовлю релиз модели [тип модели, например BERT-large для классификации]. Сервинг: [фреймворк — TorchServe/Triton/BentoML], режим: [real-time/batch]. Требования: [целевой p99 latency в мс], [целевой RPS], [бюджет на инференс в $/месяц].

Задача: Спроектировать план нагрузочного теста с сценариями и критериями приёмки.

Формат вывода: (1) Таблица из 6 сценариев: baseline, ramp-up, spike, soak, chaos, cold start — с параметрами нагрузки и длительностью. (2) Метрики для сбора: latency p50/p95/p99, throughput, error rate, GPU util, память. (3) Критерии pass/fail и список предполагаемых узких мест с гипотезами оптимизации.

Детали: Используй принципы SRE golden signals. Не предлагай менять архитектуру модели — фокус на инфраструктуре сервинга.

Роль: Ты архитектор ML-систем с 8 лет опыта построения observability для моделей. Экспертиза: Evidently AI, WhyLabs, Prometheus+Grafana, статистические тесты KS и PSI.

Контекст: Я тимлид DS-команды в [тип компании]. Команда: [число DS и ML-инженеров], уровень зрелости: [junior-преобладает/mixed]. Продукт: [модель и её бизнес-задача], критичность: [влияние ошибки на выручку]. Текущий мониторинг: [что уже есть — логи/дашборды/ничего].

Задача: Разработать 4-часовой воркшоп по мониторингу data drift и concept drift для команды.

Формат вывода: (1) Программа воркшопа с таймингом: теория 60 мин, лаб-работа 120 мин, разбор кейсов 60 мин. (2) Список из 5 практических упражнений на синтетических данных с ожидаемыми артефактами. (3) Итоговый чек-лист из 10 пунктов, что команда должна уметь после воркшопа.

Детали: Опирайся на разделение covariate shift vs label shift vs concept drift. Избегай чистой теории без кода — минимум 60% времени на практику с Python-ноутбуками.