¿Se está quedando anticuada la RAG ahora que surgen agentes de largo recorrido como Claude Cowork?

Claude Cowork es un nuevo agente de la aplicación Claude Desktop. Desde el punto de vista de un desarrollador, es básicamente un ejecutor de tareas automatizado envuelto alrededor del modelo: puede leer, modificar y generar archivos locales, y puede planificar tareas de múltiples pasos sin que tengas que preguntar manualmente por cada paso. Piense en ello como el mismo bucle detrás de Claude Code, pero expuesto al escritorio en lugar de a la terminal.

La capacidad clave de Cowork es su capacidad para funcionar durante períodos prolongados sin perder el estado. No sufre los habituales tiempos de espera de conversación o reinicio de contexto. Puede seguir trabajando, rastrear resultados intermedios y reutilizar información previa en distintas sesiones. Esto da la impresión de ser una "memoria a largo plazo", aunque la mecánica subyacente se parezca más a un estado de tarea persistente + transferencia contextual. En cualquier caso, la experiencia es diferente del modelo de chat tradicional, en el que todo se reinicia a menos que construyas tu propia capa de memoria.

Esto plantea dos cuestiones prácticas para los desarrolladores:

1. Si el modelo ya puede recordar información pasada, ¿dónde encaja la RAG o la RAG agéntica? ¿Se sustituirá la GAR?

2. Si queremos un agente local, al estilo Cowork, ¿cómo implementamos nosotros mismos la memoria a largo plazo?

El resto de este artículo aborda estas cuestiones en detalle y explica cómo encajan las bases de datos vectoriales en este nuevo panorama de "memoria modelo".

Claude Cowork vs. RAG: ¿Cuál es la diferencia?

Como he mencionado anteriormente, Claude Cowork es un modo agente dentro de Claude Desktop que puede leer y escribir archivos locales, dividir tareas en pasos más pequeños y seguir trabajando sin perder el estado. Mantiene su propio contexto de trabajo, por lo que las tareas de varias horas no se reinician como una sesión de chat normal.

RAG (Retrieval-Augmented Generation) resuelve un problema diferente: dar a un modelo acceso a conocimientos externos. Se indexan los datos en una base vectorial, se recuperan los fragmentos relevantes para cada consulta y se introducen en el modelo. Se utiliza mucho porque proporciona a las aplicaciones LLM una forma de "memoria a largo plazo" para documentos, registros, datos de productos y mucho más.

Si ambos sistemas ayudan a un modelo a "recordar", ¿cuál es la diferencia real?

Cómo gestiona Cowork la memoria

La memoria de Cowork es de lectura-escritura. El agente decide qué información de la tarea o conversación actual es relevante, la almacena como entradas de memoria y la recupera más tarde a medida que avanza la tarea. Esto permite a Cowork mantener la continuidad a través de flujos de trabajo de larga duración - especialmente aquellos que producen nuevos estados intermedios a medida que avanzan.

Cómo gestionan la memoria RAG y Agentic RAG

La RAG estándar es una recuperación basada en consultas: el usuario pregunta algo, el sistema obtiene los documentos relevantes y el modelo los utiliza para responder. El corpus de recuperación permanece estable y versionado, y los desarrolladores controlan exactamente lo que entra en él.

La RAG moderna amplía este modelo. El modelo puede decidir cuándo recuperar información, qué recuperar y cómo utilizarla durante la planificación o ejecución de un flujo de trabajo. Estos sistemas pueden ejecutar tareas largas y llamar a herramientas, de forma similar a Cowork. Pero incluso con el GAR agéntico, la capa de recuperación sigue estando más orientada al conocimiento que al estado. El agente recupera hechos fidedignos, no escribe en el corpus el estado evolutivo de su tarea.

Otra forma de verlo:

• La memoria de Cowork está orientada a tareas: el agente escribe y lee su propio estado evolutivo.

• La RAG se basa en el conocimiento: el sistema recupera información establecida en la que debe basarse el modelo.

