Peut-on faire confiance aux probabilités ?

Cette page répond à une question : peut-on faire confiance à ces chiffres de confiance ?

La conclusion d’entrée de jeu : « la forme de la sortie est garantie » et « la probabilité est exacte » sont deux affirmations entièrement différentes. La première a été vérifiée de plusieurs directions. La seconde est publiquement contestée. Quiconque place un modèle de décision derrière une barrière de production doit traiter la confiance rapportée par le fournisseur ou le projet comme un a priori à calibrer, pas comme une garantie.

Ce qu’est la calibration

Un modèle dit « je suis sûr à 80% ». Si tu rassembles tout ce qu’il a dit à 80% et qu’exactement 80% de ces cas sont corrects, le nombre est calibré. S’il y en a moins, il est trop confiant.

La métrique habituelle est l’ECE (Expected Calibration Error) : répartis les prédictions par confiance en intervalles, compare la confiance moyenne de chaque intervalle à sa précision réelle, et prends la moyenne pondérée par la taille des intervalles. Plus bas, c’est mieux.

La calibration et la précision sont des axes indépendants. Un modèle très précis peut être gravement trop confiant (surtout sur la tranche la plus difficile), et un modèle médiocre peut être bien calibré. Tu verras les deux ci-dessous.

Correctif 1 : la mise à l’échelle par température

Le correctif le moins cher et le plus général. L’idée : l’ordre des options du modèle est en général correct, mais l’échelle est fausse — trop de confiance signifie que tout se situe trop près de 0 et 1. Un paramètre de température, ajusté sur un jeu de validation, aplatit ou accentue la distribution.

Une réplique qui livre une évaluation hors ligne exécutable rapporte :

La mise à l’échelle par température plus l’abstention conformelle fait passer l’ECE de 0.170 à 0.071 (validation croisée).

Note « validation croisée » : il n’a pas été ajusté et évalué sur les mêmes données. C’est la différence entre un nombre digne de confiance et un autre qui ne l’est pas.

Correctif 2 : l’abstention conformelle

La mise à l’échelle par température corrige l’échelle. Les méthodes conformelles décident quand ne pas répondre.

Plutôt que de rendre chaque probabilité correcte, elles produisent un ensemble d’abstention et garantissent que la réponse vraie s’y trouve au moins une fraction déclarée du temps (une garantie de couverture). Les cas qui ne franchissent pas la barre sont escaladés plutôt que traités automatiquement.

Dans de vrais projets :

• Une alternative ouverte de 118M utilise la mise à l’échelle par température plus un ensemble d’abstention split-conformal et rapporte un ECE de 0.01–0.03 sur des suites publiques — tout en déclarant franchement que sur les benchmarks de décision typée, elle perd face à Laya (0.71 vs 0.77). Un projet qui publie ses pertes est plus informatif qu’un qui ne publie que ses victoires.
• Une implémentation médicale utilise deux lecteurs locaux figés plus un routeur sans ajustement et un ensemble de candidats split-conformal pour borner l’erreur, atterrissant à 2 points du service hébergé sur trois examens de licence nationaux de 600 items, sans ajustement fin ni distillation.

Ce que les deux ont en commun : ni l’une ni l’autre ne prétend que les probabilités sont devenues exactes. Elles prétendent savoir quand elles ne le sont pas. Dans un vrai système, c’est la seconde qui peut te servir de barrière.

Un résultat indépendant contre-intuitif : le biais a des signes opposés

Un test de calibration indépendant a utilisé 900 tickets générés par des règles (que le modèle ne peut pas avoir vus) plus trois benchmarks publics, publié chaque réponse brute et un ECE par rapport à un plancher de bruit simulé, et est arrivé à une conclusion sur le signe :

La valeur est dans le signe. Si le biais était aléatoire, une seule température globale le corrigerait. Des sens opposés signifient qu’une correction globale unique ne le peut pas — il faut au minimum calibrer par primitive.

Cela explique aussi une défaillance de conception précise : si un système compare les confiances de Noul et de Choice au même seuil, il mesure la même chose avec une règle trop courte et une autre trop longue.

La langue d’entrée influe aussi sur la calibration

Une autre mesure, sur un corpus espagnol de 3,200 items étiquetés par des humains :

Écrire l’état en espagnol a coûté 3.0–6.4 points de précision et a à peu près doublé l’ECE sur XNLI / PAWS-X, tandis qu’écrire les instructions en espagnol n’a eu aucun effet.

La distinction état/instructions est le cœur du propos : l’état est du contenu, les instructions sont des métadonnées. Cela compte surtout pour les lecteurs chinois et japonais — leurs états suivront très probablement un chemin similaire, et personne n’en a publié de mesure. Il n’y a aucune raison de supposer que cela ne se produit pas dans ta langue.

Alors comment le seuil est-il choisi ?

Tout ce qui précède aboutit à la même question : d’où vient ce 0.8 ?

La réponse reproductible est mesure, ne devine pas : prends tes propres données étiquetées, ajuste le seuil par question qui atteint ta précision cible, et valide-le sur un jeu de validation.

Un outil fait exactement cela et ajoute l’étape qui compte le plus : il fait échouer la CI quand une mise à jour du modèle casse un seuil verrouillé. Les seuils expirent comme les prix — sauf qu’un prix faux se fait remarquer et qu’un seuil faux, non.

En une phrase

Traite la confiance comme un a priori, pas comme une garantie. Mesure d’abord la bande fiable sur tes propres données, puis inscris cette bande dans le code.