Matrice Cynefin x Machine Learning : Quand mettre en production ?

Mettre rapide un modèle de Machine Learning en production pour minimiser le risque des systèmes complexes

Certains affirment qu’il faut attendre d’avoir finalisé son modèle de Machine Learning (ML) avant d’aller en production, d'autres qu’il faut aller au plus tôt en production pour avoir du feedback. Formé à l'école Agile, DevOps, Lean, Accelerate, je fais clairement plus partie de la deuxième catégorie ; cependant je dois reconnaître que certains problèmes méritent d’être résolus complètement avant d’aller en production.

Ayant découvert récemment la matrice Cynefin, dans ce court billet je propose une grille de lecture des problèmes de ML que nous pouvons rencontrer afin de conclure quand il convient d’amener la solution en production.

Créée en 1999 par Dave Snowden, la matrice Cynefin vise à “aider les individus à identifier comment ils perçoivent les situations et à faire sens de leur propre comportement et celui des autres”. Elle propose 5 contextes, Clair, Compliqué, Complexe, Chaotique, Confusion. Nous allons proposer une interprétation de cette matrice en projetant les problèmes de Machine Learning que nous rencontrons dans ces contextes et identifier les impacts vis-à-vis des boucles de feedback et donc la nécessité d’être en production plus ou moins tôt.

Le contexte clair est un contexte où il existe une solution connue, la démarche de résolution de problème est de constater, catégoriser et agir.
Dans ces contextes là, le problème est soluble avec des règles métiers, il n’y a pas de bénéfice à faire du ML. Le feedback donné par des tests automatisés sera suffisant pour garantir la qualité de la solution, il est possible d’attendre d’avoir fini avant d’aller en production.

Le contexte compliqué est celui où il existe plusieurs solutions valables, la démarche de résolution de problème est de constater, analyser puis agir. 
Dans ces contextes là, les problèmes de ML consistent en des problèmes où l’ensemble des situations auxquelles l’algorithme sera confronté sont présentes dans les données mais il existe de nombreuses solutions. Ce sont des problèmes qui changent peu dans le temps. Le bénéfice fourni par le ML est d’essayer de nombreuses solutions et de choisir la meilleure en fonction de la métrique choisie ; nous gagnons ainsi du temps en évitant la paralysie d'analyse. 
Un exemple de problème dans ce contexte est celui de la clusterisation de documents officiels à partir de scans ; il est possible d’avoir des exemples de la totalités des modèles de carte d’identité en circulations ; nous savons qu’ils existent de nombreuses façons de les distinguer, mais aucune est triviale et il est difficile d’aboutir à un consensus. La solution proposée sera pertinente tant qu’il n'y a pas de changement important et rare de l’environnement (exemple : changement du modèle de carte d’identité). Le feedback fourni par la mesure de la performance du modèle sur un jeu de données de test sera suffisant pour garantir la qualité de la solution. Il est possible d’attendre d’avoir une solution sèche avant d’aller en production. Il conviendra tout de même de mettre en place un monitoring des performances pour détecter au plus tôt les changements qui rendraient caduque la solution. En cas de caducité, il faudra construire un nouveau modèle en prenant en compte ces nouvelles données et en supprimant les anciennes.

Le contexte complexe est un contexte où l’on n’est pas sûr qu’il existe une solution, la démarche de résolution de problème est d’expérimenter, de constater puis de décider.
Dans ce contexte, en ML, il existe des données historiques qui permettent de construire un premier modèle mais il n’est pas possible de collecter un jeu de données représentatif de toutes les situations. Il est alors nécessaire de le mettre en production pour collecter des situations inédites, prioriser celles que le modèle doit traiter, ré-entraîner avec ces nouvelles données, déployer, recommencer. Un exemple est un modèle qui prend des photos sur une chaîne de production pour identifier des défauts, il est impossible d’avoir des photos représentatives de toutes les situations en avance (changements de luminosité, présence d’un opérateur sur les images, modification de la chaîne, …). Dans ce contexte, il faut aller rapidement en production, monitorer la performance, éventuellement tester plusieurs solutions en parallèle (avec de l’A/B testing), collecter de nouvelles données, éventuellement les annoter, les catégoriser, réentraîner. Le cycle de ré-entraînement sera de l’ordre de la semaine ou du mois, il se fera sur un jeu de données enrichie de nouvelles situations. Sans être en production nous n’aurons qu'un a priori de la performance du modèle.

