Context rot en LLMs: RAG vs contexto largo en 2026

Qué es el context rot en los LLM

El context rot es la caída medida de la precisión de un modelo de lenguaje grande a medida que crece su entrada, mucho antes de que la ventana de contexto se llene. Se debe a que la atención se reparte entre más tokens, a distractores que se parecen a la respuesta y a un entrenamiento que rara vez premia el razonamiento con longitudes extremas. La solución es enviar menos: recuperar y reordenar, borrar la salida obsoleta de las herramientas, compactar o reiniciar las sesiones largas, y medir tu propio presupuesto seguro en lugar de fiarte de la ficha técnica.

Chroma Research le puso números en 18 modelos en julio de 2025, y el término se ha popularizado tanto que la propia documentación de Anthropic ya lo define: "A medida que crece el número de tokens, la precisión y el recall se degradan, un fenómeno conocido como context rot". Una ventana anunciada más grande sube el techo de lo que puedes enviar. No promete la misma precisión en lo más alto de ese rango que en lo más bajo.

La versión práctica, para quien tenga que decidir qué construir: la ventana de contexto documentada es lo que se te permite enviar. Tu ventana utilizable es hasta donde el modelo sigue cumpliendo tu listón de calidad. Son dos números distintos, y el segundo suele ser una fracción del primero.

Esa brecha explica por qué envejeció mal el argumento que circuló por los canales de ingeniería a finales de 2024 y principios de 2025 ("RAG ya es obsoleto, pega todo dentro"). Las ventanas sí llegaron. Anthropic hace de 1M de tokens la ventana por defecto en Claude Opus 5.5, Sonnet 5.5 y el nuevo Haiku 5.5. Los modelos GPT-6 de OpenAI tienen una ventana de 1.05M, de la que 922K pueden ser de entrada. Gemini 3.1 Pro y Gemini 3.8 Flash de Google aceptan alrededor de 1M de tokens de entrada. Llama 4 Scout de Meta documenta 10M. Lo que no llegó fue un modelo que use igual de bien cada parte de su ventana.

Así que la pregunta interesante dejó de ser "cuál gana" y pasó a ser "qué patrón encaja con esta forma de datos, este presupuesto de latencia, este requisito de frescura y esta factura". Eso es lo que responde el resto de este artículo, empezando por lo que midió la investigación y por cómo corregirlo.

---

Qué mostró la investigación de Chroma sobre el context rot

El titular ("el context rot existe") no le hace justicia al trabajo. En Context Rot: How Increasing Input Tokens Impacts LLM Performance, un informe técnico publicado el 14 de julio de 2025 y el estudio al que casi todo el mundo se refiere cuando habla de "el artículo sobre el context rot", Kelly Hong, Anton Troynikov y Jeff Huber ejecutaron experimentos controlados sobre 18 modelos: Claude Opus 4, Sonnet 4, Sonnet 3.7, Sonnet 3.5 y Haiku 3.5; o3, GPT-4.1 con sus versiones mini y nano, GPT-4o, GPT-4 Turbo y GPT-3.5 Turbo; Gemini 2.5 Pro, 2.5 Flash y 2.0 Flash; y tres tamaños de Qwen3. No todos los modelos participaron en todos los experimentos, por límites de ventana y de presupuesto de razonamiento. Su kit de replicación en GitHub permite volver a ejecutarlo.

Cuatro hallazgos importan para la arquitectura.

El rendimiento se degrada de forma desigual según crece la entrada. Si has venido buscando la gráfica del context rot, la forma es justo el mensaje: no hay una sola curva. El propio resumen de Chroma es que los modelos "no usan su contexto de manera uniforme; en cambio, su rendimiento se vuelve cada vez menos fiable a medida que crece la longitud de la entrada". Con qué rapidez ocurre, y dónde, depende del modelo y de la tarea, y por eso una comprobación puntual con un tamaño de contexto no te dice casi nada del comportamiento con otro. El equipo de ingeniería de Anthropic describe el mismo patrón como "un gradiente de rendimiento más que un precipicio abrupto".

La magnitud de la caída es grande. En LongMemEval, un benchmark de preguntas y respuestas conversacionales, el equipo redujo el conjunto a 306 prompts y comparó dos versiones de cada uno. La versión enfocada contiene solo el material relevante y promedia unos 300 tokens. La versión completa entierra esa misma respuesta en la conversación circundante y promedia unos 113K tokens. El rendimiento se degradó de forma sistemática en las versiones completas. Los modelos Claude mostraron la brecha más amplia, y Chroma atribuye buena parte de ella a la abstención: Claude Opus 4 y Sonnet 4 a menudo se negaban a responder en lugar de aventurar una respuesta. Misma pregunta, mismo modelo, misma respuesta presente en la entrada. El cambio principal fue cuánto texto irrelevante venía con ella.

La similitud condiciona la caída. Cuando la aguja se parece menos semánticamente a la pregunta (Chroma lo midió con similitud de embeddings), la precisión cae más rápido a medida que crece la entrada. Los distractores que se parecen a la respuesta también perjudican: incluso uno solo reduce el rendimiento frente a la línea base con la aguja sola, y cuatro lo agravan. La posición, en cambio, apenas influyó en esta tarea. Chroma no vio variaciones notables entre 11 posiciones de la aguja, aunque Liu et al. (2024), "Lost in the Middle", en TACL encontró una curva en forma de U en preguntas y respuestas sobre varios documentos, donde el centro de un contexto largo queda sistemáticamente infraponderado.

