Score de confiance d’un LLM : calibrez-le avant de lui faire confiance

Un score de confiance d’un LLM n’est utile qu’après avoir défini ce qu’il prédit, maintenu le protocole de mesure fixe et testé ce score par rapport à des résultats annotés issus de votre propre tâche. Un « 90 % » auto-déclaré, une probabilité logarithmique de token et neuf réponses concordantes sur dix échantillons sont trois signaux différents. Aucun ne vous donne une probabilité universelle de 0,9 qu’une réponse soit correcte.

Public visé : Intermédiaire — ingénieurs produit, équipes data et responsables techniques qui ont besoin qu’un LLM réponde, transmette ou s’abstienne.

Traitez le nombre brut comme une caractéristique, pas comme une décision. Calibrez-le sur un ensemble de données réservé, examinez l’évolution des erreurs lorsque vous rejetez les réponses aux scores faibles et mettez en place des contrôles déterministes autour de toute action susceptible de déplacer de l’argent, d’exposer des données ou de modifier l’état de la production.

Que mesure un score de confiance d’un LLM ?

Un score de confiance d’un LLM est un signal numérique destiné à classer ou à estimer la fiabilité d’une sortie de modèle. Sa signification dépend de la manière dont il a été produit.

Pour qu’un score se comporte comme une probabilité calibrée, les sorties auxquelles est attribué 0,8 devraient être correctes environ 80 % du temps pour le même type de travail. Cette affirmation nécessite quatre précisions :

Supprimez l’un de ces éléments et la « confiance de 0,8 » devient ambiguë. Elle peut signifier que le modèle a jugé la formulation probable, s’est répété de manière cohérente, a suivi une instruction lui demandant d’imprimer un nombre ou a classé une réponse au-dessus des autres. Ces propriétés peuvent être corrélées à la correction. Elles ne sont pas la correction elle-même.

La calibration diffère également de la discrimination. Un score présente une bonne discrimination lorsque les réponses correctes sont généralement classées au-dessus des réponses incorrectes. Il présente une bonne calibration lorsque ses valeurs numériques correspondent aux fréquences observées. Un système peut être utile pour le classement alors que ses pourcentages sont faux, ou afficher une calibration moyenne raisonnable tout en séparant mal les bonnes réponses des mauvaises.

Trois signaux sont couramment appelés confiance

Choisir entre ces signaux est une décision d’ingénierie. Les combiner peut aider, mais un ensemble de signaux doit tout de même être évalué sur la tâche cible.

La confiance verbalisée est une réponse sollicitée

L’approche la plus simple consiste à demander :

text Return your answer and the probability that it is correct from 0 to 1.

Cela fonctionne avec presque tous les modèles. Mais la valeur de confiance fait alors partie de la génération. La formulation du prompt, l’échelle de réponse, le contexte fourni et le fait que le modèle ait produit lui-même la réponse peuvent modifier le résultat.

Une étude de 2026 a testé trois familles de modèles de base et ajustés aux instructions, ouverts et de 7 à 8B paramètres, sur quatre benchmarks de questions-réponses. Les chercheurs ont conservé le prompt de confiance verbale fixe tout en modifiant la réponse évaluée, les tokens de réponse utilisés pour calculer le score de tokens et le contexte précédant ces tokens. La modification du contexte de conditionnement a davantage déplacé la comparaison de calibration entre confiance verbale et tokens que le changement d’estimateur de calibration, et a inversé le signal semblant le meilleur dans 9 des 12 configurations ajustées aux instructions, selon les comparaisons ECE et Brier. Lorsque les modèles évaluaient des réponses fournies, les réponses plausibles mais fausses recevaient presque la même confiance verbale que les réponses correctes fournies. Les auteurs décrivent donc les deux signaux comme des mesures comportementales dépendantes du protocole, et non comme des lectures directes de l’incertitude (Kim and Kang, 2026).

Ce résultat ne prouve pas que tout score verbal est inutile. Il montre pourquoi un prompt tel que « soyez honnête quant à votre confiance » ne peut pas remplacer un ensemble de calibration.

Les logprobs des tokens mesurent la vraisemblance du token suivant

