Тестовая выборка (Test Set)

Тестовая выборка (test set) — это подмножество датасета, которое резервируют для проверки уже обученной модели. Проще всего запомнить правило так: тестовую выборку используют не для обучения и не для выбора лучшей версии модели, а для финальной оценки того, как модель обобщает на ранее невидимые данные.

Английский термин: test set. Также встречается: тестовый набор данных, hold-out test set. В базовой схеме машинного обучения его отделяют от обучающей выборки (training set) и валидационной выборки (validation set); один и тот же пример, по официальному глоссарию Google, должен принадлежать только одному из этих подмножеств.

Простыми словами

Грубо говоря, тестовая выборка — это «экзамен», который вы не показываете модели заранее. Вы можете тренироваться на учебнике и проверять себя на черновиках, но настоящий результат узнаёте только на отдельном комплекте заданий, которые не участвовали в подготовке.

Зачем это нужно? Если проверять модель на тех же данных, на которых она училась, можно получить слишком оптимистичную картину. Отдельный test set нужен именно для ответа на практический вопрос: «Что будет, когда модель увидит новые примеры, которых раньше не было?»

Как это работает

Официальные источники сходятся в трёх принципах. Первый: часть данных удерживают отдельно как test set. Второй: test set не должен использоваться для обучения или выбора гиперпараметров. Третий: даже если вы применяете кросс-валидацию (cross-validation) на этапе разработки, финальную проверку всё равно делают на отдельной отложенной тестовой выборке.

Исходный датасет
├─ Обучающая выборка (training set)
│  └─ на ней модель подгоняет параметры
├─ Валидационная выборка (validation set)
│  └─ на ней сравнивают варианты модели во время разработки
└─ Тестовая выборка (test set)
   └─ на ней делают только финальную оценку

Последовательность:
1) Разделить данные на непересекающиеся части.
2) Обучить модель на training set.
3) Подобрать настройки по validation set или через cross-validation.
4) Один раз проверить итоговую версию на test set.
5) Зафиксировать финальную метрику.

Google также отмечает, что метрика или loss на test set обычно менее смещены и качественнее отражают реальное качество, чем training loss или validation loss, потому что test set связан с обучением только косвенно. Но это верно лишь до тех пор, пока вы не начинаете регулярно подглядывать в test set и менять модель по его результатам.

Отсюда важная практическая деталь: test set может «изнашиваться». В курсе Google Crash Course прямо говорится, что повторное использование тестовой выборки снижает доверие к метрике. Если вы несколько раз посмотрели на тестовые результаты, поменяли модель и снова проверили её на тех же тестовых данных, это уже не совсем независимая финальная проверка.

Где применяется

• Финальная оценка классификатора или регрессора. После обучения модель проверяют на отложенной части данных, чтобы понять, как она ведёт себя на новых примерах.
• Проверка после подбора модели. В руководстве scikit-learn по model selection отдельно подчёркивается: даже если во время разработки вы используете кросс-валидацию, test set всё равно нужно сохранить для финальной оценки.
• Фреймворк-ориентированные пайплайны. В tutorial TensorFlow показан рабочий сценарий: данные делят на train и test, а затем проверяют итоговое качество через model.evaluate(...) или вручную накапливают метрики на test dataset.
• Сравнение нескольких кандидатов по одной честной процедуре. Если у вас есть несколько вариантов модели, архитектуры или признаков, сначала отбирают кандидатов без участия test set, а потом сравнивают финалистов на одном и том же отложенном наборе.

Практический пример

Ниже — минимальная схема разбиения в scikit-learn. По официальной документации train_test_split создаёт случайные train/test подмножества, а если не указать train_size и test_size, по умолчанию используется test_size=0.25.

from sklearn.model_selection import train_test_split

# X — признаки, y — целевая переменная
X_train, X_test, y_train, y_test = train_test_split(
    X, y, random_state=42
)

# Если train_size и test_size не заданы,
# документация scikit-learn указывает default test_size = 0.25

# 1) Обучение — только на train
model.fit(X_train, y_train)

# 2) После завершения настройки — финальная проверка на test
pred = model.predict(X_test)

# 3) Далее считается выбранная метрика на y_test и pred

Если вы работаете в TensorFlow/Keras, финальная проверка часто выглядит так:

test_loss, test_metric = model.evaluate(test_dataset)

Практический вердикт: если вы посмотрели на результат на test set, изменили модель и снова проверили её на том же наборе, для действительно честной финальной оценки лучше выделить новый hold-out test set.

Чем отличается от…

Коротко: validation отвечает на вопрос «какую версию выбрать», а test set — «как выбранная версия выглядит на новых данных в финальной проверке».

Ограничения и заблуждения

• Заблуждение: test set можно использовать для подбора гиперпараметров. Нет. Как только вы выбираете модель по тестовой метрике, test set начинает участвовать в model selection.
• Заблуждение: test set — это просто любая отложенная часть данных. Не совсем. Он ценен именно как независимый финальный контроль, а не как ещё один рабочий сплит для экспериментов.
• Заблуждение: есть универсальная правильная доля разбиения. Источники подтверждают сам принцип отдельной тестовой выборки, но не задают единственного «правильного» соотношения train/validation/test. Это зависит от задачи и объёма данных.
• Заблуждение: если есть кросс-валидация, тестовая выборка уже не нужна. Руководство scikit-learn говорит обратное: hold-out test set стоит сохранить для финальной оценки и в этом сценарии.
• Ограничение: test set можно износить. Если постоянно смотреть на одну и ту же тестовую метрику и менять систему под неё, доверие к результату падает.

Редакционное ограничение: в использованных официальных источниках хорошо описаны назначение test set, непересекающиеся сплиты, риск повторного использования и финальная оценка после cross-validation. Но они не устанавливают универсальные размеры сплитов и не закрепляют единый словарь для всех рабочих процессов: в разных командах могут встречаться термины validation, dev и test fold с немного разным операционным смыслом.

Связанные термины и материалы

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

Источники

• Machine Learning Glossary | Google for Developers
• Datasets: Dividing the original dataset | Machine Learning | Google for Developers
• 3.1. Cross-validation: evaluating estimator performance — scikit-learn 1.9.0 documentation
• train_test_split — scikit-learn 1.9.0 documentation
• Custom training: walkthrough | TensorFlow Core

Вопросы и ответы

Тестовая и валидационная выборка — это одно и то же?

Нет. Валидационную выборку используют во время разработки, чтобы сравнивать варианты модели. Тестовая выборка нужна для финальной независимой оценки уже выбранной версии.

Можно ли несколько раз проверять модель на одном и том же test set?

Технически можно, но Google предупреждает, что test set от этого «изнашивается»: доверие к метрике снижается, если вы подстраиваете систему под повторяющиеся тестовые результаты.

Нужен ли test set, если я использую cross-validation?

Да. Руководство scikit-learn рекомендует всё равно держать отдельный hold-out test set для финальной оценки после всех экспериментов и выбора модели.

Какой размер test set правильный?

Универсального процента сам термин не задаёт. Источники подтверждают необходимость отдельной тестовой выборки, но конкретная доля зависит от задачи, объёма данных и выбранной схемы валидации.

Почему метрика на test set обычно ценнее, чем на train set?

Потому что test set не участвует в прямом обучении модели. По глоссарию Google, test loss обычно менее смещён и качественнее отражает реальное поведение модели, чем training loss или validation loss.