El relleno coherente perjudicó más que el relleno barajado. Este es el resultado que debería cambiar cómo piensan los ingenieros. La intuición dice que en un pajar coherente debería ser más fácil buscar que en uno desordenado. Chroma encontró lo contrario, de forma consistente, en los 18 modelos: barajar las frases del pajar y destruir su flujo lógico mejoró el rendimiento. Por qué ocurre eso sigue abierto, y Chroma solo llega a decir que la estructura de una entrada podría influir en cómo se aplica el mecanismo de atención. La parte accionable no necesita mecanismo: un relleno coherente y sobre el mismo tema no es automáticamente inofensivo.

Un detalle más que conviene llevarse a producción: los modos de fallo son específicos de cada modelo. Bajo distractores, los modelos Claude mostraron las tasas de alucinación más bajas, con Claude Sonnet 4 y Opus 4 especialmente conservadores y propensos a abstenerse ante la incertidumbre, mientras que los modelos GPT mostraron las más altas y tendieron a responder con seguridad y equivocarse. Si estás eligiendo entre ellos, en parte estás eligiendo qué fallo prefieres depurar.

Chroma no es el único equipo que mide esto. Si buscas un benchmark de context rot que se parezca a tu carga de trabajo, estos son los principales:

Esa última fila es la que hay que recordar: incluso cuando un modelo recupera a la perfección todos los pasajes relevantes, una entrada más larga sigue costando precisión.

Para una introducción más accesible, Hamel Husain invitó a Kelly Hong a repasar la investigación y publicó un resumen anotado de esa charla. Sus conclusiones coinciden con las del informe: el rendimiento no es uniforme entre longitudes de contexto, la forma de presentar la información importa y la ingeniería de contexto deliberada es la palanca.

---

Por qué falla el contexto largo: el mecanismo

El mecanismo importa porque predice qué cargas de trabajo se rompen.

La atención de un transformer ejecuta un softmax sobre pares de tokens. Según crece la longitud de la secuencia, la atención se reparte entre más posiciones. Incluso con codificaciones de posición relativas como RoPE o ALiBi, el denominador del softmax crece y el peso disponible para cualquier token individual se encoge. Con 1M de tokens, el token correcto compite con otros 999,999 por un presupuesto finito. Los ingenieros de Anthropic lo llaman un "presupuesto de atención": "Cada nuevo token que se introduce merma este presupuesto en cierta medida".

Las codificaciones de posición estiran el rango sin eliminar el problema. RoPE se degrada al extrapolar muy por encima de la longitud de entrenamiento, así que un modelo entrenado con secuencias de 32K y desplegado a 1M está haciendo una extrapolación que las matemáticas subyacentes no respaldan del todo. Meta, por ejemplo, preentrenó y postentrenó Llama 4 Scout a 256K y documenta una ventana de 10M, así que todo lo que pasa de 256K se apoya en la generalización de longitud. YaRN, la interpolación de posiciones y el escalado NTK-aware ayudan, y ninguno produce un modelo que use 1M de tokens tan bien como usa 32K.

También hay un problema de datos de entrenamiento. Incluso cuando un modelo entrena con secuencias largas, los ejemplos que exigen razonamiento genuino a lo largo de 800K tokens son escasos. Los modelos aprenden a usar las partes del contexto que sus datos de entrenamiento les enseñaron a usar.

Así que el context rot es una propiedad de la arquitectura y de la distribución de entrenamiento, no un bug que parchee la siguiente versión. Los modelos futuros empujarán la frontera más lejos, y la forma de la degradación persistirá.

---

Terminación prematura: lo que añadió la investigación de 2026

El resultado nuevo más útil desde que se publicó por primera vez este artículo salió del trabajo con agentes de horizonte largo, no de los benchmarks.

En Diagnosing and Mitigating Context Rot in Long-horizon Search, publicado por primera vez en junio de 2026 y revisado a fondo en agosto, Shijie Xia, Yikun Wang, Zhen Huang y Pengfei Liu estudiaron cuatro modelos insignia de pesos abiertos (GLM-4.7, GLM-5.0, Qwen3.5-397B-A17B y MiniMax-M2.5) en tres benchmarks de búsqueda profunda: BrowseComp, xbench-DeepSearch y BrowseComp-Plus, que busca en un corpus local fijo. Los modelos cerrados quedaron fuera porque sus trazas de razonamiento están cifradas. La versión revisada le pone nombre a un modo de fallo que la literatura anterior había pasado por alto: la terminación prematura. Con un contexto grande, los modelos se rinden, o devuelven una respuesta incorrecta que marcan como incierta, mucho antes de haber agotado la ventana. Controlando por la dificultad de la consulta, los autores encontraron que la tasa de terminación prematura sube con la longitud del contexto.

Eso replantea el problema. El context rot cubre dos fallos distintos, y necesitan arreglos diferentes. Si el modelo ya no encuentra la aguja, hay que mejorar la precisión. Si el modelo deja de buscar, necesita espacio y motivo para seguir explorando. Para un agente que hace búsqueda en varios pasos, confundirlos cuesta semanas.

Su segundo hallazgo es el que hay que robar. Probaron siete métodos de gestión de contexto en tres familias (compactación, recorte y aislamiento mediante subagentes) y concluyeron que esos métodos funcionan sobre todo como estrategias de escalado en tiempo de inferencia: al reducir la tasa de terminación prematura, le compran al modelo más exploración. Qué familia ayuda depende del modelo. En el modelo agéntico más fuerte de los que compararon, Qwen3.5-397B-A17B, aislar el trabajo en subagentes fue lo que mejor puntuó. En el más débil, GLM-4.7, los subagentes estuvieron entre las peores opciones, y quedarse solo con los últimos resultados de herramientas más un resumen dio el mejor equilibrio entre precisión y coste. Los autores además construyeron una estrategia de filtrado consciente del comportamiento para el muestreo en paralelo que subió la precisión media entre 2.6 y 4.9 puntos porcentuales en tres métodos de agregación.

