Resumo Técnico: Calibração, não Compilação

Declaração do Problema

Modelos de Linguagem de Grande Escala (LLMs) são cada vez mais utilizados para redigir programas probabilísticos (ex: em Stan, Pyro, NumPyro). Embora esses programas frequentemente compilem, executem e passem em testes unitários convencionais, eles podem permanecer estatisticamente mal especificados. Erros comuns incluem o uso de uma verossimilhança Gaussiana para dados de cauda pesada, uma distribuição de Poisson para contagens com sobredispersão, suportes de prior inválidos ou parametrizações patológicas (ex: parametrização centrada para funis hierárquicos).

O artigo identifica uma lacuna crítica: a verificação de software padrão (compilação e testes unitários) é cega a esses erros estatísticos. Um programa que "executa e retorna amostras finitas" pode ainda assim produzir uma posterior que é mal calibrada e falha em corresponder aos dados retidos. Os autores denominam isso mal especificações invisíveis ao código. O problema central é que o "oráculo de teste" padrão (o código executa?) fornece zero informação sobre a correção estatística, potencialmente induzindo uma falsa confiança que suprime reparos necessários.

Metodologia

O Oráculo de Calibração

Os autores propõem substituir o oráculo de teste unitário por um Oráculo de Calibração derivado do fluxo de trabalho Bayesiano. Este oráculo agrega quatro famílias de diagnósticos para verificar se um modelo ajustado é estatisticamente correto:

1. Verificações Preditivas Posteriores (PPC): Avalia se o modelo consegue reproduzir estatísticas de dados chave (média, DP, máximo, contagens de zero) via probabilidades de cauda.
2. Calibração Baseada em Simulação (SBC): Verifica se o procedimento de inferência é autoconsistente com a prior do modelo examinando a distribuição de ranking das amostras da prior contra as amostras da posterior.
3. Diagnósticos de Amostrador: Monitora $\hat{R}$ dividido, tamanho de amostra efetivo (ESS) e divergências para detectar parametrizações com geometrias de posterior inacessíveis.
4. Densidade Preditiva de Dados Retidos: Utiliza a densidade logarítmica preditiva em dados retidos como uma regra de pontuação estritamente própria para comparar o modelo contra uma referência.

O oráculo retorna um veredito: o modelo é aceito apenas se passar em todos os limiares (ex: $\hat{R} < 1,05$, baixas divergências, $p$-valores de PPC não próximos de 0 ou 1, e alta densidade de dados retidos).

Configuração Experimental

• Benchmark: Um conjunto de dados de 200 instâncias através de 10 famílias de modelos e 14 tipos de mal especificação. Todas as instâncias compilam e executam.
• Taxonomia de Bugs:
  • Visíveis ao código: Erros detectáveis pela inspeção do código-fonte sob um briefing neutro (ex: ruído ínfimo codificado rigidamente).
  • Invisíveis ao código: Erros onde o código é uma implementação fiel do briefing, mas está errado para os dados específicos (ex: escolha errada de verossimilhança). Este é o foco principal, pois os oráculos de teste falham aqui.
• Loop de Reparo: Um processo iterativo onde um LLM redige um programa, o oráculo o avalia e, se estiver descalibrado, um diagnóstico estruturado (ex: "a dispersão dos dados reside na cauda extrema") é enviado de volta ao LLamento para reparo.
• Modelos: Avaliados através de 15 escritores (Open source: DeepSeek, Qwen, Llama, Phi; API: GPT, Claude, Gemini).

Principais Contribuições

1. Capacidade de Detecção: O oráculo de calibração detecta mal especificação com um AUC de 0,97. Em bugs invisíveis ao código, ele sinaliza erros em 93% dos casos com uma taxa de falso-positivo de 2%, enquanto um oráculo de teste unitário detecta 0%.
2. Operação Sem Referência: O sistema não requer um programa correto escrito à mão. Uma versão sem referência (PPC + amostrador + SBC) detecta 62% dos bugs. Adicionar uma linha de base de GLM clássico eleva isso para 68%, e uma busca de modelo automatizada (LOO sobre uma pequena biblioteca) atinge 78%. O valor de 88% citado no resumo assume uma referência correta conhecida (um limite superior).
3. Eficácia do Reparo: O uso de feedback de calibração supera significativamente tanto o "sem feedback" quanto o "feedback de teste unitário".
   • O feedback de teste unitário é prejudicial: Dizer a um LLM que "todos os testes passaram" suprime o reparo, resultando frequentemente em taxas de correção menores do que fornecer nenhum feedback (ex: Claude: 25% com feedback de teste vs. 75% sem feedback).
   • O feedback de calibração é eficaz: Para modelos fortes, mas não saturados, o feedback de calibração melhora dramaticamente as taxas de correção (ex: GPT-5.1: 33% $\to$ 92%; Claude: 75% $\to$ 100%).
4. Validação no Mundo Real: Em programas escritos do zero para briefings neutros, 15–47% dos programas executáveis estão estatisticamente mal especificados (testes unitários não capturam nenhum). O reparo guiado por calibração supera significativamente as linhas de base, incluindo revisão por LLM-como-juiz, checklists Bayesianas e auto-depuração de resumo de dados.

Resultados

• Detecção: O oráculo é quase perfeito para erros de verossimilhança, problemas de dispersão e zero-inflação. Ele tem dificuldade ligeira com volatilidade estocástica e erros específicos de ligação que preservam momentos de dados.
• Localização: O oráculo pode localizar o tipo de bug com 75% de precisão top-2, distinguindo entre verossimilhanças erradas, más parametrizações e sobredispersão, embora às vezes confunda sobidispersão com conflito prior-dados.
• Capacidade Não-Monotônica: O benefício do feedback de calibração é não-monotônico. É negligenciável para modelos fracos demais para agir sobre diagnósticos e para modelos fortes o suficiente para reparar cegamente. É mais decisivo para modelos "fortes-mas-não-saturados".
• Significância Estatística: Testes de McNemar pareados confirmam que o feedback de calibração é significativamente melhor que o sem feedback ($p=4,4 \times 10^{-3}$) e o feedback de teste unitário ($p=6,5 \times 10^{-7}$). O feedback de teste unitário é significativamente pior que o sem feedback ($p=3,4 \times 10^{-3}$).

Significância e Alegações

O artigo argumenta que, para programas probabilísticos, a correção é calibração, não compilação.

• Mudança de Paradigma: O verificador correto para código probabilístico escrito por LLM é o próprio fluxo de trabalho Bayesiano, não um conjunto de testes.
• Dano Ativo dos Testes: Passar em testes unitários pode enganar ativamente modelos capazes, fazendo-os acreditar que um modelo mal especificado está correto, thereby suprimindo o processo de reparo.
• Impacto Prático: O oráculo de calibração fornece uma base principista e leve em termos de referência para modelagem probabilística confiável assistida por LLM. Ele preenche a lacuna entre geração de código e validade estatística, permitindo que LLMs capazes corrijam erros "invisíveis ao código" que ferramentas tradicionais de engenharia de software não conseguem detectar.

Os autores observam limitações: o oráculo não é um certificado universal (não pode detectar erros estruturais causais se a distribuição preditiva for idêntica, e tem dificuldades com custos de SBC de alta dimensão), mas é um verificador robusto para os erros estatísticos comuns que os LLMs cometem.