Desafios

Além do scaling: os novos espaços de otimização para o progresso da IA

Por Marc Molas·26 de maio de 2026·9 min de leitura

Na Parte 1 cobrimos por que scaling já não é um eixo confiável de progresso. Na Parte 2 percorremos as quatro alavancas que impulsionam a taxa real de retorno por unidade de compute. O fechamento natural da série — e a parte do ensaio de Sara Hooker que achei mais energizante — é a pergunta: para onde o campo deveria ir agora?

A resposta de Hooker é que estamos entrando numa era de espaços de otimização expandidos. Cientistas da computação costumavam ter uma grande alavanca (treinar um modelo maior com mais dados) e isso era ao mesmo tempo libertador e limitante. A nova paisagem nos dá um conjunto muito mais amplo de coisas para otimizar, e muitas delas estão dramaticamente subexploradas. Vamos passar pelas que ela destaca, depois tratar de duas clarificações importantes que ela faz no fim.

1. Exploração livre de gradiente: compute em tempo de inferência como alavanca de primeira classe

Nos últimos 30 anos, a forma de tornar um modelo melhor foi atualizar seus parâmetros. Mais treino, mais dados, mais pesos. A virada acontecendo agora é que muito compute está sendo gasto no tempo de inferência, não no tempo de treino — e, crucialmente, boa parte é livre de gradiente, ou seja, o próprio modelo não muda.

Hooker agrupa essa família de técnicas como os novos espaços de otimização "compute leve" e "livres de gradiente" (a Figura 5 dela os separa explicitamente):

Best-of-N sampling. Amostre múltiplas completions, pontue-as, retorne a melhor.
Busca e planejamento sobre gerações. Tree search, variantes de beam search, loops agênticos que exploram alternativas.
Uso de ferramentas. Um modelo que pode chamar uma calculadora, um banco de dados, um interpretador de código ou outro modelo efetivamente toma emprestada capacidade que não precisa memorizar.
Retrieval-augmented generation. Já mencionado na Parte 2 — vive nesta categoria.
Enxames agênticos. Múltiplas instâncias de modelo coordenando para resolver um problema que uma só não conseguiria.
Model merging. Combinar os parâmetros de múltiplos modelos fine-tuned sem treino adicional.
Compute adaptativo. Gastar mais compute de inferência em problemas difíceis, menos nos fáceis.

A estimativa de Davidson et al. (2023) é o número de manchete: técnicas em tempo de inferência podem entregar melhorias de 5×–20× sobre o desempenho base pós-treino, com pegada mínima relativa ao custo do pré-treino. Essa é uma razão de alavancagem enorme, e está sendo capturada hoje por times que escolheram investir nessa camada em vez de esperar a próxima classe de tamanho de modelo.

A implicação estratégica é sutil mas importante. Técnicas em tempo de inferência são engenharia, não treino. Recompensam times que conseguem entregar, instrumentar, avaliar e iterar rápido. O gargalo se move de "você tem GPUs suficientes para treinar" para "você tem velocidade de engenharia suficiente para compor, avaliar e entregar". Essa é uma notícia genuinamente boa para organizações que não estão sentadas em cima de uma linha de capex do tamanho de hyperscaler — o que, de novo, é a maioria de nós.

2. O espaço de dados maleável

O segundo novo espaço de otimização de Hooker é o que ela chama de espaço de dados maleável, e pode ser a mudança filosoficamente mais interessante do ensaio todo.

Durante a maior parte da história da IA, datasets eram artefatos congelados — MNIST, ImageNet, SQuAD, C4. Você escolhia um, treinava nele, reportava os números. O dataset era um snapshot do mundo que você conseguiu reunir. O pressuposto fundamental de machine learning era IID — amostras tomadas independente e identicamente de alguma distribuição fixa. Aceitávamos o que o mundo nos entregasse.

O que muda quando a geração de dados sintéticos fica barata o bastante para tratar os próprios dados como algo que você otimiza?

Você pode direcionar a distribuição para o que de fato quer — incluindo capacidades, idiomas, casos extremos, equilíbrio demográfico — em vez de aceitar o que o corpus por acaso contém.
Você pode mirar a cauda longa diretamente. Se seu modelo é fraco numa categoria específica, pode gerar ou sintetizar exemplos para ela em vez de torcer para que o próximo scrape contenha mais deles.
Você pode encolher a distância entre a distribuição de tempo de treino e a de tempo de inferência. Historicamente houve um descompasso crônico: dados de treino são determinados pelo que você conseguiu coletar; inputs de inferência são determinados pelo que os usuários de fato fazem. Dados sintéticos podem fechar essa distância deliberadamente.
Você pode tornar populações invisíveis visíveis. A linha de trabalho do Aya (Aryabumi et al. 2024; Üstün et al. 2024; Dang et al. 2024b) é em grande parte sobre usar dados sintéticos e tradução para dar cobertura multilíngue que a web aberta não fornece.

Essa é uma ruptura nítida com "amostras IID da natureza". Hoje somos capazes de enviesar intencionalmente a distribuição na direção do que esperamos representar, em vez de aceitar uma amostra aleatória do que existe. Isso é tanto uma capacidade enorme quanto uma responsabilidade enorme — dados sintéticos mal feitos compõem viés em vez de consertá-lo.

Para times de produto, o aprendizado prático é que você deveria tratar seus dados de treino/fine-tuning como algo que você desenha, não algo que você colhe. Se seu modelo é fraco numa fatia que importa, você tem uma alavanca que não existia cinco anos atrás.

3. Design e interface

O terceiro espaço de otimização que Hooker destaca é aquele para o qual a maioria dos cientistas da computação está menos equipada: como o sistema interage com o mundo.

