Intelligence Artificielle : démocratisation en vue, place à l'AI Engineering - partie 2

Auteurs :

Jérôme BESSON

Directeur

Contactez

7 minutes

Les entreprises qui ont expérimenté l’IA sont aujourd’hui à un point d’inflexion et s’interrogent sur comment franchir le cap de l’expérimentation. Nombre de projets tagués IA ne passent en effet pas en production alors que les technologies se démocratisent et les pratiques se répandent. Dans cette deuxième partie, découvrez pourquoi un modèle d'IA n'est pas un composant logiciel comme les autres et nécessite un cycle de vie tout à fait particulier.

#Des singularités pour lesquelles l’entreprise n’est pas préparée

Contrairement aux produits logiciels traditionnels, les produits logiciels ‘data science’ basés sur des algorithmes d’apprentissage (‘machine learning’ & ‘deep learning’) sont régis par 3 cycles de vie imbriqués, ayant chacun des spécificités et réclamant des compétences particulières.

Le premier concerne la mise au point du modèle, le second porte sur son opérationnalisation et le troisième sur son exploitation.

Autre singularité, la nature intrinsèque d’un modèle. Un modèle de ‘machine learning’ consiste au final essentiellement en un algorithme mathématiques, des poids et des hyper-paramètres calibrant le fonctionnement de l'algorithme. Poids et hyper-paramètres sont des données, pas du code, alors que l’algorithme lui est une référence dans une bibliothèque statique.

##Des modèles par nature empiriques

Un modèle d’intelligence artificielle est par nature empirique. De nombreux facteurs l’expliquent.

Tout d’abord son processus de mise au point expérimental où de nombreux éléments influent sur sa qualité. En premier lieu la pertinence des données et l’algorithme utilisé.

En effet, les modèles les plus en vogues aujourd’hui dans les entreprises sont obtenus en nourrissant un algorithme mathématique de données labellisées (‘Training data set’), c’est-à-dire de données dont on connait préalablement le sens recherché, la réponse attendue. L’apprentissage consiste à trouver les bons paramètres de l’algorithme, à les optimiser, les ajuster. Le but est d’obtenir un taux d’erreur marginal sur les données d’apprentissage, sachant qu’aucun modèle ne donne de prédiction juste à 100%. Trouver les justes paramètres est un travail itératif, complexe, long et coûteux et fortement tributaire du jeu de données d’apprentissage. Ce dernier devant être suffisamment vaste et représentatif dans sa distribution pour atteindre l’objectif visé et ne pas être entaché de biais.

##La généralisation, seul juge de paix

Tout l’enjeu de l’apprentissage est de pouvoir généraliser le modèle c’est-à-dire que l’algorithme soit capable sur des données qu’il n’a jamais rencontrées de prédire une réponse avec une précision élevée. La qualité d’un modèle se mesure d’ailleurs d’abord sur ce critère de généralisation. La validation de la généralisation se fait en exposant le modèle à un jeu de données qu’il n’a jamais vu. Ce jeu de données (‘Validation data set’) est constitué à partir des données initiales dont une partie sert à l'entrainement et l'autre est mise de côté pour tester la performance de l'entrainement. L’échantillon de généralisation doit conserver les caractéristiques représentatives du jeu d’ensemble.

La généralisation est rendue possible dès lors qu’il existe une régularité connue, c'est à dire que les données peuvent être corrélées de façon à ce que le modèle soit capable de faire une prédiction fiable quasi systématiquement. Trouver cette régularité est une tâche d’autant plus ardue que les données en entrées sont disparates et décrites par un grand nombre de variables, de dimensions. Plus le nombre de variables sera élevé, plus la disparité spatiale des données d’apprentissage le sera et donc la corrélation entre elles complexes. Concrètement si l’on projette les données d’apprentissage dans cet espace multidimensionnel, elles apparaîtront extrêmement éloignées les unes des autres sans régularité apparente. Pour surmonter cette sur-dimensionalité, il faut être en mesure de les réorganiser pour faire apparaître des regroupements (‘Clusters’) séparant clairement des frontières entre des ensembles de données. Chaque frontière délimitant les réponses possibles du modèle. La bonne nouvelle est que des outils mathématiques existent pour y arriver, c’est-à-dire pour caractériser cette régularité. Ils permettent d’une part de réduire le nombre de dimensions (variables) en ne conservant que celles discriminantes sans pour autant dénaturer le ‘data set’ et d’autres part de découvrir les régularités, les regroupements permettant de dessiner des frontières aplaties abaissant le nombre de dimension et leur spatialité (‘feature engineering’). Chaque espace de part et d’autre d’une frontière correspond ainsi à une prédiction connue. Dès lors, si on positionne une donnée non connue de l’algorithme dans cet espace de moindre dimension, l’algorithme est capable de la positionner d’un côté ou d’un autre d’une des frontières et ainsi prédire une réponse rapide et fiable.

