Когда ваша модель видит то, чего нет

Открываешь статью на ArXiv. Красивые графики. Высокие метрики. Авторы утверждают: "Мы нашли паттерн в данных". Пытаешься повторить. Не получается. Снова не получается. Третий раз - и понимаешь: они нашли паттерн в ошибках предобработки.

В 2025 году Nature опубликовала исследование: 58% ML-статей в топовых конференциях содержат невоспроизводимые результаты. И главная причина - не модели, не алгоритмы. Предобработка данных.

Предупреждение: если вы делаете PCA перед кластеризацией "чтобы снизить шум", вы, скорее всего, уже создали артефакт. И скоро найдете его в результатах.

Три смертных греха предобработки

Эти ошибки настолько распространены, что стали стандартом. И это страшно.

1 Фильтрация по целевой переменной

Сценарий классический. У вас есть данные о пользователях. Нужно предсказать отток. Вы удаляете "неинформативные" строки - тех, кто был в системе меньше недели. Звучит логично?

Это гарантированная утечка информации из будущего. Вы знаете, что пользователь ушел, поэтому удаляете его ранние данные. В реальности этой информации нет. Модель учится на артефакте фильтрации.

💡

Фильтровать можно только по признакам, которые были бы доступны в момент прогноза. Никаких "если target=1, то..." в предобработке.

2 PCA как волшебная палочка

"Давайте сделаем PCA, чтобы убрать шум и мультиколлинеарность". Слышали? Я тоже. Каждый день.

Вот что происходит на самом деле:

PCA ищет направления максимальной дисперсии
Шум часто имеет высокую дисперсию
Вы оставляете шум, удаляете слабые сигналы
Потом удивляетесь, почему модель плохо работает

Особенно смешно, когда PCA делают перед кластеризацией. "Чтобы улучшить результаты". На деле - чтобы гарантировать сферические кластеры в пространстве главных компонент. Которые вы потом и найдете.

3 Нормализация по всему датасету

Train-test split? Сначала нормализуем весь датасет! Потом делим. Так все делают.

Неправильно. Утечка информации. Test set уже повлиял на параметры нормализации. Модель видит то, чего не должна видеть.

В 2024 году команда из Stanford показала: такая ошибка может улучшать метрики на 15-20%. Исследователи радуются. Реальность плачет.

Почему мы продолжаем это делать?

Потому что работает. В краткосрочной перспективе. Метрики растут. Статьи публикуются. Гранты получаются.

Проблема в системном искажении. Как в бенчмарках LLM, где ошибки в данных искажают рейтинги. Тот же механизм, другой контекст.

Ошибка	Кажется	На самом деле	Как обнаружить
Фильтрация по target	Убираем шум	Data leakage	Проверить доступность признака в момент прогноза
PCA перед кластеризацией	Снижаем размерность	Создаем артефакты	Кластеризовать в исходном пространстве, сравнить
Нормализация до split	Удобно	Information leakage	Разделить данные до любой предобработки

Как делать правильно: пошаговый план

Забудьте все, что знали. Начните с чистого листа.

Шаг 0: Разделите данные. Сразу.

Первый и главный шаг. Даже не смотрите на test set. Закройте его в сейф. Забудьте пароль.

# Правильно
from sklearn.model_selection import train_test_split

X_train, X_test, y_train, y_test = train_test_split(
    X, y, test_size=0.2, random_state=42, stratify=y
)

# Теперь X_test и y_test - священный грааль. Не трогать.
# Все трансформации - только на X_train

Шаг 1: Анализ без предобработки

Проведите EDA на сырых данных. Посмотрите распределения. Найдите выбросы. Но не удаляйте. Еще нет.

Спросите себя: "Это выброс или важная информация?" Если не знаете ответа - спросите у предметного эксперта. Не у модели.

Шаг 2: Трансформации через Pipeline

Каждая трансформация - только на train. Параметры запоминаем. На test применяем те же параметры.

from sklearn.pipeline import Pipeline
from sklearn.preprocessing import StandardScaler
from sklearn.impute import SimpleImputer

# Создаем pipeline
preprocessing_pipeline = Pipeline([
    ('imputer', SimpleImputer(strategy='median')),
    ('scaler', StandardScaler())
])

# Обучаем на train
X_train_processed = preprocessing_pipeline.fit_transform(X_train)

