Loop, repita, convirja: Ralph, RLM e autoresearch explicam por que 2026 é a era da repetição

Em 2024, a corrida era por modelos maiores. Em 2025, por janelas de contexto maiores. Em 2026, o padrão que está dominando o estado da arte é mais estranho e mais simples do que qualquer um esperava: rodar o mesmo modelo várias vezes seguidas e deixar o sistema convergir.

Três projetos independentes chegaram a essa conclusão por caminhos diferentes: o Ralph de Greg Baugues, o RLM de Alex Zhang, e o autoresearch de Andrej Karpathy. Cada um resolve um problema diferente, mas todos operam na mesma lógica. Vale entender o que cada um faz e o que os une.

O Ralph: bash loop como estratégia de engenharia

O Ralph é desarmante na sua simplicidade. O núcleo do projeto é basicamente isso:

while :; do cat PROMPT.md | claude-code ; done

Cada iteração do loop inicia uma sessão completamente nova do claude-code. Contexto zerado. Sem memória da rodada anterior acumulando lixo na janela. O agente lê o código-fonte atual, roda os testes, vê o que falhou, e tenta de novo.

A memória entre as sessões fica em arquivos. O AGENTS.md acumula aprendizados: padrões que funcionaram, erros que se repetiram, convenções do projeto. Cada iteração lê esse arquivo antes de começar. Não é memória de sessão - é memória persistente em texto, versionada no git junto com o código.

O repositório está em github.com/snarktank/ralph.

O que parece ingênuo é na verdade uma escolha de arquitetura deliberada. Contexto fresco a cada iteração significa que o agente não fica preso em raciocínios errados de rodadas anteriores. Ele sempre olha pro estado atual do código, não pro estado que existia três iterações atrás.

Dito isso, os primeiros loops do Ralph raramente saem certos. Nos meus testes iniciais, algo em torno de 3 em cada 10 iterações desperdiçavam tokens resolvendo o problema errado - o prompt não era específico o suficiente sobre os critérios de conclusão. Ralph só brilha quando o PROMPT.md define com exatidão o que “pronto” significa: quais testes precisam passar, quais arquivos podem ser modificados, quais partes do código estão fora de escopo. Sem essa precisão, o loop converge pra um resultado que satisfaz literalmente o prompt, mas não o que você queria dizer.

O RLM: recursão como mecanismo de leitura

O Recursive Language Model de Alex Zhang resolve um problema diferente: como fazer um LLM processar documentos enormes sem degradação de qualidade.

A abordagem do RLM não é aumentar a janela de contexto. É fazer o modelo escrever código Python para navegar os dados sob demanda. O conteúdo fica em estruturas Python - listas, DataFrames, dicionários. O modelo escreve scripts para buscar e filtrar. A função central é llm_query(), que permite ao código gerado fazer sub-consultas ao próprio modelo.

Isso cria uma estrutura recursiva: o modelo decompõe o problema, delega partes para chamadas menores de si mesmo, agrega os resultados. É como ter um pesquisador que, em vez de ler 10 mil artigos do início ao fim, escreve um código de busca e processa em lotes.

O repositório está em github.com/alexzhang13/rlm.

O resultado mais impressionante foi no benchmark OOLONG, que testa compreensão de documentos longos. GPT-5-mini com RLM superou GPT-5 puro por mais de 2x. Um modelo menor, com arquitetura de loop recursivo, bateu o modelo maior rodando em modo convencional.

Vale mencionar uma limitação real do RLM: a profundidade da recursão precisa ser monitorada. Sem um limite explícito de iterações, um prompt mal formulado pode gerar uma cadeia de sub-consultas que consome sua cota de API em minutos. Em produção, você precisa definir max_depth antes de soltar o sistema em documentos grandes.

O autoresearch: loop de treinamento em 5 minutos

O autoresearch de Andrej Karpathy empurra o conceito para outro nível: e se o próprio processo de treinamento fosse um loop iterativo com budget fixo de tempo?

O mecanismo é um ciclo commit/reset com janela de 5 minutos. O sistema treina, avalia, decide se o checkpoint vale a pena manter ou se faz reset para o estado anterior, e recomeça. Dentro desse loop, ele também faz pesquisa automatizada - busca literatura relacionada, extrai insights relevantes, incorpora no próximo ciclo de treinamento.

O repositório está em github.com/karpathy/autoresearch.

A limitação aqui é clara e os autores não escondem: o sistema roda em uma única máquina, e a janela de 5 minutos é um budget rígido. Não escala horizontalmente sem modificação significativa da arquitetura. Para pesquisa que exige rodadas longas de treinamento ou distribuição entre múltiplas GPUs, o autoresearch como está não resolve. É uma prova de conceito poderosa, mas ainda restrita ao ambiente de laboratório de um único pesquisador.

O que os três têm em comum

O princípio que atravessa os três projetos tem um nome técnico: test-time compute scaling.

A ideia é que você pode trocar parâmetros de modelo por tempo de computação na inferência. Em vez de treinar um modelo maior com mais dados, você roda um modelo menor mais vezes, de formas mais inteligentes. O resultado pode ser superior ao modelo maior rodando uma única vez.

Isso muda a pergunta que você faz antes de escolher uma solução. A pergunta deixa de ser “qual modelo tem os melhores benchmarks?” e passa a ser “qual arquitetura de loop extrai mais do modelo que já tenho?”

Ralph responde essa pergunta com context isolation e memória em arquivo. RLM responde com decomposição recursiva e execução de código. Autoresearch responde com ciclos de treinamento com budget de tempo fixo. São respostas diferentes para contextos diferentes, mas todas apontam na mesma direção.

O que muda na prática

Se você trabalha com pipelines de IA hoje, alguns padrões práticos emergem desses três projetos.

Contexto fresco importa mais do que contexto acumulado em muitos casos. O instinto de manter uma sessão longa aberta para preservar continuidade pode estar trabalhando contra você. Experimente quebrar em sessões curtas com estado persistido em arquivo.

A qualidade do critério de conclusão define o teto do loop. Tanto no Ralph quanto no autoresearch, o limite prático não é o modelo - é a precisão com que você define “sucesso”. Investir tempo em especificar os critérios de saída frequentemente rende mais do que trocar de modelo.

Loops simples batem pipelines complexos quando o problema tem estrutura repetitiva. Se você está construindo um pipeline de dez etapas para resolver algo que poderia ser um loop de três etapas executado dez vezes, vale questionar a complexidade. Os três projetos são, no fundo, variações de um while loop com boa definição de estado.

A tendência não é por acaso. Três pesquisadores chegando ao mesmo padrão independentemente, em domínios diferentes, no mesmo período, é um sinal. Test-time compute não é mais só um paper - está virando arquitetura de produção.