Context Rot, RAG y contexto largo: cómo diseñar sistemas LLM en 2026

El año en que las ventanas de 2M tokens dejaron de importar

Durante unos seis meses, a finales de 2024 y comienzos de 2025, un argumento conocido circuló por los canales de Slack de ingeniería: RAG está obsoleto. Solo pega todo dentro.

El razonamiento sonaba limpio. Anthropic lanzó Claude Sonnet con una ventana de contexto de 1M tokens. Google llevó Gemini 2.5 y 2.5 Pro a 2M tokens. Meta anunció Llama 4 Scout con un límite teórico de 10M tokens. Si tu base de conocimiento cabe dentro de un solo prompt, ¿para qué molestarse con vector stores, pipelines de embeddings y estrategias de chunking?

Luego, en julio de 2025, Chroma Research publicó "Context Rot: How Increasing Input Tokens Impacts LLM Performance" de Kelly Hong, Anton Troynikov y Jeff Huber. El artículo realizó experimentos cuidadosos en 18 modelos de frontera y mostró algo que las páginas de marketing no decían: las ventanas de contexto largo se degradan de formas no evidentes mucho antes de alcanzar su límite. Una ventana de 200K tokens puede mostrar una pérdida seria de precisión con 50K tokens de entrada. Una ventana de 1M tokens no razona de forma fiable sobre 1M tokens.

Ese resultado replanteó la conversación sobre arquitectura. RAG no está obsoleto. El contexto largo no es gratis. La pregunta interesante ya no es "cuál gana", sino "qué patrón se ajusta a esta forma de datos, presupuesto de latencia y requisito de frescura".

Este texto es la respuesta a nivel de arquitectura: cuándo debe tu sistema recuperar, cuándo debe volcar todo y cuándo debe hacer ambas cosas.

---

Lo que realmente mostró el artículo de Chroma

Vale la pena leer con detenimiento el artículo de Chroma porque el titular ("existe context rot") subestima lo que realmente hay allí. El equipo ejecutó versiones extendidas de los benchmarks de needle-in-a-haystack (NIAH) en GPT-4.1, la familia Claude 4 incluyendo Opus 4 y Sonnet 4, Gemini 2.5 y Qwen3. Su kit de replicación abierto en GitHub permite reproducir las ejecuciones.

Tres hallazgos destacan.

Hallazgo 1: el rendimiento se degrada de forma no uniforme a medida que crece la longitud de entrada. Este es el resultado central. Los modelos no empeoran de forma lenta y predecible a una tasa lineal a medida que la entrada se alarga. Chocan contra acantilados. Algunos modelos rinden bien en 32K y colapsan en 64K. Otros aguantan hasta que de repente no. El tamaño de la ventana de contexto documentada se correlaciona débilmente con qué tan bien usa el modelo ese contexto.

Hallazgo 2: la similitud semántica impulsa la degradación más que la longitud. Cuando la "aguja" es semánticamente distinta del "pajar" circundante, los modelos la encuentran sin problema. Cuando los distractores son semánticamente similares a la respuesta, la precisión cae bruscamente, y la caída empeora con la longitud. En otras palabras: cuanto más difícil es distinguir la respuesta del ruido, más rápido se desmorona el contexto largo. Esto coincide con un resultado independiente de Liu et al. (2024), "Lost in the Middle: How Language Models Use Long Contexts" en TACL, que mostró una curva de rendimiento en forma de U donde el medio de los contextos largos queda sistemáticamente subponderado.

Hallazgo 3 (el sorprendente): el texto estructurado y coherente degrada la atención MÁS que el texto desordenado. Este es el resultado que debería cambiar la forma en que piensan los ingenieros. La intuición era que un documento de 100K tokens limpio y bien organizado es más fácil de razonar para un modelo que un bloque revuelto de 100K tokens. Los datos dicen lo contrario, o al menos, no siempre. El texto coherente parece dispersar la atención de manera más difusa a lo largo de una secuencia larga, mientras que el texto desordenado crea señales locales más distintivas a las que el modelo puede aferrarse. La implicación: alimentar al modelo con un PDF ordenado y bien formateado no es automáticamente más seguro que alimentarlo con un conjunto de recuperación desordenado.

