От DevOps к DataOps и Data Mesh
Александр открывает выпуск честной рамкой: студентам показывают модели и архитектуры на чистых данных, где заранее понятно, какая модель подойдёт и кто даст обратную связь, а в реальной жизни под этой частью лежит огромная подводная часть айсберга, которая всё и решает. Каркасом разговора участники взяли статью Google Cloud почти трёхлетней давности — в ней много хороших иллюстраций, по которым удобно идти. Начинают с истории: лет пятнадцать назад между разработкой, которая хотела быстрее поставлять ценность, и эксплуатацией, которая хотела надёжности, стоял забор, и его ломали ради time to market. Дима вспоминает, как в его опыте админов просто упразднили, а разработчики стали фулстеком поддерживать всю рутину — и на горизонте это полетело бодрее и качественнее. Женя добавляет, что в ML разрыв был ещё ярче: те, кто строил модельки, сидели в своём загончике со своей кодовой базой, отдавали результат разработчикам, а внедряли вообще третьи люди на местах, с которыми связь была разорвана полностью.
Вторая волна — данные. Участники проходят по DataOps: хранилище, скорость, надёжность, «данные — новая нефть», Data Science, который раньше сидел в таком же загончике. Женя замечает, что строить хранилища университеты учить умеют давно, а вот системного курса про качество данных он не видел — и в компаниях этот вопрос решён редко. Один из участников шутит, что там, где не завёлся нормальный DataOps, MLOps обычно тоже пахнет, но не тем, чем нужно. Дима рассказывает про переход от классического хранилища к ELT и data lake, а дальше — к Data Mesh: концепцию, по его воспоминаниям, придумали лет пять назад или уже в 2018 году, и она делает с данными примерно то же, что микросервисы и доменный дизайн сделали с приложениями. Ответственность за качество сырья уезжает в продуктовые команды, контракт на отгрузку данных проверяется в их же пайплайне, а инциденты чинят авторы, а не «пожарные», которые ищут, где прорвало трубу. В банке, говорит Дима, этот переход как раз идёт: инструменты есть, часть людей уже заехала, основной рывок планировали на текущий год.
Жизненный цикл модели и платформа
Дальше идёт картинка жизненного цикла ML-системы, и Александр просит специалистов проверить её на правдоподобность. Ответ: если переименовать секторы, получится примерно тот же цикл, что у обычного приложения — эксперименты, сбор, интеграция, развитие, — только меняются не строчки кода, а данные, а мониторинг вообще один в один. Специфична лишь одна ветка: инкрементальное развитие модели на более сложных наборах признаков похоже на разработку новой функциональности, а вот регулярное переобучение, чтобы модель не деградировала под изменившейся средой, действительно другое. Женя считает, что в схеме не хватает этапа с переосмыслением целеполагания: требования к моделям меняются чаще, чем к понятным сервисам, — начинают иначе мерить качество, хотят от модели другого, полностью меняются данные. В разработке критерии обычно формализованы майлстоунами, а с моделью можно что-то сделать и по факту узнать, что шёл не туда; неопределённости и вариативности здесь больше.
Возможности платформы Дима разбирает по стадиям. Прототип: поднять машинку и накатить библиотеки должно быть делом с минимальным порогом входа, а не танцем с бубном. Дальше — реальные данные: посчитать признаки и таргеты, преобразовать их под обучение, и обе стадии упираются в компьют и доступ к данным. После офлайн-валидации модель либо едет по стандартным рельсам инференс-сервиса, который сам масштабируется горизонтально, либо требует кастома, когда вокруг неё навешаны бизнес-правила. Онлайн-проверку на реальных пользователях, говорит Дима, часто не делают, и это плохо кончается: платформа экспериментов — обязательный реквизит, со своей наукой о том, как нарезать пользователей и получить достоверный результат. Замыкает круг поддержка: плановое переобучение, версионирование, история о том, когда модель обновилась и как менялось качество. Кейсов, где всё это есть из коробки, Дима не видел. Женя замечает, что в картинке есть маркетинговый ход, а Александр соглашается: такие документы пишут, чтобы вы сели на их инструментарий.
Деградация, переобучение и курсы
Самый специфичный для ML кусок, по словам Димы, — переобучение. Пример: выкатили модель, которая ловит антифрод, начали банить — и те, кого банят, переходят на методы, которых модель при обучении не видела, качество ползёт вниз. Деградация бывает и от своих же багов: признак вроде CTR, посчитанный во временном окне, потихоньку сходится в ноль, потому что показы пишутся, а клики нет. Отсюда требование мониторить и выход модели, и её вход и иметь систему триггерных событий: либо переобучить автоматически, либо поднять красный флажок и идти разбираться — внутрь модели, в отличие от жёсткого интерпретируемого правила, глазами не залезешь. Александр приносит свежий пример: на встрече один на один с директором по аналитике Кириллом Николаевым обсуждали модель, которая работала на потоке, оставшемся после ручных эмпирических правил. Захотелось снять часть правил и расширить поток, но модель затюнена под старый, и на расширенном её качество сильно упало бы. Один из участников уточняет: нужен квантовый скачок — оторвать правила на части потока, собрать данные и переобучиться.
Женя проходит по тем же кубикам с точки зрения того, чему в университете реально можно научить. Подготовке данных — плохо: про краудсорсинг курс есть, а умение посмотреть на данные и увидеть закономерности он считает скорее искусством. Обучению и оценке моделей учат отлично, на любом уровне, с математикой и без. С выкаткой сложнее: устоявшегося фреймворка нет, своего PyTorch здесь не появилось. Теорию онлайн-экспериментов рассказывают хорошо, но открытой платформы для A/B-тестов, по его ощущению, не существует. Про мониторинг наберётся лекция-другая, а курс по systems design у них впервые запустится в следующем учебном году. Александр предлагает лабораторные, где студент обвешивает модель метриками, а преподаватель подсовывает другой трафик и ждёт, найдут ли проблему; сам он вспоминает экзамен администратора Kubernetes — по его памяти, 24 задачи на три часа, потом 18 на два, с пересдачей раз в два-три года. Финал у обеих сторон общий: эрудиция важна, изолированным специалистом быть не стоит, и об этом Александр с Женей договорились записать отдельный выпуск.
Что стоит унести с собой
- 01Data Mesh переносит ответственность за качество данных в продуктовые команды: контракт на отгрузку проверяется в их пайплайне, а инциденты чинят авторы, а не дежурные «пожарные».
- 02Жизненный цикл ML-системы почти повторяет цикл приложения; по-настоящему специфично только регулярное переобучение под изменившуюся среду.
- 03Модель деградирует не только от внешних причин: баг в поставке данных тихо уводит признак в ноль, поэтому мониторить нужно и выход модели, и её вход.
- 04Университет силён в обучении и оценке моделей, но выкатке, мониторингу и A/B-платформам учит слабо — здесь выручают лабораторные с поломками и стажировки.