Memória ativa vs. persistente na IA: como a IA se lembra, recupera informações e esquece

Memória ativa é a informação que um sistema de IA tem disponível para a tarefa que está realizando naquele momento. Memória persistente é a informação que o aplicativo ao redor mantém para que possa ser usada novamente mais tarde. A relação entre as duas determina se um assistente consegue dar continuidade a um projeto, aplicar uma preferência, corrigir uma suposição desatualizada ou deixar de trazer à tona algo que deveria ter esquecido.

Imagine um assistente ajudando você a preparar um relatório de pesquisa. Durante uma conversa, ele pode consultar o esboço, suas edições mais recentes e as fontes que você acabou de fornecer. Se você iniciar outra conversa uma semana depois, essa continuidade dependerá de um mecanismo diferente: se o aplicativo salvou as informações relevantes, consegue encontrá-las e as fornece novamente ao modelo.

Por isso, uma IA pode parecer se lembrar de um detalhe e, ao mesmo tempo, esquecer outro da mesma conversa. Lembrar-se envolve uma cadeia de operações. Pode haver uma falha na captura, no armazenamento, na busca, na seleção, na interpretação ou na atualização das informações.

Este guia analisa essa cadeia em detalhes. Para conhecer a taxonomia mais ampla da memória episódica, semântica e procedural, veja nossa introdução aos tipos de memória de agentes de IA. Aqui, o foco está na fronteira entre o que está ativo agora e o que pode persistir além da tarefa atual.

O que significam, na prática, memória ativa e memória persistente?

Esses termos descrevem distinções arquiteturais úteis, mas não formam um par universalmente padronizado. Interfaces de produtos e artigos de pesquisa usam “memória de trabalho”, “memória de curto prazo”, “contexto”, “estado” e “memória de longo prazo” de maneiras que se sobrepõem. Por isso, uma explicação precisa precisa definir os termos.

Neste artigo, contexto ativo significa as informações fornecidas ao modelo para gerar sua resposta atual: instruções, mensagens, resultados selecionados de ferramentas, conteúdo recuperado e outras entradas que o modelo pode processar. O estado ativo da tarefa é mais abrangente. Pode incluir um plano, uma lista de verificação ou variáveis que o aplicativo mantém, mas ainda não inseriu no contexto do modelo. Usamos memória ativa como termo abrangente e prático para esse conjunto de trabalho atual, distinguindo os dois conceitos sempre que necessário.

Memória persistente é a informação retida que permanece após o fim de uma resposta ou sessão e continua disponível para uso posterior. Pode ser uma preferência salva, uma nota de projeto, um registro de evento, um campo estruturado de banco de dados ou um ponto de controle que permite retomar uma tarefa inacabada. Persistência diz respeito à retenção; não garante que a informação seja compartilhada em todas as conversas.

Há, portanto, duas perguntas distintas: A informação ainda existe? e O modelo a receberá quando precisar dela? Uma transcrição salva pode responder à primeira pergunta sem resolver a segunda.

A exceção importante: o estado de curto prazo pode ser salvo

“Curto prazo” nem sempre significa “armazenado apenas em memória RAM volátil”. O estado de trabalho de uma conversa pode ser salvo em um ponto de controle em um banco de dados e retomado após uma interrupção. A documentação de memória do LangChain, por exemplo, distingue o estado associado a uma conversa, que é mantido por meio de pontos de controle, da memória de longo prazo, organizada em espaços de nomes separados.

Imagine um agente de suporte que pausa enquanto aguarda que um cliente envie um comprovante. O ponto de controle salvo pertence àquele caso de suporte. Ele é duradouro, mas não deve se tornar automaticamente um fato geral sobre o cliente nem aparecer em solicitações sem relação com o caso.

Uma maneira útil de avaliar qualquer recurso de memória é considerar três dimensões: sua duração, seu escopo e sua disponibilidade para a chamada atual do modelo. Um rótulo como “longo prazo” não responde por completo a nenhuma dessas perguntas.

Memória ativa vs. persistente: visão geral

O mesmo fato pode aparecer nas duas colunas. Uma preferência de projeto salva é persistente; a cópia inserida no prompt de hoje é ativa. Remover essa cópia do prompt não significa necessariamente excluir o original salvo.

O que acontece durante uma única resposta de IA?

Em uma aplicação típica de modelo de linguagem, o software que a envolve monta uma entrada, o modelo gera uma saída e o software decide o que acontece em seguida. A entrada pode conter a conversa visível, mas também pode incluir instruções do sistema, descrições de ferramentas, notas recuperadas e informações que o usuário não vê na transcrição do chat.

