Rédaction de code pour la recherche sur le traitement du langage naturel

“Le code est disponible sur demande”, “Les auteurs promettent…”, un rapport qui ne contient que model.py… nous savons tous… pas besoin d'expliquer davantage.

Beeeeeeeeeeeeeeeeep….

Lors de la première journée de # EMNLP2018, Joel Grus, Matt et Mark du Allen AI institute ont présenté le didacticiel, qui a sans doute suscité le plus grand intérêt.
 J'aime ce type de tutoriels, qui traitent de nouveaux problèmes dans le monde de la recherche, bien plus que d'avoir un défilé de modèles SOTA pour une tâche spécifique. Dans IJCNLP2017, un tutoriel similaire expliquait comment faire une bonne affiche et comment faire une présentation compréhensible.

Dans ce tutoriel, ils résument leurs meilleures pratiques et les leçons apprises lors de la rédaction de code pour la recherche en PNL et du développement de la trousse à outils Allen en PNL.

Disclaimer: J'essaie ici de citer Joel, Matt et Mark autant que possible. Il y a peu de points où je ne suis peut-être pas aussi précis (désolé pour cela). Plus important encore, il n’ya que quelques points avec lesquels je ne suis pas tout à fait d’accord - et pourtant, je le vois, en particulier dans la première partie du didacticiel qui examine la redondance des codes lors du prototypage. Mais maintenant je laisse mes opinions de côté.

Début:

à partir d'un tutoriel commence par décrire deux objectifs principaux pour l'écriture de code dans la recherche en PNL en général.

Partie de tutoriel 1: Prototypage

Les objectifs principaux du prototypage sont:
1) écrire du code rapidement.
2) exécuter des expériences avec des erreurs minimes.
3) le comportement des modèles de débogage.

1) Écrire du code rapidement

  • Au cours de cette phase du projet, vos idées changent rapidement. L’idée est donc d’exécuter rapidement quelque chose pour mieux comprendre le problème.
  • Faites-vous une base, commencez par une bibliothèque modulaire réutilisable (Allen NLP, Fairseq, Sockeye, Tensor2Tensor…) ou un document implémenté qui est facile à lire et à exécuter (lancez-le (bonne chance pour le trouver ..).
  • Parfois, cependant, vous devez recommencer à zéro si rien ne correspond à vos besoins.
  • Au cours de cette phase, ne modifiez pas votre code et ne tentez PAS de réduire la duplication de code, copiez d’abord votre code et le refactor plus tard, cela garantit que votre travail fonctionnera rapidement.

Cela vous oblige toujours à avoir un code lisible, afin que vous puissiez comprendre et maintenir. Voici quelques conseils utiles, étant donné que:

  • <<< COMMENTAIRES SUR LA FORME >>> sur les tenseurs pour faciliter le débogage ultérieur
  • Écrivez le code pour les personnes pas les machines: écrivez de longs commentaires décrivant la logique non évidente

Test minimal:

  • Faites des tests minimaux (mais pas des tests): «Si vous écrivez des tests qui vérifient le comportement expérimental, vous perdez du temps car cela risque d’être modifié ultérieurement»
  • Cependant, rédigez des tests pour la préparation des données. code. Ceci sera utilisé pour prétraiter et générer des lots et sera indépendant des ajustements du modèle, il est donc préférable de vérifier qu'il fonctionne correctement. (par exemple, écrivez des tests pour vous assurer que le code de lecture et d’évaluation du jeu de données SQUAD fonctionne correctement).

Code dur, seules les parties sur lesquelles vous ne vous concentrez pas.

  • Cela facilite les expériences contrôlées (pour vous et les personnes qui réutilisent votre code ultérieurement (le cas échéant)).

2) expériences en cours:

Gardez une trace de ce que vous avez couru tout en faisant des expériences

  • La façon la plus simple de le faire est de mettre les résultats d’expériences dans un tableur.
    Notez quelle version du code a été utilisée pour exécuter quelles expériences utilisant le contrôle de version.

Expériences contrôlées: ne testez qu'une chose à la fois (faites des tests d'ablation)

  • Ne faites pas d’expériences avec de nombreuses pièces mobiles.
  • Changer une chose à chaque fois en gardant le tout constant. C’est important pour contrôler les expériences et montrer ce qui a permis d’améliorer les performances.

