6. Cuando la memoria se degrada: context drift en conversaciones largas

Descripción

Al terminar esta lección vas a poder reconocer, con evidencia concreta del arreglo de mensajes que le llega al modelo, cuándo el comportamiento errático de un agente no es un fallo de memoria —la memoria trajo el dato correcto, en el lugar correcto del arreglo— sino context drift: la degradación gradual que sufre un modelo cuando el historial que carga en cada llamada crece demasiado. Vas a poder distinguir ese síntoma de un problema de alcance o de almacenamiento (lecciones 2 y 4), y vas a poder anticipar en qué tipo de agente es más probable que aparezca.

Esto importa porque el criterio de calidad de un agente en producción no es solo "¿recuerda?" —es "¿sigue razonando bien después de recordar mucho?". Un agente de soporte que atiende al mismo cliente durante meses, con memoria persistente (la que armaste en la lección 4), acumula un historial que un chatbot de una sola sesión nunca llega a ver. Ese historial no desaparece: se reinyecta completo, o casi completo, en cada llamada nueva. Llega un punto en que tener demasiado de lo correcto empieza a comportarse, para el modelo, de forma parecida a no tener nada —y ese punto lo va a encontrar un cliente real, no un caso de prueba de dos o tres turnos, tarde o temprano.

Conexión con el módulo: en la lección 2 viste que un historial bien reinyectado no garantiza que el modelo razone bien sobre él —el Ejercicio 2 de esa lección mostró un agente que fallaba con toda la información disponible, y la conclusión fue "sospecha del modelo o del prompt, no de la memoria". Esta lección retoma exactamente esa grieta y la explica a fondo: ese tipo de fallo no es aleatorio, tiene nombre, mecanismo y un patrón predecible. También construye sobre la lección 4 —la memoria persistente que sobrevive entre sesiones es precisamente el escenario donde un historial puede crecer sin límite natural, semana tras semana, hasta convertirse en el problema de esta lección. Lo que esta lección no cubre todavía es qué hacer al respecto de forma sistemática: resumir el historial o reiniciar el contexto es el trabajo completo de la lección 7, justo después de esta.

Cuando tener todo el historial ya no alcanza

Imagina un abogado que, antes de cada llamada con un cliente, repasa el expediente completo del caso. La primera semana el expediente tiene cinco páginas —lo lee en un minuto y no se le escapa nada. Para la semana quince, el mismo expediente tiene ochenta páginas: nuevas cláusulas, correos, actualizaciones, alguna nota que contradice algo que se dijo al principio porque las circunstancias cambiaron. El abogado sigue leyendo todo antes de cada llamada —nadie le quitó ninguna página—, pero con ochenta páginas frescas en la cabeza, en los segundos antes de contestar el teléfono, dos cláusulas parecidas de páginas distintas empiezan a mezclarse, y confunde cuál aplica a la situación de hoy. No es que se le haya "olvidado" el expediente —lo leyó completo, de principio a fin. Es que procesar ochenta páginas con precisión no es lo mismo que procesar cinco, aunque el abogado sea la misma persona con la misma capacidad.

Un modelo de lenguaje, dentro de una sola llamada, sufre una versión medible de exactamente eso. Anthropic lo llama context rot, y lo describe sin vueltas: a medida que crece el número de tokens en la ventana de contexto, la capacidad del modelo de recuperar información de ese contexto con precisión disminuye. La causa no es que al modelo "se le acabe la memoria" —es arquitectónica. Los modelos actuales están construidos sobre la arquitectura transformer, que permite que cada token le preste atención a cada otro token del contexto, lo que produce, en palabras de Anthropic, "n² pairwise relationships for n tokens" (relaciones de a pares que crecen al cuadrado del número de tokens). Los modelos operan con un "attention budget" —un presupuesto de atención que se agota a medida que entra más contexto. Cuantos más tokens hay que relacionar entre sí, más se estira ese presupuesto, y más fina queda la atención disponible para cualquier fragmento en particular.

Esto no es un interruptor que se apaga de golpe. Anthropic aclara que no hay un "acantilado": lo que hay es un "performance gradient" —un gradiente de rendimiento. Un modelo se mantiene capaz en contextos largos, pero muestra menos precisión para recuperar información específica y para razonar sobre relaciones que cruzan grandes tramos del contexto. Ese matiz importa para diagnosticar: no vas a ver que el agente funcione perfecto hasta el turno 30 y colapse por completo en el turno 31. Vas a ver que se vuelve, de a poco, menos confiable con datos que el cliente dijo hace rato, mientras sigue funcionando bien con lo más reciente.

