Documentation

Critiques publiques et résultats qui ne se sont pas reproduits

La page précédente traitait de la façon de corriger la calibration. Cette page traite pourquoi il faut la corriger — en rassemblant les preuves publiques contraires, parce qu’elles arrivent rarement sur la page d’accueil d’un projet.

La bonne façon de lire cette page n’est pas « donc le modèle est mauvais » mais : voici des modes de défaillance connus, et ton système doit y survivre.

L’expérience du dé

La plus directe. Demande au modèle de deviner un dé équilibré, 400 fois :

Élément Résultat
Quelle face il a choisie la même face les 400 fois
Probabilité auto-déclarée moyenne 82.9%
Taux de réussite réel 19.0%

Ces chiffres disent deux choses à la fois. D’abord, une probabilité auto-déclarée peut ne porter aucune information du tout — 82.9% ne t’a rien dit de fiable sur une tâche au taux de réussite de 19%. Ensuite, le modèle n’exprime pas « je ne sais pas ». Sur un dé équilibré la bonne réponse est « environ 16.7% chacun », et la forme de la sortie — une option préférée avec une probabilité élevée — n’a aucun moyen de le dire.

Un autre résultat du même auteur mérite d’être conservé : sur un document de prévision synthétique, un risque de pénurie de 30% est devenu 5.3% via Choice et 26.7% via Noul. Même entrée, même sens, primitive différente — une différence d’un facteur cinq. Le choix de la primitive change la réponse, et il y en a des preuves plus solides sur la page d’évaluation.

« On ne peut pas calibrer Jev »

Une critique largement diffusée soutient, au niveau statistique, que l’affirmation sur la calibration ne tient pas au vu des preuves disponibles. Une discussion très votée formule le même point avec plus de prudence :

La garantie de sûreté de typage est réelle (vérifiée de plusieurs directions), mais l’affirmation sur la calibration n’a ni ECE ni courbe de fiabilité publiés derrière elle.

Remarque la précision : il n’est pas dit que la calibration est fausse, il est dit que les preuves publiques qui la soutiennent manquent. Ce sont des affirmations différentes, et pour une décision d’ingénierie elles mènent au même endroit — tu ne peux pas poser un seuil de production sur quelque chose qui n’a pas de courbe de fiabilité publiée.

Le reranking : un résultat négatif complet

Cette classe de résultat est la plus précieuse, parce qu’elle est précise, reproductible, et annule exactement l’implication « il peut tout faire ».

Une évaluation de reranking a utilisé 33,047 items, 164 requêtes réelles et 9,831 paires jugées, et a conclu que le reranking par pur modèle de décision perd face à la recherche vectorielle.

L’échelle est le point : une trentaine de milliers d’items et plus de cent requêtes réelles, ce n’est pas un cadre jouet. Et le cas d’usage qu’elle annule — le reranking sémantique — est exactement celui qu’on est le plus susceptible de supposer découler gratuitement de la classification.

Une décision partagée

Certains résultats dépendent de la ligne qu’on lit. Une comparaison notation contre génération :

Sur du NLI japonais, une notation multidimensionnelle avec des poids ajustés localement a battu la question posée directement (0.9076 vs 0.8373). Mais elle a signalé environ 25 fois plus de lignes bénignes difficiles comme des attaques (37.2% vs 1.5%).

La moyenne s’est améliorée tandis que le taux de faux positifs d’une classe a été multiplié par 25. Si signaler à tort une entrée bénigne coûte cher dans ton système, cette amélioration est négative pour toi — même si elle en a l’air positive.

Il y a aussi une expérience préenregistrée (critères fixés avant l’exécution, résultats publiés dans tous les cas) qui a produit des verdicts incohérents selon les jeux de données — réussissant sur l’un, échouant sur un autre.

La documentation du fournisseur l’admet elle-même

La page officielle sur les « irrégularités du modèle » liste les modes de défaillance connus de la version publique actuelle. Ce n’est pas une preuve contraire, mais son existence dit quelque chose : « ce modèle se comporte mal sur certaines tâches » fait partie de la position officielle, ce n’est pas un secret.

Transformer cette page en règles

Trois règles d’ingénierie en découlent :

  1. Ne raisonne jamais d’une tâche à l’autre à partir de la valeur absolue d’une confiance. « 0.9 signifie 90% correct » est tout simplement faux sur une tâche comme le dé.
  2. Le choix de la primitive est une variable expérimentale, pas un choix de style. La même question posée comme Choice ou comme Noul peut varier d’un facteur cinq. Mesure cette différence plutôt que d’en choisir une arbitrairement.
  3. Regarde les sous-classes, pas les totaux. L’exemple du faux positif ×25 est complètement invisible dans l’agrégat.

En une phrase

Rien de tout cela n’est une raison de ne pas utiliser ces modèles — c’est une raison de ne pas faire confiance aux valeurs par défaut. Chaque patron ailleurs dans ce guide (le seuil est au code, le gating, l’abstention conformelle) est une façon de travailler dans les contraintes de cette page.