Reflexiones sobre ChatGPT y los sistemas de memoria de Claude: Lo que hace falta para permitir la recuperación conversacional a la carta

En los sistemas de agentes de IA de alta calidad, el diseño de la memoria es mucho más complejo de lo que parece a primera vista. En esencia, debe responder a tres preguntas fundamentales: ¿Cómo debe almacenarse el historial de conversaciones? ¿Cuándo debe recuperarse el contexto pasado? ¿Y qué debe recuperarse exactamente?

Estas opciones determinan directamente la latencia de respuesta de un agente, el uso de recursos y, en última instancia, su límite de capacidad.

Los modelos como ChatGPT y Claude son cada vez más "conscientes de la memoria" cuanto más los utilizamos. Recuerdan preferencias, se adaptan a objetivos a largo plazo y mantienen la continuidad entre sesiones. En ese sentido, ya funcionan como agentes de IA en miniatura. Sin embargo, bajo la superficie, sus sistemas de memoria se basan en supuestos arquitectónicos muy diferentes.

Recientes análisis de ingeniería inversa de los mecanismos de memoria de ChatGPTy Claude revelan un claro contraste. ChatGPT se basa en la inyección de contexto precalculado y el almacenamiento en caché por capas para ofrecer una continuidad ligera y predecible. Claude, por el contrario, adopta el estilo RAG, la recuperación bajo demanda con actualizaciones dinámicas de memoria para equilibrar la profundidad de la memoria y la eficiencia.

Estos dos enfoques no son sólo preferencias de diseño, sino que están determinados por la capacidad de la infraestructura. Milvus 2.6 introduce la combinación de recuperación híbrida densa-esparcida, filtrado escalar eficiente y almacenamiento por niveles que requiere la memoria conversacional a petición, lo que hace que la recuperación selectiva sea lo suficientemente rápida y económica como para desplegarse en sistemas del mundo real.

En este artículo, explicaremos cómo funcionan realmente los sistemas de memoria de ChatGPT y Claude, por qué divergen arquitectónicamente y cómo los recientes avances en sistemas como Milvus hacen que la recuperación conversacional bajo demanda sea práctica a escala.

El sistema de memoria de ChatGPT

En lugar de consultar una base de datos vectorial o recuperar dinámicamente conversaciones pasadas en el momento de la inferencia, ChatGPT construye su "memoria" reuniendo un conjunto fijo de componentes contextuales e inyectándolos directamente en cada solicitud. Cada componente se prepara con antelación y ocupa una posición conocida en el mensaje.

Este diseño mantiene intactas la personalización y la continuidad de la conversación, al tiempo que hace más predecibles la latencia, el uso de tokens y el comportamiento del sistema. En otras palabras, la memoria no es algo que el modelo busque sobre la marcha, sino algo que el sistema empaqueta y entrega al modelo cada vez que genera una respuesta.

A alto nivel, una consulta ChatGPT completa consta de las siguientes capas, ordenadas de más global a más inmediata:

[0] Instrucciones del sistema

[1] Instrucciones del desarrollador

[2] Metadatos de sesión (efímeros)

[3] Memoria del usuario (hechos a largo plazo)

[4] Resumen de Conversaciones Recientes (chats pasados, títulos + fragmentos)

[5] Mensajes de la sesión actual (este chat)

[6] Su último mensaje

Entre estos, los componentes [2] a [5] forman la memoria efectiva del sistema, cada uno cumpliendo una función distinta.

Metadatos de sesión

Los metadatos de sesión representan información efímera y no persistente que se inyecta una vez al principio de una conversación y se descarta cuando finaliza la sesión. Su función es ayudar al modelo a adaptarse al contexto de uso actual más que personalizar el comportamiento a largo plazo.

Esta capa captura señales sobre el entorno inmediato del usuario y sus patrones de uso recientes. Las señales típicas incluyen:

• Información sobre el dispositivo - por ejemplo, si el usuario está en el móvil o en el escritorio.

• Atributos de la cuenta: como el nivel de suscripción (por ejemplo, ChatGPT Go), la antigüedad de la cuenta y la frecuencia de uso general.

