Reprodutibilidade e Significância Estatística
Por que reprodutibilidade e significância estatística importam em IA
Resultados modernos de inteligência artificial (artificial intelligence, AI) frequentemente são ruidosos: duas execuções de treinamento do “mesmo” modelo podem produzir desfechos diferentes, e pequenos ganhos em conjuntos de referência podem desaparecer sob condições de avaliação ligeiramente distintas. Sem quantificar a incerteza, é fácil confundir variação aleatória com progresso — especialmente em Rankings (Leaderboards) competitivos, onde muitas equipes testam muitas ideias e apenas o melhor número “aparente” é reportado.
Este artigo cobre:
- Variância (variance): de onde vem a variabilidade de desempenho (sementes, divisões de dados, estocasticidade de avaliação, anotadores etc.)
- Intervalos de confiança (confidence intervals, CIs): como associar incerteza a uma métrica
- Significância estatística (statistical significance): como comparar sistemas sem se enganar
- Melhorias relevantes (meaningful improvements): por que “estatisticamente significativo” não é o mesmo que “vale a pena implantar”
Essas ideias se aplicam tanto a benchmarks clássicos de aprendizado de máquina (machine learning, ML) quanto à avaliação moderna de modelos de linguagem grandes (large language models, LLMs) (incluindo LLM como Juiz (LLM-as-Judge) e Avaliação Humana (Human Evaluation)).
Conceitos-chave e vocabulário
Reprodutibilidade: repetibilidade vs replicabilidade
As pessoas usam “reprodutibilidade” de forma inconsistente. Uma decomposição útil:
- Repetibilidade (repeatability): mesmo código, mesmos dados, mesmo hardware/software → mesmo resultado (ou extremamente próximo).
- Replicabilidade (replicability): nova execução independente (possivelmente com hardware diferente ou reimplementação) → conclusões consistentes.
- Robustez (robustness): conclusões se mantêm sob mudanças razoáveis (novos recortes de dados, diferentes instruções (prompts), diferentes sementes, mudança de distribuição). Veja Avaliação Robusta (Robust Evaluation).
Na prática, a pesquisa em aprendizado de máquina costuma ter mais dificuldade com repetibilidade (por causa do não determinismo) e robustez (porque benchmarks são proxies estreitos; veja Lei de Goodhart em Métricas (Goodhart’s Law in Metrics)).
Significância estatística vs significância prática
- Significância estatística pergunta: A diferença observada é improvável sob a suposição de “nenhuma diferença”?
- Significância prática (practical significance) pergunta: A diferença é grande o bastante para importar (custo, latência, segurança, valor para o usuário)?
Uma melhoria minúscula, ainda que estatisticamente significativa, pode continuar sendo irrelevante.
Intervalos de confiança
Um intervalo de confiança é uma faixa que deve conter a métrica verdadeira (sob suposições de amostragem repetida) com uma frequência declarada (por exemplo, 95%). Em aprendizado de máquina, intervalos de confiança são tipicamente usados para quantificar a incerteza devido a conjuntos de teste finitos e/ou à aleatoriedade entre execuções.
De onde vem a variância na avaliação em aprendizado de máquina
Variância não é uma coisa só. Fontes comuns incluem:
1) Estocasticidade de treinamento (training stochasticity)
Mesmo com dados fixos:
- Inicialização aleatória
- Ordem dos dados / embaralhamento
- Descarte aleatório de unidades (dropout), camadas estocásticas
- Kernels de GPU não determinísticos (non-deterministic GPU kernels)
- Diferenças numéricas de precisão mista (mixed precision)
Isso é especialmente relevante para redes profundas treinadas com métodos do tipo Descida do Gradiente (Gradient Descent).
2) Amostragem de dados e divisões
O desempenho difere entre:
- Diferentes divisões de treino/validação/teste
- Diferentes conjuntos de teste extraídos da mesma população
- Diferentes balanços de classes ou misturas de dificuldade
Isso motiva Construção de Benchmarks (Benchmark Construction) cuidadosa e protocolos claros de Avaliação Offline (Offline Evaluation).
3) Seleção de hiperparâmetros e de modelos (“graus de liberdade do pesquisador”)
Se você tenta 50 configurações e reporta a melhor, o número reportado fica enviesado de forma otimista. Isso é uma forma de testes múltiplos e viés de seleção (às vezes chamado de “maldição do vencedor” (winner’s curse)).
4) Estocasticidade de avaliação (evaluation stochasticity) (comum com modelos de linguagem grandes)
Para tarefas com modelos de linguagem grandes, a variabilidade pode vir de:
- Temperatura/top-p de amostragem
- Diferenças de formatação de instruções
- Não determinismo de ferramentas/API
- Não determinismo do modelo juiz em LLM como Juiz
- Discordância entre avaliadores em Avaliação Humana
5) Vazamento e contaminação de dados
Se o modelo já viu os itens de teste (diretamente ou via quase-duplicatas), estimativas de variância e incerteza podem se tornar sem sentido porque o benchmark deixa de refletir generalização. Veja Contaminação do Conjunto de Teste (Test Set Contamination).
Reprodutibilidade na prática: o que controlar e o que reportar
Determinismo é um espectro
Frequentemente não dá para obter determinismo perfeito, mas é possível reduzir variabilidade evitável:
- Fixe sementes aleatórias (seeds) (Python, NumPy, PyTorch/JAX/TensorFlow, workers do dataloader)
- Registre o ambiente: versões de bibliotecas, versões de CUDA/cuDNN, tipo de GPU, flags de compilação
- Use kernels determinísticos (deterministic kernels) quando viável (pode reduzir a velocidade)
- Registre todos os hiperparâmetros e arquivos de configuração
- Salve artefatos (artifacts): checkpoints do modelo, curvas de treinamento, saídas de avaliação
- Versione dados e instruções (incluindo scripts de pré-processamento)
Para avaliações de aplicações com modelos de linguagem grandes (por exemplo, geração aumentada por recuperação (retrieval-augmented generation, RAG)), armazene:
- Documentos recuperados (ou semente de recuperação/versão do índice)
- Instruções, mensagens de sistema, esquemas de ferramentas
- Versão e parâmetros da API do modelo (temperatura, max tokens)
Prefira pipelines de avaliação reprodutíveis
Mesmo que o treinamento seja ruidoso, a avaliação deve ser estável:
- Torne a avaliação puramente funcional (purely functional): mesmas entradas → mesmas saídas
- Armazene em cache as saídas do modelo para itens de teste (especialmente ao usar APIs pagas)
- Evite “correções pontuais” manuais que não estejam roteirizadas
Isso se encaixa naturalmente com práticas fortes de Avaliação Offline.
Quantificando incerteza com intervalos de confiança
Uma única pontuação de teste (por exemplo, acurácia = 82,1%) esconde incerteza. Em geral, você quer uma estimativa pontual (point estimate) mais um intervalo.
Erro-padrão e intervalos de confiança (intuição rápida)
Para uma métrica estimada a partir de uma amostra finita, a variabilidade escala aproximadamente assim:
- Conjuntos de teste maiores → menor incerteza
- Tarefas de maior variância → maior incerteza
Para métricas simples como acurácia em amostras i.i.d. (independentes e identicamente distribuídas; i.i.d.), a incerteza aproximada pode ser derivada analiticamente (binomial). Mas muitas métricas de aprendizado de máquina (F1, BLEU, ROUGE, taxa de vitória a partir de julgamentos pareados) não são bem atendidas por fórmulas fechadas.
Intervalos de confiança por reamostragem bootstrap (bootstrapping) (amplamente aplicáveis)
A reamostragem bootstrap estima a incerteza reamostrando o conjunto de teste com reposição e recomputando a métrica muitas vezes.
Prós:
- Funciona para muitas métricas (acurácia, F1, ROUGE, pontuação média)
- Fácil de implementar
- Dá suporte natural a comparações pareadas (paired) (importante!)
Contras:
- Assume que itens de teste são aproximadamente independentes
- Pode ser enganoso com forte agrupamento (por exemplo, muitas amostras por usuário/tópico)
Exemplo: IC por bootstrap para acurácia (e para diferenças pareadas)
import numpy as np
def bootstrap_ci(metric_fn, y_true, y_pred, n_boot=2000, alpha=0.05, rng=0):
rng = np.random.default_rng(rng)
n = len(y_true)
stats = []
for _ in range(n_boot):
idx = rng.integers(0, n, size=n) # sample with replacement
stats.append(metric_fn(y_true[idx], y_pred[idx]))
stats = np.array(stats)
lo = np.quantile(stats, alpha/2)
hi = np.quantile(stats, 1 - alpha/2)
return float(np.mean(stats)), (float(lo), float(hi))
def accuracy(y_true, y_pred):
return np.mean(y_true == y_pred)
# Paired bootstrap for A vs B: compute CI of (metric_A - metric_B)
def paired_bootstrap_diff_ci(metric_fn, y_true, pred_a, pred_b, n_boot=2000, alpha=0.05, rng=0):
rng = np.random.default_rng(rng)
n = len(y_true)
diffs = []
for _ in range(n_boot):
idx = rng.integers(0, n, size=n)
diffs.append(metric_fn(y_true[idx], pred_a[idx]) - metric_fn(y_true[idx], pred_b[idx]))
diffs = np.array(diffs)
lo = np.quantile(diffs, alpha/2)
hi = np.quantile(diffs, 1 - alpha/2)
return float(np.mean(diffs)), (float(lo), float(hi))
Por que o bootstrap pareado importa: se dois modelos são avaliados nos mesmos itens de teste, seus erros são correlacionados. Um método pareado compara resultados por item e, tipicamente, produz incerteza mais estreita e mais correta do que tratar pontuações como independentes.
Intervalos de confiança ao longo de sementes aleatórias (variância de treinamento)
Em aprendizado profundo (deep learning), uma grande fonte de incerteza é a variação entre execuções. Uma abordagem comum:
- Treinar a mesma configuração com K sementes
- Avaliar cada execução
- Reportar a média e um intervalo de confiança ao longo das sementes
Se K é pequeno (por exemplo, 3–10), frequentemente se usa um intervalo t (t-interval), mas interprete-o com cautela: sementes não são realmente amostras i.i.d. extraídas de uma população conhecida; ainda assim, isso é melhor do que reportar uma única melhor execução.
Exemplo pragmático de reporte:
- “Acurácia média em 5 sementes: 82,1 ± 0,4 (IC de 95% sobre sementes)”
- Mais: “IC por bootstrap no conjunto de teste para a melhor semente: …” (opcional, mas deixe claro qual incerteza você está quantificando)
Atenção: IC do conjunto de teste ≠ IC de implantação
Um intervalo de confiança calculado em um conjunto de teste de benchmark captura incerteza sobre a distribuição daquele benchmark e ruído de amostra finita. Ele não captura automaticamente:
- Mudança de distribuição (veja Avaliação Robusta)
- Heterogeneidade de usuários
- Deriva temporal
- Casos extremos de segurança (veja Avaliação de Segurança (Safety Evaluation))
Significância estatística para comparações de modelos
Testes de significância formalizam se uma diferença observada provavelmente se deve ao acaso sob alguma hipótese nula (null hypothesis). Os detalhes importam: usar o teste errado pode gerar valores de p (p-values) enganosos.
Sempre prefira testes pareados ao comparar modelos
Se o modelo A e o modelo B são avaliados nos mesmos exemplos, use um teste pareado. Isso controla a dificuldade por exemplo.
Configurações pareadas típicas:
- Classificação: acerto por exemplo (0/1)
- Regressão: erro por exemplo
- Julgamentos com modelos de linguagem grandes: vitória/derrota/empate por item
Testes comuns na avaliação em aprendizado de máquina
1) Teste de McNemar (McNemar’s test) (acurácia de classificação pareada)
Para dois classificadores nos mesmos exemplos, o teste de McNemar olha para discordâncias:
- b: A correto, B errado
- c: A errado, B correto
Se b e c diferem muito, A e B diferem de forma significativa.
Use quando:
- Desfecho binário por exemplo (correto/incorreto)
- Mesmo conjunto de teste
Ressalva:
- Ele testa diferença nas taxas de erro, não em outras métricas (por exemplo, F1).
2) Teste t pareado (paired t-test) / teste de postos sinalizados de Wilcoxon (Wilcoxon signed-rank) (diferenças contínuas por exemplo)
Se você tem valores por exemplo como log-loss ou erro quadrático, calcule diferenças por exemplo e teste se a diferença média é diferente de zero.
- Teste t pareado assume que diferenças são aproximadamente simétricas/normais (frequentemente OK com amostras suficientes).
- Wilcoxon signed-rank é não paramétrico e robusto, mas testa uma propriedade tipo mediana.
3) Testes de permutação (permutation tests) (padrão forte)
Um teste de permutação pareado é uma abordagem robusta, com poucas suposições:
- Calcule a diferença por exemplo em pontuação (ou acerto) entre A e B
- Sob a hipótese nula, trocar rótulos A/B por exemplo não deveria mudar a distribuição
- Troque rótulos aleatoriamente muitas vezes para obter um valor de p
Testes de permutação são amplamente aplicáveis e funcionam bem quando você consegue computar uma contribuição por exemplo.
Exemplo: teste de permutação pareado para diferença média
import numpy as np
def paired_permutation_test(diffs, n_perm=20000, rng=0):
"""
diffs: array of per-example (A - B) values, e.g., correctness_A - correctness_B
Returns two-sided p-value for mean(diffs) != 0.
"""
rng = np.random.default_rng(rng)
obs = np.mean(diffs)
count = 0
for _ in range(n_perm):
signs = rng.choice([-1, 1], size=len(diffs))
perm_stat = np.mean(signs * diffs)
if abs(perm_stat) >= abs(obs):
count += 1
return (count + 1) / (n_perm + 1)
Interpretando valores de p corretamente (e armadilhas comuns)
- Um valor de p não é “a probabilidade de a hipótese nula ser verdadeira”.
- Significância estatística não implica que o efeito é grande ou útil.
- Se você testa muitas hipóteses (muitos datasets, instruções, sementes, ablações), você obterá resultados “significativos” por acaso.
Isso é especialmente importante em iteração estilo leaderboard, onde avaliações repetidas podem transformar o conjunto de teste em um conjunto de validação implícito (um primo do overfitting e da Contaminação do Conjunto de Teste).
Comparações múltiplas e falsas descobertas
Se você compara muitos modelos ou variantes, ajuste para testes múltiplos:
- Bonferroni: muito conservador (controla erro familiar (family-wise error))
- Benjamini–Hochberg (FDR): controla a taxa de descobertas falsas esperada (false discovery rate, FDR); frequentemente mais prático em exploração de pesquisa
Um modelo mental simples: se você olhou 100 variantes, uma única “vitória” com p=0,04 não é evidência convincente a menos que você corrija pela seleção.
Melhorias relevantes: além de “p < 0,05”
Tamanhos de efeito e relevância para decisão
Em vez de focar apenas em significância, reporte e raciocine sobre:
- Melhoria absoluta (por exemplo, +0,7 ponto percentual de acurácia)
- Melhoria relativa (por exemplo, -5% na taxa de erro)
- Melhoria ajustada por custo (latência, memória, energia, requisitos de dados)
- Trocas de segurança/qualidade (veja Avaliação de Segurança)
Por exemplo, um ganho de +0,2% em acurácia pode ser relevante em ranking de anúncios em escala massiva, mas sem significado (ou não valer a complexidade adicional) em uma pequena ferramenta interna.
Efeito mínimo detectável e poder estatístico (power) (quanta evidência você precisa)
Poder estatístico é a probabilidade de seu teste detectar um efeito real de um certo tamanho. Avaliações com baixo poder produzem conclusões frágeis.
Orientação prática:
- Se conjuntos de teste são pequenos ou ruidosos, planeje conjuntos de avaliação maiores ou desenhos pareados mais fortes.
- Para variância entre sementes, considere mais sementes quando as diferenças forem pequenas.
- Para julgamentos humanos/modelos de linguagem grandes, aumente o número de itens avaliados e de avaliadores/juízes quando os tamanhos de efeito forem sutis.
Intervalos de confiança como ferramenta de decisão
Um padrão útil:
- Reporte a diferença (A − B) com um intervalo de confiança
- Decida com base em o intervalo:
- excluir 0 (evidência de melhoria)
- ser estreito o bastante para que até o pior ganho plausível seja aceitável
Exemplo de interpretação:
- “A − B = +0,6 ROUGE-L (IC 95%: +0,1 a +1,1)” sugere uma melhoria provável, porém modesta.
- “A − B = +0,6 (IC 95%: −0,4 a +1,6)” sugere que a incerteza é alta demais para alegar progresso.
Exemplos práticos em cenários comuns de avaliação em IA
Exemplo 1: Um novo classificador supera o baseline em 0,3%
Suponha:
- Acurácia do baseline: 90,1%
- Novo modelo: 90,4%
- Conjunto de teste: 5.000 exemplos
Perguntas a fazer:
- A melhoria é consistente entre classes/recortes? (métricas agregadas podem esconder regressões)
- A diferença é estatisticamente significativa sob um teste pareado (por exemplo, McNemar/permutação)?
- Ela é praticamente significativa (custo de implantação, latência, manutenibilidade)?
Frequentemente, a resposta correta é reportar:
- Intervalo de confiança da diferença pareada (bootstrap/permutação)
- Detalhamento por recortes (se pré-registrado ou claramente rotulado como exploratório)
- Sensibilidade a sementes (se a estocasticidade de treinamento for relevante)
Exemplo 2: Mudança de instrução de modelo de linguagem grande melhora taxa de vitória em julgamentos pareados
Você compara duas instruções em 1.000 tarefas com um juiz baseado em modelo de linguagem grande:
- Instrução A vence: 530
- Instrução B vence: 450
- Empates: 20
Você pode:
- Reportar taxa de vitória com um intervalo de confiança (por exemplo, bootstrap sobre itens)
- Usar um teste do sinal (sign test) (vitórias vs derrotas, ignorando empates) ou uma abordagem de permutação pareada
- Verificar a estabilidade do juiz (modelo juiz diferente, parâmetros de decodificação diferentes), porque LLM como Juiz introduz sua própria variância e viés
Pergunte também se a melhoria se mantém quando avaliada de ponta a ponta na sua aplicação (veja Avaliação de Aplicativos com LLM (LLM App Evaluation)).
Exemplo 3: Reporte “melhor de N” ao longo de sementes
Se você treina 10 sementes e reporta a melhor pontuação de teste, você infla resultados. Opções melhores:
- Pré-definir uma regra de seleção usando apenas validação, e então avaliar uma única vez no teste
- Reportar média ± IC ao longo das sementes
- Ou reportar tanto melhor quanto média, claramente rotulados, e evitar usar o conjunto de teste para seleção
Este é um problema recorrente em Rankings.
Armadilhas comuns e como evitá-las
Armadilha: usar o conjunto de teste como conjunto de ajuste
Avaliar repetidamente no benchmark durante o desenvolvimento leva a overfitting ao benchmark, mesmo sem vazamento explícito. Mitigações:
- Manter um conjunto realmente separado (held-out)
- Limitar avaliações no teste
- Usar avaliação às cegas quando possível
- Veja Avaliação Offline e Contaminação do Conjunto de Teste
Armadilha: ignorar a estrutura de dependência
Exemplos podem ser correlacionados:
- Múltiplas amostras do mesmo usuário, documento ou conversa
- Séries temporais ou dados agrupados
Bootstrap ingênuo ou testes assumem independência; considere bootstrap por conglomerados (clustered bootstrap) (reamostrar por grupo) ou avaliar no nível do grupo.
Armadilha: reportar apenas valores de p
Sempre inclua:
- Tamanho de efeito (diferença)
- Intervalo de confiança
- Protocolo exato de avaliação e tamanho de amostra
Armadilha: escolher métricas ou recortes a dedo
Se você escolhe a métrica depois de ver resultados, seus valores de p e intervalos de confiança não refletem o processo de seleção. Se você precisar explorar:
- Rotule análises claramente como exploratórias
- Confirme em um conjunto novo ou via acompanhamento pré-registrado
Armadilha: pipelines de avaliação não determinísticos
Mesmo que o treinamento seja estocástico, a avaliação não deve “se mover”. Armazene saídas em cache, fixe instruções, fixe versões de dependências e registre tudo o que for necessário para reproduzir a avaliação.
Checklist recomendado de reporte (modelo prático)
Ao publicar ou compartilhar resultados, inclua:
Dados e protocolo
- Dataset/versão, divisões, pré-processamento
- Definição exata da métrica de avaliação (tokenização, normalização, tratamento de empates)
- Número de itens de teste; estrutura de agrupamento (se houver)
Modelo e treinamento
- Arquitetura, contagem de parâmetros, computação de treinamento
- Hiperparâmetros, detalhes do otimizador
- Número de sementes; procedimento de seleção (melhor/média/escolhido na validação)
Incerteza
- Método de intervalo de confiança (bootstrap, intervalo t sobre sementes, permutação)
- Se o intervalo é sobre itens de teste, sementes, ou ambos
- Comparação pareada vs não pareada
Significância (se usada)
- Qual teste, bicaudal (two-sided) vs unicaudal (one-sided)
- Correção para comparações múltiplas se muitas variantes foram testadas
Impacto prático
- Mudanças de latência/custo
- Regressões por recortes e verificações de robustez (com link para Avaliação Robusta quando relevante)
- Implicações de segurança (com link para Avaliação de Segurança)
Como isso se encaixa no panorama mais amplo de avaliação
Reprodutibilidade e significância estatística são ferramentas fundamentais, mas não resolvem tudo:
- Um ganho em benchmark estatisticamente sólido ainda pode ser uma armadilha de métrica proxy (veja Lei de Goodhart em Métricas).
- Um resultado offline limpo pode não se traduzir em valor real para o usuário (veja Avaliação de Aplicativos com LLM).
- Julgamentos humanos e baseados em modelos de linguagem grandes introduzem variabilidade e viés adicionais que precisam ser medidos e submetidos a testes de estresse (veja Avaliação Humana e LLM como Juiz).
Trate a estimativa de incerteza e a metodologia reprodutível como o padrão: elas ajudam a garantir que, quando você afirma uma melhoria, você está medindo sinal e não ruído.