23 A IA como Revisora Adversária
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. Quando alguém que revisa lhe entrega uma lista de falhas na sua própria análise, você decide quais falhas são reais, e decide isso rodando a verificação de dados que confirma ou refuta cada uma, nunca indo com quem soou mais seguro. Confiança não é evidência, e um painel de revisores confiantes não é três evidências.
23.1 Por que essa decisão importa
A decisão em jogo: quais das falhas que uma revisão aponta são reais, resolvida por uma verificação que você roda e não pelo quanto quem revisou soou seguro.
Imagine a análise de uma proposta de levar uma mudança de loja para toda a rede. Uma gerente de operações é a pessoa cuja assinatura permite que a sua mudança chegue a todas as lojas, e que responde por ela quando as filas do caixa contam outra história. Exemplo: a gerente que aprovou o seu novo layout de autoatendimento é quem atende as reclamações quando as filas engrossam no primeiro sábado cheio. A preocupação dela é direta.
“Não me diga que os números melhoraram. Me diga qual verificação você rodou que teria pegado o problema se eles não tivessem melhorado. Eu confio na verificação, não no gráfico.”
Uma mensuração confiante, uma crítica fluente de IA e uma tabela de aparência limpa podem estar erradas do mesmo jeito convincente. A gerente está pedindo o que parece menos impressionante e mais importa: a verificação com a qual você se comprometeu antes de olhar, e o alerta que você de fato conferiu contra os dados.
23.2 O conceito
Uma revisora adversária é quem lê o seu resultado com a função de atacá-lo e achar onde ele quebra, não de elogiá-lo. Exemplo: uma colega que tenta mostrar que a melhora que você mensurou foi sorte, e não uma mudança real. Quem revisa pode ser uma pessoa, uma ferramenta de IA ou um painel de modelos, e cada um falha do seu próprio jeito.
Você defende um resultado tentando quebrá-lo primeiro. Uma verificação de robustez repete o mesmo achado sob uma escolha diferente, mas igualmente defensável, e vê se a resposta se mantém. Exemplo: você mensurou a melhora em um único horário do dia, então também a mensura em outras duas faixas de horário realistas. Um teste placebo roda o seu procedimento exato onde o efeito não pode existir e confirma que ele volta perto de zero. Exemplo: você compara dois trechos do layout antigo entre si, e qualquer “melhora” entre eles é a sua mensuração mentindo.
O hábito que mantém um ataque honesto é a ordem. Busca por especificações é tentar muitas versões de uma análise e relatar apenas aquela que deu a resposta que você queria, sem revelar a busca. O nome dela no dia a dia é p-hacking. Exemplo: você mensura dez horários diferentes e mostra só aquele em que a sua mudança vence. A cura é um conjunto de verificações pré-listadas, a lista completa do que você vai rodar, assumida antes de ver qualquer resultado. Exemplo: você anota três faixas de horário e um placebo, depois roda as quatro e relata todos os números, inclusive os que não ajudaram.
Mais uma falha ganha nome porque revisores de IA a cometem o tempo todo. Erro correlacionado é duas revisões erradas do mesmo jeito, de modo que a concordância entre elas é um eco, não uma confirmação. Exemplo: dois modelos de IA compartilham um ponto cego e ambos apontam o mesmo não problema com a mesma confiança.
23.2.1 Uma revisora agêntica continua sem ter voto
Hoje você pode apontar uma ferramenta para a sua análise inteira e deixá-la rodar o próprio loop: ler o seu código, rodá-lo de novo, cutucar variantes e voltar com uma lista ordenada de problemas. Isso é um ganho real em relação a um prompt só, e ela vai achar erros reais que você deixou passar. E não muda nada sobre quem julga. Todo item daquela lista continua sendo uma proposta, e cada um continua precisando do mesmo tratamento: nomeie a verificação, rode a verificação, leia a sua própria saída. A lista é mais longa e mais bem organizada do que costumava ser, o que a torna mais tentadora de aceitar em bloco, então segure a linha com mais firmeza. Quem revisa propõe uma falha, e os dados decidem se ela é real. Confiança, humana ou de máquina, não lhe diz nada sobre a falha existir.
23.3 Um exemplo trabalhado
Sua loja instalou um novo layout de autoatendimento, e os seus dados dizem que as pessoas passaram mais rápido pela fila. Antes de defender isso, você ataca. Primeiro, um termo. O tempo de espera p95 é a espera que 95 de cada 100 clientes conseguem não ultrapassar, um resumo mais justo que a média porque captura as esperas longas de que as pessoas de fato reclamam. Exemplo: um p95 de 210 segundos significa que só os 5 por cento mais lentos esperaram mais que isso. Sua manchete é uma queda de p95 de 210 segundos para 140.
Você entrega o resultado a três revisões adversárias, e cada uma nomeia uma falha fatal diferente. A primeira diz que a vitória é puxada por uma única manhã excepcionalmente vazia. A segunda diz que você escolheu a dedo o único perfil de clientes em que o layout ajuda. A terceira diz que você comparou uma semana com equipe completa contra uma semana com falta de gente, então mensurou pessoal, não layout. As três estão confiantes, e as três discordam.
Você não confia na voz mais alta. Você transforma cada falha em uma verificação. Deixar de fora a manhã vazia e recalcular o p95: ele quase não se move, então a primeira falha está refutada. Sua grade pré-listada de especificações roda a queda de novo em três perfis de clientes, e ela se mantém nos três, então a segunda também está refutada. O placebo compara dois trechos do layout antigo entre si. Uma melhora entre dois trechos idênticos provaria que a terceira revisão estava certa, mas ela volta perto de zero, então a maquinaria está limpa.
Os dois alertas mais barulhentos se dissolveram no instante em que uma verificação os tocou. A falha que sobrevive é uma que nenhuma mensuração adicional remove e que nenhuma das três levantou: isso rodou em uma loja, em dias de semana, não na rede inteira. Então a alegação honesta é limitada. Você mensurou uma melhora de p95 para estes três perfis de clientes nesta loja, não uma garantia para todas as unidades que a sua empresa opera.
23.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 and Attack the Analysis (abrir no Colab), parte do curso companheiro apresentado no apêndice Para instrutores. Você roda de novo uma estimativa ao longo de uma grade pré-listada de oito especificações, vê a busca por especificações fabricar um resultado significativo a partir de puro ruído, roda um placebo e uma verificação de influência deixando um caso de fora, e depois entrega a sua análise a uma pessoa, a uma IA e a um painel de modelos de IA e julga cada alerta que eles levantam contra os dados.
23.5 Prompts de IA recomendados
Comprometa-se com a sua própria leitura do resultado primeiro, e só então deixe alguém atacá-lo. Cada prompt abaixo entrega uma tarefa que você pode conferir, com uma nota de verificação nomeando a falha da qual ele defende.
Faça o red team do resultado (a verificação que ele nomear, quem roda é você).
Act as a hostile operations reviewer, not a cheerleader. Here is a one-paragraph
summary of my wait-time study and its headline claim: [paste your summary]. Name the
single most serious flaw you can find, and state the exact measurement I could run
that would confirm or refute it. Do not rewrite my study and do not list more than
one flaw.Depois de rodar, verifique (contra-ataca a concordância bajuladora): se ela chamar o seu desenho de “sólido” ou oferecer só elogios amenos, insista e peça o pior problema supondo que o resultado seja falso. Uma falha só é real depois que você roda a mensuração nomeada e os seus próprios números confirmam.
Liste as especificações que ficaram de fora (a lista, quem audita é você).
Here is my pre-listed robustness grid for one wait-time result: I vary the customer
mix, the time of day, and whether the store was fully staffed. Name up to three
additional, equally defensible specifications I did NOT list that could move the
result, and for each say which direction you expect it to push.Depois de rodar, verifique (contra-ataca a ilusão de completude): uma grade longa e arrumadinha ainda pode omitir a única configuração que quebra a alegação. Acrescente e rode de novo as sugestões que você consegue de fato operacionalizar, e descarte o resto.
Reduza os alertas do painel (o veredito continua sendo seu).
Three reviewers each named one "most serious flaw" in my analysis: [A], [B], [C].
For each, give the single data check that would confirm or refute it, in one line.
Then tell me which two of the three are most likely the same underlying concern in
different words, and which one is genuinely separate.Depois de rodar, verifique (contra-ataca os erros correlacionados): três revisões ecoando um mesmo ponto cego podem parecer três confirmações. Rode cada verificação contra a sua própria saída antes de acreditar em qualquer alerta, e trate a unanimidade como um candidato a conferir, nunca como a conferência em si.
Estas coisas continuam sendo suas, por mais fluente que quem revisa soe. Quais verificações de robustez você assume antes de olhar, porque uma verificação escolhida depois de ver o resultado não é verificação, é busca. Quais falhas apontadas os seus dados de fato confirmam, decidido pela mensuração e não pela confiança. Se uma falha é um problema de limite da alegação que nenhuma mensuração adicional conserta e que só uma alegação mais estreita resolve. E o único resultado limitado que você vai defender, com a sua incerteza declarada. Quem revisa propõe; você verifica, e a evidência decide.
23.6 Um caso de falha da IA
Você cola o resumo do seu estudo de tempo de espera em uma IA revisora, e ela responde com total certeza: a sua melhora é artefato de uma única manhã excepcionalmente vazia, tire aquela manhã e ela desaparece. A afirmação é específica, mecanicista e enunciada sem nenhuma ressalva. Ela soa exatamente como alguém que já viu esse erro cem vezes.
Aqui está como você pega isso. Você não age sobre o veredito. Você mesmo roda a verificação deixando aquela manhã de fora e recalcula o p95. A melhora quase não se move. A falha confiante foi fabricada, um mecanismo com som de real parafusado em um problema que os seus dados não têm. Confie na certeza e você joga fora um resultado genuíno por causa de um palpite. Apontar a verificação para os seus próprios números foi a única coisa que resolveu.
23.7 Agora é a sua vez
Seu projeto tem uma estimativa, um intervalo em volta dela e um teste negativo por trás. Este passo entrega o conjunto inteiro a quem tem a única função de quebrá-lo, e faz de você quem decide o que quebrou.
- Escreva um resumo de um parágrafo do seu desenho de pesquisa, da sua alegação principal e das verificações que você já rodou. Quem revisa sem saber o que você fez vai inventar falhas que você descartou semana passada.
- Encomende a revisão: peça a falha mais séria, uma só, e a mensuração exata que a confirmaria ou refutaria. Faça isso pelo menos duas vezes, com enquadramentos ou ferramentas diferentes, e trate duas respostas coincidentes como um candidato a conferir, não como duas confirmações.
- Pegue os três pontos mais difíceis que você recebeu. Para cada um, escreva em uma única linha a verificação de dados que o resolveria.
- Rode as três verificações contra os seus próprios dados. Marque cada alerta como confirmado ou refutado pela sua própria saída, nunca pelo quanto quem revisou soou seguro. Guarde o alerta errado mais confiante que você pegou; ele lhe diz algo sobre a ferramenta que você vai usar de novo amanhã.
- Encontre a falha que nenhuma verificação conserta, aquela que é um problema de limite e não de mensuração, e estreite a sua alegação até que a alegação seja verdadeira.
- Registre a revisão e cada alerta julgado 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. O raciocínio revisado por pares pertence a este momento: leve a sua alegação estreitada a uma pessoa e veja se ela sobrevive à primeira pergunta. Uma IA revisora pode rodar a checagem com você; a decisão de aceitar ou rejeitar continua sendo sua.