Esse contexto montado é a evidência imediata do modelo. Se uma mensagem anterior já não estiver incluída, o modelo não poderá recuperar seu conteúdo exato com segurança apenas porque a aplicação o exibiu antes. Ele pode inferir uma resposta plausível com base nas pistas ao redor, mas inferir é diferente de lembrar.

Uma ferramenta amplia o que o sistema pode acessar. O modelo pode solicitar um arquivo de projeto, receber seu conteúdo e usá-lo em uma resposta posterior. O arquivo estava disponível para a aplicação antes de se tornar uma evidência ativa. Essa distinção explica por que um agente pode ter acesso a um grande arquivo sem precisar lê-lo inteiro a cada interação.

Internamente, as implementações de transformers também mantêm um estado computacional, incluindo caches usados para evitar a repetição de operações. Esses mecanismos são úteis para tornar a inferência mais eficiente, mas não devem ser confundidos com um registro editável, que respeita permissões, das preferências do usuário ou do histórico do projeto. Uma resposta mais rápida não comprova que uma memória pessoal tenha sido criada.

Por que uma janela de contexto maior não resolve o problema da memória

Uma janela de contexto maior permite que uma aplicação forneça mais material de uma só vez. Isso pode ser valioso quando a resposta depende de relações entre partes de um documento extenso ou entre várias fontes relacionadas. Mas não determina qual material deve ser preservado, qual versão é a oficial nem se o usuário pode acessá-lo.

Além disso, inserir informações em uma janela de contexto não garante que o modelo as utilizará corretamente. O estudo Perdido no meio mostrou que o desempenho dos modelos testados podia variar conforme a posição das evidências relevantes em entradas longas. O resultado alerta para a necessidade de avaliar o uso efetivo do contexto, em vez de tratar a capacidade anunciada como garantia de lembrança; não é uma previsão fixa de desempenho para todos os modelos mais recentes.

Suponha que o arquivo de um projeto contenha quarenta conversas sobre uma data de lançamento. Trinta e nove mencionam a data original, e a última alteração aprovada a muda. Fornecer as quarenta conversas cria um problema de leitura e de autoridade das informações. Um registro atualizado com cuidado, vinculado à alteração aprovada, pode facilitar a apuração da resposta pertinente.

Portanto, contextos longos e recuperação seletiva podem se complementar. A recuperação encontra um conjunto útil de evidências; um contexto suficientemente amplo permite que o modelo examine essas evidências em conjunto. A escolha do projeto depende da tarefa, do volume do material de origem e das consequências de deixar passar uma ressalva.

Como as informações se tornam memória persistente

Uma memória duradoura começa com a decisão de gravar informações. Uma aplicação pode salvar uma instrução explícita do usuário, extrair um fato candidato de uma conversa, guardar um evento ou criar um resumo. Cada caminho produz um tipo diferente de evidência.

“Para o Projeto Cedar, use unidades métricas” é uma preferência explícita do projeto. “O usuário parece preferir unidades métricas” é uma inferência. “Os três últimos relatórios do Cedar usaram unidades métricas” é uma observação. Um registro útil preserva essas diferenças, em vez de reduzi-las a uma afirmação sem ressalvas sobre todas as tarefas futuras.

O que um registro útil contém

Para um assistente hipotético de projeto, um registro poderia incluir a declaração, o identificador do projeto, o usuário ou a organização a que pertence, a interação de origem, um carimbo de data e hora, um status de validade e qualquer exceção. Esses campos permitem perguntar de onde veio a informação e se ela ainda se aplica.

{
  "scope": "project:cedar",
  "statement": "Use metric units in project reports",
  "source_type": "explicit_user_instruction",
  "source_ref": "conversation_17/message_8",
  "status": "current",
  "exception": "Client edition may require dual units"
}

Este é um esquema ilustrativo, não um padrão universal. Seu propósito é mostrar por que uma memória deve conter mais do que uma frase. Uma referência à fonte facilita a verificação; o escopo impede generalizações excessivas; um campo de status permite fazer correções.

Gravações imediatas versus processamento em segundo plano

Uma gravação imediata pode tornar uma correção explícita disponível já na solicitação seguinte. O processamento em segundo plano pode examinar uma interação concluída, combinar duplicatas ou produzir um resumo mais ponderado. A documentação do LangChain descreve as duas abordagens e suas contrapartidas, incluindo o trabalho adicional introduzido no fluxo de resposta imediata.

