¿Se puede confiar en las probabilidades?
Esta página responde a una pregunta: ¿se puede confiar en esas cifras de confianza?
La conclusión por adelantado: «la forma de la salida está garantizada» y «la probabilidad es exacta» son dos afirmaciones completamente distintas. La primera se ha verificado desde varias direcciones. La segunda se discute en público. Quien ponga un modelo de decisiones detrás de una compuerta de producción debería tratar la confianza reportada por el proveedor o el proyecto como un prior que hay que calibrar, no como una garantía.
Qué es la calibración
Un modelo dice «estoy seguro al 80%». Si reúnes todo lo que dijo al 80% y exactamente el 80% de eso acierta, el número está calibrado. Si acierta menos, es demasiado confiado.
La métrica habitual es ECE (Expected Calibration Error): agrupa las predicciones por confianza, compara la confianza media de cada grupo con su precisión real y toma la media ponderada por el tamaño del grupo. Más bajo es mejor.
La calibración y la precisión son ejes independientes. Un modelo muy preciso puede ser malamente demasiado confiado (sobre todo en la parte más difícil), y un modelo mediocre puede estar bien calibrado. Verás ambos casos a continuación.
Solución 1: escalado de temperatura
La solución más barata y más general. La idea: el orden de las opciones del modelo suele ser correcto, pero la escala es incorrecta — el exceso de confianza hace que todo quede demasiado cerca de 0 y de 1. Un único parámetro de temperatura, ajustado sobre un conjunto de reserva, aplana o agudiza la distribución.
Una réplica que incluye una evaluación offline ejecutable reporta:
El escalado de temperatura más la abstención conformal llevan la ECE de 0.170 a 0.071 (validado de forma cruzada).
Fíjate en «validado de forma cruzada»: no se ajustó y se evaluó sobre los mismos datos. Esa es la diferencia entre un número en el que vale la pena confiar y uno que no.
Solución 2: abstención conformal
El escalado de temperatura corrige la escala. Los métodos conformales deciden cuándo no responder.
En lugar de hacer que todas las probabilidades sean correctas, producen un conjunto de abstención y garantizan que la respuesta verdadera cae dentro de él al menos una fracción declarada de las veces (una garantía de cobertura). Los casos que no superan el listón se escalan en vez de procesarse automáticamente.
En proyectos reales:
- Una alternativa abierta de 118M usa escalado de temperatura más un conjunto de abstención split-conformal y reporta ECE 0.01–0.03 en suites públicas — a la vez que afirma sin rodeos que en los benchmarks de decisiones con tipo pierde frente a Laya (0.71 vs 0.77). Un proyecto que publica sus derrotas es más informativo que uno que solo publica sus victorias.
- Una implementación médica usa dos lectores locales congelados más un enrutador sin ajuste y un conjunto de candidatos split-conformal para acotar el error, quedando a menos de 2 puntos del servicio alojado en tres exámenes nacionales de licencia de 600 ítems, sin ajuste fino ni destilación.
Lo que ambos tienen en común: ninguno afirma que las probabilidades se volvieran exactas. Afirman saber cuándo no lo son. En un sistema real, puedes poner la compuerta sobre lo segundo.
Un resultado independiente contraintuitivo: el sesgo tiene signos opuestos
Una prueba de calibración independiente usó 900 tickets generados por reglas (que el modelo no puede haber visto) más tres benchmarks públicos, publicó cada respuesta en bruto y una ECE contra un suelo de ruido simulado, y llegó a una conclusión sobre el signo:
| Primitiva | Dirección del sesgo |
|---|---|
Choice |
sistemáticamente demasiado confiado |
Score |
sistemáticamente demasiado confiado |
Boolean (Noul) |
sistemáticamente poco confiado |
El valor está en el signo. Si el sesgo fuera aleatorio, un único escalado de temperatura global lo corregiría. Direcciones opuestas significan que una única corrección global no puede — como mínimo necesitas calibrar por primitiva.
También explica un fallo de diseño concreto: si un sistema compara las confianzas de Noul
y Choice contra el mismo umbral, está midiendo lo mismo con una regla demasiado corta y
otra demasiado larga.
El idioma de entrada también afecta a la calibración
Otra medición, sobre un corpus en español de 3,200 ítems etiquetados por humanos:
Escribir el estado en español costó de 3.0 a 6.4 puntos de precisión y aproximadamente duplicó la ECE en XNLI / PAWS-X, mientras que escribir las instrucciones en español no tuvo efecto.
La distinción entre estado e instrucción es el punto: el estado es contenido, las instrucciones son metadatos. Esto importa sobre todo a los lectores chinos y japoneses — es muy probable que sus estados sigan un camino parecido, y nadie ha publicado una medición de ello. No hay razón para suponer que no esté ocurriendo en tu idioma.
Entonces, ¿cómo se elige el umbral?
Todo lo anterior desemboca en la misma pregunta: ¿de dónde salió ese 0.8?
La respuesta reproducible es medir, no adivinar: toma tus propios datos etiquetados, ajusta el umbral por pregunta que alcanza tu precisión objetivo y valídalo sobre un conjunto de reserva.
Una herramienta hace exactamente eso y añade el paso que más importa: falla la CI cuando una actualización del modelo rompe un umbral bloqueado. Los umbrales caducan como los precios — salvo que un precio equivocado se nota y un umbral equivocado no.
En una frase
Trata la confianza como un prior, no como una garantía. Mide primero la banda fiable sobre tus propios datos y luego escribe esa banda en el código.