Reflexões sobre o ChatGPT e os sistemas de memória do Claude: O que é preciso para permitir a recuperação de conversas a pedido

Nos sistemas de agentes de IA de alta qualidade, a conceção da memória é muito mais complexa do que parece à primeira vista. No fundo, tem de responder a três questões fundamentais: Como é que o histórico de conversação deve ser armazenado? Quando é que o contexto passado deve ser recuperado? E o que, exatamente, deve ser recuperado?

Estas escolhas moldam diretamente a latência de resposta de um agente, a utilização de recursos e - em última análise - o seu limite de capacidade.

Modelos como o ChatGPT e o Claude sentem-se cada vez mais "conscientes da memória" quanto mais os usamos. Lembram-se das preferências, adaptam-se a objectivos a longo prazo e mantêm a continuidade entre sessões. Nesse sentido, já funcionam como mini agentes de IA. No entanto, por baixo da superfície, os seus sistemas de memória são construídos com base em pressupostos arquitectónicos muito diferentes.

Análises recentes de engenharia reversa dos mecanismos de memória do ChatGPTe do Claude revelam um claro contraste. O ChatGPT baseia-se na injeção de contexto pré-computado e no armazenamento em cache em camadas para proporcionar uma continuidade leve e previsível. O Claude, por outro lado, adopta o estilo RAG, recuperação a pedido com actualizações dinâmicas da memória para equilibrar a profundidade e a eficiência da memória.

Essas duas abordagens não são apenas preferências de design - elas são moldadas pela capacidade da infraestrutura. O Milvus 2.6 introduz a combinação de recuperação híbrida densa e esparsa, filtragem escalar eficiente e armazenamento em camadas que a memória conversacional a pedido requer, tornando a recuperação selectiva suficientemente rápida e económica para ser implementada em sistemas do mundo real.

Neste post, vamos ver como funcionam os sistemas de memória do ChatGPT e do Claude, porque é que eles divergiram em termos de arquitetura e como os recentes avanços em sistemas como o Milvus tornam a recuperação conversacional a pedido prática em escala.

O sistema de memória do ChatGPT

Em vez de consultar uma base de dados de vectores ou recuperar dinamicamente conversas passadas no momento da inferência, o ChatGPT constrói a sua "memória" reunindo um conjunto fixo de componentes de contexto e injectando-os diretamente em cada prompt. Cada componente é preparado com antecedência e ocupa uma posição conhecida no prompt.

Este design mantém a personalização e a continuidade da conversação intactas, ao mesmo tempo que torna a latência, a utilização de tokens e o comportamento do sistema mais previsíveis. Por outras palavras, a memória não é algo que o modelo procura em tempo real - é algo que o sistema empacota e entrega ao modelo sempre que gera uma resposta.

Em um nível alto, um prompt ChatGPT completo consiste nas seguintes camadas, ordenadas da mais global para a mais imediata:

[0] Instruções do sistema

[1] Instruções do programador

[2] Metadados da sessão (efémeros)

[3] Memória do utilizador (factos a longo prazo)

[4] Resumo das conversas recentes (conversas anteriores, títulos + fragmentos)

[5] Mensagens da sessão atual (este chat)

[6] A sua última mensagem

Entre estes, os componentes [2] a [5] formam a memória efectiva do sistema, cada um com uma função distinta.

Metadados da sessão

Os metadados da sessão representam informação de curta duração, não persistente, que é injectada uma vez no início de uma conversa e descartada quando a sessão termina. A sua função é ajudar o modelo a adaptar-se ao contexto de utilização atual e não personalizar o comportamento a longo prazo.

Esta camada capta sinais sobre o ambiente imediato do utilizador e os padrões de utilização recentes. Os sinais típicos incluem:

• Informações sobre o dispositivo - por exemplo, se o utilizador está no telemóvel ou no computador

• Atributos da conta - como o nível de subscrição (por exemplo, ChatGPT Go), a idade da conta e a frequência geral de utilização

• Métricas comportamentais - incluindo dias activos nos últimos 1, 7 e 30 dias, duração média da conversa e distribuição da utilização do modelo (por exemplo, 49% dos pedidos tratados pelo GPT-5)

Memória do utilizador

A memória do utilizador é a camada de memória persistente e editável que permite a personalização entre conversas. Armazena informações relativamente estáveis - como o nome do utilizador, função ou objectivos de carreira, projectos em curso, resultados anteriores e preferências de aprendizagem - e é injectada em cada nova conversa para preservar a continuidade ao longo do tempo.

Esta memória pode ser actualizada de duas formas:

• As actualizações explícitas ocorrem quando os utilizadores gerem diretamente a memória com instruções como "lembrar isto" ou "remover isto da memória".

• As actualizações implícitas ocorrem quando o sistema identifica informações que satisfazem os critérios de armazenamento da OpenAI - como um nome confirmado ou um cargo - e guarda-as automaticamente, sujeitas ao consentimento predefinido do utilizador e às definições de memória.

Resumo de conversas recentes

O resumo da conversa recente é uma camada de contexto leve e entre sessões que preserva a continuidade sem reproduzir ou recuperar históricos de conversação completos. Em vez de depender da recuperação dinâmica, como nas abordagens tradicionais baseadas em RAG, este resumo é pré-computado e injetado diretamente em cada nova conversa.

Esta camada resume apenas as mensagens do utilizador, excluindo as respostas do assistente. É intencionalmente limitada em tamanho - normalmente cerca de 15 entradas - e retém apenas sinais de alto nível sobre interesses recentes, em vez de conteúdo detalhado. Como não depende de embeddings ou pesquisa de similaridade, mantém a latência e o consumo de tokens baixos.

Mensagens da sessão atual

As mensagens da sessão atual contêm todo o histórico de mensagens da conversa em curso e fornecem o contexto de curto prazo necessário para respostas coerentes e passo a passo. Esta camada inclui os inputs do utilizador e as respostas do assistente, mas apenas enquanto a sessão estiver ativa.

Como o modelo funciona dentro de um limite fixo de tokens, este histórico não pode crescer indefinidamente. Quando o limite é atingido, o sistema elimina as mensagens mais antigas para dar lugar às mais recentes. Este truncamento afecta apenas a sessão atual: a memória de longo prazo do utilizador e o resumo da conversa recente permanecem intactos.

O sistema de memória do Claude

O Claude adota uma abordagem diferente para o gerenciamento de memória. Em vez de injetar um pacote grande e fixo de componentes de memória em cada prompt - como faz o ChatGPT - o Claude combina a memória persistente do usuário com ferramentas sob demanda e recuperação seletiva. O contexto histórico é obtido apenas quando o modelo o considera relevante, permitindo que o sistema negoceie entre a profundidade do contexto e o custo computacional.

O contexto do prompt do Claude é estruturado da seguinte forma:

[0] Prompt do sistema (instruções estáticas)

[1] Memórias do utilizador

[2] Histórico da conversa

[3] Mensagem atual

As principais diferenças entre o Claude e o ChatGPT residem na forma como o histórico de conversação é recuperado e como a memória do utilizador é actualizada e mantida.

Memórias do utilizador

No Claude, as memórias do utilizador formam uma camada de contexto a longo prazo com um objetivo semelhante ao da memória do utilizador do ChatGPT, mas com uma maior ênfase nas actualizações automáticas e em segundo plano. Estas memórias são armazenadas num formato estruturado (embrulhadas em etiquetas de estilo XML) e são concebidas para evoluir gradualmente ao longo do tempo com uma intervenção mínima do utilizador.

O Claude suporta duas vias de atualização:

• Actualizações implícitas - O sistema analisa periodicamente o conteúdo da conversa e actualiza a memória em segundo plano. Estas actualizações não são aplicadas em tempo real e as memórias associadas a conversas eliminadas são gradualmente eliminadas como parte da otimização contínua.

• Actualizações explícitas - Os utilizadores podem gerir diretamente a memória através de comandos como "lembrar isto" ou "apagar isto", que são executados através de uma ferramenta dedicada memory_user_edits.

Em comparação com o ChatGPT, o Claude coloca uma maior responsabilidade no próprio sistema para refinar, atualizar e podar a memória de longo prazo. Isto reduz a necessidade de os utilizadores seleccionarem ativamente o que é armazenado.

Histórico de conversas

Para o histórico da conversa, o Claude não se baseia num resumo fixo que é injetado em cada mensagem. Em vez disso, ele recupera o contexto passado apenas quando o modelo decide que é necessário, usando três mecanismos distintos. Isto evita o transporte de histórico irrelevante e mantém a utilização de tokens sob controlo.

Componente	Objetivo	Como é utilizado
Janela de rolamento (conversa atual)	Armazena o histórico completo de mensagens da conversa atual (não um resumo), semelhante ao contexto de sessão do ChatGPT	Injetado automaticamente. O limite de tokens é de ~190K; mensagens mais antigas são descartadas quando o limite é atingido
conversation_search ferramenta	Pesquisa conversas anteriores por tópico ou palavra-chave, devolvendo links de conversas, títulos e excertos de mensagens do utilizador/assistente	Acionada quando o modelo determina que são necessários detalhes históricos. Os parâmetros incluem query (termos de pesquisa) e max_results (1-10)
recent_chats ferramenta	Recupera conversas recentes dentro de um intervalo de tempo especificado (por exemplo, "últimos 3 dias"), com resultados formatados da mesma forma que conversation_search	Acionado quando o contexto recente e limitado no tempo é relevante. Os parâmetros incluem n (número de resultados), sort_order, e intervalo de tempo

Entre estes componentes, conversation_search é especialmente notável. Pode apresentar resultados relevantes mesmo para consultas com frases vagas ou multilingues, indicando que funciona a um nível semântico em vez de se basear numa simples correspondência de palavras-chave. Isto envolve provavelmente uma recuperação baseada na incorporação ou uma abordagem híbrida que primeiro traduz ou normaliza a consulta para uma forma canónica e depois aplica a recuperação por palavra-chave ou híbrida.

Em geral, a abordagem de recuperação a pedido do Claude tem vários pontos fortes notáveis:

• A recuperação não é automática: As chamadas de ferramentas são acionadas pelo próprio julgamento do modelo. Por exemplo, quando um utilizador refere "o projeto que discutimos da última vez", o Claude pode decidir invocar conversation_search para obter o contexto relevante.

• Contexto mais rico quando necessário: Os resultados obtidos podem incluir excertos de respostas do assistente, enquanto os resumos do ChatGPT apenas captam as mensagens do utilizador. Isto torna o Claude mais adequado para casos de utilização que requerem um contexto de conversação mais profundo ou mais preciso.

• Melhor eficiência por padrão: Como o contexto histórico não é injetado a menos que seja necessário, o sistema evita transportar grandes quantidades de histórico irrelevante, reduzindo o consumo desnecessário de tokens.

As vantagens e desvantagens são igualmente claras. A introdução da recuperação a pedido aumenta a complexidade do sistema: os índices têm de ser construídos e mantidos, as consultas executadas, os resultados classificados e, por vezes, novamente classificados. A latência de ponta a ponta também se torna menos previsível do que com o contexto pré-computado e sempre injetado. Além disso, o modelo tem de aprender a decidir quando é que a recuperação é necessária. Se esse julgamento falhar, o contexto relevante pode nunca ser recuperado.

As restrições por detrás da recuperação a pedido ao estilo de Claude

A adoção de um modelo de recuperação a pedido torna a base de dados vetorial uma parte crítica da arquitetura. A recuperação de conversações coloca exigências invulgarmente elevadas tanto no armazenamento como na execução de consultas, e o sistema tem de cumprir quatro restrições ao mesmo tempo.

1. Tolerância à baixa latência

Nos sistemas de conversação, a latência do P99 tem de ser inferior a cerca de 20 ms. Os atrasos superiores a este valor são imediatamente perceptíveis para os utilizadores. Isto deixa pouco espaço para a ineficiência: a pesquisa vetorial, a filtragem de metadados e a classificação de resultados devem ser cuidadosamente optimizadas. Um estrangulamento em qualquer ponto pode degradar toda a experiência de conversação.

2. Requisito de pesquisa híbrida

As consultas dos utilizadores abrangem frequentemente várias dimensões. Um pedido como "discussões sobre RAG da semana passada" combina relevância semântica com filtragem baseada no tempo. Se uma base de dados apenas suportar a pesquisa vetorial, pode devolver 1.000 resultados semanticamente semelhantes, apenas para que a filtragem da camada de aplicação os reduza a um punhado - desperdiçando a maior parte da computação. Para ser prática, a base de dados deve suportar nativamente consultas vectoriais e escalares combinadas.

3. Separação entre armazenamento e computação

O histórico das conversas apresenta um padrão claro de acesso quente-frio. As conversas recentes são consultadas com frequência, enquanto as mais antigas raramente são tocadas. Se todos os vectores tivessem de ficar na memória, o armazenamento de dezenas de milhões de conversas consumiria centenas de gigabytes de RAM - um custo impraticável à escala. Para ser viável, o sistema deve suportar a separação entre armazenamento e computação, mantendo os dados quentes na memória e os dados frios no armazenamento de objectos, com vectores carregados a pedido.

4. Diversos padrões de consulta

A recuperação de conversas não segue um único padrão de acesso. Algumas consultas são puramente semânticas (por exemplo, "a otimização de desempenho que discutimos"), outras são puramente temporais ("todas as conversas da semana passada"), e muitas combinam várias restrições ("discussões relacionadas com Python que mencionam FastAPI nos últimos três meses"). O planeador de consultas de bases de dados deve adaptar as estratégias de execução a diferentes tipos de consultas, em vez de se basear numa pesquisa de tamanho único e de força bruta.

Juntos, estes quatro desafios definem as principais restrições da recuperação conversacional. Qualquer sistema que pretenda implementar a recuperação a pedido, ao estilo de Claude, deve abordar todos eles de forma coordenada.

Por que o Milvus 2.6 funciona bem para a recuperação conversacional

As escolhas de design do Milvus 2.6 estão alinhadas com os principais requisitos da recuperação conversacional a pedido. Abaixo está um resumo das principais capacidades e como elas se relacionam com as necessidades reais de recuperação de conversação.

Recuperação híbrida com vetores densos e esparsos

O Milvus 2.6 suporta nativamente o armazenamento de vectores densos e esparsos na mesma coleção e a fusão automática dos seus resultados no momento da consulta. Os vectores densos (por exemplo, os embeddings de 768 dimensões gerados por modelos como o BGE-M3) captam a semelhança semântica, enquanto os vectores esparsos (normalmente produzidos pelo BM25) preservam os sinais exactos das palavras-chave.

Para uma consulta como "discussões sobre o RAG da semana passada", o Milvus executa a recuperação semântica e a recuperação de palavras-chave em paralelo e, em seguida, funde os resultados através de uma nova classificação. Em comparação com a utilização de uma das abordagens isoladamente, esta estratégia híbrida proporciona uma recuperação significativamente mais elevada em cenários de conversação reais.

Separação entre armazenamento e computação e otimização de consultas

O Milvus 2.6 suporta armazenamento em camadas de duas maneiras:

• Dados quentes na memória, dados frios no armazenamento de objectos

• Índices na memória, dados vectoriais em bruto no armazenamento de objectos

Com este design, o armazenamento de um milhão de entradas de conversação pode ser conseguido com cerca de 2 GB de memória e 8 GB de armazenamento de objectos. Com o ajuste adequado, a latência do P99 pode permanecer abaixo de 20 ms, mesmo com a separação entre armazenamento e computação ativada.

Destruição de JSON e filtragem escalar rápida

O Milvus 2.6 habilita o JSON Shredding por padrão, achatando campos JSON aninhados em armazenamento colunar. Isso melhora o desempenho da filtragem escalar em 3-5× de acordo com os benchmarks oficiais (os ganhos reais variam de acordo com o padrão de consulta).

A recuperação de conversação requer frequentemente a filtragem por metadados, tais como ID de utilizador, ID de sessão ou intervalo de tempo. Com o JSON Shredding, consultas como "todas as conversas do usuário A na última semana" podem ser executadas diretamente em índices colunares, sem analisar repetidamente blobs JSON completos.

Controlo de código aberto e flexibilidade operacional

Sendo um sistema de código aberto, o Milvus oferece um nível de controlo arquitetónico e operacional que as soluções fechadas e de caixa negra não oferecem. As equipas podem ajustar os parâmetros do índice, aplicar estratégias de classificação de dados e personalizar implementações distribuídas para corresponder às suas cargas de trabalho.

Esta flexibilidade reduz a barreira à entrada: as equipas de pequena e média dimensão podem criar sistemas de recuperação de conversação à escala de milhões a dezenas de milhões sem dependerem de orçamentos de infraestrutura excessivos.

Porque é que o ChatGPT e a Claude seguiram caminhos diferentes

A diferença entre os sistemas de memória do ChatGPT e do Claude está na forma como cada um lida com o esquecimento. O ChatGPT favorece o esquecimento proativo: uma vez que a memória excede limites fixos, o contexto mais antigo é descartado. Isso troca completude por simplicidade e comportamento previsível do sistema. O Claude favorece o esquecimento retardado. Em teoria, o histórico da conversa pode crescer sem limites, com a recuperação delegada a um sistema de recuperação a pedido.

Então, porque é que os dois sistemas escolheram caminhos diferentes? Com os constrangimentos técnicos acima descritos, a resposta torna-se clara: cada arquitetura só é viável se a infraestrutura subjacente a suportar.

Se a abordagem de Claude tivesse sido tentada em 2020, teria sido provavelmente impraticável. Nessa altura, as bases de dados vectoriais incorriam frequentemente em centenas de milissegundos de latência, as consultas híbridas eram mal suportadas e a utilização de recursos aumentava de forma proibitiva à medida que os dados cresciam. Nessas condições, a recuperação a pedido teria sido considerada um excesso de engenharia.

Em 2025, o cenário mudou. Os avanços na infraestrutura - impulsionados por sistemas como o Milvus 2.6 -tornaram a separação entre armazenamento e computação, a otimização de consultas, a recuperação híbrida densa e esparsa e a fragmentação de JSON viáveis na produção. Estes avanços reduzem a latência, controlam os custos e tornam a recuperação selectiva prática em escala. Como resultado, as ferramentas a pedido e a memória baseada na recuperação tornaram-se não só viáveis, mas também cada vez mais atractivas, especialmente como base para sistemas do tipo agente.

Em última análise, as escolhas de arquitetura seguem o que a infraestrutura torna possível.

Conclusão

Nos sistemas do mundo real, a conceção da memória não é uma escolha binária entre contexto pré-computado e recuperação a pedido. As arquitecturas mais eficazes são normalmente híbridas, combinando ambas as abordagens.

Um padrão comum consiste em injetar as voltas recentes da conversa através de uma janela de contexto deslizante, armazenar as preferências estáveis do utilizador como memória fixa e recuperar o histórico mais antigo a pedido através de pesquisa vetorial. À medida que um produto amadurece, este equilíbrio pode mudar gradualmente - de um contexto primariamente pré-computado para um contexto cada vez mais orientado para a recuperação - sem ser necessário um reinício arquitetónico perturbador.

Mesmo quando se começa com uma abordagem pré-computada, é importante projetar tendo em mente a migração. A memória deve ser armazenada com identificadores claros, registos de data e hora, categorias e referências de origem. Quando a recuperação se torna viável, os embeddings podem ser gerados para a memória existente e adicionados a uma base de dados de vectores juntamente com os mesmos metadados, permitindo que a lógica de recuperação seja introduzida de forma incremental e com o mínimo de perturbações.

Tem dúvidas ou pretende aprofundar qualquer funcionalidade do Milvus mais recente? Junte-se ao nosso canal Discord ou registe problemas no GitHub. Também pode reservar uma sessão individual de 20 minutos para obter informações, orientações e respostas às suas perguntas através do Milvus Office Hours.