El benchmark Sequential-NIAH (arXiv 2504.04713) lleva esto más lejos al evaluar si los modelos pueden encadenar múltiples recuperaciones desde distintas partes de un contexto largo. La caída es aún más pronunciada para el razonamiento de varios pasos a distancia.

Hamel Husain resumió bien la implicación práctica en sus notas sobre context rot: la postura de ingeniería no debería ser "meterlo todo dentro", sino "darle al modelo el contexto más pequeño y relevante que responda la pregunta".

---

Por qué falla el contexto largo: el mecanismo

El mecanismo importa porque predice qué cargas de trabajo fallarán.

La atención estándar de los transformadores usa un softmax sobre todos los pares de tokens. A medida que la longitud de secuencia N crece, los pesos de atención se reparten entre más posiciones. Incluso con codificaciones de posición relativas como RoPE (rotary position embeddings) o ALiBi, el denominador del softmax crece y el peso por posición sobre cualquier token individual se reduce. Con 1M tokens, el token "correcto" tiene que competir con otros 999.999 por un presupuesto finito de atención.

Las codificaciones de posición ayudan, pero no son mágicas. RoPE tiene una curva de degradación conocida cuando se extrapola muy por encima de la longitud de entrenamiento. Los modelos entrenados con secuencias de hasta 32K tokens que se despliegan a 1M tokens están haciendo una extrapolación que las matemáticas subyacentes no respaldan del todo. Trucos como YaRN, interpolación de posiciones y escalado consciente de NTK extienden el rango utilizable, pero ninguno produce un modelo que use 1M tokens con la misma eficacia con que usa 32K.

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

El context rot no es un bug que arreglará la próxima versión. Es una propiedad de la arquitectura y de la distribución de entrenamiento. Los modelos futuros empujarán los límites más lejos, pero el patrón básico va a persistir un buen tiempo.

---

Dónde sigue ganando RAG

Dado el context rot, la generación aumentada por recuperación no es infraestructura heredada. Aquí es donde sigue ganando en 2026.

Corpus multidocumento a escala. Si tu base de conocimiento tiene 50.000 documentos que suman 500M tokens, no caben en ninguna ventana de contexto. La recuperación es la única arquitectura viable.

Frescura y actualidad. Los vector stores se actualizan de forma incremental. Un prompt de contexto largo requiere reconstruir el prompt cada vez que cambia el contenido. Para documentos que se actualizan cada hora (noticias, catálogos, tickets de soporte, repositorios de código), la recuperación maneja el cambio de forma barata.

Costo. El costo de inferencia escala aproximadamente lineal con los tokens de entrada. Enviar 200K tokens cuesta 200 veces lo que cuestan 1K tokens. Si el 95 por ciento de tus consultas se pueden responder con 5K tokens relevantes, la recuperación te da una reducción de costos de 40x sin perder precisión.

Citación y procedencia. La recuperación te da una lista estructurada de documentos fuente que puedes mostrar, enlazar y ordenar. Las salidas de contexto largo son más difíciles de anclar a fuentes específicas sin plomería extra de extracción de citas.

Control de acceso e inquilinos. Si tu corpus tiene visibilidad por usuario, por inquilino o por rol, no puedes simplemente volcarlo todo. La recuperación filtra por política de acceso antes de que el modelo vea los datos. Innegociable para productos B2B.

Razonamiento entre múltiples corpus. Cuando la respuesta combina un mensaje de Slack, una página de Notion, una incidencia de Linear y un PR de GitHub, la recuperación es el puente.

Si tu producto marca cualquiera de estas casillas, RAG no es opcional. La pregunta pasa a ser cómo hacer que la recuperación sea buena, no si hacerla.

---

Dónde gana el contexto largo

