O RAG está a tornar-se obsoleto agora que estão a surgir agentes de longa data como o Claude Cowork?

O Claude Cowork é um novo recurso de agente no aplicativo Claude Desktop. Do ponto de vista de um desenvolvedor, ele é basicamente um executor de tarefas automatizado em torno do modelo: ele pode ler, modificar e gerar arquivos locais, e pode planejar tarefas de várias etapas sem que você tenha que solicitar manualmente cada etapa. Pense nisso como o mesmo loop por trás do Claude Code, mas exposto ao desktop em vez de ao terminal.

A principal capacidade do Cowork é a sua capacidade de funcionar durante longos períodos sem perder o estado. Ele não atinge o habitual tempo limite de conversação ou redefinição de contexto. Pode continuar a trabalhar, acompanhar resultados intermédios e reutilizar informações anteriores em várias sessões. Isso dá a impressão de "memória de longo prazo", embora a mecânica subjacente seja mais como estado de tarefa persistente + transferência de contexto. De qualquer forma, a experiência é diferente do modelo de chat tradicional, em que tudo é reiniciado, a menos que se construa uma camada de memória própria.

Isto levanta duas questões práticas para os programadores:

1. Se o modelo já se consegue lembrar de informações passadas, onde é que o RAG ou o RAG agêntico se encaixam? As RAG vão ser substituídas?

2. Se quisermos um agente local, ao estilo Cowork, como é que nós próprios implementamos a memória de longo prazo?

O resto deste artigo aborda estas questões em pormenor e explica como as bases de dados vectoriais se enquadram neste novo cenário de "memória modelo".

Claude Cowork vs. RAG: Qual é a diferença?

Como mencionei anteriormente, o Claude Cowork é um modo de agente dentro do Claude Desktop que pode ler e gravar arquivos locais, dividir tarefas em etapas menores e continuar trabalhando sem perder o estado. Ele mantém seu próprio contexto de trabalho, de modo que tarefas de várias horas não são reiniciadas como uma sessão de bate-papo normal.

O RAG (Retrieval-Augmented Generation) resolve um problema diferente: dar a um modelo acesso a conhecimentos externos. Indexamos os dados numa base de dados vetorial, recuperamos partes relevantes para cada consulta e introduzimo-las no modelo. É amplamente utilizado porque fornece às aplicações LLM uma forma de "memória de longo prazo" para documentos, registos, dados de produtos e muito mais.

Se ambos os sistemas ajudam um modelo a "lembrar", qual é a diferença real?

Como o Cowork lida com a memória

A memória do Cowork é de leitura e gravação. O agente decide que informação da tarefa ou conversa atual é relevante, armazena-a como entradas de memória e recupera-a mais tarde à medida que a tarefa avança. Isso permite que o Cowork mantenha a continuidade em fluxos de trabalho de longa duração - especialmente aqueles que produzem um novo estado intermediário à medida que progridem.

Como o RAG e o RAG Agêntico lidam com a memória

O RAG padrão é uma recuperação orientada para a consulta: o utilizador pergunta algo, o sistema vai buscar documentos relevantes e o modelo utiliza-os para responder. O corpus de recuperação permanece estável e com versões, e os programadores controlam exatamente o que entra nele.

O RAG agêntico moderno alarga este padrão. O modelo pode decidir quando obter informações, o que obter e como utilizá-las durante o planeamento ou a execução de um fluxo de trabalho. Estes sistemas podem executar tarefas longas e chamar ferramentas, à semelhança do Cowork. Mas mesmo com o RAG agêntico, a camada de recuperação continua a ser orientada para o conhecimento e não para o estado. O agente recupera factos autorizados; não escreve o estado da sua tarefa em evolução no corpus.

Outra forma de o ver:

• A memória do Cowork é orientada para a tarefa: o agente escreve e lê o seu próprio estado evolutivo.

• O RAG é orientado para o conhecimento: o sistema recupera informação estabelecida na qual o modelo se deve basear.