• Métricas de comportamiento: incluidos los días activos de los últimos 1, 7 y 30 días, la duración media de las conversaciones y la distribución del uso del modelo (por ejemplo, el 49% de las solicitudes gestionadas por GPT-5).

Memoria de usuario

La memoria de usuario es la capa de memoria persistente y editable que permite la personalización a través de las conversaciones. Almacena información relativamente estable -como el nombre del usuario, su función o sus objetivos profesionales, proyectos en curso, resultados anteriores y preferencias de aprendizaje- y se inyecta en cada nueva conversación para mantener la continuidad a lo largo del tiempo.

Esta memoria puede actualizarse de dos maneras:

• Lasactualizaciones explícitas se producen cuando los usuarios gestionan directamente la memoria con instrucciones como "recuerda esto" o "elimina esto de la memoria".

• Lasactualizaciones implícitas se producen cuando el sistema identifica información que cumple los criterios de almacenamiento de OpenAI -como un nombre confirmado o un puesto de trabajo- y la guarda automáticamente, sujeta a la configuración predeterminada de consentimiento y memoria del usuario.

Resumen de conversaciones recientes

El resumen de conversaciones recientes es una capa de contexto ligera que permite mantener la continuidad sin necesidad de reproducir o recuperar historiales de chat completos. En lugar de depender de la recuperación dinámica, como en los enfoques tradicionales basados en RAG, este resumen se calcula previamente y se inyecta directamente en cada nueva conversación.

Esta capa sólo resume los mensajes de los usuarios, excluyendo las respuestas de los asistentes. Su tamaño es intencionadamente limitado (unas 15 entradas) y sólo conserva señales de alto nivel sobre intereses recientes, en lugar de contenido detallado. Al no depender de incrustaciones ni de búsquedas de similitudes, mantiene bajos tanto la latencia como el consumo de tokens.

Mensajes de la sesión actual

Los mensajes de la sesión actual contienen el historial completo de mensajes de la conversación en curso y proporcionan el contexto a corto plazo necesario para dar respuestas coherentes y detalladas. Esta capa incluye tanto las entradas del usuario como las respuestas del asistente, pero sólo mientras la sesión permanece activa.

Como el modelo funciona con un límite fijo de tokens, este historial no puede crecer indefinidamente. Cuando se alcanza el límite, el sistema elimina los mensajes más antiguos para dejar espacio a los más recientes. Este truncamiento sólo afecta a la sesión actual: la memoria a largo plazo del usuario y el resumen de la conversación reciente permanecen intactos.

El sistema de memoria de Claude

Claude adopta un enfoque diferente en la gestión de la memoria. En lugar de inyectar un paquete grande y fijo de componentes de memoria en cada consulta -como hace ChatGPT- Claude combina la memoria persistente del usuario con herramientas bajo demanda y recuperación selectiva. El contexto histórico sólo se recupera cuando el modelo lo considera relevante, lo que permite al sistema compensar la profundidad contextual con el coste computacional.

El contexto de Claude se estructura de la siguiente manera:

[0] Indicaciones del sistema (instrucciones estáticas)

[1] Recuerdos del usuario

[2] Historial de conversaciones

[3] Mensaje actual

Las diferencias clave entre Claude y ChatGPT radican en cómo se recupera el historial de conversaciones y cómo se actualiza y mantiene la memoria de usuario.

Memorias de usuario

En Claude, las memorias de usuario forman una capa de contexto a largo plazo similar a la memoria de usuario de ChatGPT, pero con un mayor énfasis en las actualizaciones automáticas en segundo plano. Estas memorias se almacenan en un formato estructurado (envuelto en etiquetas de estilo XML) y están diseñadas para evolucionar gradualmente con el tiempo con una intervención mínima del usuario.

Claude admite dos vías de actualización:

• Actualizaciones implícitas: el sistema analiza periódicamente el contenido de las conversaciones y actualiza las memorias en segundo plano. Estas actualizaciones no se aplican en tiempo real, y las memorias asociadas a conversaciones borradas se eliminan gradualmente como parte de la optimización en curso.

• Actualizaciones explícitas - Los usuarios pueden gestionar directamente la memoria mediante comandos como "recordar esto" o "borrar esto", que se ejecutan a través de una herramienta específica de memory_user_edits.

