2022-01-28
Cet article a été publié sur le site de Finance Innovation début 2020
L’intelligence artificielle semble aujourd’hui être partout, et depuis la résurrection de ce domaine de recherche en 2012[1],[2], on ne compte plus les petites révolutions scientifiques qui ont découlé. Entre autres : l’apprentissage par renforcement d’un agent dépassant les experts humain au jeu de Go[3], la résolution des problèmes de repliement de protéines[4] (un problème vieux de cinquante ans !), la capacité à générer du texte[5] localement convaincant, ou encore l’arrivée de nouvelles techniques de prédiction de séries temporelles arrivant en tête du célèbre concours M4[6]…
L’intelligence artificielle est pourtant source de nombreux problèmes dès lors que l’on veut appliquer ces techniques à un univers non académique. Le terme d’« intelligence artificielle », choisi par John McCarthy en 1956, est un terme trompeur. L’analogie entre réseau de neurone numérique et cerveau humain n’est pas justifiée scientifiquement, et se mélange vite à tout un imaginaire né de la science-fiction pour donner une vision totalement fausse de ces outils. Ainsi, la folie marketing entourant ce domaine a causé quelques catastrophes. On ne compte plus les startups[8],[9] ayant levé des millions sur de simples escroquerie encouragées par la narration « magique » de l’intelligence artificielle. Nous évoquerons plus tard certains scientifiques sérieux ayant réalisé après publication que leur « IA » n’avait que l’illusion du bon fonctionnement…
L’enjeu de cet article est de vous présenter huit grands pièges à éviter si vous voulez demain exploiter des outils issus de ce domaine de recherche. Nous verrons que ces pièges sont souvent invisibles à haut niveau, et qu’il faut donc faire preuve d’une vigilance particulière avant d’investir afin d’éviter les échecs, voire la destruction de valeur.
Faire du Machine Learning (le terme scientifique se cachant derrière les mots « intelligence artificielle »), c’est d’abord avoir accès à de la donnée en grande quantité. Cette donnée représente intégralement le problème que nous voulons résoudre.
Par exemple, imaginons un réseau de neurones ayant pour objectif de classifier des photos entre chat, panda et humain. Nous aurons donc accumulé de nombreuses images ainsi que le résultat associé (panda, chat ou humain). Nous avons dans cette donnée de départ à la fois l’input (les images) et l’output (la classe chat/panda/humain).
Une fois que nous avons cette donnée, nous allons lancer un apprentissage. Et en résultat de cet apprentissage, nous obtiendrons un modèle (une « intelligence artificielle ») qui prend en entrée des images et donne en sortie une estimation de la classe.
Une fois entraîné, la qualité du modèle peut être estimée par un score de précision et un score de rappel. Comment ces scores sont-ils calculés ? En prenant un dataset de test, petit sous-ensemble (souvent autour de 20%) de la donnée qui n’aura jamais été utilisée pendant l’entraînement, et en utilisant le modèle entraîné pour comparer sa réponse à celle qu’il aurait dû trouver. À noter toutefois que ces scores ne permettent pas de garantir à 100% que le modèle sera bon quand il sera demain en production, face à une nouvelle donnée. Cet enjeu s’appelle la généralisation.
Le risque vient du phénomène d’overfitting. Quand un modèle est en overfit, il affiche un score très haut sur les données de test, mais uniquement car il s’est spécialisé de manière erronée sur un biais de la donnée sur laquelle il a été entraîné. Si l’outil fait de l’overfit, ses résultats seront exécrables face à une nouvelle donnée ne présentant pas ce biais, et le modèle inutilisable.
Dans notre exemple, si dans la donnée d’entraînement tous les pandas se trouvent dans des forêts de bambous, tandis que ce n’est le cas d’aucun chat ni humain, la donnée est biaisée. Il y a alors toutes les chances que, plutôt que d’avoir appris à reconnaître un panda, le réseau ait appris à reconnaître une forêt de bambous – et qu’en production, si on lui présente la photo d’un humain dans une forêt de bambous, il le classifie comme un panda.
Il n’y a malheureusement pas de protection absolue contre l’overfit. Il peut naître d’une mauvaise analyse de la donnée disponible (et de la présence de biais), d’une sur-complexité du modèle, du fait que la donnée accumulée n’est pas assez représentative du problème que l’on veut adresser, etc. Il est même arrivé que des travaux de recherche prestigieux[10] soient deux ans plus tard invalidés par une analyse plus sérieuse, et aucun projet n’est complètement à l’abri.
Il est cependant possible, en suivant une méthodologie rigoureuse, de monter un projet de deep learning de telle façon que le risque d’overfit soit réduit. Mais surtout, en investissant dans des architectures data sérieuses, nous pouvons alors faire en sorte qu’en cas d’overfit il ne soit pas nécessaire de reprendre le projet à zéro.
Suggestion n°1 : Travailler au maximum la cartographie métier et statistique de la donnée, ne jamais se contenter d’une simple affirmation de résultat, auditer tout projet avant déploiement et, idéalement, ne jamais confier l’intégralité de la donnée à l’équipe en charge des modèles (notamment le dataset de test).
Suggestion n°2 : Investir dans une architecture data modulaire et non spécifique au modèle pour lequel elle est développée. Un plus haut coût d’entrée garantit que le coût de l’entraînement et du test de nouveaux modèles restera minimal, et que le budget alloué au projet d’origine ne sera pas complètement perdu en cas d’overfit.
Le résultat d’une « intelligence artificielle » est une moyenne statistique effectuée sur un sous-ensemble de la donnée, ce qui signifie que n’avons aucune garantie de résultat sur un résultat unitaire. C’est surtout vrai dans le domaine du Deep Learning (le sous-domaine du Machine Learning exploitant les réseaux de neurones numériques), et est souvent un argument en faveur des techniques plus anciennes et plus éprouvées. Ainsi, un excellent modèle peut, à tout moment et sans que l’on puisse le prévoir correctement, donner un résultat farfelu – on ne peut même pas utiliser les scores numériques en sortie d’un modèle pour pondérer le problème.
Dans notre exemple, un réseau de qualité pourra renvoyer devant une dizaine de photographies de chat des scores «chat » allant de 70 à 85% avec raison, pour ensuite identifier un humain standard comme « chat » avec un score de 98%. On comprend que l’utilisation d’un tel outil peut, selon la criticité du problème adressé, poser de sérieux problèmes.
Le respect de règles méthodologiques fondamentales permet néanmoins de mitiger la majorité des risques. La question à se poser est celle des conditions d’utilisation du modèle et de la propagation de ces risques : il y a une nette différence entre un modèle qui produit de l’aide à la décision pour des opérateurs humains et un modèle qui agit automatiquement sur des données de production ou dans la vie réelle. Par ailleurs signalons que de nombreux travaux de recherche visent à développer des modèles qui, au-delà d’un résultat, fournissent une estimation fiable de l’incertitude autour de ce résultat. Ces travaux vont des recherches sur les réseaux de neurones Bayésiens[11] aux modèles prédictifs DeepAR d’Amazon[12], mais sont encore assez complexes à utiliser.
Suggestion n°3 : Étudier avec rigueur le cadre d’utilisation du modèle, tester et garantir la mitigation des risques dans l’architecture de l’outil final hors modèle. Si l’on veut disposer d’une gestion de l’incertitude, se préparer à un investissement non négligeable en expérimentations et recherches.
Imaginons la scène suivante : une équipe d’experts en intelligence artificielle est rassemblée pour adresser un nouveau sujet : data-scientists, ingénieurs, chercheurs, experts métier. L’enjeu est de décider de l’architecture du réseau de neurones que l’on voudra implémenter. Apparaissent alors plusieurs questions :
-Quelle est la meilleure architecture fondamentale pour le problème ? -Quels succès peut-on espérer obtenir sur ce problème, notamment en termes de généralisation ? -Comment configurer cette architecture fondamentale (on parle d’hyper paramètres) ?
Aujourd’hui, il n’existe pas de moyen de répondre avec certitude à ces questions. C’est même pire : nous ne disposons pas, à date, d’une théorie mathématique explicitant correctement la convergence de ces réseaux de neurones et leur utilisation. Si de nombreux chercheurs travaillent aujourd’hui sur ce sujet (par exemple, récemment, Poggio et al[13]), une théorie claire manque à l’appel, et nous sommes fondamentalement ignorants sur un grand nombre de sujets liés à l’IA. Beaucoup d’évolutions majeures d’architecture ont été trouvées empiriquement, et de nombreuses questions fondamentales restent encore aujourd’hui sans réponse. Cela ne signifie pas que nous sommes impuissants, mais que nous ne pouvons prétendre à une maîtrise parfaite de ces outils, et que nous en devenons souvent « victimes ».
Il faut donc se méfier grandement des offres marketing proposant des solutions toutes faites permettant d’adresser n’importe quel problème d’un type donné, sans évaluation préalable des données visées. De même, l’apprentissage automatisé d’un modèle (où l’architecture « optimale » est découverte automatiquement) donne souvent des résultats peu intéressants pour un surcoût économique et écologique désastreux. Autre exemple, l’apprentissage continu – un paradigme dans lequel une « IA » ne cesserait jamais son apprentissage tout le long de son utilisation – est un sujet encore balbutiant sur le plan scientifique[14], et donc peu exploitable comme outil à ce jour, malgré l’enthousiasme débordant de certains acteurs à vendre ce type de solutions. D’une manière générale, certaines entreprises proposent aujourd’hui des solutions “clé en main” très attirantes, mais trop éloignées de la réalité technique et scientifique pour pouvoir espérer un fonctionnement satisfaisant.
Suggestion n°4 : Toujours faire le lien entre une affirmation marketing et la réalité du monde académique. En recherche de modèle, ne jamais hésiter à utiliser le rasoir d’Ockham : entre deux solutions équivalentes, la plus simple est par définition la meilleure.
Dans un projet logiciel classique, quand une erreur est détectée dans le logiciel, elle est analysée puis corrigée, et une architecture de test du logiciel permet de garantir sa qualité et son bon fonctionnement dans le temps.
Cette vision relève aujourd’hui du fantasme en Deep Learning. Les réseaux de neurones sont des « boîtes noires ». Nous ne savons pas tester unitairement une sous-partie d’un réseau. Nous ne savons pas non plus parcourir correctement le champs des possibles d’un réseau de manière à pouvoir garantir son bon fonctionnement (puisque nous n’avons aucune garantie sur un résultat unique). Et pire : si une erreur est trouvée, nous n’avons pas de moyen de corriger cette erreur directement, et devons souvent réfléchir à réentraîner entièrement le modèle en « espérant » qu’elle disparaîtra.
Bienvenue dans le monde de l’intelligence artificielle ! Où l’on travaille sur des boîtes noires que nous validons avec des indicateurs statistiques et que nous ne savons pas tester ni corriger d’une manière satisfaisante. Cependant, la recherche académique ne s’arrête pas (cet article de Deepmind [15]donne de nombreux axes de recherche récents), et de nouveaux outils sont apparus, comme Lucid[16], DeepHunter [17]ou DeepGauge[18]. Mais ces outils ne sont que des moyens incrémentaux d’améliorer la qualité ou la compréhension d’un modèle. Pour preuve, très récemment, Microsoft[19] a proposé un nouveau canevas de test qui prend acte de ces limites de l’intelligence artificielle et agit donc avec un moteur de génération de tests aléatoires, de manière à maximiser la vérification du modèle. Cette approche semble être aujourd’hui, de loin, la plus pertinente.
Suggestion n°5 : On ne peut pas garantir la robustesse d’un modèle, mais on peut faire le maximum en s’appuyant sur les travaux de recherche récents. Et il faut idéalement pouvoir faire du test statistique, ce qui implique une maîtrise fine de la donnée et des moteurs de génération contrôlés.
Dans l’industrie, une « intelligence artificielle » est implémentée au sein d’un système d’information. Dès lors se posent un certain nombre de questions liées à l’industrialisation, notamment des questions de sécurité de l’outil logiciel. Et les modèles IA, s’ils n’échappent pas à ces questions, introduisent de nouveaux risques.
Le terme anglais « adversarial attack » décrit une familles d’attaques[20] de sécurité spécifique aux réseaux de neurones. Ces attaques, en substance, permettent de modifier d’une manière imperceptible un élément d’entrée pour contrôler totalement le résultat produit par le réseau de neurones : un agent ayant accès à la donnée en amont du modèle pourrait donc en théorie contrôler totalement la sortie de ce modèle.
Ces failles de sécurité sont une composante fondamentale du Deep Learning. Depuis 2014 et leur découverte, chaque tentative de protection contre ces attaques a été annulée dans les mois qui suivaient par une attaque concurrente. Il faut donc considérer qu’elles sont toujours possibles et agir en conséquence.
__Suggestion n°6 __: L’utilisation d’intelligence artificielle demande une rigueur particulière sur les risques de sécurité qui y sont liés. Un tel modèle doit être encadré et protégé au maximum, afin d’éviter toute manipulation malicieuse de l’outil.
Ce point sous-tend un grand nombre des pièges déjà présentés, et en donne une des raisons principales. La révolution du Deep Learning est très récente (2012) et a lancé une vague de fond dans le monde de la recherche, le nombre de publications scientifiques et de travaux académiques a proprement explosé, avec aujourd’hui une saturation des conférences les plus en vues.
Ainsi, l’immense majorité des informations que nous recevons sur le sujet de l’IA vient de travaux de recherche, et il est vital de comprendre que ces travaux n’ont pas les mêmes contraintes et les mêmes objectifs qu’un outil de production.
En effet, ces univers sont très éloignés. Dans le monde de la recherche, l’objectif est d’être « état de l’art », autrement dit, d’avoir le meilleur score absolu sur un dataset de recherche spécifique. Du point de vue industriel où l’on désire surtout avoir un outil fonctionnel et contrôlé, plusieurs problèmes surviennent : -Un chercheur qui gagne 1% sur un dataset de recherche sera état de l’art et donc « en tête ». Or ce gain à l’intérêt discutable pour des utilisations métier dans l’industrie n’est pas forcément justifié, notamment s’il se paie par une surcharge en temps d’entraînement. -La recherche va très vite, parfois trop. Il est toujours nécessaire d’avoir du recul sur les travaux proposés, afin de vérifier par reproduction la qualité et les limites des évolutions précisées. Régulièrement, des travaux en apparence révolutionnaires sont pondérés, voire invalidés un peu plus tard. -Ce n’est pas parce qu’une architecture fonctionne sur un dataset de recherche qu’elle fonctionnera sur une donnée « métier ». Ces datasets de référence comportent déjà des défauts propres, mais toute différence significative avec une donnée d’application pourra empêcher ce bon fonctionnement souhaité. -Enfin, les scores utilisés dans la recherche (BLEU en traitement, Scores du Pascal VOC Dataset) sont des scores particuliers qui ne seront pas forcément en accord avec l’idée d’un « bon fonctionnement » dans une optique d’outil métier.
Pourtant, suivre la recherche est indispensable. Un sujet initialement inapplicable dans l’industrie peut subitement devenir simple d’application du jour au lendemain. De plus, la majorité des innovations proposées par les grands acteurs (Google, FAIR, etc) sont accompagnées d’un code source exploitable.
Suggestion n°7 : Suivre attentivement la recherche académique pour pouvoir être réellement efficace, mais en prenant soin d’avoir du recul et de vérifier la bonne adéquation avec le problème métier final, notamment concernant les datasets et les scores.
Ce sujet peut sembler secondaire, mais peut souvent revenir au cours d’un projet, souvent au pire moment, et entraîner un blocage total de l’avancement des travaux. En effet, depuis la législation RGPD, la manipulation de donnée pouvant identifier une personne est strictement encadrée. Or, de nombreux sujets Big Data concernent de près de ou de loin des activités ou informations utilisateurs, et exigent donc un travail sérieux d’anonymisation de la donnée.
Or anonymiser est une tâche non triviale, allant au-delà des simples expressions régulières qu’on utilise classiquement, l’enjeu étant de confirmer qu’il est bien impossible d’identifier une personne d’une manière unique. De plus, l’objectif est de réussir cette anonymisation (avec destruction de données) tout en conservant suffisamment d’informations pertinentes pour entraîner un modèle d’intelligence artificielle. Cela suppose un travail progressif et suivi avec rigueur, avec notamment des test poussés de l’anonymisation finale.
Par ailleurs, la légende voulant que la donnée utilisée pour entraîner un réseau de neurones ne pourrait pas être ensuite extraite du modèle final est absolument fausse. Rappelons que l’on a récemment réussi[21], en travaillant le récent OpenGPT de génération de texte, à en extraire des données personnelles. Les impacts légaux peuvent s’annoncer destructeurs.
Suggestion n°8: Ne jamais sous-estimer l’anonymisation, et auditer tout processus supposé effectuer une telle tâche en vérifiant si l’on peut identifier unitairement une personne. Ne jamais lancer l’entraînement d’un modèle IA sur une donnée non correctement anonymisée.
Concluons sur ce point : beaucoup d’acteurs veulent aujourd’hui se positionner dans ce nouveau domaine et investir dans des projets d’intelligence artificielle. Souvent, ces acteurs décident de développer un nouvel algorithme de réseaux de neurones et mettent sur pied des équipes de taille conséquente pour arriver les premiers à cette fin.
Malheureusement, ce type de démarche est généralement voué à l’échec. Deux constats permettent cette affirmation : -La rareté des ressources de qualité disponibles en recherche dans ce domaine. Les GAFAs sont déjà passé par là à partir de 2014, offrant des rémunérations sans commune mesure. -Qui plus est, ces acteurs acceptent toujours que leurs chercheurs publient publiquement leurs travaux et leurs avancées. Ces publications, pour la majorité d’entre elles, s’accompagnent de code source exploitable. -Au-delà des ressources, il y a peu de chance qu’une équipe interne à une entreprise puisse entrer en concurrence avec les moyens de recherche et les quantités de données colossales appuyant Google (Google brain, Deepmind, Google AI), Facebook (l’excellent FAIR), Microsoft, Uber, sans parler des nombreuses universités prestigieuses travaillant ces sujets depuis plus de dix ans.
Pourquoi ces acteurs publient-ils les algorithmes qui leur ont coûté des millions à développer ? C’est parce que le véritable verrou permettant d’exploiter ces nouveaux outils se trouve dans la donnée : une donnée qui doit être annotée, qualifiée, maîtrisée et cartographiée statistiquement. Cette donnée a beaucoup plus de valeur, et sans surprise, les GAFAs ne publient que très rarement les datasets sur lesquels ils travaillent.
Suggestion n°9: Aujourd’hui, un acteur désireux d’investir dans ce domaine et de saisir des opportunités a donc intérêt à commencer par travailler et qualifier sérieusement sa donnée, ce qui lui permettra ensuite d’être opportuniste sur les travaux de recherche qui sortent chaque jour.