Contexto editável para agentes: memória de trabalho não é autoridade

Pesquisadores de Meta, MIT e Universidade de Washington apresentaram Context Language Models, uma abordagem em que o modelo trata o contexto como um arquivo que pode editar.[4] Em vez de deixar toda a compactação para mecanismos externos, ele decide o que preservar, reescrever ou remover ao longo da tarefa.[4]

Minha leitura é que isso transforma memória em parte da execução. O benefício potencial vem acompanhado de uma pergunta mais importante que o tamanho da janela: quais informações o agente não pode apagar ou promover a instruções?

O que muda para quem desenvolve

A pesquisa explora modos zero-shot, aprendizado em contexto e aprendizado por reforço, distinguindo orientação de modelos existentes de treinamento específico para essa capacidade.[4] Entre os resultados zero-shot citados, o BrowseComp-Plus teve 11,4% mais acurácia com 21,5% menos FLOPs.[4] No aprendizado em contexto, o ganho no ContextBench chegou a 35,9 pontos percentuais, com menor computação.[4]

Esses números dão motivo para experimentar, não para prometer uma redução equivalente na conta da API. O resultado a medir em um agente de desenvolvimento é conclusão correta com preservação de restrições, não apenas um contexto menor.

Eu separaria a arquitetura em duas camadas. A primeira conteria fontes originais, permissões e critérios de aceite, protegidos contra edição pelo agente. A segunda seria uma memória de trabalho revisável, com hipóteses, progresso, erros encontrados e próximas verificações. A distinção evita que uma nota produzida durante a tarefa passe a valer como autorização.

Como aplicar

Monte um experimento isolado com tarefas longas que já tenham resposta verificável. Compare o mecanismo atual de compactação com uma memória editável, usando os mesmos dados, ferramentas e orçamento.

Inclua fatos que só serão necessários depois de várias etapas: uma exceção de domínio, um limite operacional e uma tentativa que falhou. Avalie se o agente ainda recupera esses elementos quando precisa decidir, sem depender de uma lembrança vaga do resumo.

Persista versões da memória e as diferenças entre elas. O relatório do experimento deve mostrar conclusão, perda de fatos críticos, consumo, necessidade de recuperação e mudanças indevidas de instruções. Faça também um teste com texto malicioso em um documento de entrada, claramente identificado como dado não confiável. O aceite exige que ele não seja convertido em regra permanente.

Não use credenciais reais ou acesso de escrita à produção nesse piloto. A comparação deve permitir reexecutar a tarefa e investigar por que determinada informação desapareceu.

Cuidados e limites

Os pesquisadores reconhecem que o modelo pode apagar informação importante sem conseguir recuperá-la e que editar contexto abre espaço para persistência de injeções de prompt ou instruções produzidas pelo próprio modelo.[4] Mais controle sobre a memória não garante melhor julgamento sobre o que merece permanecer.

A reportagem também registra ressalvas sobre os testes escolhidos e sobre reescritas que podem invalidar cache, com limitações no mecanismo alternativo usado na pesquisa.[4] Portanto, medir apenas FLOPs deixa parte da realidade operacional de fora.

A proposta merece um laboratório com histórico de alterações e recuperação. Não merece liberdade para reescrever as regras de segurança. Memória de trabalho é ferramenta; autoridade deve continuar fora dela.

Fonte

[4] Fonte: InfoQ