Si ejecutas agentes en sesiones largas, mide con qué frecuencia abandonan antes de tiempo. Es una métrica barata y casi nadie la instrumenta.

Otros tres preprints de 2026, publicados entre julio y principios de octubre, empujan en la misma dirección. Context as an Environment guarda las salidas de las herramientas como variables en una sesión de Python persistente y solo deja entrar en el contexto lo que el agente imprime; con el mismo modelo Qwen3.8-Max por debajo, obtuvo un 86.7 por ciento en el benchmark LOCA a 256K tokens, frente al 65.3 por ciento de un agente que resume su historial. Stateless Language Agents reconstruye el contexto en cada llamada a partir del estado que conserva el entorno de ejecución del agente, en lugar de arrastrar la conversación, y en optimización de kernels alcanzó el rendimiento final de la línea base más fuerte con más de un 84 por ciento menos de tokens. Y CompactionRL trata la compactación como una habilidad que hay que entrenar y no como una función que se añade a posteriori: su modelo GLM-4.5-Air puntuó 6.6 puntos más en SWE-bench Verified que el mismo modelo base con compactación añadida en tiempo de inferencia. Son preprints, pero coinciden en la dirección: mantén pequeño el conjunto de trabajo y haz que el modelo sea bueno manteniéndolo pequeño.

---

Cómo corregir el context rot en agentes y herramientas de chat

Todas las soluciones que funcionan hacen lo mismo: ponen delante del modelo menos tokens y mejores. El equipo de ingeniería de Anthropic lo dice en una línea en Effective context engineering for AI agents: "El contexto, por tanto, debe tratarse como un recurso finito con rendimientos marginales decrecientes". Lo que cambia es dónde aplicas la regla.

Si construyes aplicaciones o agentes con LLM:

• Envía menos, y elígelo bien. Recupera, reordena y descarta lo que la tarea no necesita. La guía de contexto largo de Google dice lo mismo: "En general, si no necesitas pasarle tokens al modelo, lo mejor es evitar pasárselos".
• Pon primero los documentos largos y la pregunta al final. Para entradas de 20K tokens o más, la guía de prompting de Anthropic recomienda los documentos arriba y la consulta al final, y señala que las consultas al final "pueden mejorar la calidad de la respuesta hasta en un 30 por ciento en las pruebas". También sugiere pedirle al modelo que cite los pasajes relevantes antes de responder. Google da el mismo consejo de colocación para Gemini.
• Borra los resultados de herramientas obsoletos. Los resultados de búsqueda antiguos y los volcados de ficheros son los tokens más baratos de eliminar. Anthropic llama al borrado de resultados de herramientas "una de las formas de compactación más seguras y menos invasivas" y lo ofrece como edición de contexto, que por defecto empieza a borrar a los 100,000 tokens de entrada y conserva los tres usos de herramientas más recientes.
• Compacta antes de que la ventana se llene, y pon a prueba el resumen. La API de Anthropic ofrece compactación por umbral (disparo por defecto: 150,000 tokens de entrada) y, desde septiembre de 2026, compactación bajo demanda. La Responses API de OpenAI compacta en el servidor cuando defines un compact_threshold dentro de context_management, y además expone un endpoint de compactación independiente. Un resumen pierde información, así que comprueba qué descarta. El consejo de Anthropic es empezar maximizando el recall y luego recortar lo superfluo.
• Mantén las reglas y el estado fuera del resumen. The Compaction Cliff in Long-Running AI Agent Memory, un artículo de CIKM 2026 publicado en arXiv en agosto, encontró que el prompt de compactación de Claude Code sobre Sonnet 4.6 conservaba el 53 por ciento de las reglas de seguridad de configuraciones de agentes en producción tras una ronda y el 10 por ciento tras cinco. La solución de los autores fija textualmente las reglas de seguridad y los procedimientos y comprime el resto por tipo, y mantuvo un recall del 96 por ciento a lo largo de cinco rondas. Así que fija las reglas donde el agente las vuelva a leer, y guarda el progreso en notas, en una herramienta de memoria o en git en lugar de en el historial del chat.
• Delega la exploración en subagentes. Un subagente gasta su propio contexto en la búsqueda y devuelve "un resumen condensado y destilado de su trabajo (a menudo de 1,000-2,000 tokens)", en palabras de Anthropic. Eso sí, pruébalo con tu modelo: en el artículo sobre la terminación prematura, los subagentes puntuaron mejor en el más fuerte de los dos modelos comparados y entre los peores en el más débil. Explicamos cómo encajan los subagentes, las skills y los hooks en nuestra guía de ingeniería agéntica.
• Mide por tamaño de contexto. Puntúa tu propia evaluación con varias longitudes de entrada y registra los abandonos tempranos. Sin eso, cada una de las soluciones anteriores es una conjetura.

Anthropic ha publicado cifras de la combinación. En una evaluación interna de búsqueda agéntica, su herramienta de memoria junto con la edición de contexto mejoró el rendimiento un 39 por ciento sobre la línea base, y la edición de contexto sola, un 29 por ciento. En una prueba de búsqueda web de 100 turnos, la edición de contexto redujo el consumo de tokens en un 84 por ciento. Son cifras de un proveedor sobre su propio producto, así que léelas como una dirección y no como una promesa.

