Qu’est-ce que la validation des modèles ?

Au lieu de se contenter de demander si le modèle produit une réponse, la validation d’un modèle consiste à vérifier si la conception, les hypothèses, les données, la mise en œuvre, les résultats, les limites et le comportement à long terme du modèle sont suffisamment fiables pour étayer les décisions que les utilisateurs prendront à partir de celui-ci.

La validation de modèle permet aux entreprises de réduire le risque lié au modèle, c’est-à-dire le risque qu’un modèle produise des résultats inexacts, biaisés, instables, dangereux ou susceptibles d’être utilisés à mauvais escient, en évaluant de manière proactive la façon dont le modèle remplit ses fonctions.

Pour une validation simple, les développeurs de modèles peuvent se contenter d’évaluer le modèle candidat par rapport à un ensemble de validation (l’ensemble d’exemples que les ingénieurs en ML et les data scientists utilisent pour vérifier la qualité de l’apprentissage d’un modèle) au cours du développement.

Au niveau de la gestion des risques liés aux modèles, cependant, la validation des modèles revêt une portée bien plus large. En règle générale, la validation des modèles d’entreprise consiste en une évaluation indépendante de l’ensemble du cycle de vie du modèle. Le modèle de ML est examiné par des personnes qui ne sont pas ses créateurs, et cet examen porte sur la manière dont le modèle a été construit, déployé, utilisé, surveillé, modifié et, finalement, retiré de service.

Un processus de validation réussi établit cinq éléments.

1. Le modèle de ML a un objectif clair ainsi qu’une population, un champ d’application et un contexte décisionnel bien définis.
2. L’approche conceptuelle (la méthode sous-jacente de mappage entre les entrées et les sorties, la logique et les hypothèses) du modèle est pertinente pour cet objectif.
3. Les données employées par le modèle et la mise en œuvre de celui-ci sont précises et contrôlées.
4. Le modèle fonctionne correctement sur les données pertinentes, y compris celles qu’il n’a pas vues pendant son développement.
5. L’entreprise comprend les limites du modèle et prend des mesures en cas de dégradation des performances.

La rigueur du processus de validation du modèle correspond généralement à l’objectif de celui-ci. Un outil de forecasting interne à faible impact n’a pas besoin d’être examiné aussi minutieusement qu’un modèle servant à approuver des prêts immobiliers ou à détecter des transactions bancaires frauduleuses.

Il est important de noter que la validation d’un modèle n’est pas une procédure d’approbation ponctuelle. Même s’ils fonctionnent bien au départ, les modèles peuvent dériver et se dégrader après leur mise en service. C’est pourquoi la validation continue des modèles de ML est souvent intégrée aux pratiques de gouvernance de l’intelligence artificielle (IA) d’une entreprise.

Selon le cadre de gestion des risques liés à l’IA du NIST, les piliers de la confiance dans les modèles comprennent la validité et la fiabilité, la sûreté, la sécurité et la résilience, la responsabilité et la transparence, l’explicabilité et l’interprétabilité, le renforcement de la confidentialité, ainsi que la gestion de l’équité et des biais.

La validation des modèles de machine learning contribue à établir et à maintenir la confiance dans les modèles (le niveau de confiance légitime dans le fait qu’un modèle se comportera de manière appropriée). Les entreprises prennent des décisions sur la base des résultats des modèles de ML ; la confiance dans les modèles n’est donc pas seulement un enjeu de réputation. Elle est fondamentale pour une utilisation sûre, efficace et évolutive de l’IA. En effet, les objectifs en matière de confiance dans les modèles orientent souvent les pratiques de validation.

De plus, un modèle ne peut être considéré comme fiable simplement parce que son développeur le qualifie d’« IA responsable ». Les modèles doivent être capables d’accomplir leurs tâches avec fiabilité, de protéger les personnes et les données, de résister aux utilisations abusives, et d’être compris et gouvernés. Ce niveau de confiance doit être mérité grâce à des contrôles démontrables et à la collecte persistante de preuves tout au long de la validation du modèle d’IA.

