Résumé technique : Vers la migration des implémentations de réseaux de neurones

Énoncé du problème

Les progrès rapides des réseaux de neurones (RN) ont conduit à une prolifération de frameworks d'apprentissage profond (AP) (par exemple, PyTorch, TensorFlow). Bien que les organisations adoptent ces frameworks pour tirer parti de fonctionnalités spécifiques, de caractéristiques de performance ou d'un soutien communautaire, elles font souvent face à la nécessité de migrer des implémentations existantes de RN vers un framework différent plus tard dans le cycle de vie. Cette migration est motivée par des facteurs tels que la baisse des performances, l'évolution des exigences ou la dépréciation du support pour certains frameworks (par exemple, Hugging Face dépréciant le support de TensorFlow).

Actuellement, il existe un manque significatif d'approches automatisées spécifiquement conçues pour migrer le code des RN. La littérature existante se concentre principalement sur la conversion de modèles entraînés et prêts à l'emploi (artefacts) plutôt que sur le code source lui-même. Par conséquent, les organisations sont contraintes de réécrire manuellement le code des RN à partir de zéro, un processus qui prend du temps, est sujet aux erreurs et entrave la flexibilité nécessaire pour adopter de nouvelles fonctionnalités tout en réutilisant la logique existante.

Méthodologie

Les auteurs proposent une approche d'Ingénierie Pilotée par les Modèles (IPM) pour migrer automatiquement le code des RN entre les frameworks d'AP. Le cœur de la méthode repose sur un modèle pivot pour abstraire le code source avant de générer le code cible. Le processus se compose de trois étapes principales :

1. Extraction de l'AST

Le processus commence par l'analyse du code du framework source (Python) pour extraire son Arbre de Syntaxe Abstraite (AST). Les auteurs utilisent la bibliothèque ast de Python pour représenter le code sous forme d'arbre de nœuds, où les nœuds correspondent aux composants des RN tels que les couches, les opérations sur les tenseurs et les hyperparamètres. Cette étape prend en charge les architectures Séquentielles et par Sous-classement trouvées dans PyTorch et TensorFlow.

2. Transformation (Modèle-vers-Modèle)

L'AST extrait est transformé en une représentation indépendante du framework en utilisant le métamodèle BESSER-NN. Ce métamodèle, faisant partie de la plateforme low-code BESSER, sert de modèle pivot.

• Mappage : Les nœuds de l'AST source (par exemple, une couche Dense de TensorFlow) sont mappés sur leurs équivalents dans le modèle BESSER-NN (par exemple, une couche Linear).
• Attributs : Les hyperparamètres, les configurations d'entraînement et les définitions de jeux de données sont également mappés sur le modèle pivot.
• Gestion des différences d'architecture : L'approche emploie quatre modules de transformation distincts pour gérer les quatre combinaisons d'architectures source/cible (PyTorch/TensorFlow × Sous-classement/Séquentiel).
• Traçage symbolique : Un aspect critique de cette étape consiste à tracer symboliquement le code source pour inférer des attributs non explicitement définis dans l'AST (par exemple, les formes d'entrée dans TensorFlow), garantissant ainsi que le modèle pivot contient toutes les informations nécessaires pour le framework cible.

3. Génération de code (Modèle-vers-Texte)

Une fois le modèle pivot BESSER-NN peuplé, des générateurs de code produisent l'implémentation finale dans le framework cible.

• Prétraitement : Des scripts Python traitent le modèle BESSER-NN pour résoudre les références croisées et les dépendances entre les couches.
• Moteur de templates : Le moteur de templates Jinja est utilisé pour mapper les concepts abstraits du modèle pivot sur la syntaxe spécifique du framework cible (PyTorch ou TensorFlow).
• Support d'architecture : Quatre générateurs de code ont été développés pour prendre en charge toutes les combinaisons d'architectures, garantissant que des conceptions complexes (comme la définition d'un réseau au sein d'une autre classe) sont préservées.

Contributions clés et défis techniques

L'article aborde plusieurs défis techniques spécifiques inhérents à la migration inter-framework :