Une probabilité logarithmique enregistre la probabilité qu’un token ait été produit selon la distribution de génération conditionnelle du modèle. La documentation d’OpenAI la définit comme la probabilité d’un token à une position donnée, compte tenu du contexte précédent ; les probabilités logarithmiques de séquence peuvent être additionnées pour effectuer un scoring ou un classement (OpenAI Cookbook). La réponse GenerateContent de Google expose également les probabilités logarithmiques moyennes des candidats et les résultats au niveau des tokens lorsque l’API et le modèle sélectionnés les prennent en charge (Gemini API reference).

Cela est utile pour un choix fermé tel que `approve` contre `reject`. Vous pouvez recueillir la masse de probabilité attribuée aux étiquettes autorisées, puis calibrer ce score. Il est beaucoup plus difficile d’interpréter une longue réponse en texte libre. La tokenisation, la longueur de la réponse, les paraphrases et le prompt de conditionnement influencent tous la vraisemblance de la séquence.

Une affirmation fausse mais fluide peut avoir une forte vraisemblance. Un nom correct mais inhabituel peut avoir une faible vraisemblance. Le score répond à la question « Dans quelle mesure cette séquence de tokens était-elle attendue ici ? » Il ne répond pas automatiquement à la question « L’affirmation est-elle vraie ? »

L’échantillonnage répété mesure l’accord

Échantillonner le modèle plusieurs fois fournit un signal de cohérence en boîte noire. Si huit réponses sur dix expriment la même réponse, le score d’accord empirique est de 0,8. Les réponses en texte libre nécessitent généralement un regroupement sémantique afin que les paraphrases soient comptées comme une même réponse.

Ce signal contient souvent davantage d’informations qu’une seule auto-évaluation, mais il entraîne deux coûts. Premièrement, dix générations coûtent environ dix fois plus d’appels de sortie avant que le traitement par lots, la mise en cache ou des prompts plus courts ne modifient le calcul. Deuxièmement, l’accord peut être systématiquement erroné lorsque le modèle répète la même idée fausse.

Des recherches récentes rendent ces deux points visibles. Un article de juillet 2026 a comparé la confiance verbale, un vérificateur fondé sur les logits et une méthode fondée sur l’échantillonnage appelée SliCK sur des questions-réponses factuelles courtes et à raisonnement en plusieurs étapes. Dans ce contexte, SliCK a obtenu une erreur de calibration plus faible et un meilleur classement des réponses correctes par rapport aux réponses incorrectes que les deux autres méthodes. Il a néanmoins enfreint un test de cohérence probabiliste fondé sur l’entailment dans 31 % des cas évalués. L’étude reposait sur un regroupement sémantique effectué par un juge LLM, des benchmarks de réponses courtes, un modèle principal accompagné de sous-ensembles inter-modèles plus petits et l’hypothèse que la fréquence d’échantillonnage reflète la croyance (Matta, Naphade, and Zou, 2026).

L’interprétation pratique est plus limitée que « l’échantillonnage résout la confiance ». L’accord est un signal brut utile. Il reste un signal qui doit être vérifié par rapport aux résultats.

*Un seuil de production intervient après les étiquettes propres à la tâche et les contrôles de calibration, et non directement après la sortie du modèle.*

Pourquoi un nombre de confiance plausible peut tout de même induire en erreur

Trois résultats récents devraient modifier la manière dont les équipes lisent un pourcentage placé à côté d’une réponse de LLM.

La précision et la calibration peuvent évoluer séparément

ConfidenceBench a évalué les probabilités obtenues par prompt de 15 modèles de pointe sur 200 questions privées à choix multiple en anglais, couvrant le raisonnement spatial, les mathématiques de haute précision, la recherche de mots et les questions auxquelles il est impossible de répondre. Chaque modèle a répondu trois fois à l’ensemble. Le benchmark utilisait le score de Brier, qui pénalise la distance au carré entre une probabilité déclarée et le résultat binaire.

Le classement des modèles selon la calibration ne reproduisait pas simplement celui fondé sur la précision. Les auteurs rapportent un meilleur score de Brier de 0,103, tandis que certains systèmes évalués obtenaient un score inférieur à celui d’une baseline aléatoire calibrée à quatre choix, de 0,1875. Le benchmark est volontairement réduit, privé, uniquement en anglais et à choix multiple. Ses scores verbaux peuvent refléter le suivi des instructions et le cadrage du prompt ; les chiffres ne doivent donc pas être généralisés aux tâches longues ou multi-tours (ffrench-Constant et al., 2026).