Ejemplo trabajado

NubeFit tiene, desde la lección 4, memoria persistente por cliente: Postgres Chat Memory, con sessionKey igual al teléfono del cliente y contextWindowLength en 50 —generoso a propósito, para no perder nada. Vamos a comparar la misma pregunta —"anótame en la próxima clase de spinning que tengas disponible"— en dos clientas distintas: una que recién empieza, y una que lleva cinco semanas conversando con el bot.

Ana, clienta nueva, turno 4. En el turno 1 Ana escribió: "Prefiero las clases de spinning en la mañana, trabajo de noche." El agente confirmó. Dos preguntas breves después, sobre casilleros y horarios de domingo, Ana pide que la anoten en la próxima clase de spinning.

# Arreglo de mensajes que recibe el modelo — Ana, turno 4
# (mismo nodo y misma configuración que el caso de Sofía más abajo)

messages = [
  { role: "system",    content: "Eres el asistente de NubeFit..." },
  { role: "user",      content: "Prefiero las clases de spinning en la
                                 mañana, trabajo de noche." },              # turno 1
  { role: "assistant", content: "Anotado: spinning en horario matutino." },
  { role: "user",      content: "¿Los casilleros tienen llave?" },         # turno 2
  { role: "assistant", content: "Sí, los del segundo piso, incluidos en
                                 tu membresía." },
  { role: "user",      content: "¿Y los domingos a qué hora cierran?" },   # turno 3
  { role: "assistant", content: "Los domingos cerramos a las 6:00 p. m." },
  { role: "user",      content: "Anótame en la próxima clase de spinning
                                 que tengas disponible." }                  # turno 4
]

Qué esperar — Ana. El agente responde: "Te anoto en spinning de mañana, que es el horario que me dijiste que prefieres —el próximo cupo disponible es mañana a las 7:00 a. m." La preferencia está a tres intercambios de distancia, en un arreglo de ocho mensajes cortos. El modelo la usa sin esfuerzo aparente.

Sofía, clienta hace cinco semanas, turno 42. Sofía dijo la misma preferencia en el turno 18, hace varias sesiones (todas capturadas por la memoria persistente bajo su teléfono). Desde entonces acumuló otros 23 turnos: cambió de plan, congeló la membresía dos semanas por un viaje, reclamó por el estacionamiento, preguntó por batidos de proteína —y en el turno 30, de paso, mencionó que los sábados en la noche prefiere ir a yoga, "es el único horario que tengo libre ese día". En el turno 42 escribe exactamente la misma frase que Ana:

# Arreglo de mensajes que recibe el modelo — Sofía, turno 42
# contextWindowLength = 50, así que el turno 18 SÍ entra en el arreglo

messages = [
  { role: "system",    content: "Eres el asistente de NubeFit..." },
  { role: "user",      content: "Quiero inscribirme al plan Plus." },      # turno 1
  { role: "assistant", content: "Perfecto, tu plan Plus queda activo..." },
  // ... turnos 3 a 17: pagos, horarios generales, una duda sobre clases
  { role: "user",      content: "Prefiero las clases de spinning en la
                                 mañana, trabajo de noche." },              # turno 18
  { role: "assistant", content: "Anotado: spinning en horario matutino." },
  // ... turnos 20 a 29: cambio de plan, congelamiento por viaje, reclamo
  //     por estacionamiento, pregunta sobre batidos de proteína
  { role: "user",      content: "Los sábados en la noche prefiero yoga,
                                 es el único horario que tengo libre
                                 ese día." },                               # turno 30
  { role: "assistant", content: "Anotado: yoga los sábados en la noche." },
  // ... turnos 32 a 41: facturación y una consulta por una clase
  //     grupal cancelada
  { role: "user",      content: "Anótame en la próxima clase de spinning
                                 que tengas disponible." }                  # turno 42
]

Qué esperar — Sofía. El agente responde: "¿Prefieres la clase de spinning de la mañana o de la noche? Cuéntame qué horario te queda mejor." La preferencia por la mañana está, literalmente, dentro del arreglo —en el turno 18, a 24 turnos de distancia del turno 42. La memoria hizo su trabajo: Postgres Chat Memory reunió y reinyectó el historial completo, incluido ese turno. Pero el modelo, con más de cuarenta turnos de contexto y un dato semánticamente parecido —la preferencia de yoga los sábados en la noche— compitiendo en el mismo arreglo, no lo recupera con la misma precisión con la que lo hizo para Ana.

Interpretación: la diferencia entre Ana y Sofía no es de memoria —ambas tienen el mismo nodo, la misma configuración, y en ambos casos el dato relevante SÍ llegó al modelo. La diferencia es cuánto contexto rodea a ese dato en el momento en que se necesita. Con ocho mensajes, el modelo lo recupera sin esfuerzo. Con más de cuarenta, y un distractor semánticamente cercano de por medio, empieza a fallar —el mismo patrón de degradación gradual que describe Anthropic, no un corte limpio.

Por qué ocurre: tres factores que lo empeoran

Dónde queda el dato dentro del historial. El paper "Lost in the Middle", de Liu et al., midió algo específico: el rendimiento de los modelos al recuperar información según en qué parte de un contexto largo esté ubicada. El hallazgo, en sus propias palabras, es que "performance is often highest when relevant information occurs at the beginning or end of the input context, and significantly degrades when models must access relevant information in the middle" (el rendimiento suele ser más alto cuando la información relevante está al inicio o al final del contexto, y se degrada de forma significativa cuando el modelo tiene que acceder a información que quedó en el medio). Es un patrón en forma de U. Por eso, en el caso de Sofía, el turno 18 es más vulnerable que el turno 1: para el turno 42, el turno 1 está en el extremo del historial (favorecido), mientras que el turno 18 quedó enterrado en algún punto intermedio de un arreglo que ya tiene más de cuarenta entradas.

Los distractores semánticamente parecidos amplifican el error. El informe de investigación de Chroma sobre context rot, que evaluó 18 modelos, encontró que "even a single distractor reduces performance relative to the baseline" (incluso un solo distractor reduce el rendimiento respecto a la línea base) —y ese efecto crece con el largo del contexto. En el caso de Sofía, la mención de yoga los sábados en la noche no es información sobre spinning en absoluto, pero comparte el mismo tipo de dato (una preferencia de horario para una clase) y eso basta para que compita con el dato correcto en el momento en que el modelo tiene que decidir qué usar.

Cómo lo mide n8n no es cómo lo mide el modelo. El parámetro Context Window Length del nodo de memoria —el mismo que ajustaste en las lecciones 3 y 4— cuenta, según la documentación oficial, el número de interacciones anteriores a considerar. Interacciones, no tokens. Dos agentes con el mismo valor de contextWindowLength pueden llegar al modelo con cantidades de tokens muy distintas: un agente que solo intercambia frases cortas, y otro que en cada turno reinyecta la respuesta completa de una tool con el catálogo entero de clases de la semana, acumulan volúmenes de contexto completamente diferentes bajo el mismo número de "turnos" configurado. Y con memoria persistente (lección 4), scopeada a un cliente real que puede seguir conversando durante meses, no hay ningún techo natural que frene ese crecimiento —el historial sigue expandiéndose salvo que algo, activamente, lo controle. Vale la pena distinguir esto del error duro que puede devolver el proveedor del modelo cuando el total de tokens supera el límite físico de su ventana de contexto —una falla binaria, la ejecución del nodo se corta con un error. Context rot es distinto y aparece mucho antes: la degradación es progresiva, no hace falta acercarse al límite físico del modelo para empezar a perder precisión.

Errores comunes

Creer que context rot es un fallo de memoria, corregible subiendo contextWindowLength o cambiando a un modelo con ventana más grande (conceptual). Qué pasa: al ver que el agente ignora un dato que el cliente ya dio, se sube el contextWindowLength a un número mayor, o se conecta un modelo con más capacidad —y el problema no mejora, o incluso empeora. Por qué pasa: la intuición natural es "si el agente no usa bien un dato que sí tiene, dale más espacio para que quepa mejor". Pero el mecanismo de context rot no es de espacio disponible —es de atención dividida entre más tokens. Subir el contextWindowLength agrega más tokens al arreglo que el modelo tiene que procesar en cada llamada, lo que expande el problema en vez de resolverlo. Cómo detectarlo: si subir el contextWindowLength o cambiar de modelo no mejora la precisión sobre un dato ya presente en el arreglo —o la empeora—, no es un problema de capacidad. Cómo corregirlo: diagnostica primero, con el panel de ejecución, si el dato está en el arreglo de mensajes (así descartas alcance y almacenamiento, lecciones 2 y 4); si está y aun así falla, el eje a trabajar es cuánto contexto rodea a ese dato, no cuánto contexto le permites tener en total —eso es exactamente lo que aborda la lección 7.

Confundir "el modelo no tiene el dato" con "el modelo tiene el dato pero lo usa mal por exceso de contexto" (conceptual). Qué pasa: se trata cualquier "el agente no se acuerda de X" como el mismo problema, y se revisa una y otra vez el sessionKey o el nodo de almacenamiento, sin resultado —porque en este caso ambos están perfectamente bien configurados. Por qué pasa: para el cliente que escribe, "el bot ignoró algo que ya dije" se siente idéntico sin importar la causa interna; el síntoma visible no distingue entre las dos causas. Cómo detectarlo: abre el panel de ejecución de n8n e inspecciona el arreglo real de mensajes que recibió el modelo en ese turno. Si el dato no está ahí, es un problema de alcance o almacenamiento (lecciones 2 y 4). Si está, literalmente, en algún turno anterior del arreglo, y el modelo igual falla, es context drift. Cómo corregirlo: bifurca el diagnóstico justo ahí —si el dato ya apareció en el arreglo, deja de revisar sessionKey y nodo de almacenamiento; el problema se movió a cuánto contexto rodea ese dato, el tema de esta lección.

Probar el agente solo con conversaciones cortas y recién iniciadas durante el desarrollo, nunca con una simulación de una relación larga (práctico). Qué pasa: cada prueba durante el desarrollo arranca con un cliente "nuevo" o con pocos turnos acumulados, así que nunca se junta suficiente contexto como para que aparezca la degradación. El agente pasa todas las pruebas y falla, semanas después, con un cliente real de largo plazo —exactamente el tipo de cliente que la memoria persistente de la lección 4 está pensada para atender bien. Por qué pasa: simular semanas de historial real toma tiempo, y no es el flujo natural de iterar rápido sobre un prompt o una tool durante el desarrollo. Cómo detectarlo: si nunca corriste una prueba con un arreglo de treinta, cuarenta o más turnos acumulados —aunque sea sintético, construido a mano— no verificaste context drift, solo verificaste comportamiento de corto plazo. Cómo corregirlo: antes de dar por lista una versión del agente que va a usar memoria persistente en producción, arma al menos una conversación de prueba larga —puedes pedirle a un modelo que simule treinta o cuarenta turnos plausibles— e incluye, a propósito, un dato temprano que el agente deba recuperar en el último turno, como el caso de Sofía.

Ejercicios

Ejercicio 1 — Diagnóstico con el panel de ejecución. Un agente de soporte con memoria persistente falla en el turno 55 de una conversación: el cliente había dicho, en el turno 6, que su dirección de envío es en Bogotá, y en el turno 55 el agente le cotiza el envío como si fuera a Ciudad de México. Abres el panel de ejecución de n8n y confirmas que el turno 6 completo, con la dirección de Bogotá, sí está presente en el arreglo de mensajes que recibió el modelo en el turno 55. ¿Es un problema de memoria? ¿Qué es, y en qué te basas para decirlo?

Ver solución

No es un problema de memoria. El dato está presente y en el lugar correcto del arreglo —el nodo de memoria hizo su trabajo: alcance y almacenamiento correctos, tal como los definiste en las lecciones 2 y 4. Es context drift: con 55 turnos de contexto acumulado, el modelo perdió precisión sobre un dato temprano, probablemente porque quedó enterrado lejos del turno actual —el efecto que describe "Lost in the Middle"— y posiblemente compitiendo con otras ciudades o direcciones mencionadas en turnos posteriores.

Por qué funciona: el criterio de esta lección es exactamente ese —si el dato aparece en el arreglo y el modelo aun así falla, la causa se mueve de memoria a contexto. Confirmarlo con el panel de ejecución, no con una suposición, es lo que evita revisar el nodo equivocado.

Ejercicio 2 — Aplica el criterio de contextWindowLength. Dos agentes de NubeFit tienen contextWindowLength = 30 en su nodo Postgres Chat Memory. El Agente 1 solo usa el System Message y respuestas cortas de texto. El Agente 2, además, tiene una tool conectada que devuelve el catálogo completo de clases de la semana —varios cientos de palabras— cada vez que se llama, y esa respuesta queda guardada como parte del historial. Con el mismo valor de contextWindowLength, ¿cuál de los dos agentes está más expuesto a context drift, y por qué?

Ver solución

El Agente 2, aunque el parámetro configurado sea idéntico. Context Window Length cuenta interacciones, no tokens —treinta turnos de mensajes cortos pueden ser un arreglo pequeño, mientras que treinta turnos donde varios incluyen la respuesta completa de una tool con cientos de palabras cada vez acumulan muchos más tokens. Como el mecanismo de context rot depende del volumen de tokens que el modelo tiene que relacionar entre sí en una sola llamada —no del número de turnos como tal—, el Agente 2 llega antes al régimen donde la precisión empieza a degradarse, aunque ambos agentes tengan configurado "lo mismo" en apariencia.

Por qué funciona: separar "cuántos turnos permite el nodo" de "cuántos tokens realmente acumula" es necesario porque el parámetro que ves en el nodo de memoria no mide directamente lo que causa context rot —la misma separación que ya hiciste en la lección 2 entre "capacidad del modelo" y "qué decide qué entra en esa capacidad", aplicada ahora a un eje distinto: cuánto entra, no si entra.

Ejercicio 3 — Corrige a un colega. Un colega, después de ver el caso de Sofía, te dice: "Fácil, subamos el contextWindowLength a 500 así el agente nunca pierde nada de lo que dijo un cliente." ¿Qué le responderías, usando lo que aprendiste en esta lección?

Ver solución

Que subir el contextWindowLength no resuelve context drift —probablemente lo empeora. El mecanismo no es "el modelo se queda sin espacio para guardar datos": es que cada token adicional divide más el presupuesto de atención del modelo entre más relaciones posibles entre tokens. Con un contextWindowLength de 500, el agente sí "tiene" casi todo lo que el cliente dijo alguna vez, en el sentido de que está presente en el arreglo —pero precisamente por eso, con tanto contexto compitiendo, es más probable que pierda precisión sobre un dato específico, no menos.

Por qué funciona: distinguir "el dato está disponible" de "el modelo lo usa con precisión" es la misma distinción que sostiene toda esta lección. Lo que ayuda no es acumular más historial sin límite, sino manejar qué tan grande y qué tan cargado de contexto irrelevante llega ese historial a cada llamada —el problema que la siguiente lección empieza a resolver.

Resumen y siguiente paso

Ya viste que un historial correctamente reinyectado no garantiza precisión: a medida que una conversación acumula turnos —sobre todo con memoria persistente que sobrevive semanas o meses, como la de la lección 4—, el modelo pierde exactitud sobre datos que sí están presentes en el arreglo de mensajes. Es un fenómeno documentado y con nombre, context rot o context drift, causado por cómo la arquitectura transformer divide su atención entre más y más tokens, no por ningún límite de "espacio" que resuelvas agrandando la ventana o el contextWindowLength.

Antes de avanzar deberías poder: diagnosticar, con el panel de ejecución de n8n a la vista, si un fallo de "el agente ignoró algo que el cliente ya dijo" es un problema de memoria (lecciones 2 y 4) o de context drift; explicar por qué subir contextWindowLength o el tamaño del modelo no es, por sí solo, una solución; y reconocer que el riesgo crece con conversaciones de vida larga —justo el tipo de agente que la memoria persistente de la lección 4 hace posible.

Ya sabes reconocer el síntoma y su causa. Lo que todavía no tienes es qué hacer con un historial que amenaza con volverse demasiado grande antes de que el context drift se instale —eso es exactamente el trabajo de la siguiente lección: cuándo conviene resumir la conversación para que quepa en un espacio más manejable, y cuándo conviene, directamente, reiniciar el contexto en vez de seguir arrastrando todo.

Recursos

• Effective context engineering for AI agents — Anthropic — la fuente de la definición de context rot usada en esta lección: el mecanismo del presupuesto de atención, las relaciones n² entre tokens, y por qué la degradación es un gradiente y no un corte limpio.
• Context Rot — Chroma Research — el estudio empírico con 18 modelos que sustenta el ejemplo de esta lección: cómo los distractores semánticos amplifican la degradación al crecer el contexto.
• Lost in the Middle: How Language Models Use Long Contexts — Liu et al. (arXiv) — el paper que documenta el patrón en forma de U: la información al inicio o al final de un contexto largo se recupera mejor que la que queda en medio, la base de por qué el turno 18 de Sofía es más vulnerable que el turno 1.
• Simple Memory node — n8n Docs — confirma que Context Window Length cuenta interacciones, no tokens, la base del Ejercicio 2 de esta lección.
• Postgres Chat Memory node — n8n Docs — el nodo detrás del escenario de Sofía: memoria persistente que, al no tener un techo natural de tiempo, es exactamente el tipo de configuración donde el historial puede crecer lo suficiente como para que aparezca context drift.