Si usas asistentes de chat o agentes de programación:

• Un chat por tarea. La guía de buenas prácticas de Claude Code dice: "Una sesión limpia con un prompt mejor casi siempre supera a una sesión larga con correcciones acumuladas". La guía de Codex de OpenAI coincide: "Mantén un chat por cada unidad de trabajo coherente".
• Reinicia tras dos correcciones fallidas. Es la regla práctica del propio Claude Code: ejecuta /clear y escribe un primer prompt mejor que incluya lo que has aprendido.
• Compacta cuando tú lo decidas. Claude Code, Codex y Cursor resumen automáticamente cerca del límite. Compactar antes con una instrucción de enfoque (por ejemplo, /compact Focus on the API changes) te permite influir en lo que sobrevive. Claude Code advierte de que "las instrucciones detalladas del principio de la conversación pueden perderse", así que las reglas persistentes van en un fichero que el agente vuelva a leer, como CLAUDE.md, no en el chat.
• Vigila el contador. /context en Claude Code muestra qué está llenando la ventana, y /status en Codex muestra cuánta has usado. Cursor pone junto al cuadro de entrada un anillo de contexto que, al hacer clic, abre un desglose.

Los comandos y los valores por defecto cambian entre versiones, así que toma la tabla como válida a octubre de 2026 y revisa la documentación de tu herramienta después de cada actualización.

---

Dónde sigue ganando RAG

Con todo lo anterior, la generación aumentada por recuperación se sigue ganando su sitio. Aquí es donde sigue venciendo.

Corpus multidocumento a escala. Si tu base de conocimiento son 50,000 documentos que suman 500M de tokens, no cabe en ninguna ventana. La recuperación es la única arquitectura viable.

Frescura y actualidad. Los almacenes vectoriales se actualizan de forma incremental. Un prompt de contexto largo hay que reconstruirlo cada vez que el contenido cambia. Para cualquier cosa que se actualice cada hora (noticias, catálogos, tickets de soporte, código), la recuperación absorbe el cambio de forma barata.

Coste. El coste de entrada escala con los tokens de entrada, y por encima de ciertos umbrales escala peor que linealmente. Si el 95 por ciento de tus consultas se pueden responder con 5K tokens relevantes, la recuperación sale muchas veces más barata sin pérdida de precisión.

Citas y procedencia. La recuperación te entrega una lista estructurada de fuentes que puedes mostrar, enlazar y ordenar, mientras que anclar una respuesta de contexto largo a fuentes concretas exige fontanería adicional. Es la misma razón por la que una herramienta de lectura que conserva el pasaje y su fuente le gana a una que conserva un resumen: cuando haces preguntas sobre todo lo que has guardado en Glasp, cada respuesta puede apuntar de vuelta a la fuente de la que salió.

Control de acceso y multiinquilino. Si tu corpus tiene visibilidad por usuario, por inquilino o por rol, no puedes volcarlo todo dentro. La recuperación filtra por política antes de que el modelo vea nada. Eso no es negociable en B2B.

Razonamiento entre corpus. Cuando la respuesta abarca un hilo de Slack, una página de Notion, un issue de Linear y un PR de GitHub, la recuperación es el puente.

Si marcas cualquiera de esas casillas, RAG no es opcional. La pregunta pasa a ser cómo hacer buena la recuperación, no si hacerla.

---

Dónde gana el contexto largo

El contexto largo tiene cargas de trabajo en las que es sencillamente la respuesta correcta.

Razonamiento profundo sobre un solo documento. Leer un contrato de 100 páginas y responder cruzando cláusulas. Analizar un artículo. Desmenuzar una conferencia de resultados. Cuando la respuesta conecta dos párrafos separados por 80 páginas, trocear suele cortar el vínculo.

Comprensión de código dentro de un repositorio. Muchas tareas de código necesitan imports, tipos, definiciones y puntos de llamada a la vez. Trocear por fichero pierde las relaciones entre ficheros.

Continuidad conversacional. Las sesiones largas de agente se benefician de tener historial real. La recuperación sobre el historial de conversación es frágil, porque normalmente necesitas los últimos 50 turnos, no los 50 más parecidos semánticamente.

Razonamiento exploratorio cuando todavía no conoces la consulta. Si no puedes escribir la consulta por adelantado, es difícil apuntar la recuperación. El contexto largo deja que el modelo hojee.

Referencias cruzadas dentro de una unidad coherente. Un capítulo de libro de texto, un artículo, un escrito jurídico. Trocear esto y volver a ensamblarlo tiende a perder el argumento.

Heurística aproximada: si tus datos son un único documento lógico y caben dentro de tu presupuesto seguro medido, el contexto largo es la arquitectura más limpia.

---

El patrón híbrido en el que acaba casi todo el mundo

La opción por defecto en 2026 para sistemas serios no es ni RAG puro ni contexto largo puro. Recupera un conjunto de tokens sustancial pero acotado, y luego razona sobre él.

User query
   |
   v
[Retrieval Stage]
   - Vector search (top 100 chunks)
   - Optional keyword/BM25 search merged in (hybrid retrieval)
   - Optional reranker (cross-encoder over top 100, keep top 30)
   |
   v
[Assembly Stage]
   - Concatenate retrieved chunks
   - Add metadata, source headers, structural hints
   - Target total: 50K to 200K tokens
   |
   v
[Long-Context Reasoning Stage]
   - Send to frontier model with reasoning prompt
   - Model uses the full retrieval set as its context
   |
   v
