Descobrir onde o modelo encontra cada informação que usa

Catorze anos de licenciamento ambiental cabem num servidor de arquivos, mas não cabem na cabeça de ninguém. A Veredas Ambiental, consultoria de Belo Horizonte, guarda os processos de 38 empreendimentos: minas, barragens de rejeito, loteamentos e uma pequena central hidrelétrica. São 6.400 documentos, cerca de 52 milhões de tokens. Token é o pedaço de palavra que o modelo lê e pelo qual a API cobra.

Helena, coordenadora técnica, responde aos clientes e assina os pareceres. Caio, engenheiro de dados, montou dois anos atrás um assistente de busca vetorial sobre esse acervo. Ele acertava perguntas do tipo “onde está o laudo de março da PCH” e errava perguntas do tipo “quantas condicionantes vencidas temos em todos os empreendimentos”. O erro de contagem é o mais caro, porque chega ao cliente com cara de certeza.

Trocar de ferramenta antes de saber por que a atual erra é gastar duas vezes. Ao terminar, o leitor separa o que um modelo sabe do que ele recebe e do que ele busca. Também classifica cada falha num de quatro tipos e reconhece o vocabulário que o resto do curso usa. A sigla RLM, em especial, tem três vizinhas com nomes parecidos e sentidos diferentes.

Três lugares de onde sai a resposta de um modelo de linguagem

Todo modelo de linguagem responde com o que encontra em três lugares. O primeiro são os parâmetros: os bilhões de números ajustados no treino, que guardam o que o modelo aprendeu antes de você chegar. É uma memória parecida com a de quem estudou para uma prova anos atrás: vasta, sem índice e sem data. O modelo não sabe dizer de qual livro tirou cada frase.

Em segundo lugar vem o contexto: o texto que chega na chamada, com a pergunta, as instruções e os documentos colados. Janela de contexto é o limite de tokens que cabem numa chamada, como o tamanho da mesa em que alguém espalha os papéis para ler. Em setembro de 2026, os modelos mais recentes da Anthropic, da OpenAI e do Google anunciam janelas de cerca de 1 milhão de tokens.

Ferramentas formam o terceiro lugar. São funções que o modelo chama para buscar ou calcular fora de si: uma busca num índice, uma consulta a banco, um trecho de código executado. O resultado volta para o contexto e só então entra na resposta. Uma calculadora sobre a mesa ajuda quem sabe o que digitar nela; o modelo precisa decidir o que perguntar à ferramenta.

Cada lugar tem um preço diferente. O que está nos parâmetros sai de graça a cada chamada, mas não se atualiza nem cita a origem. O que está no contexto é cobrado por token, toda vez que entra na janela. O que vem de ferramenta acrescenta tempo de espera e depende de a busca acertar o alvo. Escolher onde pôr uma informação é escolher entre custo, frescor e rastreabilidade.

Os três lugares aparecem juntos num mesmo pedido, em três gestos: receber, recuperar e usar. O modelo recebe a pergunta e o que veio com ela. Recupera o que falta, pela memória dos parâmetros ou por uma ferramenta. Usa o material ao raciocinar e escrever a resposta. Cada gesto falha de um jeito próprio, e o conserto de um não conserta o outro.

A primeira arquitetura famosa para o gesto de recuperar é o RAG, sigla de geração aumentada por recuperação. Patrick Lewis e mais onze autores do Facebook AI Research, da UCL e da NYU publicaram a proposta em maio de 2020. O modelo consulta passagens da Wikipédia indexadas por significado e escreve a resposta com elas à vista. Na época, atingiu o melhor resultado em três testes de perguntas abertas.

Os autores chamavam os parâmetros de memória paramétrica e o índice de memória não paramétrica. A ideia pegou porque resolve bem um tipo de pergunta: aquela cuja resposta mora em poucos trechos, fáceis de achar por semelhança de texto. “Onde está o laudo de março” é uma pergunta assim. “Quantas condicionantes venceram” não é, porque a resposta está espalhada em centenas de documentos que não se parecem com a pergunta.

Justamente nessa fronteira mexem os RLMs. Em vez de buscar trechos por semelhança e colá-los na janela, o RLM guarda o material inteiro fora da janela e dá ao modelo uma ferramenta de programação para lê-lo. O acervo deixa de ser contexto e passa a ser um objeto que o modelo manipula por código, pedaço por pedaço, chamando outras instâncias de modelo para ler cada parte.

O vocabulário do curso e as siglas que parecem iguais

RLM quer dizer Recursive Language Model, modelo de linguagem recursivo. Alex L. Zhang e Omar Khattab apresentaram a ideia num post de blog em 15 de outubro de 2025. O artigo, assinado por Zhang, Tim Kraska e Khattab, os três do MIT CSAIL, saiu no arXiv em 31 de dezembro de 2025. A versão atual, a terceira, é de 11 de maio de 2026.

Pela definição do artigo, o RLM é uma estrutura de inferência montada em volta de um modelo comum. Estrutura de inferência é o programa que organiza as chamadas ao modelo na hora de responder, sem mudar os pesos dele. Por fora, a interface continua a de sempre: entra texto, sai texto. Por dentro, o prompt vira uma variável num ambiente de programação, e o modelo escreve código para ler essa variável aos pedaços.

Recursivo, aqui, significa que o código escrito pelo modelo pode chamar o próprio modelo, ou uma cópia menor dele, sobre um pedaço do material. Cada chamada devolve um resultado que o código guarda e combina. A resposta final nasce dessa árvore de chamadas, e nenhuma delas precisa ler o acervo inteiro. A versão atual do artigo afirma que isso processa entradas mais de uma ordem de grandeza acima da janela do modelo.