Reverse-Engineering Claude Cowork: Como é que constrói uma memória de agente de longa duração

O Cowork é muito falado porque lida com tarefas de vários passos sem se esquecer constantemente do que estava a fazer. Do ponto de vista de um desenvolvedor, eu me pergunto como ele mantém o estado em sessões tão longas? O Anthropic não publicou os detalhes internos, mas com base em experiências anteriores de desenvolvimento com o módulo de memória do Claude, podemos montar um modelo mental decente.

Claude parece confiar em uma configuração híbrida: uma camada de memória de longo prazo persistente e ferramentas de recuperação sob demanda. Em vez de colocar a conversa completa em cada pedido, o Claude puxa seletivamente o contexto passado apenas quando decide que é relevante. Isto permite que o modelo mantenha a precisão elevada sem gastar tokens de cada vez.

Se decompormos a estrutura da solicitação, ela fica mais ou menos assim:

[0] Static system instructions
[1] User memory (long-term)
[2] Retrieved / pruned conversation history
[3] Current user message

O comportamento interessante não é a estrutura em si - é como o modelo decide o que atualizar e quando executar a recuperação.

Memória do utilizador: A camada persistente

O Claude mantém um armazenamento de memória de longo prazo que é atualizado ao longo do tempo. E, ao contrário do sistema de memória mais previsível do ChatGPT, o do Claude parece um pouco mais "vivo". Ele armazena memórias em blocos do tipo XML e as atualiza de duas maneiras:

• Actualizações implícitas: Por vezes, o modelo decide que algo é uma preferência ou um facto estável e escreve-o discretamente na memória. Estas actualizações não são instantâneas; aparecem após alguns turnos, e as memórias mais antigas podem desaparecer se a conversa relacionada desaparecer.

• Actualizações explícitas: Os utilizadores podem modificar diretamente a memória com a ferramenta memory_user_edits ("lembrar X", "esquecer Y"). Estas escritas são imediatas e comportam-se mais como uma operação CRUD.

O Claude está a executar heurísticas de fundo para decidir o que vale a pena persistir, e não está à espera de instruções explícitas.

Recuperação de conversas: A parte sob demanda

O Claude não mantém um resumo contínuo como muitos sistemas LLM. Em vez disso, tem uma caixa de ferramentas de funções de recuperação que pode chamar sempre que achar que está a faltar contexto. Estas chamadas de recuperação não acontecem a cada turno - o modelo acciona-as com base no seu próprio julgamento interno.

O destaque é conversation_search. Quando o utilizador diz algo vago, como "aquele projeto do mês passado", o Claude dispara frequentemente esta ferramenta para procurar turnos relevantes. O que é notável é que continua a funcionar quando a frase é ambígua ou numa língua diferente. Isto implica muito claramente:

• Algum tipo de correspondência semântica (embeddings)

• Provavelmente combinado com normalização ou tradução ligeira

• Pesquisa de palavras-chave para maior precisão

Basicamente, isto parece-se muito com um sistema RAG em miniatura incluído no conjunto de ferramentas do modelo.

Como o comportamento de recuperação do Claude difere dos buffers de histórico básicos

Dos testes e logs, alguns padrões se destacam:

• A recuperação não é automática. O modelo escolhe quando chamá-la. Se achar que já tem contexto suficiente, nem sequer se dá ao trabalho.

• As partes recuperadas incluem mensagens do utilizador e do assistente. Isto é útil - mantém mais nuances do que os resumos apenas do utilizador.

• A utilização de tokens mantém-se normal. Uma vez que o histórico não é injetado a cada passo, as sessões longas não se tornam imprevisíveis.

No geral, parece um LLM aumentado por recuperação, exceto que a recuperação acontece como parte do próprio ciclo de raciocínio do modelo.

Esta arquitetura é inteligente, mas não é gratuita:

• A recuperação acrescenta latência e mais "partes móveis" (indexação, classificação, reclassificação).