# Применяем на test (не fit_transform!)
X_test_processed = preprocessing_pipeline.transform(X_test)

Запомните: на test set - только transform. Никакого fit, fit_transform, повторного обучения. Один раз обучили на train - применяем везде.

Шаг 3: Валидация трансформаций

Самый важный шаг, который все пропускают. Проверьте, не создали ли вы артефакты.

Сравните распределения до и после (не должны совпадать идеально)
Проверьте, не появились ли искусственные корреляции
Запустите простую модель (например, линейную регрессию) до и после - улучшения должны быть минимальными на этом этапе

Специфические ловушки для разных методов

Кластеризация: когда группы создает алгоритм, а не данные

K-means найдет кластеры всегда. Даже в случайном шуме. Особенно если вы:

Нормализовали данные (сделали сферическими)
Удалили выбросы (убрали всё, что мешает сферичности)
Сделали PCA (гарантировали ортогональность)

Поздравляю. Вы создали идеальные условия для k-means. Он найдет кластеры. Вы опубликуете статью. Мир не станет лучше.

Как проверить: используйте индекс силуэта на исходных данных. Сравните с случайными данными. Если разница меньше 0.1 - скорее всего, нашли шум.

PCA: главный компонент - ваша ошибка

PCA-1 часто захватывает артефакты измерения. Систематическую ошибку датчика. Сезонность, которую вы не учли.

Проверка: посмотрите на нагрузку (loadings) первой компоненты. Если один признак доминирует (>0.9) - это, скорее всего, артефакт. Удалите этот признак и пересчитайте PCA.

Временные ряды: протекающее будущее

Самая жесткая ловушка. Применяете скользящее среднее? Используете будущие значения для сглаживания прошлого. Классика.

Решение: только односторонние окна. Только прошлое для предсказания будущего. Никаких симметричных фильтров.

Инструменты для автоматической проверки

На 2026 год появились инструменты, которые ловят эти ошибки автоматически. Используйте их перед публикацией:

MLflow с кастомными валидаторами - отслеживает data leakage между шагами
Great Expectations - проверяет согласованность train/test распределений
Alibi Detect от Seldon - находит drift и leakage в реальном времени
Cleanlab 3.0 - автоматически находит проблемные образцы в данных

Но инструменты - не панацея. Они ловят технические ошибки. Логические - только вы.

Кейс: как мы нашли паттерн, которого не было

2023 год. Исследование пользовательского поведения. Данные: 2 млн сессий, 50 признаков. Задача: сегментировать пользователей.

Что сделали "по учебнику":

Удалили сессии короче 10 секунд ("неинформативные")
Нормализовали все признаки
PCA до 10 компонент (объяснили 95% дисперсии)
DBSCAN для кластеризации

Нашли 5 четких кластеров. Написали статью. Отправили на конференцию.

Потом решили проверить. Сгенерировали случайные данные с теми же распределениями. Применили тот же пайплайн.

Нашли 4 четких кластера.

Весь паттерн был в предобработке. В реальных данных - шум. В статье - красивая картинка.

Это не единичный случай. Как показывает исследование логических сбоев ИИ, системные ошибки в данных порождают системные ошибки в выводах.

Что делать завтра

Перестаньте доверять метрикам. Начните доверять здравому смыслу.

Перед публикацией любого результата задайте себе вопросы:

Могу ли я воспроизвести результат, начав с сырых данных?
Что произойдет, если я изменю random seed? Сильно ли поменяются результаты?
Будет ли результат иметь смысл для предметного эксперта (не ML-инженера)?
Что я удалил из данных и почему? Не могло ли это быть сигналом?

Самое главное: публикуйте не только код, но и полный пайплайн предобработки с обоснованием каждого шага. Как в медицинских исследованиях публикуют протоколы.

💡

Совет: создайте чек-лист предобработки. Висит на мониторе. Каждый шаг - галочка. Без галочек - нет публикации. Мой чек-лист доступен в репозитории.

В 2026 году лучшие ML-инженеры - не те, кто знает самые новые архитектуры. Те, кто понимает данные. Кто видит разницу между сигналом и артефактом предобработки. Кто не создает иллюзию смысла там, где его нет.

Потому что, как показывает практика провалов ML в продакшене, иллюзии долго не живут. А вот репутация - да.

Как избежать иллюзии смысла: критический разбор ошибок предобработки данных в ML-анализе