Memória persistente para agentes de IA: arquitetura, trade-offs e padrões de produção

A ilusão da statelessness

Modelos de linguagem são stateless por natureza. Cada chamada é uma página em branco. Quando você abre um chat e continua uma conversa de horas atrás, algo precisa reconstruir esse contexto do nada. Esse "algo" é o sistema de memória, e em agentes autônomos ele é, provavelmente, o componente mais crítico e mais negligenciado da arquitetura.

A negligência acontece por um motivo legítimo: a memória parece simples até o momento em que não é. Na primeira versão, você joga o histórico inteiro no prompt. Funciona. Três meses depois, o histórico tem 200 mil tokens, o custo por requisição explodiu e o modelo começa a ignorar coisas que estavam no início da conversa.

O problema não é técnico demais. É que a memória tem três camadas conceituais que precisam ser projetadas juntas.

As três camadas de memória

Camada 1: Working memory (janela de contexto)

A janela de contexto é o equivalente à RAM de um computador. É o espaço disponível no prompt atual, medido em tokens. Um GPT-4o tem 128k tokens de contexto, mas usar 100k deles em toda chamada é um erro de arquitetura, não uma feature.

O custo escala linearmente com o número de tokens de entrada, e modelos tendem a dar peso desproporcional ao conteúdo no início e no final da janela. Isso é o lost in the middle problem: informações no meio do contexto são frequentemente ignoradas.

A working memory deve conter apenas o mínimo necessário para a ação imediata do agente. Nada mais.

Camada 2: Episodic memory (vector store)

A episodic memory guarda registros de interações passadas na forma de embeddings vetoriais. Quando o agente precisa de uma informação que não está na working memory, ele faz uma busca por similaridade no vector store e recupera os episódios mais relevantes.

Esse é o padrão RAG (Retrieval Augmented Generation) aplicado a memória de agente. A diferença para RAG em chatbots convencionais é que aqui o "documento" é cada interação, não um corpus estático.

Camada 3: Semantic memory (resumo consolidado)

A semantic memory é o que sobra depois de resumir anos de interação em fatos compactados. Funciona como a memória de longo prazo humana: não guarda o que você comeu no almoço de terça-feira de 2019, mas lembra que você é intolerante à lactose.

Cada semana (ou cada N interações), um processo de resumo extrai fatos, preferências e padrões do histórico recente e os consolida em um resumo denso que vai para a semantic memory. Quando o agente inicia uma nova sessão, ele carrega esse resumo junto com a working memory.

flowchart TD
    style WM fill:#eceff1,stroke:#455a64,stroke-width:2px
    style VS fill:#e3f2fd,stroke:#455a64,stroke-width:2px
    style SM fill:#cfd8dc,stroke:#455a64,stroke-width:2px
    WM["Working Memory"]
    VS["Vector Store"]
    SM["Semantic Memory"]
    WM -->|conversa bruta| VS
    VS -->|embeddings| SM
    SM -->|fatos resumidos| WM

Padrões de retrieval que funcionam em produção

A maioria dos tutoriais de RAG mostra embeddings com busca por similaridade pura (cosine similarity). Em produção, isso é ingênuo. O problema é que similaridade semântica não é o mesmo que relevância contextual.

Considere um agente de suporte técnico. Se o usuário diz "o sistema caiu", embeddings próximos vão recuperar episódios sobre "sistema" e "queda", mas podem ignorar que o mesmo usuário reportou o mesmo problema três vezes na semana passada. A relevância temporal e o padrão de repetição importam mais que a similaridade léxica.

Padrões que funcionam:

HyDE (Hypothetical Document Embeddings): o agente gera uma hipótese de resposta antes de buscar. A busca usa esse documento hipotético como query, não a pergunta crua. Isso melhora significativamente a qualidade do retrieval em domínios técnicos.

Query decomposition: quebre a pergunta em sub-perguntas antes de buscar. "Quais são as permissões do usuário X e quais recursos ele acessou na última semana" precisa gerar duas buscas, não uma.

Reranking: após o retrieval inicial (que pode retornar 20 resultados), um modelo menor e mais rápido (Cross-Encoder) rerankar esses resultados para as 5 melhores matches. Isso adiciona latência mas melhora precisão em 30-40% nos benchmarks.

Deduplicação: o custo invisível

Quando cada interação é embebida e armazenada, a tendência natural é o vector store crescer sem controle. O problema não é só storage, é retrieval noise.