Le cadre de gestion des risques liés à l’IA du National Institute of Standards and Technology (NIST) constitue un outil largement adopté pour comprendre les piliers de la confiance dans les modèles. Il identifie sept caractéristiques interdépendantes d’une IA digne de confiance.

Un modèle digne de confiance doit être valide pour la tâche qui lui est assignée et fiable dans le temps, dans toutes les conditions prévues. La validité consiste à vérifier si le modèle mesure, prédit, classe ou génère effectivement ce qu’il prétend faire.

La fiabilité consiste à vérifier si le modèle agit de manière cohérente et fiable lorsqu’on lui fournit des entrées comparables, y compris des entrées provenant de différents utilisateurs, environnements, sources de données et périodes.

Le pilier de la sécurité vise à déterminer si le modèle peut causer un préjudice aux personnes, aux biens, aux entreprises ou à la société, même lorsqu’il fonctionne techniquement comme prévu.

Un modèle peut être à la fois précis et dangereux. Par exemple, un chatbot de service client peut récupérer correctement des informations de compte, mais s’il peut être manipulé pour divulguer des données sensibles, son déploiement reste dangereux. La sûreté exige que les équipes identifient les risques prévisibles avant le déploiement et y remédient de manière proactive lors de la conception du système.

La sécurité protège le modèle, ses données, ses interfaces et l’application qui l’entoure contre tout accès malveillant ou toute manipulation. Pour les systèmes d’IA modernes, la surface d’attaque s’étend bien au-delà des poids du modèle. Elle inclut également les données d’entraînement, les sources de récupération, les prompts, les interfaces de programmation d’applications (API), les plug-ins, les identités utilisateurs, l’infrastructure de déploiement, les journaux et les chaînes d’approvisionnement des modèles. Les contrôles de sécurité doivent être capables de gérer l’intégralité de la surface d’attaque.

La résilience fait référence à la capacité du modèle à continuer de fonctionner en toute sécurité, à se rétablir de manière adéquate ou à échouer en douceur si un problème survient. Cela implique de vérifier que les modèles sont capables de gérer aussi bien les perturbations non malveillantes que les cyberattaques. Dans un contexte à fort impact, échouer en toute sécurité est souvent plus important que de simplement rester disponible.

La responsabilité signifie que des responsables désignés sont chargés de la conception, du déploiement, des résultats et de la résolution du modèle. Sans cette responsabilité, une entreprise peut se contenter de dire que « c’est l’IA qui a décidé » lorsqu’un problème survient.

La transparence signifie que toutes les informations pertinentes concernant le système, ses résultats, ses limites et sa gouvernance sont mises à la disposition des personnes qui en ont besoin. Elle n’exige pas des entreprises qu’elles divulguent leur code source propriétaire ou des détails sensibles en matière de sécurité. Elle implique de communiquer suffisamment d’informations précises et exploitables pour que les parties prenantes puissent appréhender l’ensemble du système.

L’explicabilité et l’interprétabilité aident les utilisateurs à comprendre comment un modèle fonctionne et ce que ses résultats signifient dans le contexte d’une décision concrète. En termes simples, l’explicabilité pose la question suivante : « Quels facteurs ou processus ont conduit à ce résultat ? », tandis que l’interprétabilité demande : « Que signifie ce résultat, et comment une personne doit-elle l’utiliser ? »

Ce pilier revêt une importance capitale lorsque les décisions ont des conséquences importantes, sont contestées, réglementées ou difficiles à annuler (la modélisation du risque de crédit, par exemple).

La confidentialité est étroitement liée à la sécurité, mais ces concepts sont distincts. La sécurité empêche des tiers non autorisés d’accéder aux données, tandis que la confidentialité contribue à garantir que les données sont collectées, utilisées, stockées et partagées de manière appropriée.

