# Дрейф данных

> Изменение распределения входных данных или связи между признаками и целевой переменной после обучения модели; главная причина тихой деградации моделей в продакшене.

Источник: https://llmdocs.ru/wiki/data-drift/ · обновлено 2026-11-09 · лицензия CC BY-SA 4.0

- **Виды**: ковариатный сдвиг, сдвиг меток, дрейф концепции
- **Метрики**: PSI, KS-тест, расстояние Вассерштейна, дивергенция Дженсена — Шеннона
- **Инструменты**: Evidently, NannyML, whylogs, Alibi Detect
- **Реакция**: переобучение, пересмотр признаков, откат
- **Связанное**: MLOps, мониторинг, Feature store
**Дрейф данных** (англ. *data drift*) — изменение свойств данных, поступающих в модель машинного обучения, по сравнению с данными, на которых она обучалась. Модель неявно предполагает, что мир остаётся таким же, как в обучающей выборке; когда это перестаёт быть правдой — меняются пользователи, сезон, цены, интерфейс сайта или источник данных, — качество предсказаний падает. Опасность в том, что модель не выдаёт ошибок: она продолжает уверенно отвечать, только всё менее точно. Обнаружение дрейфа — одна из главных задач мониторинга в [MLOps](https://llmdocs.ru/wiki/mlops.md).

## Виды дрейфа

Пусть модель учит зависимость *P(y | x)* — вероятность ответа *y* при признаках *x*.[1]

| Вид | Что меняется | Пример |
|---|---|---|
| **Ковариатный сдвиг** (data drift) | распределение признаков *P(x)* | приложение вышло в новый регион — другие возраст и доход клиентов |
| **Сдвиг меток** (prior shift) | доля классов *P(y)* | доля мошеннических транзакций выросла вдвое |
| **Дрейф концепции** (concept drift) | сама зависимость *P(y \| x)* | после изменения правил те же признаки означают другое поведение |

Дрейф бывает **внезапным** (поменялся формат поля в источнике, пандемия), **постепенным** (медленная смена аудитории), **сезонным** (праздники, выходные) и **повторяющимся**. Отдельный и очень частый случай — не настоящий дрейф, а **поломка конвейера**: признак начал приходить пустым, в других единицах или с ошибкой в джойне.

## Как обнаруживать

**Если есть истинные ответы** — например, через день становится известно, вернул ли клиент кредит, — нужно напрямую считать метрики качества по свежим данным (см. [Метрики качества классификации](https://llmdocs.ru/wiki/classification-metrics.md)). Но ответы часто приходят с большой задержкой или не приходят вовсе, поэтому следят за косвенными сигналами.

**Распределения признаков.** Для каждого признака сравнивают распределение в продакшене за окно (день, неделю) с эталоном — обучающей выборкой или «хорошим» периодом:[2]

- **PSI** (Population Stability Index) — популярен в кредитном скоринге; по традиции PSI < 0,1 — стабильно, 0,1–0,25 — заметное изменение, > 0,25 — серьёзный сдвиг;
- **тест Колмогорова — Смирнова** для числовых признаков и **хи-квадрат** для категориальных — на больших объёмах срабатывают на любые мелочи, поэтому смотрят и на величину эффекта;
- **расстояние Вассерштейна** и **дивергенция Дженсена — Шеннона** — меры величины сдвига.

**Распределение предсказаний.** Резкое изменение доли положительных ответов или средней уверенности модели — дешёвый и полезный сигнал.

**Оценка качества без меток.** Методы вроде CBPE в NannyML оценивают ожидаемую точность по калиброванным вероятностям модели.[3]

**Проверки данных.** Доля пропусков, диапазоны значений, новые категории, схема — их проверяют до модели (Great Expectations, Pandera).

## Пример

```python
import numpy as np

def psi(expected, actual, bins=10):
    edges = np.quantile(expected, np.linspace(0, 1, bins + 1))
    edges[0], edges[-1] = -np.inf, np.inf
    e = np.histogram(expected, edges)[0] / len(expected)
    a = np.histogram(actual, edges)[0] / len(actual)
    e, a = np.clip(e, 1e-6, None), np.clip(a, 1e-6, None)
    return float(np.sum((a - e) * np.log(a / e)))

psi(train_df["income"], prod_df["income"])   # > 0.25 — повод разбираться
```

На практике используют готовые библиотеки: **Evidently** строит отчёты по всем признакам, **NannyML**, **whylogs** и **Alibi Detect** решают похожие задачи; облачные платформы предлагают встроенный мониторинг моделей.[4] Метрики дрейфа можно экспортировать в [Prometheus](https://llmdocs.ru/wiki/prometheus.md) и настраивать алерты так же, как для сервисов.

## Что делать при дрейфе

1. **Проверить данные.** Сначала исключить поломку конвейера или источника — это самая частая причина.
2. **Оценить влияние.** Дрейф неважного признака может не влиять на качество; смотрят на важность признака и косвенные метрики.
3. **Переобучить** модель на свежих данных — по расписанию или по срабатыванию мониторинга. Нужна воспроизводимая процедура обучения ([версии данных](https://llmdocs.ru/wiki/dvc.md), конвейер, валидация перед выкладкой).
4. **Пересмотреть признаки**, если связь изменилась принципиально, — например, убрать признак, зависящий от изменившегося процесса.
5. **Откатиться** к предыдущей модели или к простому правилу, если новая версия хуже.

## Дрейф в системах с LLM

Для приложений на языковых моделях дрейф проявляется иначе: меняются темы и формулировки запросов пользователей, устаревают документы в базе знаний [RAG](https://llmdocs.ru/wiki/rag.md), а провайдер может обновить модель. Здесь мониторят распределение [эмбеддингов](https://llmdocs.ru/wiki/embedding.md) запросов, долю отказов и регулярно прогоняют наборы [evals](https://llmdocs.ru/wiki/llm-evals.md).

## См. также

- [MLOps](https://llmdocs.ru/wiki/mlops.md)
- [Сервинг моделей](https://llmdocs.ru/wiki/model-serving.md)
- [Feature store](https://llmdocs.ru/wiki/feature-store.md)
- [Мониторинг и алертинг](https://llmdocs.ru/wiki/monitoring-alerting.md)

## Источники

1. [Gama et al. — A Survey on Concept Drift Adaptation (ACM Computing Surveys, 2014)](https://dl.acm.org/doi/10.1145/2523813)
2. [Evidently AI — Data drift: what it is and how to detect it](https://www.evidentlyai.com/ml-in-production/data-drift)
3. [NannyML — Performance estimation without ground truth](https://nannyml.readthedocs.io/en/stable/how_it_works/performance_estimation.html)
4. [Google Cloud — Vertex AI Model Monitoring](https://cloud.google.com/vertex-ai/docs/model-monitoring/overview)
5. [Sculley et al. — Hidden Technical Debt in Machine Learning Systems (NeurIPS 2015)](https://papers.nips.cc/paper/5656-hidden-technical-debt-in-machine-learning-systems)