Как находить вредные обучающие примеры перед fine-tune: influence functions, TracIn и data pruning в production ML

В production ML «плохие» train-примеры могут стоить дорого: кластер mislabeled, устаревших или аномальных объектов способен стабильно ухудшать fine-tune на свежем срезе данных. Частая ошибка - чистить датасет только по эвристикам и не проверять, какие samples реально увеличивают loss на production-like validation.

1. Influence Functions

Идея: оценить, как изменится loss на validation-примере z_val, если немного увеличить вес train-примера z_train.

I(z_train, z_val) ≈ - ∇L_val^T H^-1 ∇L_train

где H - Hessian по параметрам модели.

Если influence большой и положительный, train-пример, вероятно, увеличивает validation loss и вредит качеству.

Плюсы:
- аккуратная теоретическая постановка;
- можно связывать конкретные train-примеры с конкретными ошибками модели.

Минусы:
- дорогой H^-1;
- плохо масштабируется на большие нейросети;
- чувствителен к non-convexity, batchnorm/dropout, чекпоинтам и приближению Hessian.

В production обычно используют приближения: LiSSA, conjugate gradients, low-rank approximation или считают influence только для последнего слоя / head модели.

2. TracIn

Более инженерный вариант: train-пример полезен для val-примера, если их градиенты по ходу обучения направлены похоже. Вреден - если направлены противоположно.

TracIn(z_train, z_val) = Σ_c η_c · ∇L_train(θ_c) · ∇L_val(θ_c)

где θ_c - чекпоинты, η_c - learning rate.

Сильно отрицательный score означает: train-пример тянет модель против направления, полезного для validation.

Мини-скетч для последнего слоя:

for ckpt in checkpoints:
    model.load_state_dict(load(ckpt))

    g_val = mean_grad(model.head, val_loader)

    for i, batch in enumerate(train_subset):
        g_train = grad(model.head, batch)
        scores[i] += lr[ckpt] * dot(g_train, g_val)

harmful = argsort(scores)[:K]

Практический совет: считайте score не по всему validation, а по важным production-срезам: новые пользователи, редкие классы, проблемные регионы, свежий drift, сегменты с высокой бизнес-ценой или высоким SLA.

3. Data pruning перед fine-tune

Рабочий пайплайн:

1. Зафиксировать production-like validation set без leakage.
2. Обучить baseline / fine-tune и сохранить несколько чекпоинтов.
3. Посчитать influence или TracIn для train→val.
4. Проверить top harmful samples:
- label noise;
- outdated distribution;
- конфликтующие дубликаты;
- corrupted inputs;
- неправильная task/schema version.
5. Удалить, downweight или отправить на relabeling.
6. Повторить fine-tune и проверить не только общий metric, но и regression по сегментам.

Production-пример: перед дообучением рекомендательной модели на свежих логах можно найти старые взаимодействия с изменившейся таксономией товаров, конфликтующие labels после миграции схемы или ботовый трафик, который ухудшает ranking loss на свежем holdout.

4. Предупреждение

Не стоит слепо удалять все «вредные» примеры. Иногда они ухудшают текущий validation, но нужны для long-tail robustness, fairness или устойчивости к редким сценариям.

Безопаснее начинать с top-K, делать human-in-the-loop аудит, сравнивать варианты remove / downweight / relabel и смотреть trade-off между quality, latency пересчета, стоимостью разметки, воспроизводимостью и надежностью мониторинга.

Вывод:
Influence Functions и TracIn полезны не как магическая чистка данных, а как инженерный способ сделать fine-tuning менее токсичным к шуму, устаревшим данным и конфликтующей разметке.