Les modèles peuvent présenter un risque en matière de confidentialité même lorsqu’ils ne sont pas explicitement conçus pour traiter des données personnelles. Les jeux de données d’entraînement des modèles peuvent contenir des informations sensibles, et les journaux peuvent conserver des données utilisateur qui n’étaient censées être stockées que temporairement. Les pratiques de validation des modèles aident les entreprises à s’assurer que les outils d’IA sont à la fois sécurisés et conformes aux règles de confidentialité.

L’équité exige d’une organisation qu’elle identifie, mesure, réduise et surveille les biais préjudiciables. Cela ne signifie pas que chaque personne doit toujours recevoir le même résultat. Au contraire, les différences de traitement ou de résultats doivent être justifiées, légales, pertinentes par rapport à la tâche et ne pas être motivées par des biais évitables ou préjudiciables.

La validation des modèles comprend généralement toute une série de contrôles et de techniques de validation différents.

La rigueur conceptuelle évalue la logique et la conception sous-jacentes du modèle. Elle permet de déterminer si la méthodologie, les données d’entrée, les hypothèses, les jugements qualitatifs et les choix de conception sont adaptés aux décisions que le modèle est censé soutenir. Les contrôles de rigueur comprennent :

• l’évaluation de la méthodologie du modèle afin de comprendre comment celui-ci convertit les données en résultats ;

• l’examen des caractéristiques et des données d’entrée pour confirmer que chaque caractéristique importante est pertinente, disponible et conforme à la loi ;

• la remise en question des hypothèses à des fins de documentation et de suivi ;

• l’identification des limites et des facteurs manquants afin de déterminer ce que le modèle ignore et de comprendre les contextes dans lesquels il devient moins fiable ;

• l’évaluation de l’interprétabilité et de la pertinence d’utilisation afin de déterminer pourquoi un modèle produit ses résultats et dans quels cas il pourrait échouer.

La validation des données aide les équipes à déterminer si les données utilisées pour concevoir, ajuster, tester et exécuter un modèle sont fiables. La validation des données comprend :

• L’évaluation de la qualité des données. Les contrôles de qualité des données visent à garantir que les enregistrements sont exacts, complets, pertinents, représentatifs, correctement étiquetés, obtenus légalement, protégés et séparés.

• La mise en place de la provenance et de la traçabilité. Les examens de validation doivent permettre de remonter jusqu’à une source identifiable pour chaque jeu de données et chaque caractéristique.

• La confirmation de la pertinence par rapport à la tâche. Confirmer la pertinence signifie vérifier si chaque élément de données du modèle reflète des informations qui sont significativement liées à l’objectif du modèle.

• La vérification des étiquettes et de la vérité terrain. La validation des étiquettes garantit que celles-ci produisent des résultats qui sont des représentations précises, appropriées et définies de manière cohérente du résultat cible. Elle identifie également la norme de référence : la meilleure base disponible pour déterminer ce qui est vrai.

L’analyse des résultats poursuit deux objectifs principaux. Premièrement, elle détermine si les résultats du modèle correspondent aux conditions réelles qu’il prétend prédire. Deuxièmement, elle examine si l’utilisation de ces résultats aide réellement une entreprise à atteindre l’objectif visé sans entraîner de préjudice, de coût ou de risque inacceptable. L’analyse des résultats peut demander aux équipes de :

• Comparer les prévisions aux résultats. L’analyse des résultats attend, recueille ou établit la « vérité terrain » du modèle et la compare à ses résultats.

• Recourir aux tests rétroactifs. Ils consistent à appliquer un modèle à des cas passés en utilisant uniquement les informations qui auraient été disponibles à ce moment historique, puis à comparer les prévisions du modèle avec ce qui s’est réellement produit.