Answer + citations

Cada etapa cubre el modo de fallo de la otra. La recuperación reduce un corpus demasiado grande para cualquier ventana a algo manejable. Razonar sobre todo el conjunto recuperado restaura el razonamiento entre fragmentos que el RAG clásico de top-5 tira a la basura.

La decisión que sostiene el diseño es el tamaño del conjunto recuperado. Con pocos tokens has vuelto a construir un RAG de top-5. Con demasiados estás en la zona de degradación, pagando más por una respuesta peor. Una regla práctica utilizable, que la siguiente sección convierte en una medición: planifica un presupuesto seguro en torno al 20 a 40 por ciento de la ventana documentada, y luego verifícalo con tus propios datos. Para un modelo con ventana de 200K son de 40K a 80K. Para uno de 1M son de 200K a 400K, que, casualmente, es más o menos donde cambia la facturación en OpenAI y en Gemini 3.1 Pro.

---

Ajustar el híbrido: cifras y heurísticas

No son verdades universales. Son puntos de partida que aguantan en producción.

Tamaño de fragmento. De 500 a 1,500 tokens para prosa. De 200 a 500 para código, por función o bloque lógico. De 1,500 a 3,000 para texto jurídico o académico donde el contexto dentro del fragmento carga significado. Solapa entre un 10 y un 20 por ciento.

Recuperación top-k. Trae más de lo que vas a enviar. Recupera entre los 50 y los 200 primeros, y luego reordena. Un cross-encoder cuesta más por par que un modelo de embeddings y es muchísimo mejor en relevancia de grano fino.

Proporción entre reordenado y contexto. Quédate con los 20 a 100 primeros fragmentos tras reordenar. El número exacto se deduce del tamaño de fragmento y de tu presupuesto seguro.

Recuperación híbrida. Combina denso y disperso (BM25, SPLADE) con fusión recíproca de rangos. El denso por sí solo se pierde coincidencias exactas como SKU, códigos de error y nombres propios. El disperso por sí solo se pierde las paráfrasis.

Dos de estos parámetros merecen más que una viñeta, porque ahí es donde los equipos pierden precisión sin darse cuenta.

El primero es tu presupuesto de contexto seguro, y la única forma honesta de fijarlo es medir. Monta un conjunto de evaluación pequeño con preguntas que exijan razonar entre varios fragmentos y puntúa la precisión con 16K, 32K, 64K, 128K y 256K de contexto relleno. Quédate con el tamaño mayor que siga superando tu listón y trabaja un 20 por ciento por debajo para tener margen. Ese número medido debería caer cerca de la regla del 20 al 40 por ciento de arriba, y cuando no lo haga, fíate de tu evaluación antes que de la heurística. Si todavía no tienes un entorno de evaluación, nuestra guía del stack de evals para LLM repasa las herramientas.

El segundo es lo que pasa cuando actualizas el modelo, algo que tomó por sorpresa a varios equipos en 2026. El tokenizador de Anthropic cambió con Claude Opus 4.7, y el mismo texto ahora genera aproximadamente entre 1.0 y 1.35 veces los tokens que antes según el contenido, lo que Anthropic resume como alrededor de un 30 por ciento más. Haiku 5.5, lanzado el 7 de octubre, también usa el tokenizador nuevo, así que un pipeline que dé el salto desde Haiku 4.5 cuenta alrededor de un 30 por ciento más de tokens para el mismo texto. Tus documentos no crecieron. Tu presupuesto encogió. Si fijaste un techo de tokens hace un año y luego cambiaste el modelo por debajo, ese techo significa algo distinto ahora, y nada en tus logs te lo va a anunciar.

Salta la recuperación por completo cuando la consulta lo pida. "Resume el documento que acabo de subir" es una tarea de un solo documento. Detecta esos casos con un clasificador pequeño, sáltate la recuperación, ahorra latencia y evita sacar a la superficie ruido no relacionado.

Capas de resumen y poda. Para historiales muy largos, comprime el material más antiguo antes del ensamblado. Los resúmenes también cuestan tokens, así que mide si de verdad ayudan.

---

Antipatrones que los ingenieros siguen enviando a producción

Hay unas cuantas trampas que se repiten lo bastante como para ponerles nombre.

"Métele todo al contexto y ya." Tentador después de cada versión que duplica la ventana. Se degrada en silencio, así que pasas las comprobaciones puntuales y fallas en producción justo en las consultas que necesitaban razonamiento entre contextos. Ejecuta una evaluación al tamaño que te has propuesto antes de desplegar.

"Usa siempre RAG." La recuperación por reflejo se pierde los casos de un solo documento. Indexar un PDF de 50 páginas y traerte los 5 mejores fragmentos suele ser mejor que nada y peor que enviar el PDF entero.

"Ignora el recuento de tokens ensamblados." Los equipos fijan el top-k en "lo que quepa" y descubren tres meses después que su prompt medio son 350K tokens, que la precisión se ha ido escurriendo en silencio y que la factura se duplicó en un umbral que nadie leyó. Trata el tamaño del contexto ensamblado como una métrica de primera clase y ponle alertas.

"Deja que la compactación automática se encargue." La compactación automática mantiene viva una sesión. No la mantiene precisa. Los resúmenes pierden instrucciones, y el artículo del Compaction Cliff vio cómo la retención de reglas caía ronda tras ronda. Decide qué tiene que sobrevivir y guárdalo fuera de la conversación.

