A Survey of Algorithm Debt in Machine and Deep Learning Systems: Definition, Smells, and Future Work

1. Problématique et Contexte

L'adoption massive des technologies d'apprentissage automatique (ML) et d'apprentissage profond (DL) introduit des défis de maintenance spécifiques, générant une Dette Technique (TD). Bien que la dette technique soit bien documentée dans le génie logiciel traditionnel, les systèmes ML/DL présentent des complexités uniques liées aux dépendances de données, à la complexité algorithmique et au reconditionnement continu des modèles.

Parmi les types de dette technique, la Dette Algorithmique (AD) émerge comme une catégorie distincte mais sous-étudiée. Elle est définie comme une dette résultant de l'implémentation inefficace de la logique algorithmique, entraînant une dégradation des performances, une scalabilité limitée et une dégradation du modèle.

• Le problème central : La littérature actuelle confond souvent l'AD avec d'autres types de dette (Dette de Modèle, Dette de Données, Dette de Conception) ou la traite comme un problème de performance implicite plutôt que comme un concept structuré. Il existe un manque de clarté conceptuelle sur ce qui distingue spécifiquement l'AD, ce qui empêche les praticiens et les chercheurs de développer des stratégies de mitigation ciblées.
• L'objectif : Clarifier la définition de l'AD, identifier ses manifestations (les « odeurs » ou smells), évaluer son état de la recherche et proposer une feuille de route pour les travaux futurs.

2. Méthodologie

Les auteurs ont mené une enquête systématique de la littérature (SLR) en suivant un protocole de recherche hybride combinant une recherche dans les bases de données et un « snowballing » (recherche par citation).

• Sources de données : Recherche dans IEEE, ACM, Springer et ScienceDirect, complétée par Google Scholar.
• Critères d'inclusion : Études publiées en anglais depuis 2010, se concentrant sur les systèmes ML/DL, la dette technique, les odeurs de code ou les refactorings dans ce domaine.
• Corpus final : 42 études primaires ont été sélectionnées après filtrage (incluant 7 études de contrôle et 35 études issues du processus de recherche et de snowballing).
• Analyse des données :
  • Analyse thématique : Pour définir l'AD et identifier ses composantes.
  • Utilisation d'un jeu de données externe : Les auteurs ont analysé un jeu de données de 7 159 commentaires de code étiquetés comme « AD » provenant d'une étude précédente (Liu et al., 2020) pour valider empiriquement les définitions théoriques.
  • Validation par les pairs : Un expert en dette technique a validé le processus de codage et les catégories finales pour assurer la rigueur.

3. Contributions Clés

L'article apporte quatre contributions majeures à la communauté du génie logiciel et du ML :

1. Une définition consolidée et élargie de l'AD :
   L'AD n'est pas seulement une question de performance brute. Elle est définie comme un type de dette technique résultant de choix algorithmiques sous-optimaux qui limitent la scalabilité et provoquent la dégradation du modèle par rapport aux objectifs du système.
2. Révélation de la prévalence implicite :
   L'étude démontre que l'AD est omniprésente mais souvent non nommée. 83 % des études analysées (35 sur 42) discutaient de problèmes liés à l'AD (inefficacité, problèmes de scalabilité, dégradation) sans utiliser le terme « Algorithm Debt », les classant souvent à tort sous d'autres catégories (Dette de Modèle ou de Données).
3. Une taxonomie de neuf « odeurs » (Smells) de l'AD :
   Les auteurs ont identifié neuf indicateurs spécifiques de dette algorithmique, regroupés en trois catégories :
   • Données : Données brutes non formatées (« Plain old data »), statistiques non représentatives, dépendances de données instables, données hors domaine, absence de mise à l'échelle avant des opérations sensibles, caractéristiques non normalisées.
   • Conception d'algorithme : Biais avec la normalisation par lots (Batch Norm), hyperparamètres sous-optimaux.
   • Expertise ML : Manque de connaissances spécialisées en ML/DL.
4. Un cadre conceptuel et une feuille de route :
   Proposition d'un cadre reliant les causes (manque d'expertise, conception défaillante) aux effets (inefficacité, dégradation) et suggérant des stratégies de mitigation (ingénierie des caractéristiques, réentraînement, revues par les pairs, outils automatisés).

4. Résultats Détaillés

A. Définition et Composantes (RQ1)

L'analyse a permis de structurer l'AD autour de trois dimensions techniques principales, validées à la fois par la littérature et les commentaires de code :

1. Inefficacité : Calculs redondants ou logique non optimisée augmentant les coûts de temps et de mémoire (ex: utilisation d'intermédiaires inutiles).
2. Limitations de Scalabilité : Conceptions algorithmiques qui échouent lors du passage à l'échelle (ex: hypothèses de conception qui ne tiennent pas en environnement distribué).
3. Dégradation du Modèle : Instabilité numérique, surapprentissage (overfitting), dérive de concept (concept drift) ou perte d'intégrité des données due à des flaws d'implémentation.

B. État de la Recherche (RQ2)

L'étude révèle une asymétrie significative : bien que les problèmes d'AD soient omniprésents dans la pratique, ils sont rarement théorisés sous ce nom. La majorité des recherches traitent ces problèmes comme des « problèmes de performance » ou des « défauts de modèle », ce qui empêche une gestion ciblée de la dette algorithmique.

C. Les Odeurs de l'AD (RQ3)

Les neuf odeurs identifiées servent de signaux d'alerte précoces :

• Exemple technique : L'utilisation de Batch Norm après une couche de Dropout peut créer un biais dans les statistiques globales, dégradant la précision du modèle (Biais avec Batch Norm).
• Exemple technique : Le choix d'hyperparamètres par défaut sans ajustement pour des modèles complexes conduit à une convergence lente ou à des optima locaux.
• Exemple technique : L'absence de mise à l'échelle (scaling) des caractéristiques avant des opérations sensibles (comme la descente de gradient) ralentit la convergence.

5. Signification et Implications

Pour les Praticiens (Ingénieurs ML/MLOps)

• Changement de paradigme : L'AD doit être vue comme un problème de maintenabilité à long terme et non seulement comme un problème de performance immédiate.
• Intégration dans MLOps : Il est nécessaire d'intégrer des tests spécifiques à l'AD (validation de l'efficacité algorithmique, vérification des dépendances de données instables) dans les pipelines de déploiement.
• Formation : Le manque d'expertise en ML est un facteur clé de l'accumulation de dette. L'investissement dans la formation continue est une stratégie préventive.

Pour les Chercheurs

• Distinction conceptuelle : Il est crucial de distinguer l'AD de la Dette de Modèle (choix d'architecture) et de la Dette de Données (qualité des données). L'AD se situe au niveau de la logique algorithmique elle-même.
• Outils automatisés : L'avenir réside dans le développement d'outils de détection automatique (utilisant des LLM pour analyser les commentaires de code et les configurations) pour identifier les odeurs d'AD avant le déploiement.
• Études longitudinales : Des recherches futures doivent suivre l'évolution de l'AD dans des projets réels pour comprendre comment elle s'accumule et est résolue au fil du temps.

Conclusion

Cet article établit la Dette Algorithmique comme un domaine de recherche distinct et actionnable. En passant d'une vision implicite à une définition explicite, accompagnée d'une taxonomie de signaux d'alerte, les auteurs fournissent les bases nécessaires pour améliorer la fiabilité, la scalabilité et la maintenabilité des systèmes d'intelligence artificielle. L'approche proposée souligne que la gestion de l'AD nécessite une combinaison de meilleures pratiques d'ingénierie logicielle, d'outils automatisés et d'une expertise humaine accrue.