Janela de contexto esquece o que importa: engenheiro constroi motor de memoria com curva de Ebbinghaus para agentes de IA

O problema estrutural das janelas de contexto

A maioria dos sistemas de memória para agentes de IA usa uma janela deslizante (sliding window): se um fato não é mencionado nas últimas N interações, ele é simplesmente descartado. O problema é que essa abordagem trata da mesma forma uma instrução fundamental dada no turno 1 e um log de debug irrelevante do turno 40 — o que for mais antigo perde, independentemente de quantas vezes foi usado.

Emmimal P Alexander, engenheiro e autor no Towards Data Science, construiu um motor de memória com decaimento reforçado por uso baseado na curva de esquecimento de Hermann Ebbinghaus — um psicólogo alemão que, em 1885, fez os primeiros experimentos sobre como a memória humana se degrada ao longo do tempo. O resultado: 100% de taxa de retenção de fatos fundamentais contra 0% do baseline com janela de recência pura, em 50 sessões com seeds diferentes.

O código é open source, determinístico e tem zero dependências externas — roda apenas com a biblioteca padrão do Python. Está disponível no GitHub em github.com/Emmimal/memory-decay-engine.

Como funciona o motor de decaimento

O coração do sistema é a curva de esquecimento de Ebbinghaus: a cada vez que um item de memória é acessado (recall), sua estabilidade é reforçada de forma não linear, empurrando o horizonte de expiração para mais longe. A fórmula de reforço é:

S_novo = S_antigo × (1 + ln(1 + contagem_de_recalls))

Na prática, isso significa que um fato acessado 4 vezes nas primeiras 45 interações de uma sessão de 150 turnos alcança uma estabilidade de aproximadamente 292. Quando o sistema pergunta por esse fato no turno 150 — 111 turnos depois do último acesso — a pontuação de retenção ainda está em 0,684, muito acima do limiar de evicção de 0,20.

O baseline com janela deslizante, em contraste, descarta o fato assim que ele ultrapassa o limite fixo de 15 turnos sem uso. Aos 36 turnos sem acesso, o fato some — e quando a sessão pergunta por ele no turno 39, o sistema simplesmente retorna silêncio. Não há crash, não há warning, não há log. A resposta chega errada ou incompleta.

Onde isso importa na prática

O padrão que o motor resolve aparece em vários cenários reais de produção:

• Agentes de código: Uma instrução crítica dada no primeiro dia (“nunca edite o arquivo X”) é esquecida após dezenas de turnos de trabalho, e o agente quebra a base de código.
• Chatbots de suporte: Em threads longos de troubleshooting, o bot esquece os dados da conta do usuário e volta a fazer perguntas que já foram respondidas.
• Pipelines RAG: Fatos centrais para a tarefa são descartados porque não foram mencionados nas últimas interações, comprometendo a resposta final.

Se suas sessões são curtas e tudo cabe na janela de contexto, você não precisa disso. Mas se o padrão for estabelecer algo importante no início → silêncio prolongado → precisar recuperar no final, o motor de decaimento resolve onde a janela fixa quebra.

Os bugs que quase invalidaram tudo

Alexander documenta dois erros que encontrou durante o desenvolvimento e que quase comprometeram os resultados:

Bug 1 — Estabilidade inicial muito baixa: O valor padrão inicial de estabilidade era 2.0. Com esse valor, um fato registrado no turno 1 e nunca acessado decaía abaixo do limiar de evicção já no turno 3 — antes mesmo do primeiro recall programado. O motor estava descartando fatos antes que tivessem chance de ser reforçados. A correção foi aumentar a estabilidade baseline para 8.0, garantindo ~13 turnos de período de graça.

Bug 2 — Benchmark estruturalmente impossível de passar: Na primeira versão, os recalls eram agendados com amostragem uniforme aleatória ao longo da sessão. Isso fazia o primeiro recall cair muito depois do período de graça, matando os dois motores antes de qualquer medição real. O baseline marcava 0.000 com desvio padrão zero — um resultado sem variância em 50 seeds é uma red flag, não uma vitória. A solução foi adotar um agendamento com intervalos espaçados (3, 8, 20, 45, 90, 150 turnos) com jitter multiplicativo, imitando a repetição espaçada real.

O caso de falha: onde a vantagem desaparece

Alexander faz questão de documentar o limite honesto do mecanismo. Quando um fato é registrado uma única vez e nunca mais é acessado, o motor de decaimento tem desempenho idêntico ao baseline com janela de recência. Ambos marcam zero. O mecanismo não resgata fatos que ninguém usa. Ele recompensa, especificamente, o que é reutilizado.

“Prefiro publicar a afirmação verdadeira e restrita do que uma afirmação ampla que desmorona no seu próprio caso limite.” — Emmimal P Alexander

Por que isso importa agora

Em julho de 2026, com agentes de IA operando em sessões cada vez mais longas — codificação multi-dia, research loops autônomos, atendimento ao cliente com dezenas de interações — o gargalo não é mais o tamanho da janela de contexto dos modelos. É a qualidade da gestão do que fica dentro dela.

Aumentar a janela não resolve: uma janela grande o suficiente para sobreviver a 100 turnos de silêncio deixa de ser um mecanismo de poda e vira um depósito de tudo. A pergunta certa não é “quando isso foi tocado pela última vez?”, mas sim “quanto do sistema depende de essa informação estar correta?”

O motor de decaimento por reforço responde a essa pergunta diretamente, e o faz de forma determinística, auditável e com zero dependências — um lembrete de que, às vezes, a solução para problemas de IA de ponta vem de um paper de psicologia de 140 anos atrás.