Accueil › Glossaire › Logprobs

Logprobs : voir la confiance du LLM token par token

Les logprobs (log-probabilités) sont les logarithmes naturels des probabilités que le modèle assigne à chaque token lors de la génération. En activant ce paramètre dans l’API d’un LLM, vous obtenez non seulement le texte généré, mais aussi un score de confiance pour chaque token choisi et les alternatives envisagées par le modèle. C’est un outil de transparence qui transforme une « boîte noire » en un système dont les décisions sont mesurables.

Comprendre les logprobs

À chaque étape de génération, un LLM calcule une distribution de probabilités sur tout son vocabulaire (typiquement 32K à 128K tokens). Le token généré est celui qui a été sélectionné (par greedy decoding, sampling, etc.) parmi cette distribution. Les logprobs exposent cette distribution.

Pourquoi des logarithmes plutôt que des probabilités directes ? Deux raisons techniques :

Stabilité numérique : les probabilités de tokens individuels sont souvent très petites (0,0001 ou moins). Multiplier de nombreuses petites probabilités cause un sous-dépassement (underflow). En log, la multiplication devient une addition, évitant le problème.

Optimisation : pendant l’entraînement, la fonction de perte (cross-entropy) opère directement sur les log-probabilités. Travailler en logprobs est donc naturel pour les calculs du modèle.

Conversion logprob ↔ probabilité

Logprob → Probabilité : P = exp(logprob)
Probabilité → Logprob : logprob = ln(P)

Exemples courants :
  logprob = 0.0    → P = 1.00  (100 % de confiance)
  logprob = -0.10  → P = 0.90  (90 %)
  logprob = -0.69  → P = 0.50  (50 %)
  logprob = -2.30  → P = 0.10  (10 %)
  logprob = -4.61  → P = 0.01  (1 %)
  logprob = -6.91  → P = 0.001 (0.1 %)

En Python :
import math
probability = math.exp(logprob)       # logprob → probabilité
logprob = math.log(probability)       # probabilité → logprob

Plus le logprob est proche de 0, plus le modèle est confiant. Plus il est négatif, moins le modèle est sûr de son choix.

Cas d’usage principaux

Classification avec score de confiance

C’est le cas d’usage le plus répandu. Au lieu de simplement obtenir la classe prédite par le LLM, les logprobs vous donnent la confiance du modèle dans cette prédiction :

Prompt : "Classifie cet email comme 'spam', 'travail', 'personnel' ou 'autre'.
Email : 'Félicitations, vous avez gagné un iPhone ! Cliquez ici...'"

Réponse du modèle : "spam"
Logprob du token "spam" : -0.013 → exp(-0.013) = 98.7 % de confiance

→ Le modèle est à 98.7 % sûr que c'est du spam. Fiable !

Autre email : "Suite à notre réunion de ce matin..."
Réponse : "travail"
Logprob du token "travail" : -0.35 → exp(-0.35) = 70.5 %
Top alternatives : "personnel" (-1.2 → 30 %)

→ Confiance de 70 % seulement. Router vers un LLM plus gros
  ou demander une revue humaine.

Ce pattern permet de construire des systèmes de classification avec seuils de confiance : si la confiance dépasse 95 %, la classification est automatique. En dessous, on escalade vers un modèle plus performant ou un humain. Résultat : un classifieur rapide et peu coûteux (petit modèle) pour les cas simples, avec un filet de sécurité pour les cas ambigus.

Évaluation de la qualité du RAG

Dans un système de RAG (Retrieval-Augmented Generation), les logprobs servent à mesurer si le modèle a trouvé la réponse dans le contexte récupéré ou s’il « hallucine » :

Quand le contexte contient l’information pertinente, le modèle génère la réponse avec des logprobs élevés (haute confiance). Quand le contexte est non pertinent, les logprobs sont bas (le modèle « devine »). En calculant la moyenne des logprobs de la réponse, on obtient un « score de grounding » qui quantifie à quel point la réponse est ancrée dans le contexte fourni.

Autocomplétion intelligente

Les logprobs révèlent les top-k tokens les plus probables à chaque position, ce qui est idéal pour construire des systèmes d’autocomplétion. Si l’utilisateur tape « La capitale de la », les top_logprobs montrent les complétions les plus probables (« France » à 40 %, « Belgique » à 15 %, « Suisse » à 10 %) que vous pouvez afficher comme suggestions.

Détection de texte généré par IA