O sistema mais inteligente será cada vez mais definido pela construção de um algoritmo que pode interagir com o mundo. Isso significa que, pela primeira vez, pesquisadores que se importam com inteligência precisam também ser obcecados com como um modelo interage. O que antes era o domínio estreito de designers de UX, artistas e especialistas em interação humano-computador, deveria agora ser de grande interesse para todos os cientistas da computação.

Isso pesa porque inverte um pressuposto cultural antigo. O progresso da IA foi historicamente limitado pelo algoritmo e tratava a interface como um wrapper. Hooker está dizendo que a interface está se tornando parte do algoritmo — e os sistemas mais capazes serão sistemas multi-componentes cuja inteligência emerge de como os componentes são compostos e de como tocam o mundo, não de qualquer modelo individual ficando maior.

Isso casa com a onda de sistemas agênticos mas reenquadra ela. Os sistemas agênticos interessantes não são "modelo maior + ferramentas". São superfícies de interação cuidadosamente desenhadas: onde o modelo obtém informação, onde pode agir, o que é mostrado ao humano, o que o humano aprova, como o feedback flui de volta. Isso é HCI, design de produto e engenharia de sistemas — e é exatamente o tipo de trabalho que foi historicamente subvalorizado em labs de IA.

Para qualquer um entregando features de IA em produto, isso é boa notícia. A disciplina que você já tem em UX, em revisão de trust-and-safety, em design de workflow, em arquitetura human-in-the-loop — agora é trabalho de IA de primeira classe. Já não é um wrapper em torno da capacidade "real".

O que isso não significa: a clarificação ambiental

Hooker é cuidadosa em antecipar uma leitura errada específica do ensaio, e quero repeti-la porque é importante. A morte lenta do scaling do compute de treino não significa que a pegada ambiental da IA está encolhendo. Pelo contrário:

A maior parte dos requisitos de energia das cargas de trabalho de IA não está no treino, mas no custo de produtizar uma carga de ML e servi-la a bilhões de usuários. Mesmo que o tamanho do modelo esteja tendendo a diminuir, a adoção generalizada de IA significa que os requisitos gerais de energia provavelmente continuarão a subir.

Em outras palavras: modelos menores e mais performantes estão sendo deployados em muito mais lugares, então a pegada agregada de energia e água da IA continua crescendo mesmo que o custo de treino por modelo potencialmente se estabilize. As linhas de trabalho de Strubell et al. (2019a), Patterson et al. (2021), Luccioni et al. (2025) e Wu et al. (2022) continuam estruturais. Se algo, o futuro com inferência pesada que Hooker descreve torna eficiência de serving, utilização de hardware e deployment carbono-consciente mais importantes, não menos.

Já escrevi antes sobre regiões operacionais soberanas viáveis exatamente sobre essa tensão — que a história de custo para IA é cada vez mais determinada pela infraestrutura de serving, não de treino. O enquadramento de Hooker reforça isso.

Vamos voltar a escalar algum dia?

A resposta de Hooker aqui é comedida e vale a pena citar:

Enquanto estivermos presos a transformers como arquitetura, não faz sentido continuar escalando compute. Nossa arquitetura atual mostra todos os sinais de plateau nos retornos de compute adicional. Enquanto o progresso girou em torno de redes neurais profundas na última década, há muito a sugerir que o próximo passo significativo à frente exigirá uma arquitetura inteiramente diferente.

A implicação é que o scaling vai voltar quando uma nova arquitetura chegar e quebrar a curva de retornos atual, abrindo uma nova — exatamente como os transformers fizeram em 2017. Mas escalar a arquitetura atual é, cada vez mais, capex perseguindo retornos decrescentes. Os labs de fronteira que liderarão a próxima onda não serão os que escalaram mais forte. Serão os que apostaram numa mudança de paradigma.

O que estou tirando da série inteira

Três fios puxados do ensaio de Hooker que acho mais importantes para qualquer um entregando IA em 2026:

O trabalho interessante voltou para as mãos dos engenheiros. Durante uma década, o progresso da IA foi uma história sobre quem podia pagar mais compute. A virada em direção à técnica algorítmica, ao design de dados, ao compute em tempo de inferência e à interface significa que a diferenciação interessante volta a ser sobre julgamento de engenharia — escolha de arquitetura de retrieval, curadoria de dados de treino, design de loops de agente, estrutura de human-in-the-loop. Esse é território recuperável para times que não têm um orçamento de treino de US$ 100M.
Os pressupostos dominantes de política pública e capex estão envelhecendo rápido. Limiares de compute na legislação, frameworks de "responsible scaling", roadmaps de fornecedor baseados em "ano que vem, maior" — são todos artefatos de um pressuposto que hoje é empiricamente fraco. Qualquer plano que dependa deles merece um novo olhar.
A próxima arquitetura é o prêmio. Esquecimento catastrófico, ineficiência amostral, a incapacidade de especializar regiões de conhecimento — esses são os problemas duros que a arquitetura atual não consegue resolver. Quem os resolver reseta o campo. Essa é uma aposta muito mais interessante do que "mais parâmetros".

Hooker fecha o ensaio com uma citação de Turing que cai bem no momento: "Só conseguimos ver a curta distância à frente, mas vemos lá bastante coisa que precisa ser feita." A razão de isso pesar é porque, por um longo trecho, ciência da computação parecia não ter muita coisa para fazer — tinha uma coisa para fazer, muito caro. Estamos finalmente do outro lado disso. A vista daqui é mais incerta, mas o trabalho é mais interessante de novo.

Este é o último post da série. A Parte 1 cobriu por que maior já não é sempre melhor. A Parte 2 percorreu o que de fato impulsiona a taxa de retorno do compute.

Referência: Sara Hooker, On the slow death of scaling, 2025.