ML System Design: сервинг и деплой

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

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

1. #serving_deployment1 / 5
   Как безопасно выкатить новую версию модели вместо текущей в проде?

   A)Просто заменить файл модели глубокой ночью и потом внимательно следить за логами сервиса

   B)Сразу пустить сплит 50/50, чтобы как можно быстрее собрать статистику

   C)Shadow → канарейка с guardrail → постепенная раскатка с откатом

   D)Выкатить сразу на всех пользователей, но с заметно пониженным порогом

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

   +C)Shadow → канарейка с guardrail → постепенная раскатка с откатом

   // разбор: Shadow ловит технические расхождения (латентность, ошибки, сдвиг скоров) бесплатно для юзеров; канарейка ограничивает радиус поражения; финальную ценность подтверждает A/B. Ключевая дисциплина — мгновенный откат (роутинг версий, а не перезаливка) и совместное версионирование модели, фичей и препроцессинга: артефакт без своего пайплайна невалиден.

2. #serving_deployment2 / 5
   Зачем логировать предсказания модели вместе с поданными фичами, а не только финальные решения?

   A)Прежде всего ради формального соответствия требованиям регламента GDPR

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

   C)Сырьё ML-цикла: разбор инцидентов, детект дрейфа, датасеты, реплей

   D)Чтобы за счёт этого заметно уменьшить итоговый размер обученной модели

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

   +C)Сырьё ML-цикла: разбор инцидентов, детект дрейфа, датасеты, реплей

   // разбор: Реконструировать «какие фичи были в тот момент» задним числом почти невозможно (источники уехали) — а логи предсказаний дают point-in-time датасет бесплатно. Реплей логов — способ оценить модель-кандидата до A/B. Практика: сэмплирование для тяжёлых фичей, PII-маскирование, схема с версией модели/фичей в каждой записи.

3. #serving_deployment3 / 5
   Модель в проде «сломалась» после планового переобучения: скоры сместились, конверсия просела. Каких предохранителей не хватило в пайплайне переобучения?

   A)Переобучение — неизбежный риск, предохранителей практически нет

   B)Автовалидация перед промоушеном: holdout vs текущая, PSI скоров, канарейка, откат

   C)Достаточно обычного ручного согласования каждого релиза модели с менеджером

   D)Просто переобучать заметно чаще, чтобы каждая конкретная ошибка жила меньше

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

   +B)Автовалидация перед промоушеном: holdout vs текущая, PSI скоров, канарейка, откат

   // разбор: Continuous training без continuous validation — генератор инцидентов: битая партиция данных тихо портит трейн. Гейт промоушена: новая модель обязана не проиграть текущей на holdout и не сдвинуть скоры сверх порога без объяснения; вход пайплайна защищают data-контракты (схема, доли пропусков, диапазоны). Плюс канарейка и кнопка отката — как у любого деплоя.

4. #serving_deployment4 / 5
   Чем инференс модели отличается от обучения?

   A)На инференсе модель как раз подбирает свои веса, а на обучении лишь выдаёт готовые предсказания

   B)Обучение подбирает веса по данным; инференс применяет готовую модель к входу

   C)Инференс и обучение — это два названия одного и того же процесса

   D)Обучение выполняется на CPU, а инференс на GPU

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

   +B)Обучение подбирает веса по данным; инференс применяет готовую модель к входу

   // разбор: Обучение — дорогой оффлайн-процесс подбора весов по размеченным данным. Инференс — быстрый прогон уже обученной модели на новом входе ради предсказания. Именно инференс живёт в проде под требованиями латентности и надёжности, поэтому его оптимизируют (батчинг, квантование), а обучение гоняют отдельно.

5. #serving_deployment5 / 5
   Зачем обученную модель разворачивают как сервис, а не гоняют в ноутбуке?

   A)Чтобы развёрнутая модель могла самостоятельно дообучаться прямо во время работы

   B)Ноутбук не способен выполнить инференс обученной модели

   C)Это требуется для соответствия требованиям регуляторов

   D)Чтобы приложения слали запросы и получали предсказания надёжно и масштабируемо

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

   +D)Чтобы приложения слали запросы и получали предсказания надёжно и масштабируемо

   // разбор: Развёртывание как сервиса даёт приложениям стабильный API для предсказаний, а команде — масштабирование под нагрузку, версионирование, мониторинг и откат. Ноутбук инференсить умеет, но не выдержит прод-трафик и не даст этих гарантий. Отсюда и требования: латентность, доступность, воспроизводимость версий модели и фич.