Tudo o que você precisa saber sobre modelos de linguagem recursiva

Neste artigo, você aprenderá o que são modelos de linguagem recursiva, por que eles são importantes para o raciocínio de entrada longa e como eles diferem dos sistemas padrão de solicitação, recuperação e agentes de contexto longo.

Os tópicos que cobriremos incluem:

• Por que o contexto longo por si só não resolve o raciocínio sobre entradas muito grandes
• Como os modelos de linguagem recursivos usam um tempo de execução externo e subchamadas recursivas para processar informações
• As principais compensações, limitações e casos de uso prático desta abordagem

Vamos direto ao assunto.

Tudo o que você precisa saber sobre modelos de linguagem recursiva
Imagem por Editor

Introdução

Se você está aqui, provavelmente já ouviu falar de trabalhos recentes sobre modelos de linguagem recursivos. A ideia tem sido tendência no LinkedIn e no X e me levou a estudar o assunto mais profundamente e compartilhar o que aprendi com vocês. Acho que todos podemos concordar que os grandes modelos de linguagem (LLMs) melhoraram rapidamente nos últimos anos, especialmente na sua capacidade de lidar com grandes entradas. Este progresso levou muitas pessoas a assumir que o longo contexto é em grande parte um problema resolvido, mas não é. Se você tentou fornecer aos modelos entradas muito longas próximas ou iguais à sua janela de contexto, você deve ter notado que eles se tornam menos confiáveis. Freqüentemente, eles perdem detalhes presentes nas informações fornecidas, contradizem afirmações anteriores ou produzem respostas superficiais em vez de raciocinar cuidadosamente. Esta questão é muitas vezes referida como “podridão de contexto”que é um nome bastante interessante.

Modelos de linguagem recursivos (RLMs) são uma resposta a esse problema. Em vez de inserir cada vez mais texto em uma única passagem de avanço de um modelo de linguagem, os RLMs mudam a forma como o modelo interage com entradas longas. Neste artigo, veremos o que são, como funcionam e os tipos de problemas que foram projetados para resolver.

Por que o contexto longo não é suficiente

Você pode pular esta seção se já entender a motivação da introdução. Mas se você estiver curioso ou se a ideia não funcionou totalmente na primeira vez, deixe-me detalhar melhor.

A forma como esses LLMs funcionam é bastante simples. Tudo o que queremos que o modelo considere é fornecido como um único immediate e, com base nessas informações, o modelo gera o token de saída por token. Isso funciona bem quando o immediate é curto. No entanto, quando se torna muito longo, o desempenho começa a degradar. Isto não se deve necessariamente a limites de memória. Mesmo que o modelo consiga ver o immediate completo, muitas vezes ele não consegue usá-lo de maneira eficaz. Aqui estão alguns motivos que podem contribuir para esse comportamento:

1. Esses LLMs são principalmente modelos baseados em transformadores com um mecanismo de atenção. À medida que o immediate aumenta, a atenção se torna mais difusa. O modelo luta para se concentrar nitidamente no que importa quando precisa atender dezenas ou centenas de milhares de tokens.
2. Outro motivo é a presença de informações heterogêneas misturadas, como logs, documentos, código, histórico de chat e saídas intermediárias.
3. Por último, muitas tarefas não envolvem apenas recuperar ou encontrar um trecho relevante em um grande quantity de conteúdo. Freqüentemente, envolvem a agregação de informações em toda a entrada.

Por causa dos problemas discutidos acima, as pessoas propuseram ideias como resumo e recuperação. Estas abordagens ajudam em alguns casos, mas não são soluções universais. Os resumos apresentam perdas por natureza e a recuperação pressupõe que a relevância pode ser identificada de forma confiável antes do início do raciocínio. Muitas tarefas do mundo actual violam essas suposições. É por isso que os RLMs sugerem uma abordagem diferente. Em vez de forçar o modelo a absorver todo o immediate de uma vez, eles permitem que o modelo discover e processe ativamente o immediate. Agora que temos o contexto básico, vamos examinar mais de perto como isso funciona.

Como funciona um modelo de linguagem recursiva na prática

Em uma configuração RLM, o immediate é tratado como parte do ambiente externo. Isso significa que o modelo não lê toda a entrada diretamente. Em vez disso, a entrada fica fora do modelo, muitas vezes como uma variável, e o modelo recebe apenas metadados sobre o immediate junto com instruções sobre como acessá-lo. Quando o modelo precisa de informações, ele emite comandos para examinar partes específicas do immediate. Esse design simples mantém o contexto interno do modelo pequeno e focado, mesmo quando a entrada subjacente é extremamente grande. Para entender os RLMs mais concretamente, vamos percorrer passo a passo uma execução típica.

Etapa 1: inicializando um ambiente REPL persistente

No início de uma execução RLM, o sistema inicializa um ambiente de tempo de execução, normalmente um REPL Python. Este ambiente contém:

