Ошибка проверки меньше, чем ошибка обучения?

Здесь и здесь я нашел два вопроса об этой проблеме, но пока нет очевидного ответа или объяснения. Я навязываю ту же проблему, где ошибка проверки меньше, чем ошибка обучения в моей Convolution Neural Network. Что это обозначает?

Трудно быть уверенным, не зная вашей реальной методологии (например, метод перекрестной проверки, метрика производительности, метод разделения данных и т. Д.).

Однако, в целом, ошибка обучения почти всегда недооценивает вашу ошибку проверки. Однако возможно, что ошибка проверки будет меньше, чем обучение. Вы можете думать об этом двумя способами:

1. В вашем тренировочном наборе было много «сложных» случаев для изучения
2. В вашем наборе проверки были в основном «простые» случаи, которые можно предсказать

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

Я думаю об оценке модели в четырех разных категориях:

1. Недостаточное оснащение - высокий уровень ошибки валидации и обучения

2. Переоснащение - ошибка проверки высокая, ошибка обучения низкая

3. Хорошая подгонка - ошибка проверки низкая, немного выше, чем ошибка обучения

4. Неизвестная посадка - ошибка проверки низкая, ошибка обучения «высокая»

Я говорю «неизвестно», потому что результат противоречит тому, как работает машинное обучение. Суть ОД заключается в предсказании неизвестного. Если вы лучше предсказываете неизвестное, чем то, чему вы «научились», AFAIK, данные между обучением и проверкой должны быть в некотором роде разными. Это может означать, что вам нужно либо переоценить метод разделения данных, либо добавить дополнительные данные, либо, возможно, изменить метрику производительности (вы на самом деле измеряете желаемую производительность?).

РЕДАКТИРОВАТЬ

Чтобы ответить на ссылку ОП на предыдущий вопрос о лазаньи на питоне .

Это говорит о том, что у вас достаточно данных, чтобы не требовать перекрестной проверки, а просто иметь подмножества данных для обучения, проверки и тестирования. Теперь, если вы посмотрите учебник по лазаньи, вы увидите, что такое же поведение наблюдается в верхней части страницы. Мне было бы трудно поверить, что авторы опубликовали бы такие результаты, если бы это было странно, но вместо того, чтобы просто предполагать, что они верны, давайте посмотрим дальше. Здесь наиболее интересный раздел находится в разделе цикла обучения , чуть выше дна вы увидите, как рассчитываются параметры потерь.

Потеря обучения рассчитывается по всем обучающему набору данных . Аналогичным образом, потери при проверке рассчитываются по всему набору данных проверки . Тренировочный набор обычно в 4 раза больше, чем валидация (80-20). Учитывая, что ошибка рассчитывается по всем выборкам, вы можете ожидать примерно 4-кратного показателя потери набора проверки. Однако вы заметите, что потеря обучения и потеря проверки приближаются друг к другу, поскольку обучение продолжается. Это преднамеренно, как если бы ваша ошибка обучения стала меньше, чем ваша ошибка проверки, которую вы начинаете перегонять для вашей модели !!!

Я надеюсь, что это проясняет эти ошибки.

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

У меня недостаточно очков, чтобы прокомментировать ответ @ DK, но теперь на него есть ответы на часто задаваемые вопросы о документации Keras:

«Почему потери при обучении намного выше, чем при испытаниях?

Модель Keras имеет два режима: обучение и тестирование. Механизмы регуляризации, такие как выпадение веса и регуляция веса L1 / L2, отключаются во время тестирования.

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

мои 2 цента: у меня тоже была такая же проблема даже без выпадающих слоев. В моем случае виновниками были партии нормальных слоев. Когда я их удалил - потеря обучения стала похожа на потерю проверки. Вероятно, это произошло из-за того, что во время обучения норма партии использует среднее значение и дисперсию данной входной партии, которая может отличаться от партии к партии. Но во время оценки норма партии использует среднее значение и дисперсию, оба из которых отражают свойства всего обучающего набора намного лучше, чем среднее значение и дисперсию одной партии во время тренировки. По крайней мере, именно так пакетная норма реализована в pytorch