Mesurez directement la calibration. Ne la déduisez pas de la précision globale d’un modèle sur un benchmark.

Le protocole de mesure peut modifier la conclusion

Le score est associé à un pipeline spécifique. Si une équipe modifie le prompt, le snapshot du modèle, le format de réponse, les étiquettes candidates, la fenêtre de contexte, la température ou l’agrégation des logprobs, elle a modifié l’instrument de mesure.

Consignez ces choix avec chaque résultat d’évaluation. Les métriques brutes d’activité des agents de code nécessitent également le contexte du système et de l’évaluation avant de pouvoir dire quoi que ce soit sur la fiabilité. Si le prompt ou le modèle change, la recalibration devient un contrôle de release, et non un nettoyage facultatif.

Un score calibré peut tout de même échouer sur un sous-ensemble

Une moyenne peut masquer un échec dans une langue, un produit, un segment de clientèle, un type de document ou une longueur de réponse. Un classifieur d’assistance peut sembler calibré globalement parce que les questions courantes de facturation dominent l’ensemble de test, tandis que les rares tickets de sécurité restent trop confiants.

Examinez toujours les sous-ensembles comportant suffisamment d’exemples pour étayer une conclusion. Lorsque les échantillons sont peu nombreux, indiquez l’incertitude au lieu de traiter un taux bruité comme un fait.

Un workflow reproductible de calibration de la confiance d’un LLM

Le workflow suivant est volontairement réduit. Il peut être exécuté avant l’adoption d’un cadre d’incertitude plus vaste.

1. Définir l’événement et l’action

Écrivez une phrase qui complète ce modèle :

Exemples :

Évitez les événements tels que « la réponse est bonne ». Ils ne peuvent pas être annotés de manière cohérente.

Pour les actions aux effets irréversibles, la confiance ne doit pas remplacer l’autorisation. Un modèle peut aider à choisir une voie, mais les permissions des agents AI doivent toujours imposer les ressources autorisées, les arguments, les règles d’approbation et les reçus.

2. Constituer un ensemble de test réservé propre à la tâche

Collectez des entrées représentatives qui n’ont pas été utilisées pour ajuster le prompt ou la fonction de calibration. Incluez :

Étiquetez la correction à l’aide d’un vérificateur déterministe lorsque cela est possible. Pour les tâches subjectives, utilisez une grille écrite et une procédure d’arbitrage. Un score de confiance ne peut pas être plus défendable que ses étiquettes de résultat.

Commencez avec suffisamment de données pour révéler une mauvaise calibration manifeste, puis élargissez autour des sous-ensembles et des seuils importants. Un petit benchmark peut guider l’exploration, mais il ne peut pas justifier un seuil de production à haut risque.

3. Capturer le signal brut sans modifier le protocole

Stockez :

N’arrondissez pas avant l’évaluation. Un modèle qui n’émet que `0.7`, `0.8` et `0.9` doit être évalué comme trois catégories grossières, et non présenté comme une mesure précise de probabilité.

4. Calculer le score de Brier et une table de fiabilité

Pour une correction binaire, le score de Brier est :

text mean((confidence - outcome)²)

Plus il est faible, mieux c’est, mais ce nombre nécessite une baseline et un jeu de données comparable. Une table de fiabilité rend l’erreur plus facile à observer : regroupez les scores similaires, puis comparez le score moyen de chaque groupe à sa précision observée.

Ce script Python sans dépendance lit `id,score,correct` depuis un fichier CSV :

python import csv

with open("predictions.csv", newline="") as source: rows = [ (float(row["score"]), int(row["correct"])) for row in csv.DictReader(source) ]

if not rows: raise SystemExit("predictions.csv has no rows")

brier = sum((score - correct) ** 2 for score, correct in rows) / len(rows) print(f"Brier score: {brier:.4f}")

bin_count = 10 bins = [[] for _ in range(bin_count)]

for score, correct in rows: if not 0 <= score <= 1 or correct not in (0, 1): raise ValueError("score must be 0..1 and correct must be 0 or 1") index = min(int(score * bin_count), bin_count - 1) bins[index].append((score, correct))

print("range,count,mean_score,accuracy,gap") for index, values in enumerate(bins): if not values: continue mean_score = sum(score for score, _ in values) / len(values) accuracy = sum(correct for _, correct in values) / len(values) lower = index / bin_count upper = (index + 1) / bin_count print( f"{lower:.1f}-{upper:.1f},{len(values)}," f"{mean_score:.3f},{accuracy:.3f},{mean_score - accuracy:+.3f}" )

La table est descriptive. Les limites des catégories peuvent modifier les résumés de type ECE, en particulier sur les petits ensembles. Conservez ensemble le score de Brier, une vue de fiabilité et une métrique orientée vers l’action, plutôt que d’optimiser un seul graphique.

5. Choisir les seuils selon le risque et la couverture

Un seuil de 0,8 n’a aucune signification universelle. Évaluez ce qui se passe lorsque le système n’accepte que les sorties supérieures ou égales à chaque seuil candidat :

python print("threshold,coverage,accepted_accuracy") for threshold in (0.5, 0.6, 0.7, 0.8, 0.9): accepted = [ correct for score, correct in rows if score >= threshold ] coverage = len(accepted) / len(rows) accuracy = sum(accepted) / len(accepted) if accepted else float("nan") print(f"{threshold:.1f},{coverage:.3f},{accuracy:.3f}")

Cela crée une vue de base du compromis risque–couverture. Augmenter le seuil peut réduire les erreurs parmi les cas acceptés, mais envoie également davantage de travail vers le traitement de secours. Choisissez un seuil en fonction du coût d’une acceptation erronée, d’un rejet erroné, d’une vérification, de la latence et du préjudice potentiel pour l’utilisateur.

Utilisez au moins trois résultats lorsque le produit le permet :

6. Tester la dérive et les changements de protocole

Relancez l’ensemble de test après :

L’échantillonnage répété et un raisonnement plus approfondi ajoutent également du calcul. Ce compromis doit faire partie de l’évaluation : comparez la réduction des erreurs à la latence et au coût en tokens, plutôt que de supposer que davantage de tokens de raisonnement valent toujours leur prix.

Quelle méthode de confiance devriez-vous utiliser ?

Les bibliothèques open source peuvent réduire le travail d’implémentation. UQLM, par exemple, expose des scoreurs de cohérence en boîte noire, de probabilité de tokens en boîte blanche, de juge, d’ensemble et de textes longs. Sa documentation explicite également les compromis de latence et d’accès : les méthodes de cohérence nécessitent davantage d’appels, tandis que les méthodes en boîte blanche exigent des logprobs (UQLM documentation). Le dépôt recevait encore des releases en juillet 2026, notamment des correctifs dans la version v0.6.4, ce qui constitue un signal de maintenance plus solide que le nombre total d’étoiles à lui seul (UQLM v0.6.4).

Une bibliothèque fournit des estimateurs. Elle ne fournit ni les étiquettes, ni la définition de la tâche, ni la tolérance au risque, ni la surveillance en production qui rendent un seuil défendable.

Ce que la recherche actuelle n’établit pas

Les études citées ne prouvent pas qu’une méthode l’emporte dans toutes les applications de LLM.

La recherche peut identifier des signaux candidats. Validez le système complet sur le travail qu’il effectuera réellement.

Foire aux questions

Les scores de confiance des LLM sont-ils précis ?

Parfois, ils sont corrélés à la correction, mais la précision dépend du modèle, de la tâche, de la méthode de scoring, du prompt et de la distribution d’évaluation. Traitez un score non calibré comme une caractéristique de classement. Testez-le par rapport à des résultats annotés avant de l’interpréter comme une probabilité.

Les logprobs des tokens sont-ils identiques à la confiance ?

Non. Une logprob de token est la vraisemblance conditionnelle d’un token compte tenu de son contexte. Elle peut contribuer à une estimation de confiance, en particulier pour les tâches à étiquettes fermées, mais elle ne représente pas automatiquement la probabilité qu’une réponse en texte libre soit factuellement correcte.

Quel seuil de confiance d’un LLM dois-je utiliser ?

Il n’existe pas de seuil universel. Choisissez-en un à partir d’une analyse risque–couverture sur un ensemble réservé, qui reflète le coût d’une acceptation erronée, d’une vérification manuelle, de l’abstention et de l’automatisation manquée. Réévaluez-le après toute modification du modèle, du prompt ou de la distribution des données.

Vérification des affirmations

Sources