A promessa tentadora (e o buraco nela)

Olha só o pitch: rodar o experimento num modelo em vez de em usuários, ter resultado em horas em vez de semanas, e ainda por cima pular a alocação de tráfego. Parece velocidade de graça, né?

Só que a maioria das propostas esquece a pergunta estatística que torna um experimento válido: sob quais condições esse procedimento identifica o efeito de tratamento que você realmente quer medir?

Experimentos randomizados são o padrão-ouro porque identificam efeito causal por design. Troque respostas reais de usuários por previsões de LLM e essa garantia some. A identificação passa a valer por premissa — e ninguém está explicitando quais premissas são essas.

Um paper recente formaliza exatamente isso, emprestando a teoria de surrogate endpoints da bioestatística. A lógica é limpa: se um desfecho substituto captura tudo sobre o tratamento que importa para o desfecho real, então experimentar no substituto te dá a resposta certa. Ensaios clínicos fazem isso com biomarcadores de laboratório o tempo todo. A pergunta é se previsões de LLM qualificam como biomarcador válido para comportamento de usuário. Dá uma olhada na pesquisa original pra ver a formalização completa.

Data analyst comparing LLM-predicted click-through rates against human A/B test outcomes on a dashboard Development Concept Image

A realidade empírica: previsões cruas são enviesadas, não só ruidosas

O time testou isso no Upworthy Research Archive — o maior dataset aberto de testes A/B disponível, com CTRs de milhares de variações de manchetes. Eles pediram pro gpt-4o-mini prever o CTR de cada manchete, separadamente para tratamento e controle, e rodaram uma análise experimental padrão.

Resultado: as previsões cruas recuperaram só 39% do efeito de tratamento humano observado.

# Ilustração simplificada do problema de atenuação
# (não é código de reprodução, é só pra fixar o conceito)

import numpy as np
from sklearn.ensemble import RandomForestRegressor
from sklearn.linear_model import LinearRegression

# y_human: CTR real dos usuários, y_llm: CTR previsto pelo LLM
tau_human = y_human_treated.mean() - y_human_control.mean()
tau_llm_raw = y_llm_treated.mean() - y_llm_control.mean()

print(f"ATE humano:       {tau_human:.4f}")
print(f"ATE LLM cru:      {tau_llm_raw:.4f}")
print(f"Taxa de recuperação: {tau_llm_raw / tau_human:.2%}")  # ~39%

# Calibração OLS: rígida demais, falhou no teste de falsificação
ols = LinearRegression().fit(y_llm_train.reshape(-1, 1), y_human_train)

# Calibração com ML não-linear: ficou dentro do erro amostral
rf = RandomForestRegressor(n_estimators=500).fit(X_train, y_human_train)

O viés é sistemático e direcional: os desfechos do LLM atenuam o efeito em direção ao zero. Os tratamentos parecem mais fracos do que são. Escala isso pra uma organização inteira e você subestima sistematicamente o valor do que entrega — e toma decisões de lançamento erradas.

As duas premissas que fazem funcionar

  1. Surrogacy — a saída do LLM precisa mediar completamente o efeito do tratamento no desfecho humano. Depois de condicionar na previsão do LLM e nas covariáveis de baseline, a atribuição de tratamento não te diz mais nada sobre o comportamento do usuário. Em bom português: o LLM captura tudo sobre o tratamento que importa.
  2. Comparabilidade — a função de calibração (o mapeamento de previsão do LLM para desfecho humano) precisa ser estável entre os dados históricos de treino e o novo experimento. Se esse mapeamento muda quando o tratamento muda, a calibração quebra.

Quando as duas valem, calibrar as saídas do LLM contra dados reais de A/B recupera o efeito humano. Quando alguma falha, você não está estimando o efeito humano — está estimando o efeito no LLM. Amostra infinita de LLM não te salva, porque o procedimento está identificando outra quantidade.

O método de calibração importa mais do que você imagina

  • Calibração linear OLS: falhou no teste de falsificação, ficando 3,8 erros-padrão longe do benchmark humano. Rígida demais pro mapeamento não-linear LLM→humano.
  • Random forest / gradient-boosted trees: flexíveis o suficiente pra aprender a não-linearidade; as estimativas calibradas ficaram dentro do erro amostral do efeito humano.
  • Ruído da temperatura de amostragem: uma única previsão do LLM é ruidosa. Tirar várias saídas por unidade e usar a média (teoria de erro de medição) reduz atenuação e variância.