• Examiner les erreurs de rappel et de prédiction. Les modèles problématiques peuvent produire des faux positifs et des faux négatifs. L’analyse des résultats mesure ces deux types d’erreurs, évalue leurs conséquences et détermine si elles dépassent le seuil de risque de l’organisation.

• Vérifier l’étalonnage. L’étalonnage consiste à vérifier si les probabilités indiquées par un modèle correspondent aux fréquences observées. Si un modèle attribue une probabilité de fraude de 70 % à 1 000 transactions, environ 700 de ces transactions devraient finalement être confirmées comme frauduleuses. Si seules 250 sont confirmées, ou si 850 le sont, le modèle estime le risque de manière erronée.

• Évaluer l’impact commercial et opérationnel. L’analyse des résultats examine si le modèle contribue à l’objectif réel pour lequel il a été déployé.

Valider la robustesse et la sensibilité d’un modèle permet de s’assurer qu’il continue à se comporter de manière fiable lorsque les conditions sont imparfaites, anormales ou délibérément hostiles.

La sensibilité n’est pas mauvaise en soi. Certaines données d’entrée doivent fortement influencer les résultats d’un modèle. Une modification récente apportée à un compte privilégié, par exemple, modifie de manière raisonnable le score de risque de cybersécurité de ce compte. Le problème réside dans une sensibilité injustifiée, où des changements mineurs, non pertinents ou courants ont un effet disproportionné sur le comportement du modèle.

Les équipes peuvent tester le modèle avec :

• Des données d’entrée bruitées et incomplètes. Les tests de robustesse simulent des conditions telles que des données manquantes ou des entrées erronées afin d’évaluer l’impact des données de mauvaise qualité sur les performances du modèle et ses réponses. Cela permet d’éviter le sous-ajustement (lorsqu’un modèle n’apprend pas suffisamment à partir des données d’entraînement et ne parvient donc pas à reconnaître les modèles) et le surajustement (lorsqu’un modèle mémorise trop de données d’entraînement, y compris le bruit).

• Des changements de conditions. Les modèles de machine learning doivent être capables de gérer les changements de distribution (nouvelles politiques, interruptions de service, dérive conceptuelle), lorsque les données de production ne ressemblent plus aux données de développement. Les évaluateurs peuvent utiliser des périodes plus récentes, de nouveaux environnements et des cas hors distribution délibérément construits pour vérifier si les performances du modèle se détériorent au-delà des niveaux acceptables.

• Des cas limites et l’incertitude. Les cas limites révèlent souvent des suppositions cachées dans un modèle. Vérifier comment le modèle réagit à de tels scénarios permet aux équipes de voir si le modèle reconnaît l’incertitude et utilise une solution de repli appropriée.

• Des entrées adverses. La validation des entrées adverses évalue si quelqu’un peut intentionnellement manipuler le modèle pour générer une sortie incorrecte, dangereuse, non autorisée ou trompeuse.

• La dérive des modèles. Les équipes peuvent recourir à la simulation de dérive pour créer délibérément des scénarios dans lesquels les données de production, le comportement des utilisateurs ou la relation entre les entrées et les résultats ont changé, puis vérifier si le modèle se dégrade en douceur et si les contrôles réagissent correctement.

Les analyses comparatives et les tests de mise au défi évaluent si un modèle apporte véritablement une valeur ajoutée en le comparant à des alternatives crédibles. Les entreprises ont recours à ces pratiques pour déterminer si un modèle offre des performances nettement supérieures à celles d’une méthode plus simple, d’un modèle antérieur, d’un processus humain ou d’un modèle challenger développé de manière indépendante (construit ou sélectionné spécifiquement pour valider le comportement du modèle candidat).

• Les points de référence (tels que les modèles de production antérieurs ou les modèles challengers) servent à évaluer les modèles de ML. Le modèle principal n’a pas besoin de surpasser toutes les alternatives sur chaque indicateur de performance. Les équipes doivent simplement comprendre les compromis afin de pouvoir justifier les modèles qu’elles choisissent.