• Ocasionalmente, o modelo julga mal se precisa de contexto, o que significa que se assiste ao clássico "esquecimento do LLM", apesar de os dados estarem disponíveis.

• A depuração torna-se mais complicada porque o comportamento do modelo depende de accionamentos invisíveis da ferramenta, e não apenas da entrada de dados.

Claude Cowork vs Claude Codex no tratamento da memória de longo prazo

Em contraste com a configuração de Claude, que é muito pesada em termos de recuperação, o ChatGPT lida com a memória de uma forma muito mais estruturada e previsível. Em vez de fazer pesquisas semânticas ou tratar conversas antigas como um mini vetor de armazenamento, o ChatGPT injeta memória diretamente em cada sessão através dos seguintes componentes em camadas:

• Memória do utilizador

• Metadados da sessão

• Mensagens da sessão atual

Memória do utilizador

A memória do utilizador é a principal camada de armazenamento a longo prazo - a parte que persiste através das sessões e pode ser editada pelo utilizador. Armazena coisas bastante normais: nome, antecedentes, projectos em curso, preferências de aprendizagem, esse tipo de coisas. Cada nova conversa tem este bloco injetado no início, por isso o modelo começa sempre com uma visão consistente do utilizador.

O ChatGPT actualiza esta camada de duas formas:

• Actualizações explícitas: Os utilizadores podem dizer ao modelo para "lembrar isto" ou "esquecer aquilo", e a memória muda imediatamente. Isto é basicamente uma API CRUD que o modelo expõe através de linguagem natural.

• Actualizações implícitas: Se o modelo detetar informações que se enquadrem nas regras da OpenAI para a memória a longo prazo - como um cargo ou uma preferência - e o utilizador não tiver desativado a memória, esta será discretamente adicionada por si própria.

Do ponto de vista do programador, esta camada é simples, determinística e fácil de compreender. Não há pesquisas embutidas, nem heurísticas sobre o que buscar.

Metadados da sessão

Os metadados de sessão situam-se no extremo oposto do espetro. Tem vida curta, não é persistente e só é injetado uma vez no início de uma sessão. Pense neles como variáveis de ambiente para a conversa. Isto inclui coisas como:

• o dispositivo em que se encontra

• estado da conta/assinatura

• padrões de utilização aproximados (dias activos, distribuição do modelo, duração média da conversa)

Estes metadados ajudam o modelo a moldar as respostas para o ambiente atual - por exemplo, escrever respostas mais curtas no telemóvel - sem poluir a memória de longo prazo.

Mensagens da sessão atual

Este é o histórico padrão de janela deslizante: todas as mensagens na conversa atual até que o limite de token seja atingido. Quando a janela se torna demasiado grande, os turnos mais antigos desaparecem automaticamente.

Crucialmente, este despejo não afecta a Memória do Utilizador ou os resumos entre sessões. Apenas o histórico da conversa local diminui.

A maior divergência do Claude aparece em como o ChatGPT lida com conversas "recentes mas não atuais". O Claude chamará uma ferramenta de busca para recuperar o contexto passado se achar que é relevante. O ChatGPT não faz isso.

Em vez disso, o ChatGPT mantém um resumo muito leve entre sessões que é injetado em cada conversa. Alguns detalhes importantes sobre essa camada:

• Ele resume apenas as mensagens do usuário, não as mensagens do assistente.

• Armazena um conjunto muito pequeno de itens - cerca de 15 - apenas o suficiente para capturar temas ou interesses estáveis.

• Não efectua nenhum cálculo de incorporação, nenhuma classificação de semelhança e nenhuma chamada de recuperação. É basicamente um contexto pré-mastigado, não uma pesquisa dinâmica.

Do ponto de vista da engenharia, esta abordagem troca a flexibilidade pela previsibilidade. Não há chance de uma falha estranha na recuperação, e a latência da inferência permanece estável porque nada está sendo buscado na hora. A desvantagem é que o ChatGPT não vai puxar uma mensagem aleatória de seis meses atrás, a menos que ela tenha entrado na camada de resumo.

