El ciclo se repite cada pocos meses con una puntualidad sospechosa. Un laboratorio anuncia una ventana de contexto más grande, el anuncio se convierte en captura de pantalla, y en la siguiente reunión alguien dice la frase: «entonces ya no necesitamos el RAG, metemos los documentos enteros en el prompt y listo». Suena a simplificación, que es lo que todo el mundo quiere oír de una arquitectura que le ha costado meses montar. Y es la clase de simplificación que se paga tres veces: en precisión, en factura y en la madrugada en que algo responde mal y nadie sabe por qué.
La tesis en una línea: «ventana de contexto grande o RAG» no es una disyuntiva, porque las dos cosas no resuelven el mismo problema. La ventana de contexto es una medida de capacidad —cuánto cabe en una llamada—. La recuperación es una decisión de selección —qué entra, de todo lo que tienes—. Aumentar la primera no responde la segunda. Y cuando renuncias a decidir qué entra, lo que ocurre está medido: la precisión cae mucho antes del límite anunciado, el coste por llamada sube con la tarifa en la mano, y el fallo deja de ser depurable porque ya no sabes qué fragmento usó el modelo.
Esto no va de defender una arquitectura por cariño. Hay casos —están al final, con nombre— en los que la ventana grande es efectivamente la respuesta correcta y montar recuperación sería sobreingeniería. Va de que la decisión se tome por los motivos reales y no por el titular de un lanzamiento.
Ventana de contexto grande o RAG: no es la misma pregunta hecha dos veces
La confusión tiene una raíz concreta: las dos cosas acaban en el mismo sitio —texto delante del modelo en el momento de responder— y por eso parecen intercambiables. No lo son. La ventana de contexto es el espacio de trabajo de esta llamada: se llena, se usa y se vacía. La recuperación es el mecanismo que elige, de un corpus que no cabe ni cabrá nunca, los fragmentos que merecen ocupar ese espacio. Una es el tamaño de la mesa; la otra es quién decide qué papeles se ponen encima.
La taxonomía completa —contexto de la conversación, conocimiento consultable y memoria a largo plazo, con dónde vive cada capa y qué cuesta— ya está escrita en la guía sobre la memoria de un agente de IA, y no tiene sentido reargumentarla aquí. Lo que aquella guía no cubre, porque no es su pregunta, es esta: qué pasa exactamente cuando el mercado te ofrece más mesa y tú decides que con eso te ahorras al que elige los papeles.
Lo que se rompe primero no es el límite: es la precisión
La parte contraintuitiva es que el problema aparece mucho antes de llenar la ventana. Un modelo con un millón de tokens anunciados no mantiene su calidad hasta el token 999.999 y luego se cae por un acantilado: se degrada de forma progresiva, y bastante pronto. El benchmark NoLiMa lo midió con un diseño que evita el atajo del que adolecían las pruebas anteriores de «aguja en el pajar» —en NoLiMa la pregunta y el fragmento relevante casi no comparten palabras, así que el modelo no puede encontrarlo por coincidencia literal y tiene que inferir la asociación, que es exactamente lo que le pides en producción—.
Los resultados: GPT-4o partía de un 99,3% con contexto corto y bajaba al 69,7% en 32K tokens y al 56% en 128K. Y no era un caso aislado: a 32K, 11 de los 13 modelos evaluados caían a la mitad o menos de su propia línea base en contexto corto. Fuente: NoLiMa: Long-Context Evaluation Beyond Literal Matching, Modarressi et al., arXiv, febrero de 2025.
A esto se le suma un efecto de posición documentado antes y de forma independiente: la precisión depende de dónde esté la información dentro del contexto. El trabajo que acuñó el término describe una curva en U —el modelo recupera razonablemente bien lo que está al principio y al final del contexto, y falla con lo que queda en el medio—. Fuente: Lost in the Middle: How Language Models Use Long Contexts, Liu et al., Transactions of the ACL, 2024.
Juntos, los dos efectos describen el modo de fallo real de la estrategia «métele todo». No es que el modelo se niegue a responder: es que responde con aplomo usando lo que encontró, que no es necesariamente lo que importaba. La respuesta llega bien escrita, bien estructurada y mal fundamentada. Es el peor tipo de error que puede tener un sistema de empresa, porque no se distingue de un acierto sin ir a comprobarlo a mano.
| Lo que dice el anuncio | Lo que mide el benchmark | Qué implica para tu sistema |
|---|---|---|
| «Ventana de 1M de tokens» | La degradación empieza muy por debajo de ese número | El límite anunciado es capacidad de entrada, no garantía de calidad |
| «Cabe tu documentación entera» | A 32K, 11 de 13 modelos caen a ≤50% de su base (NoLiMa, 2025) | Caber no es lo mismo que usarse |
| «El modelo encuentra lo que necesita» | Lo que está en el medio del contexto se recupera peor (Liu et al., 2024) | El orden en que apilas los documentos pasa a ser una variable oculta |
| «Te ahorras montar recuperación» | Los benchmarks no miden la factura ni la trazabilidad | El ahorro de ingeniería se transforma en coste recurrente y en opacidad |
El proveedor que te vende el millón de tokens te lo cobra al doble
Aquí no hace falta argumentar nada: basta con leer la tarifa del que vende la ventana grande. En la lista de precios pública de la API de Gemini, dos modelos tienen el precio partido por longitud del prompt, con el corte exactamente en 200.000 tokens. En Gemini 3.1 Pro Preview, tarifa estándar, la entrada pasa de 2,00 a 4,00 dólares por millón de tokens al cruzar ese umbral, y la salida de 12,00 a 18,00. En Gemini 2.5 Pro, de 1,25 a 2,50 la entrada y de 10,00 a 15,00 la salida. El caché de contexto también dobla. Fuente: Gemini Developer API pricing, Google, consultada el 4 de octubre de 2026.
Lo relevante no es el importe, que cambiará. Es la forma de la tarifa: el proveedor que te ofrece la ventana enorme ha decidido cobrarte el doble por usarla de verdad. Eso es una declaración sobre el coste real de atender esos prompts, escrita por quien lo paga. Cuando alguien te plantea «ventana de contexto grande o RAG» como si la primera opción fuera la gratuita, está ignorando que el propio fabricante la ha tarifado como un producto distinto y más caro.
Y el efecto compuesto es lo que descoloca presupuestos. La recuperación concentra el gasto en montar y mantener un índice: un coste que existe una vez y se amortiza en todas las consultas. Meterlo todo en el prompt mueve ese gasto al lado variable, donde se multiplica por cada llamada, cada día, para siempre. Un piloto con doscientas consultas al mes no lo nota. El mismo sistema abierto a trescientas personas, sí. El aritmética es aburrida y por eso nadie la hace antes de la reunión: multiplica tus tokens de entrada por tu volumen esperado y compáralo con lo que cuesta un índice. La guía sobre qué modelo usar en un agente tiene el resto de los ejes de esa decisión, porque el tamaño de ventana es una especificación entre varias y casi nunca la que decide.
El fallo que no puedes depurar
Este es el argumento que no aparece en ningún benchmark y el que más caro sale en operación. Con recuperación, cuando una respuesta sale mal tienes un rastro: sabes qué fragmentos se recuperaron, con qué consulta y con qué puntuación. El diagnóstico se reduce a dos preguntas con respuesta —¿el fragmento correcto estaba en el índice?, ¿lo recuperó?— y cada una apunta a un arreglo distinto: reingestar la fuente o ajustar la recuperación.
Sin recuperación no hay rastro, porque no hubo selección que registrar. Le pasaste doscientos mil tokens y el modelo usó lo que usó. No puedes saber en qué se apoyó, no puedes reproducir el camino y no puedes arreglarlo con una intervención acotada: tu única palanca es reordenar documentos y volver a probar, que es depurar por superstición. En un sistema interno con tolerancia alta eso es una molestia. En un sistema que responde a clientes o alimenta una decisión, es la diferencia entre un incidente que se cierra y uno que se queda abierto.
Cuándo la ventana grande sí es la respuesta correcta
Montar recuperación sobre un corpus que no la necesita es la otra forma de equivocarse, y es más común de lo que parece. Hay tres situaciones en las que la ventana grande gana limpiamente:
- El corpus es pequeño y estable. Si todo lo que el sistema necesita consultar cabe holgadamente por debajo del umbral donde el modelo se degrada, y no cambia cada semana, un índice es infraestructura que hay que mantener para no ganar nada.
- La evidencia está repartida por todo el documento. Cuando la tarea es sintetizar, comparar secciones o detectar contradicciones a lo largo de un texto largo, la recuperación trabaja en contra: trocear es precisamente lo que destruye la relación entre las partes. Aquí el contexto largo no es un lujo, es el requisito.
- Es un análisis puntual, no un sistema. Un contrato, un informe, un volcado de datos que se analiza una vez. Nadie debería montar una canalización de ingesta para una pregunta que se hace una sola vez.
La lectura honesta de la literatura reciente es que el planteamiento binario está desfasado por los dos lados: el contexto largo rinde mejor cuando la evidencia está distribuida, y la recuperación rinde mejor cuando la evidencia es escasa y hay que encontrarla. La arquitectura que está ganando no elige: recupera para acotar el universo a lo plausible y después usa la ventana larga para razonar sobre ese conjunto ya reducido. La recuperación deja de ser un filtro de precisión quirúrgica y pasa a ser un reductor de ruido, lo cual relaja bastante los requisitos de tu índice.
La prueba de los dos minutos antes de tirar nada
Si alguien en tu equipo propone retirar la recuperación porque salió un modelo con más contexto, estas cuatro preguntas resuelven la conversación sin reunión de seguimiento:
- ¿Cuántos tokens tiene el corpus completo, hoy y en doce meses? Si la respuesta a doce meses cruza el umbral donde el modelo se degrada —y está muy por debajo del límite anunciado—, la ventana no es una solución, es una prórroga.
- ¿Cuánto costaría el volumen real de consultas a tarifa de prompt largo? Con el precio partido en 200K tokens, el cálculo se hace en una hoja. Hazlo con el volumen al que aspiras, no con el del piloto.
- ¿La evidencia típica está en un sitio o repartida? Puntual y localizada: recuperación. Distribuida por todo el documento: contexto largo. Las dos cosas según la pregunta: híbrido, y es la respuesta más frecuente.
- ¿Qué respondes cuando un cliente pregunta de dónde salió esa frase? Si la respuesta tiene que ser verificable, necesitas el rastro de qué entró. Eso solo lo da la selección.
Ninguna de las cuatro se contesta con el tamaño de la ventana, y eso es justo lo que se intentaba demostrar.
Lo que esto cambia en la operación
Hay una razón menos técnica por la que la propuesta de tirar el RAG resulta tan atractiva, y conviene nombrarla: no es que la ventana grande sea mejor, es que mantener un índice es un trabajo continuo y a nadie le apetece hacerlo. El conocimiento envejece, las fuentes cambian, los documentos se sustituyen, y si nadie reingesta ni invalida lo caduco, el sistema empieza a responder con la versión del año pasado. Esa es la grieta real que explota el argumento del contexto infinito: promete deshacerse de una función operativa, no de una pieza de software.
El problema es que la función no desaparece, solo se vuelve invisible. Si metes los documentos enteros en el prompt, sigues necesitando que esos documentos sean los vigentes —solo que ahora no tienes ni índice ni pipeline donde comprobarlo—. Por eso la frescura de la base de conocimiento es una función continua que se opera, no un proyecto que se cierra: el refresco por fuente, la invalidación de lo caduco y el dueño de cada decisión editorial existen igual, con RAG o sin él.
Y si la discusión que tienes abierta de verdad no es esta sino la otra —si hay que reentrenar el modelo con tus datos—, está resuelta en otro sitio y con la misma lógica: casi siempre gana la opción de recuperar frente a la de hacer fine-tuning, por coste y por capacidad de actualizar sin reentrenar. Las tres conversaciones —ventana, recuperación y entrenamiento— se mezclan en las mismas reuniones y conviene tenerlas separadas, porque solo una de ellas cambia cuando sale un modelo nuevo.
La conclusión operativa es corta. Más contexto es una buena noticia: te deja pasar más evidencia relevante por llamada y relaja la precisión que le exiges a tu recuperación. Lo que no hace es decidir qué es relevante. Ese trabajo lo sigue haciendo alguien —un índice, una consulta, una política— o no lo hace nadie, y entonces lo que tienes no es una arquitectura más simple: es la misma complejidad, sin registro y a tarifa doble.