Memória persistente para agentes: o que guardar, por quanto tempo e como corrigir

O problema da amnésia nos agentes autónomos

Os agentes de IA atuais costumam funcionar em sessões isoladas. Quando uma interação termina, podem perder o contexto de decisões anteriores, convenções da equipa ou preferências do utilizador. Isso obriga as equipas a repetir informação e pode levar o agente a propor soluções que já tinham sido rejeitadas, gerando ineficiência e erros recorrentes.

A memória persistente procura resolver esse problema, permitindo que o agente retenha informação útil entre sessões. Mas nem tudo o que é processado merece ser guardado por tempo indeterminado. Distinguir factos duradouros de estados temporários é essencial para evitar a acumulação de dados desatualizados ou irrelevantes, que podem prejudicar as respostas.

Distinguir os diferentes tipos de memória

Convém separar quatro conceitos que são frequentemente confundidos: memória persistente, histórico da conversa, estado temporário da tarefa e cache de contexto. A memória persistente guarda factos e preferências que podem ser úteis a longo prazo. O histórico regista a conversa atual. O estado temporário acompanha o progresso de uma tarefa em curso. A cache de contexto facilita o acesso a informação recente, por exemplo para reutilizar conteúdo sem o voltar a processar.

Cada tipo tem um ciclo de vida próprio. A memória persistente deve poder ser auditada e editada; o estado temporário pode ser descartado quando a tarefa termina. Confundir estas categorias pode fazer com que o agente trate uma preferência momentânea como um facto permanente, ou que perca informação importante ao limpar a cache.

Critérios para decidir o que guardar

Nem tudo o que o agente processa deve transformar-se em memória persistente. Uma forma prática de avaliar cada dado é considerar quatro dimensões: finalidade — para que será usado?; âmbito — a quem ou a que projeto diz respeito?; fonte — quem o forneceu?; e necessidade de persistência — é provável que continue válido no futuro?

Num agente de programação, por exemplo, pode ser útil guardar a decisão de utilizar uma biblioteca específica. Já o erro de sintaxe cometido numa linha concreta tende a ser um detalhe transitório, não uma memória duradoura. A fonte também importa: a informação fornecida pelo utilizador não deve ser confundida com uma inferência do modelo. Conjeturas não devem ser guardadas como factos; se forem retidas, precisam de ser identificadas como incertas.

Como estruturar um registo de memória

Cada registo deve incluir metadados que permitam geri-lo mais tarde: o conteúdo, a proveniência, a data de criação, o âmbito de aplicação e uma condição de validade ou revisão. A data ajuda a identificar informação potencialmente desatualizada. O âmbito indica se o dado se aplica a um utilizador, a um projeto ou a um contexto mais amplo.

A condição de validade pode depender do tempo ou de um acontecimento. Por exemplo, um dado pode deixar de ser válido quando o utilizador altera um plano, ou ter de ser revisto quando este atualiza o perfil. Sem metadados desse tipo, o agente pode não conseguir distinguir o que ainda se aplica, o que deve atualizar e o que é irrelevante para a tarefa atual.

Recuperação, atualização e correção

A recuperação deve trazer informação pertinente para a tarefa atual. Pode basear-se em pesquisa lexical, que procura correspondências entre palavras, ou semântica, que procura semelhanças de significado. A pesquisa semântica pode lidar melhor com formulações diferentes, mas requer modelos de embeddings e pode acrescentar custos. A escolha do método não elimina a necessidade de avaliar se os resultados são adequados ao contexto.

Quando o utilizador corrige um dado, o sistema deve atualizar o registo correspondente e verificar se existem representações derivadas que também precisam de ser alteradas. Resumos, índices de pesquisa ou vetores podem conservar versões antigas. Se o agente ainda os puder recuperar, poderá responder com informação incorreta, mesmo que o registo principal já tenha sido corrigido.

Testar o ciclo de vida da memória

A memória deve ser testada não apenas quanto à capacidade de guardar e recuperar informação, mas também quanto à forma como lida com dados desatualizados, corrigidos ou eliminados. Os testes devem verificar se o agente recupera apenas informação pertinente, se deixa de tratar versões antigas como válidas e se respeita o âmbito do utilizador ou do projeto.

Um teste de correção pode consistir em guardar um dado, alterá-lo e perguntar novamente sobre o mesmo assunto. A resposta deve refletir a versão atual, e não uma representação derivada desatualizada. Para testar a eliminação, apague o dado e execute uma pesquisa que normalmente o recuperaria; confirme que não aparece nos resultados nem reaparece numa tarefa posterior. Os resultados devem ser observáveis, para que a equipa consiga perceber que informação influenciou a resposta.

Aplicar o modelo a diferentes agentes

A mesma política de memória não serve necessariamente para todos os produtos. Num assistente de suporte, uma preferência explicitamente indicada pode ser útil em interações futuras, mas o estado de uma verificação em curso deve permanecer temporário. A equipa deve definir que dados são necessários para prestar o serviço e em que âmbito podem ser recuperados.

Num agente de programação, as decisões de arquitetura e as convenções do projeto podem ajudar a evitar recomendações já rejeitadas. O âmbito deve deixar claro se a memória pertence ao projeto ou a uma pessoa; não se deve presumir que uma decisão individual se aplica a toda a equipa. Num agente de investigação, hipóteses de trabalho, observações e resultados provisórios precisam de proveniência e contexto, para não serem tratados como conclusões estabelecidas quando uma tarefa posterior os recuperar.

Em todos os cenários, a política deve separar o que é útil de guardar do que é apenas acessório à interação. Deve também definir como corrigir, rever e eliminar os dados e como testar essas operações. Os exemplos ilustram questões de conceção; não determinam as capacidades de qualquer implementação concreta. As funções de armazenamento, edição, caducidade e eliminação dependem do sistema utilizado e têm de ser verificadas na sua documentação e através de testes próprios.

Conclusão: memória útil exige gestão ao longo do tempo

A memória persistente não é simplesmente um histórico mais longo. É uma decisão de produto e de engenharia sobre que informação deve sobreviver ao fim de uma sessão, a quem diz respeito, durante quanto tempo pode ser útil e como será corrigida ou removida. Separá-la do histórico, do estado temporário da tarefa e da cache ajuda a evitar que cada dado processado se transforme automaticamente num registo duradouro.

Um ciclo de vida robusto começa por definir finalidade, âmbito e proveniência; continua com regras de validade e recuperação pertinente; e inclui mecanismos verificáveis de correção e eliminação. A equipa deve testar não apenas se um dado aparece quando esperado, mas também se deixa de aparecer quando foi corrigido, se tornou obsoleto ou foi eliminado. A documentação de uma implementação pode descrever funções concretas, mas não substitui os testes necessários para confirmar o comportamento do sistema completo, incluindo índices e representações derivadas.

Continue a explorar

Correções e transparência

Se encontrar informação incorreta ou desatualizada, envie-nos a página e a fonte que devemos rever.