ЛекцияВШЭ · 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 или свой 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