Valider un modèle d’IA dont on ne peut pas ouvrir la boîte

Ce qu’est la validation, et ce qui change pour l’IA#

La validation d’un modèle est l’appréciation indépendante de son adéquation à l’usage prévu, menée par quelqu’un d’autre que son constructeur et doté de l’autorité de refuser l’approbation. Cette définition ne change pas pour l’intelligence artificielle.

Ce qui change, c’est la preuve disponible : sur un modèle classique, un validateur peut lire la spécification, réestimer les paramètres et reproduire le résultat ; sur beaucoup de systèmes d’IA, la relation apprise n’est pas véritablement lisible, et sur un système acheté, les rouages peuvent n’être pas accessibles du tout.

La validation passe donc de l’inspection du mécanisme à l’interrogation du comportement — plus difficile à bien faire, et bien plus facile à mal faire.

Le test sur échantillon retenu et ses compromissions#

Le socle de la validation comportementale est le test sur échantillon retenu : une performance mesurée sur des données que le modèle n’a jamais vues à l’entraînement et, idéalement, que le développeur n’a jamais vues non plus. On le répète si souvent qu’il vaut la peine de nommer les manières dont on le compromet discrètement.

• La fuite d’information, lorsqu’un champ disponible au moment du scoring encode le résultat, produit des tests spectaculaires et aucune valeur en production.
• La fuite temporelle, lorsque l’échantillon de test est tiré aléatoirement sur une période plutôt que sur une période postérieure aux données d’entraînement, flatte tout modèle opérant dans un environnement changeant.
• le réglage répété contre un même échantillon de test le transforme progressivement en second échantillon d’entraînement.

Un validateur qui accepte un chiffre de performance sans établir comment l’échantillon a été construit n’a rien validé.

Là où le modèle se trompe compte plus que la fréquence#

L’exactitude agrégée est le chiffre le moins informatif du rapport. Ce qui compte, c’est de savoir où le modèle se trompe, car les erreurs ne sont presque jamais uniformément réparties : un système peut bien fonctionner globalement et mal sur un segment, un produit, un canal, une langue ou une période — et le segment où il échoue est souvent celui qui comptait le moins d’exemples d’entraînement et porte les plus lourdes conséquences.

Une validation utile décompose donc la performance selon toutes les dimensions sur lesquelles l’établissement prend des risques différents, et prête une attention particulière aux queues : cas aux extrémités de la plage d’intrants, soumissions atypiques, clients qui ne ressemblent pas à la population d’entraînement.

Le référentiel que l’établissement comprend réellement#

Un référentiel que l’établissement comprend réellement est l’outil de validation le plus sous-utilisé. Comparer le système d’IA à une alternative simple et transparente — un modèle logistique, une grille de score, un petit jeu de règles métier, ou le processus humain qu’il remplacerait — répond à deux questions à la fois : le surcroît de complexité achète-t-il assez de performance pour justifier son coût de gouvernance, et le système se comporte-t-il sensément ?

Un modèle qui écrase le référentiel mérite un examen de ses données plutôt qu’une célébration, car ce profil signale généralement une fuite.

Un modèle qui ne le dépasse que de peu a, en environnement régulé, plaidé pour l’option la plus simple.

La robustesse : ce qui se passe aux bords#

Les tests de robustesse interrogent les bords, là où vit la production et où les échantillons de test se rendent rarement. Il s’agit de soumettre au système des intrants incomplets, mal formés, anormalement longs, dans une langue ou un format inattendus, construits de façon adverse, ou simplement hors de la plage d’entraînement, puis d’observer non seulement si la réponse est fausse, mais si le système sait qu’il est incertain.

Un modèle qui produit un résultat assuré sur du non-sens est plus dangereux qu’un modèle qui échoue visiblement, car l’humain en aval ne dispose d’aucun signal pour s’en méfier.

Savoir si un système se dégrade gracieusement — signalement d’une faible confiance, routage vers un humain, refus de répondre — est une propriété de conception qui doit être testée et non supposée.

Tester les écarts de traitement#

Lorsque les résultats affectent des personnes, tester les écarts de traitement fait partie de la validation et non d’un exercice d’éthique parallèle. Le mécanisme à rechercher est l’encodage indirect : un modèle entraîné sans caractéristique protégée peut néanmoins la reconstituer via des variables corrélées — localisation, historique produit, terminal, canal — et le fera d’autant plus volontiers qu’il est flexible.

Un test pratique compare les taux de résultats et d’erreurs entre les groupes que l’établissement peut légalement mesurer, examine si les erreurs pèsent de façon disproportionnée sur l’un d’eux, et demande si un écart observé repose sur une justification métier légitime et documentée.

Ce travail est difficile lorsque l’établissement ne détient pas les attributs pertinents, et la réponse honnête à cette difficulté est de le consigner dans le rapport de validation plutôt que de porter la question comme sans objet.

Les systèmes tiers : décider avant d’acheter#

Les systèmes tiers exigent que la stratégie de validation soit arrêtée avant l’achat, car après l’achat l’établissement n’a plus de levier et conserve la même responsabilité.

Ce qu’il est raisonnable d’exiger au contrat — et que les fournisseurs servant des acheteurs régulés s’attendent de plus en plus à fournir — comprend :

• la documentation de l’usage prévu et des limites connues
• la preuve des tests effectués et de la population concernée
• un droit de tester indépendamment sur ses propres données
• un préavis avant toute modification ou réentraînement du modèle
• un accès aux journaux suffisant pour reconstituer une décision passée
• une sortie qui ne bloque pas un processus en production

Un établissement qui ne parvient pas à obtenir un droit de test indépendant devrait traiter ce refus comme un constat sur le fournisseur plutôt que comme une contrainte à contourner.

La validation ne s’arrête pas à l’approbation#

La validation ne s’arrête pas à l’approbation, et pour l’IA la partie continue pèse davantage que l’exercice initial. Un modèle juste le jour de son approbation peut devenir faux sans qu’aucun code ne change, parce que la population qu’il note a évolué, qu’un mix de canaux s’est déplacé, qu’un produit a été retarifé ou que le comportement appris appartenait à des conditions révolues.

La surveillance qui le détecte compare les réalisations aux prédictions plutôt que de confirmer seulement la disponibilité du service, observe la distribution des intrants pour déceler une dérive par rapport à la population de développement, et porte des seuils convenus à l’avance à partir desquels le modèle est réentraîné, restreint ou retiré.

Ces seuils doivent être fixés avant d’être approchés, car la décision de continuer à exploiter un modèle qui se dégrade sous pression commerciale est la défaillance la plus prévisible du domaine.

Quand la bonne réponse est une restriction#

Parfois, la bonne conclusion de validation n’est ni l’approbation ni le rejet mais la restriction — et les dispositifs n’offrant que deux verdicts poussent les validateurs à approuver ce qui les met mal à l’aise.

Un système qui ne peut être validé à la profondeur qu’exige son niveau de risque peut souvent servir à quelque chose :

• comme intrant de classement plutôt que comme décision
• sur un segment plus étroit où les preuves sont suffisantes
• avec une revue humaine obligatoire
• à un seuil d’automatisation plus bas
• sous surveillance renforcée pendant une période définie

Consigner la restriction, son motif et la condition de sa levée vaut mieux qu’une approbation qui surestime les preuves ou qu’un rejet qui verra le même système revenir par une autre porte six mois plus tard.