Le contexte chaotique est celui où la relation entre cause et effet change continuellement, la résolution de problème consiste à agir, constater le résultat, réagir. Les contextes chaotiques sont souvent temporaires car après l’évènement nous tendons vers une stabilisation de la situation pour retourner dans un contexte complexe ou compliqué. 
En Machine Learning, un contexte chaotique ponctuel rendra caduque les algorithmes développés dans les précédents contextes, il peut alors être intéressant de tester la robustesse de nos algorithmes face à un changement violent du contexte (un peu comme le chaos engineering en logiciel et de fixer des bornes au fonctionnement du modèle.
Il est envisageable de mettre en place des modèles dans des environnements de chaos constants. Le bénéfice apporté par le ML ici sera celui de la vitesse du cycle action-constat-réaction.  Par exemple, en real time bidding ou en détection de tentative de fraudes, le comportement des autres parties change continuellement, de manière non prédictible. Le problème à résoudre change continuellement et nous ne pouvons pas imaginer toutes les situations auxquelles nous serons confrontés. Nous allons devoir ré-entraîner très régulièrement le modèle avec des nouvelles données tout en supprimant les plus anciennes. Nous commençons alors à nous rapprocher des algorithmes d’apprentissage en ligne. Le cycle de ré-entraînement sera de l’ordre de l’heure ou du jour. Sans être en production, il est impossible d’obtenir un a priori sur la pertinence du modèle.

Nous pouvons résumer cet article par le tableau suivant :

Pour finir, je vous propose quelques précisions et ouvertures :

1. Le contexte de confusion a été exclu de cette réflexion car c’est celui où l’on ne sait pas dans quel contexte nous nous situons, cela n’aidera pas le raisonnement déroulé ici.

2. Dans cet article nous avons discuté du contexte dans lequel le modèle de ML se situe et pas de tout ce qui l’entoure. Ainsi si le problème de ML est dans un contexte compliqué, les interactions utilisateurs-modèle peuvent relever d’un contexte complexe.

3. Le lecteur notera que dans cet article nous avons abordé les problématiques de monitoring des modèles et fréquences de réentraînement mais pas de typologie d’algorithme (réseaux de neurones profonds versus modèle à base d’arbre versus …) car la complexité de l’algorithme n’a pas de corrélation avec le contexte dans lequel nous nous situons. Il est possible de faire du deep learning en contexte compliqué comme en contexte chaotique.

4. Même s'il peut y avoir une corrélation entre le contexte et la difficulté à construire un modèle pertinent, la matrice Cynefin ne nous permet pas de conclure sur la possibilité de construire un modèle performant.

5. Dans la suite de ses travaux Dave Snowden étudie les transitions entre les contextes. Un exemple d’un tel changement de contexte appliqué au ML est la COVID-19. Le problème de prédiction de nombre de réservation de billet de train qui étaient dans un contexte compliqué, est passé ponctuellement dans un contexte chaotique (car la relation entre cause et effet a changé, un weekend long ne signifie plus forte réservation), puis une phase de normalisation a ramené le problème dans le contexte compliqué. Pour prendre en compte ce genre de changement de contexte, il convient de s’assurer que le modèle saura dire “je suis dans une zone de fonctionnement non normale je ne préfère pas répondre, ou je réponds une réponse par défaut”.

Remerciements : Cet article a été rédigé à la suite de conversations avec Christian Fauré. Je tiens également à remercier mes relecteurs Gilles Masy, Pablo Pernot, Yves Peligry, Romain Vailleux, Basile du Plessis

Pour aller plus loin :

• Dave Snowden interviendra à l’USI 2022

• Lean for Machine Learning (ML)

• Une alternative au monitoring de distributions

• Amener son projet de machine learning jusqu'en production avec Wheel et Docker

• Data science en production : les difficultés pour récupérer la prédiction idéale

• A Leader's Framework for Decision Making