"Sáltate las evaluaciones porque el modelo ya es bueno." Las actualizaciones de modelo cambian cuál es la arquitectura correcta, y a veces te cambian la contabilidad de tokens por debajo. Reevalúa cuando cambien los modelos.

"Da por hecho que un fallo silencioso es un fallo seguro." Bajo distractores, algunos modelos alucinan y otros se abstienen, y en trabajo de horizonte largo algunos simplemente paran antes de tiempo. Averigua qué hace el tuyo, e instruméntalo.

---

Qué cambió en 2026: modelos, precios y compactación

Casi todo lo que sigue cambió entre septiembre y principios de octubre de 2026, cuando Anthropic, OpenAI y Google lanzaron modelos nuevos, y no todo apunta en la misma dirección.

La gama de modelos se renovó. Anthropic lanzó Claude Fable 5.1 el 1 de septiembre, Opus 5.5 el 22 de septiembre, Sonnet 5.5 el 28 de septiembre y Haiku 5.5 el 7 de octubre, todos con ventanas de 1M de tokens. OpenAI lanzó GPT-6 Astra el 3 de septiembre, GPT-6 Sol y Luna el 22 de septiembre y GPT-6.1 Sol el 29 de septiembre, cada uno con una ventana de 1.05M y hasta 922K tokens de entrada. Google puso Gemini 3.8 Flash en disponibilidad general el 2 de septiembre, mientras que Gemini 3.1 Pro sigue siendo un modelo en versión preliminar.

Las mejores puntuaciones de recuperación se dispararon, y la dispersión entre modelos es enorme. En OpenAI MRCR v2, su propia prueba de 8 agujas, OpenAI informa de que GPT-6 Astra logra un 96.3 por ciento entre 512K y 1M de tokens, frente al 73.8 por ciento de GPT-5.6 Sol. La model card de Google puntúa Gemini 3.1 Pro en el MRCR v2 (8 agujas) propio de Google, un conjunto de datos distinto pese a compartir nombre: un 84.9 por ciento de promedio hasta 128K y un 26.3 por ciento a 1M. Así que la brecha entre proveedores es una señal, no un resultado cara a cara. Ambas series de cifras las ejecutan los propios proveedores (OpenAI informa de la mejor puntuación obtenida con cualquier nivel de esfuerzo de razonamiento), y MRCR mide encontrar y reproducir el pasaje correcto, no razonar a lo largo de un documento. El context rot no desapareció. Se convirtió en algo que hay que medir modelo a modelo.

Los precipicios de precio ahora son distintos en cada proveedor. OpenAI sigue retarificando la petición completa por encima de 272K tokens de entrada, y en los modelos GPT-6 eso significa "2x en las tarifas de entrada y de caché, y 1.5x en la salida". GPT-6.1 Sol pasa de $2 y $10 por millón de tokens de entrada y de salida a $4 y $15, y GPT-6 Astra de $10 y $50 a $20 y $75. Los $4 y $20 de GPT-5.6 Sol son un precio promocional vigente al menos hasta el 21 de noviembre de 2026, y por encima de ese mismo umbral de tokens sube a $8 y $30. Google factura los prompts de Gemini 3.1 Pro de más de 200K a $4 y $18 en lugar de $2 y $12, pero Gemini 3.8 Flash no tiene ese tramo. Anthropic factura la ventana completa de 1M a tarifas estándar en Claude 4.6 y posteriores ("Una petición de 900k tokens se factura a la misma tarifa por token que una de 9k tokens", según su página de precios), con una excepción: en Haiku 5.5, los prompts de más de 100,000 tokens cuestan cinco veces más, $0.50 y $2.50 en lugar de $0.10 y $0.50.

La compactación se convirtió en producto. Los ajustes ya aparecen en las soluciones de más arriba. Lo que cambió es que ahora los proveedores compactan por ti. La documentación de Anthropic recomienda su nueva compactación bajo demanda "dondequiera que esté disponible". La Responses API de OpenAI devuelve el contexto compactado como un elemento opaco que no está pensado para que lo lea una persona, y su Agents API, en beta pública desde el 10 de septiembre, dice: "OpenAI se encarga de la orquestación de sesiones, la compactación del contexto y la recuperación ante fallos". Fíjate, eso sí, en el valor por defecto: un proveedor con una ventana de un millón de tokens arranca la compactación por umbral a los 150K.

El caché se abarató. Sigue sin arreglar el context rot. Las lecturas de caché cuestan una décima parte del precio base de entrada en la mayoría de los modelos de Anthropic, una vigésima parte en Opus 5.5 y Sonnet 5.5, y una cuadragésima parte en Fable 5.1. OpenAI cobra una décima parte en la mayoría de los modelos y una vigésima en GPT-6.1 Sol, y desde GPT-5.6 factura las escrituras en caché a 1.25 veces la tarifa de entrada. El caché abarata mucho las consultas repetidas contra contenido estable. No cambia lo que el modelo hace con una entrada larga, y en OpenAI los tokens cacheados duplican su precio pasados los 272K, igual que la entrada sin cachear.

Lo que no ha cambiado es el resultado de fondo. Un modelo mejor desplaza la curva, una ventana más grande por sí sola no arregla nada, y sigues necesitando recuperación para cargas de trabajo con datos frescos, multiinquilino y de múltiples fuentes.

Es la misma disciplina que aparece en la ingeniería de contexto en general: lo que dejas fuera del prompt importa tanto como lo que metes. También es la razón por la que la capa de recuperación merece el mismo escrutinio que cualquier otra vía de entrada, ya que la inyección indirecta de prompts llega a través de documentos recuperados y no a través de tus usuarios.