• Les tests de mise au défi désignent la pratique plus large consistant à tenter de réfuter l’adéquation d’un modèle à l’usage auquel il est destiné. Outre les situations de test où le modèle est censé bien fonctionner, les tests de mise au défi vérifient les scénarios d’échec les plus probables.

Les contrôles de sûreté, de sécurité et de confidentialité évaluent les différents risques qu’un modèle peut engendrer, mais de nombreuses faiblesses résident dans les intégrations autour d’un modèle de ML plutôt que dans le modèle lui-même.

Un modèle peut, par exemple, disposer d’une politique interne stricte contre la divulgation d’informations confidentielles, mais une application pourrait tout de même exposer des documents privés si son système de récupération ne parvient pas à faire respecter les autorisations d’accès aux documents. De même, un modèle peut résister à un débridage basique, mais un agent construit autour de celui-ci peut tout de même effectuer une action dangereuse parce qu’une page récupérée contenait une injection indirecte de prompt.

Par conséquent, une validation efficace exige que les équipes évaluent le modèle et l’ensemble de l’écosystème qui l’entoure.

La documentation et la reproductibilité font de la validation un ensemble de preuves vérifiables, plutôt qu’une simple affirmation informelle selon laquelle un modèle « fonctionne ».

La documentation couvre l’ensemble du cycle de vie d’un modèle de ML, depuis l’analyse de rentabilité initiale jusqu’au développement, à la validation, au déploiement, à la surveillance, aux modifications substantielles et, finalement, à la mise hors service. Elle implique de consigner la généalogie du modèle et de maintenir un contrôle des versions clair, ce qui permet aux évaluateurs de comprendre comment le modèle évolue au fil du temps.

La reproductibilité permet de garantir qu’un évaluateur indépendant qualifié puisse utiliser les documents fournis pour reproduire le processus de développement ou de validation du modèle et obtenir plus ou moins les mêmes résultats.

La validation, les tests et la surveillance des modèles sont des pratiques d’assurance qualité liées, mais elles répondent à des questions différentes à des étapes différentes du cycle de vie d’un modèle de machine learning :

• La validation pose la question suivante : « Le modèle est-il adapté, fiable et correctement conçu pour l’usage auquel il est destiné ? »

• Les tests posent la question suivante : « Le modèle finalisé répond-il à ses critères d’acceptation prédéfinis sur les plans technique, commercial, de sécurité et opérationnel ? »

• La surveillance pose la question suivante : « Le modèle déployé continue-t-il à fonctionner correctement avec des données réelles dans des conditions réelles ? »

Les tests du modèle ont lieu tout au long du processus de développement, mais l’évaluation formelle sur un jeu de données de test intervient généralement après que les équipes ont finalisé les principaux choix de conception et les décisions de réglage. Les tests sont souvent menés par une personne indépendante des décisions relatives au développement du modèle. Dans le cas des techniques train_test_split, on emploie également un jeu de données de test distinct qui n’a pas servi à l’entraînement, au réglage des hyperparamètres, à la sélection des seuils ou à la sélection du modèle, afin d’obtenir une estimation crédible et non biaisée des performances du modèle finalisé sur des données véritablement inédites.

Les entreprises peuvent choisir parmi toute une gamme d’approches d’évaluation des modèles.

Les ensembles de rétention, par exemple, consistent à mettre de côté une partie des données, à l’écart de l’entraînement et du développement du modèle, puis à utiliser ces données mises de côté pour évaluer les performances du modèle final sur des cas inédits. Les équipes peuvent recourir à la validation croisée à k blocs, où le modèle est entraîné et testé k fois sur différentes portions des données, puis la moyenne des résultats est calculée. Ou, pour une forme plus rigoureuse de validation croisée à k blocs, une équipe peut recourir à la validation croisée d’un contre tous (LOOCV), dans laquelle le modèle est testé simultanément sur chaque point de données. Quelle que soit la méthode, les tests de modèle visent à prédire la qualité d’un modèle de ML en conditions réelles avant son déploiement.