El contexto largo tiene cargas de trabajo donde es la respuesta correcta.

Razonamiento profundo sobre un solo documento. Leer un contrato legal de 100 páginas y responder preguntas que atraviesan cláusulas. Analizar un artículo de investigación. Resumir una llamada de resultados. Cuando la respuesta correcta conecta dos párrafos separados por 80 páginas, la recuperación suele romper la conexión. El contexto largo la preserva.

Comprensión de código dentro de un repositorio. Muchas tareas de razonamiento sobre código necesitan imports, tipos, definiciones y sitios de llamada simultáneamente. Trocear por archivo pierde las relaciones entre archivos. Meter todo el repositorio en contexto (cuando cabe) preserva la estructura.

Continuidad conversacional. Las sesiones de agente de larga duración se benefician de tener todo el historial en contexto. La recuperación sobre el historial de conversación es frágil: a menudo necesitas los últimos 50 turnos, no los 50 turnos semánticamente más similares.

Razonamiento exploratorio cuando no conoces la consulta. Si no estás seguro de qué preguntarle a un documento hasta que has empezado a razonar sobre él, la recuperación es difícil de usar. No puedes escribir la consulta por adelantado. El contexto largo deja que el modelo explore el material.

Referencias cruzadas dentro de una unidad coherente. Un capítulo de libro de texto, un artículo de investigación, un escrito jurídico: estos están unificados lógicamente. Trocear y reensamblar a menudo pierde la estructura argumental.

Heurística aproximada: si tus datos son un solo documento lógico y cabe, el contexto largo es la arquitectura más limpia.

---

El patrón híbrido que realmente funciona

El valor por defecto en 2026 para los sistemas LLM serios no es ni RAG puro ni contexto largo puro. Es un híbrido: recuperar un conjunto sustancial pero acotado de tokens, y luego razonar sobre ellos con contexto largo.

Este es el flujo canónico:

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

Por qué funciona: cada etapa maneja el modo de falla de la otra. La recuperación reduce un corpus demasiado grande para cualquier ventana de contexto a un conjunto manejable. El razonamiento con contexto largo sobre el conjunto recuperado restaura el razonamiento multidocumento y multichunk que el RAG puro a menudo rompe cuando envía solo los 5 chunks superiores.

La decisión clave de ingeniería es el tamaño del conjunto de recuperación. Envía muy pocos tokens y pierdes el beneficio del contexto largo (más vale hacer RAG clásico top-5). Envía demasiados y disparas el context rot. Los datos de Chroma sugieren que el techo seguro está muy por debajo del límite documentado del modelo, a menudo entre 4x y 10x menos. Un modelo con ventana de 200K suele ser sólido hasta 40K a 80K. Un modelo con ventana de 1M a menudo puede manejar entre 150K y 300K con un rot mínimo.

Este es el patrón arquitectónico al que convergieron la mayoría de los equipos que desplegaron funciones LLM a escala a finales de 2025. No es glamoroso, pero funciona.

---

Afinando el híbrido: números y heurísticas

Voy a ponerles números a las palancas. No son verdades universales; son puntos de partida que funcionan en producción para muchos equipos.

Tamaño de chunk. Entre 500 y 1.500 tokens por chunk para la mayoría de la prosa. Entre 200 y 500 para código (por función o por bloque lógico). Entre 1.500 y 3.000 para texto legal o académico donde importa el contexto dentro de un chunk. Solapa los chunks entre un 10 y un 20 por ciento.

Recuperación top-k. Recupera más de lo que vas a enviar. Recupera el top 50 a 200 y luego reordena. El reranker (un cross-encoder, a menudo un modelo especializado pequeño como Cohere Rerank o un BGE reranker afinado) cuesta más por par que el modelo de embeddings, pero es dramáticamente más preciso en la relevancia de grano fino.

Relación rerank-a-contexto. Después de reordenar, conserva los 20 a 100 chunks superiores para la etapa de contexto largo. El número exacto depende del tamaño del chunk y de tu presupuesto de contexto seguro.

