Qué es el context rot en los LLM
El context rot es la tendencia medida de un modelo de lenguaje grande a usar peor la información a medida que la entrada se alarga, mucho antes de que la ventana de contexto se llene. Chroma Research le puso números en 18 modelos de frontera en julio de 2025, y el trabajo posterior a lo largo de 2026 ha afilado el hallazgo en lugar de suavizarlo. Un modelo anunciado con 1M de tokens no razona sobre 1M de tokens con la calidad que muestra a 30K.
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 ofrece 1M de tokens en Claude Opus 5 y Claude Sonnet 5. La familia GPT-5.6 de OpenAI ronda los 1.05M. Gemini 3.1 Pro de Google llega a 1M. Llama 4 Scout de Meta documenta 10M. Lo que no llegó fue un modelo que use bien todo eso.
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.
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, publicado el 14 de julio de 2025, Kelly Hong, Anton Troynikov y Jeff Huber ejecutaron experimentos controlados sobre 18 modelos, incluyendo la familia Claude 4 más Claude 3.7 y 3.5, o3, la familia GPT-4.1, GPT-4o, GPT-4 Turbo, Gemini 2.5 Pro y Flash, y tres tamaños de Qwen3. Su kit de replicación en GitHub permite volver a ejecutarlo.
Cuatro hallazgos importan para la arquitectura.
El rendimiento se degrada de forma no uniforme según crece la entrada. Si has venido buscando la gráfica del context rot, la forma es justo el mensaje: no es una pendiente lineal suave. La precisión aguanta, luego cae por un precipicio, y ese precipicio está en un punto distinto para cada modelo. Si lo dibujas obtienes un descenso dentado, no una rampa, y por eso mismo una comprobación puntual con un tamaño de contexto no te dice casi nada del comportamiento con otro.
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. Los modelos resolvieron bien los prompts enfocados y se degradaron de forma sistemática en los completos. La brecha varía mucho según el modelo, y Chroma señaló que los modelos Claude mostraron la versión más pronunciada. Misma pregunta, mismo modelo, misma respuesta presente en la entrada. Lo único que cambió fue cuánto texto irrelevante venía con ella.
La similitud semántica impulsa la degradación más que la longitud. Cuando la "aguja" es fácil de distinguir del "pajar", los modelos la encuentran. Cuando los distractores se parecen semánticamente a la respuesta, la precisión cae en picado, y la caída se ensancha con la longitud. Incluso un solo distractor reduce el rendimiento frente a la línea base con la aguja sola, y cuatro lo agravan. Esto encaja con Liu et al. (2024), "Lost in the Middle," in TACL, que encontró una curva en forma de U donde el centro de un contexto largo queda sistemáticamente infraponderado.
El texto estructurado y coherente degrada la atención más que el texto barajado. Este es el resultado que debería cambiar cómo piensan los ingenieros. La intuición dice que sobre un documento limpio de 100K tokens es más fácil razonar que sobre uno desordenado. Chroma encontró lo contrario, de forma consistente, en los 18 modelos: barajar el 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 la atención. La parte accionable no necesita mecanismo: un PDF pulcro y bien formateado no es automáticamente la opción segura.
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 y tendieron 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.
| Qué cambias | Qué le pasa a la precisión | Qué significa para tu pipeline |
|---|---|---|
| La entrada crece de ~300 a ~113k tokens | Degradación sistemática en LongMemEval | El contexto irrelevante no es relleno gratis |
| La aguja se parece al pajar | Caída brusca, empeora con la longitud | Reordena buscando precisión, no añadas tokens sin más |
| Se añade un distractor | Caída medible respecto a la línea base | Descarta los casi aciertos antes del ensamblado |
| Pajar barajado frente a coherente | El barajado puntuó mejor en los 18 modelos | Un formateo limpio no es un margen de seguridad |
| Cambio de modelo bajo distractores | Claude se abstiene, GPT alucina | Elige el modo de fallo que puedas detectar |
El benchmark Sequential-NIAH (arXiv 2504.04713) incide en el mismo punto desde otro ángulo, comprobando si los modelos pueden extraer agujas que además deben devolverse en el orden correcto. Con seis LLM y contextos de 8K a 128K, el mejor modelo alcanzó el 63.5 por ciento. La recuperación en varios pasos a distancia es más difícil de lo que sugieren las demos con una sola aguja.
Para una entrada más suave, Hamel Husain invitó a Kelly Hong a repasar la investigación y publicó un resumen anotado de esa charla. Sus conclusiones aterrizan donde lo hace el 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.
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. 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ó 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 (junio de 2026), Shijie Xia, Yikun Wang, Zhen Huang y Pengfei Liu estudiaron cuatro modelos insignia en tres benchmarks y le pusieron 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 con dudas, mucho antes de haber agotado la ventana. Controlando por la dificultad de la consulta, 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 opuestos. Si el modelo ya no encuentra la aguja, mejora 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. Analizaron siete métodos de gestión de contexto en tres categorías y concluyeron que esos métodos funcionan sobre todo como estrategias de escalado en tiempo de inferencia: al recortar la tasa de terminación prematura, le compran al modelo más exploración. La compactación y la poda se ganan el sueldo como funciones de precisión, no solo como control de costes. Los autores además construyeron una estrategia de filtrado consciente del comportamiento para el muestreo en paralelo y midieron una mejora del 2.6 al 4.9 por ciento 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.
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 al resaltado del 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. Trabajarse una llamada 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 resulta ser justo el punto donde cambia la facturación.
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 dramáticamente mejor en relevancia de grano fino.
Proporción entre reordenado y contexto. Quédate con entre 20 y 100 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.
El segundo es lo que pasa cuando actualizas el modelo, algo que mordió a varios equipos en 2026. El tokenizador de Anthropic cambió con Claude Opus 4.7, y el mismo texto ahora se mapea a entre 1.0 y 1.35 veces más tokens según el contenido, lo que Anthropic resume como alrededor de un 30 por ciento más. 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.
| Eje | RAG puro (top-5 fragmentos) | Contexto largo puro | Híbrido (recuperar 50K-200K y razonar) |
|---|---|---|---|
| Forma de los datos | Muchos documentos, corpus amplio | Un documento o un conjunto pequeño | Muchos documentos, razonamiento profundo |
| Tamaño de entrada típico | 2K-10K tokens | 100K-1M tokens | 50K-200K tokens |
| Latencia | Rápida | Lenta | Media |
| Coste por consulta | Bajo | Alto, y peor pasado el precipicio de precio | Medio |
| Precisión a escala | Buena si el top-k es correcto | Se degrada con el rot | La mejor para consultas complejas |
| Frescura | Fácil (actualizar el índice) | Difícil (reconstruir el prompt) | Fácil (actualizar el índice) |
| Citas | Nativas | Requiere trabajo extra | Nativas (vía conjunto recuperado) |
| Control de acceso | Nativo (filtrar en la recuperación) | Difícil | Nativo |
| Razonamiento sobre un documento | Suele romperse | Fuerte | Fuerte |
| Razonamiento entre documentos | Limitado (solo top-k) | No aplica salvo un documento | Fuerte |
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.
"Fíate de la ventana documentada." El límite documentado es lo que puedes enviar. El límite utilizable es hasta donde aguanta la calidad. Son números distintos, y solo uno de ellos está en la ficha técnica.
"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.
"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 cuál de los dos hace el tuyo, e instruméntalo.
Qué cambió en 2026: ventanas, precios y compactación
Dos cosas se movieron desde la primera versión de este artículo, y ambas apuntan en la misma dirección.
El contexto largo ya lleva un precipicio de precio publicado, en dos proveedores. OpenAI factura la familia GPT-5.6 con dos contadores. Por debajo del umbral, GPT-5.6 Sol cuesta $4 por millón de tokens de entrada y $20 por millón de salida. Por encima, ese mismo modelo cuesta $8 y $30. Terra pasa de $2/$12 a $4/$18, y Luna de $0.20/$1.20 a $0.40/$1.80. El umbral está en 272K tokens de entrada, y cruzarlo vuelve a tarificar la petición entera, no solo el excedente. Un prompt de 272,001 tokens factura todos y cada uno de esos tokens a la tarifa más alta. Frente a una ventana anunciada de 1.05M de tokens, eso es aproximadamente una cuarta parte al precio anunciado.
Google hace lo mismo con un umbral más bajo. Gemini 3.1 Pro cuesta $2 por millón de entrada y $12 por millón de salida para prompts de hasta 200K tokens, y luego $4 y $18 por encima. La misma estructura de 2x en entrada y 1.5x en salida, 72K tokens antes. Si dimensionaste tu pipeline contra el precipicio de OpenAI y luego cambiaste de proveedor, puedes pasarte el de Google de largo sin cambiar una sola línea de código.
Que dos proveedores independientes tarifiquen el contexto largo como una prima es una evidencia más fuerte que cualquiera de los dos por separado. Convierte un argumento de calidad en un argumento de presupuesto: mantenerte por debajo de tu presupuesto de contexto seguro ya era el movimiento que preservaba la precisión, y ahora además es la diferencia entre una factura y dos.
Los proveedores lanzan la gestión de contexto como función de producto. La compactación de Anthropic resume en el servidor el contexto anterior a medida que crece la conversación. Hay que activarla, no viene encendida por defecto, pero una vez la habilitas el umbral de disparo está por defecto en 150K tokens en modelos cuya ventana es de 1M. Léelo otra vez: el proveedor con una ventana de un millón de tokens pone su propio valor por defecto en el 15 por ciento de esa ventana. Anthropic también ofrece edición de contexto, que elimina resultados de herramientas o bloques de razonamiento antiguos en lugar de resumirlos. Dos mecanismos distintos, la misma admisión de fondo.
El caché de prompts sí es la palanca de coste de verdad, y es real: las lecturas de entrada cacheada cuestan alrededor de una décima parte del precio normal de entrada en ambas APIs principales. El caché abarata mucho las consultas repetidas contra contenido estable. No arregla el context rot, y en OpenAI tampoco te exime del tramo de contexto largo.
| Modelo | Ventana documentada | Advertencia práctica |
|---|---|---|
| Claude Opus 5 / Sonnet 5 | 1M tokens | La compactación queda en 150K una vez activada |
| Claude Haiku 4.5 | 200K tokens | El presupuesto seguro cae cerca de 40K-80K |
| GPT-5.6 (Sol / Terra / Luna) | ~1.05M tokens | La petición entera se retarifica por encima de 272K de entrada |
| Gemini 3.1 Pro | 1M tokens | La petición entera se retarifica por encima de 200K |
| Llama 4 Scout | 10M tokens (iRoPE) | Documentado, no demostrado a esa profundidad |
Lo que no ha cambiado es el resultado de fondo. Ninguno de estos lanzamientos vino con pruebas de que una ventana más grande arregle la degradación. Las ventanas más grandes suben el techo, la forma de la degradación persiste, y sigues necesitando recuperación para cargas frescas, 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 Google, o, con cualquier otro proveedor, por debajo de tu presupuesto seguro medido: bien.
- Rondando cualquiera de los dos umbrales: 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.
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 observación de que los LLM usan el contexto largo peor de lo que sugiere el marketing. A medida que metes más tokens, la precisión en recuperación y razonamiento se degrada de forma no lineal, cayendo por precipicios en lugar de deslizarse por una rampa. Empeora más rápido cuando el texto distractor se parece a la respuesta, y Chroma encontró que incluso una entrada coherente y bien estructurada perjudicó la atención más que una entrada barajada en los 18 modelos evaluados. Llenar una ventana de 1M de tokens no te compra una respuesta con calidad de 1M de tokens.
¿RAG está obsoleto en 2026?
No, y la evidencia apunta en sentido contrario. 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 sí 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 todo él. 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 desde entonces los proveedores han coincidido en sus propios productos: la compactación opcional de Anthropic resume por defecto a los 150K en un modelo de 1M de tokens, OpenAI retarifica las peticiones por encima de 272K tokens de entrada y Google por encima 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 y en Google por debajo de 200K. 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 de entrada cacheada cuestan aproximadamente una décima parte del precio normal de entrada, 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, el caché tampoco te exime del tramo de precio de contexto largo.
¿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 entre 50 y 200 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 contexto pesado, los modelos se rinden o responden con una confianza no ganada antes de agotar la ventana, a una tasa que sube con la longitud del contexto. La gestión de contexto ayuda sobre todo porque recorta 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. Elige un presupuesto de contexto seguro midiendo en lugar de fiándote de una ficha técnica, y vuelve a medir cuando cambien el modelo o su tokenizador. 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 tarifican y diseñan como si estuvieran de acuerdo contigo. Precipicios en 272K y 200K, y una compactación por defecto en 150K, son todas admisiones de que la ventana utilizable es una fracción de la anunciada. Eso es útil, porque significa 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.