Um projeto prático poderia salvar imediatamente uma preferência confirmada e processar mais tarde uma longa sessão de pesquisa. Ainda assim, precisa lidar com o intervalo entre essas etapas. Se o sistema informar ao usuário que salvou uma preferência antes de a gravação ser concluída, a conversa seguinte poderá revelar uma falha de continuidade.

As gravações na memória também precisam de uma política para lidar com falhas. Se o armazenamento estiver temporariamente indisponível, o aplicativo pode informar que o salvamento não foi concluído ou manter uma operação pendente claramente identificada. Tratar uma tentativa de gravação como uma memória salva cria uma experiência enganosa para o usuário.

Como a memória persistente volta ao contexto ativo

A recuperação é uma sequência de decisões sobre elegibilidade, relevância e evidências. Primeiro, o sistema precisa identificar o usuário, o locatário, o projeto ou a tarefa cujos registros pode consultar. Em seguida, localiza registros candidatos e seleciona o que incluir no contexto da resposta.

O método de recuperação deve ser adequado à pergunta. “Qual é o prazo aprovado do Cedar?” talvez seja respondida melhor por meio de uma consulta exata a um campo do projeto. “Já vimos esse erro de implantação antes?” pode se beneficiar de uma pesquisa por palavras-chave e de uma análise de similaridade semântica entre incidentes anteriores. Um banco de dados vetorial é uma opção nesse processo, não um requisito para toda memória.

A pesquisa semântica é particularmente útil quando a formulação muda. Uma consulta sobre “manter os relatórios concisos” pode corresponder a uma preferência armazenada por “resumos executivos curtos”. No entanto, uma afirmação relacionada pode dizer respeito a outro cliente ou a uma versão abandonada do projeto. A similaridade identifica candidatos; não comprova a veracidade nem a autorização.

A recuperação precisa prever um resultado de não encontrado

Considere a pergunta: “Qual limite de gastos aprovei no mês passado?” Se não for possível localizar nenhum valor aprovado, uma resposta útil identifica a evidência ausente e pede esclarecimentos. Apresentar um número plausível transforma a ausência de memória em uma autorização inventada.

A interface de memória deve, portanto, distinguir entre uma correspondência confirmada, uma correspondência incerta, um conflito e a ausência de um registro que dê suporte. Esses resultados podem levar a comportamentos diferentes: responder diretamente, fazer ressalvas à resposta, pedir esclarecimentos ou se recusar a agir com base em uma suposição sem respaldo.

Depois da recuperação, a interpretação continua sendo importante. Um registro que diz “orçamento máximo proposto: US$ 5.000, aprovação pendente” não pode se transformar em “orçamento aprovado: US$ 5.000”. Manter as ressalvas tanto na representação armazenada quanto no contexto fornecido é tão importante quanto encontrar o documento correto.

Um exemplo prático: acompanhar um projeto ao longo do tempo

Imagine um assistente ajudando uma equipe a produzir o relatório de pesquisa Cedar. O exemplo a seguir é hipotético, mas expõe algumas escolhas comuns no projeto de sistemas de memória.

Sessão um: estabelecer o projeto

O usuário pede um relatório, especifica unidades métricas, fornece três fontes e informa que o rascunho deve ser entregue na sexta-feira. O contexto ativo inclui essas instruções e os trechos das fontes. O estado ativo da tarefa registra quais seções foram concluídas e quais afirmações ainda precisam ser verificadas.

Possíveis registros persistentes têm finalidades diferentes. A preferência por unidades métricas faz parte do projeto. O prazo do rascunho corresponde à etapa atual. As fontes fornecidas devem ficar no arquivo de evidências do projeto. As afirmações não verificadas devem ser incluídas em uma lista de pesquisas pendentes, mantendo-se a incerteza quanto a elas.

Sessão dois: retomar com as evidências certas

Três dias depois, o usuário pede para concluir a seção de métodos. O assistente precisa do esboço mais recente, das fontes relevantes, do estado atual da tarefa e da regra de formatação aplicável. Não precisa necessariamente de todas as frases descartadas durante a sessão anterior de brainstorming.

Se o ponto de controle indicar que a revisão da literatura está concluída, o assistente ainda deve abrir o documento salvo antes de fazer alterações com base nele. “Concluída” é uma afirmação sobre o progresso; o documento em si é a evidência do que foi concluído. Referências duradouras a documentos podem ser mais úteis do que um resumo que tente reproduzir todo o seu conteúdo.