Comment écrire des expériences contrôlées:

  • Rendre tout contrôlable en tant que paramètre du modèle.
  • Chargez ces modèles à partir d'un code de configuration ou d'un script en cours d'exécution

3) Analyse des performances du modèle

Tensorboard est très utile pour cela. Il est également compatible avec presque toutes les bibliothèques DL, pas seulement tensorflow.

Voici une liste de mesures utiles à visualiser:
1) Perte, précision
2) Gradients: valeurs de mise à jour moyennes, standard et réelles
3) paramètres: moyenne, std
4) Activations: enregistre les activations problématiques

Regardez vos données:

  • ne pas imprimer les déclarations à la fin de la formation
  • Au lieu de cela: enregistrez les points de contrôle du modèle, puis écrivez un script indiquant que, compte tenu du point de contrôle du modèle, il exécute des requêtes sur votre modèle.
  • Il est toujours préférable de mettre cela dans une démo Web, cela facilite beaucoup le débogage du modèle et l'interaction visuelle. De plus, vous pouvez montrer certaines des idées internes du modèle (par exemple, une matrice d’attention) avec chacun des exemples donnés dans votre démonstration Web.

Construisez votre traitement de données: pour que vous lisiez à partir d’un fichier mais que vos modèles puissent s’exécuter sans libellés donnés, c’est-à-dire que le modèle ne plante pas s’il ne peut pas calculer une perte, le même code peut être exécuté pour Train et pour la démonstration.

Partie 2 du tutoriel: Développer de bons processus:

mais vous en avez besoin :)

La deuxième partie du didacticiel portait sur la manière de développer un bon processus de développement dans votre expérience pour pouvoir le réexécuter partout.

  1. Utilisez le contrôle de source: «J'espère que vous le faites déjà»
  2. Révisions de code:
    * Trouver des bugs pour vous
    * Vous obliger à rendre votre code lisible
    * L'écriture de code clair permet à la révision de code d'être une discussion pour modéliser elle-même pas le code
    * Empêche la publication d'un code et la recherche ultérieure de bogues susceptibles de rendre vos résultats incorrects - cela se produit d'ailleurs et peut vous amener à retirer l'un de vos papiers acceptés
  3. Intégration continue (automatisation de la construction)
  • L'intégration continue est toujours une fusion dans une branche
  • L'automatisation de la construction exécute toujours des tests à chaque fusion

4. Tester votre code (revoir le test)

  • Test unitaire: est une vérification automatique du fonctionnement de la partie de votre code.
  • Si vous êtes en train de prototyper, pourquoi devriez-vous écrire des tests?
    * Testez les bases: testez les éléments de direction qui ne dépendent pas directement des résultats
    * par exemple. Affirmez que la taille du lot est identique à celle que vous attendez
    * par exemple. Tous les mots du lot sont dans le vocabulaire
  • Si vous créez une bibliothèque réutilisable, pourquoi devriez-vous écrire des tests?
    << TOUT >>
    * les modèles peuvent former, enregistrer et charger
    * qu'il calcule des gradients de backprop
  • Montage de test: l'exécution de tests sur de grands ensembles de données chaque fois que vous fusionnez est un peu grosse et lente. conservez plutôt une petite quantité de données stockées et exécutez ces tests.
  • Utilisez vos connaissances pour rédiger des tests intelligents: Il est difficile de tester l’attention, car elle repose sur des paramètres: par exemple: Il est difficile de tester les modèles d’attention, mais vous pouvez modifier ce test si vous mettez tous les poids de l’attention à égalité, cela équivaudrait-il à faire la moyenne de tous les vecteurs d’entrée?

Partie 3 du tutoriel: Écrire du code pour les composants réutilisables

La troisième partie de l’exposé concerne l’écriture de code pour les composants réutilisables, par exemple. le code que vous et vos collègues allez beaucoup réutiliser (par exemple, la bibliothèque MT de votre laboratoire). Joel commence à répertorier ses meilleures pratiques lors du développement de la bibliothèque AllenNLP.

Certaines abstractions (l’abstraction consiste simplement à créer une classe générique pour ce type de classes) se sont révélées utiles, mais d’autres ne l’ont pas été.

