⏱️ Lectura: 18 min
Un clasificador que dice “estoy 98% seguro” debería acertar 98 de cada 100 veces. En la práctica, muchos modelos de lenguaje entregan ese nivel de confianza y solo aciertan 7 de cada 10: ese desajuste entre la probabilidad que el modelo reporta y la probabilidad real de estar en lo correcto es lo que la calibración de modelos mide y corrige.
📑 En este artículo
- TL;DR
- ¿Qué es la calibración de modelos?
- Por qué importa
- Cómo funciona: del logit a la probabilidad calibrada
- Ejemplos prácticos: medir el ECE paso a paso
- Cómo empezar: calibrar tu propio clasificador
- Comparativa de métodos de calibración
- Casos de uso reales
- Errores comunes y buenas prácticas
- Profundizando: por qué las redes son sobreconfiadas
- Preguntas frecuentes
- Referencias
El problema aparece sobre todo cuando un modelo se usa como decision model: un sistema que elige entre opciones fijas en una sola pasada, en lugar de generar texto token por token. Ahí la confianza reportada suele tratarse como un puntaje de certeza, pero sin calibrar, ese puntaje miente.
TL;DR
- 98% de confianza no significa 98% de aciertos: la calibración mide exactamente esa brecha.
- El ECE (error de calibración esperado) resume en un número cuánto se aleja la confianza de la exactitud real.
- Temperature scaling corrige la sobreconfianza ajustando un parámetro sobre los logits, sin reentrenar nada.
- Platt scaling e isotonic regression sirven cuando el desajuste no es uniforme entre clases o bins.
- Veinte líneas de PyTorch bastan para calcular el ECE de cualquier clasificador antes de confiar en sus probabilidades.
¿Qué es la calibración de modelos?
La calibración de modelos es la propiedad de un clasificador donde la probabilidad que reporta para cada predicción coincide, en promedio, con la frecuencia real de acierto: un modelo calibrado que dice 80% de confianza acierta cerca del 80% de esas veces, sin sobreestimar ni subestimar su propio desempeño.
La calibración no es lo mismo que la exactitud. Un modelo puede acertar el 90% de las veces y estar pésimamente calibrado si reporta 99% de confianza en casi todos los casos. Un modelo con menos exactitud puede estar perfectamente calibrado si sus niveles de confianza reflejan honestamente su tasa de error. Son dos ejes ortogonales. Uno mide si el modelo tiene razón; el otro, si el modelo sabe cuándo tiene razón.
Por qué importa
La calibración de modelos importa especialmente en sistemas que automatizan decisiones: triage médico, moderación de contenido, scoring de riesgo crediticio o cualquier pipeline que decide “confío en esto y lo dejo pasar sin revisión humana” por encima de un umbral de confianza. Si ese umbral está mal calibrado, el pipeline automatiza errores con la misma seguridad con la que automatiza aciertos.
El caso que motiva este artículo es ilustrativo. Un desarrollador evaluó un modelo Qwen3-1.7B como clasificador de opción múltiple sobre una muestra de CommonsenseQA, restringiendo la salida a cinco tokens posibles (A, B, C, D, E) y usando el softmax de esos logits como puntaje de confianza. El modelo acertó 725 de 1221 preguntas (59,38% de exactitud), un resultado razonable para un modelo de apenas 1.7B parámetros sin ajuste fino. El problema no fue la exactitud global: fue lo que pasó al agrupar las predicciones por nivel de confianza.
Al dividir las predicciones en diez bins de confianza, el bin superior (entre 90% y 100%) promedió una confianza de 98,55% pero acertó solo el 70,09% de las veces. El modelo se equivocaba casi 3 de cada 10 veces en el grupo donde decía estar casi completamente seguro. En el bin de 80% a 90% la brecha era peor todavía: 85,55% de confianza promedio contra 47,11% de aciertos reales. El modelo no solo se equivocaba, sino que lo hacía con una confianza que no tenía ninguna relación con su probabilidad real de éxito.
Cómo funciona: del logit a la probabilidad calibrada
Todo empieza en la capa final de la red. Un clasificador no produce directamente una probabilidad: produce un vector de logits, números sin normalizar que después se convierten en una distribución de probabilidad con softmax. La fórmula es softmax(z)_i = exp(z_i / T) / Σ exp(z_j / T), donde T es la temperatura. Con T = 1 obtenés el softmax estándar; subir T aplana la distribución y bajarla la afila.
El problema de calibración surge porque las redes modernas, entrenadas con suficiente capacidad y suficientes épocas, tienden a producir logits con magnitudes grandes: la red “aprende” a estar segura de sí misma más rápido de lo que aprende a estar en lo correcto. El paper de referencia sobre el tema, “On Calibration of Modern Neural Networks” (Guo et al., 2017), documentó este fenómeno en redes de visión profundas y mostró que la sobreconfianza crece con la profundidad y el número de parámetros, no necesariamente con la exactitud.
Para medir cuánto se desvía un modelo de la calibración perfecta se usa el ECE (error de calibración esperado). El cálculo agrupa las predicciones en M bins según su confianza, y para cada bin compara la confianza promedio contra la exactitud real:
flowchart TD
A["Logits del modelo"] --> B["Softmax con temperatura T"]
B --> C["Probabilidad por clase"]
C --> D["Agrupar en M bins por confianza"]
D --> E["Comparar confianza promedio vs exactitud real"]
E --> F[("ECE = suma ponderada de las diferencias")]
La fórmula es ECE = Σ (n_m / N) * |acc(m) - conf(m)|, donde n_m es la cantidad de ejemplos en el bin m, N el total, acc(m) la exactitud real del bin y conf(m) la confianza promedio del bin. Un ECE de 0 significa calibración perfecta; en la práctica, modelos sin calibrar rondan valores de 0.10 a 0.25 en tareas con muchas clases.
Una forma visual de ver lo mismo es el reliability diagram: un gráfico de barras donde el eje X es la confianza promedio de cada bin y el eje Y es la exactitud real de ese bin. Si el modelo estuviera perfectamente calibrado, cada barra tocaría la diagonal donde confianza y exactitud son iguales. Cuando las barras quedan por debajo de la diagonal en los bins de alta confianza, como en el experimento con Qwen3-1.7B, el diagrama muestra de un vistazo que el modelo es sistemáticamente sobreconfiado.
Ejemplos prácticos: medir el ECE paso a paso
El primer paso siempre es medir antes de corregir. Este ejemplo calcula el ECE a partir de un arreglo de confianzas y aciertos, sin depender de ningún framework de deep learning:
import numpy as np
def expected_calibration_error(confidences, accuracies, n_bins=10):
bin_edges = np.linspace(0, 1, n_bins + 1)
ece = 0.0
n = len(confidences)
for low, high in zip(bin_edges[:-1], bin_edges[1:]):
mask = (confidences > low) & (confidences <= high)
if mask.sum() == 0:
continue
bin_conf = confidences[mask].mean()
bin_acc = accuracies[mask].mean()
ece += (mask.sum() / n) * abs(bin_acc - bin_conf)
return ece
# confianzas y aciertos (1 = correcto, 0 = incorrecto) de un clasificador de ejemplo
confidences = np.array([0.98, 0.96, 0.99, 0.55, 0.60, 0.91])
accuracies = np.array([1, 0, 1, 1, 0, 0])
print(f"ECE: {expected_calibration_error(confidences, accuracies):.4f}")
Salida esperada:
ECE: 0.3317
Un ECE de 0.33 es alto: indica que, en promedio, la confianza reportada se aleja 33 puntos porcentuales de la exactitud real en los bins donde cae este puñado de ejemplos. En un dataset real con miles de predicciones, cualquier valor por encima de 0.05 ya amerita corrección.
El segundo paso es llevar esta misma lógica a un modelo real. Siguiendo el patrón de clasificación por tokens restringidos que usa el experimento original con Qwen3-1.7B, este script calcula la confianza por predicción antes de aplicar ninguna corrección:
import torch
from transformers import AutoModelForCausalLM, AutoTokenizer
model_name = "Qwen/Qwen3-1.7B"
tokenizer = AutoTokenizer.from_pretrained(model_name)
model = AutoModelForCausalLM.from_pretrained(model_name, torch_dtype="auto", device_map="auto")
def predict_with_confidence(prompt, option_token_ids):
inputs = tokenizer(prompt, return_tensors="pt").to(model.device)
with torch.no_grad():
logits = model(**inputs).logits[0, -1]
probs = torch.softmax(logits[option_token_ids], dim=-1)
idx = probs.argmax().item()
return idx, probs[idx].item()
# option_token_ids: ids de los tokens A, B, C, D, E obtenidos con tokenizer.encode
Corriendo esta función sobre un lote de preguntas y acumulando (confianza, acierto) por cada una, se obtiene el mismo arreglo que alimenta expected_calibration_error(). En el experimento de referencia, el bin de confianza 90-100% fue el que más pesó en el promedio final: concentró 809 de las 1221 predicciones.
Cómo empezar: calibrar tu propio clasificador
Antes de instalar nada necesitás tres dependencias: Python 3.10 o superior, PyTorch y la librería transformers de Hugging Face. Si vas a correr un modelo como Qwen3-1.7B en CPU, alcanza sin GPU, aunque cada inferencia tarda más.
En Linux (Ubuntu/Debian):
python3 -m venv venv
source venv/bin/activate
pip install torch transformers numpy
En macOS el mismo bloque funciona igual con python3 del sistema o de Homebrew. En Windows, activá el entorno con venv\Scripts\activate en vez de source venv/bin/activate; el resto de los comandos es idéntico.
Con el entorno activo, guardá el script de medición de ECE de la sección anterior en un archivo calibration.py y corrélo:
python3 calibration.py
Salida esperada (usando el arreglo de ejemplo):
ECE: 0.3317
El siguiente paso es corregir ese ECE con temperature scaling. La técnica busca, por optimización numérica, el valor de T que minimiza la pérdida logarítmica (NLL) sobre un conjunto de validación separado del que se usó para entrenar:
import torch
def fit_temperature(logits, labels, lr=0.01, max_iter=50):
temperature = torch.nn.Parameter(torch.ones(1))
optimizer = torch.optim.LBFGS([temperature], lr=lr, max_iter=max_iter)
nll = torch.nn.CrossEntropyLoss()
def closure():
optimizer.zero_grad()
loss = nll(logits / temperature, labels)
loss.backward()
return loss
optimizer.step(closure)
return temperature.item()
Esta implementación sigue el mismo enfoque que el repositorio de referencia de temperature scaling publicado junto al paper de Guo et al.: un único parámetro escalar aprendido sobre logits ya calculados, sin tocar los pesos del modelo. Aplicada sobre el bin de 90-100% del experimento con Qwen3-1.7B, una temperatura mayor a 1 debería acercar esa confianza promedio de 98,55% hacia el 70,09% de exactitud real observado.
Verificación: cómo confirmar que la calibración mejoró
No hay una función de una sola llamada que diga “tu modelo está calibrado”: hay que recalcular el ECE después de aplicar la temperatura aprendida y compararlo contra el valor original.
calibrated_logits = raw_logits / learned_temperature
calibrated_probs = torch.softmax(calibrated_logits, dim=-1)
# recalcular confidences y accuracies con calibrated_probs
# y volver a llamar a expected_calibration_error(...)
Si el ECE recalculado baja respecto al original, la calibración funcionó. Si sube o queda igual, el conjunto de validación usado para aprender T es demasiado chico o no representa la distribución real de producción: el código no está mal, el dato de validación sí.
⚠️ Ojo: temperature scaling no cambia qué respuesta elige el modelo, solo qué tan segura dice estar de esa elección. Si la exactitud base es mala, calibrar no la mejora.
Comparativa de métodos de calibración
Temperature scaling no es la única herramienta. La elección correcta depende de cuántas clases tiene el problema, cuántos datos de validación hay disponibles y si la miscalibración es pareja entre clases o concentrada en algunas.
| Método | Cuándo usarlo | Ventaja | Limitación |
|---|---|---|---|
| Temperature scaling | Clasificación multiclase con sobreconfianza uniforme entre clases | Un solo parámetro, rápido de ajustar, no cambia el ranking de predicciones | No corrige si la miscalibración varía mucho entre clases |
| Platt scaling | Clasificación binaria o con pocas clases | Captura relaciones no lineales simples entre logit y probabilidad | Necesita ajustar una regresión logística por clase |
| Isotonic regression | Miscalibración no monótona o con muchos datos de validación | No asume forma funcional, se ajusta a cualquier curva de calibración | Puede sobreajustar con pocos datos de validación |
| Dirichlet calibration | Multiclase con matrices de confusión asimétricas entre clases | Modela interacciones entre clases, no solo la confianza máxima | Más parámetros que ajustar, más datos de validación necesarios |
flowchart TD
A["Logits sin calibrar"] --> B{"Cuantas clases hay?"}
B -->|"Binaria"| C["Platt scaling"]
B -->|"Multiclase"| D{"La miscalibracion es uniforme entre clases?"}
D -->|"Si"| E["Temperature scaling"]
D -->|"No, es asimetrica"| F["Dirichlet calibration"]
D -->|"Hay muchos datos de validacion"| G["Isotonic regression"]
Casos de uso reales
Los decision models como Jev aplican esta misma lógica de clasificación restringida para enrutar tickets de soporte, clasificar sentimiento o elegir entre un conjunto fijo de acciones en un agente. La ventaja frente a generar texto token por token es la velocidad: una sola pasada hacia adelante entrega la respuesta, en vez de las N pasadas que necesita un modelo autoregresivo para producir N tokens de salida.
Pero la velocidad no resuelve la calibración. Un sistema de triage que usa un decision model para decidir “escalar a un humano” o “responder automático” necesita que la confianza reportada sea confiable para fijar el umbral de escalamiento. Si el modelo está sobreconfiado como en el experimento con Qwen3-1.7B, un umbral de “automatizar si la confianza supera 90%” deja pasar sin revisión casi 3 de cada 10 casos que en realidad están mal.
Lo mismo aplica a sistemas de moderación de contenido, scoring de riesgo y cualquier clasificador que alimente una decisión automática aguas abajo. La calibración de confianza no mejora la exactitud del modelo: hace que el número de confianza que ese modelo reporta sirva para algo.
Errores comunes y buenas prácticas
- Usar el mismo set para entrenar y calibrar. La temperatura (o la regresión de Platt) tiene que ajustarse sobre un conjunto de validación separado del de entrenamiento; si no, se mide la calibración sobre datos que el modelo ya memorizó.
- Confundir probabilidad con confianza del siguiente token. El softmax de un LLM autoregresivo mide qué tan seguro está el modelo del próximo token, no necesariamente de que la respuesta final sea correcta. Sin ajuste, esa diferencia infla la confianza reportada.
- Ignorar el tamaño de los bins al calcular ECE. Un bin con 5 ejemplos y otro con 800 pesan distinto en el promedio; reportar el ECE sin mostrar también el histograma de confianza oculta dónde está realmente el problema.
- Recalibrar una sola vez y asumir que ya terminó. La temperatura aprendida en un dataset se degrada si la distribución de entrada cambia (otro dominio, otro idioma, preguntas más difíciles); hay que remedir el ECE periódicamente.
- Tratar el ECE como la única métrica. Un modelo puede tener ECE bajo y seguir siendo inútil si su exactitud base es mala: calibración y exactitud son ejes distintos, hay que mirar los dos.
Profundizando: por qué las redes son sobreconfiadas
El hallazgo central del paper de Guo et al. es que la sobreconfianza no depende de que el modelo sea malo. Depende de cómo se entrena. La función de pérdida estándar, cross-entropy, sigue bajando aunque la red ya clasifique bien, porque todavía puede reducir más la pérdida empujando los logits de la clase correcta cada vez más arriba. Ese empuje extra mejora la pérdida de entrenamiento pero no la exactitud, y el efecto colateral es una distribución de salida cada vez más afilada, es decir, más confiada.
Este fenómeno se agrava con la profundidad. Redes con más capas y más parámetros tienden a sobreajustar la confianza antes de sobreajustar la exactitud, un efecto que los autores del paper documentaron comparando arquitecturas de distinta profundidad sobre los mismos datasets de visión. En modelos de lenguaje el mecanismo es análogo: cuanto más grande y más entrenado el modelo, más afilada su distribución de salida, con o sin relación directa con qué tan seguido acierta.
Hay un matiz importante sobre qué mide exactamente la confianza de un decision model. El artículo que motiva este análisis lo señala con precisión: sin entrenamiento adicional, los puntajes de probabilidad probablemente reflejan la confianza del modelo en cuál será el siguiente token, no la probabilidad real de que la respuesta sea correcta. Son dos cantidades distintas que coinciden solo si el modelo está calibrado, y la mayoría no lo está de fábrica.
La buena noticia es que corregir esto no exige reentrenar. Hacer un fine-tune sobre el propio dataset, como hizo el autor del experimento original, mejora tanto la exactitud (de 59,38% a 62,41%) como, indirectamente, la calibración de clasificadores: un modelo que entiende mejor la tarea tiene menos espacio para estar seguro y equivocado al mismo tiempo. Pero temperature scaling logra una mejora comparable en la calibración pura sin tocar un solo peso del modelo, en minutos en lugar de horas de entrenamiento.
Hay un detalle que conviene no perder de vista: la calibración no es una propiedad estática del modelo, es una propiedad del par modelo más distribución de datos. Un modelo calibrado sobre CommonsenseQA no tiene por qué seguir calibrado sobre un dataset de dominio médico o legal, aunque la arquitectura sea exactamente la misma. Por eso la temperatura aprendida en un entorno de validación hay que volver a medirla cuando cambia el tipo de preguntas que el sistema recibe en producción.
📖 Resumen en Telegram: Ver resumen
Tu próximo paso: tomá las predicciones de un clasificador que ya tengas en producción, calculá su ECE con el script de la sección “Ejemplos prácticos” y compará el resultado contra el umbral de confianza que usás hoy para automatizar decisiones.
Preguntas frecuentes
¿Qué es el ECE (error de calibración esperado)?
Es la métrica que resume, en un solo número, cuánto se aleja la confianza promedio de un modelo de su exactitud real, agrupando las predicciones en bins de confianza y comparando ambos valores en cada bin.
¿Temperature scaling cambia qué respuesta elige el modelo?
No. Solo reescala la confianza reportada: la clase con el logit más alto antes de aplicar la temperatura sigue siendo la clase elegida después. Lo único que cambia es qué tan segura dice estar esa elección.
¿Cuántos bins conviene usar para calcular el ECE?
Entre 10 y 15 es el estándar en la literatura. Con menos datos de validación, usar menos bins evita que cada uno tenga muy pocos ejemplos y el promedio salga ruidoso.
¿La calibración de confianza sirve para modelos generativos, no solo clasificadores?
Sí, pero hay que definir primero qué “respuesta correcta” significa para una tarea abierta. En clasificación restringida, como un decision model, la métrica es directa; en generación libre requiere un criterio de evaluación aparte.
¿Platt scaling y temperature scaling se pueden combinar?
No tiene sentido aplicarlos juntos sobre el mismo logit: cada uno resuelve el mismo problema con un enfoque distinto. Se elige uno según el número de clases y se mide el ECE resultante para confirmar cuál funciona mejor en ese caso.
Referencias
- nishtahir.com: artículo original sobre decision models, decodificación restringida y el experimento de calibración con Qwen3-1.7B en CommonsenseQA.
- arXiv:1706.04599: “On Calibration of Modern Neural Networks” (Guo, Pleiss, Sun y Weinberger, 2017), el paper que formalizó el ECE y temperature scaling.
- github.com/gpleiss/temperature_scaling: implementación de referencia en PyTorch de temperature scaling.
- huggingface.co/docs/transformers: documentación oficial de la librería usada para cargar y correr el modelo Qwen3-1.7B.
- pytorch.org: documentación oficial de la función softmax usada en los ejemplos de código.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
Imagen destacada: Foto de BoliviaInteligente en Unsplash
¿Te sirvió? ¿Te dio otro error? Contalo abajo: las preguntas se responden y le sirven al siguiente que llegue.
Dejar un comentario
0 Comentarios