Другая возможность, которая каким- то образом объединяет ответ @cdeterman и @DK , - это если вы используете какой-то механизм дополнения данных. Фактическое увеличение данных обычно выполняется только на обучающем наборе, а не на проверочном наборе (как для регуляризации отсева), и это может привести к получению проверочного набора, содержащего «более простые» случаи, чем в обучающем наборе.

Я получил аналогичные результаты (потеря теста была значительно ниже, чем потеря тренировки). После того как я удалил регуляризацию отсева, обе потери стали практически равными.

@cdeterman и @DK имеют хорошее объяснение. Я хотел бы еще одну причину data leakage. Некоторая часть ваших данных о поездах "тесно связана" с данными испытаний.

Потенциальный пример: представьте, что у вас 1000 собак и 1000 кошек с 500 одинаковыми изображениями на питомца (некоторые владельцы любят фотографировать своих питомцев в очень похожих положениях), скажем, на заднем плане. Поэтому, если вы сделаете случайное разделение 70/30, вы получите утечку данных о поездах в тестовые данные.

Проще говоря, если потеря при обучении и потеря при проверке рассчитаны правильно, невозможно, чтобы потеря при обучении была выше потери при проверке. Это связано с тем, что обратное распространение DIRECTLY уменьшает ошибку, вычисленную на обучающем наборе, и только НЕПОСРЕДСТВЕННО (даже не гарантировано!) Уменьшает ошибку, вычисленную на наборе проверки.

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

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

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

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

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

Обратите внимание: асимптотически эффект (1) исчезает, а (2) - нет! Ниже я показываю, что Керас, похоже, выполняет и (1), и (2).

(1) Показывает, что метрики усредняются по каждому пакету в эпоху, а не по всем сразу в конце. Обратите внимание на ОГРОМНОЕ различие в точности выборки по сравнению с val_accuracy в пользу val_accuracy в самой первой эпохе. Это связано с тем, что некоторые ошибки в образце вычисляются при очень небольшом количестве пакетных обновлений.

>>> model.fit(Xtrn, Xtrn, epochs = 3, batch_size = 100, 
...                 validation_data = (Xtst, Xtst))
Train on 46580 samples, validate on 1000 samples
Epoch 1/3
46580/46580 [==============================] - 8s 176us/sample 
- loss: 0.2320 - accuracy: 0.9216 
- val_loss: 0.1581 - val_accuracy: 0.9636
Epoch 2/3
46580/46580 [==============================] - 8s 165us/sample 
- loss: 0.1487 - accuracy: 0.9662 
- val_loss: 0.1545 - val_accuracy: 0.9677
Epoch 3/3
46580/46580 [==============================] - 8s 165us/sample 
- loss: 0.1471 - accuracy: 0.9687 
- val_loss: 0.1424 - val_accuracy: 0.9699
<tensorflow.python.keras.callbacks.History object at 0x17070d080>

(2) Отображаемая ошибка вычисляется перед обновлением для каждой партии. Обратите внимание, что для эпохи 1, когда мы используем batch_size = nRows(т. Е. Все данные в одном пакете), ошибка выборки составляет около 0,5 (случайное угадывание) для эпохи 1, но ошибка проверки составляет 0,82. Поэтому ошибка выборки была вычислена до пакетного обновления, тогда как ошибка проверки была рассчитана после пакетного обновления.

>>> model.fit(Xtrn, Xtrn, epochs = 3, batch_size = nRows, 
...                 validation_data = (Xtst, Xtst))
Train on 46580 samples, validate on 1000 samples
Epoch 1/3
46580/46580 [==============================] - 9s 201us/sample 
- loss: 0.7126 - accuracy: 0.5088 
- val_loss: 0.5779 - val_accuracy: 0.8191
Epoch 2/3
46580/46580 [==============================] - 6s 136us/sample 
- loss: 0.5770 - accuracy: 0.8211 
- val_loss: 0.4940 - val_accuracy: 0.8249
Epoch 3/3
46580/46580 [==============================] - 6s 120us/sample 
- loss: 0.4921 - accuracy: 0.8268 
- val_loss: 0.4502 - val_accuracy: 0.8249