Вопросы на собеседовании: MLOps-инженер

MLOps представляет собой дисциплину надёжной разработки, развёртывания и эксплуатации систем машинного обучения.

• Она объединяет практики машинного обучения, программной инженерии и эксплуатации.
• Она превращает эксперименты в повторяемые пайплайны и готовые к развёртыванию артефакты моделей.
• Она добавляет версионирование, автоматизацию, тестирование, мониторинг и ответственность на всём жизненном цикле модели.

Жизненный цикл ML начинается с постановки задачи и подготовки данных, а затем включает обучение, развёртывание и эксплуатацию.

• Данные собирают, проверяют, преобразуют и разделяют для обучения и оценки.
• Модели-кандидаты обучают, оценивают по критериям приёмки и упаковывают.
• Одобренную модель развёртывают для пакетного или онлайн-инференса.
• Данные и качество в продакшене отслеживают, чтобы решать, когда нужны проверка или переобучение.

MLOps применяет принципы DevOps, но учитывает данные, эксперименты и модели как дополнительные изменяемые части системы.

• DevOps обычно сосредоточен на исходном коде, сборках приложений, релизах и инфраструктуре.
• В MLOps также нужно версионировать датасеты, признаки, параметры, метрики и артефакты моделей.
• Поведение ML зависит и от кода, и от данных, поэтому тесты должны проверять качество данных и модели.
• Помимо непрерывной интеграции и доставки, MLOps часто включает непрерывное обучение.

Одного исходного кода недостаточно для идентификации результата ML, потому что на него также влияют данные, конфигурация, зависимости и входы обучения.

• Один и тот же код может создать другую модель при изменении датасета или определений признаков.
• Гиперпараметры и случайные начальные значения могут изменить результат обучения без изменения кода.
• Версии библиотек и среды выполнения могут изменить предобработку или численные вычисления.
• Воспроизводимая версия модели должна связывать все эти входы с итоговым артефактом.

Непрерывная интеграция в ML автоматически проверяет каждое предложенное изменение до слияния с основной веткой.

• Она запускает проверки кода, например форматирование, модульные и интеграционные тесты.
• Она может проверять схемы, пропущенные значения, диапазоны и другие контракты данных.
• Она может выполнить небольшое тестовое обучение, чтобы подтвердить завершение пайплайна и получение ожидаемых результатов.
• Она быстро сообщает команде о проблемах без полного продакшен-обучения.

Непрерывная доставка готовит проверенный релиз модели к развёртыванию через контролируемый и повторяемый процесс.

• Пайплайн упаковывает модель с нужным кодом инференса и зависимостями.
• Автоматические проверки подтверждают качество модели, совместимость и наличие обязательных метаданных.
• Одобренный артефакт продвигают между средами, а не пересобирают по-разному на каждом этапе.
• Выпуск в продакшен может требовать ручного одобрения, даже если все предыдущие шаги автоматизированы.

Непрерывное обучение представляет собой автоматизированный процесс переобучения и оценки модели при наступлении заданного триггера.

• Триггером может быть расписание, появление новых размеченных данных или отслеживаемый сигнал качества.
• Пайплайн повторяет подготовку данных, обучение, оценку и регистрацию модели.
• Новый кандидат должен пройти критерии приёмки, прежде чем сможет заменить текущую модель.
• Непрерывное обучение автоматически создаёт кандидатов, но не требует их автоматического продвижения в продакшен.

CI проверяет изменения, CT создаёт подходящие модели-кандидаты, а CD упаковывает и продвигает одобренные релизы.

• CI защищает общую кодовую базу и определения пайплайнов до слияния изменений.
• CT повторно запускает обучение с заданными версиями данных и конфигурации.
• CD проводит один и тот же проверенный артефакт через этапы контроля в тестовой среде и продакшене.
• Вместе они обеспечивают трассируемость от изменения или триггера данных до развёрнутой версии модели.

В системе контроля версий должны храниться текстовые определения, необходимые для ревью и повторной сборки ML-процесса.

• Храните код обучения, оценки, предобработки и инференса.
• Храните определения пайплайнов, тесты, описания окружения и небольшие конфигурационные файлы.
• Храните определения схем и ссылки или манифесты, идентифицирующие внешние датасеты и артефакты.
• Большие датасеты, бинарные файлы моделей, секреты и сгенерированные результаты храните в специализированных системах, а не в Git.

Версионируемая конфигурация делает изменения поведения обучения явными и не прячет их в исходном коде.

• В конфигурации можно записать гиперпараметры, выбранные признаки, расположение данных и настройки ресурсов.
• Для запуска нужно сохранять фактически применённые значения, включая значения по умолчанию и переопределения.
• Сравнение версий конфигурации помогает понять изменения между экспериментами.
• Связь версии конфигурации с каждым запуском помогает воспроизводить и сравнивать результаты.

Воспроизводимость означает возможность повторить записанный процесс в тех же заданных условиях и получить согласованный результат.

