Top‑level код виконується лише один раз при ініціалізації БД Airflow, тому зміни в ньому не можуть застосовуватись без міграцій.

Top‑level код компілюється в DAG‑серіалізацію, тому будь-які зовнішні виклики автоматично блокуються політиками безпеки.

Top‑level код виконується для кожної task instance на worker, тому важкі імпорти дублюються під час кожного виконання задачі.

Scheduler і Webserver регулярно обробляють DAG‑файли, тому top‑level код збільшує час обробки й деградує планування та масштабованість.

Залишити catchup=True, але збільшити ресурси кластера, оскільки планувальник має обробити всю пропущену історію перед переходом до нормального режиму роботи.

Вимкнути catchup для цього DAG, якщо масове дообчислення історичних інтервалів не є бізнес-вимогою, і запускати лише актуальні інтервали або виконувати backfill окремо, контрольовано.

Змінити schedule з @hourly на @daily, щоб зменшити кількість автоматично створених запусків без зміни політики catchup.

Перенести start_date ще далі в минуле, але одночасно обмежити кількість активних tasks, щоб планувальник поступово обробив історичні запуски без пікового навантаження.

Дає швидкий baseline, але може обмежити контроль над feature engineering і provenance; потрібні додаткові механізми lineage, SBOM та governance.

Гарантує нульову деградацію якості, тому canary/shadow стратегії та rollback-політики можна прибрати як надмірність.

Дає повний контроль над усіма стадіями конвеєрів, тому lineage і SBOM стають зайвими для аудиту та повторюваності.

Гарантує відсутність data drift, тому production-моніторинг і closed-loop retraining не потрібні в жодному сценарії.

Замінює canary на shadow, бо shadow автоматично усуває error rate й гарантує нормалізацію latency без змін коду.

Виконує rollback canary за порушенням SLO сервісу та розбирає причину, бо стабільність платформи є базовою вимогою.

Чекає на збільшення PSI, бо лише drift‑метрики мають визначати рішення про rollback незалежно від помилок сервісу.

Продовжує rollout, бо офлайн‑метрика моделі важливіша за SLO і завжди компенсує технічні регресії сервісу.

Перевіряє монотонність прогнозу відносно доходу на контрольованих контрфактичних парах, фіксуючи напрям очікуваної зміни.

Перевіряє лише загальну accuracy на тесті, бо доменні інваріанти автоматично виконуються при високій глобальній якості.

Перевіряє лише p95 latency сервісу, бо монотонність є властивістю інференсу і залежить від швидкодії системи.

Перевіряє лише KS-дрейф доходу, бо монотонність порушується лише тоді, коли змінюється розподіл цієї ознаки.

Перенавчає модель щоразу при зміні відсотка трафіку, щоб weights відповідали новому canary‑режиму.

Дублює код сервісу в окремий репозиторій і перемикає користувачів шляхом зміни DNS раз на добу.

Додає новий тег latest і покладається на cache registry, щоб трафік "сам" розподілився між версіями.

Виносить маршрутизацію/вибір моделі під feature flag і керує часткою трафіку та fallback без перевипуску артефакту.

Тренує кожну конфігурацію до максимального бюджету, а вибір здійснює лише за фінальною валідаційною метрикою.

Будує Gaussian Process surrogate і мінімізує acquisition function, гарантуючи глобальний оптимум при обмежених запусках.

Виконує повний grid search з детермінованим перебором, що забезпечує повне покриття простору гіперпараметрів.

Адаптивно розподіляє бюджет між багатьма конфігураціями та рано відсікає слабкі через successive halving.

Можливо слід було версіонувати модель у Docker, а не дані, бо дані ніколи не знижують якість самі по собі.

Можливо потрібно було перевірити git diff, бо версіонування даних автоматично виконується у Git.

Можливо зберегли .dvc у Git, але забули виконати commit коду, бо код точно не впливає на дані в pipeline.

Можливо не зафіксовано .dvc-файли у Git і не виконано dvc push, тому модель навчалася на змішаній/несанкціонованій версії даних.

Винести перетворення ознак у спільний артефакт перетворення, який однаково використовується і під час навчання, і під час інференсу.

Додати canary-розгортання нової версії препроцесингу та зупиняти реліз при погіршенні онлайн-метрик.

Підвищити частоту перенавчання моделі, щоб вона швидше адаптувалася до нових статистичних властивостей ознак.

Запровадити суворіші unit- і integration-тести для коду перетворення ознак у сервісному компоненті.

Так, якщо змінилася залежність target від ознак (P(Y|X)), а модель не була перетренована на новій залежності.

Ні, це обов'язково pipeline failure, бо concept drift визначається тільки зовнішніми умовами, а не тренувальним набором.

Ні, це training-serving skew, бо offline і online мають різні scalers і потрібно узгодити попередню обробку.

Ні, це завжди означає data drift (зміна P(X)), бо concept drift не впливає на offline-тестування.