«RAG ha muerto» es un error de categoría

Hay un titular que vuelve como un reloj cada vez que crecen las ventanas de contexto: «RAG ha muerto». Llegó la ventana de un millón de tokens, así que seguro puedes meterlo todo en el prompt y borrar tu pipeline de recuperación. Es una historia limpia, se vuelve tendencia cada pocos meses, y se ha equivocado cada vez. Vale la pena entender por qué — porque el error es un patrón de pensamiento, no un hecho sobre RAG.

Técnica vs. problema

«RAG ha muerto» confunde una técnica con el problema que resuelve. RAG — retrieval-augmented generation — es una implementación. El problema que hay debajo es permanente: poner el contexto correcto delante del modelo, de forma barata y trazable. Ese problema no desaparece cuando la ventana se agranda. Si acaso se vuelve más difícil, porque ahora puedes volcarlo todo dentro — y el modelo ignora silenciosamente la parte del medio mientras tu factura se dispara.

Solo la economía ya mata el plan de «usa contexto largo y ya»: la recuperación es según los informes de 8 a 82 veces más barata que meter un contexto largo para cargas de trabajo típicas, y con mejor latencia. Pagar por empujar 400k tokens a través del modelo en cada llamada, para que pase de largo junto al único párrafo que importaba, no es una mejora frente a traer ese párrafo.

Lo que sí murió

Algo sí murió — pero no la recuperación. El RAG ingenuo murió: trocéalo todo, incrústalo, similitud coseno top-k, y a cruzar los dedos. Esa receta concreta siempre fue frágil, y la está reemplazando una recuperación más inteligente, no ausente. El consenso emergente es «el RAG ingenuo ha muerto, el RAG sofisticado prospera»: búsqueda híbrida, recuperación como una acción agéntica que el modelo elige cuando la necesita, grep y consultas estructuradas junto a los vectores, un fetch de alto recall con el modelo haciendo el filtrado final. La técnica evolucionó. La necesidad no se movió ni un centímetro.

«X ha muerto» es casi siempre alguien confundiendo la implementación actual con el problema permanente. La fontanería cambia constantemente. Aquello para lo que sirve la fontanería casi nunca cambia.

El patrón es lo importante

Esto vale la pena interiorizarlo más allá de RAG, porque vas a oír «X ha muerto» sobre algo cada trimestre: prompt engineering, fine-tuning, agentes, RAG, lo que venga después. Pásalo por el mismo filtro cada vez:

• Separa la necesidad de la herramienta. ¿Qué problema permanente resolvía esta técnica? La recuperación: meter el contexto correcto. Esa necesidad no está en la lista de deprecación.
• Pregunta qué se rompió exactamente. Normalmente es la versión ingenua, y la «muerte» es en realidad una evolución. «El X ingenuo ha muerto, el buen X prospera» es el titular honesto nueve de cada diez veces.
• Sigue la economía y los modos de fallo. El enfoque más barato, más trazable y más depurable gana en producción sin importar qué esté de moda. El contexto largo perdió por coste y por el-medio-es-un-cementerio, no por capacidad.
• Desconfía del «mételo todo y ya». Cualquier propuesta que termine en «ya no necesitas la disciplina» suele venderte un cubo más grande, no una respuesta mejor.

Para mí esto conecta directo con el grounding: poner el contexto correcto y verificable delante del modelo es todo el juego, y la recuperación es cómo lo haces. Ese requisito no está muriendo — las herramientas para cumplirlo simplemente siguen mejorando, que es lo contrario de estar muerto.

En resumen

«RAG ha muerto» vuelve cada vez que crece la ventana y pierde el punto cada vez: mata una técnica y declara resuelto el problema, cuando el problema — contexto correcto, barato, trazable — está exactamente tan vivo como siempre lo estuvo.

No jubiles la necesidad cuando la implementación cambie. Cuando oigas «X ha muerto», pregunta qué problema resolvía X — y si ese problema de verdad se fue a algún lado. Normalmente no lo hizo.