Кратко: падение с 98% → 70% при наличии covariate shift и «шумных» прод‑меток — типичная ситуация. Нужно быстро $1$ диагностировать, что именно меняется — p$x$, p$y|x$, или метки шумные/несовместимые, $2$ выбрать адекватную стратегию адаптации $перетренировкасновымиданными,importanceweighting,domainadaptation,коррекцияметок$, $3$ организовать надёжный цикл мониторинга/автопереката и отката. Ниже — практическое руководство.

1) Быстрая диагностика причин падения $чтоделатьпервымделом$

Соберите и сохраните срезы входных данных и предсказаний из продакшна $featuresnapshot,timestamps,requestmetadata$.Выделите «контрольные» $trusted$ метки: если есть небольшая выборка ручных аннотаций/QA — используйте её как эталон.Сравните статистики train vs prod:
Одномерные тесты: Population Stability Index $PSI$, KL‑дивергенция, KS‑тест на распределения признаков.Многомерные тесты: MMD $maximummeandiscrepancy$, EMD, Hotelling’s T2, PCA/t‑SNE/UMAP визуализация кластеров.Сравните распределение предсказаний: распределение скоров/классов, доверия/калибровка $reliabilitydiagrams,Brierscore$. Резкий сдвиг в confidence или новый массовый класс — важный сигнал.Отделите типы сдвигов:
Covariate shift $p(x)изменилась,p(y|x)неизменилась$: полезно, когда качество меток на тесте сохраняется.Label/target shift $p(y)изменилась$: изменение основной частоты классов.Concept shift/label noise $p(y|x)изменилась$: модель уже не отражает реальную зависимость → требует срочной перетренировки или изменение модели/фичей.Постройте «domain classifier»: обучите бинарный классификатор различать train vs prod X. Если он хорошо различает — есть covariate shift; вероятно, можно оценить плотностное отношение.Проверка меток из продакшн‑логов:
Оцените уровень шума в метках через согласованность аннотаций, интер‑аннотатную согласованность, проверьте кейсы с аномальными входами $missingvalues,defaulttokens$.Если метки собираются неявно $userfeedback,clicks$, проверьте систематические смещения $selectionbias$.Error analysis: разберите ошибки по важным срезам $featurebuckets,время,источникданных$ — это часто указывает на причину.

2) Методы адаптации модели $когдаичтоприменять$

Немедленные шаги $mitigation,lowcost$

Canary/holdback: переключите процент трафика на «старую» модель/ручную проверку для оценки.Фильтрация/отбор плохих инстансов $dropoutliers,sanitizeinputs$: если проблемы из‑за багов в фичах, их легче исправить.Thresholding / abstain: модель может отказаться от предсказания при низкой уверенности $human‑in‑the‑loop$.Calibrated probabilities или корректировка отсечения классов по новым приоритетам.

Перетренировка

Соберите $ивалидационнопометьте$ репрезентативную выборку из продакшна; очистите/пометьте метки вручную при возможности.Перетренировка «from scratch» на объединённой выборке train+prod $илиfine‑tune$, с разделением holdout для оценки.Стратегия: частая инкрементальная перетренировка $еслидрейфбыстрый$ vs периодическая $еслисезонный$.Контроль: заливайте модели в registry, регистрируйте метрики, используйте offline evaluation на «trusted» prod labels.

Importance weighting $преобразованиепоплотностям$

Если covariate shift и p$y|x$ ≈ const, можно минимизировать взвешенную ошибку: вес для x = p_prod$x$/p_train$x$.Практическая оценка веса: обучите классификатор $trainvsprod$, используйте odds ratio: w$x$ ≈ p$D=prod|x$/p$D=train|x$.Используйте методы density ratio estimation: logistic regression, uLSIF, KLIEP.Применение: взвешивание лосс‑функции при дообучении модели или при переоценке метрик.Ограничения: чувствительно к области, где p_train≈0 $высокиевеса\to нестабильность$. Клаппинг весов и регуляризация обязательны.

Domain adaptation / transfer learning

Fine‑tuning: держите предобученную модель и дообучайте на промаркированных prod данных $еслиесть$.Feature alignment:CORAL $aligncovariances$, MMD regularization.Adversarial domain adaptation $DANN$: учите фичи, инвариантные к домену $domaindiscriminator$.Self‑training / pseudo‑labeling: модель предсказывает метки для prod данных; берутся высокоуверенные predictions для дальнейшего do‑training. Риск: подтверждение ошибок → аккуратность важна.Multi‑task / meta‑learning: если ожидаете множество доменов, тренируйте модель, устойчивую к сменам домена.Unsupervised domain adaptation: если нет меток, используйте методы, выравнивающие распределения фичей.

Работа с ненадёжными метками $labelnoise$