Recuperación híbrida. Combina recuperación densa (vectorial) y dispersa (BM25, SPLADE) con fusión recíproca de rangos. La densa pura se pierde consultas de coincidencia exacta (SKU, códigos de error, nombres propios). La dispersa pura se pierde paráfrasis. El híbrido captura ambas.

Presupuesto de contexto seguro. Evalúa tu modelo. Construye un pequeño conjunto de eval con preguntas cuya respuesta requiera razonar entre múltiples chunks en distintas longitudes de contexto. Mide la precisión con 16K, 32K, 64K, 128K y 256K tokens de contexto saturado. Elige el tamaño más grande donde la precisión siga siendo aceptable. Ese es tu presupuesto seguro. Mantente un 20 por ciento por debajo en producción para dejar margen.

Saltar la recuperación por completo. "Resume el documento que acabo de subir" es una tarea de un solo documento. Detecta estas consultas con un clasificador pequeño y omite la recuperación; ahorras latencia y evitas exponer ruido no relacionado.

Capa de resumen. Para historiales muy largos (conversaciones de varios meses, bases de código grandes), intercala un paso de resumen que comprima el material antiguo antes del ensamblaje. Los resúmenes también cuestan tokens, así que evalúa si realmente ayudan.

Aquí hay una tabla comparativa que captura los compromisos:

---

Antipatrones que los ingenieros siguen desplegando

Algunas trampas se repiten con suficiente frecuencia como para señalarlas.

"Volcar todo al contexto sin más." Tentador después de cada lanzamiento que duplica la ventana. Los datos de Chroma dicen que se degrada en silencio. Pasarás los spot-checks y fallarás en producción en consultas que requieren razonamiento entre contextos. Siempre ejecuta una eval en tu tamaño de contexto objetivo antes de lanzar.

"Usar RAG siempre." Aplicar RAG por reflejo a cada carga de trabajo se pierde los casos de un solo documento. Meter un PDF de 50 páginas en un índice vectorial y luego recuperar los 5 chunks superiores normalmente produce una respuesta peor que entregarle el PDF completo al modelo. Heurística: si un solo documento cabe en tu presupuesto de contexto seguro y la consulta es sobre ese documento, omite la recuperación.

"Ignorar el conteo de tokens del conjunto de recuperación." Los equipos fijan el top-k en "todos los que caben" y descubren tres meses después que su prompt promedio es de 350K tokens y la precisión se ha degradado en silencio. Trata el tamaño del contexto ensamblado como una métrica de primera clase. Alerta sobre ella.

"Confiar en la ventana documentada." Una ventana de 1M tokens no significa que el modelo use 1M tokens igual de bien. El límite documentado es lo que puedes enviar técnicamente. El límite utilizable es donde el modelo aún rinde a tu vara de calidad. Son números distintos, a menudo por un orden de magnitud.

"Saltarse las evals porque el modelo ya es bueno." Las actualizaciones de modelos de frontera cambian la elección óptima de arquitectura. Una carga de trabajo que necesitaba RAG en GPT-4-32K podría andar bien con contexto largo en Gemini 2.5 Pro. Reevalúa cuando los modelos cambien.

---

Qué cambia el hardware de 2026

Las ventanas más grandes sí cambian algunas decisiones. Vale la pena ser específico sobre cuáles.

Llama 4 Scout con 10M tokens. Si el contexto utilizable es incluso la mitad del límite documentado, corpus enteros de tamaño medio caben en un solo prompt. Los asistentes mono-inquilino sobre una base de conocimiento interna de 1M tokens pueden saltarse la recuperación. La economía importa, eso sí: 5M tokens de entrada en un modelo de frontera es caro por consulta.

Gemini 2.5 / 3 Pro con 2M tokens. Una ventana de 2M con prompt caching cambia el cálculo para flujos de trabajo que consultan repetidamente el mismo conjunto grande de documentos. Cachea 1,5M tokens de contexto de fondo, paga solo por la consulta marginal, y el costo por consulta empieza a competir con la recuperación.