Claude Cowork: ingeniería inversa: Cómo construye una memoria de agente de larga duración

A Cowork se le da mucho bombo porque maneja tareas de varios pasos sin olvidar constantemente lo que estaba haciendo. Desde la perspectiva de un desarrollador, me pregunto cómo mantiene el estado a través de sesiones tan largas. Anthropic no ha publicado la información interna, pero basándonos en experimentos anteriores con el módulo de memoria de Claude, podemos elaborar un modelo mental decente.

Claude parece confiar en una configuración híbrida: una capa de memoria persistente a largo plazo más herramientas de recuperación bajo demanda. En lugar de incluir toda la conversación en cada petición, Claude recupera selectivamente el contexto pasado sólo cuando decide que es relevante. De este modo, el modelo mantiene un alto nivel de precisión sin gastar fichas en cada turno.

Si desglosas la estructura de la petición, es más o menos así:

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

El comportamiento interesante no es la estructura en sí, sino cómo el modelo decide qué actualizar y cuándo ejecutar la recuperación.

Memoria de usuario: La capa persistente

Claude mantiene un almacén de memoria a largo plazo que se actualiza con el tiempo. Y a diferencia del sistema de memoria más predecible de ChatGPT, el de Claude se siente un poco más "vivo". Almacena las memorias en bloques tipo XML y las actualiza de dos maneras:

• Actualizaciones implícitas: A veces el modelo simplemente decide que algo es una preferencia o un hecho estable y lo escribe tranquilamente en la memoria. Estas actualizaciones no son instantáneas; aparecen al cabo de unos turnos, y los recuerdos más antiguos pueden desvanecerse si desaparece la conversación relacionada.

• Actualizaciones explícitas: Los usuarios pueden modificar directamente la memoria con la herramienta memory_user_edits ("recuerda X", "olvida Y"). Estas escrituras son inmediatas y se comportan más como una operación CRUD.

Claude ejecuta una heurística en segundo plano para decidir qué vale la pena persistir, y no espera instrucciones explícitas.

Recuperación de conversaciones: La parte bajo demanda

Claude no mantiene un resumen continuo como muchos sistemas LLM. En su lugar, dispone de una caja de herramientas de funciones de recuperación a las que puede recurrir cuando cree que le falta contexto. Estas llamadas no se producen en cada turno, sino que el modelo las activa en función de su propio criterio interno.

La más destacada es conversation_search. Cuando el usuario dice algo tan vago como "ese proyecto del mes pasado", Claude suele activar esta herramienta para buscar los turnos pertinentes. Lo notable es que sigue funcionando cuando la frase es ambigua o está en otro idioma. Eso implica claramente

• Algún tipo de concordancia semántica (embeddings)

• Probablemente combinado con normalización o traducción ligera.

• Búsqueda de palabras clave para mayor precisión.

Básicamente, esto se parece mucho a un sistema RAG en miniatura integrado en el conjunto de herramientas del modelo.

Diferencias entre el comportamiento de recuperación de Claude y los búferes de historial básicos

A partir de las pruebas y los registros, destacan algunos patrones:

• La recuperación no es automática. El modelo elige cuándo llamarla. Si cree que ya tiene suficiente contexto, ni siquiera se molesta.

• Los fragmentos recuperados incluyen mensajes tanto del usuario como del asistente. Esto es útil, ya que conserva más matices que los resúmenes sólo del usuario.

• El uso de tokens es razonable. Como el historial no se inyecta en cada turno, las sesiones largas no se disparan de forma impredecible.

En general, se siente como un LLM de recuperación aumentada, excepto que la recuperación se produce como parte del propio bucle de razonamiento del modelo.

Esta arquitectura es inteligente, pero no gratuita:

• La recuperación añade latencia y más "partes móviles" (indexación, clasificación, reclasificación).

• En ocasiones, el modelo se equivoca al juzgar si necesita contexto, lo que se traduce en el clásico "olvido LLM", aunque los datos estuvieran disponibles.

