[PYTHON] À propos des tests dans la mise en œuvre de modèles d'apprentissage automatique

Un exemple qui vient avec un certain nombre de frameworks, une histoire sur la mise en œuvre d'un modèle d'apprentissage automatique. Ce qu'ils ont tous en commun, c'est qu'il n'y a pas de tests. Même un modèle d'apprentissage automatique fait partie du code de production une fois qu'il est intégré à l'application. Vous souhaitez intégrer une implémentation non testée dans votre environnement de production? Je ne pense pas que ce soit généralement le cas.

Il est facile d'oublier que les modèles d'apprentissage automatique sont plus précis au «moment de la sortie». La raison en est que le moment de la publication est le modèle qui a été formé en utilisant les données complètes et complètes disponibles à ce moment-là, et après cela, de plus en plus de données inconnues entreront. Par conséquent, il est très important de pouvoir vérifier à tout moment l'exactitude et la validité du modèle. C'est la même raison pour tester votre code régulier, ce qui signifie que ce n'est pas spécial parce qu'il s'agit d'un modèle d'apprentissage automatique.

Dans cet article, je vais vous expliquer comment tester ce modèle d'apprentissage automatique. Bien sûr, c'est la méthode que je pratique actuellement, et je pense que le savoir-faire de méthodes plus pratiques se répandra au fur et à mesure que l'application de l'apprentissage automatique aux applications progressera dans le futur.

Concevoir un modèle d'apprentissage automatique

Premièrement, il doit être bien conçu pour effectuer le test. Il y a un document qui expliquait ce point plus tôt, alors je voudrais en citer.

Conception de code pour éviter de pleurer avec l'apprentissage automatique

Model est un véritable modèle d'apprentissage automatique (construit avec scicit-learn, Chainer, TensorFlow), qui contient souvent tout le traitement. C'est une histoire de la diviser comme suit.

• Le formateur est responsable de l'apprentissage
• L'API de modèle relie le processus d'appel d'un modèle de l'extérieur
• Extraction de données et prétraitement vers DataProcessor
• Gérer les paramètres de formation, les modèles enregistrés, etc. dans Resource

Lorsqu'un problème tel qu'une imprécision se produit à cause de cela, est-ce un problème du modèle lui-même, est-il mauvais à entraîner, le modèle est-il correct et il y a un problème uniquement lors de son utilisation du côté de l'application? Est de pouvoir isoler et vérifier et tester s'il y a une erreur dans le prétraitement des données.

Cependant, la sortie de l'apprentissage automatique est indéfinie par rapport à un programme normal dans lequel l'entrée / la sortie peut être clairement définie. DataProcessor et Resource sont presque les mêmes que les programmes normaux, il est donc facile à tester, mais c'est un problème pour Trainer et Model API, y compris Model lui-même.

Je ne suis pas entré dans les détails sur ce point dans le matériel ci-dessus, mais j'aimerais jeter un coup d'œil à ces tests à partir d'ici.

Tester le modèle d'apprentissage automatique

Il y a quatre éléments principaux à tester dans un modèle d'apprentissage automatique:

• Test de fonctionnement: un test pour vérifier la mise en œuvre de l'apprentissage automatique pour les erreurs.
• Vérifier le test: un test pour vérifier la validité du modèle d'apprentissage automatique (comme une comparaison avec la ligne de base)
• Test d'intégration: un test pour voir si l'appel de l'application est réussi.
• Test d'évaluation: un test pour savoir si le service réel contribue à l'indice d'évaluation (KPI).

Je voudrais adopter une approche étape par étape de ces tests. Dans l'introduction du code suivante, je citerai le référentiel récemment développé suivant.

icoxfog417/tensorflow_qrnn

Ceci est basé sur TensorFlow, mais je pense que l'idée peut être utilisée avec d'autres bibliothèques (j'ai fait la même conception et les mêmes tests lors de l'utilisation de Chainer auparavant). Au contraire, lors de l'utilisation de TensorFlow, il y a certains points auxquels je suis accro pendant le test, donc je mentionnerai également comment gérer ces problèmes.

Test de fonctionnement

Dans le test de fonctionnement, nous vérifions si le modèle fonctionne de l'entrée à la sortie sans générer d'erreur. Dans le cas d'un modèle de réseau neuronal, il peut également être appelé contrôle avant.

