Le seuil est au code, le modèle ne donne qu’une probabilité

Mets quelques centaines de vrais projets côte à côte et le trait commun le plus stable est celui-ci :

Le modèle répond « quelle est la probabilité ». Ton code répond « est-ce suffisant ».

Ce n’est pas une préférence de style. C’est la seule conclusion sûre à tirer du fait que la confiance auto-déclarée ne peut pas être crue — et il y a une mesure indépendante derrière cela dans Peut-on faire confiance aux probabilités ?.

À quoi cela ressemble concrètement

Choice et Score renvoient une réponse avec un confidence attaché ; Noul renvoie directement une probabilité entre 0 et 1. L’interface elle-même ne juge rien pour toi — le seuil est le tien. Dans de vrais projets, cela se traduit par des choses très précises :

Un filtre d’insultes tournant sur un Cloudflare Worker garde son seuil, sa politique d’agrégation max() et son schéma OpenAPI public dans le code du Worker. Le modèle n’est qu’une fonction qu’il appelle.
Une extension de navigateur qui masque les commentaires garde 0.85 / 0.7 / 0.5 inscrits dans l’extension, et reste masquée quand la vérification échoue — cette préférence fait partie de la politique de seuil elle aussi.
Un outil de triage d’incidents définit « réveiller quelqu’un » comme P(SEV1) + P(SEV2) ≥ 0.80, et ce 0.80 vit dans sa propre configuration, pas dans le modèle.

Tous les trois partagent une propriété : change le modèle et le seuil ne bouge pas ; retouche le seuil et le modèle ne bouge pas. Confie le seuil au modèle et ces deux choses ne font plus qu’une — et « régler mon seuil » revient alors à modifier un prompt.

Pourquoi le principe compte

Parce qu’il sépare deux types de défaillance :

Le modèle a mal répondu — change la question, change l’état, change le modèle.
Le seuil est mal réglé — change le nombre dans le code.

Mélange les deux et « la précision n’est pas assez bonne » peut être l’un ou l’autre, sans moyen de savoir lequel. L’outil de triage peut inscrire 0.80 directement dans la configuration précisément parce que ce nombre peut être relu pour lui-même.

Le contre-exemple à connaître

Le principe repose sur une hypothèse : que le nombre que tu reçois est une probabilité calibrée.

Un recalcul indépendant a montré que le confidence renvoyé pour les questions Score n’est souvent que la partie fractionnaire du score, ces sorties étant fortement regroupées (121 d’entre elles). Ce n’est pas « le modèle est confiant » — cela ressemble à une valeur dérivée du score lui-même.

La différence compte :

Si c’est une probabilité calibrée, 0.85 soutient un raisonnement du type « j’aurai raison dans environ 85% des cas comme celui-ci ».
Si c’est une fonction du score, 0.85 signifie seulement « celui-ci a obtenu un score élevé » et ne dit rien sur la fréquence à laquelle il a raison — et poser un seuil dessus revient à poser une barre sur un nombre sans signification probabiliste.

Séparément, un rapport de mesure indépendant a confronté les champs auto-déclarés du modèle à la vérité terrain et a trouvé des valeurs bien moins granulaires que ne le suggère la description (voir Critiques publiques).

Que faire à la place

Trois étapes, et l’ordre compte :

Utilise le seuil de façon opérationnelle, pas sémantique. Que 0.8 signifie « 80% de correct » n’a pas d’importance. Ce qui compte, c’est de savoir si, sur tes données, les cas au-dessus de 0.8 sont mesurablement plus précis. Cela, tu peux le vérifier sur un jeu de validation.
Ajuste le seuil sur tes propres étiquettes. Des outils existent exactement pour cela : prends tes données étiquetées, ajuste le seuil par question qui atteint ta précision cible, valide sur un jeu de validation — et fais échouer la CI quand une mise à jour du modèle casse un seuil verrouillé.
Mets le seuil dans le code et donne-lui une date de revue. Les seuils expirent avec les versions du modèle, comme les prix. C’est une chose qu’une personne doit regarder à nouveau, pas quelque chose qu’on règle une fois pour toutes.

En une phrase

La fiabilité du modèle doit se voir dans ton seuil, pas dans son propre nombre déclaré. Le premier, tu peux le mesurer sur tes propres données ; le second, non.