IA

Meta põe uma segunda IA a vigiar a memória da primeira

Investigadores da Meta propõem um agente de memória separado para manter tarefas longas sob controlo. A ideia: menos esquecimentos, menos loops idiotas, mais trabalho feito à primeira.

Meta põe uma segunda IA a vigiar a memória da primeira

Os agentes de IA estão a ficar mais autónomos, mas continuam a falhar em coisas básicas: esquecem restrições, repetem comandos que já falharam, redescobrem erros que tinham acabado de diagnosticar. A Meta decidiu atacar isto com um truque pouco glamoroso mas muito pragmático: pôr uma segunda IA a servir de coach de memória da primeira.

No artigo científico, os investigadores baptizam o problema de “behavioral state decay”: o estado que devia guiar o agente vai-se espalhando por um histórico cada vez maior, perde-se no meio da janela de contexto ou cai fora dela. Mesmo quando a informação ainda lá está, o modelo simplesmente deixa de a usar de forma consistente. A resposta óbvia tem sido dar mais contexto, mais tokens, mais histórico. A Meta diz que isso não chega e, honestamente, os comportamentos actuais dos agentes confirmam.

Em vez de mais contexto bruto, o que o sistema da Meta faz é decidir quando a memória importa. Um agente principal, o “action agent”, continua a fazer o trabalho normal. Ao lado corre um “memory agent” separado, que a cada N passos lê uma janela dos últimos eventos, actualiza um banco de memória estruturado e decide se vale a pena injectar um lembrete curto na próxima chamada do agente de acção. Se sim, envia um aviso específico. Se não, cala-se. É um módulo de encaixar, não obriga a redesenhar todo o agente, o que o torna compatível com frameworks de agentes que já estão a ser montados por empresas que querem pôr estes sistemas em produção, como se vê no OpenAI Presence.

O banco de memória tem três zonas. Um campo de estado privado, com progresso e riscos, que nunca é mostrado ao agente de acção. Uma “Knowledge Memory” com factos estáveis: requisitos, caminhos de ficheiros, configurações. E uma “Procedural Memory” com o que já foi tentado e o resultado: comandos que falharam, hipóteses rejeitadas, correcções que funcionaram. O memory agent só mexe nisto através de chamadas de ferramentas pré-definidas, não pode reescrever tudo como quer. Depois decide se reactiva uma memória concreta e se envia um lembrete direccionado. Escolher não intervir também é uma decisão explícita.

Nos testes, usaram Claude Opus 4.6 como agente de memória e Claude Sonnet 4.5 como agente de acção. No benchmark Terminal-Bench 2.0, que avalia agentes em ambientes de linha de comandos realistas, a taxa de sucesso à primeira tentativa subiu de 38 para 46 por cento. No tau2-Bench, focado em uso de ferramentas em contextos de aviação, retalho e telecom, a média task-weighted foi de 55 para 62 por cento. Nada de milagres, mas são ganhos concretos num cenário em que cada falha custa tempo, tokens e, em contexto empresarial, dinheiro.

Os resultados variam por domínio: aviação e retalho sobem cerca de 10 pontos percentuais, telecom quase não mexe. Ou seja, não há bala de prata, há um padrão: tarefas com regras e requisitos relativamente estáveis parecem beneficiar mais deste tipo de memória estruturada. Para um mercado que está a experimentar agentes a mexer em sistemas reais, inclusive com riscos bem mais sérios como discutimos em quem paga quando os agentes de IA começam a fazer hacking a sério, ter um “segundo cérebro” dedicado a lembrar restrições e falhas passadas é menos glamour que novos modelos gigantes, mas provavelmente mais útil. Meta aqui não está a tentar vender magia, está a admitir que os agentes esquecem-se do óbvio e a colar por cima um supervisor discreto para reduzir o estrago.

Fonte: The Decoder

Newsletter

Os artigos que importam, duas vezes por semana.

Terça e sexta, cinco minutos de leitura. Sem spam, cancelas quando quiseres.

Comentários · 0