Girar o Botão de Raciocínio no Máximo Piorou a IA

2.080 combinações de modelo e esforço foram rodadas contra dois casos reais de vulnerabilidade de segurança, e 70,8% delas encontraram alguma parte da falha. Apenas 1,9% produziram uma solução completa. Essa dispersão é o primeiro aviso. O segundo é mais afiado: neste experimento, girar o botão de raciocínio para cima não tornou as respostas confiavelmente melhores. Parsia, engenheiro de segurança na Microsoft, rodou o teste e publicou os números. Uma frase resume o resultado melhor do que qualquer gráfico: “parece que mais esforço de raciocínio (e até modelos mais novos) nem sempre são melhores para triar resultados de segurança.”

O instinto na maioria das equipes é o oposto. Quando uma resposta de IA parece frágil, force mais o modelo. Suba o esforço de raciocínio, escolha a versão mais nova, dê mais espaço para ele pensar. Este é um experimento bem documentado, não um benchmark da indústria, mas ele coloca um número em algo que a maioria das equipes presume sem testar: o botão nem sempre gira na direção que você espera.

O botão é não monotônico

O dado mais claro é um confronto direto entre dois níveis de esforço da mesma família de modelos. O gpt-5.5 em esforço médio marcou 0,360. O mesmo modelo em esforço extra-alto marcou 0,327. Mais raciocínio, resultado pior, mesma tarefa. Não é uma oscilação de arredondamento, é uma reversão.

Um botão monotônico significaria que todo aumento de esforço compra ao menos um pouco mais de qualidade. Este aqui dobra. Passado um pico, o raciocínio adicional nesta tarefa começou a custar precisão em vez de adicionar. O modelo, com mais espaço para pensar, se convenceu de respostas piores em alguns casos. Qualquer um que já viu um colega capaz complicar uma decisão simples reconhece o formato.

A consequência operacional é direta. Se você padronizou “esforço máximo, modelo mais novo” como sua configuração de segurança, pode estar pagando mais por um ajuste que pontua mais baixo no trabalho com que você de fato se importa. A única forma de saber é medir sua tarefa em vários níveis de esforço, e não presumir que o topo do botão é o lado seguro.

Escopo moveu o ponteiro mais do que esforço

A maior variação de todo o conjunto de dados não veio do esforço de raciocínio. Veio de como o problema foi enquadrado.

Quando a análise foi restrita a uma única função, os resultados superaram a análise de arquivo inteiro em até 31,7% em uma configuração (gpt-5.4 em esforço extra-alto). Mesmo modelo, mesmo esforço, mesma vulnerabilidade. A única mudança foi o tamanho da janela sobre a qual o modelo tinha de raciocinar. Restrinja à função relevante e a precisão subiu. Entregue o arquivo inteiro e o modelo teve mais onde se perder.

Os números por caso reforçam o ponto. Na vulnerabilidade openbsd-sack, a análise de arquivo inteiro ficou em 1,7% entre todos os modelos. No caso freebsd-nfs, a análise de arquivo inteiro chegou a 90,8%. O enquadramento da tarefa dominou o resultado muito mais do que a escolha de modelo ou de nível de esforço. Um escopo ruim afundou todos os modelos. Um escopo bom manteve a maioria deles à tona.

Essa é a alavanca que as equipes subutilizam. Esforço de raciocínio é um botão no modelo. Escopo é uma decisão que você controla. Você decide se o agente vê uma função ou dez mil linhas. Neste experimento, essa decisão valeu mais do que qualquer ajuste no próprio modelo.

Um conselho vence uma única execução confiante

Se um modelo no esforço máximo não é confiável, trocar por outro modelo único também não resolve. O que resolve é estrutura em torno dos modelos.

