Resumen Técnico: Calibración, no Compilación

Planteamiento del Problema

Los Modelos de Lenguaje de Gran Escala (LLMs) se utilizan cada vez más para redactar programas probabilísticos (por ejemplo, en Stan, Pyro, NumPyro). Aunque estos programas suelen compilarse, ejecutarse y pasar las pruebas unitarias convencionales, pueden permanecer estadísticamente mal especificados. Los errores comunes incluyen el uso de una verosimilitud gaussiana para datos de cola pesada, una distribución de Poisson para conteos con sobredispersión, soportes de prior inválidos o parametrizaciones patológicas (por ejemplo, parametrización centrada para embudos jerárquicos).

El artículo identifica una brecha crítica: la verificación de software estándar (compilación y pruebas unitarias) es ciega a estos errores estadísticos. Un programa que "se ejecuta y devuelve muestras finitas" puede seguir produciendo un posterior que está mal calibrado y no logra ajustarse a los datos no utilizados para el entrenamiento. Los autores denominan a esto mal especificaciones invisibles al código. El problema central es que el "oráculo de prueba" estándar (¿se ejecuta el código?) no proporciona información alguna sobre la corrección estadística, lo que potencialmente induce una falsa confianza que suprime las reparaciones necesarias.

Metodología

El Oráculo de Calibración

Los autores proponen reemplazar el oráculo de las pruebas unitarias por un Oráculo de Calibración derivado del flujo de trabajo bayesiano. Este oráculo agrega cuatro familias de diagnósticos para verificar si un modelo ajustado es estadísticamente correcto:

1. Chequeos Predictivos Posteriores (PPC): Evalúa si el modelo puede reproducir estadísticas clave de los datos (media, DE, máximo, conteos de ceros) mediante probabilidades de cola.
2. Calibración Basada en Simulación (SBC): Comprueba si el procedimiento de inferencia es consistente consigo mismo con respecto al prior del modelo examinando la distribución de rangos de los dibujos del prior frente a los dibujos del posterior.
3. Diagnósticos del Muestreador: Monitorea el $\hat{R}$ dividido, el tamaño de muestra efectivo (ESS) y las transiciones divergentes para detectar parametrizaciones con geometrías de posterior inalcanzables.
4. Densidad Predictiva de Datos No Utilizados: Utiliza la densidad logarítmica predictiva en datos no utilizados como una regla de puntuación estrictamente propia para comparar el modelo contra una referencia.

El oráculo devuelve un veredicto: el modelo se acepta solo si pasa todos los umbrales (por ejemplo, $\hat{R} < 1.05$, bajas divergencias, valores $p$ de PPC no cercanos a 0 o 1, y alta densidad de datos no utilizados).

Configuración Experimental

• Benchmark: Un conjunto de datos de 200 instancias a través de 10 familias de modelos y 14 tipos de mal especificación. Todas las instancias compilan y se ejecutan.
• Taxonomía de Errores:
  • Visibles al código: Errores detectables inspeccionando el código fuente bajo un breve contexto neutral (por ejemplo, ruido minúsculo codificado a mano).
  • Invisibles al código: Errores donde el código es una implementación fiel de la instrucción pero errónea para los datos específicos (por ejemplo, elección incorrecta de la verosimilitud). Este es el enfoque principal, ya que los oráculos de prueba fallan aquí.
• Bucle de Reparación: Un proceso iterativo donde un LLM redacta un programa, el oráculo lo evalúa y, si no está calibrado, se le entrega al LLM un diagnóstico estructurado (por ejemplo, "la dispersión de los datos se encuentra en la cola extrema") para su reparación.
• Modelos: Evaluados a través de 15 escritores (Código abierto: DeepSeek, Qwen, Llama, Phi; API: GPT, Claude, Gemini).

Contribuciones Clave