Se o agente recupera 10 episódios relevantes e 3 são duplicatas quase idênticas, o contexto fica poluído e o modelo desperdiça tokens processando redundância. Em agentes que rodam milhares de sessões por dia, isso é dinheiro jogado fora.

Estratégias de deduplicação:

• Deduplicação por threshold: se dois vetores têm similaridade > 0.95, mantenha apenas o mais recente.
• Deduplicação semântica por cluster: agrupar episódios por tema e substituir cada cluster por uma versão condensada.
• Expiration policy: episódios com mais de 30 dias sem acesso são arquivados ou deletados, a menos que pertençam a uma thread considerada "importante" (marcada por um flag no metadata).

def should_expire(episode: dict, importance_threshold: int = 3) -> bool:
    days_old = (datetime.now() - episode['created_at']).days
    is_important = episode.get('importance_score', 0) >= importance_threshold
    is_recently_accessed = episode.get('last_accessed') and \
        (datetime.now() - episode['last_accessed']).days < 7
    
    # Importante e recentemente acessado: nunca expira
    if is_important and is_recently_accessed:
        return False
    
    # Padrão: expira após 30 dias sem acesso
    return days_old > 30

O custo que ninguém calcula

Vamos fazer a conta que a maioria ignora. Um agente com 1000 sessões ativas por dia, cada sessão com 50 mensagens de média, e histórico de 6 meses:

• Sessões: 1000 × 30 × 6 = 180.000 episódios
• Cada episódio embebido (512 tokens): ~$0.0001 por embedding (OpenAI ada-002)
• Custo de armazenamento vetorial (Pinecone serverless, 384 dimensões): ~$0.0001 por vetor/mês
• Retrieval por sessão: 5 buscas × 20 resultados rerankeados

O custo de embedding é irrisório. O custo de storage também. O custo real está no volume de tokens que você joga no contexto a cada recuperação. Se cada retrieval retorna 5 episódios de 1000 tokens cada, são 5000 tokens por chamada. A 1000 sessões/dia, são 5 milhões de tokens de entrada por dia, ou seja, ~$15/dia só em tokens de retrieval, sem contar o custo do modelo que processa tudo.

A otimização mais impactante não é trocar de vector store ou usar embeddings mais baratos. É reduzir agressivamente o tamanho dos episódios recuperados, resumir antes de armazenar e filtrar com precisão antes de rerankar.

Privacidade: a dimensão ignorada

A memória de agente guarda dados de terceiros. O cliente X mencionou o nome dos funcionários dele. O usuário compartilhou documentos confidenciais. O agente que a empresa está em vias de ser vendida.

Se esse vector store vaza, o dano é reputacional e jurídico. Não é opcional criptografar os embeddings em repouso (AES-256) e em trânsito (TLS 1.3). Não é opcional ter um schema de acesso por tenant, com isolation rigorosa.

Mas o problema mais sutil é o seguinte: quando o modelo usa memória para retrieval, ele está potencialmente usando dados de um cliente para responder perguntas de outro cliente. Isso é contamination. Em arquiteturas ingênuas, um embedding de um documento do Cliente A pode ser recuperado em uma sessão do Cliente B se a query semântica for próxima o suficiente.

A mitigação mínima:

• Cada tenant tem seu namespace isolado no vector store.
• Metadata de tenant é um filtro obrigatório (não apenas um campo, mas uma partição física).
• Periodicamente, audite queries de retrieval para verificar se resultados cruzados estão ocorrendo.

Síntese: a decisão de arquitetura

A escolha de arquitetura de memória não é técnica no sentido abstrato. É uma decisão de produto disfarçada de engineering.

Se o agente precisa de contexto em uma única sessão: maximize a janela de contexto, use um summarizer conservador e descarte tudo ao final.

Se o agente precisa de continuidade entre sessões: vector store com retrieval seletivo, deduplicação agressiva e semantic memory limitada a fatos estruturados.

Se o agente opera em ambiente multi-tenant com dados sensíveis: cada escolha de arquitetura precisa passar pelo filtro de privacy-by-design antes de passar pelo filtro de performance.

O erro mais caro que você pode cometer é tratar memória como storage quando ela é, na verdade, compute. Cada vetor armazenado é uma operação de retrieval pendente. Cada resumo gerado é um custo de inferência recorrente. A memória que parece "barata" no protótipo vai ser o item de custo mais difícil de otimizar quando o agente escalar.

Se sua arquitetura de memória está gerando custos imprevisíveis ou vazamentos de dados sensíveis em produção, podemos mapear onde o problema está escondido e desenhar a solução concreta.

Fale com um especialista da Eficify