MLOps: трекинг и реестр моделей

Проверьте себя

Пять вопросов из банка по этой подтеме. Всего их 12, остальные разбираются в тренажёре.

1. #experiment_registry1 / 5
   Код модели уже в git. Зачем отдельно версионировать данные, например через DVC?

   A)Тот же код на разных данных даёт разную модель, а git не тянет большие бинарные датасеты

   B)Git и так хранит датасеты в сотни гигабайт и построчно отслеживает их изменения

   C)Версионирование данных избавляет от необходимости писать тесты на код пайплайна

   D)Это нужно ради ускорения чтения обучающего датасета с диска в момент обучения модели

   показать ответ и разбор

   +A)Тот же код на разных данных даёт разную модель, а git не тянет большие бинарные датасеты

   // разбор: Модель определяется кодом И данными: тот же скрипт на другом срезе даёт другую модель, поэтому для воспроизводимости данные версионируют вместе с кодом. Git для этого не годится — он не рассчитан на гигабайтные бинарники; DVC хранит данные в объектном хранилище, а в git кладёт только лёгкий указатель на версию. Тесты и скорость чтения тут ни при чём.

2. #experiment_registry2 / 5
   Что такое training-serving skew и чем от него защищает feature store?

   A)Это когда обучающая выборка случайно оказалась значительно больше по объёму, чем тестовая выборка

   B)Это постепенный уход распределения таргета со временем, который лечится полным переобучением

   C)Это рассинхрон версий библиотек между машиной обучения и продакшен-сервером инференса модели онлайн

   D)Фичи в проде считаются иначе, чем на обучении; общий feature store даёт единую логику офлайн и онлайн

   показать ответ и разбор

   +D)Фичи в проде считаются иначе, чем на обучении; общий feature store даёт единую логику офлайн и онлайн

   // разбор: Training-serving skew — когда фича на обучении и та же фича в проде считаются по-разному (другой SQL, другое окно, другой дефолт для пропуска). Модель обучалась на одном распределении, а в проде видит другое — тихая деградация. Feature store хранит одно определение фичи и отдаёт её консистентно и в офлайн-обучение, и в онлайн-инференс. Это не про размер выборки и не про версии либ.

3. #experiment_registry3 / 5
   Эксперимент дал +2% метрики, но на той же конфигурации гиперпараметров результат не воспроизводится. Что чаще всего забыли зафиксировать?

   A)Ничего: расхождение в пару процентов между прогонами нормально и фиксировать тут нечего

   B)Seed, версию данных и версии библиотек — источники недетерминизма помимо гиперпараметров

   C)Забыли увеличить число эпох обучения, из-за чего вторая модель банально не успела дообучиться до конца

   D)Забыли развернуть обучение на таком же числе GPU — это возможная причина расхождения

   показать ответ и разбор

   +B)Seed, версию данных и версии библиотек — источники недетерминизма помимо гиперпараметров

   // разбор: Гиперпараметры — лишь часть конфигурации. Невоспроизводимость обычно даёт незафиксированный источник случайности: random seed (инициализация, шаффл, dropout), версия данных (датасет подъехал/пересобрался), версии библиотек и CUDA (недетерминизм ядер). Фиксируют seed, пинят версии и версионируют данные — иначе «тот же» эксперимент каждый раз чуть другой.

4. #experiment_registry4 / 5
   Модель в проде дала спорное предсказание; нужно узнать, на каких данных и коде она обучена. Что это за свойство системы?

   A)Lineage/происхождение (provenance): связка модели с версией кода, данных, гиперпараметров и окружением обучения

   B)Латентность инференса: время, за которое модель успевает ответить на один запрос в продакшене под нагрузкой

   C)Пропускная способность сервиса: сколько всего запросов к модели он успевает обработать за одну секунду времени

   D)A/B-тест: сравнение спорной версии модели с предыдущей на живом трафике реальных пользователей сервиса

   показать ответ и разбор

   +A)Lineage/происхождение (provenance): связка модели с версией кода, данных, гиперпараметров и окружением обучения

   // разбор: Чтобы разобрать инцидент или воспроизвести модель, нужна прослеживаемость (lineage/provenance): для каждой продовой модели зафиксировано, каким коммитом кода, на какой версии данных, с какими гиперпараметрами и в каком окружении она обучена. Это дают трекинг экспериментов плюс версионирование данных/артефактов (MLflow, DVC, registry). Латентность и throughput — про инференс, A/B — про сравнение, а не про происхождение.

5. #experiment_registry5 / 5
   Зачем в model registry заводят стадии (staging → production → archived) для версий модели?

   A)Стадии нужны для красоты интерфейса реестра и на реальный процесс выката они не влияют

   B)Чтобы хранить как можно меньше версий: все версии, кроме одной текущей, немедленно и безвозвратно удаляются

   C)Управляемое продвижение: версия проходит staging, помечается production, прежняя архивируется — прод ссылается на стадию

   D)Чтобы автоматически ускорять инференс production-версии в несколько раз по сравнению со staging-версией модели

   показать ответ и разбор

   +C)Управляемое продвижение: версия проходит staging, помечается production, прежняя архивируется — прод ссылается на стадию

   // разбор: Стадии в registry задают управляемый жизненный цикл: новая версия сначала в staging (прогоны, canary, приёмка), затем помечается production, а прежняя — archived. Прод-сервис ссылается не на конкретный хеш, а на стадию «production», поэтому выкат и откат — это смена указателя, с аудитом кто и когда продвинул. Это про процесс и управляемость, а не про красоту, удаление версий или скорость инференса.