Claude Sonnet 1M. Útil para cargas de trabajo agénticas donde el estado de sesión crece mucho. Los agentes conversacionales que tenían que resumir o aplicar RAG sobre su propio historial ahora pueden mantener más historial crudo en contexto.

Prompt caching entre proveedores. Anthropic, Google y OpenAI soportan caché de entrada. Las arquitecturas de contexto largo se vuelven mucho más baratas para consultas repetidas contra contenido estable. La ventaja de costo de RAG se reduce cuando entra el caching, aunque no desaparece.

Lo que no ha cambiado: el context rot. Ninguno de estos lanzamientos incluye datos de benchmark que muestren que las ventanas más grandes resuelven el problema de rot. Las ventanas más grandes suben el techo, pero la misma forma de degradación persiste. Sigues necesitando medir tu presupuesto seguro. Sigues necesitando recuperación para cargas frescas, multi-inquilino y multifuente. El híbrido sigue siendo el valor por defecto correcto.

---

Un marco de decisión que puedes aplicar de verdad

Aquí hay un flujo que puedes aplicar a cualquier nueva función LLM. Recórrelo de arriba abajo.

Paso 1: ¿Qué tan grande es tu corpus?

• Menos de 100K tokens en total: omite la recuperación, usa contexto largo directamente.
• Entre 100K y 1M tokens: depende de la frescura (ve al Paso 2).
• Más de 1M tokens: la recuperación es obligatoria.

Paso 2: ¿Qué tan fresca necesitan ser los datos?

• Actualizaciones cada hora o más rápido: recuperación. Los prompts de contexto largo son demasiado caros para reconstruir.
• Actualizaciones diarias o semanales: cualquiera de los dos patrones funciona.
• Estáticos o pocas veces actualizados: contexto largo con prompt caching es barato y limpio.

Paso 3: ¿Cuál es la forma de la consulta?

• Razonamiento profundo sobre un solo documento: inclínate por contexto largo.
• Síntesis multidocumento: inclínate por híbrido.
• Búsqueda o recuperación de hechos: inclínate por RAG clásico (top-k, contexto pequeño).
• Exploratoria o abierta: inclínate por contexto largo si el conjunto de docs está acotado; de lo contrario, híbrido.

Paso 4: ¿Necesitas citación o control de acceso?

• Sí a cualquiera: la recuperación es obligatoria (RAG clásico o híbrido). Las arquitecturas solo de contexto largo son muy difíciles de adaptar después para citas y filtrado por usuario.

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

• Menos de 1 segundo: RAG clásico (contexto pequeño, rápido).
• Entre 1 y 5 segundos: el híbrido es factible.
• Más de 5 segundos: cualquier patrón funciona.

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

• Alta precisión en razonamiento de varios pasos sobre 50K+ tokens: híbrido con reranker.
• Mejor esfuerzo: RAG clásico suele bastar.

Recorre estos seis pasos y aterrizarás en una de tres arquitecturas: RAG top-k clásico, contexto largo puro o híbrido. La mayoría de los sistemas en producción para cargas serias aterrizan en híbrido. No porque el híbrido sea universalmente mejor, sino porque las cargas reales suelen tener al menos una restricción (datos multi-inquilino, frescura, costo, citación) que rompe el contexto largo puro, y al menos una (razonamiento sobre un solo doc, consultas entre contextos, exploración) que rompe el RAG top-k puro.

El artículo de Chroma cambió el discurso. Hizo que el debate contexto-largo-versus-RAG se sintiera un poco vergonzoso en retrospectiva. No son competidores; son dos de los tres componentes de un stack LLM que funciona, y el tercero (reordenamiento) es lo que hace estable al híbrido.

---

Preguntas frecuentes

¿La ventana de contexto de 2M de Gemini mató a RAG?