---

Un marco de decisión que puedes aplicar hoy

Recorre esto de arriba abajo para cualquier función nueva con LLM.

Paso 1: ¿qué tamaño tiene tu corpus?

• Menos de 100K tokens en total: sáltate la recuperación, usa contexto largo.
• De 100K a 1M de tokens: depende de la frescura, ve al Paso 2.
• Más de 1M de tokens: la recuperación es obligatoria.

Paso 2: ¿cuán frescos deben ser los datos?

• Cada hora o más rápido: recuperación. Reconstruir prompts largos sale demasiado caro.
• De diario a semanal: cualquiera de los dos patrones sirve.
• Estáticos: contexto largo con caché de prompts es barato y limpio.

Paso 3: ¿qué forma tiene la consulta?

• Razonamiento profundo sobre un solo documento: inclínate por contexto largo.
• Síntesis multidocumento: inclínate por el híbrido.
• Búsqueda de un dato o recuperación de hechos: inclínate por RAG clásico.
• Exploratoria: contexto largo si el conjunto de documentos está acotado, y si no, híbrido.

Paso 4: ¿necesitas citas o control de acceso?

• Un sí en cualquiera de las dos: la recuperación es obligatoria. Añadir citas y filtrado por usuario a posteriori sobre un diseño de solo contexto largo es doloroso.

Paso 5: ¿cuál es tu presupuesto de latencia?

• Menos de 1 segundo: RAG clásico.
• De 1 a 5 segundos: el híbrido es viable.
• Más de 5 segundos: cualquier patrón sirve.

Paso 6: ¿cuál es tu suelo de precisión en consultas largas?

• Precisión alta en razonamiento de varios pasos por encima de 50K tokens: híbrido con reranker.
• Lo mejor que se pueda: RAG clásico suele bastar.

Paso 7: ¿dónde cae tu prompt ensamblado respecto al precipicio de precio?

• Por debajo de 272K en OpenAI, por debajo de 200K en Gemini 3.1 Pro, por debajo de 100K en Claude Haiku 5.5 o, en cualquier otro caso, por debajo de tu presupuesto seguro medido: bien.
• Rondando alguna de esas líneas: añade un reranker y recorta el conjunto recuperado. Normalmente obtendrás una respuesta mejor y una factura más pequeña a la vez.

Paso 8: ¿se ejecutará como una sesión larga o como un agente?

• Sí: decide de antemano qué se borra (resultados de herramientas antiguos), qué se compacta, qué vive fuera de la conversación (reglas, progreso) y cuándo empieza el agente de cero. Registra los abandonos tempranos.
• No: las peticiones de una sola vuelta solo necesitan los Pasos 1 a 7.

La mayoría de los sistemas en producción aterrizan en el híbrido, porque las cargas reales llevan al menos una restricción que rompe el contexto largo puro (multiinquilino, frescura, coste, citas) y al menos una que rompe el RAG puro de top-k (razonamiento sobre un documento, consultas entre contextos, exploración).

Existe una versión humana de esta misma habilidad. Decidir qué merece ponerse delante de un proceso de razonamiento es lo que los lectores atentos han hecho siempre a mano, y resaltar es esa decisión hecha explícita. El resaltador web de Glasp conserva los pasajes que juzgaste dignos de guardar en lugar de la página entera, que es recuperación con un reranker humano. Si quieres apuntar tus propias herramientas a ese conjunto, el conector MCP de Glasp expone tus resaltados directamente a un LLM. Escribimos más sobre ese montaje en convertir tus notas en un servidor MCP.

---

Preguntas frecuentes

¿Qué es el context rot en los LLM?

El context rot es la caída medida en lo bien que un LLM usa su entrada a medida que esa entrada crece, mucho antes de que la ventana de contexto se llene. La precisión en recuperación y razonamiento cae de forma desigual, en distinta medida según el modelo, y más rápido cuando el texto distractor se parece a la respuesta. Chroma encontró que un pajar coherente perjudicaba más que uno barajado en los 18 modelos que evaluó, y la documentación de Anthropic ya define el término directamente: "A medida que crece el número de tokens, la precisión y el recall se degradan, un fenómeno conocido como context rot". Llenar una ventana de 1M de tokens no te compra una respuesta con calidad de 1M de tokens.

¿Cómo se corrige el context rot?

Enviando menos tokens y mejores. En aplicaciones y agentes, eso significa recuperar y reordenar en lugar de rellenar, poner los documentos largos antes de la pregunta, borrar los resultados de herramientas obsoletos, compactar antes de que la ventana se llene, mantener las reglas y el progreso fuera de la conversación y delegar la exploración en subagentes. En herramientas de chat y de programación, significa un chat por tarea, reiniciar tras dos correcciones fallidas, compactar pronto con una instrucción de enfoque y guardar las reglas persistentes en un fichero que el agente vuelva a leer, como CLAUDE.md.

¿Los modelos más nuevos, como Claude Opus 5.5 o GPT-6, arreglan el context rot?

Ningún modelo es inmune, pero la dispersión entre modelos es amplia. OpenAI informa de que GPT-6 Astra logra un 96.3 por ciento en su MRCR de 8 agujas entre 512K y 1M de tokens, mientras que la model card de Google muestra a Gemini 3.1 Pro con un 26.3 por ciento a 1M en la versión de la prueba propia de Google. Los conjuntos de datos son distintos, pero la brecha es demasiado grande para ignorarla. La documentación de Anthropic describe el context rot como una propiedad general de las entradas que crecen, y la documentación de Claude Code dice que el rendimiento "se degrada a medida que la ventana se llena". Mide el modelo que de verdad usas, con entradas que se parezcan a las tuyas.