##Les biais, attention dangers

La validation du modèle métier est en elle-même une source de préoccupation. Il convient de s’assurer que le modèle ne présente pas de biais cognitif c’est-à-dire une altération et donc un faussement des prédictions. Le biais est directement lié au jeu de données d’entraînement. Si ce dernier en comporte, le modèle les reconduira, voire les amplifiera. Un biais n’est pas toujours trivial à détecter. Tout un pan de recherche leur est consacré aujourd’hui pour produire des modèles au comportement équitable (‘Fair AI’).

##L’explicabilité, le talon d’Achille

Une autre source de préoccupation est la capacité à expliquer la prédiction d’un modèle (‘Explainable & Interpretable AI’). Lorsque la dimensionalité est importante et que les variables ont été autodéterminées, elles ne présentent aucune lisibilité humainement compréhensible et les mathématiques sont aujourd’hui incapables de nous apporter une réponse logique à la prédiction faite. Une situation qui pose clairement un problème de responsabilité et de conformité (‘Responsible AI’).

##Une opérationnalisation délicate

L’opérationnalisation consiste à rendre exécutable le modèle expérimental développé. Une opération qui peut demander un effort plus ou moins important selon la sensibilité du modèle (métier et technique), ses contextes d'usage et sa performance à l'exécution attendue. Les travaux de ‘data science’ produisent en effet rarement des modèles prêts à déployer, les ‘data scientists’ étant ni des développeurs chevronnés ni des épris de normes et standards par rapport à l’empirisme de leur activité. Ils se soucient peu des problématiques de qualité du code (‘craftmanship’), d’invocation et de sollicitation, de performance (‘scalabilty’), de sécurité, de supervision et de compatibilité avec les environnements de production disponibles à l’exécution. Ils ignorent le sujet d’intégration au système d’information pourtant critique. Ils n’hésitent pas à multiplier les langages pour opérer les nécessaires transformations sur les données (‘data pre-processing’).

L'opérationnalisation peut ainsi comporter différentes opérations pour en garantir le niveau de service : nettoyage, harmonisation, restructuration, voire réécriture de parties de code pour produire un modèle robuste et performant sur les différents environnements cibles (‘device embedded, edge, cloud’).

L’opérationnalisation doit également embarquer les mécanismes permettant d’analyser la distribution des données en entrée et en sortie pour anticiper les risques de dérive dans ses prédictions. Une analyse qui peut être faite à froid où à chaud selon la sensibilité métier du modèle et l’impératif, l’urgence de réaction en cas de dysfonctionnement.

Le modèle opérationnalisé n’est pourtant pas la fin du chemin. Deux étapes clés restent à franchir, son intégration au système d’information en regard de sa finalité d’usage et son exploitation où le modèle va être exposé aux données réelles et où sa dérive et ses performances devront être 'monitorées' de près.

##Une intégration à ne pas négliger

Les singularités propres aux modèles d’intelligence artificielle imposent de pouvoir réagir rapidement en cas de dérive. Le modèle opérationnalisé doit être intégré de façon telle qu’en cas de disfonctionnement ils ne mettent pas en péril l’exécution du processus métier ou l’aide à la décision à laquelle il contribue. Il doit pouvoir être remplacé, substitué à chaud et de façon transparente par un modèle recalibré, voire débranché totalement si nécessaire tout en permettant un mode de fonctionnement dégradé, par exemple en étant remplacé par un algorithme déterministe.

##Une exploitation à placer sous haute surveillance

L’exploitation du modèle est aussi problématique. Il faut en effet s’assurer que le profil des données réelles ne dérive pas avec celui des données ayant servi à son entrainement en termes de distribution (‘data drift‘) et/ou de caractéristiques (‘data leakage’). Il faut pouvoir déclencher si besoin un réentrainement (‘model retraining’) où à l’extrême le développement d’un nouveau modèle (‘model refitting’). Avant de substituer le modèle en production, il faut s’assurer que le nouveau modèle permet à minima de rétablir la performance nominale. Cela implique de pouvoir faire cohabiter plusieurs modèles concurrents ou versions d’un même modèle (‘A/B testing, blue-green & Canary deployment’).

Ne manquez pas la suite dans notre prochaine article où nous verrons l'intérêt de mettre en place une plateforme d'intelligence artificielle d'entreprise.

Si vous avez manqué la première partie de cet article. Vous avez aimé ? Lire la suite sur l'Enterprise Intelligent Platform.

Pour aller plus loin, découvrez une des interventions de Sentelis pour la filiale spécialiste des technologies de l’information d’un groupe international banque-assurance ; Sentelis a réalisé l’opérationnalisation de modèles de ‘machine learning’ (Intelligence artificielle) produits par le 'Lab Data Science'.

Intéressé(e) par l'intelligence artificielle, contactez-nous ?