Sessão três: aplicar uma exceção sem reescrever tudo

O usuário solicita uma edição para o cliente com unidades métricas e imperiais. A tarefa atual deve usar as duas unidades. A mudança da regra geral do projeto depende da formulação e do escopo do pedido do usuário: “para esta edição” tem um alcance mais restrito do que “de agora em diante, use as duas unidades”.

Um assistente cuidadoso registra uma exceção específica para aquela edição. Um assistente que generaliza demais reescreve a preferência global e introduz erros em relatórios posteriores. Isso é uma falha de memória, mesmo que todas as gravações no banco de dados e todas as solicitações de recuperação sejam bem-sucedidas.

Sessão quatro: concluir e descartar o estado temporário

Após a entrega, a etapa deve ser marcada como concluída. Uma instrução para “continuar o relatório” deve levar o assistente à versão entregue e fazê-lo perguntar qual revisão é necessária, em vez de retomar uma lista de verificação obsoleta. Notas temporárias de trabalho podem expirar de acordo com a política do projeto, enquanto o relatório final e as decisões importantes permanecem disponíveis.

O valor da memória persistente fica evidente aqui: menos explicações repetidas e mais continuidade. Seu custo também fica evidente: a aplicação precisa manter relações entre preferências, exceções, documentos e mudanças no estado da tarefa.

Resumo, compactação e o risco de perder a exceção

Interações longas podem acumular mais material do que será útil para a resposta seguinte. A compactação substitui parte desse histórico por uma representação menor. Um resumo pode preservar o objetivo, as decisões, as questões não resolvidas e as referências ao trabalho original.

As orientações da Anthropic sobre engenharia de contexto descrevem a compactação e as notas armazenadas fora da janela de contexto como abordagens para manter a continuidade em trabalhos prolongados. Ambas as técnicas alteram o material disponível para respostas futuras, por isso sua qualidade é importante.

A compressão é seletiva. Um resumo como “Use unidades métricas” é mais curto do que “Use unidades métricas, exceto na edição para o cliente, que exige os dois sistemas”. Mas também está errado em um dos casos importantes do projeto. A exceção omitida pode passar despercebida em resumos posteriores e se tornar difícil de rastrear.

Para nosso assistente Cedar, uma passagem de contexto mais completa preservaria a regra geral, sua exceção, as seções concluídas, as tarefas de verificação restantes e as referências aos arquivos mais recentes. Detalhes exatos, como valores aprovados ou identificadores, devem permanecer em registros estruturados ou documentos de origem quando aproximações puderem causar problemas.

Os resumos também devem preservar a incerteza. “Consideramos usar a Pesquisa B” não pode se transformar em “A Pesquisa B foi selecionada”. Se o histórico compactado fizer decisões provisórias parecerem definitivas, o sistema terá criado uma falsa memória ao tentar economizar contexto.

Como a memória da IA deve lidar com correções e conflitos

A memória persistente perde utilidade se não puder ser atualizada. Os projetos avançam, as preferências evoluem e informações anteriores podem se revelar equivocadas. Acrescentar uma correção como mais um registro sem ressalvas pode deixar o sistema de recuperação diante de duas afirmações contraditórias.

Uma atualização mais útil identifica o que as novas evidências substituem. Se a pessoa responsável pelo projeto adiar a data de lançamento de 15 de novembro para 29 de novembro, o registro antigo pode ser marcado como substituído e vinculado à nova decisão. Perguntas sobre o prazo atual usam a nova versão; para perguntas sobre o plano original, pode-se consultar a versão histórica.

A recência, por si só, não resolve todos os conflitos. Uma anotação recente em um rascunho pode ter menos autoridade do que uma política aprovada há mais tempo. Uma pessoa pode ter autorização para alterar uma preferência pessoal sem ter autorização para mudar uma regra válida para toda a organização. A política de atualização deve levar em conta o tipo de fato e a autoridade de sua fonte.

Algumas contradições devem permanecer sem solução até que uma pessoa as esclareça. Se duas pessoas responsáveis por um projeto fornecerem datas incompatíveis, sem que uma substitua explicitamente a outra, o assistente pode mostrar as duas fontes e perguntar qual deve prevalecer. Escolher em silêncio o registro mais parecido ou mais recente oculta uma decisão que talvez o sistema não tenha autoridade para tomar.

O que significa a IA esquecer?

Esquecer não é uma única chave que se aciona. Um produto pode deixar de inserir um fato nos prompts, excluí-lo das buscas rotineiras, marcá-lo como desatualizado, apagar seu registro de memória ou remover outras cópias armazenadas. Essas operações têm efeitos diferentes sobre o comportamento futuro e os dados retidos.

Deixar de fazer parte do contexto ativo

Um fato pode deixar de aparecer na entrada seguinte do modelo porque mensagens mais antigas foram omitidas ou resumidas. Isso reduz o que o modelo pode usar de imediato. A transcrição original ou o registro de memória ainda podem existir e voltar a ser usados em uma recuperação posterior.

Fazer a recuperação expirar ou suprimi-la

Um prazo expirado pode permanecer em um arquivo e, ao mesmo tempo, ser excluído das consultas sobre o trabalho atual. A supressão é útil quando há um motivo para manter o histórico, mas não deve ser descrita como exclusão completa. Uma busca histórica ou um fluxo de trabalho administrativo ainda pode acessar o registro.

Apagar a memória armazenada

Apagar um registro permanente também deve incluir as representações de recuperação derivadas dele. Se uma frase for removida de um perfil, mas continuar em um resumo pesquisável, o assistente poderá reconstruir a mesma preferência mais tarde. Dependendo da arquitetura, registros de origem, embeddings, resumos, caches e réplicas podem exigir ações de remoção separadas.

Cópias de segurança e registros podem seguir seus próprios prazos de retenção. Um produto deve explicar claramente esses limites e impedir que o material apagado volte a ficar ativo durante uma restauração. “Não usaremos mais esta memória” e “todas as cópias retidas foram removidas” são promessas diferentes.

Alterar os pesos do modelo

A exclusão de memória externa não altera, por si só, os parâmetros do modelo. Se as informações tiverem sido usadas no treinamento, lidar com elas no modelo é um problema à parte, que envolve o processo de treinamento e implantação. Da mesma forma, apagar uma memória pessoal não garante que o modelo nunca gerará um fato semelhante com base em conhecimentos gerais ou em pistas fornecidas em um novo prompt.

Um teste significativo de esquecimento pergunta, portanto, tanto se o sistema ainda armazena a informação quanto se os caminhos habituais de recuperação podem trazê-la de volta. Uma única resposta no chat dizendo “esqueci” não prova nenhuma dessas coisas.

Memória, RAG, treinamento e cache: onde estão os limites

A geração aumentada por recuperação, ou RAG, fornece evidências externas ao modelo durante a geração. A pesquisa original sobre RAG combinou parâmetros do modelo com um índice de documentos pesquisável. Um sistema de memória pessoal também pode usar recuperação, mas precisa ainda de políticas para criar, atualizar e descartar registros de interações.

Um manual da empresa pode ser recuperado sem ser uma memória do usuário. Uma anotação sobre uma interação anterior pode ser recuperada de um arquivo simples, sem um índice vetorial. A recuperação é um mecanismo; a finalidade e o ciclo de vida dos registros subjacentes determinam que tipo de sistema está sendo desenvolvido.

O treinamento e o ajuste fino modificam os parâmetros do modelo. Já a memória externa comum altera as evidências fornecidas ao modelo. Um assistente que segue uma preferência recém-salva pode se comportar de maneira diferente, mesmo que os pesos do modelo permaneçam inalterados.

O cache de prompts e de inferência reutiliza computações anteriores quando há suporte para isso. Esses recursos podem aumentar a eficiência, mas, por si só, não determinam se uma informação lembrada está atualizada, autorizada ou é adequada para tarefas futuras. Essas camadas podem coexistir, e a solução de problemas exige identificar qual delas é responsável pelo comportamento observado.

MemGPT oferece um exemplo arquitetônico influente: explorou a movimentação de informações entre um contexto limitado e níveis de memória externa, usando uma analogia com sistemas operacionais. A lição útil é gerenciar explicitamente a movimentação das informações, em vez de presumir que o armazenamento expande automaticamente, sem limites, o contexto imediato do modelo.

Por que a memória persistente pode tornar os erros mais duradouros

Uma resposta equivocada pode afetar uma interação. Uma memória equivocada pode afetar muitas. Se um assistente deduz que o usuário aprovou uma decisão, salva essa dedução como fato e, mais tarde, cita o registro salvo, o próprio erro anterior pode ganhar a aparência de evidência independente.

