L'objectif intrinsèque d'une chaîne d'intégration et de déploiement continue est d'automatiser le contrôle du résultat. S'il est jugé conforme, le déploiement est effectué, sinon il est empêché. Cette automatisation conduit à une agilité accrue car les équipes peuvent s'autoriser de nombreuses versions de code sans craindre une dégradation de la production. Cette agilité est d'autant plus intéressante dans le domaine du machine learning que les modèles doivent être constamment améliorés. Embarquons donc notre machine learning dans le monde merveilleux du CI/CD. Pourquoi pas, mais alors ...

Dans le monde du logiciel "classique", le code est produit pour répondre à un objectif fonctionnel décrit dans ses spécifications. Il est donc relativement simple de contrôler le résultat car seul le code est en jeu : si le résultat fonctionnel n'est pas celui attendu, les tests échouent et le code est revu et corrigé.

Dans le domaine de l'apprentissage automatique, une entité maîtresse vient perturber cette relative simplicité : les données.

En effet, la raison d'être de l'IA, ce sont les données. La donnée fait vivre ou tue le code. Car c'est d'elle que vient la pseudo intelligence (phase d'apprentissage) et c'est encore à elle que tient l'exploitation de cette intelligence (prédiction, classement, etc.).

Ces données sont instables, elles ne cessent de croître et de subir des changements qui altèrent progressivement tout modèle d'apprentissage automatique. L'instabilité des données rend le modèle instable.Il est nécessaire de contrôler constamment les deux pour détecter une dégradation de la pertinence de l'inférence. C'est une différence majeure avec les logiciels classiques dont le fonctionnement n'a quasiment plus à être contrôlé tant que le code et l'environnement ne subissent pas d'évolution.

Contrôler la pertinence d'une inférence ? Dans le cadre d'un modèle prédictif ou prescriptif, les solutions de contrôle les plus évidentes sont les contrôles de type "a posteriori". Par exemple, comparer ce que le modèle a prédit à ce qui s'est réellement passé. Ou encore, contrôler statistiquement la structure des données d'apprentissage par rapport à celle des données qui ont été effectivement transmises au modèle lors de ses dernières inférences. Une approche par des contrôles de type "a priori" peut également permettre de détecter une mutation des données. Par exemple, établir des statistiques sur les données à un instant T et les comparer régulièrement aux nouvelles données entrantes (mesure de la dérive).

On est loin de la simplicité des contrôles des logiciels "classiques", le contrôle en machine learning est à considérer comme un projet en soi, ardu et dont le prix est celui de la confiance dans le modèle. Lorsque le contrôle échoue, l'analyse et la correction dépassent largement le cadre du code, c'est tout un ensemble d'éléments interdépendants qui doivent être la cible des investigations : les données, le paramétrage des caractéristiques, le stockage, etc. Les outils dans ce domaine sont soit, encore absents, soit nécessitent des développements spécifiques sur la base de briques logicielles détournées.

L'industrialisation d'un modèle d'apprentissage automatique implique la mise en place de pipelines complexes et il faut garder à l'esprit que l'automatisation conduira inévitablement à des opérations manuelles dès que le modèle sera dégradé. Il est crucial d'anticiper le besoin futur de tous les acteurs de la chaîne de production d'un modèle.

Laisser vivre le modèle seul, c'est le condamner à une mort certaine. L'accompagner des outils et d'une organisation appropriés représente un coût non-neutre. La rentabilité du modèle est donc la toute première question à se poser, apportera-t-il plus de valeur à l'entreprise qu'il ne lui en coûtera ?