En comparación con ChatGPT, Claude atribuye una mayor responsabilidad al propio sistema a la hora de refinar, actualizar y podar la memoria a largo plazo. Esto reduce la necesidad de que los usuarios seleccionen activamente lo que se almacena.

Historial de conversaciones

Para el historial de conversaciones, Claude no se basa en un resumen fijo que se inyecta en cada solicitud. En su lugar, recupera el contexto pasado sólo cuando el modelo decide que es necesario, utilizando tres mecanismos distintos. De este modo se evita arrastrar un historial irrelevante y se mantiene bajo control el uso de tokens.

Componente	Finalidad	Cómo se utiliza
Ventana móvil (conversación actual)	Almacena el historial completo de mensajes de la conversación actual (no un resumen), similar al contexto de sesión de ChatGPT.	Se inyecta automáticamente. El límite de tokens es ~190K; los mensajes más antiguos se eliminan una vez alcanzado el límite.
conversation_search herramienta	Busca conversaciones pasadas por tema o palabra clave, devolviendo enlaces de conversaciones, títulos y extractos de mensajes de usuario/asistente.	Se activa cuando el modelo determina que se necesitan detalles históricos. Los parámetros incluyen query (términos de búsqueda) y max_results (1-10)
recent_chats herramienta	Recupera conversaciones recientes dentro de un intervalo de tiempo especificado (por ejemplo, "últimos 3 días"), con resultados formateados igual que conversation_search	Se activa cuando el contexto reciente y temporal es relevante. Los parámetros son n (número de resultados), sort_order y el intervalo de tiempo.

Entre estos componentes, destaca especialmente conversation_search. Es capaz de mostrar resultados relevantes incluso en el caso de consultas con una redacción poco precisa o multilingües, lo que indica que opera a nivel semántico en lugar de basarse en la simple coincidencia de palabras clave. Es probable que esto implique una recuperación basada en la incrustación o un enfoque híbrido que primero traduzca o normalice la consulta a una forma canónica y luego aplique la recuperación por palabras clave o híbrida.

En general, el método de recuperación a petición de Claude tiene varios puntos fuertes notables:

• Larecuperación no es automática: Las llamadas a la herramienta se activan por el propio criterio del modelo. Por ejemplo, cuando un usuario menciona "el proyecto que discutimos la última vez", Claude puede decidir invocar conversation_search para recuperar el contexto relevante.

• Contextomás rico cuando es necesario: Los resultados recuperados pueden incluir extractos de las respuestas de los asistentes, mientras que los resúmenes de ChatGPT sólo capturan los mensajes de los usuarios. Esto hace que Claude sea más adecuado para casos de uso que requieren un contexto conversacional más profundo o preciso.

• Mayor eficacia por defecto: Como el contexto histórico no se inyecta a menos que sea necesario, el sistema evita cargar grandes cantidades de historial irrelevante, reduciendo el consumo innecesario de tokens.

Las contrapartidas son igualmente claras. La introducción de la recuperación bajo demanda aumenta la complejidad del sistema: hay que crear y mantener índices, ejecutar consultas, clasificar los resultados y, a veces, volver a clasificarlos. La latencia de extremo a extremo también es menos predecible que con un contexto precalculado y siempre inyectado. Además, el modelo debe aprender a decidir cuándo es necesaria la recuperación. Si ese juicio falla, es posible que el contexto relevante no se recupere nunca.

Las limitaciones de la recuperación a petición al estilo de Claude

Adoptar un modelo de recuperación bajo demanda convierte a la base de datos vectorial en una parte fundamental de la arquitectura. La recuperación de conversaciones impone exigencias inusualmente altas tanto al almacenamiento como a la ejecución de consultas, y el sistema debe cumplir cuatro restricciones al mismo tiempo.

1. Tolerancia a la baja latencia

En los sistemas de conversación, la latencia P99 debe ser inferior a ~20 ms. Los retrasos superiores a este valor se notan inmediatamente. Los retrasos superiores a esa cifra son inmediatamente perceptibles para los usuarios. Esto deja poco margen para la ineficacia: la búsqueda vectorial, el filtrado de metadatos y la clasificación de resultados deben optimizarse cuidadosamente. Un cuello de botella en cualquier punto puede degradar toda la experiencia conversacional.

