¿Qué es el Context Rot en modelos de lenguaje?
El Context Rot es el fenómeno por el cual el rendimiento de un modelo de lenguaje (LLM) decae de forma no lineal a medida que aumenta la longitud del contexto de entrada. Un estudio reciente de Chroma evaluando 18 LLMs confirma que añadir más tokens no mejora la precisión, sino que introduce ruido y aumenta el coste computacional.
En esta edición te explico el benchmark que demuestra el problema y el patrón de Progressive Disclosure (estandarizado por Microsoft y Anthropic) para resolverlo.
Esta semana
Cada vez que añades más contexto a tu agente, se vuelve más lento y menos preciso. No es un bug: es el Context Rot.
En esta edición mostramos el dato concreto de 18 LLMs que demuestra el fenómeno, y el patrón de 3 tiers que Microsoft y Anthropic ya están estandarizando para resolverlo.
Te lo explico con el ejemplo real de Chroma, que lo descubrieron por las malas.
Contexto Rot
Un estudio de Chroma acaba de demostrar algo que cualquiera que construya agentes con IA lleva meses intuyendo: cuanto más texto le metes a un modelo, menos preciso se vuelve.
No es que el modelo "se confunde". Es un efecto arquitectural medible. Los investigadores de Chroma evaluaron 18 LLMs (GPT-4.1, Claude 4, Gemini 2.5, Qwen3, Llama 4) y encontraron que el rendimiento decae de forma no lineal a medida que crece la longitud del input. Esto se llama Context Rot: a medida que aumentan los tokens en el contexto, la capacidad del modelo para recuperar información de ese contexto de forma precisa disminuye.
El benchmark Needle-in-a-Haystack que todos conocemos ya no es suficiente para medir la capacidad de contexto. Los modelos son buenos recuperando frases exactas en texto largo, pero se vuelven inconsistentes en tareas semánticas reales: resumir, razonar, comparar. Y esas son las tareas que importan cuando un agente trabaja sobre código, documentación o datos de producción.
La consecuencia directa es que un contexto más grande no es un contexto mejor. Es un contexto más caro y más ruidoso.
Lo que hice esta semana fue implementar un sistema de Skills con Progressive Disclosure, un patrón que Microsoft está estandarizando en su repositorio agent-skills. La idea es simple pero contraintuitiva: tu agente no necesita saberlo todo desde el minuto cero. Necesita saber solo lo que necesita para la tarea actual, y tener un camino claro para obtener más detalle cuando lo pida.
El sistema tiene 3 niveles de carga:
Tier 1 — Metadata (~50-100 tokens por skill, siempre en contexto): el name y description del SKILL.md en YAML frontmatter. Esto es lo que el agente escanea al inicio de la sesión. La descripción es el trigger: contiene keywords que el agente compara contra la tarea del usuario para decidir si la skill es relevante.
Tier 2 — Instructions (~500-2000 tokens, se carga solo al activar la skill): el cuerpo del SKILL.md. Las instrucciones detalladas, ejemplos, patrones. El agente solo lo lee cuando la descripción del Tier 1 indica que es necesario.
Tier 3 — Resources (se carga solo si el agente lo pide explícitamente): archivos de referencia en subdirectorios (references/, scripts/, assets/). El SKILL.md los referencia con links, pero el contenido no se inyecta hasta que el agente lo solicita.
Esto no es un capricho de organización. Anthropic lo llama Context Engineering y lo define como el arte y la ciencia de seleccionar qué entra en la ventana de contexto limitada. Los LLMs tienen un "attention budget" finito: cada token irrelevante en el prompt resta capacidad de atención para la tarea real. La arquitectura transformer crea relaciones n² entre tokens — si tienes 10.000 tokens, el modelo procesa 100 millones de relaciones entre pares. La mayoría son ruido.
El contraste es brutal. Ardalis (Steve Smith) documenta el patrón "Bad" vs "Good" con un ejemplo concreto: un AGENTS.md de 1000+ líneas que carga instrucciones de build, código, dominio, testing y API en cada sesión — incluso cuando el agente solo necesita cambiar un typo en un README — versus un sistema de skills modulares donde cada skill carga solo lo suyo.
La métrica que importa no es cuánta información tiene el agente. Es la proporción signal-to-noise.
El resultado práctico es que mi agente de Community no lee 50 páginas de manual del producto cuando le pregunto por una feature específica. Lee 100 tokens de metadata, encuentra la skill correcta, carga 800 tokens de instrucciones relevantes y listo. El resto del contexto permanece en disco, accesible pero invisible.
El agente más inteligente no es el que tiene más contexto, es el que tiene el contexto correcto en el momento correcto. Y eso no se resuelve con modelos de 1M de tokens — se resuelve con disciplina de ingeniería de contexto.
Nota sobre X y Grok: Mientras optimizo agentes locales, sigo analizando cómo X está integrando Grok en su timeline. Parece que la búsqueda semántica nativa de la plataforma está cambiando la forma en que los agentes deben buscar información en tiempo real. Voy a seguir de cerca cómo evoluciona esta integración y si afecta al algoritmo de distribución de contenido.
🛠️ Herramienta de la semana: ClaudeMD Score
Lo construí para resolver un problema que me molestaba: evaluar si un CLAUDE.md estaba bien escrito o era un amasijo de instrucciones redundantes. Pegas el archivo y te da un score por categorías con valoración y problemas concretos.
Lo uso a diario antes de integrar cualquier nuevo CLAUDE.md en un proyecto. No es perfecto — a veces se obsesiona con la longitud — pero te ahorra 10 minutos de revisión manual.
Útil para: quien trabaja con múltiples proyectos y quiere mantener sus CLAUDE.md bajo control.
No es útil para: quien solo usa un proyecto y un solo modelo.
Antes de cerrar
Si esta semana aprendiste algo sobre tu propio stack, compártelo. Me interesa más tu caso concreto que cualquier benchmark.
Respóndeme con una sola línea: ¿Cuántas líneas tiene tu CLAUDE.md o prompt principal y qué patrón usas para no pasarte?
→ Solo tienes que responder a este email.
P.D. — Si tienes 100+ líneas y no las has segmentado, probablemente estás perdiendo precisión sin saberlo.
Preguntas frecuentes sobre sistemas de agentes IA para marketing
¿Qué es el Context Rot?
El Context Rot es el fenómeno por el cual el rendimiento de un LLM decae de forma no lineal a medida que crece la longitud del input. Un benchmark de Chroma sobre 18 modelos (GPT-4.1, Claude 4, Gemini 2.5, Qwen3, Llama 4) confirma que añadir tokens no mejora la precisión — la reduce. El modelo procesa más relaciones entre pares de tokens, la mayoría irrelevantes, y pierde capacidad de atención para la tarea real.
¿Qué es el patrón Progressive Disclosure para agentes IA?
Progressive Disclosure es un patrón de carga de contexto en 3 niveles. El Tier 1 carga solo metadata de la skill (~100 tokens, siempre visible). El Tier 2 carga las instrucciones completas (~500-2000 tokens) solo cuando la skill es activada. El Tier 3 carga archivos de referencia únicamente si el agente los solicita explícitamente. El agente tiene acceso a todo, pero solo procesa lo que necesita para la tarea actual.
¿Cómo optimizar el contexto de un agente IA sin perder precisión?
Separar el contexto en capas con carga selectiva. En lugar de inyectar todas las instrucciones al inicio de cada sesión, usar un sistema de skills donde cada archivo tiene un name y description cortos (Tier 1) que el agente usa para decidir si carga el resto. Anthropic llama a este enfoque Context Engineering: curar activamente qué entra en la ventana de contexto en cada llamada.
¿Qué modelos fueron evaluados en el benchmark de Chroma sobre Context Rot?
El estudio de Chroma evaluó 18 LLMs incluyendo GPT-4.1, Claude 4, Gemini 2.5, Qwen3 y Llama 4. El hallazgo es consistente entre familias de modelos: el rendimiento en tareas semánticas (resumir, razonar, comparar) decae de forma no lineal al crecer el input, aunque los modelos mantengan buena precisión en recuperación de frases exactas.
¿Qué es el Context Engineering según Anthropic?
Anthropic define Context Engineering como el arte y la ciencia de seleccionar qué información entra en la ventana de contexto limitada de un LLM. La premisa es que los modelos tienen un "attention budget" finito: cada token irrelevante reduce la capacidad de atención disponible para la tarea real. El objetivo no es maximizar el contexto — es maximizar la proporción de señal respecto al ruido.
¿Qué es Gradiente y para quién es?
Gradiente es una newsletter semanal en español sobre inteligencia artificial aplicada, escrita por Agustín Ruíz (@agusbuilds), ingeniero de software con más de 10 años de experiencia. Cada edición documenta en tiempo real la construcción de productos con IA: sistemas de agentes, automatización de marketing, apps y herramientas. Para desarrolladores, makers y emprendedores hispanohablantes que construyen con IA y valoran la transparencia sobre el hype.