¿Se han quedado obsoletos los RAG's?

La industria tecnológica tiene una tendencia clara a declarar obsoleta cualquier técnica en cuanto aparece una mejora incremental en modelos. Con las ventanas de contexto creciendo de forma acelerada, algunos han empezado a preguntarse si los RAG (Retrieval-Augmented Generation) se han quedado obsoletos, ya que si podemos volcar terabytes de información en un modelo con capacidad de procesarlos, ¿para qué complicarse con pipelines de recuperación, embeddings y re-rankers? La pregunta es cuanto menos legítima, pero la conclusión no lo es tanto.

Es cierto que disponer de ventanas de contexto más amplias facilita ciertas tareas concretas. En usos ad hoc, como analizar un número limitado de documentos o hacer comparativas internas, ampliar el contexto reduce fricción operativa: puedes volcar más información en el modelo y obtener una respuesta sin necesidad de diseñar un sistema de recuperación complejo. Para demos o pruebas de concepto esto suele funcionar bien. El problema surge cuando se intenta pasar de esa demo a un producto en producción. En entornos SaaS o en despliegues enterprise, volcar todos los datos disponibles en cada prompt no es una estrategia, es una temeridad técnica. Primero por precisión: Gregory Kamradt popularizó el benchmark “Needle in a Haystack”, que mostraba cómo la capacidad de recuperación efectiva dentro de un gran bloque de contexto se degrada a medida que aumenta el ruido irrelevante. No tenemos acceso a todos los experimentos replicados en producción, pero el patrón es consistente con lo observado en múltiples implementaciones: añadir contexto indiscriminado no mejora la calidad, la diluye. Si nos basamos en los comportamientos observados en LLMs, los modelos tienden a priorizar información al inicio y al final de los bloques de texto, con menor atención efectiva en zonas intermedias cuando el volumen crece. Si se inyectan millones de tokens sin curación previa, el riesgo de perder la señal relevante aumenta.

En segundo lugar, está el asunto de los permisos. En un entorno corporativo, el acceso a datos no es homogéneo: un pipeline de RAG bien diseñado incorpora capas de control de acceso que garantizan que cada consulta solo recupere documentos que el usuario tiene derecho a ver. Si la alternativa es cargar “todo el data lake” en cada prompt y confiar en que el modelo ignore lo que no corresponde, estamos ante un problema de seguridad serio. No es una cuestión teórica; es una cuestión de gobernanza y cumplimiento normativo.

El tercer factor es la latencia. En producto, la experiencia de usuario no se negocia. Procesar grandes volúmenes de tokens incrementa tiempos de respuesta y costes de inferencia y aunque los modelos mejoren su eficiencia, el coste y el tiempo seguirán correlacionados con la longitud del prompt. Un chatbot interno que tarda minutos en responder puede funcionar en un piloto, pero difícilmente encontrará encaje real en un flujo operativo.

A estos tres argumentos se han sumado otros más técnicos: uno es el riesgo de alucinaciones; más contexto no implica menos invención, en ocasiones, implica más confusión. Cuando el modelo recibe información heterogénea y extensa, puede mezclar fuentes o generar respuestas con aparente coherencia pero débil trazabilidad. En sectores regulados, donde la exigencia es “legal-grade AI”, el grounding explícito mediante RAG sigue siendo la vía más defendible. Otro es el coste por query. Incluso preguntas simples tendrían que “pagar” el precio computacional de un contexto masivo si se opta por la estrategia de volcado total. En sistemas de alto volumen, ese diferencial no es marginal, es estructural. También está la cuestión de frescura de datos. Si dos palabras cambian en una página de precios, ¿tiene sentido reenviar el corpus completo en cada llamada? Los sistemas de recuperación permiten reindexar selectivamente y mantener actualizaciones granulares sin rehacer el prompt entero. Y quizá más relevante en términos de confianza, está la trazabilidad. Cuando el sistema recupera chunks concretos y puede citarlos con precisión, el usuario sabe de dónde proviene la respuesta. Frente a un contexto de un millón de tokens, la explicación “la respuesta está en este bloque enorme” pierde valor operativo.

Ahora bien, tampoco conviene convertir los RAG’s en dogma. Las ventanas de contexto más amplias sí cambian la forma en que se implementa. Reducen la obsesión por el chunking extremo, permiten incluir más contexto circundante y simplifican ciertas decisiones de ingeniería. En documentos pequeños, puede ser razonable inyectar piezas completas en lugar de fragmentarlas en exceso. No se trata de si usar RAG o no, sino de cómo ajustar la estrategia a cada caso. Hay incluso expertos que sostienen que los flujos agénticos o ciertos enfoques basados en ejecución de código pueden desplazar partes del RAG tradicional. Es posible que en determinados escenarios esto ocurra, pero no tenemos datos comparativos exhaustivos que permitan afirmarlo como tendencia consolidada, aunque sí parece claro que el problema de fondo sigue siendo el mismo: seleccionar la información adecuada antes de pasarla al modelo. Podemos usar la llamada analogía del bibliotecario: ¿Es más eficiente alguien que hojea todos los libros de la biblioteca antes de responder o alguien que sabe localizar los dos volúmenes pertinentes y trabajar sobre ellos? Mientras el espacio de recuperación potencial sea “todo internet” más los repositorios internos de una compañía, la lógica de recuperación selectiva no pierde sentido. En entornos como el publicitario o el de MarTech, donde los datasets son voluminosos, sensibles y cambiantes, esto es especialmente crítico. Las implementaciones reales no fallan por falta de tokens, fallan por falta de gobernanza, por ruido excesivo o por latencias incompatibles con el negocio. Observando despliegues empresariales recientes, el trabajo más complejo no está en ampliar el contexto, sino en diseñar capas de acceso, relevancia y evaluación continua. La ventana de contexto es un parámetro técnico; la estrategia es otra cosa.

Dicho todo esto, los RAG’s no están muertos, pero tampoco están intactos. Los entornos RAG están evolucionando bajo nuevas restricciones y nuevas oportunidades. Ventanas de contexto más largas no eliminan la necesidad de recuperación inteligente sino que elevan el listón de cómo debe hacerse. En un producto real, el equilibrio entre precisión, seguridad, coste y experiencia de usuario sigue siendo la variable decisiva y mientras ese equilibrio importe, la recuperación selectiva seguirá formando parte del núcleo arquitectónico.