Agente de IA a produzir lixo? O problema é que não quer queimar Tokens

Questões não estão nas palavras-chave!

Autor: Systematic Long Short

Tradução: Deep潮 TechFlow

Deep潮 Guia de leitura: O ponto central deste artigo é uma frase: a qualidade da saída do AI Agent é proporcional à quantidade de Tokens que você investe.

O autor não está falando de teoria genérica, mas apresentando duas abordagens concretas que podem ser usadas hoje mesmo, além de delimitar claramente a fronteira do problema que os Tokens não podem resolver — a “questão da novidade”.

Para leitores que usam Agents para escrever código ou executar fluxos de trabalho, a densidade de informação e a operacionalidade são altas.

Introdução

Bem, você tem que admitir que esse título realmente chama atenção — mas, falando sério, não é brincadeira.

Em 2023, enquanto ainda usamos LLMs para gerar código de produção, as pessoas ao redor ficaram boquiabertas, pois a percepção comum era que LLMs só produziam lixo inutilizável. Mas sabemos de uma coisa que muitos não perceberam: a qualidade da saída do Agent é uma função do número de Tokens investidos. Simples assim.

Você mesmo pode fazer alguns experimentos para ver. Peça ao Agent para completar uma tarefa complexa e pouco comum de programação — por exemplo, implementar do zero um algoritmo de otimização convexa com restrições. Primeiro, execute com o menor nível de reflexão; depois, mude para o nível máximo, peça para revisar o próprio código e identificar quantos bugs consegue encontrar. Teste também níveis intermediários. Você verá claramente: a quantidade de bugs diminui monotonicamente à medida que aumenta o número de Tokens investidos.

Fácil de entender, não é?

Mais Tokens = menos erros. Você pode levar essa lógica um passo adiante, e ela basicamente é o núcleo (simplificado) por trás de produtos de revisão de código. Em um contexto totalmente novo, investindo uma quantidade enorme de Tokens (por exemplo, pedir para analisar linha por linha, verificar bugs em cada uma delas) — você consegue detectar a maioria, ou até todos, os bugs. Esse processo pode ser repetido dez, cem vezes, cada vez com uma “perspectiva” diferente sobre o código, até que todos os bugs sejam encontrados.

A ideia de que “mais Tokens melhoram a qualidade do Agent” também tem suporte empírico: equipes que afirmam usar Agents para escrever código de produção de ponta a ponta, ou são fornecedores de modelos básicos, ou são empresas com recursos financeiros extremamente elevados.

Portanto, se você ainda está frustrado por Agents não gerarem código de nível de produção — para ser direto: o problema é seu. Ou, mais precisamente, seu bolso.

Como saber se estou usando Tokens suficientes

Já escrevi um artigo inteiro dizendo que o problema não está na sua estrutura (harness), que “manter simples” ainda assim produz resultados excelentes, e continuo defendendo essa ideia. Você leu, seguiu as orientações, mas ainda assim ficou decepcionado com a saída do Agent. Você me enviou uma DM, eu li, mas não respondi.

Este artigo é a minha resposta.

Se seu Agent tem desempenho ruim ou não resolve problemas, na maioria das vezes é porque você não investiu Tokens suficientes.

A quantidade de Tokens necessária para resolver um problema depende do seu tamanho, complexidade e novidade.

“2+2 é quanto?” não precisa de muitos Tokens.

“Me ajude a criar um bot que escaneie todos os mercados entre Polymarket e Kalshi, identifique aqueles semanticamente similares, que deveriam ser liquidados na mesma ou em eventos relacionados, defina limites de arbitragem, e execute negociações automáticas com baixa latência assim que surgirem oportunidades” — isso exige uma quantidade enorme de Tokens.

Na prática, descobrimos uma coisa interessante.

Se você investir Tokens suficientes para lidar com problemas gerados por escala e complexidade, o Agent consegue resolver de qualquer jeito. Em outras palavras, se você quer construir algo extremamente complexo, com muitos componentes e linhas de código, basta investir Tokens suficientes nesses problemas — eles serão resolvidos de forma definitiva.

Há uma pequena, mas importante exceção.

Seu problema não pode ser muito inovador. No estágio atual, qualquer quantidade de Tokens não resolve a “questão da novidade”. Tokens suficientes podem eliminar erros causados pela complexidade, mas não fazem o Agent inventar coisas que ele não conhece.

Essa conclusão, na verdade, nos traz alívio.

