O problema da janela de contexto em documentos grandes
Quem já tentou analisar documentos extensos com modelos de linguagem grandes (LLM, do inglês Large Language Model) conhece bem o problema: em algum momento, o documento simplesmente não cabe na janela de contexto do modelo. E quando isso acontece, ou a requisição falha, ou o modelo trabalha com informações incompletas — o que compromete diretamente a qualidade das respostas.
Considere uma tarefa comum de análise financeira: comparar métricas de dois anos consecutivos de relatórios anuais de uma empresa. Cada relatório pode ter entre 300 e 500 páginas. Somando relatórios de analistas, documentos da SEC e materiais complementares, o total facilmente chega a milhões de caracteres. Mesmo os maiores contextos disponíveis hoje têm um teto — e o famoso problema do “lost in the middle” (informação perdida no meio do contexto) ainda afeta modelos mesmo quando o documento tecnicamente cabe.
A AWS publicou uma abordagem para contornar essa limitação estrutural usando Amazon Bedrock AgentCore em conjunto com o Strands Agents SDK. A técnica é chamada de Modelos de Linguagem Recursivos (RLM, do inglês Recursive Language Models).
O que são Modelos de Linguagem Recursivos (RLM)
Os RLMs foram introduzidos por Zhang et al. no artigo arXiv:2512.24601 e propõem uma mudança de perspectiva: em vez de tentar colocar o documento inteiro dentro da janela de contexto, o modelo passa a tratar o documento como um ambiente externo com o qual ele interage programaticamente.
Na prática, o modelo recebe apenas a pergunta do usuário e uma descrição do ambiente disponível. A partir daí, ele escreve código para buscar, fatiar e analisar o documento de forma iterativa. Quando precisa de compreensão semântica de uma seção específica, ele delega essa análise a uma chamada de sub-LLM, mantendo os resultados em memória de trabalho como variáveis Python — sem consumir espaço na janela de contexto principal.
Isso cria uma estrutura recursiva: o LLM raiz orquestra a análise via código, chamando sub-LLMs conforme necessário para tarefas semânticas, enquanto o documento completo jamais entra diretamente na janela de contexto do modelo orquestrador.
Arquitetura da solução com Amazon Bedrock AgentCore
A implementação descrita pela AWS combina três componentes que trabalham juntos:
- Agente LLM raiz, construído com o Strands Agents SDK, que recebe a pergunta do usuário e decide qual código executar.
- Sessão do Amazon Bedrock AgentCore Code Interpreter, rodando em modo de rede pública (
PUBLIC), com o documento completo carregado como variável Python. - Função
llm_query()injetada no sandbox, que chama o Amazon Bedrock diretamente de dentro do Code Interpreter — mantendo os resultados dos sub-LLMs em variáveis Python, sem que eles retornem para o contexto do LLM raiz.
O modo de rede pública do Bedrock AgentCore Code Interpreter é essencial aqui: ele permite que o sandbox faça chamadas de saída para a API do Amazon Bedrock. O estado persistente da sessão garante que variáveis, resultados intermediários e dados extraídos se acumulem ao longo de múltiplas execuções de código — funcionando como uma memória de trabalho que persiste durante toda a análise.
Como implementar: passo a passo
Pré-requisitos
Para seguir a implementação, são necessários:
- Uma conta AWS com acesso aos modelos fundacionais do Amazon Bedrock.
- Python 3.10 ou superior.
- A Interface de Linha de Comando da AWS (AWS CLI) configurada com as credenciais adequadas.
- Familiaridade com Python e uso básico do AWS SDK (Boto3).
- Um Amazon Bedrock AgentCore Code Interpreter configurado em modo de rede
PUBLIC. - Permissões do Gerenciamento de Identidade e Acesso (IAM) para:
bedrock:InvokeModel,bedrock-agentcore:StartCodeInterpreterSession,bedrock-agentcore:InvokeCodeInterpreterebedrock-agentcore:StopCodeInterpreterSession.
Passo 1: Iniciar uma sessão do Code Interpreter e carregar o documento
O primeiro passo é criar uma sessão do Amazon Bedrock AgentCore Code Interpreter e escrever o documento no sandbox:
import boto3
import json
# Start a Bedrock AgentCore Code Interpreter session
client = boto3.client('bedrock-agentcore', region_name='us-east-1')
response = client.start_code_interpreter_session(
codeInterpreterIdentifier=code_interpreter_id,
name="rlm-session",
sessionTimeoutSeconds=3600
)
session_id = response["sessionId"]
# Write the document to the sandbox
client.invoke_code_interpreter(
codeInterpreterIdentifier=code_interpreter_id,
sessionId=session_id,
name="writeFiles",
arguments={"content": [{"path": "_context.txt", "text": document}]}
)Passo 2: Inicializar o documento e definir a função llm_query() dentro do sandbox
Dentro do sandbox, o documento é carregado e a função llm_query() é definida para que as chamadas de sub-LLM possam ser feitas diretamente de dentro do Code Interpreter:
# Runs inside the Bedrock AgentCore Code Interpreter sandbox
with open('_context.txt', 'r') as f:
context = f.read()
def llm_query(prompt: str) -> str:
"""Query a sub-LLM from within the sandbox."""
response = bedrock_client.invoke_model(
modelId=sub_model_id,
body=json.dumps({
"anthropic_version": "bedrock-2023-05-31",
"max_tokens": 4096,
"messages": [{"role": "user", "content": prompt}]
})
)
result = json.loads(response['body'].read())
return result['content'][0]['text']Passo 3: Criar o agente Strands e executar a consulta
Com o ambiente preparado, basta criar um agente Strands com uma ferramenta execute_python que executa código na sessão e enviar a pergunta:
from strands import Agent
agent = Agent(
model="us.anthropic.claude-sonnet-4-5-20250929-v1:0",
system_prompt=rlm_system_prompt,
tools=[execute_python],
)
answer = agent("What are the key revenue trends across these reports?")O agente escreve e executa código Python de forma iterativa para explorar o documento, extrair seções relevantes e chamar llm_query() quando precisar de análise semântica de trechos específicos.
Resultados: RLM vs. abordagens tradicionais
A AWS avaliou a abordagem em dois subconjuntos do benchmark LongBench v2, comparando três estratégias:
- Base: o documento completo é enviado diretamente ao modelo em uma única chamada de API com janela de contexto de 200 mil tokens.
- Long Context: uso da janela estendida de 1 milhão de tokens do Claude, que suporta entradas maiores mas ainda tem limite superior e pode sofrer com o problema do “lost in the middle”.
- RLM: a abordagem descrita neste post.
QA Financeiro Multi-Documento (15 questões)
Os resultados para o subconjunto de QA Financeiro foram os seguintes:
- A abordagem Base atingiu taxa de sucesso de 46,7% e precisão de 33,3% (Claude Haiku 4.5).
- A abordagem Long Context atingiu 93,3% de sucesso e 60–66,7% de precisão, dependendo do modelo.
- O RLM atingiu 100% de taxa de sucesso em todas as configurações avaliadas, com precisão variando de 66,7% (Haiku 4.5 e Sonnet 4.5) a 80,0% (Claude Opus 4.6 + Haiku 4.5 como sub-LLM).
- Para referência, a precisão de especialistas humanos no mesmo benchmark é de 40%.
Compreensão de Repositórios de Código (50 questões)
O segundo subconjunto testou a capacidade de navegar por grandes bases de código — um cenário especialmente adequado para exploração programática. Os resultados foram igualmente expressivos:
- Base: 30% de sucesso e 20% de precisão.
- Long Context: 60% de sucesso e 42–46% de precisão.
- RLM: 100% de sucesso e precisão entre 64% e 76% dependendo do modelo raiz.
Três conclusões dos resultados
1. O RLM elimina falhas por limite de contexto. Ao desacoplar o tamanho do documento da janela de contexto, o RLM processa 100% das questões — enquanto Base e Long Context falham em parte delas.
2. O RLM melhora a precisão na maioria dos modelos. O maior ganho foi observado no Claude Haiku 4.5 (de 33,3% para 66,7%). Modelos mais fortes como Sonnet 4.6 e Opus 4.6 também melhoraram, mas com ganhos menores. O Claude Sonnet 4.5 não apresentou melhora sobre o Long Context baseline, sugerindo que os ganhos dependem da capacidade do modelo raiz de decompor a tarefa em sub-consultas eficazes.
3. A escolha do sub-LLM tem impacto limitado. Nos experimentos, usar o Claude Haiku 4.5 como sub-LLM em vez do mesmo modelo principal não produziu diferença significativa de precisão. O desempenho é determinado principalmente pela capacidade do modelo raiz de gerar sub-consultas eficientes.
Como o modelo trabalha na prática
Para ilustrar o funcionamento real, a AWS descreve uma sequência representativa de um dos casos de avaliação. O modelo precisa comparar métricas financeiras em dois relatórios anuais que somam aproximadamente 1,5 milhão de caracteres.
Primeiro, o modelo busca marcadores estruturais para entender o layout do documento:
matches = re.findall(r'Table of Contents|ANNUAL REPORT', context)Em seguida, fatia seções específicas para localizar tabelas de receita:
revenue_section = context[450000:500000]
print(revenue_section)Para análise semântica, delega ao sub-LLM:
analysis = llm_query(f"Compare these revenue figures: {chunk}")Por fim, agrega os resultados de múltiplas seções e chega à resposta final.
Considerações práticas
A AWS destaca três pontos importantes para quem for adotar o RLM em produção:
Latência. O RLM troca latência por capacidade. Nas avaliações, execuções individuais variaram de cerca de 10 segundos para perguntas simples a alguns minutos para questões complexas com contextos grandes. Para processamento em lote ou análise offline, esse tradeoff é bem justificado. Para aplicações em tempo real, vale avaliar se a tarefa realmente exige processar documentos além da janela de contexto do modelo.
Custo. Cada execução do RLM envolve múltiplas invocações de modelo — tanto o raciocínio iterativo do LLM raiz quanto as chamadas de sub-LLM dentro do sandbox. Para workloads sensíveis a custo, usar um modelo menor (como o Haiku 4.5) como sub-modelo e um modelo maior como raiz é uma estratégia eficaz para reduzir custos sem comprometer a precisão.
Engenharia de prompt. O prompt de sistema influencia diretamente a eficiência do modelo no uso das ferramentas. Sem orientações claras, modelos tendem a fazer chamadas desnecessárias ao sub-LLM para validar o próprio raciocínio ou imprimir resumos intermediários verbosos. Instruções precisas sobre quando usar execução de código versus raciocínio direto reduzem chamadas desperdiçadas e melhoram a latência.
Limpeza de recursos
Para evitar cobranças contínuas, a sessão do Amazon Bedrock AgentCore Code Interpreter deve ser encerrada ao final da análise:
client.stop_code_interpreter_session(
codeInterpreterIdentifier=code_interpreter_id,
sessionId=session_id
)Se um recurso de Code Interpreter dedicado foi criado apenas para esse teste, ele pode ser excluído pelo console do Amazon Bedrock AgentCore ou pela AWS CLI.
Conclusão
Os Modelos de Linguagem Recursivos oferecem um caminho prático para processar documentos que excedem as janelas de contexto dos modelos atuais. Combinando o Amazon Bedrock AgentCore com o Strands Agents SDK, é possível implementar RLM para raciocinar sobre dados de entrada arbitrariamente longos através de execução iterativa de código e chamadas de sub-LLM.
Os resultados dos benchmarks são expressivos: Claude Opus 4.6 com RLM alcança 80% de precisão no LongBench v2 Financial QA — contra 66,7% do Long Context com janela de 1 milhão de tokens e 40% de especialistas humanos. Claude Sonnet 4.5 com RLM atinge 76% no LongBench v2 Code Repository QA — contra 20% do prompting base com janela de 200 mil tokens e 46% do Long Context.
Tarefas que exigem raciocínio sobre contextos longos — análise financeira, compreensão de repositórios de código, pesquisa em ciências da saúde e ciências da vida, revisão jurídica ou auditoria de conformidade — podem se beneficiar diretamente desse padrão arquitetural.
Recursos adicionais
- Amazon Bedrock AgentCore — documentação do serviço e capacidades para construir agentes prontos para produção.
- AgentCore Code Interpreter — documentação da ferramenta de interpretação de código usada nesta implementação.
- Strands Agents SDK — SDK de código aberto usado para construir a camada de orquestração do RLM.
Referências
- Zhang, A. L., Kraska, T., & Khattab, O. (2025). Recursive Language Models. arXiv:2512.24601
- Bai, Y., Tu, S., Zhang, J., Peng, H., Wang, X., Lv, X., Cao, S., Xu, J., Hou, L., Dong, Y., Tang, J., & Li, J. (2024). LongBench v2: Towards Deeper Understanding and Reasoning on Realistic Long-context Multitasks. arXiv:2412.15204
Fonte
Break the context window barrier with Amazon Bedrock AgentCore (https://aws.amazon.com/blogs/machine-learning/break-the-context-window-barrier-with-amazon-bedrock-agentcore/)
Leave a Reply