Un texte généré par un LLM aura tendance à avoir des logprobs élevés (le modèle est « confiant » car il suit ses propres distributions). Un texte écrit par un humain aura des logprobs plus variables et globalement plus bas (les humains font des choix de mots que le modèle n’aurait pas privilégiés). La somme ou la moyenne des logprobs d’un texte peut servir de signal (imparfait) pour la détection de contenu IA.

Monitoring des API LLM

Une utilisation récente (2025) : surveiller les changements non annoncés dans les API de LLM. En envoyant régulièrement un prompt fixe et en comparant les logprobs retournés, on peut détecter quand un fournisseur a modifié son modèle, changé ses paramètres de serving, ou remplacé une version par une autre. Des recherches ont montré que cette technique (« logprob tracking ») détecte les changements de modèle plus rapidement et à moindre coût que les méthodes basées sur les tokens de sortie.

Le paramètre top_logprobs

En plus du logprob du token choisi, les API permettent de voir les alternatives que le modèle a envisagées :

# OpenAI API
response = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "La capitale du Japon est"}],
    logprobs=True,
    top_logprobs=5,    # retourne les 5 tokens les plus probables
    max_tokens=5,
    temperature=0
)

# Résultat pour le premier token généré :
# Token choisi : "Tokyo"   logprob: -0.0002 → P = 99.98 %
# Alternatives :
#   "Tok"      logprob: -8.5    → P = 0.02 %
#   " la"      logprob: -12.3   → P = 0.00 %
#   "la"       logprob: -13.1   → P = 0.00 %
#   " Tokyo"   logprob: -14.0   → P = 0.00 %

OpenAI autorise jusqu’à 5 top_logprobs par position, Gemini jusqu’à 20, et les frameworks open source (vLLM) n’ont pas de limite technique.

Calculer la probabilité d’une séquence

La probabilité jointe d’une séquence complète est le produit des probabilités de chaque token. En log, c’est la somme :

logprob(séquence) = Σ logprob(token_i)

Exemple : "Tokyo est une ville" (4 tokens)
  logprob("Tokyo")   = -0.0002
  logprob(" est")    = -0.15
  logprob(" une")    = -0.30
  logprob(" ville")  = -0.45

  logprob(séquence) = -0.0002 + -0.15 + -0.30 + -0.45 = -0.90
  P(séquence) = exp(-0.90) ≈ 40.7 %

Perplexité moyenne par token :
  PPL = exp(-logprob_moyen) = exp(0.90/4) = exp(0.225) ≈ 1.25

Cette somme de logprobs est utilisée pour scorer et comparer différentes sorties du même modèle (par exemple, choisir la meilleure traduction parmi k hypothèses de beam search). La moyenne par token (et la perplexité associée) est plus juste que la somme brute car elle ne pénalise pas les séquences longues.

Implémentation pratique

# OpenAI : classification avec logprobs
from openai import OpenAI
import math

client = OpenAI()

def classify_with_confidence(text, categories):
    response = client.chat.completions.create(
        model="gpt-4o",
        messages=[
            {"role": "system", "content": f"Classifie le texte dans une de ces catégories : {', '.join(categories)}. Réponds uniquement avec le nom de la catégorie."},
            {"role": "user", "content": text}
        ],
        logprobs=True,
        top_logprobs=3,
        max_tokens=10,
        temperature=0
    )

    token_info = response.choices[0].logprobs.content[0]
    category = token_info.token
    confidence = math.exp(token_info.logprob)
    alternatives = {
        alt.token: math.exp(alt.logprob)
        for alt in token_info.top_logprobs
    }

    return {
        "category": category,
        "confidence": f"{confidence:.1%}",
        "alternatives": alternatives
    }

result = classify_with_confidence(
    "Votre colis sera livré demain entre 14h et 18h.",
    ["logistique", "facturation", "réclamation", "autre"]
)
# {"category": "logistique", "confidence": "94.2%", "alternatives": {...}}

# Hugging Face : accéder aux logprobs manuellement
import torch
from transformers import AutoModelForCausalLM, AutoTokenizer

model = AutoModelForCausalLM.from_pretrained("mistralai/Mistral-7B-v0.1")
tokenizer = AutoTokenizer.from_pretrained("mistralai/Mistral-7B-v0.1")

inputs = tokenizer("La capitale du Japon est", return_tensors="pt")
with torch.no_grad():
    outputs = model(**inputs)

# Logits du dernier token → logprobs
logits = outputs.logits[0, -1, :]  # dernier token
logprobs = torch.log_softmax(logits, dim=-1)

# Top 5 tokens les plus probables
top5 = torch.topk(logprobs, k=5)
for logprob, idx in zip(top5.values, top5.indices):
    token = tokenizer.decode(idx)
    prob = torch.exp(logprob).item()
    print(f"{token:15s} logprob={logprob:.4f}  P={prob:.2%}")