Gastamos uma enorme quantidade de Tokens tentando, sem muita orientação, fazer o Agent reproduzir processos de investimento institucional. Parte do objetivo era entender quantos anos ainda nos separam de uma substituição total por IA na pesquisa quantitativa. Mas descobrimos que o Agent simplesmente não consegue reproduzir um processo de investimento institucional decente. Acreditamos que isso ocorre porque esses processos simplesmente não estão presentes nos dados de treinamento — ou seja, eles não existem nos dados.

Portanto, se seu problema é muito inovador, não espere que empilhar Tokens resolva. Você precisa guiar a exploração por conta própria. Mas, uma vez que tenha uma solução clara, pode investir Tokens para execução — independentemente do tamanho do código ou da complexidade dos componentes.

Uma regra heurística simples: o orçamento de Tokens deve crescer proporcionalmente ao número de linhas de código.

O que exatamente os Tokens extras fazem

Na prática, Tokens adicionais geralmente elevam a qualidade do trabalho do Agent de várias formas:

Permitem que ele dedique mais tempo ao raciocínio na mesma tentativa, aumentando as chances de detectar erros lógicos. Quanto mais profundo o raciocínio, melhor o planejamento, maior a chance de acerto.

Permitem múltiplas tentativas independentes, explorando diferentes caminhos de solução. Alguns caminhos são melhores que outros. Com várias tentativas, ele pode escolher o melhor.

De forma semelhante, mais tentativas de planejamento independentes permitem que ele abandone direções fracas e preserve as mais promissoras.

Mais Tokens também possibilitam usar um contexto renovado para criticar o trabalho anterior, dando uma chance de melhorar, ao invés de ficar preso em uma “inércia de raciocínio”.

E, claro, minha preferência: mais Tokens permitem usar testes e ferramentas para verificar. Executar o código na prática para ver se funciona é a forma mais confiável de confirmar a correção.

Essa lógica funciona porque o fracasso do Engineering do Agent não é aleatório. Geralmente, ocorre por escolher caminhos prematuramente, não verificar se esses caminhos realmente levam ao resultado desejado (no início), ou por não ter orçamento suficiente para recuperar e retroceder ao detectar erros.

A história é essa. Literalmente, Tokens representam a qualidade de decisão que você compra. Imagine como uma pesquisa: se você faz uma pessoa responder a uma questão difícil na hora, a qualidade da resposta diminui com a pressão do tempo.

Pesquisa, no fundo, é gerar o “saber a resposta”. Humanos gastam tempo biológico para produzir respostas melhores; Agents gastam mais tempo computacional para produzir respostas melhores.

Como melhorar seu Agent

Você ainda pode estar cético, mas há muitas evidências em artigos que suportam isso. Sinceramente, o fato de existir um “botão de raciocínio” já é a maior prova de que essa abordagem funciona.

Uma das minhas favoritas é uma pesquisa que treinou com um pequeno conjunto de exemplos de raciocínio, e depois usou uma técnica para forçar o modelo a continuar pensando — adicionando um “Wait” (espera) onde ele queria parar. Só isso elevou um benchmark de 50% para 57%.

Vou ser direto: se você reclama que seu Agent escreve código ruim, provavelmente o nível de reflexão máxima ainda não é suficiente.

Tenho duas soluções bem simples:

Solução 1: WAIT (espera)

Hoje mesmo, você pode montar um ciclo automático: após construir o código, fazer o Agent revisar N vezes, cada vez com um contexto renovado, corrigindo problemas que encontrar.

Se perceber que essa técnica simples melhora seu resultado, você entendeu que o problema é a quantidade de Tokens — então, bora investir mais nisso.

Solução 2: VERIFY (verificação)

Faça o Agent validar seu trabalho cedo e frequentemente. Escreva testes que garantam que o caminho escolhido realmente funciona. Isso é especialmente útil em projetos complexos e profundamente aninhados — uma função pode ser chamada por muitas outras. Detectar erros na origem economiza muito tempo de processamento (Tokens) depois.

Se possível, coloque pontos de verificação ao longo de toda a construção.

Depois que o principal Agent disser que terminou, envie uma segunda instância para verificar. Fluxos de pensamento independentes podem identificar falhas sistêmicas.

É basicamente isso. Posso escrever muito mais sobre o tema, mas acredito que, ao perceber essas duas estratégias e colocá-las em prática, você resolve 95% dos problemas. Acreditar que, ao simplificar ao máximo, e só depois acrescentar complexidade, se chega ao sucesso.

Reforçando: “questões de novidade” não podem ser resolvidas apenas com Tokens. Quero enfatizar isso mais uma vez, porque cedo ou tarde você vai esbarrar nesse problema e reclamar que Tokens não funcionam.

Quando o problema que você quer resolver não está nos dados de treinamento, você é quem precisa criar a solução. Portanto, conhecimento especializado na área continua sendo fundamental.