Developer prompting GPT-4o-mini to predict headline CTR variants for a surrogate A/B testing pipeline Coding Session Visual

Onde isso quebra: o problema do tratamento futuro

Aqui está o núcleo desconfortável: surrogacy e comparabilidade podem ser parcialmente checadas em dados históricos, mas nunca provadas para um tratamento que você nunca rodou.

Quanto mais um novo tratamento se afasta dos experimentos passados — um paradigma de UI diferente, um modelo de precificação novo, uma feature que não se parece com nada já lançado — mais fraca é a base pra confiar nas saídas do LLM. Para intervenções genuinamente novas, as premissas são inerentemente não-testáveis.

O que leva ao punchline: o LLM oferece o maior benefício exatamente onde é menos provável que funcione. Experimentos humanos continuam indispensáveis pra inovação real de produto.

Um alerta sobre o próprio caso de teste

O dataset Upworthy é quase um cenário ideal: desfecho binário, tratamentos textuais e linguisticamente similares, e LLMs treinados em oceanos de texto sobre o que faz uma manchete ser clicável. Mude o layout, o algoritmo ou o preço, e as condições ficam muito mais difíceis de justificar. Não existe evidência empírica de que as premissas valham em geral no portfólio de inovação de uma empresa — que é exatamente o que "usar em escala" exigiria.

Os dados que você queria evitar

Calibração precisa de experimentos históricos com usuários reais. A maioria dos times de produto não tem milhares de experimentos limpos e homogêneos — tem uma mistura bagunçada entre superfícies, com logging inconsistente. O framework não elimina experimentos com usuários; ele permite reduzir a quantidade só quando os novos experimentos se parecem com os antigos. O investimento inicial em respostas reais de usuários não é opcional — é o que torna tudo confiável.

E o churn de versão de LLM adiciona outra camada: uma função de calibração ajustada a um modelo específico num momento específico pode ser inválida seis meses depois. Nova calibração idealmente precisa de novos experimentos com usuários, ou fica enviesada temporalmente. LLMs melhores, prompting melhor ou fine-tuning não removem a necessidade de validação humana.

Se você curte ver onde métricas substitutas já deram certo em produção, o estudo de caso da Netflix que cortou CPU de recomendação de 7,5% para 1% com a JDK Vector API é uma boa leitura complementar sobre medir ganhos reais com rigor.

Server cluster running calibration models that map LLM predictions to real user treatment effects Algorithm Concept Visual

A lição final

Previsões de LLM podem deixar experimentos humanos melhores — filtrando ideias fracas antes de consumirem um slot de experimento, ou servindo como covariáveis pra redução de variância. Isso é ganho real quando você tem histórico forte e o novo tratamento se parece com os passados.

Substituí-las pelos desfechos humanos é outra jogada completamente diferente. É trocar identificação por design por identificação por premissa. Não abra mão disso de graça.

Limitações pra manter no radar:

  • As premissas são não-verificáveis para tratamentos novos — justamente o caso de maior valor.
  • A calibração é específica da versão do modelo e decai com o tempo.
  • Previsões cruas atenuam efeitos em direção ao zero; uso ingênuo subestima features sistematicamente.

Próximos passos se quiser explorar isso:

  1. Estude teoria de surrogate endpoints em bioestatística — é a espinha dorsal rigorosa aqui.
  2. Comece usando previsões de LLM como pré-filtro pra priorização de experimentos, não como substituto do experimento.
  3. Audite seu corpus histórico de experimentos quanto à homogeneidade antes de assumir que a calibração vai transferir.

Mudanças de segurança e plataforma também podem invalidar premissas da noite pro dia — se você roda infra React, vale conferir o guia da vulnerabilidade crítica RCE em React Server Components antes do próximo ciclo de experimentos.

Este conteúdo foi elaborado com o auxílio de ferramentas de IA, com base em fontes confiáveis, e revisado pela nossa equipe editorial antes da publicação. Não substitui o aconselhamento de um profissional especializado.