• Uma variável que contém o immediate completo do usuário, que pode ser arbitrariamente grande
• Uma função (por exemplo, llm_query(...) ou sub_RLM(...)) que permite ao sistema invocar chamadas de modelo de linguagem adicionais em trechos de texto selecionados

Do ponto de vista do usuário, a interface permanece simples, com uma entrada e uma saída textual, mas internamente o REPL atua como uma estrutura que permite um raciocínio escalável.

Etapa 2: invocando o modelo raiz apenas com metadados de immediate

O modelo de idioma raiz é então invocado, mas não recebe o immediate completo. Em vez disso, é dado:

• Metadados de tamanho constante sobre o immediate, como comprimento ou prefixo curto
• Instruções que descrevem a tarefa
• Instruções de acesso para interagir com o immediate por meio do ambiente REPL

Ao reter o immediate completo, o sistema força o modelo a interagir intencionalmente com a entrada, em vez de absorvê-la passivamente na janela de contexto. Deste ponto em diante, o modelo interage indiretamente com o immediate.

Etapa 3: inspecionar e decompor o immediate por meio da execução de código

O modelo pode começar inspecionando a estrutura da entrada. Por exemplo, ele pode imprimir as primeiras linhas, procurar títulos ou dividir o texto em partes com base em delimitadores. Essas operações são realizadas por meio da geração de código, que é então executado no ambiente. As saídas dessas operações são truncadas antes de serem mostradas ao modelo, garantindo que a janela de contexto não fique sobrecarregada.

Etapa 4: Emitir subchamadas recursivas em fatias selecionadas

Depois que o modelo compreender a estrutura do immediate, ele poderá decidir como proceder. Se a tarefa exigir compreensão semântica de determinadas seções, o modelo poderá emitir subconsultas. Cada subconsulta é uma chamada de modelo de linguagem separada em uma fatia menor do immediate. É aqui que entra a parte “recursiva”. O modelo decompõe repetidamente o problema, processa partes da entrada e armazena resultados intermediários. Esses resultados residem no ambiente, não no contexto do modelo.

Etapa 5: montagem e devolução da resposta ultimate

Finalmente, depois de coletadas e processadas informações suficientes, o modelo constrói a resposta ultimate. Se a saída for longa:

• O modelo o constrói incrementalmente dentro de uma variável REPL, como Last
• Uma vez Last está definido, o loop RLM termina
• O valor de Last é retornado como a resposta

Este mecanismo permite que o RLM produza saídas que excedem os limites de token de uma chamada de modelo de linguagem única. Durante todo esse processo, nenhuma chamada de modelo de idioma único precisa ver o immediate completo.

O que diferencia os RLMs dos agentes e sistemas de recuperação

Se você passar algum tempo no espaço LLM, poderá confundir essa abordagem com estruturas de agente ou geração aumentada de recuperação (RAG). No entanto, estas são ideias diferentes, mesmo que as distinções possam parecer subtis.

Em muitos sistemas de agentes, o histórico completo da conversa ou memória de trabalho é repetidamente injetado no contexto do modelo. Quando o contexto fica muito grande, as informações mais antigas são resumidas ou descartadas. Os RLMs evitam totalmente esse padrão, mantendo o immediate externo desde o início. Os sistemas de recuperação, por outro lado, dependem da identificação de um pequeno conjunto de partes relevantes antes do início do raciocínio. Isso funciona bem quando a relevância é escassa. Os RLMs são projetados para ambientes onde a relevância é densa e distribuída e onde é necessária a agregação de muitas partes da entrada. Outra diferença importante é a recursão. Nos RLMs, a recursão não é metafórica. O modelo literalmente chama modelos de linguagem dentro de loops gerados como código, permitindo que o trabalho seja dimensionado de acordo com o tamanho da entrada de forma controlada.

Custos, compensações e limitações

Também vale destacar algumas desvantagens desse método. Os RLMs não eliminam o custo computacional. Eles mudam isso. Em vez de pagar por uma única invocação de modelo muito grande, você paga por muitos modelos menores, juntamente com a sobrecarga de execução e orquestração de código. Em muitos casos, o custo whole é comparável a uma chamada padrão de contexto longo, mas a variação pode ser maior. Existem também desafios práticos. O modelo deve ser capaz de escrever código confiável. Modelos mal restritos podem gerar muitas subchamadas ou não conseguir terminar corretamente. Os protocolos de saída devem ser cuidadosamente projetados para distinguir as etapas intermediárias das respostas finais. Estes são problemas de engenharia, não falhas conceituais, mas ainda assim são importantes.

Conclusão e Referências

Uma regra prática útil é esta: se sua tarefa se tornar mais difícil simplesmente porque a entrada é mais longa, e se o resumo ou a recuperação perderem informações importantes, provavelmente vale a pena considerar um RLM. Se a entrada for curta e a tarefa simples, uma chamada de modelo de linguagem padrão geralmente será mais rápida e barata. Se você quiser explorar modelos de linguagem recursivos com mais profundidade, os seguintes recursos são pontos de partida úteis: