CI/CD и оркестрация

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

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

1. #cicd_orchestration1 / 5
   Что такое автоматический retraining-триггер и когда он опасен?

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

   B)Это полный и бессрочный запрет на переобучение модели после её первого выката в продакшен

   C)Это откат модели на предыдущую версию строго в тот момент, когда падает её онлайн-метрика в проде

   D)Авто-переобучение по расписанию или дрифту; опасно без валидации — задеплоит модель хуже на грязных данных

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

   +D)Авто-переобучение по расписанию или дрифту; опасно без валидации — задеплоит модель хуже на грязных данных

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

2. #cicd_orchestration2 / 5
   Авто-ретрейн выкатил модель, онлайн-метрика упала, хотя офлайн-валидация на holdout прошла. Какого контроля не хватило в CD?

   A)Постепенного выката с gate на онлайн-метрику (canary/shadow) и авто-rollback, а не только офлайн-гейта

   B)Не хватило исключительно увеличения размера отложенной holdout-выборки в несколько раз при офлайн-валидации

   C)Проблема только в том, что модель обучали на слишком коротком по числу эпох цикле градиентного спуска

   D)Основная причина — устаревшая версия библиотеки для инференса на продакшен-сервере данной модели

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

   +A)Постепенного выката с gate на онлайн-метрику (canary/shadow) и авто-rollback, а не только офлайн-гейта

   // разбор: Офлайн-метрика на holdout может быть хорошей, а онлайн — просесть: сместилось распределение, holdout нерепрезентативен, прокси-метрика не совпала с бизнесом. CD должен катить постепенно — shadow/canary на малой доле трафика с гейтом на живую метрику и автоматическим откатом при просадке. Один офлайн-гейт не ловит расхождение офлайн/онлайн.

3. #cicd_orchestration3 / 5
   CI для ML-пайплайна гоняет юнит-тесты кода. Какой класс проверок специфичен для ML и часто забыт?

   A)Проверка стиля кода линтером — для ML-пайплайна этого набора проверок достаточно на практике

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

   C)Проверки данных и контракта фичей: схема, типы, диапазоны, доля пропусков, распределения на входе

   D)Ручной визуальный просмотр каждого отдельного предсказания дежурным аналитиком перед каждым релизом модели

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

   +C)Проверки данных и контракта фичей: схема, типы, диапазоны, доля пропусков, распределения на входе

   // разбор: Код может быть корректен, а пайплайн — сломаться из-за данных: поехала схема источника, колонка сменила тип, выросла доля пропусков, распределение фичи уплыло. CI для ML дополняют data-тестами и проверкой контракта фичей (Great Expectations, схемы, статистики), ловящими «плохие данные» до обучения/деплоя. Линтинг и нагрузка фронта важны, но не покрывают ML-специфику, а ручной просмотр не масштабируется.

4. #cicd_orchestration4 / 5
   Чем blue-green деплой модели отличается от canary?

   A)Blue-green шлёт трафик обеим версиям поровну, а canary отдаёт весь трафик новой версии сразу

   B)Blue-green держит две полные среды и переключает весь трафик разом; canary льёт новой версии сначала малую долю

   C)Это два названия одного и того же подхода — разницы между blue-green и canary на практике практически нет

   D)Canary мгновенно заменяет старую версию, а blue-green выкатывает новую по одному запросу за раз

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

   +B)Blue-green держит две полные среды и переключает весь трафик разом; canary льёт новой версии сначала малую долю

   // разбор: Blue-green держит две полные среды (старую blue и новую green) и переключает весь трафик разом, с мгновенным откатом на blue при проблеме. Canary выкатывает новую версию постепенно — сначала 1-5% трафика, следя за метриками, затем наращивает. Blue-green проще и быстрее по переключению, canary безопаснее ловит регресс на малой доле. Оба снижают риск релиза, но устроены по-разному.

5. #cicd_orchestration5 / 5
   Пайплайн обучения перезапустили после сбоя, и он частично задублировал данные и артефакты. Какого свойства не хватило?

   A)Большей вычислительной мощности кластера — на более мощном железе этот сбой попросту не случился бы

   B)Более частых коммитов кода в git, чтобы можно было откатиться на предыдущую рабочую версию скрипта

   C)Более подробного логирования — сами по себе подробные логи предотвратили бы повторную запись данных при рестарте

   D)Идемпотентности: повторный запуск шага должен давать тот же результат без дублей (перезапись по ключу/партиции)

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

   +D)Идемпотентности: повторный запуск шага должен давать тот же результат без дублей (перезапись по ключу/партиции)

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