Fonction de perte pour les encodeurs automatiques

J'expérimente un peu les auto-encodeurs, et avec tensorflow j'ai créé un modèle qui essaie de reconstruire l'ensemble de données MNIST.

Mon réseau est très simple: X, e1, e2, d1, Y, où e1 et e2 sont des couches de codage, d2 et Y sont des couches de décodage (et Y est la sortie reconstruite).

X a 784 unités, e1 a 100, e2 a 50, d1 a encore 100 et Y 784 à nouveau.

J'utilise sigmoids comme fonctions d'activation pour les couches e1, e2, d1 et Y. Les entrées sont en [0,1] et devraient donc être les sorties.

Eh bien, j'ai essayé d'utiliser l'entropie croisée comme fonction de perte, mais la sortie était toujours un blob, et j'ai remarqué que les poids de X à e1 convergeraient toujours vers une matrice à valeur nulle.

D'un autre côté, l'utilisation d'erreurs quadratiques moyennes comme fonction de perte produirait un résultat décent, et je suis maintenant en mesure de reconstruire les entrées.

Pourquoi est-ce si? J'ai pensé que je pouvais interpréter les valeurs comme des probabilités, et donc utiliser l'entropie croisée, mais évidemment je fais quelque chose de mal.

Je pense que la meilleure réponse à cela est que la fonction de perte d'entropie croisée n'est tout simplement pas bien adaptée à cette tâche particulière.

En adoptant cette approche, vous dites essentiellement que les vraies données MNIST sont binaires et que vos intensités de pixels représentent la probabilité que chaque pixel soit allumé. Mais nous savons que ce n'est pas vraiment le cas. L'inexactitude de cette hypothèse implicite nous pose alors des problèmes.

Nous pouvons également examiner la fonction de coût et voir pourquoi elle pourrait être inappropriée. Disons que notre valeur de pixel cible est de 0,8. Si nous traçons la perte MSE et la perte d'entropie croisée$- [ (\text{target}) \log (\text{prediction}) + (1 - \text{target}) \log (1 - \text{prediction}) ]$ (normaliser ceci pour que son minimum soit à zéro), on obtient:

Nous pouvons voir que la perte d'entropie croisée est asymétrique. Pourquoi voudrions-nous cela? Est-il vraiment pire de prédire 0,9 pour ce 0,8 pixel que de prédire 0,7? Je dirais que c'est peut-être mieux, si quelque chose.

Nous pourrions probablement entrer plus en détail et comprendre pourquoi cela conduit aux taches spécifiques que vous voyez. Je suppose que c'est parce que les intensités de pixels sont supérieures à 0,5 en moyenne dans la région où vous voyez le blob. Mais en général, il s'agit d'un cas où les hypothèses de modélisation implicite que vous avez formulées sont inappropriées pour les données.

J'espère que cela pourra aider!