Context rot: por qué los chats largos pierden precisión

El context rot reduce la fiabilidad de los agentes en chats largos. Aprende a detectar el problema y conservar el contexto que necesita cada decisión.

Publicado el

Context rot: por qué los chats largos pierden precisión

El context rot puede reducir la precisión de un agente incluso cuando toda la información de entrada cabe en la ventana de contexto anunciada. El estudio de Chroma sobre 18 modelos de lenguaje observó que la fiabilidad variaba según la longitud de la entrada. En la práctica, conviene conservar la evidencia necesaria para la siguiente acción y reducir el historial que ya no aporta nada.

¿Qué es el context rot en IA?

El context rot, o degradación del contexto, es la pérdida de fiabilidad que se produce al aumentar la información que recibe un modelo de lenguaje. Puede manifestarse como datos que se pasan por alto, asociaciones incorrectas o respuestas que dejan de respetar una decisión ya tomada. El modelo puede seguir aceptando una conversación larga aunque le resulte cada vez más difícil utilizarla con precisión.

La ventana de contexto es el espacio de trabajo del que dispone el modelo para una solicitud. Puede contener instrucciones, historial de conversación, documentos y resultados de herramientas. Un token es una unidad de contenido que procesa el modelo, a menudo un fragmento de una palabra. Nuestra guía sobre la ventana de contexto explica qué ocupa ese espacio.

Imagina una sala de gestión de incidentes en cuya pared conviven el plan vigente, las hipótesis descartadas, las cronologías que ya quedaron obsoletas y los registros antiguos. Una pared más grande permite guardar más material. Pero no le indica a la siguiente persona qué decisión sigue rigiendo el trabajo.

Esta distinción importa al investigar los fallos de un agente. Si el dato necesario se eliminó antes de que el modelo recibiera la solicitud, revisa el truncamiento o la recuperación de información. Si el dato estaba presente, pero la respuesta lo omitió o lo usó mal, revisa cómo manejó el modelo el contexto recibido. Ninguno de los dos síntomas demuestra, por sí solo, que el problema sea la longitud.

Documentación revisada el 24 de octubre de 2026: las recomendaciones del proveedor que aparecen a continuación se verificaron con la documentación vigente de Anthropic. Los ejemplos de flujos de trabajo son propuestas de diseño, no resultados observados en producción.

El estudio sobre context rot: qué demuestra la evidencia

El informe de Chroma, publicado el 14 de julio de 2025, observó que las coincidencias semánticas más difíciles de identificar y los distractores con apariencia de relevancia reducían la fiabilidad de la recuperación en entradas más largas. Sus tareas controladas aportan evidencia útil, pero no miden el rendimiento de tu agente. Estudio original.

Gráficos originales del experimento de Chroma con distractores que muestran la precisión según la longitud de la entrada y la condición de distracción
Figura original de Chroma: condiciones de distracción con distintas longitudes de entrada. Resultados históricos del estudio, reproducidos sin cambios.

En su versión depurada del conjunto de evaluación de conversaciones LongMemEval, Chroma comparó 306 prompts con una media aproximada de 113,000 tokens frente a versiones centradas en la información pertinente, con una media de unos 300 tokens. Las entradas centradas en lo relevante obtuvieron mejores puntuaciones en todos los modelos evaluados. Hay un matiz fundamental: esas entradas breves se elaboraron a partir de pasajes etiquetados como relevantes y de ajustes manuales; no procedían de un sistema de recuperación evaluado de forma automática. Métodos y resultados del estudio.

Gráfico original de Chroma para la familia GPT que compara las puntuaciones en LongMemEval con entradas centradas en lo relevante y entradas completas, para los modelos y configuraciones históricos indicados
Figura original de Chroma: entradas centradas en lo relevante frente a entradas completas en su evaluación de la familia GPT. Corresponde a los modelos y configuraciones del estudio, no a una clasificación actual.

Hasta dónde llegan las conclusiones de Chroma

El informe no establece el mecanismo subyacente ni una cantidad de tokens que sea segura en todos los casos. Además, en su experimento con texto repetido, la salida crece junto con la entrada, a diferencia de las pruebas de recuperación con respuestas breves. Limitaciones de la investigación y descripción de las tareas.