• La depuración se vuelve más complicada porque el comportamiento del modelo depende de disparadores invisibles de la herramienta, no sólo de la entrada de datos.

Claude Cowork frente a Claude Codex en el manejo de la memoria a largo plazo

En contraste con la configuración de recuperación de Claude, ChatGPT maneja la memoria de una manera mucho más estructurada y predecible. En lugar de realizar búsquedas semánticas o tratar las conversaciones antiguas como un mini almacén vectorial, ChatGPT inyecta memoria directamente en cada sesión a través de los siguientes componentes estratificados:

• Memoria de usuario

• Metadatos de sesión

• Mensajes de la sesión actual

Memoria de usuario

La Memoria de Usuario es la principal capa de almacenamiento a largo plazo, la parte que persiste a través de las sesiones y que puede ser editada por el usuario. Almacena cosas bastante estándar: nombre, antecedentes, proyectos en curso, preferencias de aprendizaje, ese tipo de cosas. A cada nueva conversación se le inyecta este bloque al principio, de modo que el modelo siempre comienza con una visión coherente del usuario.

ChatGPT actualiza esta capa de dos maneras:

• Actualizaciones explícitas: Los usuarios pueden decirle al modelo "recuerda esto" u "olvida aquello", y la memoria cambia inmediatamente. Se trata básicamente de una API CRUD que el modelo expone a través del lenguaje natural.

• Actualizaciones implícitas: Si el modelo detecta información que se ajusta a las reglas de OpenAI para la memoria a largo plazo -como un puesto de trabajo o una preferencia- y el usuario no ha desactivado la memoria, la añadirá discretamente por su cuenta.

Desde el punto de vista del desarrollador, esta capa es sencilla, determinista y fácil de razonar. Sin búsquedas incrustadas, sin heurística sobre qué obtener.

Metadatos de sesión

Los metadatos de sesión se sitúan en el extremo opuesto del espectro. Son efímeros, no persistentes y sólo se inyectan una vez al inicio de la sesión. Piense en ellos como variables de entorno para la conversación. Esto incluye cosas como

• en qué dispositivo estás

• estado de la cuenta/suscripción

• patrones de uso aproximados (días activos, distribución del modelo, duración media de la conversación)

Estos metadatos ayudan al modelo a dar forma a las respuestas para el entorno actual -por ejemplo, escribir respuestas más cortas en el móvil- sin contaminar la memoria a largo plazo.

Mensajes de la sesión actual

Se trata del historial estándar de ventana deslizante: todos los mensajes de la conversación actual hasta que se alcanza el límite de tokens. Cuando la ventana se hace demasiado grande, los turnos más antiguos se desalojan automáticamente.

Crucialmente, este desalojo no toca la Memoria de Usuario ni los resúmenes entre sesiones. Sólo se reduce el historial local de la conversación.

La mayor divergencia con Claude aparece en cómo ChatGPT maneja las conversaciones "recientes pero no actuales". Claude llamará a una herramienta de búsqueda para recuperar el contexto pasado si cree que es relevante. ChatGPT no hace eso.

En su lugar, ChatGPT mantiene un resumen muy ligero entre sesiones que se inyecta en cada conversación. Algunos detalles clave sobre esta capa:

• Resume sólo los mensajes del usuario, no los del asistente.

• Almacena un conjunto muy reducido de elementos (unos 15), lo suficiente para captar temas o intereses estables.

• No realiza cálculos de incrustación, clasificaciones de similitud ni llamadas de recuperación. Básicamente, se trata de contexto pre-masticado, no de búsqueda dinámica.

Desde el punto de vista de la ingeniería, este enfoque cambia flexibilidad por previsibilidad. No hay posibilidad de que se produzca un fallo extraño en la recuperación, y la latencia de la inferencia se mantiene estable porque no se obtiene nada sobre la marcha. El inconveniente es que ChatGPT no recuperará un mensaje aleatorio de hace seis meses a menos que haya llegado a la capa de resumen.

Desafíos para hacer que la memoria del agente sea escribible