• Attributs manquants (Formes d'entrée) : Dans TensorFlow, les formes d'entrée sont souvent inférées automatiquement, tandis que PyTorch exige une définition explicite. Les auteurs ont résolu ce problème en ajoutant une étape de traçage symbolique pendant la phase de transformation pour inférer et remplir les attributs de forme d'entrée manquants (par exemple, in_features, in_channels) dans le modèle pivot avant de générer le code PyTorch.
• Fonctions d'activation dynamiques : TensorFlow permet d'assigner dynamiquement des fonctions d'activation à des variables et de les transmettre aux couches, tandis que PyTorch s'attend généralement à des définitions de couches explicites. L'approche de migration gère cela en vérifiant la valeur de la fonction d'activation ; s'il s'agit d'une chaîne connue, une couche standard est générée. Si elle est dynamique, le générateur crée un appel de fonction personnalisé qui résout l'activation à l'exécution, préservant ainsi la logique originale.
• Conventions d'ordre des canaux : TensorFlow utilise un ordre « canal-dernier », tandis que PyTorch utilise un ordre « canal-premier ». Pour maintenir l'équivalence fonctionnelle sans modifier le format des données d'entrée, l'approche insère des opérations de tenseur permute. Ces opérations réorganisent les dimensions des tenseurs avant et après les couches de convolution dans le code cible afin de s'aligner sur la convention native du framework tout en maintenant le flux de données cohérent avec la source.
• Intégration système : L'article démontre comment le métamodèle BESSER-NN peut être intégré avec des langages de modélisation logicielle généraux comme UML. Cela permet de définir les RN comme des implémentations de comportement au sein de modèles système plus larges (par exemple, en tant que méthodes dans une machine à états), facilitant la migration des RN dans le cadre d'une migration plus vaste d'un système intelligent.

Évaluation expérimentale

Les auteurs ont évalué l'approche en utilisant cinq réseaux de neurones distincts issus de la littérature : AlexNet, VGG16, LSTM, CNN-RNN et TF-Tutorial. Ces réseaux couvrent 12 types de couches distincts et un mélange d'architectures Séquentielles et par Sous-classement.

L'évaluation a abordé deux questions de recherche (QR) :

1. QR1 (Succès de la migration) : L'approche a migré avec succès les cinq réseaux dans tous les scénarios pris en charge (PyTorch $\leftrightarrow$ TensorFlow, Séquentiel $\leftrightarrow$ Sous-classement). Le code généré s'est exécuté sans erreurs structurelles lorsqu'il a été alimenté avec des données d'entrée factices.
2. QR2 (Préservation fonctionnelle) : Les auteurs ont vérifié que les réseaux migrés produisaient des sorties fonctionnellement équivalentes aux originaux.
   • Entrées aléatoires : En utilisant des poids identiques et des entrées aléatoires, la Différence Absolue Maximale (DAM) entre les sorties source et cible était négligeable (jusqu'à $5,96 \times 10^{-8}$).
   • Jeux de données de référence : Les réseaux ont été entraînés sur CIFAR-10, SVHN, IMDB et SST-2. La précision de prédiction des réseaux migrés était hautement cohérente avec celle des réseaux sources, la plus grande différence observée étant de 0,022 (pour VGG16 sur CIFAR-10).

Importance et affirmations

L'article affirme que son importance principale réside dans le déplacement du focus de la migration de modèles entraînés vers la migration de code source. Contrairement aux outils existants (par exemple, ONNX, MMdnn, CoreML) qui convertissent des artefacts statiques et entraînés, cette approche migre la définition du réseau lui-même.

Cette distinction est significative car elle :

• Permet une expérimentation itérative, permettant aux développeurs d'inspecter, de modifier et de réentraîner le modèle dans le nouveau framework.
• Prend en charge les pipelines pilotés par les modèles, permettant de traiter les RN comme des citoyens de première classe au sein des flux de travail plus larges du génie logiciel.
• Évite le caractère « boîte noire » de la conversion d'artefacts, préservant la capacité de tirer parti des nouvelles fonctionnalités et des meilleures pratiques du framework cible.

Les auteurs concluent que leur approche comble efficacement le fossé entre les frameworks d'AP, réduisant l'effort manuel requis pour la modernisation tout en maintenant l'équivalence fonctionnelle. Ils notent que les travaux futurs consisteront à étendre le métamodèle pour prendre en charge des concepts d'IA plus avancés (par exemple, Transformers, Réseaux de Neurones à Graphes) et à développer des transformations de refactorisation pour améliorer la structure des RN.