Si desarrollas un sistema, la pregunta útil es si puede encontrar y conservar la evidencia necesaria. Un gráfico que compara evidencia seleccionada cuidadosamente con un historial completo no dice si tu índice de búsqueda, tus filtros o tu sistema de resumen harán bien esa selección. Esa capacidad debe evaluarse por separado.

¿Por qué cuesta más usar un contexto largo?

El material relevante debe poder distinguirse de todo lo que lo rodea. Un plan de despliegue antiguo puede parecerse más al plan vigente que un documento sobre otro tema. El riesgo no consiste solo en no encontrar una frase, sino en aplicar a la situación actual una frase que no corresponde.

La guía de ingeniería de contexto de Anthropic señala las limitaciones de arquitectura y el entrenamiento con secuencias mayoritariamente más cortas como factores que contribuyen a la dificultad de manejar contextos largos. Describe una pérdida gradual de precisión, no un límite único a partir del cual desaparece la capacidad. Estas explicaciones ayudan a analizar el problema, pero no demuestran que exista una explicación causal completa.

Piensa en un agente de soporte cuyo historial contiene un diagnóstico inicial, una solución provisional fallida y una corrección confirmada después. Si una llamada posterior a una herramienta devuelve una versión antigua de la guía de resolución de problemas, la siguiente respuesta tendrá que conciliar tanto la cronología como la autoridad de las fuentes. El texto adicional ha complicado la decisión, aunque la pregunta del usuario siga siendo la misma.

Haz explícita esa conciliación: identifica el estado actual, marca el diagnóstico anterior como descartado y conserva la fuente que respalda la corrección aceptada. El objetivo es disponer de evidencia suficiente cuyo estado esté claro, no fabricar el prompt más corto posible.

Qué revisar primero al desarrollar u operar un agente

Compara la misma decisión con distintos contextos antes de atribuir el fallo al modelo. Para quienes desarrollan el sistema, esto implica capturar la solicitud real que prepara la aplicación. La conversación visible puede omitir instrucciones del sistema, resultados de recuperación o respuestas de herramientas que sí llegaron al modelo.

Para quienes operan el agente, el punto de partida es identificar un requisito concreto que no se cumplió o una acción incorrecta. «El chat parece funcionar peor» es difícil de investigar; «recomendó la solución provisional que ya se había descartado en el registro del incidente» permite reproducir un caso concreto.

Aplica esta secuencia de diagnóstico a un ejemplo guardado:

  1. Fija las condiciones de la decisión

    Mantén constantes la pregunta, la configuración del modelo y el resultado requerido. Guarda la entrada original y la evidencia de referencia. Reproduce el caso sin ejecutar acciones externas, para que la comparación no altere la situación de partida.

  2. Comprueba si llegó la evidencia

    Busca el pasaje necesario en la solicitud real. Si falta, corrige primero la recuperación, el truncamiento o la carga del estado. Si llegó una fuente obsoleta en su lugar, corrige la selección de fuentes y su vigencia.

  3. Prepara una comparación con el contexto relevante

    Conserva las mismas instrucciones de la tarea y toda la evidencia necesaria para responder, pero elimina el historial ajeno al caso y los resultados de herramientas obsoletos. No incluyas la respuesta esperada ni simplifiques la tarea. Compara la corrección de las respuestas, el uso de las fuentes y el cumplimiento de las restricciones al reproducir casos representativos.

  4. Elige la corrección según el fallo

    Si la entrada centrada en lo relevante mejora el resultado, investiga la selección y organización del contexto. Si ambas versiones fallan, revisa la tarea, las instrucciones, la calidad de la evidencia y la capacidad del modelo. Si el fallo empieza después de resumir, comprueba qué se perdió en el resumen.

Esta comparación sirve para diagnosticar, pero no demuestra que la longitud por sí sola haya causado el error: al quitar material también cambia la composición del contexto. Para comprobar de forma más rigurosa el efecto de la longitud, controla la evidencia relevante y su posición mientras añades material ajeno al caso. No saques conclusiones generales de una repetición que salió bien por casualidad.

Conviene intervenir cuando el crecimiento del historial acompaña de forma repetida a errores evitables. Un flujo de trabajo breve y acotado que supera sus comprobaciones de corrección puede conservar un diseño sencillo. Añade orquestación cuando haya un fallo concreto que deba resolver.

