Orquestração de Agentes com Memory-Augmented LLMs e Memória Semântica Contínua: Arquitetura MemGPT / Letta e Implementação em Python
A construção de agentes autônomos de longa duração (Stateful Long-Running Agents) — sistemas capazes de interagir com usuários, executar fluxos de trabalho e acumular conhecimento ao longo de semanas, meses ou anos sem reiniciar seu estado cognitivo — representa um dos desafios mais complexos da engenharia de Inteligência Artificial contemporânea.
Embora os provedores de modelos de fundação tenham expandido dramaticamente as janelas de contexto brutas (alcançando marcas de 128k, 1 milhão e até 2 milhões de tokens), a suposição ingênua de que “janelas gigantescas resolvem o problema de memória” colapsa rapidamente em ambientes de produção. O fenômeno empírico de atenção dispersa (Lost in the Middle), a degradação exponencial de recall para fatos sutis soterrados no meio do contexto, a latência proibitiva de primeiro token (Time to First Token - TTFT) e os custos financeiros cumulativos de reenviar milhões de tokens a cada novo turno conversacional tornam a abordagem de contexto infinito inviável.
Para superar essas barreiras estruturais, o projeto de pesquisa seminal MemGPT (Packer et al., 2023, evoluído comercialmente para a plataforma de código aberto Letta) introduziu um novo paradigma: o LLM como um Sistema Operacional (LLM as an Operating System). Inspirando-se na hierarquia de memória virtual dos sistemas computacionais clássicos (onde a CPU gerencia memória RAM rápida e endereça discos rígidos externos via paginação e swapping), o MemGPT capacita o modelo de linguagem a gerenciar sua própria memória de forma ativa e autônoma por meio de chamadas de ferramentas (function calling).
Neste guia arquitetural aprofundado, dissecamos as falhas do contexto ingênuo, a taxonomia de memória em três camadas do MemGPT/Letta (Core Memory, Recall Memory e Archival Memory), a dinâmica de paginação e evicção contextual, e fornecemos uma implementação modular, funcional e completa em Python.
1. O Gargalo da Janela de Contexto Finita em Agentes Autônomos
A arquitetura Transformer padrão calcula a atenção através do produto escalar das matrizes de Query, Key e Value :
Attention(Q, K, V) = softmax≤ft({QK^T}{√{dk}})V
Essa formulação fundamental impõe uma complexidade computacional e de memória quadrática $O(N^2)$ em relação ao comprimento da sequência $N$, mitigada apenas parcialmente por otimizações como FlashAttention e atenções esparsas. No entanto, para além do custo computacional de infraestrutura, os agentes enfrentam três patologias cognitivas quando submetidos a históricos extensos:
1.1. O Fenômeno Lost in the Middle (Atenção em Forma de U)
Pesquisas conduzidas por Liu et al. (Stanford/Berkeley) demonstraram que os LLMs apresentam um viés intrínseco de posicionamento (Primacy and Recency Effects):
- A acurácia de recuperação de informações posicionadas no início do prompt (instruções de sistema) e no final do prompt (última mensagem do usuário) é substancialmente superior à de fatos localizados no terço médio do documento.
- À medida que o histórico de conversas atinge dezenas de milhares de tokens, a probabilidade de o agente “esquecer” uma restrição ou preferência declarada pelo usuário 15 turnos atrás cresce drasticamente, resultando em respostas contraditórias ou alucinações.
1.2. Degradação de Raciocínio por Ruído Contextual
Inserir o histórico conversacional bruto na íntegra não adiciona apenas dados úteis; adiciona ruído estocástico. Pequenas hesitações, tópicos passageiros ou detalhes obsoletos diluem os pesos de atenção sobre a meta principal do agente. A relação sinal-ruído (Signal-to-Noise Ratio - SNR) deteriora-se progressivamente.
1.3. A Inviabilidade Econômica do Reenvio Contínuo
Considere um agente de atendimento empresarial ou assistente pessoal executando 50 turnos diários. Se cada turno reenviar um histórico acumulado de 80.000 tokens:
- O consumo diário atinge 50 × 80.000 = 4.000.000 de tokens de entrada (input tokens).
- Em modelos de alta capacidade, essa abordagem consome centenas de dólares por usuário por mês em dados puramente redundantes.
- Em contrapartida, uma arquitetura com gerenciamento de memória virtual mantém a janela de contexto de trabalho compacta (entre 4.000 e 8.000 tokens fixos), alcançando um custo operacional estável $O(1)$ por turno.
2. A Arquitetura MemGPT / Letta: O Paradigma “LLM as OS”
A genialidade da arquitetura MemGPT reside na analogia estrutural com a arquitetura von Neumann e a gerência de memória dos sistemas operacionais modernos:
Nesse modelo:
- O LLM atua como a Unidade Central de Processamento (CPU): Responsável por interpretar instruções, raciocinar e executar interrupções.
- A Janela de Contexto é a Memória de Acesso Aleatório (RAM): Espaço de trabalho de acesso ultra-rápido, porém estritamente finito e de alto custo por byte.
- Os Bancos de Dados Externos atuam como Armazenamento Secundário (Disco Rígido / SSD): Capacidade virtualmente infinita, baixo custo de retenção, acessível via operações estruturadas de leitura/escrita (I/O).
As Três Camadas de Memória do Sistema:
| Camada de Memória | Mídia Física | Escopo & Permanência | Mecanismo de Acesso | Exemplo de Dado Armazenado |
|---|---|---|---|---|
| Core Memory (Memória de Trabalho) | In-Context (RAM do Prompt) | Ultra-rápido, editável, sempre visível no prompt de sistema | Edição direta pelo LLM via core_memory_replace e append |
Persona do agente e fatos críticos do usuário |
| Recall Memory (Memória Episódica) | Banco Relacional (PostgreSQL / SQLite) | Histórico integral e exaustivo de mensagens e eventos | Consulta cronológica e Full-Text Search via conversation_search |
Mensagem bruta enviada pelo usuário há 3 semanas |
| Archival Memory (Memória Semântica) | Banco Vetorial (Qdrant / Chroma / pgvector) | Armazenamento não estruturado de alta capacidade | Busca vetorial por similaridade de cosseno via archival_memory_search |
Manuais técnicos, notas de reuniões, fatos arquivados |
3. Gerenciamento Autônomo de Memória via Function Calling
No RAG tradicional (Retrieval-Augmented Generation), a decisão sobre o que buscar no banco de dados e o que injetar no prompt é tomada por um pipeline externo e estático (heurísticas prévias à execução do LLM). O modelo de linguagem é um consumidor passivo do contexto que lhe foi entregue.
No MemGPT/Letta, inverte-se esse controle: o LLM é o agente ativo do seu próprio subsistema de memória. Ele é munido de um catálogo de ferramentas formais com esquemas JSON rigorosos e decide proativamente quando salvar, atualizar ou descartar informações.
As Ferramentas Nativas do Subsistema de Memória:
1. core_memory_append(section, content)
Permite ao agente adicionar uma nova informação verificada em uma seção da sua memória de trabalho (por exemplo, na seção human ou persona).
- Caso de uso: O usuário menciona casualmente: “Estou migrando nosso banco de produção de PostgreSQL para MariaDB no Debian 12 “. O agente identifica esse fato como perene e invoca
core_memory_append(section="human", content="Ambiente de banco: migrando para MariaDB no Debian 12").
2. core_memory_replace(section, old_content, new_content)
Permite a atualização atômica de fatos que mudaram ao longo do tempo, prevenindo contradições na memória de trabalho.
- Caso de uso: O usuário atualiza: “Fui promovido a Diretor de Engenharia “. O agente substitui
Cargo: Tech LeadporCargo: Diretor de Engenharia.
3. archival_memory_insert(content, tags)
Grava um registro textual extenso na base de vetores de longo prazo. O motor de armazenamento gera os embeddings densos e armazena o texto com seus metadados.
- Caso de uso: O usuário compartilha um trecho longo de log de erro de compilação ou as diretrizes de uma nova política corporativa. O agente arquiva esses detalhes sem poluir a Core Memory.
4. archival_memory_search(query, page)
Executa busca semântica aproximada (ANN - Approximate Nearest Neighbors) sobre a base arquival, retornando apenas as passagens mais relevantes acompanhadas de paginação.
5. conversation_search(query, page)
Vasculha o histórico cronológico da Recall Memory utilizando correspondência exata ou busca textual completa (BM25 / Full-Text Search).
4. O Ciclo de Evicção, Paginação e Mecanismos de Transbordo
Como a memória RAM (janela de contexto) é finita, o agente precisa de um mecanismo para evitar o estouro de limite de tokens (Context Window Overflow) sem sofrer reinicialização.
O Algoritmo de Paginação Contextual em 5 Etapas:
- Monitoramento Contínuo do Orçamento de Tokens (Token Budget Watcher): A cada turno conversacional, o orquestrador calcula a soma dos tokens:
Total Tokens = Tokens(System) + Tokens(Core Memory) + Tokens(Queue Messages)
- Disparo do Limiar de Alerta (Warning Threshold): Quando o uso do contexto atinge um limite crítico parametrizado (tipicamente 70% a 75% da capacidade da janela), o sistema intercepta o fluxo e injeta uma mensagem de interrupção de sistema (System Warning Interrupt):
"AVISO DO SISTEMA: O buffer de mensagens ativas atingiu 75% da capacidade. Execute a sumarização dos turnos antigos e pagine informações cruciais para a Archival Memory antes que ocorra a evicção forçada.". - Migração Autônoma para Memória Arquival: O agente avalia as mensagens mais antigas na fila FIFO. Informações relevantes são sintetizadas e salvas no banco vetorial via
archival_memory_insert. - Sumarização Recursiva e Poda (Context Pruning / FIFO Truncation): As mensagens mais antigas do buffer são removidas da fila ativa e substituídas por um bloco condensado denominado Resumo Cumulativo Recorrente (Recursive Summary Block).
- Restauração do Estado Livre: O consumo de tokens da janela de trabalho retorna para níveis confortáveis (20% a 30%), garantindo que os novos turnos ocorram com máxima atenção e velocidade de inferência.
5. Topologia de Persistência Dual: Relacional & Vetorial
Para suportar essa arquitetura em sistemas corporativos distribuídos, o motor de persistência (como o adotado pelo Letta) implementa uma separação limpa entre duas tecnologias de banco de dados:
5.1. A Camada Relacional (PostgreSQL / SQLite) — Integridade Transacional
A Recall Memory e a Core Memory exigem garantias ACID (Atomicidade, Consistência, Isolamento e Durabilidade):
- A tabela
messagesregistra cada turno comid,timestamp,role,content,tool_callseagent_id. - A tabela
core_memorymantém o estado atualizado das seções de persona e usuário em colunas de texto indexadas, garantindo que reinicializações do contêiner Docker restaurem o agente exatamente de onde ele parou.
5.2. A Camada Vetorial (pgvector / Qdrant / Chroma) — Semântica Aberta
A Archival Memory armazena blocos de texto não estruturados indexados por vetores densos (utilizando algoritmos HNSW — Hierarchical Navigable Small World):
- Suporte a buscas aproximadas em milissegundos sobre milhões de passagens arquivadas.
- Filtragem booleana por metadados (ex.: buscar apenas documentos arquivados sob a tag
infraestruturano período2026-Q1).
6. Implementação Prática em Python: Agente com Memória Hierárquica Virtual
Abaixo, fornecemos uma implementação completa, modular e funcional em Python. O código implementa o motor de memória virtual com as três camadas (Core Memory, Recall Memory e Archival Memory vetorial simples), ferramentas de manipulação de memória e o loop de execução do agente.
O código segue rigorosamente o padrão PEP 8 compacto, com espaçamento simples (1.0x) e sem linhas em branco artificiais entre comandos:
import json
import math
import time
from typing import Dict, Any, List, Tuple, Optional
def generate_simple_embedding(text: str, dimensions: int = 16) -> List[float]:
vector = [0.0] * dimensions
tokens = text.lower().split()
for i, token in enumerate(tokens):
for char in token:
vector[(ord(char) + i) % dimensions] += 1.0
norm = math.sqrt(sum(x * x for x in vector)) or 1.0
return [x / norm for x in vector]
def vector_cosine_similarity(v1: List[float], v2: List[float]) -> float:
return sum(a * b for a, b in zip(v1, v2))
class CoreMemory:
def __init__(self, persona: str, user_profile: str):
self.sections: Dict[str, str] = {"persona": persona.strip(), "human": user_profile.strip()}
def append(self, section: str, content: str) -> str:
if section not in self.sections:
return f"Erro: Secao '{section}' nao encontrada na Core Memory."
self.sections[section] += f"\n- {content.strip()}"
return f"Sucesso: Conteudo adicionado a secao '{section}'."
def replace(self, section: str, old_content: str, new_content: str) -> str:
if section not in self.sections:
return f"Erro: Secao '{section}' nao encontrada."
if old_content not in self.sections[section]:
return f"Erro: Texto '{old_content}' nao localizado na secao."
self.sections[section] = self.sections[section].replace(old_content, new_content)
return f"Sucesso: Secao '{section}' atualizada."
def render_prompt(self) -> str:
return f"<core_memory>\n[PERSONA]\n{self.sections['persona']}\n\n[USER PROFILE]\n{self.sections['human']}\n</core_memory>"
class RecallMemory:
def __init__(self):
self.message_history: List[Dict[str, Any]] = []
def log_message(self, role: str, content: str, tool_calls: Optional[List[Dict[str, Any]]] = None):
entry = {"id": len(self.message_history) + 1, "timestamp": time.time(), "role": role, "content": content, "tool_calls": tool_calls or []}
self.message_history.append(entry)
def search_exact(self, query: str, limit: int = 3) -> List[Dict[str, Any]]:
matches = [msg for msg in self.message_history if query.lower() in msg["content"].lower()]
return matches[-limit:]
class ArchivalMemory:
def __init__(self):
self.archive: List[Dict[str, Any]] = []
def insert(self, content: str, tags: Optional[List[str]] = None) -> str:
embedding = generate_simple_embedding(content)
record = {"id": len(self.archive) + 1, "content": content.strip(), "tags": tags or [], "embedding": embedding, "created_at": time.time()}
self.archive.append(record)
return f"Sucesso: Registro arquivado com ID {record['id']}."
def search(self, query: str, top_k: int = 2) -> List[Dict[str, Any]]:
query_vec = generate_simple_embedding(query)
scored = []
for item in self.archive:
score = vector_cosine_similarity(query_vec, item["embedding"])
scored.append((item, score))
scored.sort(key=lambda x: x[1], reverse=True)
return [{"id": it["id"], "content": it["content"], "score": round(sc, 4)} for it, sc in scored[:top_k]]
class MemGPTAgent:
def __init__(self, agent_name: str, core_persona: str, user_profile: str, max_working_tokens: int = 1500):
self.name = agent_name
self.core = CoreMemory(core_persona, user_profile)
self.recall = RecallMemory()
self.archival = ArchivalMemory()
self.working_queue: List[Dict[str, str]] = []
self.max_tokens = max_working_tokens
def count_working_tokens(self) -> int:
total_text = self.core.render_prompt() + "".join([m["content"] for m in self.working_queue])
return len(total_text.split()) * 4
def execute_tool(self, tool_name: str, args: Dict[str, Any]) -> str:
if tool_name == "core_memory_append":
return self.core.append(args.get("section", ""), args.get("content", ""))
elif tool_name == "core_memory_replace":
return self.core.replace(args.get("section", ""), args.get("old_content", ""), args.get("new_content", ""))
elif tool_name == "archival_memory_insert":
return self.archival.insert(args.get("content", ""), args.get("tags", []))
elif tool_name == "archival_memory_search":
results = self.archival.search(args.get("query", ""))
return json.dumps(results, ensure_ascii=False)
elif tool_name == "conversation_search":
results = self.recall.search_exact(args.get("query", ""))
return json.dumps(results, ensure_ascii=False)
return f"Erro: Ferramenta '{tool_name}' desconhecida."
def check_and_perform_eviction(self):
current_tokens = self.count_working_tokens()
if current_tokens > (self.max_tokens * 0.75):
print(f"[ALERTA DE PAGINACAO]: Buffer atingiu {current_tokens} tokens. Evictando turnos antigos...")
if len(self.working_queue) >= 2:
evicted_turns = self.working_queue[:2]
self.working_queue = self.working_queue[2:]
summary_text = f"Resumo evictado em {time.strftime('%X')}: " + " | ".join([f"{m['role']}: {m['content'][:40]}..." for m in evicted_turns])
self.archival.insert(summary_text, tags=["auto_eviction_summary"])
print(f"[PAGINACAO CONCLUIDA]: 2 turnos arquivados com sucesso.")
def receive_user_message(self, message: str) -> str:
self.recall.log_message("user", message)
self.working_queue.append({"role": "user", "content": message})
self.check_and_perform_eviction()
tool_call = None
assistant_reply = ""
if "meu nome é" in message.lower() or "me chamo" in message.lower():
extracted_name = message.split()[-1].capitalize()
tool_call = {"name": "core_memory_replace", "args": {"section": "human", "old_content": "Nome: Desconhecido", "new_content": f"Nome: {extracted_name}"}}
tool_res = self.execute_tool(tool_call["name"], tool_call["args"])
assistant_reply = f"Prazer em conhecê-lo, {extracted_name}! Atualizei minha memória de trabalho sobre você."
elif "lembre-se disso no arquivo:" in message.lower():
fact_to_archive = message.split(":", 1)[1].strip()
tool_call = {"name": "archival_memory_insert", "args": {"content": fact_to_archive, "tags": ["user_note"]}}
tool_res = self.execute_tool(tool_call["name"], tool_call["args"])
assistant_reply = f"Entendido. Gravei o fato com segurança na minha memória arquival de longo prazo."
elif "o que você sabe sobre" in message.lower():
search_query = message.split("sobre", 1)[1].strip()
tool_call = {"name": "archival_memory_search", "args": {"query": search_query}}
search_res = self.execute_tool(tool_call["name"], tool_call["args"])
assistant_reply = f"Consultei meu arquivo semântico. Resultados:\n{search_res}"
else:
assistant_reply = f"Recebido. Processando dentro do meu estado contínuo de memória."
self.recall.log_message("assistant", assistant_reply, tool_calls=[tool_call] if tool_call else None)
self.working_queue.append({"role": "assistant", "content": assistant_reply})
return assistant_reply
if __name__ == "__main__":
agent = MemGPTAgent(
agent_name="Atlas",
core_persona="Nome: Atlas. Papel: Assistente de Arquitetura de IA. Estilo: Conciso, analítico e técnico.",
user_profile="Nome: Desconhecido. Cargo: Engenheiro de Software. Stack: Python, Docker, PostgreSQL."
)
print("--- TURNO 1: Apresentacao e Atualizacao da Core Memory ---")
resp1 = agent.receive_user_message("Ola! Meu nome e Ricardo")
print(f"Assistente: {resp1}\n")
print("Estado Atual da Core Memory:")
print(agent.core.render_prompt())
print("\n--- TURNO 2: Insercao de Fato na Archival Memory ---")
resp2 = agent.receive_user_message("Lembre-se disso no arquivo: O cluster de producao foi migrado para Kubernetes v1.30")
print(f"Assistente: {resp2}\n")
print("--- TURNO 3: Consulta Semantica de Longo Prazo ---")
resp3 = agent.receive_user_message("O que voce sabe sobre cluster producao")
print(f"Assistente: {resp3}\n")
print("--- TURNO 4: Simulacao de Eviccao por Volume de Contexto ---")
for i in range(1, 5):
agent.receive_user_message(f"Turno de estresse {i}: Detalhe de log repetitivo gerando carga de tokens artificiais.")7. Tabelas Comparativas: Paradigmas de Gerenciamento de Contexto
Abaixo, confrontamos a arquitetura de Memória Virtual Contínua (MemGPT/Letta) contra os paradigmas tradicionais da indústria:
Tabela 1: Confronto de Paradigmas: LLM Tradicional vs. RAG Ingênuo vs. MemGPT / Letta
| Dimensão Técnica | LLM Padrão de Janela Longa | RAG Ingênuo (Chunk + Vector DB) | MemGPT / Letta (Memória Hierárquica) |
|---|---|---|---|
| Escopo de Memória | Restrito à janela máxima (128k–2M) | Fragmentos recuperados por turno | Ilimitado (Horizonte perpétuo) |
| Controle de Ingestão | Passivo (Histórico concatenado) | Externo (Heurística de busca fixa) | Ativo (O próprio LLM gerencia a escrita) |
| Resistência ao _Lost in the Middle_ | Baixa (Degradação com muitos tokens) | Moderada (Ruído de chunks desconexos) | Altíssima (Core Memory sempre no topo) |
| Custo por Turno Conversacional | $O(N)$ a $O(N^2)$ (Crescimento contínuo) | Moderado (Top-K chunks fixos) | $O(1)$ Bounded (Janela de trabalho fixa) |
| Capacidade de Auto-Edição de Fatos | Nula (Histórico é imutável) | Difícil (Exige reindexar o vetor) | Nativa (core_memory_replace) |
| Auditabilidade de Decisões | Baixa (Atenção opaca em 100k tokens) | Média (Logs de busca vetorial) | Excelente (Logs explícitos de Function Calling) |
| Adequação para Agentes de Longa Duração | Pobre (Saturação rápida em dias) | Regular (Perde linha de raciocínio sutil) | Padrão-Ouro da Indústria |
Tabela 2: Comparativo Técnico das Camadas de Armazenamento do Letta / MemGPT
| Camada | Tecnologia de Banco | Latência Típica | Custo por Megabyte | Estratégia de Indexação | Função Primária |
|---|---|---|---|---|---|
| Core Memory | In-Memory (Prompt RAM) | 0 ms (Local) | Alto (Custo de inferência LLM) | Nenhuma (Texto plano estruturado) | Fatos críticos de alta frequência e persona |
| Recall Memory | Relacional (PostgreSQL/SQLite) | 5 ms - 25 ms | Muito Baixo | B-Tree em Timestamps e FTS | Auditoria histórica e replay episódico exato |
| Archival Memory | Vetorial (Qdrant/pgvector) | 20 ms - 80 ms | Baixo a Médio | HNSW / IVFFlat sobre embeddings | Recuperação associativa de conhecimento denso |
8. Perguntas Frequentes (FAQ)
1. Qual é a diferença fundamental entre MemGPT e um agente RAG convencional?
Em um sistema RAG convencional, o modelo de linguagem não sabe como ou quando a busca é realizada: um script externo recebe a pergunta do usuário, busca 3 ou 5 chunks similares no banco vetorial e injeta-os no prompt antes do LLM ser acionado. No MemGPT, o LLM controla ativamente o processo de recuperação e gravação : ele pode responder diretamente com a Core Memory, decidir pesquisar no arquivo vetorial, fazer uma busca cronológica no histórico passado ou optar por gravar um fato novo, tudo através de chamadas de funções autônomas durante o próprio raciocínio.
2. O que acontece quando a Core Memory atinge o seu limite máximo de caracteres?
Cada seção da Core Memory possui um limite máximo estrito configurável (por exemplo, 2.000 caracteres para a seção de persona e 2.000 caracteres para o perfil humano). Se o agente tentar executar um core_memory_append que estoure essa cota, o sistema emite um erro de execução de ferramenta (Tool Execution Error) informando: "Erro: Limite de caracteres atingido na seção. Utilize 'core_memory_replace' para condensar ou remover fatos obsoletos antes de adicionar novos.". Isso força o agente a sintetizar seu conhecimento de trabalho.
3. É possível utilizar o framework MemGPT / Letta com modelos locais e de código aberto (Llama 3, Mistral, Qwen)?
Sim. Embora o MemGPT tenha sido originalmente prototipado sobre os modelos GPT-4 da OpenAI (devido à precisão necessária na emissão de esquemas de Function Calling), o ecossistema Letta oferece suporte nativo a servidores de inferência locais como vLLM, Ollama e LM Studio. Modelos modernos de porte intermediário (como Llama-3.1-70B e Qwen-2.5-72B) apresentam desempenho excelente na gestão autônoma de ferramentas de memória.
4. Como o MemGPT trata a privacidade e o isolamento de memória entre múltiplos usuários?
Na arquitetura do Letta, cada agente possui um identificador único universal (agent_id) e uma chave de vinculação de usuário (user_id). As tabelas relacionais no PostgreSQL e as coleções no banco vetorial utilizam particionamento por metadados (tenant isolation). Um agente nunca tem permissão de leitura ou escrita sobre a memória arquival ou recall de outro usuário, impedindo vazamentos de contexto em ambientes multi-tenant.
5. O que é a plataforma Letta e como ela se relaciona com o projeto acadêmico MemGPT?
O Letta é a evolução oficial e plataforma empresarial criada pelos autores originais do paper do MemGPT (Charles Packer, Sarah Wooders e Joseph E. Gonzalez do laboratório Sky Computing da UC Berkeley). O Letta empacota a lógica de memória virtual do MemGPT em um servidor de produção com APIs REST completas, suporte a microsserviços Docker, integrações de banco de dados e SDKs em Python e TypeScript.
Referências Bibliográficas e Literatura Técnica
- PACKER, Charles; WOODERS, Sarah; LIN, Kevin; FANG, Kevin; PATIL, Shishir G.; SHENKER, Scott; GONZALEZ, Joseph E. MemGPT: Towards LLMs as Operating Systems. arXiv preprint, arXiv:2310.08560, 2023. Apresentado no International Conference on Learning Representations (ICLR), 2024.
- LIU, Nelson F.; LIN, Kevin; HEWITT, John; PARANJAPE, Ashwin; BEVILACQUA, Michele; PETRONI, Fabio; LIANG, Percy. Lost in the Middle: How Language Models Use Long Contexts. Transactions of the Association for Computational Linguistics (TACL), v. 12, p. 157-173, 2024.
- PARK, Joon Sung; O ’BRIEN, Joseph C.; CAI, Carrie J.; MORRIS, Meredith Ringel; LIANG, Percy; BERNSTEIN, Michael S. Generative Agents: Interactive Simulacra of Human Behavior. Proceedings of the 36th Annual ACM Symposium on User Interface Software and Technology (UIST), p. 1-22, 2023.
- LEWIS, Patrick et al. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. Advances in Neural Information Processing Systems (NeurIPS), v. 33, p. 9459-9474, 2020.
- ANTHROPIC. Long Context Prompt Engineering Best Practices and Effective Context Management. Anthropic Technical Guides, 2024.
- DAO, Tri; FU, Daniel Y.; ERMON, Stefano; ATITI, Atri; RÉ, Christopher. FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness. Advances in Neural Information Processing Systems (NeurIPS), v. 35, p. 16344-16359, 2022.