Podemos confiar nas probabilidades?

Esta página responde a uma pergunta: é possível confiar naqueles valores de confiança?

A conclusão à cabeça: «a forma da saída está garantida» e «a probabilidade é exata» são duas afirmações completamente diferentes. A primeira foi verificada a partir de várias direções. A segunda está a ser contestada em público. Quem puser um modelo de decisão atrás de uma barreira de produção deve tratar a confiança reportada pelo fornecedor ou pelo projeto como um prior a calibrar, não como uma garantia.

O que é a calibração

Um modelo diz «tenho 80% de certeza». Se reúnes tudo o que ele disse com 80% e exatamente 80% dessas coisas estiverem certas, o número está calibrado. Se estiverem certas menos do que isso, é demasiado confiante.

A métrica habitual é o ECE (Expected Calibration Error): agrupa as previsões por confiança, compara a confiança média de cada grupo com a sua exatidão real e tira a média ponderada pelo tamanho do grupo. Mais baixo é melhor.

Calibração e exatidão são eixos independentes. Um modelo muito exato pode ser gravemente demasiado confiante (sobretudo na fatia mais difícil), e um modelo medíocre pode estar bem calibrado. Vais ver ambos à frente.

Correção 1: temperature scaling

A correção mais barata e mais geral. A ideia: a ordenação das opções pelo modelo costuma estar certa, mas a escala está errada — o excesso de confiança significa que tudo fica demasiado perto de 0 e de 1. Um único parâmetro de temperatura, ajustado num conjunto de validação, achata ou aguça a distribuição.

Uma réplica que inclui uma avaliação offline executável reporta:

O temperature scaling mais a abstenção conformal levam o ECE de 0.170 para 0.071 (validado de forma cruzada).

Repara em «validado de forma cruzada»: não foi ajustado e avaliado nos mesmos dados. É essa a diferença entre um número em que vale a pena confiar e um que não.

Correção 2: abstenção conformal

O temperature scaling corrige a escala. Os métodos conformais decidem quando não responder.

Em vez de tornarem cada probabilidade correta, produzem um conjunto de abstenção e garantem que a resposta verdadeira cai dentro dele pelo menos uma fração declarada das vezes (uma garantia de cobertura). Os casos que não passam o critério são escalados em vez de processados automaticamente.

Em projetos reais:

• Uma alternativa aberta de 118M usa temperature scaling mais um conjunto de abstenção split-conformal e reporta ECE 0.01–0.03 em suites públicas — ao mesmo tempo que diz claramente que, em benchmarks de decisões tipadas, perde para o Laya (0.71 vs 0.77). Um projeto que publica as suas derrotas é mais informativo do que um que só publica vitórias.
• Uma implementação médica usa dois leitores locais congelados, mais um encaminhador sem ajuste e um conjunto de candidatos split-conformal para limitar o erro, ficando a 2 pontos do serviço alojado em três exames nacionais de licenciatura de 600 itens, sem ajuste fino nem destilação.

O que ambos têm em comum: nenhum afirma que as probabilidades passaram a ser exatas. Afirmam saber quando não são. Num sistema real, é isso que podes usar como barreira.

Um resultado independente contra-intuitivo: o enviesamento tem sinais opostos

Um teste de calibração independente usou 900 tickets gerados por regras (que o modelo não pode ter visto) mais três benchmarks públicos, publicou todas as respostas em bruto e um ECE contra um nível de ruído simulado, e chegou a uma conclusão sobre o sinal:

O valor está no sinal. Se o enviesamento fosse aleatório, uma temperatura global corrigia-o. Direções opostas significam que uma única correção global não consegue — precisas de calibrar por primitiva, no mínimo.

Também explica uma falha de conceção concreta: se um sistema compara confianças de Noul e Choice com o mesmo limiar, está a medir a mesma coisa com uma régua demasiado curta e outra demasiado comprida.

A língua de entrada também afeta a calibração

Outra medição, num corpus espanhol de 3,200 itens anotados por humanos:

Escrever o estado em espanhol custou 3.0–6.4 pontos de exatidão e cerca de duplicou o ECE em XNLI / PAWS-X, enquanto escrever as instructions em espanhol não teve efeito.

A distinção estado/instructions é o ponto: o estado é conteúdo, as instructions são metadados. Isto importa sobretudo para leitores de chinês e japonês — os seus estados muito provavelmente seguirão um caminho semelhante, e ninguém publicou uma medição disso. Não há razão para assumir que não está a acontecer na tua língua.

Então como se escolhe o limiar?

Tudo o que está acima desagua na mesma pergunta: de onde veio aquele 0.8?

A resposta reproduzível é mede, não adivinhes: pega nos teus próprios dados anotados, ajusta o limiar por pergunta que atinge a tua exatidão-alvo e valida-o num conjunto de validação.

Uma ferramenta faz exatamente isso e acrescenta o passo que mais importa: falha a CI quando uma atualização do modelo quebra um limiar bloqueado. Os limiares expiram como os preços — só que um preço errado é notado e um limiar errado não.

Numa frase

Trata a confiança como um prior, não como uma garantia. Mede primeiro a faixa fiável nos teus próprios dados e depois escreve essa faixa no código.