Olá a todos, aqui é Alex do agntai.net. Estamos em março de 2026, e estou lutando com algo que provavelmente está na mente de muitos de vocês: como construir agentes que não pareçam simplesmente chamadas de API aumentadas, mas que realmente demonstrem um certo nível de comportamento inteligente e persistente? Mais especificamente, eu penso muito sobre arquiteturas de memória para agentes de IA. É uma coisa trazer um modelo GPT para responder a uma pergunta; é outra ter um agente que se lembre de um projeto de vários dias, que adapte sua estratégia com base em falhas passadas e que verdadeiramente aprenda com as interações.
Há algum tempo, muitos de nós estamos nos apoiando fortemente em bancos de dados vetoriais como nossa memória externa principal para os agentes. E não se engane, eles são ótimos para a geração aumentada por recuperação (RAG) e para dar a nossos agentes acesso a enormes quantidades de informações factuais ou contextuais. Mas, depois de construir alguns protótipos para clientes – um tentando ser um assistente de pesquisa pessoal, o outro um bot de suporte ao cliente dinâmico – comecei a notar suas limitações. Eles são excelentes para “sobre o que falamos na terça-feira passada?” ou “quais são as características principais do produto X?”, mas têm dificuldade com “lembre-se daquela preferência sutil que eu expressei há três semanas e a integre em sua recomendação atual.”
Tive uma revelação ao tentar fazer meu agente assistente de pesquisa entender que eu *realmente odeio* artigos muito acadêmicos, a menos que seja absolutamente necessário. Eu dizia a ele, ele concordava, e então, dois dias depois, ele me jogava outro artigo denso do arXiv nos braços. Os vetores de representação para “eu não gosto de artigos acadêmicos” estavam lá, mas o agente realmente não estava aprendendo com meu feedback de uma maneira que modificasse realmente sua estratégia de pesquisa a longo prazo. Era como falar com alguém com uma excelente memória de curto prazo, mas sem memória de longo prazo para preferências pessoais ou o contexto evolutivo.
Além da pesquisa vetorial: A necessidade de uma memória multimodal
Minha conclusão? Precisamos ir além de uma dependência única em bancos de dados vetoriais para a memória dos agentes. Não se trata de substituí-los, mas de complementá-los com outras formas de memória que atendam diferentes tipos de informações e diferentes horizontes temporais. Pense na maneira como os humanos se lembram das coisas. Temos uma memória de trabalho de curto prazo, uma memória episódica (eventos), uma memória semântica (fatos) e uma memória procedural (como fazer as coisas). Um único vetor de codificação de um trecho da conversa não separa esses elementos de maneira clara.
O problema de confiar apenas na pesquisa vetorial para tudo é que ela trata todas as lembranças como igualmente importantes e igualmente estruturadas. Uma preferência sutil, uma crença fundamental, um objetivo a longo prazo ou uma observação transitória – todos estão misturados em representações. Quando o agente consulta sua memória, ele recupera o que é semanticamente similar, mas não necessariamente o que é *mais relevante* de uma maneira profundamente contextual ou temporalmente consciente. É como ter uma biblioteca onde cada livro é apenas uma coleção de palavras-chave, e onde você só pode encontrar coisas fazendo correspondência com essas palavras-chave, não compreendendo o gênero do livro, a intenção do autor ou seu lugar em uma série.
Então, como seria uma arquitetura de memória “multimodal” para um agente de IA? Para mim, isso se resume a segmentar e estruturar diferentes tipos de informações e depois fazer com que o motor de raciocínio central do agente decida inteligentemente qual armazenamento de memória consultar e como atualizá-lo.
1. Memória de curto prazo / memória de trabalho: O bloco de notas
Esse é o contexto imediato do seu agente. É no que o agente está pensando ativamente neste momento. Para mim, geralmente se trata de uma simples lista das interações recentes de uma conversa, dos parâmetros de tarefa atuais e das observações transitórias. É volátil, e isso é frequentemente apagado ou resumido. Pense nisso como a RAM do agente.
Exemplo: Se meu agente assistente de pesquisa está atualmente encarregado de “encontrar artigos sobre as melhorias na arquitetura dos transformadores de 2024”, sua memória de trabalho contém essa solicitação específica, os últimos artigos que ele revisou e talvez um indicador de que ele ainda está pesquisando. Isso é geralmente gerenciado passando o histórico recente da conversa diretamente para o LLM ou mantendo-o em um simples buffer na memória.
2. Memória episódica: O diário de eventos
É aqui que os bancos de dados vetoriais realmente brilham, mas com uma reviravolta. Em vez de simplesmente integrar pedaços de conversa brutos, acho mais útil *resumir* e *etiquetar* os eventos antes de integrá-los. Um “evento” pode ser uma interação do usuário, uma ação do agente, uma decisão tomada, ou uma observação chave. Cada evento tem um carimbo de data/hora, uma breve descrição, e talvez algumas entidades associadas ou uma indicação de sentimento.
Por que resumir/etiquetar? Porque uma transcrição de conversa bruta pode ser muito barulhenta. “O usuário disse ‘isso é interessante’ e então ‘você pode me mostrar mais’ e então ‘e quanto a X?'” pode ser resumido como “O usuário expressou seu interesse, pediu mais informações e então fez perguntas sobre X.” Isso torna as representações mais concentradas no *significado* da interação ao invés da formulação específica. Isso também permite um filtragem mais fácil por etiquetas depois.
# Pseudo-código Python para uma entrada de memória episódica
class EpisodicMemoryEntry:
def __init__(self, timestamp, description, tags=None, associated_entities=None, raw_context=None):
self.timestamp = timestamp
self.description = description # Evento resumido pelo LLM
self.tags = tags if tags is not None else []
self.associated_entities = associated_entities if associated_entities is not None else {}
self.raw_context = raw_context # Interação original para uma lembrança detalhada, se necessário
def to_embedding_text(self):
# Concatenar campos relevantes para embedding
return f"Evento em {self.timestamp}: {self.description}. Etiquetas: {', '.join(self.tags)}. Entidades: {self.associated_entities}"
# Exemplo de uso:
# Suponha que 'llm_summarize_event' seja uma função que chama um LLM
# para condensar um trecho de conversa em uma descrição e extrair etiquetas/entidades.
conversation_chunk = "Usuário: Eu realmente preciso terminar este relatório até sexta-feira. Agente: Certo, como posso ajudar? Usuário: Você pode encontrar as tendências de mercado recentes para IA no setor de saúde? Estou particularmente interessado em rodadas de financiamento."
# Chamada LLM para processar esse trecho
summary, tags, entities = llm_summarize_event(conversation_chunk)
# resumo: "O usuário pediu as tendências de mercado recentes para IA no setor de saúde, focando em rodadas de financiamento, a serem entregues até sexta-feira."
# etiquetas: ["pedido_de_pesquisa", "sensível_ao_prazos", "IA_saúde", "rodadas_de_financiamento"]
# entidades: {"tópico": "IA no setor de saúde", "prazo": "sexta-feira", "foco": "rodadas de financiamento"}
event = EpisodicMemoryEntry(
timestamp=datetime.now(),
description=summary,
tags=tags,
associated_entities=entities,
raw_context=conversation_chunk
)
# Depois, integrar event.to_embedding_text() e armazenar no banco de dados vetorial
Quando o agente precisa recordar eventos passados, ele consulta essa memória episódica, mas agora ele também pode filtrar por etiquetas, entidades ou intervalos de tempo, além da similaridade semântica.
3. Memória semântica: O grafo de conhecimentos de fatos e crenças
Este pode ser o domínio menos desenvolvido em muitas arquiteturas de agentes, mas é onde o agente pode armazenar fatos estruturados, relações e suas próprias crenças ou preferências evolutivas. Os bancos de dados vetoriais são suficientes para fatos gerais, mas não são ideais para representar relações (por exemplo, “Alex prefere X a Y”, “O projeto Z é uma subtarefa do projeto A”).
É aqui que comecei a experimentar com grafos de conhecimentos. Em vez de simplesmente integrar tudo, uso LLMs para extrair trios (sujeito-predicado-objeto) a partir das interações e armazená-los em um banco de dados gráfico (como Neo4j ou até mesmo um simples banco de dados relacional se o grafo não for muito complexo).
“`html
Por que um grafo de conhecimentos? Porque ele modela explicitamente as relações. Se meu agente aprende “Alex não gosta de artigos acadêmicos”, essa é uma relação direta. Se ele aprende depois que “os artigos sobre IA no setor de saúde são frequentemente acadêmicos”, ele pode deduzir “Alex provavelmente não gosta de artigos sobre IA no setor de saúde.” Esse tipo de inferência é difícil apenas com similaridade vetorial.
# Pseudo-código Python para extrair e armazenar triplas
def extract_and_store_triples(agent_id, text_input):
# Chamada LLM para extrair triplas.
# Prompt: "Extraia triplas factuais (sujeito, predicado, objeto) do texto a seguir.
# Exemplo: 'Alex prefere café' -> (Alex, prefere, café)."
# text_input = "O usuário Alex mencionou que prefere resumos concisos e não gosta de artigos muito acadêmicos."
triples_str = call_llm_for_triple_extraction(text_input)
# Exemplo de saída: "[(Alex, prefere, resumos concisos), (Alex, não gosta de, artigos acadêmicos)]"
extracted_triples = parse_triples_string(triples_str) # Converter a string em lista de tuplas
for s, p, o in extracted_triples:
# Armazenar em um banco de dados gráfico (por exemplo, usando um dicionário Python simples para a demonstração)
# Em um sistema real, seria uma chamada de cliente Neo4j ou similar
graph_db_add_triple(agent_id, s, p, o)
# Exemplo de 'graph_db_add_triple' (simplificado)
knowledge_graph = {} # {sujeito: {predicado: [objetos]}}
def graph_db_add_triple(agent_id, s, p, o):
if agent_id not in knowledge_graph:
knowledge_graph[agent_id] = {}
if s not in knowledge_graph[agent_id]:
knowledge_graph[agent_id][s] = {}
if p not in knowledge_graph[agent_id][s]:
knowledge_graph[agent_id][s][p] = []
if o not in knowledge_graph[agent_id][s][p]: # Prevenir duplicados
knowledge_graph[agent_id][s][p].append(o)
# Para consultar:
# O que Alex não gosta? -> knowledge_graph[agent_id]["Alex"]["não gosta"]
O agente pode consultar esse gráfico não apenas por palavras-chave, mas também por relações. “Quais são as preferências de Alex?” ou “Quais tarefas estão relacionadas ao Projeto A?” É uma maneira muito mais poderosa de recuperar conhecimentos estruturados.
4. Memória Procedimental: A Biblioteca de Habilidades
Isso não corresponde à memória no sentido tradicional, mas sim a uma coleção de ferramentas, funções e fluxos de trabalho que o agente sabe executar. Quando um LLM decide que precisa realizar uma ação, ele consulta essa “biblioteca de habilidades.” Isso poderia ser uma lista de funções Python, especificações de API ou até mesmo fluxos de trabalho multi-etapas pré-definidos.
Minha experiência: Eu achei útil tornar essas habilidades descobertas pelo LLM usando docstrings descritivas e assinaturas de funções claras. O LLM então pode escolher a ferramenta certa com base no objetivo atual.
“`
class AgentSkills:
def search_web(self, query: str) -> str:
"""
Pesquisa na web por informações relacionadas à consulta.
Útil para conhecimento geral, notícias e eventos recentes.
Args:
query (str): A consulta de pesquisa.
Returns:
str: Um resumo dos resultados da pesquisa.
"""
# ... implementação real da pesquisa na web ...
return f"Resultados da pesquisa na web para '{query}': ..."
def analyze_document(self, document_id: str, analysis_type: str) -> str:
"""
Analisa um documento específico para vários insights.
Útil para resumir, extrair pontos-chave ou para análise de sentimentos de um documento.
Args:
document_id (str): O ID do documento a ser analisado.
analysis_type (str): O tipo de análise a ser realizada (por exemplo, 'resumo', 'palavras-chave', 'sentimento').
Returns:
str: O resultado da análise.
"""
# ... implementação da análise de documento ...
return f"Análise do documento {document_id} para {analysis_type}: ..."
def get_user_preferences(self, user_id: str, preference_type: str = None) -> dict:
"""
Recupera as preferências armazenadas para um usuário específico.
Útil para personalizar respostas e ações.
Args:
user_id (str): O ID do usuário.
preference_type (str, opcional): Tipo específico de preferência a ser recuperada (por exemplo, 'não gosta', 'tópicos').
Returns:
dict: Um dicionário das preferências do usuário.
"""
# Isso consultaria a memória semântica (gráfico de conhecimento)
# Para simplificar, retorna dados fictícios aqui
if user_id == "Alex" and preference_type == "não gosta":
return {"não gosta": ["artigos acadêmicos", "explicações verbosas"]}
return {"preferências": "..."}
# O LLM seria solicitado a selecionar e chamar essas funções com base em seu raciocínio.
Implementação: A Camada de Orquestração
A verdadeira mágica acontece na forma como o motor de raciocínio central do agente (o LLM em si, tipicamente) interage com essas diferentes lojas de memória. Não é simplesmente um sistema de recuperação passiva; o agente deve decidir ativamente:
- Quais informações eu preciso neste momento?
- Qual loja de memória é mais provável de conter essa informação?
- Como eu devo atualizar minha memória com base nessa nova interação/observação?
Esse processo de tomada de decisão é onde o agente se torna realmente dinâmico. Eu normalmente estruturo isso com um prompt que guia o LLM a pensar em voz alta, planejar e, em seguida, executar operações de memória. É uma cadeia de processos de pensamento que integra a interação de memória.
Minha abordagem atual:
- Perceber: O agente recebe uma entrada (consulta do usuário, evento do sistema).
- Refletir & Planejar: O LLM analisa a entrada, considera os objetivos atuais e formula um plano. Esse plano frequentemente envolve interrogar a memória.
- « Eu preciso lembrar de interações passadas (episódicas)? Quais são as preferências conhecidas do usuário (semânticas)? Eu tenho ferramentas para alcançar isso (procedural) ? »
- Ele poderia interrogar a memória episódica por situações passadas semelhantes ou a memória semântica por fatos relevantes.
- Agir: Com base no plano e nas memórias recuperadas, o LLM decide uma ação (por exemplo, gerar uma resposta, chamar uma ferramenta, atualizar a memória).
- Memorizar & Aprender: Após uma ação, o LLM reflete sobre o resultado e atualiza suas diferentes lojas de memória.
- Uma nova interação é resumida e adicionada à memória episódica.
- Novos fatos ou preferências são extraídos e adicionados ao gráfico de conhecimento semântico.
- Se uma estratégia falhar, ele poderia gerar uma entrada “lição aprendida” na memória semântica.
Esse processo iterativo permite que o agente desenvolva uma compreensão mais rica e nuance de seu ambiente, de seu usuário e de si mesmo ao longo do tempo. Ele vai além da simples recuperação de fatos para realmente formar crenças persistentes e adaptar seu comportamento.
Dicas Práticas para a Arquitetura do Seu Agente
Se você está construindo agentes de IA neste momento e alcançando limites de RAG simples, aqui está o que eu recomendo tentar:
- Não trate toda a memória da mesma forma. Categorize o tipo de informações que você precisa armazenar: contexto de curto prazo, histórico de eventos, fatos/preferências estruturados e capacidades.
- Aumente seu banco de dados vetorial. Ele é excelente para memória episódica, especialmente quando você resume e rotula as entradas. Mas não o faça o único repositório de memória.
- Experimente com gráficos de conhecimento para memória semântica. Mesmo um simples repositório de triplas pode fazer uma enorme diferença na forma como seu agente armazena e recupera relações estruturadas e crenças fundamentais. Isso permite um verdadeiro raciocínio, não apenas uma busca por similaridade.
- Projete para uma gestão ativa da memória. O motor de raciocínio central do agente (sua solicitação LLM) deve incluir explicitamente etapas para consultar, atualizar e refletir sobre seus diferentes repositórios de memória. Não se contente em despejar todo o contexto em uma única solicitação.
- Mantenha a memória procedural (uso de ferramentas) organizada. Descrições claras e exemplos para suas ferramentas ajudam o LLM a usar suas capacidades de forma eficaz.
Construir verdadeiros agentes inteligentes não se resume a modelos maiores; trata-se de designs mais inteligentes. Ao oferecer aos nossos agentes um sistema de memória mais semelhante ao dos humanos, podemos nos aproximar de agentes que não apenas se lembram, mas aprendem e se adaptam de verdade. É um caminho difícil, mas incrivelmente gratificante, e estou ansioso para ver aonde todos nós vamos levá-lo a seguir.
🕒 Published: