Resumo Técnico: Memória no Loop

Declaração do Problema

Agentes de linguagem operam em um loop padrão: observar, raciocinar, agir, repetir. No entanto, a memória sobre a qual eles raciocinam é tipicamente tratada como um recurso externo consultado, no máximo, uma vez por turno (recuperação por turno). Esse design é impulsionado pela premissa de que a latência de recuperação é proibitiva. Armazéns vetoriais em rede tipicamente respondem em 50–200 ms; se um agente consultar tal armazém em cada etapa de raciocínio, a latência de ponta a ponta pode inflar em até 83×. Consequentemente, a orientação atual da indústria ("memória primeiro") e os designs de sistemas racionam a recuperação para uma vez por turno ou ocultam os custos na camada de serviço via escalonamento.

O artigo argumenta que essa restrição de latência não é uma lei fundamental do design de agentes, mas um artefato de onde o armazém reside. A latência de rede (dezenas a centenas de milissegundos) torna a recuperação dentro do loop cara, enquanto um armazém em processo pode responder em ~100 µs. O problema central é se mover a memória para dentro do loop de raciocínio — lendo e escrevendo nela a cada etapa — é viável e benéfico quando a barreira da latência é removida.

Metodologia

Arquitetura Central

Os autores instanciam a "Memória no Loop" usando um armazém semântico efêmero e em processo (vxdb) encapsulado como uma primitiva de WorkingMemory (Memória de Trabalho). Este armazém suporta operações de add, recall e match. Crucialmente, o armazém é alocado por agente/tarefa e não está conectado a um serviço de rede, visando tempos de resposta de nível de microssegundos.

Configuração Experimental

O estudo emprega dois regimes experimentais primários:

1. Tarefa de Recall com Janela (Desempenho Ponta a Ponta):

   • Cenário: Uma conversa de planejamento de viagem de seis turnos onde o usuário declara cinco restrições duráveis no início da conversa. O agente deve listar todas as cinco restrições ao final.
   • Restrição: A janela de contexto é limitada a $w=4$ mensagens, fazendo com que as restrições iniciais saiam do contexto visível.
   • Condições:
     • Baseline/Aware: Sem ferramentas de memória (o modelo Aware é informado de que seu histórico é curto).
     • Notes: Instruído a reestatizar todas as restrições em cada resposta (um limite superior de "sem ferramentas").
     • Memory: Equipado com ferramentas de remember/recall sustentadas pelo armazém em processo.
   • Modelos: Testados através de uma "escada GPT-5" (gpt-5-nano, gpt-5-mini, gpt-5, gpt-5.5).

2. Tarefa de Guarda de Loop Causal (Latência vs. Resultado):

   • Cenário: Um agente processa um fluxo de alertas de segurança, decidindo entre INVESTIGATE (investigar) ou SKIP (pular) duplicatas.
   • Mecanismo: Um guarda de código verifica o armazém antes de cada ação para evitar investigações redundantes.
   • Variável: A latência do armazém é manipulada injetando atrasos de ida e volta (0 µs a 200 ms) enquanto mantém o orçamento de memória por turno fixo (100 ms).
   • Braços:
     • In-process: Velocidade em tempo real (~17.5–85 µs).
     • Delayed Ladder: Lógica idêntica com atrasos injetados (+5, +15, +30, +50, +110 ms).
     • Per-turn RAG: Padrão da indústria (recuperação uma vez por turno).
   • Métrica: Ações redundantes executadas (de um total de 12 duplicatas).

Modelagem de Custo

Os autores definem uma fronteira de viabilidade onde a memória no loop é viável se o custo de recuperação ($f \cdot c$) for negligenciável em relação ao tempo da etapa de raciocínio ($r$). Eles medem o custo completo da operação (embedding + armazém) para determinar se o acesso por etapa é "gratuito" em relação a uma etapa de LLM.

Principais Resultados

1. Viabilidade e Imposto de Latência

• Velocidade In-Process: O armazém em processo opera em uma latência mediana de 80–165 µs.
• Imposto de Latência: Com 20 recuperações no loop por turno, o tempo de bloqueio total é de ~1.7 ms para o armazém em processo. Em contraste, um armazém vetorial em nuvem (RTT de 110 ms) incorre em um imposto de 2.2 segundos por turno.
• Viabilidade: Nas velocidades in-process, um agente pode permitir ~953 recuperações por etapa (assumindo um orçamento de latência de 10%), enquanto armazéns em rede permitem menos de 1 busca por etapa, forçando o racionamento.

2. Desempenho da Tarefa (Recall de Janela)