2. Requisitos de la búsqueda híbrida

Las consultas de los usuarios suelen abarcar múltiples dimensiones. Una petición como "discusiones sobre RAG de la semana pasada" combina la relevancia semántica con el filtrado basado en el tiempo. Si una base de datos sólo admite la búsqueda vectorial, puede devolver 1.000 resultados semánticamente similares, sólo para que el filtrado de la capa de aplicación los reduzca a un puñado, desperdiciando la mayor parte del cálculo. Para ser práctica, la base de datos debe admitir de forma nativa consultas vectoriales y escalares combinadas.

3. Separación entre almacenamiento y cálculo

El historial de conversaciones muestra un claro patrón de acceso caliente-frío. Las conversaciones recientes se consultan con frecuencia, mientras que las antiguas apenas se tocan. Si todos los vectores tuvieran que permanecer en memoria, el almacenamiento de decenas de millones de conversaciones consumiría cientos de gigabytes de RAM, un coste poco práctico a escala. Para ser viable, el sistema debe soportar la separación almacenamiento-computación, manteniendo los datos calientes en memoria y los fríos en almacenamiento de objetos, con vectores cargados bajo demanda.

4. Patrones de consulta diversos

La recuperación de conversaciones no sigue un único patrón de acceso. Algunas consultas son puramente semánticas (por ejemplo, "la optimización del rendimiento que discutimos"), otras son puramente temporales ("todas las conversaciones de la semana pasada"), y muchas combinan múltiples restricciones ("discusiones relacionadas con Python que mencionen FastAPI en los últimos tres meses"). El planificador de consultas de la base de datos debe adaptar las estrategias de ejecución a los distintos tipos de consulta, en lugar de basarse en una búsqueda de fuerza bruta de talla única.

En conjunto, estos cuatro retos definen las principales limitaciones de la recuperación conversacional. Cualquier sistema que pretenda implantar la recuperación a la carta al estilo de Claude debe abordarlos todos de forma coordinada.

Por qué Milvus 2.6 funciona bien para la recuperación conversacional

Las opciones de diseño de Milvus 2. 6 se ajustan estrechamente a los requisitos básicos de la recuperación conversacional a petición. A continuación se presenta un desglose de las capacidades clave y su correspondencia con las necesidades reales de recuperación conversacional.

Recuperación híbrida con vectores densos y dispersos

Milvus 2.6 admite de forma nativa el almacenamiento de vectores densos y dispersos dentro de la misma colección y la fusión automática de sus resultados en el momento de la consulta. Los vectores densos (por ejemplo, las incrustaciones de 768 dimensiones generadas por modelos como BGE-M3) capturan la similitud semántica, mientras que los vectores dispersos (producidos normalmente por BM25) conservan las señales exactas de las palabras clave.

Para una consulta del tipo "debates sobre el GAR de la semana pasada", Milvus ejecuta la recuperación semántica y la recuperación de palabras clave en paralelo, y luego fusiona los resultados mediante reordenación. En comparación con el uso de cualquiera de los dos enfoques por separado, esta estrategia híbrida ofrece una recuperación significativamente mayor en escenarios conversacionales reales.

Separación almacenamiento-ordenador y optimización de consultas

Milvus 2.6 admite el almacenamiento por niveles de dos maneras:

• Datos calientes en memoria, datos fríos en almacenamiento de objetos

• Índices en memoria, datos vectoriales en bruto en almacenamiento de objetos

Con este diseño, se puede almacenar un millón de entradas de conversación con aproximadamente 2 GB de memoria y 8 GB de almacenamiento de objetos. Con el ajuste adecuado, la latencia de P99 puede permanecer por debajo de 20 ms, incluso con la separación almacenamiento-computación activada.

Trituración JSON y filtrado escalar rápido

Milvus 2.6 activa JSON Shredding por defecto, aplanando los campos JSON anidados en almacenamiento columnar. Esto mejora el rendimiento del filtrado escalar entre 3 y 5 veces según los puntos de referencia oficiales (las ganancias reales varían según el patrón de consulta).

