Memória e Contexto
O Problema da Memória
Por que o LLM esquece entre chamadas e o que significa stateless na prática.
Nesta aula você vai
- Explicar que cada chamada HTTP é independente por padrão
- Relacionar amnésia do chatbot com arquitetura, não "defeito" do modelo
- Listar o que precisa ser persistido externamente
O Problema da Memória
Objetivos
- Entender limitações nativas — e a solução correta
- Parar de esperar que o modelo "lembre" sozinho
"Você não lembra do que eu disse?"
Esse é o bug report mais comum em chatbot novo — e quase nunca é bug do modelo.
O usuário testa:
Usuário: "Meu nome é Bruno."
Bot: "Prazer, Bruno!"
Usuário: (nova mensagem, nova requisição) "Qual meu nome?"
Bot: "Não tenho essa informação."
O cliente acha que a IA é "burra". Na verdade, o sistema foi construído como stateless — cada chamada HTTP é uma conversa nova para o provedor.
Entender isso muda tudo: memória não é feature mágica do GPT; é responsabilidade da sua aplicação.
Stateless por padrão
Cada POST /chat/completions é isolado. O modelo não guarda nada após responder.
Requisição 1: "Meu nome é Bruno" → "Prazer, Bruno!"
Requisição 2: "Qual meu nome?" → "Não tenho essa informação"
Não é defeito — não há sessão no servidor do OpenAI ligada ao seu usuário. Você envia contexto ou não envia.
Analogia: o LLM é um consultor que entra na sala, responde e sai. Se você não deixar anotações na mesa para a próxima reunião, ele não lembra de nada.
O que o ChatGPT web faz diferente
A interface do ChatGPT mantém histórico no produto deles e reenvia mensagens anteriores a cada turno. Parece memória — mas é reenvio de contexto.
Você replica isso no seu backend: salva mensagens, monta messages[] de novo a cada chamada.
Diálogo de arquitetura:
Junior: "Vamos pedir pro OpenAI guardar sessão."
Senior: "Não existe sessão persistente no provedor. Guardamos nós."
Junior: "No banco?"
Senior: "Sim — e limitamos quantas mensagens reenviamos."
Três tipos de "memória" em produtos reais
| Tipo | Onde vive | Exemplo |
|---|---|---|
| Curto prazo | Histórico da conversa atual | Últimas 10 mensagens no prompt |
| Longo prazo | Banco de dados do usuário | Preferências, pedidos anteriores |
| Conhecimento | Docs, FAQ, vetores (RAG — próximo nível) | Manual do produto |
Este curso cobre curto prazo + ponte para longo prazo via tools (matéria final).
O que persistir
Mínimo por mensagem:
{
"sessionId": "sess_abc",
"role": "user",
"content": "Pedido 4421?",
"createdAt": "2025-06-25T14:00:00Z",
"tokensEstimate": 12
}
Opcional: userId, channel, metadata.
Pense na tabela de mensagens como gravador da conversa — o LLM só lê a transcrição que você escolher enviar.
Anti-padrão: confiar no frontend
// ❌ Frontend manda histórico completo — usuário pode manipular
body: { messages: [...1000 mensagens falsas...] }
Backend carrega histórico do seu banco por sessionId autenticado. Usuário malicioso não injeta contexto falso para enganar o bot ou estourar tokens.
Resumo
- LLM não lembra — sua aplicação lembra
- Memória = reenviar contexto relevante a cada chamada
- Persistência externa (DB/Redis) é obrigatória para assistente real
Na próxima aula implementamos isso: salvar mensagens, carregar histórico e fazer "Qual meu nome?" funcionar de verdade.