¿RAG sigue siendo relevante en 2026?

Sí. La recuperación sigue siendo obligatoria para corpus que superan cualquier ventana, para datos que cambian cada hora, para el control de acceso por inquilino y para las citas. Lo que está obsoleto es el RAG clásico de top-5 como único patrón. La opción por defecto ahora es el híbrido: recuperar un conjunto acotado y razonar sobre el conjunto entero. Las ventanas de contexto más grandes cambiaron cuánto recuperas, no si recuperas.

¿El contexto largo reemplaza a RAG?

No en el caso general. El informe Context Rot de Chroma mostró que el rendimiento se degrada mucho antes de que la ventana se llene, y los proveedores diseñan como si estuvieran de acuerdo: la compactación por umbral de Anthropic salta por defecto a los 150K en los modelos de 1M de tokens, OpenAI retarifica las peticiones por encima de 272K tokens de entrada y Google cobra más por los prompts de Gemini 3.1 Pro de más de 200K. El contexto largo sí reemplaza a RAG para un documento acotado que quepa dentro de tu presupuesto seguro medido.

¿De qué tamaño debería ser mi conjunto recuperado antes de que aparezca el context rot?

Prueba con tu modelo concreto, pero un punto de partida razonable es del 20 al 40 por ciento de la ventana documentada. Eso son de 40K a 80K para un modelo de 200K y de 200K a 400K para uno de 1M, aunque en OpenAI te conviene quedarte por debajo de 272K por motivos de facturación, en Gemini 3.1 Pro por debajo de 200K y en Claude Haiku 5.5 por debajo de 100K. Monta una evaluación pequeña de preguntas de varios saltos, mide la precisión a distintos tamaños de contexto y quédate con el mayor que siga superando tu listón.

¿El caché de prompts arregla el context rot?

No. El caché arregla el coste, no la precisión. Las lecturas cacheadas cuestan ahora entre una décima y una cuadragésima parte del precio normal de entrada según el modelo, así que las consultas de contexto largo contra contenido estable salen mucho más baratas y la ventaja de coste de RAG se estrecha. El modelo sigue leyendo el mismo contexto largo y se degrada igual, así que estás pagando menos por la misma respuesta más floja. En OpenAI, además, los tokens cacheados duplican su precio por encima de 272K.

¿Debería usar un reranker antes de enviar al contexto largo?

Para la mayoría de los sistemas híbridos en producción, sí. Un cross-encoder que puntúe tus 50 a 200 primeros fragmentos recuperados mejora mucho lo que llega a la etapa de razonamiento. Saltarse el reordenado suele significar meter más tokens para compensar una precisión más floja, lo que te empuja a la vez hacia la zona de degradación y hacia el precipicio de precio. Es uno de los cambios de mayor impacto que puedes hacer en un pipeline híbrido.

Mi agente se detiene antes de tiempo en tareas largas. ¿Es context rot?

Probablemente, y ya tiene nombre. El artículo de 2026 Diagnosing and Mitigating Context Rot in Long-horizon Search lo llama terminación prematura: con un contexto pesado, los modelos se rinden o devuelven una respuesta incorrecta que marcan como incierta antes de agotar la ventana, a una tasa que sube con la longitud del contexto. La gestión de contexto (compactación, recorte o subagentes) ayuda sobre todo porque reduce esa tasa y así el agente sigue explorando. Instrumenta los abandonos tempranos como métrica propia.

---

Reflexiones finales

Cada versión con una ventana más grande trae la misma promesa implícita: deja de hacer ingeniería, vuélcalo todo. Chroma puso números duros a por qué esa promesa no se ha cumplido, el trabajo de 2026 añadió un segundo modo de fallo que nadie vigilaba, y las matemáticas de fondo (dilución del softmax, extrapolación de posiciones, distribución de entrenamiento) dicen que tampoco se cumplirá limpiamente con 100M de tokens.

Lo que queda es la respuesta aburrida y productiva. Construye recuperación. Ajústala. Añade un reranker. Borra lo que el modelo ya no necesita, y guarda fuera de la conversación lo que nunca debe perder. Elige un presupuesto de contexto seguro midiendo en lugar de fiarte de una ficha técnica, y vuelve a medir cuando cambien el modelo o su tokenizador, algo que entre septiembre y principios de octubre de 2026 pasó por igual en Anthropic, OpenAI y Google. Envía el conjunto de tokens más pequeño y más relevante que contenga la respuesta. Deja que el modelo razone sobre eso. Cita las fuentes.

El giro de 2026 es que los proveedores ahora diseñan como si estuvieran de acuerdo contigo. La línea de OpenAI en 272K, la de Google en 200K en Gemini 3.1 Pro, la de Haiku 5.5 en 100K y una compactación por defecto en 150K en los modelos Claude de un millón de tokens son todas admisiones de que la ventana utilizable es una fracción de la anunciada. El precio plano de Anthropic en sus modelos más grandes elimina el precipicio de precio pero no el coste en precisión, y con una tarifa plana menos tokens siguen costando menos. Así que la arquitectura disciplinada es también la barata, y esas dos rara vez apuntan en la misma dirección.

Si quieres un mapa más amplio de qué modelo apuntar a qué trabajo, mantenemos uno en la matriz de tareas y modelos de IA. Las decisiones de arquitectura sobreviven a los lanzamientos de modelos. Acierta en estas y la siguiente actualización será una mejora gratis en lugar de una reescritura forzosa.