La recuperación conversacional suele requerir el filtrado por metadatos, como el ID de usuario, el ID de sesión o el intervalo de tiempo. Con JSON Shredding, las consultas del tipo "todas las conversaciones del usuario A en la última semana" pueden ejecutarse directamente en índices columnares, sin tener que analizar repetidamente blobs JSON completos.

Control de código abierto y flexibilidad operativa

Como sistema de código abierto, Milvus ofrece un nivel de control arquitectónico y operativo que no ofrecen las soluciones cerradas de caja negra. Los equipos pueden ajustar los parámetros de los índices, aplicar estrategias de clasificación de datos por niveles y personalizar los despliegues distribuidos para adaptarlos a sus cargas de trabajo.

Esta flexibilidad reduce la barrera de entrada: los equipos pequeños y medianos pueden crear sistemas de recuperación conversacional a escala de millones a decenas de millones sin depender de presupuestos de infraestructura desorbitados.

Por qué ChatGPT y Claude tomaron caminos diferentes

A grandes rasgos, la diferencia entre los sistemas de memoria de ChatGPT y Claude se reduce a cómo gestiona cada uno el olvido. ChatGPT favorece el olvido proactivo: una vez que la memoria supera unos límites fijos, se elimina el contexto más antiguo. De este modo, se sustituye la exhaustividad por la simplicidad y el comportamiento predecible del sistema. Claude prefiere el olvido retardado. En teoría, el historial de conversaciones puede crecer sin límites, y la recuperación se delega en un sistema a la carta.

¿Por qué los dos sistemas han elegido caminos diferentes? Con las limitaciones técnicas expuestas anteriormente, la respuesta es clara: cada arquitectura sólo es viable si la infraestructura subyacente puede soportarla.

Si el planteamiento de Claude se hubiera intentado en 2020, probablemente habría sido inviable. En aquella época, las bases de datos vectoriales solían incurrir en cientos de milisegundos de latencia, las consultas híbridas no estaban bien soportadas y el uso de recursos aumentaba prohibitivamente a medida que crecían los datos. En esas condiciones, la recuperación bajo demanda se habría considerado un exceso de ingeniería.

En 2025, el panorama ha cambiado. Los avances en infraestructura -impulsados por sistemas como Milvus 2.6-han hecho que la separación almacenamiento-ordenador, la optimización de consultas, la recuperación híbrida densa-esparcida y la trituración de JSON sean viables en producción. Estos avances reducen la latencia, controlan los costes y hacen que la recuperación selectiva sea práctica a escala. Como resultado, las herramientas bajo demanda y la memoria basada en la recuperación no sólo son viables, sino cada vez más atractivas, especialmente como base para sistemas de tipo agente.

En última instancia, la elección de la arquitectura depende de lo que la infraestructura haga posible.

Conclusión

En los sistemas del mundo real, el diseño de la memoria no es una elección binaria entre el contexto precalculado y la recuperación bajo demanda. Las arquitecturas más eficaces suelen ser híbridas, combinando ambos enfoques.

Un patrón común consiste en inyectar los giros recientes de la conversación a través de una ventana de contexto deslizante, almacenar las preferencias estables del usuario como memoria fija y recuperar el historial más antiguo bajo demanda mediante búsqueda vectorial. A medida que un producto madura, este equilibrio puede cambiar gradualmente -de un contexto principalmente precalculado a otro cada vez más basado en la recuperación- sin que sea necesario un reinicio arquitectónico disruptivo.

Incluso cuando se empieza con un enfoque precalculado, es importante diseñar teniendo en cuenta la migración. La memoria debe almacenarse con identificadores claros, marcas de tiempo, categorías y referencias a la fuente. Cuando la recuperación sea viable, se pueden generar incrustaciones para la memoria existente y añadirlas a una base de datos vectorial junto con los mismos metadatos, lo que permite introducir la lógica de recuperación de forma incremental y con una interrupción mínima.

¿Tiene alguna pregunta o desea profundizar en alguna de las características de la última versión de Milvus? Únase a nuestro canal de Discord o presente incidencias en GitHub. También puede reservar una sesión individual de 20 minutos para obtener información, orientación y respuestas a sus preguntas a través de Milvus Office Hours.