Qu'est-ce qui compte comme preuve quand la machine est probabiliste ?
La probabilité n’est pas un verdict
Lorsqu’une machine renvoie 0,87, la première question est généralement trop étroite. On se demande si 0,87 est élevé. Élevé par rapport à quoi, pour quel résultat, sur quels cas, et pour quelle décision ? Un nombre affiché à côté d’un résultat ressemble à une propriété de ce résultat. Souvent, ce n’en est pas une. C’est une tentative de décrire une relation entre un modèle, une population définie de cas et un résultat observé au fil du temps. Cette relation peut être utile. Elle peut orienter une file d’examen, fixer un seuil ou signaler à un opérateur qu’un résultat mérite un second regard. Mais elle ne transforme pas une prédiction individuelle en un fait assorti d’une décimale.
C’est le point délicat au cœur des systèmes probabilistes. Leurs résultats sont souvent plus informatifs qu’une simple étiquette, car ils peuvent exprimer des degrés de soutien ou d’incertitude. Ils sont aussi plus faciles à surinterpréter. Un score peut être traité comme une déclaration de témoin, une conclusion juridique, un diagnostic ou un feu vert. Par défaut, il n’est rien de tout cela. La preuve commence lorsque l’organisation peut dire ce que le nombre représente, comment il a été vérifié, où cette vérification s’applique et quelle action le nombre est autorisé à modifier.
Cette distinction compte bien avant qu’un système ne rencontre un régulateur. Une équipe peut décider si un document suggéré nécessite une vérification humaine. Un acheteur peut comparer deux fournisseurs qui annoncent tous deux des mesures de confiance. Un opérateur peut définir une règle d’escalade. Un organisme public peut se demander si une liste classée est assez fiable pour influencer l’ordre des priorités. Dans chaque cas, une exécution réussie prouve une seule chose : cette exécution a produit un résultat. Ce n’est pas encore une preuve que le système mérite l’autorité qu’on lui attribue.
La réponse sensée n’est pas d’interdire les probabilités dans les travaux à enjeux. C’est de leur donner une véritable fiche de poste. Une probabilité peut appuyer une décision lorsqu’elle est liée à un événement défini, à une population pertinente, à une méthode d’observation, à une limite d’incertitude et à une règle pour ce qui se passe lorsque les preuves sont faibles. C’est plus lent que d’admirer un seul nombre et bien plus rapide que de découvrir plus tard que personne ne peut expliquer ce que le nombre était censé faire.
La preuve doit nommer sa question
La preuve n’est jamais simplement présente. Elle est une preuve en faveur d’une proposition. Un résultat de test peut appuyer la proposition selon laquelle un composant produit une sortie particulière pour une entrée particulière dans une configuration particulière. Il peut appuyer la proposition selon laquelle un modèle classe bien les exemples sur un ensemble de données réservé. Il peut appuyer la proposition selon laquelle une estimation de probabilité correspond raisonnablement aux fréquences observées dans un ensemble d’évaluation défini. Ces propositions sont différentes. La discipline commence par écrire la proposition avant de choisir la métrique.
Considérons l’affirmation apparemment simple selon laquelle un système est précis. Précis à quel égard ? Une précision de classification peut décrire la fréquence à laquelle la classe ayant obtenu le score le plus élevé correspondait à une étiquette. Elle ne dit pas si la probabilité indiquée était bien calibrée. Une métrique de classement peut décrire l’ordre, et non la qualité de l’échelle de scores. Une erreur moyenne faible peut coexister avec un schéma d’erreur préjudiciable dans un sous-groupe ou à un seuil qui déclenche une action. La métrique n’est pas fausse. C’est le passage de la métrique à la conclusion opérationnelle qui pose généralement problème.
Les travaux de l’OCDE sur les instruments d’évaluation sont utiles précisément parce qu’ils renoncent au fantasme selon lequel un seul score pourrait porter l’ensemble de l’explication. Leur cadre distingue des facettes, notamment la couverture, la finalité, le réalisme, la fiabilité, la reproductibilité, l’objectivité et la partialité. Ce ne sont pas des ornements bureaucratiques autour d’un point de référence. Elles décrivent si le résultat entretient la bonne relation avec la question posée. Une comparaison de recherche, une évaluation de la conformité et une décision de mise en service opérationnelle peuvent toutes recourir à des tests. Elles n’attendent pas la même chose de ces tests.
Commencez donc par une phrase avec laquelle on peut être en désaccord. Par exemple : ce système peut orienter des cas vers un examen humain lorsque son estimation de probabilité documentée pour un résultat défini dépasse un seuil précis, à condition que l’entrée corresponde au périmètre validé et que l’examinateur conserve le pouvoir de rejeter la suggestion. C’est une proposition opérationnelle discutable. Elle nomme l’action, la condition et la limite. Elle ne prétend pas qu’un score a choisi de lui-même son rôle dans le monde.
La phrase contraire est familière parce qu’elle est commode : le modèle est confiant à 87 pour cent. Même lorsqu’un modèle émet réellement une probabilité, la phrase laisse de côté l’événement, les preuves de calibration, la population, la période et la décision. Elle transforme une relation en trait de personnalité. Les machines n’ont pas besoin d’être décrites comme timides ou certaines. Elles doivent être décrites comme des systèmes dont les sorties ont des significations et des limites définies.
La confiance n’est pas la même chose que l’exactitude
Un système peut être confiant et se tromper. Il peut aussi être exact tout en exprimant une faible confiance. Ces deux faits ne surprennent plus une fois les termes maintenus distincts. L’exactitude demande si un résultat correspond à la référence choisie pour un cas donné. La confiance est une déclaration attachée à une sortie, souvent dérivée d’un score de modèle ou d’une transformation de celui-ci. La calibration pose une question supplémentaire sur de nombreux cas : lorsque le système attribue des probabilités similaires, les résultats se produisent-ils à peu près au taux indiqué ? Ce sont des questions liées, mais une bonne réponse à l’une ne fournit pas les autres.
Imaginons un ensemble de cas pour lesquels un classifieur rapporte une probabilité de 0,80 pour un événement défini. Si, sur un ensemble de cas comparables, décrit de manière adéquate et suffisamment vaste, l’événement se produit environ huit fois sur dix, l’estimation peut être considérée comme bien calibrée pour cette population et cette condition. Cela ne signifie pas que le prochain cas à 0,80 a un destin de quatre-vingts pour cent. Cela signifie que le score a montré une relation avec les résultats observés dans l’ensemble indiqué. L’expression dans l’ensemble indiqué fait l’essentiel du travail intellectuel.
L’étalonnage n’est pas non plus un badge universel. Un score peut être bien étalonné sur un jeu de données historique et mal étalonné après un changement de source d’entrée, de population d’utilisateurs, de flux de travail, de processus d’étiquetage ou de conditions de déploiement. Il peut être bien étalonné dans l’ensemble tout en se comportant différemment au sein d’une partie de la population qui compte pour le service. Il peut sembler correct dans une catégorie large tout en masquant une différence marquée près du seuil de décision. Un graphique d’étalonnage n’est pas un diplôme encadré au-dessus du système de production. C’est une observation datée avec un périmètre.
La littérature sur l’étalonnage des modèles rend la distinction concrète. Guo et ses collègues ont étudié l’étalonnage de la confiance dans les réseaux de neurones modernes et ont montré que la précision seule ne permet pas de déterminer si les estimations de confiance correspondent aux probabilités de correction observées. Leurs travaux évaluent également des méthodes d’étalonnage post-traitement. La leçon opérationnelle importante est plus étroite qu’une recette : il ne faut pas supposer qu’un score de modèle a une signification probabiliste appropriée simplement parce qu’il est fourni dans une plage pratique entre zéro et un.
Une organisation rigoureuse enregistre donc trois choses distinctes. Elle enregistre la performance de la tâche, afin de pouvoir se demander si les sorties répondent à la tâche définie. Elle enregistre l’étalonnage ou une autre propriété d’incertitude explicite, afin de pouvoir se demander ce que le score signifie en pratique. Et elle enregistre la conséquence d’agir à un seuil donné, afin de pouvoir se demander si la règle de décision est appropriée. Combiner les trois en un seul indicateur vert peut simplifier un tableau de bord. Cela ne simplifie pas le monde.
L’étalonnage a un dénominateur
Toute affirmation sur l’étalonnage a un dénominateur. Le dénominateur n’est pas simplement le nombre d’enregistrements dans un fichier. C’est l’ensemble des cas qui étaient admissibles au comptage, la manière dont ils ont été regroupés, la définition du résultat, la période, les exclusions et le processus qui a produit les étiquettes de référence. Retirez ces conditions et un diagramme de fiabilité devient une courbe agréable sans autorité sur une décision.
Supposons qu’une évaluation regroupe les prédictions selon la confiance déclarée. Le taux observé dans chaque groupe dépend des cas admis dans le groupe et de la définition du résultat. Les cas ambigus ont-ils été exclus ? Les abstentions ont-elles été traitées comme des erreurs, des refus sûrs ou autre chose ? L’étiquette représentait-elle un événement immédiat, un examen ultérieur ou un appel final ? Les doublons ont-ils été conservés ? L’évaluation n’a-t-elle inclus que les enregistrements ayant franchi une étape de validation en amont ? Chaque réponse peut être raisonnable. Chaque réponse change ce que l’affirmation d’étalonnage qui en résulte signifie.
C’est pourquoi un modèle peut avoir un résultat d’étalonnage global respectable et être néanmoins inadapté à un usage spécifique. Le résultat global peut regrouper des langues, des longueurs d’entrée, des régions, des types d’appareils, des parcours clients ou des modes de fonctionnement qui ne partagent pas la même structure d’erreur. Un chiffre agrégé peut être un résumé honnête et rester une preuve insuffisante pour une décision locale. La bonne réponse n’est pas d’exiger un modèle distinct pour chaque personne. C’est de tester les hypothèses de regroupement que la décision elle-même rend pertinentes.
Le cadre d’évaluation de l’OCDE appelle cela la couverture. Le cadre demande si un instrument d’évaluation couvre une distribution biaisée ou représentative de ce qu’il est censé mesurer, et il distingue la performance de la tâche d’une affirmation de capacité plus large. Ces distinctions sont utiles pour les preuves probabilistes. Un score peut être une preuve de performance sur une distribution de tâches. Il ne devrait pas devenir silencieusement une preuve de capacité, de population affectée ou de contexte futur que l’évaluation n’a pas couvert.
Le dénominateur a aussi un versant social. Lorsqu’une organisation décide quels cas sont assez simples pour être automatisés et lesquels doivent attendre une personne, les définitions déterminent qui porte l’incertitude restante. Un score agrégé peut masquer le fait qu’un groupe plus restreint compte moins d’exemples, des étiquettes moins stables ou un contexte d’exploitation différent. Ce n’est pas une raison pour promettre des statistiques équivalentes là où les preuves sont minces. C’est une raison pour signaler clairement ces preuves minces et pour établir autour d’elles une règle de décision prudente.
Une exécution réussie est un échantillon, pas une conclusion
Les systèmes probabilistes invitent à une forme particulière d’excès de confiance parce qu’ils sont si faciles à démontrer. On saisit une entrée, on obtient un résultat impressionnant, on recommence avec une entrée proche, on en obtient un autre. La démonstration peut montrer que le système est capable d’accomplir la tâche. Elle peut même révéler quelque chose qui mérite d’être étudié. Elle ne peut pas montrer la distribution des résultats, la stabilité du score, la réponse aux cas limites, la qualité des étiquettes de référence ni l’effet d’un changement dans les conditions de déploiement. Un échantillon peut amorcer une enquête. Il ne peut pas la conclure.
Il en va de même pour une exécution unique de référence. Un résultat peut avoir été recueilli correctement, sur un système bien décrit, avec une métrique légitime. S’il n’a été exécuté qu’une fois, il témoigne de la valeur observée une seule fois dans ces conditions. Il ne prouve pas automatiquement une propriété stable du système. La répétition aide à faire ressortir la variation. Elle ne supprime pas la nécessité de se demander si le test représente l’usage prévu. La reproductibilité et la validité résolvent des problèmes différents, et les deux méritent une place dans le compte rendu.
Le cadre de l’OCDE rend cette distinction explicite. La fiabilité concerne la question de savoir si une évaluation présente suffisamment de répétitions, une longueur d’épisode ou un nombre d’instances suffisants pour donner une faible variation lorsqu’elle est appliquée de nouveau. La reproductibilité concerne la question de savoir si le même test peut être généré de nouveau, y compris si les composantes stochastiques modifient les interactions. Un test peut être exactement reproductible et répondre tout de même à une question inutile. Il peut être réaliste et difficile à reproduire exactement parce que l’environnement a changé. Aucune de ces conditions n’est un défaut en soi. Le compte rendu doit indiquer laquelle s’applique et ce qu’elle permet au lecteur d’inférer.
Il y a ici une habitude opérationnelle modeste mais précieuse : conserver l’exécution réussie, sans lui faire porter plus qu’elle ne le peut. Préserver l’entrée, la configuration, la version, la graine le cas échéant, les dépendances, la sortie et la décision d’évaluation. Puis la placer à côté des mesures répétées, des contre-exemples, des abstentions et des conditions modifiées. Un résultat qui reste utile après avoir rencontré ses voisins gênants vaut plus qu’un résultat qu’il a fallu protéger d’eux.
Pour les systèmes génératifs, une réponse réussie est une preuve particulièrement faible de répétabilité, à moins que le contrat d’interaction ne soit consigné. Les paramètres d’échantillonnage, les invites, le matériel récupéré, la disponibilité des outils, la version du modèle, la politique de sécurité et le flux de travail environnant peuvent tous façonner le résultat. Rejouer une suite de mots sans l’état pertinent peut reproduire l’apparence d’un test tout en manquant la condition qui le rendait significatif. Dans le travail sur les preuves, la ressemblance n’est pas la relecture.
La répétabilité n’est pas un synonyme de confiance
Une relecture déterministe peut être une excellente preuve pour une proposition étroite : étant donné les mêmes entrées, la même configuration et les mêmes conditions de mise en œuvre consignées, le système a produit le même résultat. Cela rend les enquêtes, les tests de régression et les comparaisons de versions plus faciles à mener. Cela n’établit pas que le résultat était correct, que l’entrée était appropriée, que le système aurait dû être utilisé pour la décision, ni que le résultat se généralisera au-delà de sa limite consignée. La répétabilité est une propriété de l’expérience. La confiance est un jugement sur un arrangement plus large.
Un comportement stochastique modifie l'enregistrement plutôt que d'excuser son absence. Si une sortie varie, l'évaluation doit consigner quelles parties varient, à quelle fréquence, dans quelle plage, et comment cette variation affecte la décision. Un système qui propose des formulations alternatives peut tolérer une plage plus large qu'un système qui classe des cas pour attirer l'attention. Un système qui conseille un humain peut exiger des preuves différentes de celles d'un système qui rend disponible une action irréversible. La probabilité n'est pas une catégorie opérationnelle en soi. C'est la conséquence qui détermine la quantité d'incertitude qu'un processus peut supporter en toute sécurité.
Il existe une erreur facile des deux côtés. Une équipe exige une sortie fixe d'un outil dont l'objectif déclaré inclut l'exploration, puis confond le déterminisme qui en résulte avec la qualité. Une autre équipe accepte une sortie variable d'un système d'aide à la décision, puis qualifie la variabilité de créative lorsqu'elle devient difficile à évaluer. Aucune des deux positions n'est sérieuse. La question est de savoir si la variation est attendue, bornée, observable et compatible avec l'autorité assignée au système.
La réglementation européenne ne réduit pas cette question à un score universel unique. Pour les systèmes d'IA à haut risque, l'article 15 de l'AI Act exige un niveau approprié de précision, de robustesse et de cybersécurité, ainsi qu'une performance constante à ces égards tout au long du cycle de vie. Il précise également que les niveaux de précision et les mesures de précision pertinentes doivent être indiqués dans les instructions d'utilisation, et encourage des références et des méthodes de mesure pour les aspects techniques de l'évaluation de la performance. La disposition ne dit pas qu'un seul test répété règle la question. Elle demande que la performance soit spécifiée et maintenue en contexte.
C'est la posture raisonnable pour toute évaluation sérieuse. Un test reproductible est un maillon de la chaîne de preuves. Il lui faut un propriétaire, une limite de version, un déclencheur de changement et un lien avec la décision opérationnelle qu'il soutient. Sans cela, la reproductibilité peut devenir un autre mot attrayant qui voyage plus loin que l'expérience.
L'incertitude a besoin d'une voie opérationnelle
Le but pratique de l'incertitude n'est pas de rendre un tableau de bord plus sophistiqué. Il est de modifier ce que le système est autorisé à faire. Si un score n'a aucun effet sur l'acheminement, l'examen, l'explication, la surveillance ou l'arrêt, il peut s'agir d'une curiosité technique plutôt que d'un signal opérationnel. S'il modifie une action, l'organisation doit énoncer le chemin allant du score à l'autorité.
Un seuil est une telle voie, mais ce n'est pas une ligne magique. Fixer un seuil revient à choisir un compromis entre les types d'erreurs, la charge de travail, le délai et le préjudice potentiel. Un seuil peut être approprié pour prioriser une file d'examen à faible enjeu et inapproprié pour refuser à une personne l'accès à un service. Le même seuil numérique peut signifier des choses différentes lorsque le taux de base, le coût de l'erreur, les recours disponibles et la qualité de l'examen en aval changent. Il n'existe pas de nombre prudent universel attendant dans un manuel de fournisseur.
Pour cette raison, une règle de décision devrait décrire plus qu'un seuil. Elle devrait nommer le résultat estimé, les preuves qui soutiennent le score, les cas hors du champ d'application, les circonstances qui imposent l'abstention, l'autorité humaine qui demeure, l'enregistrement qui sera conservé et les conditions de révision de la règle. Un seuil sans ces compagnons est une décision déguisée en configuration.
Une hypothèse utile illustre le propos sans inventer un incident public. Considérons un service qui utilise un score de modèle pour trier les demandes entrantes destinées à un examinateur formé. Les preuves pourraient soutenir une affirmation limitée : le score peut aider à ordonner des demandes comparables dans une catégorie d'admission définie, tandis que toute priorisation finale reste à l'examinateur. Les mêmes preuves ne soutiennent pas le rejet automatique des demandes à faible score, car il s'agit d'une action différente avec des conséquences différentes et des besoins de preuves différents. La sortie n'a pas changé. Son autorité, si.
L’abstention mérite la même rigueur. Un système capable de dire que ses éléments de preuve sont insuffisants peut générer davantage de travail à court terme et réduire les erreurs non observées à long terme. Mais l’abstention n’est utile que si elle a une destination responsable. Si les cas incertains disparaissent dans une file d’attente sans propriétaire, le système n’a fait que convertir l’incertitude en délai. Un bon circuit précise qui reçoit le cas, ce qu’il peut voir, comment il le corrige et comment cette correction éclaire les évaluations ultérieures.
Les affirmations causales exigent plus qu’un graphique avant-après
Les estimations de probabilité servent souvent à étayer des affirmations sur ce qui se produira si une organisation agit. C’est une tâche probatoire différente de celle qui consiste à prédire ce qui s’est passé dans des données historiques. Un modèle peut estimer qu’un cas ressemble à d’autres cas ayant un certain résultat. Il ne démontre pas pour autant que modifier le cas, changer une politique ou suivre une recommandation entraînera une modification du résultat. La prédiction et l’intervention ne doivent pas être confondues simplement parce que le graphique paraît net.
Les figures avant-après sont particulièrement tentantes. Une équipe introduit un outil, un résultat change, et l’outil reçoit le crédit ou le blâme. Bien d’autres choses ont pu changer : la population entrant dans le service, la documentation, les effectifs, les politiques, les conditions saisonnières, les filtres en amont ou la mesure elle-même. L’observation peut mériter l’attention. Elle ne constitue pas une conclusion causale tant que la comparaison, les explications alternatives et l’incertitude restante n’ont pas été traitées.
Cela importe pour la gouvernance de l’IA, car un système peut avoir une influence opérationnelle bien avant d’être formellement décisif. Un classement peut changer quel dossier une personne ouvre en premier. Un indicateur de confiance peut inciter un examinateur à accepter un résultat. Une action recommandée peut devenir routinière parce que la file d’attente est chargée. Le chemin causal inclut l’interprétation humaine, la conception de l’interface, les incitations, la pression temporelle et le circuit de correction disponible. Évaluer le modèle seul ne peut pas raconter toute l’histoire.
Lorsqu’une affirmation causale importe, le plan de collecte de preuves devrait préciser quelle comparaison rendrait l’affirmation plus crédible et ce qu’elle ne pourrait toujours pas exclure. Cela peut impliquer un test contrôlé, un déploiement progressif, un examen indépendant, une conception observationnelle soigneusement élaborée, ou la décision de s’abstenir entièrement d’une affirmation causale. Il ne s’agit pas d’exiger la perfection académique pour chaque changement opérationnel. Il s’agit de faire correspondre la confiance de l’affirmation aux éléments de preuve réellement disponibles.
Il y a là une forme de bon sens à la néerlandaise, qui voyage bien : si vous avez seulement mesuré que le vent a changé, n’annoncez pas que vous avez redessiné la météo. Une prédiction peut avoir de la valeur sans devenir une histoire de causalité. L’honnêteté n’est pas un repli. C’est ce qui rend le résultat utilisable par quelqu’un qui doit décider quoi faire ensuite.
L’exactitude peut masquer une mauvaise règle de décision
L’exactitude est souvent utile et souvent insuffisante. Un système peut atteindre une exactitude élevée lorsqu’un résultat est fréquent, tout en offrant peu d’aide sur les cas qui comptent le plus. Il peut avoir une moyenne solide tout en performant mal près de la frontière d’action. Il peut faire des prédictions correctes sans offrir d’estimations de probabilité qui soutiennent des seuils sensés. Il peut sembler réussi parce que l’étiquette de référence est facile à prédire, même si cette étiquette est elle-même un proxy faible pour la décision que le service doit prendre.
Rien de tout cela ne signifie que l'exactitude n'a pas de sens. Cela signifie que le lecteur doit se demander ce qu'elle mesure et ce qu'elle laisse hors du cadre. L'AI Act reconnaît ce besoin de contexte dans ses exigences relatives aux notices d'utilisation : la documentation des systèmes à haut risque doit inclure les caractéristiques et les limites de performance, la finalité prévue, les mesures d'exactitude pertinentes utilisées pour tester et valider le système, ainsi que les circonstances connues ou raisonnablement prévisibles susceptibles d'affecter les performances attendues. Un chiffre d'exactitude devient plus utile lorsque les conditions qui l'entourent restent attachées.
Un bon examen opérationnel s'intéresse donc aux schémas d'erreur, et pas seulement aux totaux. Quels types de cas ont été mal classés ? Lesquels étaient incertains ? Quels cas ont été exclus ou envoyés pour examen ? Qu'advient-il d'un faux positif, d'un faux négatif, d'une réponse retardée ou d'une abstention injustifiée ? Qui peut détecter le résultat, le contester et corriger l'enregistrement ? Ces questions ramènent l'évaluation au service plutôt que de la laisser au modèle.
Il peut également être utile de distinguer les preuves d'un composant de celles d'un flux de travail. Un test de composant peut établir les propriétés d'un modèle dans des conditions d'entrée définies. Une évaluation de flux de travail peut établir comment le modèle, l'interface, les données, les personnes et les politiques interagissent. Un composant peut avoir un excellent calibrage des scores tandis que le flux de travail produit un biais d'automatisation parce que l'interface masque l'incertitude. Un flux de travail peut avoir un excellent processus d'examen tout en s'appuyant sur un composant dont les données sources ne correspondent plus au champ d'application déclaré. Les tests doivent se rencontrer quelque part.
Les preuves qui en résultent ne constituent pas nécessairement un rapport grandiose. Elles peuvent prendre la forme d'un enregistrement concis et versionné si la décision est étroite. Ce qui importe, c'est qu'une autre personne puisse examiner la proposition, la population, la méthode, le résultat, la limite et la décision. La taille du fichier ne détermine pas la qualité du raisonnement. Un enregistrement court peut être rigoureux. Une grande présentation peut être surtout vide.
Le changement transforme les preuves d'hier en une question
Chaque résultat d'évaluation a une date, même lorsque la date est masquée. Les modèles changent. Les invites changent. Les sources de données changent. Un formulaire en amont gagne un champ. Un fournisseur modifie une politique. Une équipe déplace un service vers un autre environnement. Un nouveau groupe commence à utiliser le système. Une mesure est calculée après un processus d'examen modifié. Chaque changement peut altérer la proposition que les preuves précédentes soutenaient.
La bonne réponse n'est pas de relancer tous les tests après chaque modification. Elle consiste à définir quels changements sont importants pour quelles affirmations. Un changement de couleur peut ne pas affecter le calibrage des probabilités. Un nouveau canal d'entrée peut le faire. Une politique d'étiquetage révisée peut modifier la définition du résultat. Une nouvelle version du modèle peut changer à la fois les performances et l'interprétation de ses scores. Un changement dans l'autorité accordée au système peut invalider une règle de décision même si le modèle reste identique octet pour octet. Le plan de test doit rendre ces relations visibles avant qu'une version ne soit pratique.
L'article 9 de l'AI Act décrit un processus continu et itératif de gestion des risques pour les systèmes à haut risque tout au long de leur cycle de vie. Le processus comprend l'identification et l'analyse des risques connus et raisonnablement prévisibles, l'estimation et l'évaluation des risques lorsque le système est utilisé conformément à sa finalité prévue et dans des conditions de mauvaise utilisation raisonnablement prévisible, et l'adoption de mesures de gestion des risques. Le point est direct pour l'évaluation : les preuves ne sont pas une cérémonie unique au lancement. Elles appartiennent à un système d'exploitation d'examen, de changement et de réponse.
Surveiller ne signifie pas collecter tous les signaux disponibles en espérant qu’un schéma se révèle de lui-même. Cela signifie décider quelle observation permettrait de rouvrir une réclamation. Un contrôle d’étalonnage peut être planifié selon la période, le volume ou la modification de la composition des intrants. Un seuil peut être réexaminé lorsque la pression sur la file d’attente altère la qualité de la supervision humaine. Un changement de source peut suspendre une utilisation jusqu’à ce que le test concerné soit répété. Un plan de surveillance sérieux précise ce qui est observé, par qui, par rapport à quelle référence, et quelle action en découle.
C’est plus exigeant qu’une fiche de modèle archivée le jour de l’acquisition, mais c’est aussi plus utile. Un document statique peut préserver ce qui a été affirmé. Un registre de preuves vivant peut montrer si l’affirmation a toujours sa place. Pour un système probabiliste, cette différence est celle qui existe entre savoir que le score a existé et savoir s’il signifie encore ce que le service pense qu’il signifie.
Les registres permettent à un lecteur ultérieur de contester à bon escient
Les preuves ont besoin de mémoire. Un examinateur ultérieur ne peut pas évaluer une affirmation à partir d’une capture d’écran d’un score et d’un souvenir de la réunion. Il lui faut l’objet versionné : la question, les conditions d’entrée, la méthode de test ou d’observation, le résultat, les exclusions, l’incertitude, la décision et le responsable. Il peut aussi avoir besoin de savoir ce qui n’a pas été capturé. Un registre qui rend ses angles morts visibles est plus utile qu’un registre d’apparence parfaite qui laisse l’état du système à la spéculation.
Pour les systèmes d’IA à haut risque, le règlement sur l’IA exige l’enregistrement automatique des événements pendant toute la durée de vie du système, avec des capacités de journalisation adaptées à l’usage prévu et utiles pour identifier les risques, soutenir la surveillance après la mise sur le marché et surveiller le fonctionnement. Il exige également que la documentation technique soit établie avant la mise sur le marché du système et tenue à jour. Ces exigences ne sont pas simplement une invitation à conserver davantage de journaux. Elles sont une invitation à rendre les journaux intelligibles par rapport à un système, à un objectif et à une décision.
La traçabilité est particulièrement importante lorsque la probabilité est interprétée par une personne. Si un examinateur voit un score, le registre de preuves doit permettre de reconstituer à quoi ce score était rattaché, comment il a été présenté, quelles données ou sources étaient dans le périmètre, ce que l’examinateur a décidé, et si une correction ultérieure a eu lieu. Sans cette chaîne, une équipe peut apprendre qu’un résultat était erroné, mais pas si le problème venait des intrants, du modèle, de l’interface, de la règle de décision ou du processus humain qui l’entoure.
Chez Dweve, AION est un exemple restreint et pertinent du principe plus large, et non une affirmation selon laquelle les preuves peuvent être réduites à la cryptographie. Sa description publique indique qu’un producteur peut émettre un certificat typé accompagnant un résultat, et qu’AION vérifie le certificat de manière indépendante par rapport aux prémisses d’origine. Ce type de registre vérifiable peut renforcer une proposition étroite selon laquelle un résultat découle de prémisses enregistrées. Il ne prouve pas que les prémisses étaient appropriées, que la tâche était juste ou que l’utilisation était adaptée. Les preuves nécessitent à la fois vérification et jugement.
Cette limite mérite d’être conservée, car elle évite une erreur de catégorie courante. Une trace parfaitement préservée peut montrer ce qui s’est passé. Elle ne peut pas rendre bonne une question mal formulée. Une décision reproductible peut tout de même être une décision qui n’aurait jamais dû être automatisée. Le registre doit aider un lecteur ultérieur à poser les deux questions, sans répondre prématurément à la seconde.
La confiance peut être honnête sans être utile
Une probabilité bien calibrée peut tout de même être inutile. Elle peut être trop large pour distinguer les cas qui nécessitent un traitement différent. Elle peut arriver trop tard pour influencer la décision. Elle peut être liée à un résultat qui n'est pas exploitable. Elle peut être si incertaine que chaque cas exige le même examen. Ce ne sont pas des manquements à l'honnêteté. Ce sont des limites d'utilité, et elles devraient être reconnues tôt plutôt que découvertes après qu'un flux de travail a été construit autour du score.
À l'inverse, un système utile n'a pas besoin de prétendre être certain. Un signal modeste peut améliorer l'organisation du travail s'il a un objectif étroit et un parcours d'examen clair. Il peut aider un opérateur à voir quels cas méritent une vérification supplémentaire de la source. Il peut sélectionner un petit ensemble pour l'assurance qualité. Il peut faire apparaître un conflit entre des enregistrements. Dans ces usages, l'exigence de preuve concerne la question de savoir si le signal améliore le processus de décision spécifique sans introduire de nouvelles erreurs ou dépendances inacceptables. Le signal n'a pas besoin de devenir un oracle pour gagner sa place.
C'est pourquoi l'objectif visé doit contrôler l'évaluation. Les principes d'IA de l'OCDE appellent à une information significative sur les capacités et les limites des systèmes, et à la traçabilité en ce qui concerne les ensembles de données, les processus et les décisions, afin que les résultats puissent être analysés et que les demandes puissent être traitées. Les principes appellent également à une action humaine et à une surveillance appropriées. L'implication pratique n'est pas que chaque interface ait besoin d'un affichage de probabilité. C'est que les preuves et les explications d'un système doivent convenir à la personne et à la décision concernées.
Il n'y a aucun mérite à exposer une valeur d'incertitude que l'utilisateur ne peut ni interpréter ni utiliser. Un nombre sans voie de décision peut créer le théâtre de la transparence. Il donne aux gens quelque chose à montrer du doigt et aucun moyen de le contester. Mieux vaut montrer la limite pertinente en langage clair, comme cette suggestion est en dehors de la catégorie validée, ou ce résultat nécessite un examen parce que les preuves disponibles sont incomplètes. La présentation appropriée suit le contrôle opérationnel, et non l'inverse.
Pour la même raison, un score de confiance ne doit pas être traité comme une mesure de valeur morale, de crédibilité ou de droit. C'est une déclaration technique avec un contrat de preuve limité. Il peut aider un processus. Il ne devrait pas devenir un vague classement social parce que sa forme numérique le fait paraître décisif.
L'organisation est propriétaire de l'inférence
Les fournisseurs peuvent fournir des modèles, de la documentation, des scores et des résultats de tests. Ils ne peuvent pas s’approprier silencieusement le sens d’une décision prise dans le cadre d’un service qui appartient à quelqu’un d’autre. L’organisation qui relie un résultat probabiliste à une action doit décider sur quelle proposition elle s’appuie, quelle population importe, quel seuil est acceptable, qui examine les exceptions, quels enregistrements sont conservés et quand les preuves ont expiré. Les contrats peuvent répartir les tâches. Ils ne suppriment pas la nécessité du jugement.
Cela devient visible lors des achats. Un acheteur devrait demander à un fournisseur potentiel non seulement une mesure phare, mais aussi la question d’évaluation, la population, les étiquettes, les exclusions, les versions, la variation, la méthode de calibration si une affirmation de probabilité est faite, les limites connues et la politique de changement. L’objectif n’est pas d’exiger une divulgation que le fournisseur ne peut pas légalement fournir. Il s’agit d’établir si l’acheteur peut comprendre la limite de l’affirmation suffisamment bien pour l’utiliser de manière responsable dans un contexte opérationnel européen.
La réponse peut parfois être que les preuves ne sont pas adéquates pour l’utilisation prévue. Ce n’est pas un processus d’achat échoué. C’est le processus d’achat qui fait son véritable travail avant que l’organisation ne se soit rendue dépendante d’un score inexpliqué. Une utilisation plus restreinte et inspectable peut encore être possible. Un autre fournisseur peut être approprié. Ou la décision peut rester humaine parce que les preuves et la voie de correction ne sont pas assez solides pour justifier l’automatisation. Dire non fait partie de la discipline des preuves.
Les preuves ont également besoin d’un propriétaire désigné après le lancement. Quelqu’un doit être responsable de vérifier si la population a changé, si les examens révèlent un nouveau schéma d’erreur, si un seuil correspond toujours à la charge de travail, si les enregistrements peuvent être interprétés, et si un changement déclenche une réévaluation. Le propriétaire n’a pas besoin d’exécuter personnellement chaque test. Mais si aucun rôle ne possède l’inférence, le système acquerra progressivement de l’autorité par l’habitude. L’habitude est un piètre substitut à un registre de décisions.
La partie la plus difficile est souvent culturelle. Les équipes ont l’habitude de présenter les modèles réussis comme des produits et les modèles échoués comme de la recherche. Les preuves probabilistes leur demandent de préserver l’ambiguïté entre les deux : utile, limité, surveillé, et pas encore autorisé à devenir plus que ce que les preuves soutiennent. Cela peut sembler moins excitant. C’est plus durable.
Ce que contient un registre de preuves proportionné
Le registre approprié dépend de l’utilisation. Un outil d’aide à la rédaction utilisé par un auteur a des conséquences différentes d’un système qui influence l’accès à un service public. Néanmoins, un registre proportionné a une forme reconnaissable. Il identifie l’affirmation et l’objectif prévu. Il identifie le modèle, la configuration et le flux de travail environnant. Il définit le résultat et la population utilisés pour évaluer l’affirmation. Il préserve la méthode, le résultat et les limites significatives. Il identifie la règle de décision, le propriétaire, la voie d’examen et les déclencheurs de changement. Chaque champ donne à un lecteur ultérieur un point de départ.
Le registre doit distinguer la mesure de l’interprétation. Une observation mesurée pourrait dire que, sur un ensemble de données et une période spécifiés, un ensemble déclaré de scores correspondait à des résultats observés dans une fourchette décrite. Une interprétation pourrait dire que cela soutient l’utilisation comme signal d’ordonnancement des examens sous des contrôles spécifiés. Une décision pourrait dire que le système peut être utilisé à cette fin jusqu’à ce qu’un déclencheur de changement déclaré se produise. Mettre ces trois phrases sous un titre appelé performance n’est efficace que si personne n’a jamais besoin de contester le raisonnement.
Il doit aussi rendre les inconnues utilisables. Peut-être que les étiquettes sont retardées. Peut-être qu’un petit groupe linguistique manque de cas suffisants pour une évaluation de calibrage stable. Peut-être que le déploiement est récent et qu’il n’existe pas encore de preuve opérationnelle. Le dossier peut le dire, imposer une limite temporaire d’utilisation, organiser une observation supplémentaire ou conserver une voie humaine. Prétendre que l’inconnu a été résolu parce qu’un modèle a produit un nombre ne fait que convertir l’incertitude en un passif non documenté.
La discipline visuelle est utile ici. Dessinez la chaîne de l’entrée au score, du score à l’explication affichée, de l’explication à l’action humaine, et de l’action au résultat observé et à la correction. Dessinez où l’état est capturé, où il est perdu, et où une personne peut arrêter ou inverser le parcours. Si l’équipe ne peut pas dessiner le parcours, il est peu probable qu’elle puisse l’évaluer. Les diagrammes ne remplacent pas les preuves. Ils empêchent que les preuves soient attribuées à la mauvaise partie du système.
Avant tout, notez ce que le dossier n’établit pas. Il peut ne pas établir de causalité. Il peut ne pas établir d’équité entre tous les groupes. Il peut ne pas établir le comportement après un changement de fournisseur. Il peut ne pas établir l’adéquation à une action plus conséquente. Ces non-affirmations ne sont pas des excuses. Elles sont ce qui empêche une évaluation limitée d’être utilisée comme une autorisation universelle.
Les preuves donnent le droit de rester incertain
On est tenté de penser que l’objectif de l’évaluation est d’éliminer l’incertitude. Souvent, le meilleur objectif est de la localiser. Un système probabiliste n’est pas défectueux parce qu’il ne peut pas transformer chaque cas en certitude. Il devient dangereux lorsque l’organisation traite l’incertitude comme un détail technique privé tout en accordant à la sortie une autorité publique. Le travail consiste à décider quelle incertitude est tolérable, visible et récupérable pour l’objectif visé.
Cette décision doit devenir plus exigeante à mesure que les conséquences augmentent. Une suggestion à faible conséquence peut nécessiter un champ d’application clair, une limitation visible et une correction facile. Un système qui influence les droits, la sécurité, l’accès ou les opportunités matérielles nécessite des preuves plus solides sur l’ensemble du processus, une surveillance plus attentive, une autorité humaine significative et une voie de contestation et de recours. Le score du modèle ne détermine pas à lui seul cette norme. C’est l’effet de l’action qui en découle qui la détermine.
Une seule exécution réussie peut encore valoir la peine d’être conservée. Elle peut être le premier spécimen d’un dossier utile. Elle peut révéler une capacité, un mode de défaillance ou une question qui mérite une évaluation appropriée. Mais elle doit rester un spécimen jusqu’à ce que l’organisation ait testé la proposition sur laquelle elle veut s’appuyer. La distance entre ces deux choses est l’endroit où vit l’ingénierie responsable.
Ainsi, la réponse à ce qui compte comme preuve lorsque la machine est probabiliste n’est pas un score, un graphique ou une étiquette de conformité. C’est un argument limité : cette sortie, pour cette question, dans cette population et cette période, dans ces conditions, a été observée de cette manière ; voici ce que nous pouvons en déduire ; voici ce que nous ne pouvons pas en déduire ; et voici l’action que nous sommes, ou ne sommes pas, prêts à laisser changer. Cet argument n’est pas glamour. Il est inspectable, ce qui est mieux.