Содержание слайдов

1. 1. DataOps / MLOps для ИИ-бизнеса

   Как менеджеру управлять данными, моделями, выпуском и экономикой рабочего ИИ

2. 2. Александр Поломодов

   Technical Director & Fellow, Т-Технологии

   Архитектура и RnD в инженерии.

   AI в SDLC на масштабе.

   Фокус: управляемый production AI.

3. 3. DataOps/MLOps — управленческий контур

   Как безопасно выпускать модели поверх data platform

   Не повторяем базу — ETL, lakehouse, Data Mesh — в заметках.

   Смотрим как менеджеры — Решения, владельцы, контроль контура.

   Считаем экономику — Данные, признаки, инференс, review.

4. 4. 01. Управленческая рамка

   DataOps/MLOps нужен не ради инструментов, а ради контролируемого пути от данных до бизнес-решения

5. 5. Какие решения реально принимает менеджер

6. 6. Варианты операционной модели

7. 7. Оценивайте контур, а не стек

   Что ускоряет результат

   Гипотеза → живая проверка.

   Повторяемый выпуск без ручной сборки.

   Самообслуживание без потери контроля.

   Что удерживает риск

   Воспроизводимые данные, признаки, evals.

   Стоп-правила, откат, blast radius.

   Unit cost и обратимость пути.

8. 8. 02. Контракты данных и признаков

   После платформы данных появляется следующий вопрос: какие данные и признаки можно безопасно использовать в модели

9. 9. Data platform не равен MLOps

10. 10. Жизненный цикл модели как цепочка управляемых решений

11. 11. Контракт признаков: что централизовать, что оставить доменам

12. 12. Антипаттерны данных для ML

    Невоспроизводимый training slice.

    Признаки без owner/version/SLA.

    Offline-метрики без production skew.

    Retrain маскирует data/policy debt.

13. 13. 03. Безопасный выпуск моделей

    Модель меняет продукт; релиз должен быть управляемым

14. 14. Гейты выпуска: replay, shadow, canary, A/B, откат

15. 15. Кто владеет выпуском модели

16. 16. Почему качество модели не равно бизнес-решение

    AUC/precision/recall не видят cost/latency.

    Порог и резервный сценарий меняют исход.

    Release card фиксирует изменения.

    Решение соединяет quality, risk, cost.

17. 17. 04. Сервинг и экономика выполнения

    Модель в проде стоит денег каждую минуту: в признаках, инференсе, проверке и поддержке решений

18. 18. Онлайн, пакетный и потоковый инференс

19. 19. Managed или свой runtime

    Когда хватает managed

    Быстрый запуск, стандартная нагрузка.

    Базовые SLO, мониторинг, ограничения провайдера.

    Цена ошибки ниже платформенной сложности.

    Когда нужен свой runtime

    Нестандартная маршрутизация, резервный сценарий, SLA.

    Большой объём; unit cost решает.

    Особые политики доступа, аудита, контуров.

20. 20. FinOps для моделей: как посчитать стоимость

21. 21. Затраты надо привязать к владельцу

22. 22. 05. Наблюдаемость, обратная связь и зрелость

    После релиза нужны деградация, обратная связь и масштаб

23. 23. Ручная проверка и управление качеством

24. 24. Рост требует более зрелого контура

25. 25. Итоговая матрица менеджера

    Managed: типовой путь, быстрый старт.

    Платформа: release, observability, SLO, FinOps.

    Домены: гипотеза, ошибка, обратная связь.

    Свой runtime: контроль, масштаб, economics.

    Модель в проде — отдельный бизнес-контур.

26. 26. Ссылки и материалы

    Google Cloud — MLOps pipelines.

    Sculley et al. — Hidden Technical Debt.

    Feast Feature Store documentation: docs.feast.dev

    NIST AI Risk Management Framework 1.0: nist.gov/itl/ai-risk-management-framework