No. La ventana de 2M tokens es real, pero el artículo "Context Rot" de Chroma demostró que el rendimiento se degrada mucho antes de que la ventana se llene. Los presupuestos prácticos de contexto seguro para modelos con ventana de 2M tienden a ubicarse entre 150K y 400K tokens para cargas de alta precisión, lo que es mucho menos que el límite anunciado. RAG (o el patrón híbrido de recuperar-luego-razonar) sigue siendo la arquitectura correcta para corpus grandes, multidocumento, frescos o multi-inquilino.

¿Qué es el context rot en términos sencillos?

El context rot es la observación de que los LLM usan el contexto largo peor de lo que sugieren los materiales de marketing. A medida que metes más tokens, la precisión en tareas de recuperación y razonamiento se degrada de forma no lineal. Empeora más rápido cuando el texto distractor es semánticamente similar a la respuesta, e incluso una entrada coherente y bien estructurada puede dañar la atención más que una entrada desordenada. El resultado: llenar una ventana de 1M tokens no te da una respuesta de calidad de 1M tokens.

¿Qué tan grande debería ser mi conjunto de recuperación antes de que se active el context rot?

Evalúa tu modelo específico. Un punto de partida aproximado: quédate entre el 20 y el 40 por ciento de la ventana de contexto documentada para cargas de alta precisión. Para un modelo con ventana de 200K, eso son entre 40K y 80K tokens de recuperación. Para un modelo con ventana de 1M, entre 200K y 400K. Construye un pequeño conjunto de eval con preguntas de razonamiento multi-salto y mide la precisión en distintos tamaños de contexto. Elige el tamaño más grande donde la precisión siga estando en tu rango de calidad.

¿El prompt caching cambia el cálculo?

Sí, de forma significativa. El prompt caching (disponible en Anthropic, Google y OpenAI) hace que el costo marginal de las consultas de contexto largo contra contenido estable sea mucho más barato. Si puedes cachear un conjunto grande de documentos de fondo y pagar solo por el delta por consulta, el contexto largo se vuelve económicamente competitivo con la recuperación para corpus relativamente estáticos. Sin embargo, el caching no arregla el context rot: el contexto largo cacheado sigue siendo contexto largo, con la misma degradación de precisión.

¿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 reranker (modelo cross-encoder que puntúa pares consulta-documento) sobre tus 50 a 200 chunks recuperados mejora dramáticamente la relevancia de lo que pasas a la etapa de contexto largo. Saltarse el rerank a menudo significa meter más tokens para compensar la menor precisión, lo que te empuja hacia la zona de rot. El rerank es una de las mejoras de mayor palanca que puedes hacerle a un pipeline híbrido.

---

Reflexiones finales

Lo seductor de cada nuevo lanzamiento de modelo con una ventana más grande es la promesa implícita: "deja de hacer ingeniería, solo vuélcalo". El artículo de Chroma puso números duros sobre por qué esa promesa no se ha cumplido, y la matemática subyacente (dilución del softmax, extrapolación de codificación de posiciones, distribución de entrenamiento) sugiere que no se cumplirá limpiamente ni siquiera cuando las ventanas de contexto crezcan a 100M tokens.

Lo que nos queda es la respuesta aburrida y productiva. Construye recuperación. Afínala. Añade un reranker. Elige un presupuesto de contexto seguro midiendo, no confiando en la hoja de especificaciones. Envíale al modelo el conjunto más pequeño y relevante de tokens que realmente contenga la respuesta. Deja que razone sobre eso. Cita las fuentes.

Esto es menos emocionante que "la AGI ya está aquí, solo pega tu base de código", pero entrega funciones que funcionan en producción. Los equipos que construyen en silencio buenos productos LLM en 2026 son los que trataron la narrativa del contexto largo con escepticismo y la narrativa de RAG con el mismo escepticismo, y terminaron con pipelines híbridos que manejan las cargas de trabajo que realmente tienen.

Las decisiones de arquitectura sobreviven a los lanzamientos de modelos. Acierta en esas y la próxima actualización de modelo será una mejora gratis en vez de una reescritura forzada.