21 Robustez e Sensibilidade
Este capítulo faz parte de um livro em desenvolvimento ativo e ainda não passou pela revisão do autor. O conteúdo pode mudar conforme a revisão avança.
A decisão de pesquisa. Você decide a lista completa de verificações de robustez e de sensibilidade que vai rodar, e decide isso antes de olhar um único resultado, e depois relata todas elas. Mesmo código, mesma tabela, integridade oposta: a única coisa que separa um achado defensável de uma fatia de sorte é a ordem entre olhar e decidir.
21.1 Por que essa decisão importa
A decisão em jogo: quais versões alternativas da sua análise você se compromete a rodar e a relatar, escolhidas antes de ver qualquer resposta.
“Todo mundo me mostra a versão da análise que deu certo. Presumo que ela exista. Minha pergunta de verdade é o que aconteceu com todas as versões razoáveis que você poderia ter rodado no lugar, e se você olhou para elas antes ou depois de ver esta resposta.” — um parecerista de periódico, abrindo a primeira leitura séria que o seu trabalho vai receber
Esse parecerista não está acusando você de trapaça. Ele está apontando um fato simples sobre análise. Quase toda estimativa real depende de escolhas que você poderia ter feito de outro jeito, e qualquer escolha isolada pode favorecer o resultado. Se você relata só a versão que deu certo, entregou um número sem nenhuma forma de distinguir uma verdade delicada de uma fatia de sorte. Este capítulo lhe dá o hábito que responde à pergunta antes de ela ser feita.
21.2 O conceito
Uma estimativa não é um número só. É um número que depende de várias escolhas, e quem critica ataca as escolhas. Então você as ataca primeiro. Dois ataques com nome próprio fazem esse trabalho, e as pessoas os confundem o tempo todo.
Uma verificação de robustez é repetir o mesmo achado sob uma escolha diferente, mas igualmente defensável, para ver se a resposta permanece. Exemplo: você relatou um valor médio do pedido, então também o calcula depois de remover a única conta que se revelou um comprador atacadista, e confirma que a história se mantém. Uma verificação de sensibilidade, que alguns campos chamam de análise de sensibilidade, é mudar de propósito uma suposição para ver o quanto a resposta se move. Exemplo: você supôs que o sistema de checkout registrava toda compra, então pergunta o quanto o seu resultado mudaria se ele deixasse passar em silêncio dois por cento delas.
Os dois ataques miram no mesmo alvo, a estimativa principal: o número único que representa o seu achado inteiro. Você a ataca a partir de quatro alavancas, e qualquer plano honesto gira uma ou mais delas. A amostra é quais dados você mantém. A mensuração é como você transforma um conceito em número. A especificação é o pacote de escolhas de modelagem por trás da estimativa. A métrica é a régua que você relata.
Girar todas as alavancas de uma vez e plotar os resultados produz uma curva de especificações: uma imagem de uma estimativa sob muitas escolhas defensáveis lado a lado. Se a curva inteira fica de um mesmo lado do zero, a sua direção é robusta. A dispersão dela é o seu intervalo honesto.
O perigo tem nome. A busca por especificações, cujo nome do dia a dia é p-hacking, é rodar muitas análises e relatar apenas aquela que deu o resultado que você queria, sem revelar a busca. O oposto dela são as verificações pré-listadas: escrever cada verificação que você vai rodar, e comprometer-se a relatar todas elas, antes de ver qualquer resultado.
Essa distinção está sob uma pressão nova, e vale saber por quê. Trabalhar com uma assistente de IA significa trabalhar em um loop de IA, o ciclo prompt → resposta → interrogação → refinamento → nova execução, com ferramentas agênticas hoje girando esses ciclos sozinhas. Cada volta do loop pode mudar um filtro, uma variável ou um modelo, o que significa que cada volta é uma nova especificação. Vinte voltas são vinte análises. Se você ficou repetindo o prompt porque o número era decepcionante, você rodou uma busca por especificações, e a ferramenta não guardou registro nenhum disso por você. Mantenha o seu próprio registro dos ciclos, e o seu plano pré-listado sobrevive ao contato com o loop.
21.3 Um exemplo trabalhado
Sua equipe testa se um novo desconto de fidelidade eleva o valor médio do pedido, o valor médio que uma pessoa gasta por compra. Sua manchete: quem recebeu a oferta do desconto gasta cerca de doze por cento a mais do que quem não recebeu. Antes de defender esse número, você o ataca pelas quatro alavancas.
- Amostra. Todas as pessoas compradoras, ou todas menos a única conta que se revelou um comprador atacadista fazendo pedidos em grande volume pelo site de varejo, o que é uma exclusão legítima pela sua definição de cliente, não uma exclusão de conveniência.
- Mensuração. O valor do pedido lido como o total cobrado, ou lido sem frete e impostos.
- Especificação. O gasto calculado sobre todo mundo que recebeu a oferta, ou calculado só sobre quem de fato fez um pedido.
- Métrica. O ganho em dólares, ou o ganho em porcentagem.
Você pré-lista as dezesseis combinações, roda todas e plota a curva de especificações. Todas voltam positivas: o desconto ajuda não importa qual escolha defensável você faça. A magnitude vai de cerca de mais oito por cento a mais quinze por cento. Então a manchete honesta não é “doze por cento”. É “gasto maior em todas as especificações que rodamos, entre cerca de oito e quinze por cento”.
Depois você roda mais um ataque, um teste placebo: divide quem recebeu a mesma oferta em grupos falsos “A” e “B” e confirma que a diferença entre eles fica perto de zero. Se pessoas idênticas mostrassem uma diferença, seria a sua mensuração, e não o desconto, fabricando o resultado.
21.4 O laboratório no Colab
Este capítulo tem o seu próprio notebook companheiro — abra-o no Colab pelo selo acima. O notebook reúne os prompts e o código do capítulo e termina com o espaço de trabalho Agora é a sua vez, para você completar a etapa do capítulo no seu projeto sem sair do Colab. O laboratório completo de sala de aula por trás deste capítulo é o notebook do curso nb10 — Share the research + attack the analysis (abrir no Colab), parte do curso companheiro apresentado no apêndice Para instrutores. Lá você roda de novo uma diferença principal ao longo de uma grade pré-listada e lê a curva de especificações dela, vê a busca por especificações fabricar um resultado “significativo” a partir de dados sem efeito nenhum, e roda um teste placebo e uma verificação de influência deixando um caso de fora por vez, em código com semente fixa, para sentir a diferença entre um achado robusto e um frágil.
21.5 Prompts de IA recomendados
Comprometa-se com a sua própria resposta primeiro, depois delegue. Cada prompt é uma tarefa conferível, não um pedido de veredito.
Localize as verificações padrão.
Act as a methods assistant for a two-group comparison of average customer spending.
Before any code, name the standard families of robustness and sensitivity checks for
this design and the four things I can vary to stress the estimate. Cite a real methods
reference you are confident exists; if you are unsure a source is real, say so.Depois de rodar, verifique: abra a referência e confirme que as verificações e a fonte existem. Contra-ataca a fabricação confiante (um método ou uma citação inventada chega com a mesma confiança de um real).
Delegue, com uma lista para verificar.
Here is my pre-listed robustness grid for one estimate: I vary the sample (all
shoppers / drop the wholesale account), the measurement (total charged / shipping and
taxes stripped out), the specification (averaged over everyone offered / averaged over
buyers only), and the metric (dollars / percent). Name up to three additional, equally
defensible specifications I did NOT list, and for each say which direction you expect
it to push the estimate.Depois de rodar, verifique: confronte cada sugestão com as quatro alavancas e acrescente apenas as que você consegue de fato rodar nos seus próprios dados. Contra-ataca a ilusão de completude (uma grade arrumadinha que omite em silêncio a única escolha capaz de quebrar a alegação).
Faça o red team do seu intervalo.
Here is my claim: "higher spending in every specification we ran, by roughly 8 to 15
percent." Act as a hostile reviewer of a retail pricing study. Name the single worst
way this could be specification searching rather than robustness, and the one check
that would expose it. Do not rewrite the claim for me.Depois de rodar, verifique: rode nos seus próprios dados a checagem que ela nomear; a falha só é real se os seus números confirmarem. Contra-ataca a concordância bajuladora (elogio que revisa o seu ego, não a sua evidência).
Três decisões continuam sendo suas. Você decide quais verificações você assume antes de olhar, quais problemas apontados os dados de fato confirmam e a alegação final que você defende, com o seu intervalo e o seu limite. Uma pessoa ou uma IA que revisa propõe. Você verifica contra os seus próprios dados, e a evidência decide.
21.6 Um caso de falha da IA
Você cola a sua grade de quatro alavancas e pede a uma IA que escreva a sua seção de robustez. Volta um texto longo e bem organizado que roda a alavanca da amostra, a da especificação e a da métrica, e fecha com “o resultado de doze por cento é robusto em todas as especificações padrão”. Ele soa minucioso e completo. A armadilha é que ele nunca listou a alavanca da mensuração, o total cobrado contra o valor sem frete e impostos, e essa é justamente a escolha que mais move a sua estimativa. A seção parece exaustiva enquanto omite a primeira verificação que um parecerista procuraria.
Você pega isso porque pré-listou as quatro alavancas você mesmo, antes de abrir a ferramenta. Lendo a seção dela contra a sua própria lista, você percebe que a mensuração está faltando, roda essa comparação e vê a estimativa escorregar para a ponta baixa do seu intervalo. Um texto que parece completo não é a mesma coisa que um texto completo. Você confere a lista dela contra a sua, não contra o quanto ela soa acabada.
21.7 Agora é a sua vez
Seu projeto tem uma análise que você rodou com uma assistente e um número principal que você mesmo refez. Este passo tenta quebrar esse número antes que um parecerista tenha a chance.
- Escreva a sua estimativa principal em uma frase. Depois liste as quatro alavancas dela: a amostra que você manteve, a mensuração que escolheu, a especificação que ajustou e a métrica que relata. Para cada uma, nomeie uma alternativa que você defenderia tão bem quanto a que escolheu.
- Pré-liste as verificações que você vai rodar, pelo menos duas, mirando nas alavancas que um leitor hostil atacaria primeiro. Escreva-as antes de rodar qualquer uma delas e comprometa-se desde já a relatar todas, dê no que der.
- Rode cada verificação da sua lista. Relate o achado como uma direção mais um intervalo, do tipo “positivo nas quatro versões, entre oito e quinze por cento”, em vez do número mais simpático.
- Acrescente um placebo: construa grupos que você sabe serem idênticos, rode a mesma análise neles e confirme que a diferença fica perto de zero. Se não ficar, é a sua maquinaria que está produzindo o efeito.
- Releia o seu registro de ciclos com a IA e marque todo novo prompt que veio logo depois de um número decepcionante. Toda versão que você de fato rodou pertence ao relatório, inclusive as que não lhe ajudaram.
- Registre o plano pré-listado e os resultados completos dele no seu AI Research Ledger (registro de pesquisa com IA), e verifique pelo menos uma saída com um método nomeado do Guia de Verificação. Uma caça ao contraexemplo combina com uma alegação de robustez: tente honestamente construir uma especificação defensável que inverta o sinal e, se encontrar, essa especificação entra no seu relatório. Uma IA revisora pode rodar a checagem com você; a decisão de aceitar ou rejeitar continua sendo sua.