Оценка уровня шума: confusion estimation, clean labelling subset.Методы устойчивости к шуму: robust losses $symmetriccross‑entropy,focallossvariants$, co‑training, bootstrapping $Reedetal.$, noise‑aware training $estimateconfusionmatrixandкорректироватьлосс$.Weak supervision: объединение множественных слабых сигналов через Snorkel‑подобные методы.Привлекать человеческие аннотаторы по приоритетным случаям $оченьважныепримеры$.

3) Практический цикл мониторинга и отката модели $MLOps$

Архитектура мониторинга $основныекомпоненты$

Data ingestion & snapshotting: сохранять страницы входов X, предсказания, метаданные $userid,requestid,timestamp$.Feature store + schema validation: автоматические проверки $missing,range,categoricaldomain$.Drift detection service: считает PSI, KS, MMD per feature; прогоняет domain classifier; агрегирует drift score.Prediction monitoring: class distribution, confidence histograms, latency, throughput.Label pipeline: механизм сбора меток $batchlabeling,userfeedback$, обработка и качество меток.Alerting & dashboard: правила, пороги, оповещения $Slack,PagerDuty$.Model registry + CI/CD: хранение артефактов, метрик, тестов, автоматические тесты при деплое.Rollout manager: поддержка blue/green, canary, shadowing, A/B.

Детали мониторинга $чтоотслеживатьикакиепороги$

Feature drift per feature: PSI > 0.2 считается значимым; но настройте под доменную специфику.Domain classifier AUC: если >0.75 → сильный дрейф.Change in prediction distribution: новые классы >X% or drop in top‑1 accuracy proxies >Y%.Calibration shift: ECE рост больше порога.Latency/throughput errors → возможные баги в препроцессинге.Наличие «hot keys»/user segments с ухудшением — важный показатель.

Триггеры и workflow отката

Автоматические триггеры:Триггер на feature drift + отсутствие меток → поставить модель в mode «abstain»/traffic reduced.Триггер на падение label‑based метрик под SLA → автоматический rollback на предыдущую стабильную версию $blue/green/canary$.Canary/blue‑green стратегия:Запускайте новую модель на небольшом трафике $1–5$, мониторьте proxy/label‑based метрики; при отклонении — откат.Shadow deployment $параллельныйпрогонбезвлияния$: собирайте pred/score, но решения принимает старая модель.Human‑in‑loop: при подозрительном дрейфе — включать ручную проверку критичных запросов.Rollback safety:Всегда держать quick failover план + готовый артефакт стабильной версии.Логировать почему сделан откат, сохранять все метрики и снэпшоты.

Округлый цикл $end‑to‑end$

Production monitoring обнаружил дрейф → алерт.Быстрая triage: snapshot данных, domain classifier, PSI, sanity checks $ETLbugs$.Если баг ETL/feature → фикс и redeploy $fastfix$.Если истинный drift:
Собрать и пометить репрезентативный набор prod‑данных.Локальная оценка $offline$: compare retrained/fine‑tuned models, apply importance weighting, domain adaptation methods.Canary deploy лучшей кандидатуры на ограниченный трафик, мониторинг.Полный rollout при прохождении метрик; в противном случае — rollback.Автоматизировать: триггеры для retrain $event‑based$ + регулярные scheduled retrains.Пост‑mortem и обновление тестов/валидаторов, чтобы предотвратить повтор.

4) Практические рекомендации и контрольные точки

Не доверяйте только прод‑логам как «ground truth», особенно если метки косвенные. Всегда имейте small trusted labelled set.Начинайте с простых мер: domain classifier, PSI, визуализация, before/after сравнение предсказаний.Используйте importance weighting, если уверены, что p$y|x$ неизменна. Оценивайте стабильность весов, use clipping.Для concept drift — нужен labelled data и перетренировка; domain adaptation и self‑training помогают, но требуют контроля ошибок.Внедрите shadow deployments и canaries от начала проекта — они резко снижают риск при неожиданных сдвигах.Проектируйте модель и пайплайн с возможностью «abstain» и human review для критичных кейсов.Логируйте все: входы, предсказания, версии модели и препроцессинга — это ключ к расследованию инцидентов.

5) Быстрый чек-лист при падении качества

Проверить: recent code/ETL deploys, feature pipeline errors, schema changes.Снять снэпшоты X_prod и X_train, вычислить PSI и domain classifier AUC.Оценить качество меток: есть ли недавние изменения в источнике меток $логика,instrumentation$?Провести error analysis на небольшой доверенной выборке.Если серьёзный дрейф: canary + collect labels + retrain/fine‑tune + test → rollout/rollback.

Если хотите, могу:

Предложить конкретный набор метрик и порогов для вашей задачи $укажитедомениобъёмытрафика$.Написать примерный pipeline $Terraform/MLflow/TensorFlowDataValidation+Grafana/Prometheus$ и шаблон alert‑правил.Показать код‑пример для оценки веса p_prod/p_train через logistic regression.