Time Travel в ML: как избежать утечки данных из будущего при построении фичей для production

Модель, которая знает будущее (и поэтому врет)

Вы обучили модель для fraud-детекции. На тестовых данных она показывает 99% точности. Выкатываете в production. Через месяц метрики падают до 70%. Модель пропускает мошенников. Бизнес теряет деньги.

Почему? Потому что ваша модель научилась путешествовать во времени. Она использовала данные из будущего для предсказания прошлого. И теперь, когда будущее наступило, у нее нет этих данных.

Классический пример: chargebacks, которые еще не произошли

Допустим, вы строите фичу "количество chargebacks за последние 30 дней" для транзакции. В production вы считаете chargebacks, которые произошли до момента транзакции. Логично?

А теперь посмотрите, как это часто делают при обучении:

# КАК НЕ НАДО ДЕЛАТЬ
import pandas as pd

# Загружаем все данные
transactions = pd.read_csv('all_transactions.csv')
chargebacks = pd.read_csv('all_chargebacks.csv')

# Объединяем по user_id
data = transactions.merge(chargebacks, on='user_id', how='left')

# Считаем chargebacks за последние 30 дней для каждой транзакции
# ПРОБЛЕМА: мы используем ВСЕ chargebacks, включая те,
# которые произошли ПОСЛЕ транзакции!
data['chargebacks_30d'] = data.groupby('user_id')['chargeback_date']\
    .transform(lambda x: x.between(x['transaction_date'] - pd.Timedelta(days=30), 
                                   x['transaction_date']))

# Теперь модель знает будущее
model.fit(data[features], data['is_fraud'])

Модель видит паттерн: "Если у пользователя будет chargeback через 2 недели после этой транзакции, то это мошенничество". В production у вас нет этого знания. Модель ломается.

Почему это происходит? Пять главных причин

1. Случайное перемешивание временных данных. Random shuffle без учета временных меток — классическая ошибка новичков.
2. Глобальные статистики. Использование mean/std/min/max по всему датасету для нормализации.
3. Оконные функции с lookahead. Фичи, которые "заглядывают" вперед во временном ряду.
4. Задержки в данных. Chargebacks приходят через 30-60 дней. Если не учитывать эту задержку, вы используете будущую информацию.
5. Неправильный train-test split. Разделение случайным образом вместо временного.

Практическое решение: временной шлюз

1 Определите точку во времени для каждой записи

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

# Правильная структура данных
class TemporalPoint:
    """Точка во времени для вычисления фичей"""
    def __init__(self, entity_id, timestamp, cutoff_time):
        self.entity_id = entity_id  # user_id, transaction_id
        self.timestamp = timestamp  # момент события
        self.cutoff_time = cutoff_time  # момент, ДО которого доступны данные
        
    # Все фичи вычисляются только на данных до cutoff_time
    def compute_features(self, historical_data):
        relevant_data = historical_data[
            historical_data['timestamp'] <= self.cutoff_time
        ]
        # ... вычисляем фичи

2 Используйте временной train-test split

Забудьте про sklearn.train_test_split для временных данных. Вместо этого:

# Временной сплит
from sklearn.model_selection import TimeSeriesSplit

# 5-fold временная кросс-валидация
tscv = TimeSeriesSplit(n_splits=5)

for train_idx, test_idx in tscv.split(X):
    X_train, X_test = X.iloc[train_idx], X.iloc[test_idx]
    y_train, y_test = y.iloc[train_idx], y.iloc[test_idx]
    
    # Важно: test set всегда хронологически ПОСЛЕ train set
    assert X_train['timestamp'].max() < X_test['timestamp'].min()

3 Реализуйте правильный подсчет chargebacks

Вернемся к нашему примеру с fraud-детекцией. Вот как считать фичи правильно:

def compute_chargebacks_features(transaction_row, chargebacks_df):
    """Вычисляем фичи по chargebacks ДО момента транзакции"""
    transaction_time = transaction_row['timestamp']
    user_id = transaction_row['user_id']
    
    # Берем только chargebacks, которые произошли ДО этой транзакции
    user_chargebacks = chargebacks_df[
        (chargebacks_df['user_id'] == user_id) &
        (chargebacks_df['chargeback_date'] < transaction_time)
    ]
    
    # Chargebacks за последние 30 дней (относительно transaction_time)
    thirty_days_ago = transaction_time - pd.Timedelta(days=30)
    recent_chargebacks = user_chargebacks[
        user_chargebacks['chargeback_date'] > thirty_days_ago
    ]
    
    return {
        'chargebacks_30d_count': len(recent_chargebacks),
        'chargebacks_total_count': len(user_chargebacks),
        'days_since_last_chargeback': compute_days_since_last(transaction_time, user_chargebacks)
    }