Voici le code que j'ai réellement utilisé.

tensorflow_qrnn/test_tf_qrnn_forward.py

L'entrée peut être aléatoire, alors assurez-vous qu'elle passe par la sortie. Le test de fonctionnement est fréquemment utilisé (utilisé) pendant le développement dans le but de "vérifier aussi légèrement et rapidement que possible" s'il fonctionne pour le moment lors du développement ou de la réorganisation du modèle. En ce sens, la position est proche de la compilation.

Dans TensorFlow, lorsque unittest est exécuté, plusieurs tests partagent des informations de graphe global et une erreur involontaire se produit. Par conséquent, veuillez noter que vous devez séparer le graphique pour chaque scénario de test.

class TestQRNNForward(unittest.TestCase):

    def test_qrnn_linear_forward(self):
        batch_size = 100
        sentence_length = 5
        word_size = 10
        size = 5
        data = self.create_test_data(batch_size, sentence_length, word_size)

        with tf.Graph().as_default() as q_linear:
            qrnn = QRNN(in_size=word_size, size=size, conv_size=1)
            ...

En particulier, ce phénomène devient chaotique si la variable scope n'est pas désactivée. Fondamentalement, lors de l'utilisation de TensorFlow, il est important de couper fermement la portée de la variable avec variable_scope lors de la déclaration de variables (les doublons ne peuvent pas être vérifiés avec name_scope).

class QRNNLinear():

    def __init__(self, in_size, size):
        self.in_size = in_size
        self.size = size
        self._weight_size = self.size * 3  # z, f, o
        with tf.variable_scope("QRNN/Variable/Linear"):
            initializer = tf.random_normal_initializer()
            self.W = tf.get_variable("W", [self.in_size, self._weight_size], initializer=initializer)
            self.b = tf.get_variable("b", [self._weight_size], initializer=initializer)

Pour plus d'informations sur la portée, reportez-vous à cet article, veuillez donc vous y référer. Je vais le résumer). Dans tous les cas, veuillez garder à l'esprit les points suivants lorsque vous utilisez TensorFlow.

Vérifier le test

Une fois que vous avez un modèle qui passe le test de fonctionnement, il est un peu hâte d'apprendre à utiliser les données de production immédiatement. Le volume de données de production sera considérable et il faudra du temps pour apprendre. Si vous n'êtes pas très confiant, vous devez d'abord vérifier que votre modèle se comporte comme prévu et enregistrer une meilleure précision que la ligne de base, ou vérifier avec des données plus petites. Ceci est un test de vérification.

À l'inverse, la création d'un ensemble de données pour les tests de validation et d'un modèle de base pour celui-ci aidera à améliorer le modèle d'apprentissage automatique. Un ensemble de données de test de validation est un jeu de données facile à gérer et qui complète la formation en un laps de temps relativement court. Et le modèle de base est un modèle de base qui "s'il ne dépasse pas cela, c'est NG".

Sans cela, il y a une tendance à se laisser prendre dans l'illusion selon laquelle «il vaut peut-être mieux augmenter un peu plus les données» et «la précision peut être améliorée si un peu plus de temps d'apprentissage est pris», et il a tendance à être difficile d'améliorer l'algorithme essentiel. Il y a.

C'est tout un piège de dire: «Nous pouvons traiter les mêmes données que les données réelles immédiatement», et la tendance peut être fortement biaisée car les données réelles sont les données réelles (par exemple, 90 dans le diagnostic par image). Si% est normal, la précision sera de 90% même avec un modèle qui prédit simplement "aucune anomalie"). C'est une question fondamentale en apprentissage automatique qu'un biais de jugement soit causé par un biais dans les données, mais le sentiment de sécurité que «nous utilisons des données de production» tend à nous distraire d'un tel point.

Afin de résoudre les problèmes ci-dessus, il est recommandé de préparer des données de test de vérification de «taille facile à utiliser» et «d'étiquette équilibrée» et leur environnement.

L'implémentation ci-dessous teste avec l'ensemble de données de caractères manuscrits appelé digit fourni avec scicit-learn. scikit-learn est livré avec un ensemble de données comme des caractères manuscrits à l'avance, donc si vous pouvez l'utiliser, vous pouvez éviter de préparer les données.