• Запуск должен определять код, данные, конфигурацию, зависимости и среду выполнения.
• Случайные начальные значения и детерминированные режимы нужно записывать там, где фреймворк их поддерживает.
• Итоговые метрики могут совпадать в пределах принятого допуска, а не побитово.
• Воспроизводимость помогает проверять, сравнивать, аудировать и надёжно обновлять модели.

Случайное начальное значение контролирует часть случайности, но само по себе не делает все этапы обучения детерминированными.

• Воркеры загрузки данных и параллельное выполнение могут использовать случайные операции в разном порядке.
• Некоторые GPU-ядра и численные библиотеки используют недетерминированные алгоритмы.
• Оборудование, драйверы и версии библиотек могут изменить результаты вычислений с плавающей точкой.
• Для воспроизводимости также нужны зафиксированные входы, сведения об окружении и доступные детерминированные настройки.

Отслеживание экспериментов записывает входы, результаты и контекст запусков разработки моделей в доступной для поиска системе.

• К входам относятся ревизия кода, версия датасета, параметры и сведения об окружении.
• К результатам относятся метрики, графики, логи, контрольные точки и итоговые артефакты моделей.
• Запуски можно группировать и сравнивать, чтобы понять влияние изменений на результаты.
• Такие инструменты, как MLflow и Weights & Biases, предоставляют интерфейсы и API для отслеживания.

MLflow Tracking объединяет связанную работу в эксперименты, а отдельные выполнения внутри них называет запусками.

• Параметры представляют собой входные настройки вроде скорости обучения или размера батча, которые обычно неизменны в рамках запуска.
• Метрики представляют собой числовые результаты вроде функции потерь или точности, которые можно многократно записывать на разных шагах.
• Артефакты представляют собой выходные файлы, например графики, отчёты, контрольные точки и сериализованные модели.
• Каждый запуск получает идентификатор, связывающий эти записи и метаданные выполнения.

Weights & Biases используют для отслеживания, сравнения и визуализации экспериментов машинного обучения и связанных артефактов.

• SDK записывает параметры, метрики, системные показатели, таблицы и медиафайлы из кода обучения.
• Дашборды помогают сравнивать запуски и изучать кривые обучения или использование ресурсов.
• Артефакты позволяют версионировать датасеты и модели с сохранением связей между ними.
• Общие проекты и отчёты делают результаты экспериментов доступными команде.

Для запуска обучения нужно записать достаточно информации, чтобы сравнить результат и проследить, как он был получен.

• Запишите ревизию кода, версию датасета, версию признаков или предобработки и итоговую конфигурацию.
• Запишите гиперпараметры, случайные начальные значения, версии зависимостей, оборудование и параметры среды выполнения.
• Запишите динамику метрик обучения и валидации, а также итоговые метрики оценки.
• Сохраните нужные логи, графики, контрольные точки и итоговый артефакт модели с идентификатором запуска.

Реестр моделей представляет собой каталог, который версионирует обученные модели и управляет сведениями для их контролируемого использования.

• Он связывает каждую версию модели с её артефактом, исходным запуском, метриками и метаданными.
• Команды могут записывать статус проверки, владельца, назначение и ссылки на развёртывания.
• Псевдонимы или стадии могут обозначать версии, одобренные для тестирования или продакшена.
• Такие системы, как MLflow Model Registry, отделяют продвижение модели от её обучения.

Псевдоним или стадия дают системе развёртывания контролируемую логическую ссылку на одобренную версию модели.

• Имя вроде champion или production может одновременно указывать только на одну неизменяемую версию.
• При продвижении меняется ссылка, поэтому код инференса не нужно редактировать и пересобирать.
• Реестр сохраняет, какая версия использовала ссылку и когда она изменилась.
• Для отката псевдоним можно снова направить на ранее одобренную версию.

Метаданные представляют собой структурированные сведения, описывающие ML-ресурсы, выполнения и связи между ними.

• Метаданные запуска могут включать время, владельца, ревизию кода, параметры и окружение.
• Метаданные датасета и модели могут включать версии, схемы, результаты оценки и назначение.
• Связи образуют происхождение от исходных данных через запуск обучения к зарегистрированной модели и развёртыванию.
• Метаданные позволяют искать, сравнивать, аудировать и воспроизводить ресурсы.

Управление артефактами обеспечивает хранение, версионирование и получение файлов, которые создают или используют ML-процессы.

• Артефактами могут быть датасеты, снимки признаков, контрольные точки, модели, отчёты об оценке и графики.
• Крупные файлы обычно хранятся в объектном хранилище, а системы отслеживания сохраняют их идентификаторы и метаданные.
• Неизменяемые версии и контрольные суммы помогают подтвердить, что получен ожидаемый артефакт.
• Контроль доступа, правила хранения и связи с запусками поддерживают безопасное и трассируемое повторное использование.