Desafios para tornar a memória do agente gravável

Quando um agente passa da memória somente leitura (típica RAG) para a memória gravável - ondepode registrar as ações, decisões e preferências do usuário - a complexidade aumenta rapidamente. Já não se trata apenas de recuperar documentos; é necessário manter um estado crescente do qual o modelo depende.

Um sistema de memória gravável tem de resolver três problemas reais:

1. O que lembrar: O agente precisa de regras para decidir quais os eventos, preferências ou observações que vale a pena guardar. Sem isso, a memória ou explode em tamanho ou enche-se de ruído.

2. Como armazenar e distribuir a memória: Nem toda a memória é igual. Itens recentes, factos de longo prazo e notas efémeras precisam de diferentes camadas de armazenamento, políticas de retenção e estratégias de indexação.

3. Como escrever rapidamente sem quebrar a recuperação: A memória deve ser escrita continuamente, mas as actualizações frequentes podem degradar a qualidade do índice ou tornar as consultas lentas se o sistema não for concebido para inserções de elevado débito.

Desafio 1: O que vale a pena lembrar?

Nem tudo o que um utilizador faz deve acabar na memória de longo prazo. Se alguém cria um ficheiro temporário e o apaga cinco minutos mais tarde, gravar isso para sempre não ajuda ninguém. Esta é a dificuldade central: como é que o sistema decide o que é realmente importante?

(1) Formas comuns de avaliar a importância

As equipas normalmente recorrem a uma mistura de heurísticas:

• Baseada no tempo: as acções recentes têm mais importância do que as antigas

• Baseada na frequência: os ficheiros ou acções acedidos repetidamente são mais importantes

• Baseada no tipo: alguns objectos são inerentemente mais importantes (por exemplo, ficheiros de configuração do projeto vs. ficheiros de cache)

(2) Quando as regras entram em conflito

Estes sinais entram frequentemente em conflito. Um ficheiro criado na semana passada mas muito editado hoje - deve ganhar a idade ou a atividade? Não existe uma única resposta "correta", e é por isso que a pontuação de importância tende a tornar-se confusa rapidamente.

(3) Como as bases de dados vectoriais ajudam

As bases de dados vectoriais fornecem-lhe mecanismos para aplicar regras de importância sem limpeza manual:

• TTL: o Milvus pode remover automaticamente os dados após um determinado período de tempo

• Decadência: os vectores mais antigos podem ser reduzidos para que desapareçam naturalmente da recuperação

Desafio 2: Classificação de memória na prática

À medida que os agentes trabalham por mais tempo, a memória acumula-se. Manter tudo em armazenamento rápido não é sustentável, por isso o sistema precisa de uma forma de dividir a memória em camadas quentes (frequentemente acedidas) e frias (raramente acedidas).

(1) Decidindo quando a memória se torna fria

Neste modelo, a memória quente refere-se a dados mantidos na RAM para acesso de baixa latência, enquanto a memória fria refere-se a dados movidos para o disco ou armazenamento de objectos para reduzir o custo.

A decisão de quando a memória se torna fria pode ser tratada de diferentes maneiras. Alguns sistemas utilizam modelos leves para estimar a importância semântica de uma ação ou ficheiro com base no seu significado e utilização recente. Outros baseiam-se numa lógica simples, baseada em regras, como mover a memória que não tenha sido acedida durante 30 dias ou que não tenha aparecido nos resultados da recuperação durante uma semana. Os utilizadores também podem marcar explicitamente determinados ficheiros ou acções como importantes, garantindo que permanecem sempre quentes.

(2) Onde são armazenadas as memórias quentes e frias

Uma vez classificadas, as memórias quentes e frias são armazenadas de forma diferente. A memória quente permanece na RAM e é utilizada para conteúdos frequentemente acedidos, como o contexto de tarefas activas ou acções recentes do utilizador. A memória fria é movida para o disco ou para sistemas de armazenamento de objectos como o S3, onde o acesso é mais lento mas os custos de armazenamento são muito mais baixos. Esta solução de compromisso funciona bem porque a memória fria raramente é necessária e, normalmente, é acedida apenas para referência a longo prazo.