tensorflow_qrnn/test_tf_qrnn_work.py

Si vous disposez de données de production, il est judicieux de créer un ensemble de données échantillonnées bien équilibré en tenant compte de l'étiquette cible, plutôt que de simplement l'extraire par période. Cela réduira la perte et vérifiera si la précision est correcte.

La comparaison avec la ligne de base est également un rôle important des tests de validation. On dit souvent que SVM était certainement meilleur que le modèle en dur du réseau neuronal (* Réglez correctement le modèle utilisé pour la ligne de base. L'important n'est pas d'utiliser le réseau neuronal, mais pour votre objectif. Parce que vous recherchez un modèle adapté). Heureusement, scikit-learn est livré avec une variété de modèles, ce qui le rend parfait pour cette vérification. Je pense que vous pouvez comparer et vérifier avec le modèle de base sans écrire trop de code.

En établissant cette barrière appelée test de vérification, vous pouvez économiser le temps et l'argent (frais de GPU) dépensés sur un mauvais modèle.

Cependant, il est également vrai que certains modèles ne peuvent être précis que s'ils sont entraînés à l'infini. Dans de tels cas, vous pouvez enregistrer la valeur de perte / précision (semblable à la vitesse) pour le temps d'apprentissage et la vérifier pour la remplacer.

Test d'intégration

Le test d'intégration vérifie si l'appel de l'application a réussi. Lors de l'utilisation d'un modèle d'apprentissage automatique, ce n'est pas seulement la précision qui doit être testée, mais également le prétraitement, etc.

Par conséquent, le processeur de données doit être testé indépendamment avant le test de coopération. Ensuite, testez si l'API de modèle fonctionne correctement lorsqu'elle est utilisée à partir de l'application. En ce qui concerne la précision, il est bon de préparer un ensemble de données d'une taille facile à vérifier et à tester l'API du modèle, c'est-à-dire la précision lors de l'exécution dans une application réelle, comme dans le test d'évaluation ci-dessus. C'est parce que les choses suivantes se produisent souvent pendant le test de coopération.

• J'ai oublié de faire le prétraitement avant d'appliquer le traitement de prédiction
• J'ai oublié d'appliquer une conversion au résultat de la prédiction (en particulier dans le cas de la prédiction de valeur, puisque la valeur prédite est normalisée pendant l'apprentissage, la normalisation inverse est effectuée et la valeur est restaurée lors de son utilisation réelle. Il y a un besoin)

Pour cette raison, il est conseillé de mesurer la précision et simplement de fonctionner.

L'ensemble de données utilisé pour tester la précision de cette API de modèle est également utile pour surveiller en permanence les performances des modèles d'apprentissage automatique. En faisant cela, vous pouvez juger du moment du ré-apprentissage / reconstruction, et en ce sens, il est recommandé de préparer un test de coopération séparément du test d'évaluation (les données seront un peu plus réelles que le test d'évaluation).

Test d'évaluation

Nous passerons au test d'évaluation lorsque le test de vérification dépasse la ligne de base et que le test de coopération confirme qu'il peut être appelé depuis l'application.

Ici, des tests dits A / B sont effectués. Dans la mise en œuvre, si nécessaire, nous nous entraînerons fermement avec la quantité de données qui dépasse le test de vérification. Vérifiez ensuite s'il présente un avantage sur les modèles existants.

Les indicateurs contrôlés lors du test d'évaluation et les indicateurs contrôlés lors du test de vérification sont très différents. Au stade du test de vérification, les indicateurs qui représentent la performance du modèle tels que la précision sont vérifiés, et au test d'évaluation, le KPI (Key Performance Indicator) dans le service tel que le «taux d'engagement des utilisateurs» est vérifié.

En fin de compte, il ne s'agit pas de créer un modèle très précis, mais de créer un modèle qui contribue au service, c'est-à-dire ajoute de la valeur à l'utilisateur. Le test d'évaluation vérifie ce point.

Ce qui précède est la méthode de test pour la mise en œuvre du modèle d'apprentissage automatique. En fait, je le fais par essais et erreurs, donc si vous avez des opinions comme celle-ci, j'aimerais avoir de vos nouvelles.