Cuando un agente pasa de la memoria de sólo lectura (típica RAG) a la memoria con capacidad de escritura -dondepuede registrar las acciones, decisiones y preferencias del usuario- la complejidad aumenta rápidamente. Ya no se trata sólo de recuperar documentos, sino de mantener un estado creciente del que depende el modelo.

Un sistema de memoria escribible tiene que resolver tres problemas reales:

1. Qué recordar: El agente necesita reglas para decidir qué eventos, preferencias u observaciones merece la pena conservar. Sin esto, la memoria explota en tamaño o se llena de ruido.

2. Cómo almacenar y clasificar la memoria: No toda la memoria es igual. Los elementos recientes, los hechos a largo plazo y las notas efímeras necesitan diferentes niveles de almacenamiento, políticas de retención y estrategias de indexación.

3. Cómo escribir rápido sin interrumpir la recuperación: La memoria debe escribirse continuamente, pero las actualizaciones frecuentes pueden degradar la calidad del índice o ralentizar las consultas si el sistema no está diseñado para inserciones de alto rendimiento.

Reto 1: ¿Qué merece la pena recordar?

No todo lo que hace un usuario debe acabar en la memoria a largo plazo. Si alguien crea un archivo temporal y lo borra cinco minutos después, grabarlo para siempre no ayuda a nadie. Ésta es la principal dificultad: ¿cómo decide el sistema lo que realmente importa?

(1) Formas habituales de juzgar la importancia

Los equipos suelen basarse en una mezcla de heurísticas:

• Basada en el tiempo: las acciones recientes importan más que las antiguas.

• Basada en la frecuencia: los archivos o acciones a los que se accede repetidamente son más importantes.

• Basada en el tipo: algunos objetos son intrínsecamente más importantes (por ejemplo, los archivos de configuración del proyecto frente a los archivos de caché).

(2) Cuando las reglas entran en conflicto

Estas señales suelen entrar en conflicto. Un archivo creado la semana pasada pero muy editado hoy: ¿debe prevalecer la antigüedad o la actividad? No existe una única respuesta "correcta", por lo que la puntuación de importancia tiende a complicarse rápidamente.

(3) Cómo ayudan las bases de datos vectoriales

Las bases de datos vectoriales le ofrecen mecanismos para aplicar reglas de importancia sin necesidad de limpieza manual:

• TTL: Milvus puede eliminar datos automáticamente después de un tiempo determinado.

• Decadencia: los vectores más antiguos se pueden ponderar a la baja para que desaparezcan de forma natural de la recuperación.

Reto 2: La jerarquización de la memoria en la práctica

A medida que los agentes funcionan durante más tiempo, la memoria se acumula. Mantener todo en almacenamiento rápido no es sostenible, por lo que el sistema necesita una forma de dividir la memoria en niveles calientes (de acceso frecuente) y fríos (de acceso poco frecuente).

(1) Decidir cuándo la memoria se convierte en fría

En este modelo, la memoria caliente se refiere a los datos que se mantienen en la RAM para un acceso de baja latencia, mientras que la memoria fría se refiere a los datos que se mueven al disco o al almacenamiento de objetos para reducir costes.

Decidir cuándo se enfría la memoria puede hacerse de distintas maneras. Algunos sistemas utilizan modelos ligeros para estimar la importancia semántica de una acción o archivo basándose en su significado y uso reciente. Otros se basan en una lógica simple basada en reglas, como mover la memoria a la que no se ha accedido en 30 días o que no ha aparecido en los resultados de recuperación en una semana. Los usuarios también pueden marcar explícitamente determinados archivos o acciones como importantes, asegurándose de que siempre permanezcan calientes.

(2) Dónde se almacenan las memorias calientes y frías

Una vez clasificadas, las memorias calientes y frías se almacenan de forma diferente. La memoria caliente permanece en la RAM y se utiliza para contenidos de acceso frecuente, como el contexto de tareas activas o acciones recientes del usuario. La memoria fría se traslada al disco o a sistemas de almacenamiento de objetos como S3, donde el acceso es más lento pero los costes de almacenamiento son mucho menores. Esta compensación funciona bien porque la memoria fría rara vez se necesita y normalmente sólo se accede a ella como referencia a largo plazo.