Os quatro termos aparecem juntos em anúncios e posts, e a mistura produz expectativa errada. Quem lê “modelo recursivo” e entende “modelo que melhora sozinho” espera que o sistema aprenda com cada pergunta da Veredas. Nada disso acontece num RLM puro. Ele responde melhor a perguntas difíceis porque organiza a leitura, e esquece tudo quando a execução termina.

Um pesquisador que lê a sigla com atenção evita outra confusão, a de que RLM seja um produto. Existe uma biblioteca oficial, publicada no PyPI como rlms, e existe um módulo dspy.RLM no DSPy desde a versão 3.1.1, de 19 de janeiro de 2026. Até 23 de setembro de 2026, nenhum modelo comercial de fronteira foi anunciado como treinado para operar como RLM.

Com as palavras no lugar, a pergunta útil deixa de ser “qual tecnologia é melhor” e passa a ser “em qual dos três gestos o meu sistema falha”. Uma falha de recuperação pede busca melhor. Uma falha de leitura pede outra forma de expor o material ao modelo. Armadilha comum: trocar o modelo por um maior quando o defeito está no que chega até ele. Um modelo mais caro lendo os mesmos oito trechos errados erra com mais eloquência.

Como a Veredas descobriu por que o assistente contava errado

Helena levou a Caio uma pergunta de negócio que o assistente nunca acertava: “quais condicionantes de monitoramento hídrico estão vencidas ou com laudos contraditórios, em quais empreendimentos, e com que evidência?”. Condicionante é a obrigação que o órgão ambiental impõe na licença, como medir a turbidez de um córrego a cada trimestre e entregar o laudo. Vencida quer dizer prazo passado sem laudo entregue.

Antes de trocar qualquer peça, os dois montaram um conjunto de avaliação. Helena escreveu 120 perguntas com a resposta de referência de cada uma: 40 de localização, 50 de agregação ou contagem e 30 de cruzamento entre pares de documentos. Cruzamento é comparar um documento com outro, como o laudo de 2023 com o de 2024 do mesmo poço, para achar contradição.

Rodado sobre as 120 perguntas, o assistente de busca vetorial acertou 64. O retrato por tipo de pergunta mostrou o padrão que Helena já sentia no dia a dia: 36 de 40 em localização, 21 de 50 em agregação e 7 de 30 em cruzamento. O sistema era bom em achar e ruim em juntar.

Caio então abriu cada um dos 56 erros e perguntou em qual gesto a resposta tinha quebrado. Criou quatro rótulos. Informação: o dado não existia no índice, como laudos escaneados sem texto legível. Contexto: o dado existia, mas não chegou ao modelo. Raciocínio: o dado chegou e o modelo concluiu errado, como comparar datas em formatos diferentes. Execução: a resposta quebrou no caminho, cortada ou fora do formato.

Com a regra escrita, o rótulo deixou de depender do palpite de quem lia o erro. Para conferir, Helena sorteou 15 dos 56 rótulos para revisar e discordou de 2. Os dois eram laudos que chegaram ao modelo pela metade, e ambos ficaram como erro de contexto.

Trinta e um dos 56 erros, mais da metade, eram de contexto. O dado estava no acervo e no índice, e o modelo nunca o viu. A causa ficou clara quando Caio contou os documentos que cada resposta exigia. Uma pergunta de contagem sobre condicionantes hídricas em todos os empreendimentos precisava de cerca de 300 documentos. O assistente mandava ao modelo os 8 trechos mais parecidos com a pergunta.

A conta explica o resto. Oito trechos para uma resposta que depende de 300 documentos cobrem, no máximo, 8 dividido por 300, perto de 2,7 por cento do material. Nenhum modelo conta o que não leu. E a busca por semelhança escolhe os trechos que mais se parecem com a pergunta, geralmente os mais genéricos, e não os que trazem a data de vencimento.

Os 12 erros de raciocínio pesavam mais no cruzamento. Mesmo quando os dois laudos chegavam, o modelo misturava unidades, confundia o ponto de coleta ou aceitava a data de emissão como data de amostragem. Esses erros não somem com mais contexto e voltam ao longo do curso, na trilha de confiabilidade. Os 6 erros de informação pediam outra coisa: extrair texto dos PDFs escaneados.

Daí sai também um teto. Se uma nova arquitetura consertasse todos os 31 erros de contexto e nenhum outro, o placar subiria de 64 para 95 acertos em 120. Esse número não promete nada; ele diz até onde vale investir na forma de expor o acervo antes de atacar raciocínio e extração. Proposta que prometa mais precisa explicar qual dos outros três tipos de erro também resolve.

Helena tirou da tabela uma decisão de gestão: manter o assistente atual nas perguntas de localização, em que acerta 90 por cento, e procurar outra arquitetura para agregação e cruzamento. Caio tirou uma pergunta técnica. Se o acervo tem 52 milhões de tokens e a maior janela disponível tem cerca de 1 milhão, como fazer o modelo ler tudo o que uma contagem exige?

O caso ganhou uma linha de base de 64 acertos em 120 e uma causa principal com número: 31 erros de contexto. Liste agora as perguntas de agregação que falharam por contexto e anote, ao lado de cada uma, quantos documentos a resposta de referência exige. A lista está completa quando cada pergunta tiver esse número, e toda pergunta acima de 50 documentos já não cabe no desenho de busca por trechos.