Modelos de Linguagem Recursivos (Recursive Language Models)

• Foi proposta uma nova estratégia de inferência, RLM (Recursive Language Model), para permitir que grandes modelos de linguagem (LLMs) processem prompts de entrada muito longos
• O RLM trata prompts longos como parte de um ambiente externo, permitindo que o modelo os explore, decomponha e invoque recursivamente de forma programática
• Essa abordagem ultrapassa os limites da janela de contexto e processa entradas de até dezenas de milhões de tokens, com grande melhora de qualidade em relação aos LLMs convencionais
• Nos experimentos, RLMs baseados em GPT-5 e Qwen3-Coder apresentaram ganhos de desempenho de dois dígitos em várias tarefas longas, com custo similar ou menor
• A proposta é avaliada como uma abordagem geral capaz de superar os limites no tratamento de contexto longo e ampliar significativamente a capacidade de raciocínio dos LLMs

---

Visão geral do RLM

• O Recursive Language Model (RLM) foi projetado para que o LLM não insira diretamente entradas longas na rede neural, mas sim interaja com elas ao tratá-las como variáveis de um ambiente externo
  • O prompt de entrada P é carregado como variável em um ambiente REPL em Python, e o LLM o explora, decompõe e invoca recursivamente por meio de código
  • O LLM reconhece o estado do ambiente REPL (por exemplo, o comprimento de uma string), observa os efeitos colaterais da execução do código e resolve o problema de forma gradual
• Essa estrutura resolve o problema das abordagens tradicionais de compactação de contexto (compaction) ou baseadas em resumo, que perdem detalhes
• O RLM é apresentado como um paradigma geral de inferência capaz de expandir tanto o comprimento da entrada quanto o da saída

Limites das abordagens existentes

• LLMs convencionais apresentam o fenômeno de context rot, no qual o desempenho cai rapidamente com entradas longas por causa do limite da janela de contexto
• Técnicas de compactação de contexto repetem resumos quando se ultrapassa certo tamanho, mas são inadequadas para tarefas que exigem acesso a informações detalhadas
• O RLM trata o prompt como um objeto externo e, com isso, consegue expandir o tamanho da entrada para além do limite do modelo

Configuração dos experimentos

• Modelos avaliados: GPT-5 (OpenAI, 2025) e Qwen3-Coder-480B-A35B (Team, 2025)
• Métodos de comparação:
  • chamada direta ao LLM base
  • agente de resumo (Summary agent)
  • agente baseado em busca com CodeAct + BM25
  • RLM (com ambiente REPL) e RLM (REPL, sem chamada recursiva)
• Nos experimentos com GPT-5, foi usado o GPT-5-mini para chamadas recursivas e o GPT-5 como modelo raiz, buscando equilíbrio entre desempenho e custo

Tarefas de avaliação

• S-NIAH: problema único de “needle-in-a-haystack”, com custo de processamento constante independentemente do tamanho da entrada
• BrowseComp-Plus: tarefa de perguntas e respostas multi-hop entre vários documentos, com a resposta correta incluída entre 1000 documentos
• OOLONG: tarefa de raciocínio sobre textos longos em que quase todos os itens da entrada precisam ser transformados e integrados semanticamente, com custo de processamento linear em relação ao tamanho da entrada
• OOLONG-Pairs: variante do OOLONG que exige combinação de informações em pares, com custo de processamento quadrático em relação ao tamanho da entrada
• LongBench-v2 CodeQA: tarefa de múltipla escolha que exige compreensão de repositórios de código, difícil até para modelos recentes

Principais resultados

• O RLM quase não sofre queda de desempenho em contextos longos em comparação com o GPT-5
  • O GPT-5 apresenta forte queda de desempenho à medida que aumentam o tamanho da entrada e a complexidade da tarefa
  • O RLM processa de forma eficaz até mesmo entradas que excedem o limite de 272K tokens (até mais de 10M de tokens)
• Em todas as tarefas longas, o RLM mostrou ganhos de desempenho de dois dígitos em relação aos outros métodos
• A eficiência de custo também foi mantida, com custo por consulta similar ou inferior ao das abordagens existentes

Análise de complexidade das tarefas longas

• A janela de contexto efetiva dos LLMs pode ser mais curta do que o limite físico, dependendo da complexidade da tarefa
  • Problemas simples de NIAH podem ser resolvidos mesmo com 1M+ tokens
  • Tarefas mais complexas da família OOLONG apresentam queda de desempenho mesmo com comprimentos bem menores