(3) Como as bases de dados vectoriais ajudam

O Milvus e o Zilliz Cloud suportam este padrão ao permitirem o armazenamento em camadas quente-frio, mantendo uma única interface de consulta, de modo a que os vectores acedidos frequentemente permaneçam na memória e os dados mais antigos sejam movidos automaticamente para um armazenamento de menor custo.

Desafio 3: Com que velocidade a memória deve ser gravada?

Os sistemas RAG tradicionais normalmente escrevem dados em lotes. Os índices são reconstruídos offline - muitas vezes durante a noite - e só se tornam pesquisáveis mais tarde. Esta abordagem funciona para bases de conhecimento estáticas, mas não se adequa à memória do agente.

(1) Por que a memória do agente precisa de gravações em tempo real

A memória do agente deve capturar as acções do utilizador à medida que estas acontecem. Se uma ação não for registada imediatamente, o próximo turno de conversação pode carecer de contexto crítico. Por esta razão, os sistemas de memória gravável requerem gravações em tempo real em vez de actualizações atrasadas e offline.

(2) A tensão entre a velocidade de escrita e a qualidade da recuperação

A memória em tempo real exige uma latência de escrita muito baixa. Ao mesmo tempo, a recuperação de alta qualidade depende de índices bem construídos, e a construção de índices leva tempo. Reconstruir um índice para cada gravação é muito caro, mas atrasar a indexação significa que os dados recém-escritos permanecem temporariamente invisíveis para recuperação. Este compromisso está no centro do design da memória gravável.

(3) Como os bancos de dados vetoriais ajudam

Os bancos de dados vetoriais resolvem esse problema desacoplando a gravação da indexação. Uma solução comum é transmitir escritas e executar construções incrementais de índices. Usando o Milvus como exemplo, os novos dados são primeiro gravados em um buffer na memória, permitindo que o sistema lide com gravações de alta frequência de forma eficiente. Mesmo antes de um índice completo ser criado, os dados armazenados em buffer podem ser consultados em segundos por meio de mesclagem dinâmica ou pesquisa aproximada.

Quando o buffer atinge um limite predefinido, o sistema constrói índices em lotes e os persiste. Isto melhora o desempenho da recuperação a longo prazo sem bloquear as escritas em tempo real. Ao separar a ingestão rápida da construção mais lenta de índices, o Milvus alcança um equilíbrio prático entre velocidade de gravação e qualidade de pesquisa que funciona bem para a memória do agente.

Conclusão

O Cowork dá-nos um vislumbre de uma nova classe de agentes - persistentes, com estado e capazes de transportar contexto através de longas linhas de tempo. Mas também deixa claro outra coisa: a memória de longo prazo é apenas metade do quadro. Para construir agentes prontos para a produção que sejam autónomos e fiáveis, continuamos a precisar de uma recuperação estruturada de grandes bases de conhecimento em evolução.

As RAG tratam dos factos do mundo; a memória gravável trata do estado interno do agente. E as bases de dados vectoriais encontram-se na intersecção, fornecendo indexação, pesquisa híbrida e armazenamento escalável que permitem que ambas as camadas trabalhem em conjunto.

À medida que os agentes de longa duração continuam a amadurecer, as suas arquitecturas irão provavelmente convergir para este design híbrido. O Cowork é um forte sinal do rumo que as coisas estão a tomar - não para um mundo sem RAG, mas para agentes com pilhas de memória mais ricas, alimentadas por bases de dados vectoriais subjacentes.

Se quiser explorar estas ideias ou obter ajuda com a sua própria configuração, junte-se ao nosso Canal Slack para conversar com os engenheiros da Milvus. E para uma orientação mais prática, pode sempre reservar uma sessão Milvus Office Hours .