Parsia montou um conselho de triagem de LLMs: vários modelos votando em cada achado, em vez de um modelo decidindo sozinho. O conselho chegou a 86,2% de unanimidade, com apenas 2,8% dos casos sem nenhuma maioria. O restante ficou no meio, marcado como genuinamente contestado. Esse é o sinal que você quer. Quando o conselho concorda, você tem corroboração de execuções independentes. Quando ele se divide, você tem uma marca dizendo “um humano deveria olhar aqui”, o que é mais honesto do que a resposta errada e confiante de um modelo único.

Isso se conecta a um padrão sobre o qual já escrevemos, o desacoplamento entre competência de output e verificação. Um modelo pode produzir um output fluente, confiante e errado, e fluência não é evidência. Um conselho não conserta nenhum modelo isolado. Ele torna a discordância visível, e discordância visível é uma primitiva de verificação. Um modelo seguro de si não te dá nada para auditar. Cinco modelos, três deles em dissidência, te dão um mapa exato de onde o trabalho está frágil.

Esforço também elevou a taxa de recusa

Há um custo em forçar o esforço que não tem nada a ver com precisão. As recusas subiram com ele.

No topo da escala, o claude-4.7-1m em esforço extra-alto atingiu 21% de recusa por filtragem de conteúdo neste trabalho de triagem de segurança. A tarefa era análise legítima de vulnerabilidades, o tipo que um engenheiro de segurança faz todo dia. Mais esforço de raciocínio se correlacionou com mais casos em que o modelo se recusou a responder. Suba o botão e um quinto do seu trabalho pode voltar como recusa, não como resultado.

O gasto conta a própria história. O experimento completo custou cerca de US$ 9.200, e o Claude rodou de três a quatro vezes mais caro do que o GPT via Copilot. Ou seja, a configuração de esforço alto no modelo mais caro comprou, em alguns pontos, tanto uma taxa de recusa mais alta quanto uma pontuação de precisão mais baixa. Esse é o oposto da intuição de que mais é mais seguro. Nesta tarefa, mais foi, às vezes, mais lento, mais caro e menos útil de uma vez só.

Essa é a armadilha de especificidade de domínio que sinalizamos no imposto da expertise de domínio. O ajuste certo se descobre por tarefa, por modelo, por escopo. Carregar um padrão global entre tarefas é onde o erro mora.

Faça isto agora

Escolha uma tarefa de IA que seu time roda no piloto automático em “esforço máximo, modelo mais novo”. Triagem de segurança, revisão de código, análise de contrato, qualquer tarefa em que você confia no topo do botão porque parece seguro.

Primeiro, rode em três níveis de esforço, não em um. Médio, alto, extra-alto, sobre os mesmos insumos, e pontue as saídas contra um pequeno conjunto de casos em que você já sabe a resposta certa. Se o médio empata ou vence o extra-alto, você vinha pagando mais por um resultado pior. A reversão neste experimento não era exótica; era uma família de modelos padrão em dois ajustes vizinhos.

Segundo, teste dois escopos. Rode a mesma tarefa uma vez sobre o recorte estreito e relevante e uma vez sobre o documento inteiro. A variação de 31,7% nesses dados veio só do escopo. Se estreitar a janela elevar sua precisão, o controle de escopo entra no seu pipeline antes de qualquer upgrade de modelo.

Terceiro, monte um conselho de dois ou três modelos nas suas decisões de maior risco. Você não precisa de um orçamento de pesquisa. Rode o mesmo prompt pelos modelos que você já paga, compare as saídas e encaminhe toda discordância para um humano. A taxa de concordância é seu sinal de confiança. As discordâncias são sua fila de auditoria. Essa estrutura, e não uma execução única maior, é de onde vem a confiança. A mesma lição vale quando agentes burlam a própria verificação: a resposta mora na estrutura em volta do modelo, no conselho e na fila de auditoria que você monta por fora dele.

Fontes

Parsia. “Brain the Size of a Planet: Are LLMs Thonking Too Hard?.” Junho de 2026.

A Victorino ajuda equipes a construir estrutura de verificação em torno do output de IA, em vez de confiar em uma única execução do modelo: contato@victorino.com.br | www.victorino.com.br