• Portanto, é preciso considerar em conjunto a densidade de informação da tarefa e sua relação com o tamanho da entrada

Conclusão

• O RLM expande recursivamente a capacidade de raciocínio dos LLMs, permitindo lidar com entradas ultralongas que modelos existentes não conseguem processar
• O ponto central da inovação é o projeto que trata o prompt como um objeto do ambiente, resolvendo limites estruturais no processamento de textos longos
• A proposta é apresentada como um framework geral de inferência que alcança equilíbrio entre desempenho, custo e escalabilidade em diversos modelos e tarefas

[GN⁺]

Comentários no Hacker News

• Isso parece apenas o conceito de subagent
  Ou seja, uma forma de chamar outro LLM para ler arquivos e extrair as informações necessárias, evitando complicar o contexto principal
  A ideia é boa, mas não é totalmente nova

  • Eu vejo isso mais como um meio de gerenciamento de contexto do que como subagents antropomorfizados, como se fossem humanos
    No momento, estou experimentando no projeto Scope para que subagents observáveis decomponham tarefas recursivamente
    Só que não sei como melhorar essa avaliação da etapa de planejamento
    Registro heurísticas em arquivos Markdown, mas a estrutura é solta demais, então é difícil medir
    Se alguém conhecer literatura ou projetos relacionados, seria ótimo saber
  • O artigo diz o seguinte
    RLM não é agente nem resumo
    Usar várias chamadas de LM dentro de um sistema não é um conceito novo, e isso é o que a maioria dos agentic scaffolds faz
    O exemplo mais parecido seria o ROMA agent, que decompõe o problema e o resolve com vários sub-agents
    Além disso, assistentes de código como Cursor e Claude Code também resumem ou podam o contexto à medida que ele cresce
    Essas abordagens normalmente fazem a decomposição por unidade de tarefa, mas o RLM enfatiza a decomposição por unidade de contexto e entende que essa escolha deve ser feita pelo próprio LM
  • Pelo título, parece que toda a computação é differentiable e treinada como um único modelo, mas na prática parece ser apenas um nível de chamadas repetidas ao modelo
  • Se um subagent não puder chamar outro subagent indefinidamente, então isso não pode ser chamado de recursivo
  • Parece que estão falando do conceito de sub-agents que acessam e manipulam o mesmo contexto (sistema de arquivos ou variáveis do REPL)

• O insight central é que prompts longos não devem ser colocados diretamente na rede neural (Transformer), mas tratados como parte de um ambiente com o qual o LLM pode interagir simbolicamente
  Mas fico curioso sobre como isso difere fundamentalmente de RAG
  Pelo diagrama 4, a diferença parece ser que o mecanismo de retrieval é implementado diretamente pelo LLM, e não por uma pessoa

  • Na minha visão, há duas diferenças
    1️⃣ RAG está mais próximo de um workflow, enquanto isso aqui é mais agentic
    2️⃣ Tem uma estrutura recursiva
    Em um workflow, uma pessoa desenha o fluxo passo a passo, mas em uma abordagem agentic o agente decide por conta própria o que pesquisar, quantas chamadas fazer e quando responder
    Por exemplo, Claude Code ou Codex explorando um codebase, lendo arquivos e rodando ripgrep
    Tentativas recursivas desse tipo já existiam antes (por exemplo: babyagi, por volta de 2023), mas na época o desempenho dos modelos era insuficiente, então era necessário muito glue code
    Agora os modelos já são fortes o bastante para que essa estrutura funcione de fato

• Como na piada “T̶u̶r̶t̶l̶e̶s̶ LLMs all the way down”, isso sugere uma estrutura em que um LLM chama outro sem parar

  • É como aplicar “attention is all you need” repetidamente, e no fim o que devemos buscar é precisão (precision)

• Há uma versão mais fácil de ler do texto: post no blog de alexzhang13

• O que eu gostaria de ver em 2026 é a Anthropic ou a OpenAI mostrando aos criadores de plugins de CLI “como a compaction é executada”
  Essa técnica talvez possa substituir a funcionalidade embutida no Claude Code, mas no momento não há hooks ou recursos adequados expostos

  • Se o Codex é open source, não daria para ler diretamente?
    Eu vi o código do Gemini, e era uma estrutura de prompt simples que resumia tudo quando a janela de contexto ficava cheia

• Parece semelhante a este artigo: arXiv:2510.14826