(3) Cómo ayudan las bases de datos vectoriales

Milvus y Zilliz Cloud admiten este patrón al permitir el almacenamiento por niveles frío-caliente manteniendo una única interfaz de consulta, de modo que los vectores a los que se accede con frecuencia permanecen en la memoria y los datos más antiguos se mueven automáticamente a un almacenamiento de menor coste.

Reto 3: ¿A qué velocidad debe escribirse la memoria?

Los sistemas RAG tradicionales suelen escribir datos por lotes. Los índices se reconstruyen fuera de línea -a menudo de un día para otro- y no se pueden consultar hasta más tarde. Este enfoque funciona para las bases de conocimiento estáticas, pero no se adapta a la memoria del agente.

(1) Por qué la memoria del agente necesita escrituras en tiempo real

La memoria del agente debe capturar las acciones del usuario en el momento en que se producen. Si una acción no se registra inmediatamente, el siguiente turno de conversación puede carecer de contexto crítico. Por esta razón, los sistemas de memoria con capacidad de escritura requieren escrituras en tiempo real en lugar de actualizaciones retrasadas y fuera de línea.

(2) La tensión entre velocidad de escritura y calidad de recuperación

La memoria en tiempo real exige una latencia de escritura muy baja. Al mismo tiempo, la recuperación de alta calidad depende de índices bien construidos, y la construcción de índices lleva tiempo. Reconstruir un índice para cada escritura es demasiado caro, pero retrasar la indexación significa que los datos recién escritos permanecen temporalmente invisibles para la recuperación. Esta disyuntiva es la base del diseño de memorias con capacidad de escritura.

(3) Cómo ayudan las bases de datos vectoriales

Las bases de datos vectoriales resuelven este problema desvinculando la escritura de la indexación. Una solución común es la escritura en flujo y la creación de índices incrementales. Utilizando Milvus como ejemplo, los nuevos datos se escriben primero en un búfer en memoria, lo que permite al sistema gestionar eficazmente las escrituras de alta frecuencia. Incluso antes de crear un índice completo, los datos almacenados en la memoria intermedia pueden consultarse en cuestión de segundos mediante una fusión dinámica o una búsqueda aproximada.

Cuando el búfer alcanza un umbral predefinido, el sistema construye índices por lotes y los persiste. Esto mejora el rendimiento de la recuperación a largo plazo sin bloquear las escrituras en tiempo real. Al separar la ingestión rápida de la construcción de índices más lenta, Milvus logra un equilibrio práctico entre la velocidad de escritura y la calidad de búsqueda que funciona bien para la memoria del agente.

Conclusión

Cowork nos permite vislumbrar una nueva clase de agentes: persistentes, con estado y capaces de llevar el contexto a través de largas líneas temporales. Pero también deja clara otra cosa: la memoria a largo plazo es sólo la mitad del problema. Para crear agentes listos para la producción que sean autónomos y fiables, necesitamos una recuperación estructurada de grandes bases de conocimiento en evolución.

La RAG se ocupa de los hechos del mundo; la memoria con capacidad de escritura, del estado interno del agente. Y las bases de datos vectoriales se sitúan en la intersección, proporcionando indexación, búsqueda híbrida y almacenamiento escalable que permiten a ambas capas trabajar juntas.

A medida que los agentes de larga duración vayan madurando, es probable que sus arquitecturas converjan en este diseño híbrido. Cowork es una clara señal de hacia dónde se dirigen las cosas, no hacia un mundo sin RAG, sino hacia agentes con pilas de memoria más ricas alimentadas por bases de datos vectoriales subyacentes.

Si quieres explorar estas ideas u obtener ayuda con tu propia configuración, únete a nuestro canal de Slack para charlar con los ingenieros de Milvus. Y para una orientación más práctica, siempre puede reservar una sesión de Milvus Office Hours .