Como foi projetar a memória do ChatGPT - e o que ainda falta

Como a memória foi concebida

Benjamin Zweig, um dos primeiros designers da OpenAI, relata que a memória do ChatGPT surgiu tanto de uma convicção sobre sua utilidade quanto de uma demanda observável. Antes do recurso, usuários criavam resumos das conversas e os copiavam para novos chats para preservar alguma continuidade, enquanto as janelas de contexto eram mais limitadas. A primeira versão adotou um modelo simples: um bloco de notas persistente que o modelo podia ler, escrever e editar entre conversas.

O desafio central não era apenas criar uma tela de configurações, mas definir quando algo valia a pena ser salvo e quando uma lembrança deveria ser recuperada. A equipe reuniu exemplos considerados bons e ruins, testou versões internas do modelo e transformou julgamentos humanos em instruções e critérios para avaliadores. Esse processo exigiu tratar decisões intuitivas - como a importância, a frequência e a recência de uma informação - como padrões que pudessem orientar o comportamento do modelo. Zweig considera possível usar metadados como a data de criação e a última referência de uma memória, mas alerta contra estruturas excessivamente inspiradas em metáforas da mente humana, como um “palácio da memória”, que talvez não ofereçam vantagem em escala.

Esquecimento, controle e interface

Para Zweig, a principal lacuna das implementações atuais é o esquecimento produtivo e eficaz. Como os sistemas tendem mais a aplicar memórias em excesso do que a deixar de aplicá-las, sua preferência é por uma memória “honesta e agressivamente esquecida”, mantendo informações arquivadas sem apresentá-las quando forem irrelevantes. Exemplos de personalização indevida, como associar incorretamente um usuário a uma profissão ou usar preferências fora de contexto, mostram por que esse equilíbrio ainda não foi resolvido.

O designer imaginava uma experiência sem painel especial: o usuário perguntaria ao próprio ChatGPT o que ele lembra e diria diretamente o que deveria guardar. Como o sistema ainda não era confiável o bastante, a equipe adicionou um rótulo de “memória atualizada”, que mostrava o conteúdo salvo e permitia apagá-lo ou consultar a conversa de origem. Para Zweig, a interface tradicional funciona como uma fonte de verdade controlável e ajuda o usuário a entender o que o produto realmente fez. À medida que a confiabilidade aumenta, interfaces mais simples podem prevalecer; enquanto houver uma “fronteira irregular” de capacidades, mecanismos de inspeção e correção continuam necessários.

A equipe também discutiu instruções negativas, dependências entre memórias e alterações feitas diretamente pelos usuários. Nem todos esses casos foram resolvidos antes do lançamento, que priorizou os usos mais comuns. Dar controle ao usuário exige, porém, preparar o modelo para lidar com formatos e mudanças inesperados, usando exemplos variados para evitar dependência de uma sintaxe rígida.

Projetar em várias escalas

Após o lançamento, métricas, uso interno, testes simultâneos e avaliações automatizadas ajudaram a comparar versões. Zweig defende lançar um produto funcional mesmo longe da perfeição, porque o uso real revela valor, limites e expectativas mais rapidamente.

Essa experiência também mudou sua visão sobre design de produtos de IA: é preciso trabalhar simultaneamente no modelo, nos mecanismos que decidem quando ele age e na interface que comunica o resultado. Designers devem prototipar cedo, usar o modelo real e aprender diretamente o que ele faz bem ou mal. Como as capacidades podem melhorar em meses, decisões devem considerar o que é possível na próxima semana, em seis meses e em dois anos, evitando tanto o excesso de estruturas provisórias quanto a paralisia. Para Zweig, a tendência é que técnicas específicas de engenharia de prompts percam importância, enquanto comunicação clara, direção e compreensão do problema se tornem habilidades mais duradouras.