Cómo reducir la degradación del contexto en un agente

Elige la intervención según el material que esté causando el problema. La compactación gestiona el historial acumulado; la recuperación selecciona evidencia; los subagentes mantienen acotada la exploración; el orden aclara la tarea; y las respuestas concisas de las herramientas reducen la entrada innecesaria. Son controles complementarios, y cada uno puede fallar de una manera distinta.

Compacta el historial sin perder el estado del trabajo

La compactación sustituye las partes antiguas de la conversación por un registro más breve que permite continuar el trabajo. La documentación vigente sobre compactación de Anthropic explica por qué importa mantener reducido el contexto activo: «la calidad de las respuestas se degrada a medida que crece la conversación». Su API admite tanto la compactación solicitada por la aplicación como la que se activa al alcanzar un umbral de tokens configurado.

Diseña el registro de continuidad en función de lo que exige la siguiente acción. En el ejemplo del incidente, conserva el objetivo actual, la causa confirmada, la solución provisional descartada y el motivo del descarte, las incertidumbres pendientes, la ubicación de las fuentes y la siguiente acción. Mantén los identificadores o el texto exactos cuando de ellos dependa la corrección del resultado.

Un registro insuficiente dice: «Se investigó el problema y se avanzó». Uno útil dice: «La solución provisional se descartó porque rompe el comportamiento requerido; la corrección aceptada está registrada en el documento del incidente; la verificación sigue pendiente». El segundo permite continuar sin volver a contar toda la investigación.

El límite: un resumen puede eliminar un detalle que más adelante resulte importante. Mantén accesible el registro original y evalúa si el agente que retoma el trabajo todavía puede responder las preguntas que dependen de ese detalle. Guardar un estado persistente y elegir qué volver a cargar son tareas distintas; las explicamos en la guía sobre la memoria de los agentes.

Recupera la evidencia cuando la tarea la necesite

Conserva referencias a las fuentes extensas y carga las partes pertinentes cuando hagan falta. Anthropic lo describe como contexto justo a tiempo: el agente puede guardar rutas de archivos, consultas o enlaces y recuperar después el material que necesite. Recomendaciones sobre recuperación de contexto.

En un agente de gestión de incidentes, empieza por el registro del incidente actual y la documentación del servicio que corresponda. Recupera un incidente anterior cuando el diagnóstico lo requiera. Devuelve cada pasaje con su fuente, versión o fecha cuando estén disponibles, y con suficiente texto alrededor para interpretar una excepción.

El límite: la recuperación puede omitir la cláusula decisiva o devolver una coincidencia plausible pero desactualizada. Comprueba que la evidencia necesaria esté presente antes de medir la calidad de la respuesta. Ofrece al agente una forma de ampliar la búsqueda o leer la fuente completa cuando un extracto no permita resolver la cuestión.

Un conjunto de resultados más pequeño solo es útil si conserva lo que la decisión necesita. «Recuperar en vez de meterlo todo» es un criterio de selección, no una instrucción para ocultar contexto incómodo.

Asigna a los subagentes tareas acotadas y contextos limpios

Usa un contexto separado para las exploraciones cuyos resultados en bruto no necesita el agente principal. La documentación de subagentes de Claude Code de Anthropic describe agentes que trabajan en sus propias ventanas de contexto y devuelven los resultados a la conversación principal.

Un subagente que investiga un registro puede recibir la pregunta concreta, los detalles pertinentes del servicio y una referencia al registro. Pídele que devuelva el hallazgo, la ubicación de la evidencia que lo respalda, la incertidumbre y cualquier dependencia sin resolver. El agente principal podrá usar ese resultado sin cargar con todo el recorrido de la búsqueda.

El límite: el aislamiento también elimina conocimiento compartido. Incluye las restricciones que el subagente necesita y exige que aporte evidencia junto con su conclusión. Comprueba qué información le transmite realmente tu marco de orquestación: copiar todo el historial del agente principal anularía la separación buscada. Pegar de nuevo todas las conversaciones de los subagentes en la conversación principal vuelve a acumular allí el material innecesario.

Usa este patrón para investigaciones que puedan separarse. Una decisión cuyos elementos estén estrechamente relacionados y dependan de un registro compartido puede ser más fácil de resolver en el contexto principal con recuperación selectiva de información.

