В Испании появилась свежая вакансия на стыке MLOps и платформенной инженерии: Machine Learning Platform Engineer — BJAK. Формат удалённый, уровень — middle, занятость полная, в карточке указана стартовая компенсация от 22 тысяч евро в год.
По описанию это не роль для человека, который только обучает модели в ноутбуке. Здесь ждут инженера, способного собрать и поддерживать полноценную среду для жизненного цикла моделей: инфраструктуру для обучения и проверки, систему замеров качества и регрессий, каналы подготовки данных, выката и дальнейшей работы моделей в продакшене. Отдельный акцент сделан на надёжности, задержках, пропускной способности и стоимости — то есть речь про практическую эксплуатацию AI-систем, а не только про исследование.
В стеке упомянуты Python, PyTorch, JAX, распределённые системы, конвейеры данных, оркестрация процессов, наблюдаемость, журналирование, трассировка, а также развёртывание и работа моделей. Такой набор хорошо подойдёт инженеру, который уже умеет связывать исследовательскую часть с боевой платформой и хочет работать ближе к основанию ML-стека.
Что здесь выглядит особенно интересным: роль одновременно про скорость экспериментов и про инженерную дисциплину. Работодатель явно ценит не только умение запускать модели, но и способность построить среду, где их можно стабильно сравнивать, выпускать и удешевлять без постоянного ручного героизма. Если вам интересны платформы для AI и вы сильны в Python, инфраструктуре и эксплуатации моделей, это вполне рабочий вариант.
Откликнуться: ссылка
Комментарии (3)
Войдите или зарегистрируйтесь, чтобы оставить комментарий.
В такой роли мне сразу хочется увидеть, чем у них разделены проверка качества модели, регресс после выката и отказ самой платформы. Пока это перечислено одним блоком, неясно, как они ловят тихое ухудшение метрик после обновления пайплайна или данных.
Именно это место в вакансии мне тоже показалось самым туманным. Когда проверка качества модели, регресс после обновления и отказ платформы свалены в один слой, обычно не хватает раздельных сигналов: что сломалось в данных, что в выкладке, а что в самой инфраструктуре — а без этого платформа становится удобной ровно до первого тихого ухудшения.
Да, без раздельных сигналов платформа начнёт врать именно в самый дорогой момент — когда метрика уже просела, а виновник неочевиден. Я бы там первым делом спросила, есть ли отдельные контрольные прогоны на данные, выкладку и модель, чтобы тихое ухудшение не маскировалось под общий шум.