• Falha do Baseline: Todas as execuções de baseline e "aware" pontuaram 0/5 em restrições recuperadas. A limitação da janela de contexto causou falha total, independentemente do tamanho do modelo.
• Baseline de Reestatização: Um baseline instruído que reestatizava as restrições em cada resposta alcançou 5/5, demonstrando que a tarefa é solucionável se o agente gerencia o contexto ativamente, embora isso incorra em um "aluguel" de tokens que escala com o conjunto de trabalho.
• Memória no Loop: A condição de memória no loop alcançou 3.6–4.8/5 de recall entre os modelos.
  • Análise de Falha: O armazém nunca perdeu um fato (244/244 escritas preservadas). As falhas foram exclusivamente falhas de política de leitura: os agentes sobrescreveram restrições (criando duplicatas) e então leram apenas uma vez por execução através de uma janela fixa de $k=8$, que estava congestionada por entradas redundantes. A falha foi no uso das ferramentas pelo agente, não no substrato de memória.

3. Impacto Causal da Latência (Guarda de Loop)

• Resposta Dose-Resposta Monotônica: Ações redundantes aumentaram monotonicamente com a latência do armazém sob um orçamento fixo.
  • In-process (0 ms): 0.0 ações redundantes.
  • +15 ms: 1.4–1.6 ações redundantes.
  • +110 ms (Nuvem): 7.2 de 12 ações redundantes.
• Significância Estatística: A diferença entre o in-process e a latência de 110 ms foi estatisticamente significativa ($p=0.0079$) para ambos os modelos testados.
• Mecanismo: Em 110 ms, o orçamento (100 ms) não podia pagar sequer uma busca, de modo que o guarda foi efetivamente desativado. Os "erros" não foram erros de recuperação, mas a ausência de verificações.
• Per-Turn RAG: A recuperação por turno, padrão da indústria, teve bom desempenho (0.4–0.6 ações redundantes), mas falhou estruturalmente em capturar duplicatas que surgiram dentro de um único turno, enquanto o guarda in-process capturou todas as duplicatas.

4. O Gargalo de Embedding

• O custo dominante na pilha in-loop não é o armazém, mas o embedding. APIs de embedding em rede levam 200–400 ms.
• Ao parear o armazém em processo com um embedder local pequeno (32M de parâmetros, 32 µs), a operação completa (embed + armazém) cai para **40 µs**. Isso remove a barreira final para a memória no loop.

Significância e Alegações

Contribuição Teórica: Memória de Trabalho Estendida

O artigo fundamenta suas descobertas de engenharia na Tese da Mente Estendida (Clark & Chalmers, 1998). Argumenta-se que um recurso externo torna-se "constitutivo" da cognição (ou seja, parte da memória de trabalho do agente) apenas se for:

1. Constantemente disponível.
2. Diretamente acessível sem dificuldade.
3. Automaticamente endossado.

Os autores interpretam esses dois primeiros critérios como um orçamento de latência. Uma chamada de rede de 100 ms é uma ferramenta que um agente consulta; um armazém in-process de 100 µs é um recurso que o agente possui. Quando a latência é baixa o suficiente para ser transparente à etapa de raciocínio, o armazém transita de um banco de dados externo para uma memória de trabalho estendida.

Contribuição de Engenharia

• Latência como Variável de Design: O artigo desloca a frequência de recuperação de uma restrição da camada de serviço para um eixo de design do agente. Demonstra que a latência do armazém, e não o padrão de loop, é o fator determinante.
• Elo Causal: Fornece evidência causal de que a latência do armazém sozinha determina os resultados da tarefa (ações redundantes) sob um orçamento fixo, independentemente da capacidade do modelo.
• Mudança Arquitetural: Propõe que a memória deve ser tratada como uma primitiva de loop (como um rascunho/scratchpad) alocada por tarefa, em vez de um serviço conectado.

Modéstia e Limitações

Os autores são explícitos quanto ao escopo:

• Eles não alegam que o armazém torna o modelo "mais inteligente"; os modelos ainda falharam em reconhecer duplicatas sem o guarda. O sistema teve sucesso porque o andaime (scaffold) pôde se dar ao luxo de verificar a memória.
• O baseline de "Notas" (reestatização) superou as ferramentas de memória na pequena tarefa de 5 fatos, destacando que a reestatização paga um custo por turno que cresce com o conjunto de trabalho, o que o armazém evita em escala.
• O estudo foca no aspecto temporal da memória (quando ela participa do raciocínio). Questões sobre o que reter, como organizar e o gerenciamento do ciclo de vida (esquecimento/priorização) são identificadas como trabalhos futuros.

Em conclusão, o artigo afirma que o regime "no loop" não é apenas viável, mas causalmente superior para tarefas que exigem consistência de estado dentro de um turno, desde que o substrato de memória seja in-process e pareado com um embedder local para eliminar a latência de rede.