Oi pessoal, Alex aqui do agntai.net. Espero que todos vocês estejam tendo uma semana produtiva construindo coisas legais. Hoje, quero falar sobre algo que tem me incomodado e, honestamente, alguns dos meus colegas também: a mudança sutil, mas significativa, em como estamos pensando sobre arquiteturas de agentes de IA, especialmente quando se trata de tarefas longas e com estado. Nós já superamos a fase do “engenharia de prompt é tudo” e até mesmo além do “RAG é a resposta para todos os males.” Agora, trata-se de construir agentes que lembram, raciocinam ao longo do tempo e se adaptam. E para isso, precisamos de um sistema de memória melhor do que simplesmente enfiar tudo em um banco de dados vetorial.
Especificamente, estou falando sobre a construção de uma arquitetura de memória prática e em múltiplas camadas para agentes de IA. Esqueça os artigos acadêmicos sofisticados por um segundo; quero discutir o que funciona na prática quando você está tentando construir um agente que realmente ajude um usuário por várias horas, dias ou até semanas, sem esquecer constantemente o que acabou de fazer ou aprender.
O Problema com a Memória Plana: Meu Debacle do “Ticket Bot”
Deixe-me contar uma história. Alguns meses atrás, fui encarregado de construir um agente de suporte interno para um cliente. A ideia era simples: um agente que pudesse ajudar os funcionários com problemas comuns de TI – redefinições de senha, guias de instalação de software, solução de problemas de VPN. Começamos com uma configuração RAG bastante padrão. O usuário faz uma pergunta, o agente recupera documentos relevantes, sintetiza uma resposta. Funcionou bem para consultas simples e pontuais.
Mas então os usuários começaram a fazer perguntas de acompanhamento. “Ok, eu tentei isso, e agora?” Ou, “Você pode me lembrar dos passos para configuração de VPN de ontem?” O agente frequentemente repetia o mesmo conselho ou, pior, ficava confuso porque a janela de contexto já estava cheia da conversa anterior e a nova consulta não tinha “sinal” suficiente para trazer o *próximo* documento relevante.
Era como conversar com alguém com amnésia de curto prazo. Cada interação era um recomeço. Minha solução inicial foi apenas enfiar mais da história da conversa no prompt. Isso funcionou por talvez 3-4 interações, mas depois atingiu o limite da janela de contexto, e o desempenho começou a se degradar. O agente se tornava lento e caro, e ainda assim, parecia burro. Este foi meu debacle do “ticket bot” – ele conseguia abrir tickets, mas não conseguia realmente *resolver* nada de maneira interativa ao longo do tempo.
Essa experiência destacou um problema fundamental: um modelo de memória plana, onde tudo vai para uma única loja vetorial ou um buffer de conversa linear, não é suficiente para agentes que precisam operar de forma inteligente por períodos prolongados.
Além da Busca Vetorial: Por Que Memória em Múltiplas Camadas?
Pense em como os humanos lembram. Não temos apenas um grande descarregamento do cérebro. Temos memória de curto prazo (o que estamos pensando ativamente), memória episódica (eventos e conversas específicas), memória semântica (conhecimento geral, fatos) e até memória procedural (como fazer as coisas). Essas camadas interagem, cada uma cumprindo um propósito diferente e operando em diferentes escalas de tempo e níveis de abstração.
Para um agente de IA, precisamos de algo semelhante. Uma arquitetura de memória em múltiplas camadas permite que o agente recorde informações em diferentes granularidades e escalas de tempo, priorizando o que é relevante agora em comparação ao que é importante para compreensão ou planejamento a longo prazo.
Aqui está como comecei a pensar sobre isso e o que tem funcionado bem desde então:
Camada 1: O “Bloco de Notas” – Contexto Imediato e Efêmero
Esta é a memória de muito curto prazo do seu agente, como um quadro branco. Ela mantém a interação atual da conversa, a consulta imediata do usuário, quaisquer ferramentas que acabou de usar e a saída direta. Frequentemente, é apenas parte da janela de contexto do prompt.
Propósito: Recordação rápida para a interação imediata, mantendo o fluxo da conversa dentro de uma única interação ou uma sequência muito curta. É aqui que o agente mantém seu processo de pensamento atual, etapas intermediárias e o objetivo explícito que está tentando alcançar *agora mesmo*.
Implementação: Geralmente, apenas uma lista simples de mensagens recentes ou um dicionário contendo variáveis temporárias. É limpo ou resumido com frequência.
“`html
class ScratchpadMemory:
def __init__(self):
self.current_context = []
self.temp_vars = {}
def add_message(self, role, content):
self.current_context.append({"role": role, "content": content})
def get_context(self, max_tokens=2000):
# Simples truncamento para demonstração
full_context = "\n".join([f"{msg['role']}: {msg['content']}" for msg in self.current_context])
return full_context[-max_tokens:] # Bruto, melhor usar tokenizadores
def set_temp_var(self, key, value):
self.temp_vars[key] = value
def get_temp_var(self, key):
return self.temp_vars.get(key)
def clear(self):
self.current_context = []
self.temp_vars = {}
# Exemplo de uso
scratchpad = ScratchpadMemory()
scratchpad.add_message("usuário", "Preciso redefinir minha senha do VPN.")
scratchpad.set_temp_var("task_type", "redefinir_senha")
print(scratchpad.get_context())
Camada 2: Memória Episódica – O Registro da Conversa
É aqui que reside todo o histórico de interação com o usuário. Cada mensagem, cada chamada de ferramenta, cada resposta do agente, cada informação relevante recuperada de outras fontes. Está indexado, mas não necessariamente vetorizado para recuperação densa em sua totalidade.
Propósito: Fornece um registro cronológico do que aconteceu. Crucial para entender a continuidade da conversa, referir-se a declarações passadas e identificar padrões ao longo de uma única sessão.
Implementação: Um banco de dados persistente (SQL, loja de documentos NoSQL como MongoDB ou DynamoDB) armazenando objetos JSON estruturados para cada turno. Cada entrada pode incluir marcas de tempo, orador, conteúdo, chamadas de ferramenta e pensamentos do agente. Podemos então consultar isso diretamente para intervalos de tempo ou eventos específicos.
Para meu bot de atendimento, comecei a armazenar cada turno como um objeto JSON em um banco de dados PostgreSQL. Isso fez uma grande diferença. Eu poderia então recuperar os últimos 5 turnos, ou todos os turnos relacionados a “VPN” dentro da última hora, sem depender apenas da similaridade vetorial.
# Supondo que você tenha uma conexão de banco de dados 'db_conn'
# usando psycopg2 para PostgreSQL
import json
from datetime import datetime
class EpisodicMemory:
def __init__(self, db_conn):
self.conn = db_conn
self._create_table_if_not_exists()
def _create_table_if_not_exists(self):
cursor = self.conn.cursor()
cursor.execute("""
CREATE TABLE IF NOT EXISTS agent_episodes (
id SERIAL PRIMARY KEY,
session_id TEXT NOT NULL,
timestamp TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
episode_data JSONB
);
""")
self.conn.commit()
cursor.close()
def add_episode(self, session_id, data):
cursor = self.conn.cursor()
cursor.execute(
"INSERT INTO agent_episodes (session_id, episode_data) VALUES (%s, %s);",
(session_id, json.dumps(data))
)
self.conn.commit()
cursor.close()
def get_episodes_by_session(self, session_id, limit=10):
cursor = self.conn.cursor()
cursor.execute(
"SELECT episode_data FROM agent_episodes WHERE session_id = %s ORDER BY timestamp DESC LIMIT %s;",
(session_id, limit)
)
records = cursor.fetchall()
cursor.close()
return [r[0] for r in records] # Cada registro é um objeto JSONB
def get_episodes_by_timeframe(self, session_id, start_time, end_time):
cursor = self.conn.cursor()
cursor.execute(
"SELECT episode_data FROM agent_episodes WHERE session_id = %s AND timestamp BETWEEN %s AND %s ORDER BY timestamp ASC;",
(session_id, start_time, end_time)
)
records = cursor.fetchall()
cursor.close()
return [r[0] for r in records]
# Exemplo de Uso (substitua pela conexão db real)
# conn = psycopg2.connect(...)
# episodic_mem = EpisodicMemory(conn)
# episodic_mem.add_episode("usuario_abc_sessao_123", {"role": "usuário", "content": "Esqueci minha senha novamente."})
# episodic_mem.add_episode("usuario_abc_sessao_123", {"role": "agente", "content": "Sem problemas, posso ajudar com isso."})
# print(episodic_mem.get_episodes_by_session("usuario_abc_sessao_123", limit=2))
Camada 3: Memória Semântica – A Base de Conhecimento
É isso que a maioria das pessoas pensa quando escuta “RAG.” É sua base de conhecimento factual de longo prazo. Documentos, artigos, FAQs, manuais – qualquer coisa que forneça conhecimento geral do domínio. É aqui que os bancos de dados vetoriais se destacam, permitindo a pesquisa de similaridade em embeddings.
Propósito: Fornece recordação factual, permitindo que o agente responda a perguntas com base em informações pré-existentes. Esses dados são estáticos ou mudam lentamente.
Implementação: Banco de dados vetorial (Pinecone, Weaviate, Chroma, Qdrant) armazenando embeddings de partes dos seus documentos de conhecimento. Este é o motor para recuperar informações de fundo relevantes.
O que é crucial aqui é que o agente não deve *sempre* recorrer à memória semântica. Se a resposta está no scratchpad ou na memória episódica (por exemplo, “O que acabei de te contar?”), ele deve priorizar essas opções. Somente quando precisar de fatos externos ou de um contexto mais amplo deve consultar a memória semântica.
“““html
Camada 4: Memória Procedimental – Habilidades Aprendidas & Rotinas
Isso é frequentemente negligenciado, mas está se tornando incrivelmente importante à medida que os agentes ficam mais complexos. A memória procedimental armazena sequências de ações, padrões de uso de ferramentas ou heurísticas de tomada de decisão que o agente aprendeu ou foi explicitamente programado. Pense nisso como conhecimento de “como fazer”.
Propósito: Permite que o agente execute tarefas complexas de forma eficiente, recuperando procedimentos estabelecidos em vez de replanejar do zero todas as vezes. É aqui que os agentes aprendem a encadear ferramentas, lidar com fluxos de usuários comuns ou aplicar estratégias específicas de resolução de problemas.
Implementação: Isso pode ser complicado. Para casos mais simples, pode ser um conjunto de “receitas” ou “fluxos de trabalho” pré-definidos acionados por certas palavras-chave ou intenções. Para agentes mais avançados, pode envolver o armazenamento de sequências de chamadas de ferramentas e suas condições em um banco de dados gráfico, ou até mesmo usar um modelo de linguagem menor e especializado treinado em conclusões de tarefas bem-sucedidas.
Um exemplo simples para meu bot de tickets: se um usuário diz “reiniciar minha senha,” a memória procedimental pode ditar uma sequência: 1. Confirmar identidade do usuário, 2. Chamar API de redefinição de senha, 3. Notificar o usuário sobre o sucesso, 4. Perguntar se ele precisa de mais alguma coisa. Essa sequência é uma “habilidade” que o agente possui.
class ProceduralMemory:
def __init__(self):
self.skills = {
"password_reset": [
{"action": "confirm_identity", "params": {"method": "email_code"}},
{"action": "call_api", "params": {"endpoint": "/reset_password", "args": {"user_id": "current_user"}}},
{"action": "send_notification", "params": {"message": "Senha redefinida com sucesso!"}},
{"action": "ask_followup", "params": {"question": "Há mais alguma coisa com que eu possa ajudar?"}}
],
"vpn_setup_guide": [
{"action": "retrieve_doc", "params": {"doc_id": "vpn_setup_manual_v2"}},
{"action": "present_steps"},
{"action": "ask_followup", "params": {"question": "Esses passos ajudaram?"}}
]
}
def get_skill_steps(self, skill_name):
return self.skills.get(skill_name, [])
def learn_skill(self, skill_name, steps):
# Em um sistema real, isso envolveria aprendizado/armazenamento mais sofisticado.
self.skills[skill_name] = steps
# Exemplo de Uso
proc_mem = ProceduralMemory()
reset_steps = proc_mem.get_skill_steps("password_reset")
# O agente então executaria esses passos sequencialmente
# Para passo em reset_steps: execute(step)
Juntando Tudo: O Processo de Recuperação do Agente
Então, como um agente realmente usa essas camadas? É uma hierarquia de recuperação, muitas vezes guiada pelo loop de raciocínio interno do agente:
- Interação Atual: Primeiro, verifique o Bloco de Notas. A resposta está imediatamente disponível? Existe um processo de pensamento em andamento que precisa ser continuado?
- Histórico Recente: Se não, consulte a Memória Episódica. Essa pergunta exata ou uma muito semelhante foi feita recentemente nesta conversa? Quais foram as interações anteriores? Quais ferramentas foram usadas? Isso ajuda a manter a coerência e evita repetição.
- Conhecimento a Longo Prazo: Se o acima não fornecer uma resposta direta ou contexto suficiente, então consulte a Memória Semântica. “Quais são os fatos sobre X?” “Conte-me sobre Y.” É aqui que seu RAG entra.
- Ação & Estratégia: À medida que o agente planeja seu próximo movimento, ele consulta a Memória Procedimental. “Dada essa intenção, eu tenho uma maneira predefinida de lidar com isso?” “Que sequência de ferramentas devo usar para essa tarefa?”
A chave é uma orquestração cuidadosa desses tipos de memória. O motor de raciocínio central do agente (seu LLM) precisa saber *quando* consultar qual camada de memória e como sintetizar informações a partir delas.
Insights Ação para a Arquitetura do Seu Agente
“`
- Não confie apenas no preenchimento da janela de contexto: É uma solução temporária, não uma solução de memória escalável. Assim que você vai além de perguntas e respostas simples, você atingirá limites.
- Implemente pelo menos duas camadas de memória inicialmente: Um Bloco de Notas (para a interação atual) e uma Memória Episódica (para o histórico completo da conversa). Isso por si só tornará seus agentes muito mais coerentes.
- Separe o conhecimento factual do histórico de conversas: Seu banco de dados vetorial para RAG (Memória Semântica) deve ser distinto de onde você armazena o registro cronológico das interações do usuário (Memória Episódica).
- Pense sobre as habilidades do agente: Como seu agente pode aprender ou ser ensinado a realizar sequências de ações? Comece com “receitas” simples e predefinidas (Memória Procedimental) e construa a partir daí.
- Projete para resumir e comprimir: À medida que a memória episódica cresce, você não pode reintroduzir tudo no LLM. Resuma periodicamente conversas passadas em fatos de nível superior ou pontos-chave e armazene esses resumos de forma mais compacta (por exemplo, como novas entradas na memória semântica, ou como “insights” na memória episódica).
- Priorize o acesso à memória: O loop de raciocínio do seu agente deve decidir explicitamente qual camada de memória consultar com base na consulta atual e seu estado interno. Não se trata mais apenas de recuperar o “mais semelhante”.
Construir agentes de IA verdadeiramente inteligentes e com estado não é apenas sobre escolher o maior LLM ou a configuração RAG mais sofisticada. É sobre projetar uma arquitetura que imite como a inteligência opera – gerenciando efetivamente informações em diferentes escalas de tempo e níveis de abstração. Meu “bot de tickets” começou sem inteligência, mas ao implementar essas camadas de memória, agora é realmente útil, lembrando passos de solução de problemas anteriores e até sugerindo soluções proativas com base em interações passadas. Experimente; seus agentes (e seus usuários) vão agradecê-lo.
Isso é tudo por hoje. Deixe suas opiniões ou quais arquiteturas de memória você achou úteis nos comentários abaixo! E, como sempre, continue construindo.
🕒 Published: