Erreur de validation inférieure à l'erreur d'apprentissage?

J'ai trouvé deux questions ici et ici à propos de ce problème, mais il n'y a pas encore de réponse ou d'explication évidente. J'applique le même problème lorsque l'erreur de validation est inférieure à l'erreur d'apprentissage dans mon réseau de neurones à convolution. Qu'est-ce que ça veut dire?

Il est difficile d’être certain de ne pas connaître votre méthodologie actuelle (par exemple, méthode de validation croisée, métrique de performance, méthode de fractionnement des données, etc.).

En règle générale, une erreur d’entraînement sous - estime presque toujours votre erreur de validation. Cependant, il est possible que l'erreur de validation soit inférieure à la formation. Vous pouvez le penser de deux manières:

1. Votre formation a eu beaucoup de cas difficiles à apprendre
2. Votre jeu de validation avait surtout des cas «faciles» à prédire

C'est pourquoi il est important que vous évaluiez réellement votre méthodologie de formation de modèle. Si vous ne divisez pas correctement vos données pour la formation, vos résultats conduiront à des conclusions confuses, sinon simplement incorrectes.

Je pense à l'évaluation du modèle dans quatre catégories différentes:

1. Underfitting - Erreur de validation et d’entraînement élevée

2. Overfitting - L'erreur de validation est élevée, l'erreur d'apprentissage est faible

3. Bon ajustement - Erreur de validation faible, légèrement supérieure à l'erreur d'apprentissage

4. Ajustement inconnu - Erreur de validation basse, erreur d'apprentissage 'élevée'

Je dis ajustement «inconnu» parce que le résultat est contre-intuitif au fonctionnement de l'apprentissage automatique. L'essence de ML consiste à prédire l'inconnu. Si vous êtes mieux à même de prédire l'inconnu que ce que vous avez "appris", autant que je sache, les données entre la formation et la validation doivent être différentes. Cela peut signifier que vous devez réévaluer votre méthode de fractionnement des données, ajouter plus de données ou éventuellement modifier votre métrique de performance (mesurez-vous réellement la performance que vous souhaitez?).

MODIFIER

Répondre à la référence du PO à une question précédente sur les lasagnes au python .

Cela suggère que vous disposez de suffisamment de données pour ne pas nécessiter de validation croisée et simplement pour votre formation, votre validation et vos sous-ensembles de données de test. Maintenant, si vous regardez le tutoriel sur les lasagnes, vous pouvez voir que le même comportement est observé en haut de la page. J'aurais du mal à croire que les auteurs publieraient de tels résultats si c'était étrange, mais au lieu de supposer qu'ils sont corrects, regardons plus loin. La section qui nous intéresse le plus ici se trouve dans la section de la boucle d’entraînement . Juste au-dessus du bas, vous verrez comment les paramètres de perte sont calculés.

La perte d'apprentissage est calculée sur l' ensemble de données de formation . De même, la perte de validation est calculée sur l' ensemble du jeu de données de validation . L'ensemble de formation est généralement au moins 4 fois plus grand que la validation (80-20). Étant donné que l'erreur est calculée pour tous les échantillons, vous pouvez vous attendre à environ 4 fois la mesure de perte de l'ensemble de validation. Vous remarquerez cependant que les pertes d’entraînement et de validation se rapprochent à mesure que l’entraînement se poursuit. C'est intentionnel, car si votre erreur d'entraînement commence à être inférieure à votre erreur de validation, vous commencerez à sur-adapter votre modèle !!!

J'espère que cela clarifie ces erreurs.

Une possibilité: si vous utilisez une couche de régularisation des abandons sur votre réseau, il est raisonnable que l'erreur de validation soit plus petite que l'erreur d'apprentissage. En général, l’abandon est activé lors de la formation, mais désactivé lors de l’évaluation du jeu de validation. Vous obtenez une fonction plus lisse (signifie généralement mieux) dans ce dernier cas.

Je n'ai pas assez de points pour commenter la réponse de @ DK, mais voici maintenant une réponse à la FAQ de la documentation de Keras:

"Pourquoi la perte d’entraînement est-elle beaucoup plus élevée que la perte d’essais?

Un modèle Keras a deux modes: formation et test. Les mécanismes de régularisation, tels que l'abandon et la régularisation du poids L1 / L2, sont désactivés au moment du test.

De plus, la perte d'apprentissage correspond à la moyenne des pertes sur chaque lot de données d'apprentissage. Étant donné que votre modèle évolue avec le temps, la perte sur les premiers lots d'une époque est généralement supérieure à celle des derniers lots. D'autre part, la perte de test pour une époque est calculée à l'aide du modèle tel qu'il est à la fin de l'époque, ce qui permet de réduire la perte. "

mes 2 centimes: j'ai aussi eu le même problème même sans avoir de couches abandonnées. Dans mon cas, les coupables étaient constitués de couches de normes de lots. Lorsque je les ai supprimés, la perte d'entraînement est devenue similaire à la perte de validation. Cela est probablement dû au fait que, pendant l’entraînement, norm-batch utilise la moyenne et la variance du lot en entrée donné, qui peuvent être différentes d’un lot à l’autre. Toutefois, au cours de l’évaluation, la norme et la variance en cours d’exécution reposent sur des propriétés bien meilleures que celles de la moyenne et de la variance d’un lot au cours de la formation. Du moins, c’est comme ça que batch-norm est implémenté dans pytorch

