Train, validation и test: как разделить данные

Train-выборка используется для подбора параметров модели. Validation — для выбора признаков, гиперпараметров и порогов. Test хранится до финальной оценки и имитирует новые данные, которых команда не видела при принятии решений.

Если много раз смотреть на test и менять модель, test фактически становится validation. Финальная метрика будет оптимистичной, даже если веса модели напрямую на test не обучались. Для продолжительной разработки нужен новый holdout или корректная схема cross-validation.

Базовый случай с независимыми объектами можно разделить случайно. Для классификации часто сохраняют доли классов через stratification, особенно при редком положительном классе.

Время и группы меняют split

Для прогноза будущего случайное перемешивание часто создаёт утечку: модель обучается на более поздних объектах и проверяется на прошлом. Делите по времени так, чтобы validation и test шли после train, а признаки вычислялись только из доступной на тот момент информации.

Связанные строки одного пользователя, пациента, устройства или документа должны попадать в одну часть. Иначе модель узнаёт особенности группы на train и демонстрирует завышенное качество на почти тех же объектах в test. Используйте group split.

Правильная схема соответствует production-вопросу: на каких объектах и в какой момент модель будет делать прогноз. Универсальной пропорции 80/10/10 нет.

Pipeline обучается только на train

Импутация, масштабирование, словарь категорий, отбор признаков и oversampling тоже являются обучением. Их параметры fit-ят на train и применяют к validation/test. Если сначала нормализовать всю таблицу, статистики будущих частей проникнут в train.

Удобно собирать преобразования и модель в единый pipeline: cross-validation тогда повторяет fit преобразований внутри каждого fold. После выбора решения модель можно переобучить на train+validation и один раз оценить на нетронутом test — если это было частью плана.

Сохраняйте сами идентификаторы split и seed. Воспроизводимый baseline важнее случайно удачного разбиения, а расхождение offline и production часто начинается именно с неверной схемы оценки.

Проверка пересечения пользователей между выборками

Таблица может содержать несколько строк одного человека. Разделение по строкам способно поместить одного пользователя и в обучение, и в проверку. Для задачи обобщения на новых пользователей нужно разделять группы, а не независимо тасовать события. Ниже показан аудит уже созданных выборок.

train_users = {10, 11, 12}
validation_users = {13, 14}
test_users = {15, 16}
assert train_users.isdisjoint(validation_users)
assert train_users.isdisjoint(test_users)
assert validation_users.isdisjoint(test_users)
print("Пересечений пользователей нет")

Если задача — прогноз будущего поведения знакомых пользователей, групповой запрет может быть лишним, зато становится важен порядок времени. До split сначала сформулируйте, на каких объектах и в какой момент модель будет работать. После этого проверяйте пересечения по нужным ключам: пользователю, устройству, организации или источнику снимка. Хороший split воспроизводит будущий сценарий, а не просто даёт три непересекающихся набора строк.

Продолжите разбор: Data leakage в машинном обучении: как найти утечку.