Qualidade do Agente de IA Correlacionada com a Queima de Tokens

Autor: Systematic Long Short

Tradução: Deep潮 TechFlow

Leitura da Shenchao: O argumento central deste artigo é apenas uma frase: a qualidade da saída do AI Agent é proporcional ao número de tokens investidos.

O autor não está falando genericamente sobre teorias, mas apresenta dois métodos concretos que podem ser usados já hoje, e delimita claramente o limite que os tokens não conseguem ultrapassar — o "problema da novidade".

Para leitores que estão usando Agent para escrever código ou executar fluxos de trabalho, a densidade de informações e a operacionalidade são muito altas.

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

Em 2023, quando ainda estávamos usando LLMs para executar código de produção, todos ao nosso redor ficaram atônitos, pois a percepção geral na época era que LLMs só produziam lixo inutilizável. Mas nós sabíamos algo que os outros não percebiam: a qualidade da saída do Agente é uma função da quantidade de Tokens investidos. É tão simples assim.

Você pode ver isso por si mesmo executando alguns experimentos. Peça ao Agente para realizar uma tarefa de programação complexa e um pouco especializada — por exemplo, implementar do zero um algoritmo de otimização convexa com restrições. Primeiro, execute com o nível de pensamento mais baixo; depois, altere para o nível mais alto, permitindo que ele revise seu próprio código e veja quantos bugs consegue identificar. Experimente também os níveis médio e alto. Você verá intuitivamente que o número de bugs diminui monotonicamente com o aumento da quantidade de tokens investida.

Isso não é difícil de entender, certo?

Quanto mais tokens, menos erros. Você pode levar essa lógica um passo adiante — essa é basicamente a ideia central (simplificada) por trás do produto de revisão de código. Em um contexto totalmente novo, invista uma quantidade massiva de tokens (por exemplo, faça-o analisar o código linha por linha, verificando se cada linha contém um bug) — isso basicamente consegue detectar a maioria, senão todos os bugs. Esse processo pode ser repetido dez, cem vezes, sempre examinando o repositório de código sob “ângulos diferentes”, e você acabará por descobrir todos os bugs.

A ideia de que “quanto mais Token for queimado, melhor será a qualidade do Agente” tem ainda um suporte empírico: as equipes que afirmam ser capazes de usar Agentes para escrever código do início ao fim e implantá-lo diretamente em produção são ou fornecedoras do modelo básico ou empresas com financiamento extremamente generoso.

Então, se você ainda está se preocupando porque o agente não consegue gerar código de produção — digamos francamente, o problema está em você. Ou, melhor ainda, no seu bolso.

Escrevi um artigo inteiro dizendo que o problema absolutamente não está no seu framework, "manter simples" ainda assim permite criar coisas excelentes, e eu ainda mantém essa opinião. Você leu aquele artigo, seguiu as instruções, mas ainda ficou profundamente desapontado com a saída do Agent. Você me enviou uma DM, vi que você leu, mas não respondeu.

Esta é a resposta.

Seu agente desempenha mal e não resolve problemas, na maioria das vezes, porque você não queimou tokens suficientes.

The number of tokens required to solve a problem depends entirely on the problem’s scale, complexity, and novelty.

「2 + 2 é igual a quanto?」Não precisa de muitos tokens.

“Me ajude a criar um bot que escaneie todos os mercados entre Polymarket e Kalshi, identifique mercados semanticamente semelhantes que devem ser resolvidos no mesmo evento, defina limites de arbitragem e execute automaticamente negócios de baixa latência assim que surgir uma oportunidade de arbitragem” — isso vai consumir uma grande quantidade de Token.

Descobrimos algo interessante na prática.

Se você investir suficientes Token para lidar com os problemas causados pela escala e complexidade, o agente conseguirá resolver de qualquer maneira. Em outras palavras, se você quiser construir algo extremamente complexo, com muitos componentes e linhas de código, basta jogar suficientes Token nesses problemas para que eles sejam completamente resolvidos.

Aqui há uma pequena mas importante exceção.

Sua pergunta não pode ser muito inovadora. No estágio atual, qualquer quantidade de tokens não consegue resolver o problema da "novidade". Um número suficiente de tokens pode reduzir erros causados pela complexidade a zero, mas não permite que o agente invente algo do nada que ele não conheça.

Essa conclusão, na verdade, nos aliviou.

Investimos uma enorme quantidade de esforço, queimamos — muitíssimos, muitíssimos tokens — para tentar descobrir se o agente conseguiria recriar o processo de investimento institucional quase sem orientação. Parte disso foi para entender quantos anos ainda nos separam de sermos totalmente substituídos pela IA. Descobrimos que o agente simplesmente não consegue se aproximar de um processo de investimento institucional adequado. Acreditamos que essa é, em parte, porque eles nunca viram algo assim — ou seja, o processo de investimento institucional simplesmente não existe nos dados de treinamento.