Une autre possibilité qui combine à la fois la réponse de @cdeterman et de @DK est si vous utilisez un mécanisme d’augmentation de données. L’augmentation des données d’Infact n’est en général effectuée que sur le jeu d’entraînement et non sur le jeu de validation (comme pour la régularisation du décrochage), ce qui peut conduire à un jeu de validation contenant des cas "plus faciles à prédire" que ceux du jeu de formation.

J'ai eu des résultats similaires (la perte au test était significativement inférieure à la perte à l'entraînement). Une fois que j'ai supprimé la régularisation des abandons, la perte est devenue presque égale.

@cdeterman et @DK ont une bonne explication. Je voudrais une raison de plus - data leakage. Une partie de vos données de train est "étroitement liée" aux données de test.

Exemple potentiel: imaginez que vous avez 1 000 chiens et 1 000 chats avec 500 images similaires par animal (certains propriétaires aiment prendre des photos de leurs animaux dans des positions très similaires), par exemple sur l'arrière-plan. Ainsi, si vous effectuez une répartition aléatoire 70/30, vous obtiendrez une fuite de données de train dans les données de test.

En termes simples, si les pertes d’entraînement et de validation sont calculées correctement, il est impossible que la perte d’entraînement soit supérieure à la perte de validation. En effet, la rétro-propagation réduit DIRECTEMENT l'erreur calculée sur l'ensemble d'apprentissage et seul INDIRECTLY (non même garanti!) Réduit l'erreur calculée sur l'ensemble de validation.

Il doit y avoir quelques facteurs supplémentaires qui sont différents lors de la formation et lors de la validation. Le décrochage est un bon exemple, mais il peut y en avoir d’autres. Assurez-vous de consulter la documentation de la bibliothèque que vous utilisez. Les modèles et les couches peuvent généralement avoir des paramètres par défaut auxquels nous ne faisons généralement pas attention.

Une fluctuation inférieure à l’erreur d’entraînement peut être causée par des fluctuations associées à l’abandon ou autrement, mais si elle persiste à long terme, cela peut indiquer que les ensembles de données d’apprentissage et de validation n’ont pas été réellement extraits des mêmes ensembles statistiques. Cela peut se produire si vos exemples proviennent d'une série et si vous n'avez pas correctement randomisé les ensembles de données de formation et de validation.

A cette époque, les méthodes basées sur les gradients stochastiques sont presque toujours l'algorithme de choix pour un apprentissage en profondeur. Cela signifie que les données entrent par lots, que les gradients sont calculés et les paramètres mis à jour. Cela signifie que vous pouvez également calculer la perte sur les données lorsque chaque lot est sélectionné. Dans ce cadre, il y a deux façons de la façon dont la perte est calculé que je peux penser à ce qui peut conduire à ce phénomène que l'erreur de formation est supérieure à l'erreur de validation. Je montre ci-dessous que Keras semble en fait calculer les erreurs dans l'échantillon de cette manière.

1.) L' erreur d'apprentissage est moyennée sur toute une époque, plutôt en une seule fois à la fin de l'époque, mais l'erreur de validation est seulement à la fin de l'époque. Notez que l'erreur de validation présente l'avantage d'être entièrement mise à jour, tandis que l'erreur d'apprentissage inclut des calculs d'erreur avec moins de mises à jour. Bien entendu, asymptotiquement, cet effet devrait généralement disparaître.

2.) L' erreur de formation est calculée avant la mise à jour par lot. Dans une méthode basée sur un gradient stochastique, il y a du bruit dans le dégradé. En grimpant une colline, il est fort probable que la perte globale calculée diminue sur tous les échantillons d’entraînement. Cependant, lorsque l’on se rapproche beaucoup du mode, le sens de la mise à jour sera négatif par rapport aux échantillons de votre lot. Mais comme nous rebondissons sur un mode, cela signifie en moyenne que nous devons choisir une direction positive par rapport aux échantillons .de lot. Maintenant, si nous sommes sur le point de mettre à jour les échantillons d’un lot donné, cela signifie qu’ils ont probablement été contournés par de nombreuses mises à jour de lot dans lesquelles ils n’étaient pas inclus, en calculant leur perte avant la mise à jour, c’est alors que le stochastique les méthodes ont poussé les paramètres les plus en faveur des autres échantillons de votre jeu de données, nous donnant ainsi un léger biais à la hausse dans la perte attendue.

Notez que bien que asymptotiquement, l'effet de (1) disparaisse, (2) ne disparaît pas! Je montre ci-dessous que Keras semble faire les deux (1) et (2).

(1) Montrant que les métriques sont moyennées sur chaque lot de l'époque, plutôt que toutes en même temps à la fin. Notez l’énorme différence entre la précision de l’échantillon et celle de val_accuracy favorisant val_accuracy à la toute première époque. Cela est dû au fait que certaines erreurs dans l'échantillon ont été calculées avec très peu de mises à jour par lots.

>>> 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) L'erreur d'affichage est calculée avant la mise à jour pour chaque lot. Notez que pour l'époque 1, lorsque nous utilisons batch_size = nRows(c'est-à-dire toutes les données d'un lot), l'erreur dans l'échantillon est d'environ 0,5 (estimation aléatoire) pour l'époque 1, mais l'erreur de validation est de 0,82. Par conséquent, l'erreur dans l'échantillon a été calculée avant la mise à jour par lot, tandis que l'erreur de validation a été calculée après la mise à jour par lot.

>>> 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