Почему только три раздела? (обучение, проверка, тестирование)

Когда вы пытаетесь подогнать модели к большому набору данных, общий совет - разбить данные на три части: набор данных обучения, проверки и тестирования.

Это связано с тем, что модели обычно имеют три «уровня» параметров: первый «параметр» - это класс модели (например, SVM, нейронная сеть, случайный лес), второй набор параметров - это параметры «регуляризации» или «гиперпараметры» ( например, коэффициент штрафа Лассо, выбор ядра, структура нейронной сети) и третий набор - это то, что обычно считается «параметрами» (например, коэффициенты для ковариат).

Учитывая класс модели и выбор гиперпараметров, выбирают параметры, выбирая параметры, которые минимизируют ошибки в обучающем наборе. Учитывая класс модели, можно настроить гиперпараметры, минимизировав ошибку на множестве проверки. Один выбирает класс модели по производительности на тестовом наборе.

Но почему не больше разделов? Часто можно разделить гиперпараметры на две группы и использовать «проверку 1», чтобы соответствовать первой, и «проверку 2», чтобы соответствовать второй. Или можно даже рассматривать размер разделения обучающих данных / проверочных данных как гиперпараметр, подлежащий настройке.

Это уже распространенная практика в некоторых приложениях? Есть ли теоретическая работа по оптимальному разделению данных?

machine-learning model-selection data-mining charles.y.zheng
источник

Ответы:

Во-первых, я думаю, вы ошибаетесь в том, что делают три раздела. Вы не делаете никакого выбора на основе тестовых данных. Ваши алгоритмы корректируют свои параметры на основе данных обучения. Затем вы запускаете их для проверки данных, чтобы сравнить ваши алгоритмы (и их обученные параметры) и выбрать победителя. Затем вы запускаете победителя на своих тестовых данных, чтобы дать вам прогноз того, насколько хорошо он будет в реальном мире.

Вы не проверяете данные обучения, потому что это будет соответствовать вашим моделям. Вы не останавливаетесь на оценке победителя шага валидации, потому что вы итеративно корректировали вещи, чтобы получить победителя на шаге валидации, и поэтому вам нужен независимый тест (который вы специально не настраивали), чтобы дать вам Идея о том, как хорошо вы будете делать за пределами текущей арены.

Во-вторых, я думаю, что одним из ограничивающих факторов здесь является количество данных, которые у вас есть. В большинстве случаев мы даже не хотим разбивать данные на фиксированные разделы вообще, следовательно, CV.

Wayne
источник

Концептуальная проблема, с которой я столкнулся, заключается в том, что если вы сравниваете достаточно моделей, вы эффективно подгоняете данные проверки, когда вы «выбираете победителя», используя данные проверки. Следовательно, все еще может быть пункт в разделении данных проверки.

charles.y.zheng

Я думаю, что слой обучения-валидации и слой валидации-тестирования в некотором смысле служат разным целям, и что вам в конечном итоге придется сравнивать модели по общему набору валидации, если вы собираетесь объявить победителя. Поэтому я не уверен, что дополнительные слои помогут. (Хотя мои знания недостаточно глубоки, чтобы действительно знать.) Самое близкое, что я могу придумать к вашему предложению, - это как проходил конкурс Netflix. Я считаю, что они использовали частичные тестовые наборы, чтобы удержать команды от подъема градиента тестовых наборов, но я думаю, что это другое.

Уэйн

@ user10882, ваш комментарий неверный, как и Firebugs. Как (1) параметры модели (веса, пороги), так и (2) так называемые «гипер» параметры (количество скрытых слоев, количество деревьев решений) могут иметь совершенно разную интерпретацию и восприятие, но все это просто параметры, различающие разные модели . Используйте данные обучения, чтобы оптимизировать их все, используйте данные проверки, чтобы избежать перебора, и используйте перекрестную проверку, чтобы убедиться, что ваши результаты стабильны. Тестовые данные служат только для определения ожидаемой производительности вашей модели, не используйте ее для принятия / отклонения.

Ицен де Бур

@RubenvanBergen: Я понимаю, что вы говорите, и это полезно и полезно указать пользователю user10882. Но я до сих пор утверждаю, что это в конечном итоге техническая. Допустим, вы используете алгоритм градиентного спуска, который использует данные обучения, чтобы вывести направление шага (включая полиномиальную степень ) вместе с процедурой проверки, которая добавляет потерю проверки к потере обучения на каждом шаге алгоритма градиентного спуска (аналогично раннему остановки). Теперь разница между «нормальным» или «гипер» уже не актуальна: это зависит от процедуры.

n

$n$

Ицен де Бур

@YtsendeBoer: Достаточно справедливо - если вы используете sth, как ранняя остановка на основе проверки, я согласен, что границы размыты, по крайней мере, с точки зрения процедуры оптимизации. На мой взгляд, это не полностью объединяет понятие «гиперпараметр» с понятием обычного. Есть еще много ситуаций, когда к ним относятся по-разному, и я также думаю о них по-разному с точки зрения их роли в определении модели. В любом случае, я надеюсь, что это обсуждение было полезным для других, чтобы проиллюстрировать (тонкие) различия и сходства между этими понятиями =).

Рубен ван Берген

Это интересный вопрос, и я нашел, что это полезно с ответом от @Wayne.

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

Обычно у нас есть два набора данных: обучение и тестирование. Обучающий используется для определения параметров моделей или подгонки моделей. Тестирование используется для оценки производительности модели в невидимых данных (или данных реального мира).

Если мы просто сделаем один шаг в обучении, очевидно, что есть процесс обучения и тестирования (или проверки).

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

Дао Ву Хоанг
источник