1. Capacidad de Detección: El oráculo de calibración detecta la mal especificación con un AUC de 0.97. En errores visibles al código, señala errores en el 93% de los casos con una tasa de falsos positivos del 2%, mientras que un oráculo de pruebas unitarias detecta el 0%.
2. Operación Libre de Referencia: El sistema no requiere un programa correcto escrito a mano. Una versión libre de referencia (PPC + muestreador + SBC) detecta el 62% de los errores. Añadir una línea base de GLM clásica eleva esto al 68%, y una búsqueda de modelos automatizada (LOO sobre una pequeña librería) alcanza el 78%. La cifra del 88% citada en el resumen asume una referencia conocida y correcta (un límite superior).
3. Eficacia de la Reparación: El uso de retroalimentación de calibración supera significativamente tanto al escenario de "sin retroalimentación" como al de "retroalimentación de pruebas unitarias".
   • La retroalimentación de pruebas unitarias es perjudicial: Decirle a un LLM que "todas las pruebas pasan" suprime la reparación, resultando a menudo en tasas de corrección menores que no proporcionar retroalimentación alguna (por ejemplo, Claude: 25% con retroalimentación de pruebas vs. 75% sin retroalimentación).
   • La retroalimentación de calibración es efectiva: Para modelos fuertes pero no saturados, la retroalimentación de calibración mejora drásticamente las tasas de reparación (por ejemplo, GPT-5.1: 33% $\to$ 92%; Claude: 75% $\to$ 100%).
4. Validación en el Mundo Real: En programas escritos desde cero para instrucciones neutrales, del 15 al 47% de los programas ejecutables están estadísticamente mal especificados (las pruebas unitarias no detectan ninguno). La reparación guiada por calibración supera significativamente a las líneas base, incluyendo la revisión de LLM-como-juez, listas de verificación bayesianas y auto-depuración de resumen de datos.

Resultados

• Detección: El oráculo es casi perfecto para errores de verosimilitud, problemas de dispersión y sobre-inflación de ceros. Tiene dificultades leves con la volatilidad estocástica y errores de enlace específicos que preservan los momentos de los datos.
• Localización: El oráculo puede localizar el tipo de error con una precisión top-2 del 75%, distinguiendo entre verosimilitudes incorrectas, malas parametrizaciones y sobredispersión, aunque a veces confunde la sobredispersión con el conflicto entre el prior y los datos.
• Capacidad No Monótona: El beneficio de la retroalimentación de calibración es no monótono. Es insignificante para modelos demasiado débiles para actuar sobre los diagnósticos y para modelos lo suficientemente fuertes como para reparar a ciegas. Es más decisivo para modelos "fuertes pero no saturados".
• Significancia Estadística: Las pruebas de McNemar pareadas confirman que la retroalimentación de calibración es significativamente mejor que la de no retroalimentación ($p=4.4 \times 10^{-3}$) y la de pruebas unitarias ($p=6.5 \times 10^{-7}$). La retroalimentación de pruebas unitarias es significativamente peor que la de no retroalimentación ($p=3.4 \times 10^{-3}$).

Significancia y Reivindicaciones

El artículo argumenta que, para programas probabilísticos, la corrección es la calibración, no la compilación.

• Cambio de Paradigma: El verificador adecuado para el código probabilístico escrito por LLM es el propio flujo de trabajo bayesiano, no una suite de pruebas.
• Daño Activo de las Pruebas: Pasar las pruebas unitarias puede inducir erróneamente a modelos capaces a creer que un modelo mal especificado es correcto, suprimiendo así el proceso de reparación.
• Impacto Práctico: El oráculo de calibración proporciona una base con principios sólidos y ligera en referencias para la modelización probabilística asistida por LLM confiable. Cierra la brecha entre la generación de código y la validez estadística, permitiendo a los LLM capaces corregir errores "invisibles al código" que las herramientas tradicionales de ingeniería de software no pueden detectar.

Los autores señalan las limitaciones: el oráculo no es un certificado universal (no puede detectar errores estructurales causales si la distribución predictiva es idéntica, y tiene dificultades con los costos de SBC en alta dimensión), pero es un verificador robusto para los errores estadísticos comunes que cometen los LLM.