No nosso assistente de projetos, a fonte original deve permanecer distinguível da interpretação do modelo. Um resumo de uma decisão pode facilitar a consulta, mas a própria decisão aprovada deve embasar qualquer ação de consequência significativa. A repetição em várias anotações geradas não transforma uma única inferência sem respaldo em várias confirmações independentes.

A memória persistente também cria uma via para a contaminação por instruções. Um documento não confiável pode conter uma frase que instrui o assistente a alterar seu comportamento futuro. Armazenar essa frase como regra operacional faria o conteúdo externo atravessar uma fronteira de autoridade. O aplicativo deve tratá-la de acordo com sua origem, em vez de promovê-la a instrução confiável só porque aparece em um repositório de memória.

Ambientes compartilhados acrescentam outra fronteira. Um fato pode ser relevante para uma pergunta, mas pertencer a outro cliente ou projeto. As verificações de acesso devem restringir a recuperação antes que as informações cheguem ao modelo. Pedir ao modelo que ignore registros não autorizados depois que eles já foram fornecidos é uma solução menos robusta.

Como avaliar se a memória realmente funciona

Uma demonstração convincente muitas vezes pede ao assistente que repita uma preferência salva. Uma avaliação rigorosa acompanha informações que mudam ao longo de várias sessões e verifica se a memória melhora a tarefa concluída.

LongMemEval avalia extração de informações, raciocínio entre sessões, raciocínio temporal, atualização de conhecimento e abstenção. Essas categorias mostram por que a qualidade da memória de longo prazo vai além de recuperar uma única frase correspondente. Os resultados publicados de benchmarks devem ser interpretados considerando os sistemas e as configurações testados, em vez de se presumir que descrevam todos os produtos atuais.

No fluxo de trabalho Cedar, uma avaliação poderia introduzir uma preferência, retomar o projeto, acrescentar uma exceção, revisar um prazo, excluir uma anotação e, em seguida, fazer perguntas planejadas para revelar lembranças desatualizadas ou sem respaldo. O mesmo modelo também deve ser testado sem o recurso de memória, para determinar se o sistema adicional melhora os resultados.

• Precisão da gravação: O sistema salvou a declaração pretendida, com seu escopo e suas ressalvas?
• Utilidade da recuperação: O sistema encontrou as evidências necessárias para a tarefa sem sobrecarregar o contexto com histórico irrelevante?
• Tratamento de atualizações: Uma correção substituiu o fato atual e, ao mesmo tempo, preservou distinções históricas úteis?
• Abstenção: O assistente reconheceu quando não havia nenhum registro que desse respaldo à informação?
• Isolamento: Os registros permaneceram restritos ao usuário, locatário e projeto corretos?
• Esquecimento: A exclusão ou o vencimento impediram a recuperação futura pretendida, inclusive por meio de resumos derivados?
• Custo operacional: As melhorias justificaram o aumento da latência, das chamadas ao modelo, do armazenamento e da manutenção?

As falhas devem ser rastreadas até a etapa em que ocorreram. A ausência de uma resposta pode ser resultado de uma gravação malsucedida, de um escopo de busca incorreto, de uma decisão inadequada de ranqueamento, da omissão de uma ressalva ou de o modelo ter interpretado mal evidências válidas. Aumentar o tamanho do contexto não resolverá todos esses problemas.

Como escolher a arquitetura de memória certa

Um resumo pontual de um documento talvez precise apenas do documento atual e das instruções. Uma análise interrompida se beneficia de um ponto de controle da tarefa. Um assistente para projetos recorrentes talvez precise de decisões versionadas e referências a artefatos. Um assistente que trabalha em muitas sessões de usuário talvez precise de um repositório de preferências separado e editável.

Comece especificando a pergunta futura que a memória deve ajudar a responder. “O que ainda está pendente?” exige o estado da tarefa. “Qual formato este cliente exige?” exige uma preferência com escopo definido. “Por que rejeitamos esta abordagem?” exige um registro da decisão com evidências que a sustentem. Perguntas diferentes exigem representações diferentes.

Prefira poucos registros claros e atribuíveis a um arquivo indiscriminado apresentado como personalização. Mantenha o estado atual separado dos acontecimentos históricos, preserve os links para os artefatos de origem e incorpore correções e exclusões ao projeto desde o início.

A memória ativa dá a um sistema de IA um presente coerente. A memória persistente pode lhe dar continuidade ao longo do tempo. A qualidade dessa continuidade depende das decisões que conectam as duas: o que é salvo, o que é recuperado, qual versão prevalece e o que pode desaparecer.