Pourquoi ce rappel
Les récentes avancées spectaculaires du Machine Learning, concernant notamment les IA Génératives, ont tendance à faire oublier qu'il n'y a pas de magie dans le Machine Learning et qu'il est important de respecter certains fondamentaux sans lesquels ces avancées n'auraient pas été possibles.
C'est également l'oubli ou le non respect de ces fondamentaux qui explique en grande partie le fait que la plupart des projets de développement d'applications à base de Machine Learning échouent, sont décevants et/ou ne vont jamais jusqu'à l'étape finale de mise en production de ces applications.
Il parait donc utile de rappeler certains de ces fondamentaux.
Dans la suite de cet article, nous utiliserons l'acronyme :
ML pour désigner toutes les techniques de Machine Learning, incluant les techniques “classiques” (régression, SVM, Random Forest, Gradient Boosting, etc.) et les techniques de Deep Learning,
DL pour désigner plus spécifiquement les techniques de Deep Learning à base de réseaux de neurones.
Facteurs clés de succès des projets de Machine Learning
Les facteurs clés de succès des projets de ML sont rarement technologiques.
La grande majorité des projets consistant à développer des applications à base de ML, sont réalisés par des entreprises ou organisations publiques ou privées qui sont essentiellement “consommatrices” de technologies de ML préalablement mises au point par des tiers, que ce soient des Big Tech, des startups, des communautés open source ou etc.
Ces entreprises “consommatrices” de technologies de ML essaient évidemment d'utiliser des technologies à l'état de l'art mais cela ne leur est pas toujours possible et de toute façon, elles ont rarement la possibilité d'être sûr que les technologies de ML qu'elles ont retenues pour développer leurs applications, soient optimales et/ou soient configurées de manière optimale. C'est d'autant plus vrai que les technologies de ML sont de plus en plus complexes, qu'elles évoluent très rapidement et qu'il est difficile de rester toujours au fait des dernières évolutions.
Cependant, ce n'est pas si grave car, quoi qu'il en soit, ce n'est généralement pas la technologie qui est la cause des échecs partiels ou totaux de nombreux projets de ML.
Dans la grande majorité des cas, les causes principales de ces échecs sont ailleurs. S'agissant de projets de Machine Learning, on incrimine souvent les données et on n'a pas tord, sauf que ce problème de données n'est généralement que la conséquence d'une cause bien plus importante.
Comme pour tout projet, le premier facteur clé de succès d'un projet de ML est la spécification rigoureuse et précise du besoin.
L'adage “un problème bien posé est à moitié résolu” s'applique particulièrement bien aux projets de ML mais il conviendrait de rajouter : “un problème de ML mal posé est voué à l'échec”.
En effet, il est pratiquement impossible de mener à bien un projet de ML sans une énonciation claire et précise des objectifs de l'application à développer (système ou service) ainsi que de son contexte opérationnel sous tous ces aspects : usages, parties prenantes, environnements, règlementations, potentielles perturbations, risques, opportunités, etc.
Ce n'est d'ailleurs en principe qu'à l'issue de cette phase de spécification qu'on est en capacité de voir si une approche de ML est effectivement possible et constitue la meilleure approche sur tout ou partie de son contexte opérationnel.
Pour cela, il convient :
d'une part, de formaliser et de définir le contexte opérationnel de l'application à développer, à l'aide d'attributs spécifiques à chaque aspect de ce contexte,
d'autre part, de vérifier la couverture et la distribution des données disponibles et envisageables par rapport à ces attributs.
Si cette couverture ou distribution est insuffisante sur certains de ces attributs, on peut être amené à renoncer à une approche de ML pour la partie du contexte opérationnel concernée, et/ou à réduire certains niveaux d'exigences sur cette partie.
Cette étape capitale dans l'ingénierie d'applications à base de ML sera détaillée dans un prochain article présentant la méthode d'ingénierie de bout en bout que nous préconisons pour tout projet de ML (y-compris pour les POC). S'agissant d'une version proposant une lecture simplifiée de la méthode d'ingénierie développée avec nos partenaires dans le cadre du programme Confiance.ai, vous pouvez consulter la version d'origine ici.
Vous pourrez voir qu'elle utilise la notion d'ODD (Operational Design Domain) pour formaliser et définir le contexte opérationnel des applications à développer. Il s'agit d'une notion qui a été introduite au niveau international pour formaliser et définir le contexte opérationnel des voitures autonomes et qui a donc été étendue par Confiance.ai à tous les projets d'ingénierie.
Nous détaillerons cette notion d'ODD dans un prochain article. Nous montrerons combien elle est fondamentale pour l'ingénierie d'applications (systèmes ou services) à base de ML, sur tout le cycle de vie de ces applications, qui ne s'arrête pas au déploiement.
Nous montrerons aussi qu'une parfaite compréhension du contexte opérationnel de l'application à développer est indispensable :
premièrement, pour bien définir un ODD,
deuxièmement, pour ensuite bien exploiter cet ODD dans les étapes suivantes du processus d'ingénierie,
troisièmement, pour bien comprendre les données disponibles ou envisageables, permettant de considérer une approche de ML sur tout ou partie de cet ODD.
Tout projet de développement d'application à base de ML est voué à l'échec sans expertise métier suffisante sur la compréhension du besoin et des données.
Cette condition de réussite d'un projet de ML est nécessaire quelle que soit la quantité et la qualité des données disponibles ou envisageables pour considérer une approche de ML. Mais elle n'est pas suffisante pour maximiser les chances de succès d'un telle approche.
Le deuxième facteur clé de succès d'un projet de développement d'une application à base de ML, est lié à la disponibilité en quantités suffisantes de données de qualité.
Ces fondamentaux sur les facteurs clé de succès des projets de développement d'applications (systèmes ou services) à base de ML se déclinent en d'autres fondamentaux qu'il est tout aussi important de garder à l'esprit pour maximiser les chances de succès de ces projets.
Autres fondamentaux à garder à l'esprit
En ML, tout est appris dans les données !
Cela semble être un évidence mais on a souvent tendance à l'oublier quand on spécifie les exigences opérationnelles d'une application, surtout lorsqu'on n'a pas encore décidé si on optait pour une approche de ML pour répondre à tout ou partie de ces exigences.
Si on opte pour une approche de ML pour répondre à tout ou partie des exigences d'une application, tous les éléments à apprendre pour répondre aux exigences couvertes par cette approche de ML, doivent pouvoir être appris dans les données.
Concrètement cela signifie que si par exemple, on veut couvrir des exigences d'éthique par une approche de ML, il faut disposer de suffisamment de données labellisées par rapport à ces exigences pour apprendre celles-ci sous tous leurs aspects et toutes leurs éventuelles subtilités. Cela peut être très compliqué et complexifier énormément l'apprentissage comme la validation. Il peut alors être judicieux de confier le traitement de ces exigences à des modèles spécifiques qui ne sont pas nécessairement (tous) des modèles de ML.
Afin d'illustrer plus encore ce point fondamental, prenons un autre exemple très courant d'exigences pour les applications à base de ML. Il est souvent demandé qu'elles soient robustes à divers perturbations liées à leur contexte d'emploi. On peut par exemple exiger d'une application de détection d'objets sur des images vidéos, qu'elle soit robuste, dans certaines limites, au flou. Cela suppose que si on opte pour une solution de ML pour couvrir cette exigence, il faudra collecter et labelliser suffisamment d'images floutées dans toutes les circonstances souhaitées de détection, pour apprendre à la satisfaire. A nouveau, il peut être judicieux de déporter le traitement de ces exigences de robustesse sur des modèles dédiés et annexes, en ayant éventuellement recours à d'autres approches que le ML (règles métiers, etc.), surtout s'il s'avère compliqué de faire apprendre ces exigences de robustesse dans toutes leurs subtilités ou nuances avec du ML.
Le volume de données nécessaire pour développer une application par une approche de ML, ne dépend pas de la technique de ML ou de DL utilisée.
On entend ou on lit souvent que les techniques de DL nécessitent forcément beaucoup de données et forcément beaucoup plus que les techniques plus classiques de ML. Ce n'est pas vrai. On peut très bien faire une régression sur 3 points avec du DL. Ce n'est pas très judicieux, mais c'est facilement réalisable.
Si nous utilisons généralement plus de données avec les techniques de DL qu'avec les techniques classiques de ML, c'est essentiellement parce que les techniques de DL nous permettent en principe de construire des modèles (beaucoup) plus sophistiqués et de développer des applications soumises à des exigences plus nombreuses et/ou de plus hauts niveaux, qui sont de ce fait (beaucoup) plus complexes à satisfaire.
Le volume de données nécessaire pour développer une application par une approche de ML, dépend avant tout de la complexité des informations (ou concepts) à apprendre pour satisfaire toutes les exigences auxquelles cette application est soumise.
Cette complexité dépend beaucoup de la nature des informations (ou concepts) à extraire des données, qui elle-même dépend de la nature des exigences. Il faudra généralement beaucoup plus de données pour extraire et apprendre des informations mal connues, mal maitrisées, abstraites, informelles, enchevêtrées et/ou diffuses, que si c'est le contraire.
Le niveau d'exigence peut également constituer un facteur de complexité important puisqu'il implique souvent d'apprendre certaines informations (ou concepts) de manière beaucoup plus précise, c'est-à-dire dans toutes leurs subtilités ou nuances, ce qui peut s'avérer extrêmement difficile si ces informations sont déjà complexes par nature.
Le nombre d'exigences n'introduit généralement pas qu'un simple facteur multiplicatif à cette complexité. En effet, leur satisfaction implique souvent l'apprentissage d'informations plus ou moins décorrélées les unes des autres, et cela peut conduire à une explosion combinatoire du nombre de “cas” à considérer dans les données. Par exemple, un système de détection de panneaux routiers sur des voitures se doit de prendre en compte non seulement chacun des panneaux à détecter, mais aussi différentes conditions de vitesses, de distances, de luminosités, d'occultations et/ou etc., ce qui constitue énormément de combinaisons possibles d'observations de panneaux routiers qu'il faudra considérer dans les données d'apprentissage (et de validation).
Le volume de données et plus généralement, les efforts nécessaires pour développer une application par une approche de ML, croissent exponentiellement avec cette complexité.
Ce constat est vrai pour toutes les techniques actuelles de ML ou de DL mais on peut espérer que ce ne sera plus le cas ou moins le cas avec les futures techniques d'apprentissage qui seront vraisemblablement plus efficaces.
Quoiqu'il en soit, certaines exigences portent inévitablement sur la définition des indicateurs de performances (KPI) et sur leur niveau minimal à atteindre.
Les niveaux minimaux attendus des KPI constituent d'importants facteurs de complexité.
Trop souvent ces niveaux sont définis de manière arbitraire sans véritable analyse préalable des efforts qu'ils impliquent. A défaut d'analyse, on est souvent tenté de spécifier des applications quasi-infaillibles avec des niveaux de performances trop élevés et inatteignables.
L'approche “think big, start small” est à privilégier.
Au lieu de viser d'emblée le développement d'une application à base de ML quasi-infaillible qui risque de s'avérer rapidement irréalisable, même à long terme, il est généralement préférable de viser une application moins ambitieuse, c'est-à-dire avec des objectifs de performances moindres, mais qui sont atteignables dans un budget prédéfini.
Pour pratiquement toutes les applications à base de ML, il existe des niveaux de KPI à partir desquelles ces applications présentent un gros intérêt, sans que leur développement ne nécessite des efforts démesurés.
Le coût de développement d'une application qui ne se trompe quasiment jamais est souvent exorbitant alors que celui d'une application moins infaillible mais guère moins utile, peut s'avérer très abordable. Il est très souvent possible de développer pour un coût modéré, des applications à base de ML qui ne sont certes pas infaillibles, mais qui sont néanmoins bien meilleures que toutes les solutions préexistantes et/ou qui présentent un gros intérêt.
Prenons l'exemple des applications de détection visuelle. Beaucoup et notamment celles utilisant le modèle Alexnet qui est à l'origine du renouveau de l'IA et du DL en 2012, ont été mises aux points sur le dataset ImageNet comprenant plusieurs millions d'images pouvant représenter plusieurs milliers “d'objets” au sens large (objets, végétaux, animaux, humains, …). Le modèle Alexnet puis les modèles plus performants qui lui ont succéder, ont permis de passer d'un taux d'erreur de l'ordre de 25% sur ce dataset, à un taux d'erreur de l'ordre de 11%. Le coût de développement de ces modèles qui constituent aujourd'hui l'état de l'art, a été estimé à quelques millions d'Euros. Le coût estimé pour développer des modèles permettant de descendre à 5% d'erreur sur ImageNet avec les techniques de DL actuelles, serait approximativement de 100 milliards d'Euros ! Ce coût passerait à de l'ordre de 100 millions de milliards d'Euros si on voulait descendre à 1% d'erreur avec les techniques de DL actuelles !! Cet exemple illustre bien l'accroissement exponentiel de la complexité et des coûts de développement des applications à base de ML, en fonction du niveau de leurs KPI. Il montre même que cet accroissement peut être totalement disproportionné par rapport à l'intérêt d'avoir une application plus performante. En l'occurrence pour les applications de détection visuelle, cet intérêt d'améliorer leurs modèles de DL actuels n'est pas si grand puisque ceux-ci s'avèrent déjà très utiles sur de très nombreuses tâches en Computer Vision, dont certaines pour lesquelles ils sont déjà plus performants que les humains.
On doit vérifier les niveaux des KPI d'une application à base de ML sur chaque partie constitutive de son contexte opérationnel (ODD).
Très souvent, on valide les modèles de ML en calculant leur KPI (précision, rappel, RMSE et/ou etc.) sur l'ensemble des observations ou tests de leur dataset de validation, après s'être assuré que ces observations ou tests couvrent bien tout l'ODD de ces modèles, mais sans forcément s'être soucié :
d'une part, de leur distribution par rapport à cet ODD,
d'autre part, des possibles variations des niveaux des KPI sur cet ODD.
Cette validation est insuffisante pour un grand nombre d'applications qui ne pourront passer en production sans une validation plus rigoureuse sur chaque partie constitutive de leur ODD.
Prenons à nouveau un exemple pour illustrer ce problème. Imaginons que nous souhaitions développer une application de détection et de classification d'avions. Si cette application doit être utilisée dans un contexte professionnel soumis à des exigences de confiance et de sureté de fonctionnement, elle ne pourra pas être mise en production sans avoir vérifié quels avions peuvent être détectés et dans quelles circonstances (environnements, orientations, etc.), avec le niveau minimal de performance requis. Sa mise en production imposera aussi de connaitre ses limites et notamment les avions et/ou les circonstances pour lesquels ces performances minimales ne sont pas atteintes.
Des KPI sans intervalle de confiance ne veulent rien dire.
Trop souvent les KPI des modèles de ML sont fournis sans intervalle de confiance. Cette absence d'intervalle de confiance peut être admissible pour des POC surtout si le processus de développement de ces modèles permet de supposer plus ou moins explicitement que ces intervalles doivent être corrects. Par contre, il est en principe inconcevable de mettre en production une application soumise à des exigences de confiance, sans intervalles de confiance.
Revenons à l'exemple précédent d'une application de détection et de classification d'avions. On ne peut évidemment accorder aucune confiance à la détection d'un certain type d'avion si cette détection n'a été validée que sur seulement quelques images, quand bien même il n'y a eu aucune erreur de détection sur ces images et que les KPI pour ce type d'avion sont donc à leur niveau maximum.
Chaque dataset offre un potentiel d'apprentissage au-delà duquel aucune technique de ML ou de DL ne pourra jamais aller.
Chaque dataset (ensemble de données) renferme une quantité finie d'informations utiles pour satisfaire, par une approche de ML, tout ou partie des exigences auxquelles une application est soumise.
Il n'y a pas de magie dans le ML et donc aucune technique de ML ou de DL ne permettra d'apprendre plus que ce contenu d'informations utiles. Il est même assez rare qu'on parvienne à exploiter tout ce potentiel, même en faisant de gros efforts pour la recherche de la solution de ML ou de DL optimale.
Il est par contre très fréquent que ce contenu d'informations utiles ne couvre pas tous les aspects des informations à apprendre pour satisfaire toutes les exigences.
La qualité des données est à préférer à la quantité.
Pour faire de bons modèles de ML et pour bien les valider, il est préférable de disposer de grandes quantités de données. Cependant, il est souvent très difficile de faire de bons modèles avec des données de mauvaise qualité ou simplement de qualité médiocre, même si elles sont en grandes quantités.
Par conséquent, il est pratiquement toujours préférable de faire des efforts sur la mise en qualité et le contrôle des données avec des experts métiers, quitte à constituer des datasets plus petits, plutôt que de constituer des datasets plus gros mais avec des données de moindre qualité.
Ce constat renvoie à la formule bien connue “garbage in, garbage out” et aux facteurs clés de succès vus précédemment pour les projets de ML. La qualité des données est primordiale et cette qualité ne peut être assurée sans expertise métier suffisante.
La qualité des données constitue actuellement un des principaux enjeux pour les applications d'IA générative.
Les modèles de ML n'apprennent que lors de leurs phases d'entrainement.
Il parait utile de rappeler cette évidence quand on voit par exemple pour les applications d'IA générative, que le prompt engineering est souvent assimilé à de l'apprentissage de nouvelles connaissances. Non, le prompt engineering n'est pas un apprentissage. Il permet seulement de mieux exploiter des connaissances préalablement acquises et/ou récupérées dans une base de connaissances à l'aide de retrievers (RAG, graphRAG, etc.).
Les phases d'entrainement ou de réentrainement doivent être réalisées sous supervision humaine.
Utiliser les capacités d'auto-apprentissage offertes par certaines techniques de ML et plus particulièrement de DL, sans aucune supervision humaine, revient à admettre de prendre des risques de dérive(s) qui ne sont quasiment jamais acceptables.
Tous les modèles sont faux mais certains sont utiles.
Ce nouvel adage permet de conclure ce rappel des fondamentaux du ML sur le fait que tous nos modèles de ML sont effectivement faux puisqu'ils modélisent une réalité plus ou moins bien perçue par nous humains et que nous ne connaissons donc jamais vraiment.
La problématique fondamentale du ML revient donc à développer des modèles utiles et si possible très utiles à l'humanité, et en corollaire à son environnement.