Donc, vous n’avez pas besoin de tout résumer, mais plutôt de trouver la bonne quantité d’abstraction pour faire un compromis entre capacité de réutilisation et temps passé à coder les abstractions. Ceci concerne essentiellement les composants qui:
* Vous allez être réutilisé beaucoup: par exemple former un modèle, mapper des mots sur des identifiants, résumer la séquence à un seul tenseur.
* Cela comporte de nombreuses variantes: changer un caractère ou un mot en tenseur, transformer un tenseur en une séquence de tenseurs, résumer une séquence de tenseurs en un tenseur (modèle d'attention, avg, concat, sum ..etc)
* Les éléments qui reflètent notre réflexion de niveau supérieur (texte, balises, étiquettes, ..) vous permettent d’abstraire le plus possible votre modèle.

Meilleures pratiques de la PNL Allen

cette partie ne fait que énumérer quelques exemples d’abstractions de la bibliothèque Allen NLP.
Je vais les parcourir rapidement, mais vérifiez les diapositives pour plus de détails:

  • Modèles: sont l'extension de torch.nn.module utilise la même abstraction de modèle à partir de pytorch.
    * Vocabulaire: all_tokens, tokens2id, id2token ..etc
    * Instances: les instances de l'ensemble de données, utilisées pour créer du vocabulaire
    * Les instances contiennent des champs: (texte source, tgt text ..etc)

et quelques autres abstractions…
* TokenIndexer:
* DataReader:
* DataIterator: Itérateur de base: mélange les lots
* BucketIterator: groupe des instances de longueurs similaires
* Tokenizer
* TokenEmbedder
* Deux abstractions différentes pour les RNN (Seq2Seq, Seq2Vec) |
* Attention
* MatrixAttention

Syntaxe déclarative:

La plupart des objets PNL Allen peuvent être instanciés à partir de blobs jsonnet
* Cela permet de spécifier des expériences utilisant json
* Permet également de changer d'architecture sans changer de code.

Archives modèles:

Chaque boucle d'apprentissage crée une archive de modèle qui est:
config.json + vocab + poids de modèles formés

Ceci peut être utilisé pour évaluer un test ou pour faire une démonstration

Créer des démos:

Pour créer un modèle, votre modèle doit accepter json et json en sortie.
`Les prédicteurs` sont un simple wrapper json de votre modèle conçu pour cela.

Il reste encore beaucoup de choses à découvrir dans AllenNLP:

* régularisation / initialisation
* modèle avec composants pré-entraînés
* créer des boucles complexes de formation
* mise en cache des données prétraitées
* vocabulaire en expansion

Joel termine sa partie du didacticiel en présentant un cas d'utilisation montrant les différences entre les modèles de construction à l'aide de numpy (ne pas le faire), de pytorch & AllenNLP.

Partie 4 du tutoriel: Comment partager votre code

Utilisez les conteneurs Docker:

Ne soyez pas intimidé par docker, c’est assez simple:
1) Écrire un fichier docker
2) Le fichier Docker est utilisé pour créer des images Docker.
3) Exécuter des images de menu fixe sur des conteneurs

Dans les diapositives, vous trouverez un didacticiel rapide concernant le menu fixe qui contient toutes les commandes importantes dont vous aurez probablement besoin.

Libérer votre code:

Lorsque vous relâchez votre code, assurez-vous que les personnes disposent des bonnes données pour le réexécuter. Soyez précis: «le site Web contient 27 fichiers jar corenlp». Les gens peuvent facilement télécharger la mauvaise chose.

Utiliser le cache de fichiers:

Utiliser un environnement python: pour cela, vous pouvez compter sur virtualenvs ou anaconda. créer un nouvel env virtuel pour chaque projet. Exportez-le dans un fichier require.txt pouvant être installé par toute personne réutilisant votre code

Le tutoriel se termine ici ..

Espérons que ce tutoriel aura un impact sur la quantité de code réutilisable que nous verrons lors des prochaines conférences NLP.
Merci Joel, Mark et Matt pour le tutoriel génial et les grandes quantités de fichiers GIF dans les diapositives.

Oh en parlant de diapositives, vous voilà ..