Ordena los documentos y la solicitud actual con un criterio claro

Haz que la tarea actual se distinga fácilmente del material que la respalda. Las recomendaciones de Anthropic para prompts con contexto largo aconsejan situar los documentos extensos cerca del inicio del prompt, distinguir sus fuentes y colocar la consulta después. También recomiendan localizar las citas pertinentes antes de responder preguntas sobre documentos.

En tu aplicación, mantén las instrucciones que rigen el comportamiento en el canal de instrucciones que les corresponde. Dentro de la entrada de la tarea, identifica por separado el registro del incidente actual y las notas históricas; después, expresa con claridad la pregunta y la salida requerida. Cambiar de sitio un texto recuperado no debe convertirlo en una instrucción que gobierne el comportamiento.

El límite: reorganizar el contexto no recupera evidencia que nunca se cargó, y ningún orden garantiza buenos resultados en todos los modelos y tareas. Compara distintas disposiciones con tus propios ejemplos. Evita repetir un reglamento completo en cada turno cuando baste con una formulación breve y actualizada de la tarea.

Devuelve resultados selectivos sin perder acceso a la salida completa

Devuelve el resultado necesario para la siguiente decisión y una vía de acceso al archivo o resultado completo. La guía de diseño de herramientas de Anthropic recomienda respuestas con información útil y controles como filtros, paginación y truncamiento. Por otra parte, su documentación sobre edición de contexto describe cómo eliminar del historial los resultados antiguos de herramientas.

Si una comprobación falla, devuelve el fallo, el fragmento pertinente del error y la ubicación del informe guardado. Si se trata de una búsqueda, devuelve los pasajes relevantes y sus fuentes. Si una operación termina correctamente, devuelve el estado y los identificadores necesarios para continuar. Evita incorporar el informe completo solo porque la herramienta lo haya generado.

El límite: truncar a ciegas puede eliminar el error decisivo o un matiz importante. Indica qué se ha omitido y permite que el agente pida más información. Conserva la salida completa fuera del contexto activo cuando vaya a ser necesario revisarla.

Estas decisiones corresponden a la capa que prepara las solicitudes. La guía de ingeniería de contexto explica de forma más amplia cómo encajan las instrucciones, la memoria, las herramientas y el material recuperado.

¿Qué se exagera sobre el context rot?

No existe un número universal de mensajes ni un porcentaje de la ventana que indique a todos los agentes cuándo deben reiniciar el contexto. Un umbral que evita una solicitud demasiado grande es un ajuste de capacidad. El punto en el que un flujo de trabajo concreto pierde fiabilidad debe medirse con sus tareas reales.

Tampoco toda mala respuesta en un chat largo demuestra que haya context rot. La falta de evidencia, las instrucciones contradictorias, una herramienta averiada o una tarea que el sistema no puede realizar pueden producir síntomas parecidos. Un informe de incidente útil identifica la decisión que falló y registra lo que recibió el modelo.

La compactación pierde información, y la memoria externa no garantiza relevancia por sí sola. Trata ambas como componentes cuyos resultados necesitan comprobaciones. Conservar con mayor eficiencia una conclusión incorrecta puede hacer que un flujo de trabajo se equivoque de manera sistemática.

Por último, el uso de caché es una intervención distinta. Una caché KV reutiliza cálculos de atención; no decide qué documento importa ni elimina el historial obsoleto. Una solicitud con un uso eficiente de la caché puede seguir conteniendo material inadecuado para la siguiente decisión.

Una lista breve para ponerlo en práctica esta semana

Aplica estos pasos a un agente que presente un fallo recurrente:

  • Captura la entrada real en el momento de la decisión fallida e identifica la evidencia que necesitaba.
  • Reproduce la tarea con la evidencia pertinente y sin cambiar los requisitos; compara la corrección de los resultados en casos representativos.
  • Sustituye la respuesta de herramienta con más ruido por un extracto relevante y una referencia al resultado completo.
  • Define un registro de continuidad para la compactación que conserve decisiones, enfoques descartados, restricciones, fuentes y trabajo pendiente.
  • Aísla una investigación que pueda separarse en el contexto limpio de un subagente, si la exploración es la que está acumulando material innecesario.
  • Pon el cambio en producción solo si el flujo, al retomarse, conserva los datos necesarios y mejora el fallo que buscas corregir; mantén disponible el comportamiento anterior para poder restaurarlo.