4 Создайте пайплайн с временными ограничениями

Используйте библиотеки, которые заточены под временные данные. Например, Featuretools с временными cutoff:

import featuretools as ft

# Создаем entity set
es = ft.EntitySet()

# Добавляем entities с временными метками
es = es.add_dataframe(
    dataframe_name="transactions",
    dataframe=transactions,
    index="transaction_id",
    time_index="timestamp"
)

# Определяем cutoff times для каждой транзакции
cutoff_times = transactions[['transaction_id', 'timestamp']].copy()
cutoff_times.columns = ['instance_id', 'time']

# Генерируем фичи с учетом временных ограничений
feature_matrix, feature_defs = ft.dfs(
    entityset=es,
    target_dataframe_name="transactions",
    cutoff_time=cutoff_times,  # Ключевой параметр!
    cutoff_time_in_index=True,
    training_window=ft.Timedelta("30 days"),  # Только последние 30 дней
    verbose=True
)

Три типа временных утечек, которые вы пропустили

Проверка на практике: тест временной согласованности

Создайте простой тест, который запускается в CI/CD:

def test_temporal_integrity(data_pipeline):
    """Проверяем, что нет утечек из будущего"""
    
    # Берем случайную транзакцию
    sample = transactions.sample(1)
    transaction_time = sample['timestamp'].iloc[0]
    
    # Получаем все фичи для этой транзакции
    features = data_pipeline.compute_features(sample)
    
    # Проверяем каждую фичу
    for feature_name, feature_value in features.items():
        # Получаем данные, использованные для вычисления фичи
        source_data = data_pipeline.get_feature_source_data(feature_name, sample)
        
        # Проверяем, что все source_data.timestamp <= transaction_time
        max_source_time = source_data['timestamp'].max()
        
        assert max_source_time <= transaction_time, \
            f"Утечка в фиче {feature_name}: {max_source_time} > {transaction_time}"
    
    return True

Что делать с задержками в данных?

Chargebacks приходят через 60 дней. Отзывы пользователей — через неделю. Это реальность production. Решение — использовать два типа фичей:

1. Real-time фичи: то, что известно в момент транзакции (баланс, история транзакций до этого момента)
2. Delayed фичи: обновляются позже, когда приходят данные (chargebacks, отзывы)

В обучении вы должны симулировать эту задержку. Если chargeback приходит через 60 дней, то при обучении на транзакции от 1 января вы можете использовать chargebacks только до 1 января, даже если в реальных данных у вас есть chargebacks до 1 марта.

Инструменты и библиотеки, которые спасут вас

• Temporian от Google — специально для временных данных с strict causality
• Featuretools с cutoff times — автоматически соблюдает временные ограничения
• MLflow — логируйте не только метрики, но и временные диапазоны данных
• Great Expectations — создавайте тесты на временную целостность

Но инструменты — это только половина дела. Главное — изменить мышление. Каждый раз, когда вы создаете фичу, задавайте вопрос: "Эта информация была бы доступна в момент предсказания в production?"

Связь с другими проблемами ML-инфраструктуры

Временные утечки — это не изолированная проблема. Она связана с:

• Воспроизводимостью экспериментов. Если вы не контролируете временные аспекты, эксперименты невозможно воспроизвести. Как и в случае с бенчмаркингом длинных контекстов LLM, где временные метки токенов критически важны.
• Дрейфом данных. Временные утечки маскируют реальный дрейф. Модель кажется стабильной, потому что она "подглядывает" в будущее.
• Безопасностью. Как и в случае с атаками на LLM, утечка данных — это фундаментальная уязвимость архитектуры.

Чеклист перед выкаткой модели

1. Проверьте, что train-test split хронологический
2. Убедитесь, что все фичи вычисляются только на данных ДО момента предсказания
3. Протестируйте на синтетических данных с известными временными паттернами
4. Запустите модель в shadow mode на свежих данных и сравните с production
5. Документируйте временные ограничения для каждой фичи

И последний совет: создайте в команде культуру "временного мышления". Каждый PR с новыми фичами должен включать ответ на вопрос: "Как эта фича будет вычисляться в реальном времени в production?"

P.S. Если вы думаете, что эта проблема вас не касается, потому что вы работаете с LLM, подумайте еще раз. Галлюцинации в LLM часто возникают из-за нарушения временных связей в тренировочных данных. Модель "помнит" информацию из будущих документов при генерации исторических текстов. Принцип тот же — только масштаб больше.