Alors que les tests se concentrent sur l’évaluation de la qualité, la surveillance du modèle vise à garantir qu’un modèle entraîné et l’écosystème qui l’entoure se comportent comme prévu après le déploiement. La surveillance, qui peut être mise en œuvre en continu ou selon un calendrier prédéfini, observe les entrées, les sorties et le comportement opérationnel d’un modèle en production, afin que les équipes de gestion des risques puissent détecter les changements avant qu’ils ne se transforment en régressions à part entière, voire en défaillances.

La surveillance offre aux entreprises un système d’alerte précoce en cas de comportement problématique du modèle, mais elle ne remplace pas la validation. La validation des modèles est un processus d’évaluation itératif qui intervient généralement pendant que les équipes de développement construisent un modèle, mais celles-ci peuvent également valider les modèles dans le cadre d’un processus indépendant avant leur validation et périodiquement par la suite.

Bien que la validation, les tests et la surveillance soient des processus distincts, les entreprises ont généralement besoin de ces trois éléments pour optimiser les performances et la fiabilité des modèles de ML tout au long de leur cycle de vie.

L’IA générative et les agents d’IA nécessitent les mêmes pratiques de validation fondamentales que les autres systèmes de ML. Cependant, ces outils peuvent engendrer des risques que la validation des modèles prédictifs ne peut pas entièrement prendre en compte. Les systèmes d’IA générative produisent des résultats ouverts, et les agents peuvent exploiter ces résultats pour planifier et exécuter des actions au sein de systèmes interconnectés.

Avec le ML standard, le résultat d’un modèle peut souvent être évalué directement par rapport à une étiquette de référence. Si un modèle de détection de fraude prédit une « fraude » pour une transaction et qu’une enquête ultérieure confirme la fraude, la prédiction était correcte. Si un modèle de prévision de la demande prévoit 1 150 unités et que la demande réelle s’élève à 1 600, les équipes peuvent utiliser l’erreur quadratique moyenne (un indicateur de régression qui évalue dans quelle mesure les prédictions du modèle se rapprochent des valeurs réelles) pour mesurer précisément l’écart.

Les résultats de l’IA générative ne se traduisent généralement pas par une formulation correcte unique et peuvent ne pas avoir une seule « bonne réponse » complète. Certaines tâches contraintes (extraction structurée, sélection d’outils) peuvent néanmoins être évaluées par rapport à des résultats attendus explicites. Mais d’une manière générale, le comportement d’un modèle dépend fortement du contexte d’exécution, qui peut varier d’une interaction à l’autre. L’IA générative peut également halluciner, c’est-à-dire présenter avec assurance des informations fausses ou erronées en réponse à un prompt.

Par conséquent, la validation de l’IA générative exige que les équipes utilisent un jeu d’évaluation contenant des prompts réalistes, des sources approuvées, des éléments de réponse attendus et des grilles d’évaluation. Ces dernières permettent au modèle de générer plusieurs réponses acceptables tout en exigeant que chaque réponse contienne certains faits, évite les affirmations non étayées et signale l’incertitude lorsqu’elle existe.

Les agents d’IA peuvent élaborer des plans, accorder des accès, modifier des enregistrements, envoyer des messages et lancer des workflows entièrement nouveaux (avec de nouveaux agents). À ce titre, les agents d’IA nécessitent les mêmes contrôles axés sur les résultats que l’IA générative, mais ils exigent également que les développeurs valident les décisions et les actions qui découlent de ces résultats. Tout changement significatif tel qu’une modification du modèle de fondation de l’agent ou une nouvelle connexion à un référentiel de récupération doit déclencher une nouvelle validation.