Empieza por el fallo que puedas reproducir. Así el cambio tendrá una prueba de aceptación clara, en lugar de medir el éxito por tener «menos contexto».

Preguntas frecuentes sobre context rot

¿Sigue existiendo el context rot?

La documentación actual de Anthropic sobre compactación sigue describiendo de forma explícita una degradación de la calidad de las respuestas a medida que crecen las conversaciones. Esto respalda la necesidad de seguir gestionando el contexto; no determina cómo rinde cada modelo actual. Evalúa el modelo y el flujo de trabajo que pongas en uso.

¿Cómo evitar el context rot?

Conserva las instrucciones vigentes y la evidencia necesaria, elimina el material obsoleto o redundante, compacta el historial con cuidado y recupera los detalles cuando hagan falta. Aísla las tareas secundarias que generen mucho ruido cuando resulte útil. Verifica que cada cambio mantenga los datos necesarios para la siguiente acción.

¿Qué causa el context rot?

La longitud del contexto, la relevancia del material que rodea a la información y la forma de presentarla pueden afectar a la fiabilidad. El estudio original no establece un único mecanismo subyacente. En un agente, revisa la evidencia recibida y el estado del trabajo antes de elegir una solución.

Suscríbete al boletín para recibir guías prácticas sobre cómo crear y operar flujos de trabajo con IA.

Publicado
Categoría
Build
Artículos relacionados
Agentes de IA: cómo funciona su bucle y cuándo detenerlo

Agentes de IA: cómo funciona su bucle y cuándo detenerlo

Descubre cómo funciona el bucle de los agentes de IA: llamadas al modelo, herramientas, condiciones de parada y controles para evitar ejecuciones sin fin.24 oct 2026Build
Programar con IA: cómo trabajar con agentes y qué delegar

Programar con IA: cómo trabajar con agentes y qué delegar

Aprende a programar con IA mediante agentes: cómo funcionan Claude Code, Codex, Cursor y Copilot, qué delegar y cómo verificar cada cambio antes de aceptarlo.24 oct 2026Build
Búsqueda híbrida con BM25: combina vectores y mide el resultado

Búsqueda híbrida con BM25: combina vectores y mide el resultado

Combina BM25 y búsqueda vectorial con RRF o puntuaciones ponderadas. Aprende a implementarlo en tu base actual y a medir recall con consultas etiquetadas.24 oct 2026Build
Mezcla de expertos: qué revelan los parámetros activos y totales

Mezcla de expertos: qué revelan los parámetros activos y totales

Cómo funciona la mezcla de expertos (MoE), qué diferencia los parámetros activos de los totales y qué implica al usar una API o alojar el modelo por tu cuenta.24 oct 2026Build
LLM evaluation: valida cada cambio antes de publicar

LLM evaluation: valida cada cambio antes de publicar

Aplica la evaluación de LLM con un ejemplo de 20 casos: define criterios, mide la versión actual y valida cada cambio antes de aprobar una nueva versión.24 oct 2026Build
Tokens por segundo: mide la velocidad real de un LLM

Tokens por segundo: mide la velocidad real de un LLM

Aprende a medir los tokens por segundo de un LLM, la espera hasta el primer token y la latencia total para comparar proveedores con las tareas de tu aplicación.24 oct 2026Build
LLMOps en producción: qué controlar y por dónde empezar

LLMOps en producción: qué controlar y por dónde empezar

Qué es LLMOps, cómo se diferencia de MLOps y qué controles de evaluación, trazas, permisos y recuperación necesita una aplicación con LLM en producción.23 oct 2026Build
Salidas estructuradas: cómo usarlas en OpenAI, Claude y Gemini

Salidas estructuradas: cómo usarlas en OpenAI, Claude y Gemini

Aprende a usar salidas estructuradas en OpenAI, Claude y Gemini: límites de los esquemas, extracción de facturas, validación, reintentos y streaming.23 oct 2026Build
Newsletter

Una carta, cada domingo.Sistemas que funcionan, no opiniones calientes.

Semanal. Sin spam. Cancele cuando quiera.