Limites et précautions

Non-déterminisme : les logprobs ne sont pas parfaitement reproductibles. Même avec le même prompt et seed, de légères variations peuvent apparaître entre requêtes, causées par le batching sur GPU, les arrondis en précision réduite, et le routage vers différentes machines dans les API cloud.

Confiance ≠ exactitude : un logprob élevé signifie que le modèle est confiant, pas qu’il a raison. Un modèle peut être très confiant dans une hallucination. Les logprobs mesurent la cohérence interne du modèle, pas la vérité factuelle.

Indisponibilité chez certains fournisseurs : Anthropic (Claude) ne propose pas les logprobs dans son API publique. Si les logprobs sont critiques pour votre cas d’usage, vérifiez la disponibilité chez votre fournisseur avant de vous engager.

Coût du top_logprobs : retourner les top 5 ou top 20 alternatives à chaque position augmente la taille de la réponse API. Pour les applications à haut débit, cela peut impacter la bande passante et les coûts de transfert.

Utilisations avancées des logprobs

Routage intelligent entre modèles

Les logprobs permettent de construire des systèmes de routage qui choisissent dynamiquement le modèle à utiliser. Le principe : un petit modèle rapide et peu coûteux traite d’abord chaque requête. Si ses logprobs indiquent une haute confiance (> 95 %), sa réponse est acceptée. Si la confiance est faible, la requête est redirigée vers un modèle plus performant (et plus cher).

Ce pattern, appelé « cascade de modèles » ou « model routing », réduit considérablement les coûts en production. Si 80 % des requêtes sont « faciles » (haute confiance du petit modèle), vous n’utilisez le grand modèle que pour les 20 % restants, économisant potentiellement 60 à 70 % de votre budget API.

Calibration des probabilités

Les logprobs bruts ne sont pas toujours bien calibrés : un modèle qui annonce 90 % de confiance devrait avoir raison 90 % du temps. En pratique, les LLM tendent à être sur-confiants (ils annoncent 95 % mais n’ont raison que 85 % du temps). La température affecte cette calibration : une température de 1.0 donne généralement les logprobs les plus calibrés, tandis qu’une température basse les rend sur-confiants.

Pour les applications critiques (médical, juridique, financier), il est recommandé de calibrer les logprobs sur un jeu de validation : mesurez la précision réelle pour chaque tranche de confiance et ajustez vos seuils en conséquence.

Évaluation de modèles par perplexité

La perplexité, dérivée directement des logprobs, est la métrique standard pour comparer des modèles de langue. Pour évaluer un modèle sur un corpus de test :

PPL = exp(-1/N × Σ logprob(token_i))

Interprétation :
  PPL = 1    → le modèle prédit parfaitement chaque token
  PPL = 10   → le modèle hésite en moyenne entre 10 options
  PPL = 100  → le modèle hésite entre 100 options (mauvais)

Valeurs typiques sur des corpus anglais :
  GPT-4 : PPL ≈ 5-8
  GPT-2 (small) : PPL ≈ 20-30
  Modèle aléatoire : PPL = |V| (taille du vocabulaire)

La perplexité permet de comparer des modèles entre eux sur le même corpus, de mesurer l’impact du fine-tuning, et de détecter si un texte fait partie des données d’entraînement (perplexité anormalement basse).

Débogage de prompts

Les logprobs sont un outil puissant pour comprendre pourquoi un prompt ne fonctionne pas. En examinant les logprobs token par token, vous pouvez identifier le point exact où le modèle « déraille » (logprobs chutant brusquement) et reformuler le prompt en conséquence. C’est particulièrement utile pour les problèmes de tokenisation : si un URL ou un terme technique est mal tokenisé, les logprobs révèlent l’incertitude du modèle sur ces tokens spécifiques.

Modération et guardrails

Les logprobs renforcent les systèmes de modération. Un prompt « guardrail » peut demander au modèle de classifier sa propre réponse comme « conforme » ou « non conforme ». Si les logprobs montrent que le modèle hésite (faible écart entre « conforme » et « non conforme »), le système peut bloquer la réponse par précaution. Cette approche est plus fine qu’un simple classifieur binaire car elle exploite l’incertitude du modèle comme signal de risque.

Dans les secteurs réglementés (finance, santé, juridique), les logprobs des guardrails sont souvent loggés pour des raisons d’auditabilité. Ils constituent une trace documentée de la confiance du modèle dans la conformité de chaque réponse.