RAG não é memória. Memória não é contexto. E contexto não é prompt.

Os quatro termos aparecem juntos com tanta frequência que é fácil tratá-los como praticamente sinônimos, ou pior, como se um fosse só uma versão mais chique do outro. Não são. Cada um resolve um problema diferente, e a confusão entre eles costuma ser o motivo real por trás de frases como “meu agente não lembra de nada”, ditas sobre sistemas que nunca tiveram memória nenhuma para começo de conversa.

Prompt é a instrução de uma chamada específica

Prompt é o texto de entrada enviado numa chamada específica ao modelo: a pergunta, a instrução, o comando. É a unidade mais concreta e mais imediata dos quatro conceitos, existe naquela chamada e só naquela chamada.

Contexto é tudo que está ativo naquele momento

Contexto é mais amplo que prompt: é todo o conteúdo presente dentro da janela de contexto do modelo no momento da geração, o que inclui o prompt atual, mas também o histórico da conversa reenviado junto, instruções de sistema, e qualquer trecho de documento injetado por um mecanismo externo. O prompt é uma parte do contexto. O contexto é o pacote inteiro que o modelo efetivamente enxerga naquela chamada.

Isso já explica por que um modelo “esquece” o que foi dito há muitas mensagens atrás numa conversa longa: se aquele trecho antigo não está mais dentro do contexto reenviado (por limite de tamanho, por truncamento, por qualquer estratégia de gerenciamento de janela), ele simplesmente não existe para aquela chamada específica, mesmo tendo existido em algum momento anterior da mesma conversa.

Memória é o que sobrevive além do contexto de uma chamada

Memória é diferente de contexto porque ela persiste deliberadamente além de uma única chamada, ou até além de uma única sessão. Um sistema de memória guarda informação relevante (uma preferência do usuário, um fato mencionado numa conversa anterior) num armazenamento externo, e decide, em algum momento posterior, recuperar e reinserir essa informação dentro do contexto de uma nova chamada.

A parte importante aqui é que memória não é uma capacidade nativa do modelo. É uma camada de engenharia construída em volta dele: alguém precisa decidir o que guardar, onde guardar, e quando (e como) trazer aquilo de volta para dentro do contexto na hora certa. Sem essa camada, não existe memória nenhuma, só uma sequência de chamadas independentes, cada uma vendo apenas o que está dentro do próprio contexto daquela vez.

RAG é um mecanismo de busca, não é a memória em si

RAG é o mecanismo específico de buscar informação relevante numa fonte externa (tipicamente documentos, não necessariamente histórico de conversa do usuário) e injetar isso no contexto antes da geração. Ele pode ser usado como uma das formas de implementar memória, buscando conversas ou fatos anteriores guardados de forma indexada, mas RAG e memória não são a mesma coisa: RAG é a técnica de recuperação, memória é o problema de persistência que essa técnica pode ajudar a resolver, entre outras abordagens possíveis, como simplesmente resumir e reinjetar o histórico relevante sem envolver busca vetorial nenhuma.

Juntando os quatro numa única cadeia

Numa aplicação com memória e RAG combinados, a cadeia funciona assim: memória decide o que persiste entre chamadas e guarda isso em algum lugar. RAG busca, dentro dessa memória ou de uma base de conhecimento externa, o que é relevante para a pergunta atual. Esse resultado, junto com histórico recente e instrução de sistema, forma o contexto daquela chamada específica. E o prompt é a parte mais imediata desse contexto, a pergunta ou instrução que efetivamente disparou a geração.

Por que separar isso evita diagnóstico errado

Um sistema “sem memória” pode simplesmente estar gerenciando mal o contexto, cortando informação relevante de uma janela que na verdade nunca precisou de mecanismo de memória nenhum, só de um limite maior ou melhor gerenciado. Um sistema “com RAG mal configurado” pode estar sendo confundido com um problema de memória, quando na real o que falta é uma busca melhor sobre uma fonte externa. Separar os quatro conceitos evita gastar esforço corrigindo a peça errada de um sistema que, na verdade, tem um problema bem específico numa camada bem específica.