ЛекцияВШЭ · 23 мая 2026
DataOps / MLOps для ИИ-бизнеса
Как менеджеру управлять данными, моделями, выпуском и экономикой рабочего ИИ
/ DataOps / MLOps · ВШЭ 2026
Содержание слайдов
1. DataOps / MLOps для ИИ-бизнеса
Как менеджеру управлять данными, моделями, выпуском и экономикой рабочего ИИ
2. Александр Поломодов
Technical Director & Fellow, Т-Технологии
Архитектура и RnD в инженерии.
AI в SDLC на масштабе.
Фокус: управляемый production AI.
3. DataOps/MLOps — управленческий контур
Как безопасно выпускать модели поверх data platform
Не повторяем базу — ETL, lakehouse, Data Mesh — в заметках.
Смотрим как менеджеры — Решения, владельцы, контроль контура.
Считаем экономику — Данные, признаки, инференс, review.
4. 01. Управленческая рамка
DataOps/MLOps нужен не ради инструментов, а ради контролируемого пути от данных до бизнес-решения
5. Какие решения реально принимает менеджер
Граница: эксперимент → пилот → production.
Стандарт выпуска: quality, risk, cost.
Что централизует платформа.
Метрики управляемости результата.
6. Варианты операционной модели
Обычно выбирают не один инструмент, а распределение ответственности
Managed / self-service — Пайплайны, registry, serving, observability; стандарты задает платформа.
Доменные ML-команды — Качество, гипотеза, цена ошибки и retrain у команды.
Гибрид — Общий стандартный путь; критичным сценариям отдельный runtime.
7. Оценивайте контур, а не стек
Что ускоряет результат
Гипотеза → живая проверка.
Повторяемый выпуск без ручной сборки.
Самообслуживание без потери контроля.
Что удерживает риск
Воспроизводимые данные, признаки, evals.
Стоп-правила, откат, blast radius.
Unit cost и обратимость пути.
8. 02. Контракты данных и признаков
После платформы данных появляется следующий вопрос: какие данные и признаки можно безопасно использовать в модели
9. Data platform не равен MLOps
Платформа данных
Данные, каталоги, lineage, доступы.
Надежный путь к data products.
DataOps/MLOps
Готовность данных к training/inference/release.
Признаки, evals, release, runtime, обратная связь.
10. Жизненный цикл модели как цепочка управляемых решений
Каждый переход должен оставлять артефакт: данные, признаки, оценку, решение о выпуске и план отката
11. Контракт признаков: что централизовать, что оставить доменам
Признак становится продуктовым контрактом: схема, владелец, свежесть, версия логики и готовность к продакшену
12. Антипаттерны данных для ML
Невоспроизводимый training slice.
Признаки без owner/version/SLA.
Offline-метрики без production skew.
Retrain маскирует data/policy debt.
13. 03. Безопасный выпуск моделей
Модель меняет продукт; релиз должен быть управляемым
14. Гейты выпуска: replay, shadow, canary, A/B, откат
Разные режимы выпуска отвечают на разные вопросы: что изменится, где риск и как быстро откатиться
15. Кто владеет выпуском модели
Участники решения
Продукт: цена ошибки, исход.
ML: качество, калибровка, риск.
Платформа: release path, откат, SLO.
Что ломается без матрицы
Качество отдельно от риска.
Релиз без владельца последствий.
Откат после деградации.
16. Почему качество модели не равно бизнес-решение
AUC/precision/recall не видят cost/latency.
Порог и резервный сценарий меняют исход.
Release card фиксирует изменения.
Решение соединяет quality, risk, cost.
17. 04. Сервинг и экономика выполнения
Модель в проде стоит денег каждую минуту: в признаках, инференсе, проверке и поддержке решений
18. Онлайн, пакетный и потоковый инференс
Режим инференса выбирают по задержке, цене ошибки, стоимости мощности и требованиям к свежести решения
19. Managed serving или свой runtime
Когда хватает managed
Нужен быстрый запуск и стандартный профиль нагрузки.
Достаточно базовых SLO, мониторинга и ограничений провайдера.
Экономика ошибки ниже, чем цена собственной платформенной сложности.
Когда нужен свой runtime
Нестандартная маршрутизация, резервный сценарий, SLA.
Большой объем; unit cost решает экономику.
Требуются особые политики доступа, аудита и разделения контуров.
20. FinOps для моделей: как посчитать стоимость
Features: backfill, materialization, freshness, storage.
Training/evals: experiments, retrain, baseline, replay.
Serving: CPU/GPU, peak, batch/online, cache.
Review: labeling, queues, escalation, corrections.
21. Затраты надо привязать к владельцу
Как распределять расходы
Бизнес-сценарий: антифрод, рекомендации.
Модель/endpoint: дорогие маршруты.
Домен/продукт: владелец решения.
Как использовать в управлении
Showback сначала показывает поведение.
Chargeback — после правил и owners.
Оптимизация меняет архитектуру, не бюджет.
22. 05. Наблюдаемость, обратная связь и зрелость
После релиза нужны деградация, обратная связь и масштаб
23. Ручная проверка и управление качеством
Human-in-the-loop нужен не как вечный костыль, а как контролируемый путь обучения, проверки и эскалации
24. Матрица зрелости: пилот -> рост -> регулирование -> масштаб
Зрелость DataOps/MLOps видна по повторяемости выпуска, владению риском, наблюдаемости и экономике единицы решения
25. Итоговая матрица менеджера
Managed: типовой путь, быстрый старт.
Платформа: release, observability, SLO, FinOps.
Домены: гипотеза, ошибка, обратная связь.
Свой runtime: контроль, масштаб, economics.
Модель в проде — отдельный бизнес-контур.
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