Então, se a sua pergunta for nova, não espere resolver tudo apenas acumulando Tokens. Você precisa guiar o processo de exploração por conta própria. Mas assim que definir a solução, pode confiar plenamente em acumular Tokens para executá-la — não importa o tamanho do repositório de código ou a complexidade dos componentes, não será um problema.

Existe um princípio heurístico simples: o orçamento de tokens deve crescer proporcionalmente ao número de linhas de código.

Na prática, os tokens adicionais geralmente melhoram a qualidade do projeto do agente por meio dos seguintes métodos:

Gaste mais tempo raciocinando na mesma tentativa, dando-se a chance de descobrir erros lógicos por conta própria. Quanto mais profundo o raciocínio, melhor o planejamento e maior a probabilidade de acertar na primeira.

Permita que ele faça múltiplas tentativas independentes, seguindo diferentes caminhos de resolução. Alguns caminhos são melhores do que outros. Ao permitir mais de uma tentativa, ele poderá escolher o melhor.

Da mesma forma, mais tentativas de planejamento independente permitem que ele descarte direções fracas e mantenha as mais promissoras.

Mais tokens permitem que ele critique seu próprio trabalho anterior em um novo contexto, oferecendo-lhe uma oportunidade de melhoria, em vez de ficar preso em alguma “inércia de raciocínio”.

Claro, e meu ponto favorito: mais tokens significam que pode ser verificado com testes e ferramentas. Executar o código real para ver se funciona é a maneira mais confiável de confirmar que a resposta está correta.

Essa lógica funciona porque a falha de engenharia do Agente não é aleatória. Quase sempre ocorre devido à escolha errada prematura de um caminho, à falta de verificação se esse caminho realmente é viável (no início) ou à ausência de orçamento suficiente para recuperar e retroceder após detectar um erro.

É assim que a história se desenrola. O token é literalmente a qualidade da decisão que você comprou. Pense nisso como uma pesquisa: se você pedir a alguém para responder imediatamente a uma pergunta difícil, a qualidade da resposta diminui à medida que a pressão temporal aumenta.

Pesquisa, em última análise, é o que produz a base de “saber a resposta”. Os humanos gastam tempo biológico para produzir respostas melhores, enquanto os agentes gastam mais tempo computacional para produzir respostas melhores.

Você ainda pode estar cético, mas há muitos artigos que apoiam isso; francamente, a própria existência do controle de "raciocínio" já é toda a prova de que você precisa.

Um artigo que eu adoro: os pesquisadores treinaram com um pequeno conjunto de amostras de raciocínio cuidadosamente elaboradas e depois usaram um método para forçar o modelo a continuar pensando quando queria parar — especificamente, adicionando "Wait" (espere) no ponto em que ele pretendia parar. Apenas isso elevou um benchmark de 50% para 57%.

Quero ser o mais direto possível: se você sempre reclamou que o código escrito pelo Agente é medíocre, o nível máximo de pensamento único provavelmente ainda não é suficiente para você.

Dou-te duas soluções muito simples.

Abordagem simples 1: WAIT (esperar)

A coisa mais simples que você pode começar a fazer hoje: crie um ciclo automático — após construí-lo, faça com que o Agente revise N vezes com novos contextos, corrigindo qualquer problema encontrado a cada revisão.

Se você descobrir que essa dica simples melhorou o desempenho do seu agente, então você já entendeu que seu problema era apenas uma questão de número de tokens — então venha se juntar ao clube do gasto de tokens.

Segunda opção simples: VERIFY (verificar)

Faça o Agent verificar seu próprio trabalho o mais cedo e com frequência possível. Escreva testes para provar que o caminho escolhido realmente funciona. Isso é especialmente útil para projetos altamente complexos e profundamente aninhados — uma função pode ser chamada por muitas outras funções a jusante. Capturar erros na fase inicial pode economizar-lhe uma grande quantidade de tempo de cálculo (Token) posterior. Portanto, sempre que possível, defina "pontos de verificação" em todo o processo de construção.

Após escrever um trecho, o agente principal diz que terminou? Peça ao segundo agente para verificar novamente. Fluxos de pensamento não relacionados podem cobrir as fontes de viés sistemático.

É基本上 isso. Posso escrever muito mais sobre esse assunto, mas acho que, se você reconhecer esses dois pontos e implementá-los bem, conseguirá resolver 95% dos problemas. Acredito firmemente em fazer coisas simples de forma perfeita e adicionar complexidade apenas conforme necessário.

Mencionei que a "novidade" é um problema que não pode ser resolvido com tokens, e quero reforçar novamente, pois você certamente acabará enfrentando esse problema e virá me reclamar dizendo que acumular tokens não funcionou.

Quando o problema que você deseja resolver não está no conjunto de treinamento, você é a pessoa que realmente precisa fornecer a solução. Portanto, o conhecimento especializado no campo ainda é extremamente importante.