1) O que mudou: “inference-time compute” vira botão

Nos últimos meses, a conversa sobre IA começou a sair do eixo “qual modelo é maior” para o eixo “quanto raciocínio você compra por resposta”. Em termos práticos, isso aparece como:

• Modo rápido vs. modo pensado (resposta imediata vs. raciocínio estendido).
• Controle de orçamento (“pense até N tokens” / “baixo, médio, alto esforço”).
• Transparência (parcial) do raciocínio: alguns produtos exibem tokens de “pensamento” como uma prévia/experimento.

O Claude 3.7 Sonnet posiciona isso explicitamente como um “hybrid reasoning model”: o mesmo modelo pode responder na hora ou dedicar um orçamento de “pensamento” maior quando a tarefa exige (e quando você aceita pagar por isso). Já o OpenAI o3‑mini leva a mesma ideia para um modelo pequeno de raciocínio, com níveis de reasoning effort selecionáveis.

2) Por que isso está acontecendo agora

Há três pressões convergindo:

2.1) Agentes e automações “gastam” mais inferência

Quando você usa IA como agente (planejar → chamar ferramenta → verificar → corrigir → tentar de novo), o custo deixa de ser “uma resposta” e vira uma trajetória. Nessa lógica, “pensar mais” pode reduzir retrabalho e, paradoxalmente, economizar custo total — se for aplicado só quando necessário.

2.2) Token ficou mais barato — mas a conta total cresce

Mesmo com queda de preço por token, fluxos mais longos (ferramentas, múltiplas tentativas, checagens) empurram o gasto para cima. Por isso o controle explícito de esforço/orçamento começa a ser visto como uma funcionalidade de primeira linha.

2.3) Benchmarks e produtos começaram a refletir “test-time compute”

Uma ideia que circula na pesquisa como test-time compute (processamento extra na inferência) está virando opção de UI e parâmetro de API. Em vez de um “modelo novo” para cada nível de raciocínio, surge o mesmo modelo com “modos”.

3) Benchmarks citados (com números e fontes)

Quando números aparecem, vale olhar qual setup foi usado (scaffolding, número de tentativas, orçamento de tokens, etc.). Abaixo, um recorte do que as próprias fontes publicaram.

3.1) Claude 3.7 Sonnet (exemplos)

• SWE‑Bench Verified: segundo o resumo do The Batch (deeplearning.ai), Claude 3.7 Sonnet teria atingido 70,3% (média de 16 tentativas) “sem extended thinking”, enquanto o o3‑mini aparece com 49,3% em “high effort”. (fonte)
• GPQA Diamond: o mesmo resumo cita 84,8% para Claude 3.7 Sonnet em modo de pensamento paralelo com orçamento de 64k tokens, e 79,7% para o3‑mini em high effort. (fonte)
• AIME 2024: o The Batch aponta 80,0% para Claude 3.7 Sonnet (pensamento paralelo, 64k tokens) e 87,3% para o3‑mini em high effort. (fonte)
• τ‑Bench (TAU‑bench): o The Batch cita, por exemplo, 81,2% no subset Retail (sem extended thinking) e 58,4% no subset Airline, ambos acima de o1 nas comparações listadas. (fonte)

3.2) OpenAI o3‑mini (exemplos)

• O post de lançamento ressalta que o3‑mini oferece níveis de reasoning effort (low/medium/high) e dá números de avaliação humana: 56% de preferência vs. o1‑mini e 39% de redução em “major errors” em questões difíceis. (fonte)
• Também cita ganhos de latência em A/B: 24% mais rápido que o1‑mini (média 7,7s vs. 10,16s) e “~2500ms” a menos até o primeiro token. (fonte)
• Para SWE‑Bench Verified, a OpenAI direciona o leitor ao system card como fonte de verdade (incluindo detalhes de subset e scaffolds). (fonte)

Leitura crítica: números de benchmark ajudam a comparar, mas para decisão de produto (especialmente em empresa) o que mais importa é: qual tarefa real, qual latência aceitável, qual limite de custo, qual taxa de erro tolerável.

4) O impacto de produto: custo, latência e previsibilidade

Quando o “pensamento” vira parâmetro, você ganha uma alavanca nova para desenhar sistemas com IA:

• Roteamento por dificuldade: tarefas simples em modo rápido; tarefas críticas com orçamento maior (ou com múltiplas tentativas).
• Orçamento por etapa: planejamento com alto esforço; execução de passos rotineiros com baixo esforço; verificação com esforço médio.
• SLAs mais claros: em vez de “às vezes erra”, você mede: “com esforço X, erro cai para Y e custo sobe Z”.
• Observabilidade: quando há “thinking tokens”/modo estendido, você passa a monitorar também consumo de raciocínio (não só tokens de saída).

O risco óbvio: overthinking (gastar muito para ganhar pouco). O risco menos óbvio: “underthinking” em etapas críticas — e aí o sistema parece barato, mas vira caro no retrabalho humano.

5) O que isso significa na prática

Se você quer aplicar esse movimento já (sem depender de “ficar na moda”), aqui vai um plano simples:

5.1) Transforme “pensar mais” em uma política explícita

• Defina 3 perfis: rápido (FAQ, classificação), normal (texto e análise leve), crítico (código, finanças, decisões com impacto).
• Para o perfil crítico, adote pelo menos uma salvaguarda: verificação automática, segunda opinião ou teste (em código, rodar testes; em texto, checar fontes).

5.2) Comece por um caso de uso que “pague a conta”

Exemplos que se beneficiam de orçamento de raciocínio:

• Agente de suporte com ferramentas: consulta base interna + ações (cancelar, reemitir, localizar pedido).
• Assistente de engenharia: localizar arquivos, propor patch e rodar testes (SWE‑bench é exatamente essa direção).
• Backoffice: conciliação e auditoria (onde erros custam caro, mas volume é grande).

5.3) Meça o que importa (e não só “qual modelo é melhor”)

• Custo por tarefa concluída (não por resposta).
• Tempo até conclusão (latência fim‑a‑fim, incluindo retries).
• Taxa de retrabalho humano (quantas vezes alguém precisou consertar).

6) Fique de olho amanhã

• Padronização: “orçamento de pensamento” tende a virar um parâmetro comum entre provedores, como hoje é temperatura/top_p.
• Benchmarks mais realistas: crescerá a pressão por avaliações que simulem fluxos com ferramentas, políticas, limites e checagem (não só Q&A).
• Segurança: system cards e relatórios de risco vão ganhar espaço — especialmente quando agentes têm permissão de executar ações (editar, pagar, publicar).
• UX: veremos mais produtos expondo “modo rápido/preciso” para usuário final (não só para dev).

7) Próximo passo

Se você curte acompanhar IA sem hype e com fonte, assine a newsletter (MailPoet) para receber o post diário e favorite o blog para voltar amanhã.