La evolución del RAG: lo que realmente está pasando (desde la práctica)

En los últimos meses he estado bastante obsesionado con una pregunta muy concreta.

Todo empezó a raíz de trabajar en varios proyectos donde la recuperación de información era, literalmente, el cuello de botella del sistema.

Sistemas que tenían que consultar normativa, documentación institucional, bases de conocimiento extensas o estructuras técnicas complejas, donde una mala estrategia de retrieval hacía que el agente pareciera “tonto”, independientemente del modelo que usara.

Ahí fue cuando empecé a preguntarme en serio:

¿Cuál es la forma óptima de recuperar información para un agente de IA en mi sistema?

A partir de esa necesidad, he podido probar distintos enfoques en sistemas reales:

• RAG clásico con embeddings y bases vectoriales
• Búsqueda híbrida (keywords + semántica)
• Retrieval estructurado (buscar por carpetas, nombres de archivo, rutas y metadatos, como lo haría un humano)
• Retrieval agéntico inspirado en herramientas de agentes de código

Y tras experimentar con todos ellos en contextos donde el retrieval era crítico, la conclusión no es que el RAG esté muerto.

La conclusión es bastante más interesante (y útil):

El RAG no está desapareciendo. Está evolucionando.

El malentendido: “RAG = vector database”

Gran parte del debate actual parte de una simplificación excesiva.

Cuando mucha gente dice “RAG”, en realidad se refiere a:

Embeddings + vector database + similarity search

Pero eso no es el RAG en sí. Es solo la implementación más popular entre 2023 y 2024.

En esencia, RAG significa algo mucho más simple:

Cualquier sistema donde el modelo recupera información externa y la usa para razonar.

Bajo esta definición, incluso un agente que usa herramientas para buscar archivos, ejecutar comandos o consultar APIs sigue siendo un sistema RAG. Solo que con otro tipo de retrieval.

RAG puede entenderse, como una solución a una limitación muy concreta: no podemos introducir todo el conocimiento disponible en la ventana de contexto del LLM, así que el sistema debe recuperar de forma selectiva solo la información relevante e inyectarla en el contexto para que el modelo razone mejor.

Cuando el RAG clásico deja de ser suficiente

Al principio, implementé el pipeline típico:

• Chunking de documentos
• Generación de embeddings
• Indexación en base vectorial
• Similarity search
• Inyección de contexto en el prompt

Este enfoque funciona especialmente bien cuando el conocimiento es difuso y no estructurado: PDFs, documentación larga, correos, FAQs, etc.

Pero al trabajar con sistemas más complejos (repositorios, documentación técnica organizada, estructuras jerárquicas), empecé a notar algo importante:

No siempre necesitamos “similitud semántica”. A veces necesitamos precisión estructural.

La diferencia clave: datos no estructurados vs estructurados

Aquí está el punto que cambia todo el diseño de arquitectura.

El RAG clásico brilla cuando trabajamos con lenguaje natural ambiguo:

• Documentación extensa
• Bases de conocimiento corporativas
• Contenido textual desordenado
• Información con sinónimos y matices

En estos casos, los embeddings son insustituibles porque capturan relaciones conceptuales.

Pero cuando el agente opera sobre información estructurada, el escenario cambia radicalmente:

• Código fuente
• APIs
• bases de datos
• documentación técnica bien organizada
• sistemas con jerarquías claras (carpetas, módulos, endpoints)

Aquí no buscamos “algo parecido”. Buscamos algo exacto.

Por qué los agentes modernos usan menos RAG vectorial en código

Si observas cómo funcionan los agentes de programación actuales, verás un patrón claro:

No dependen principalmente de vector databases para entender un repositorio.

En su lugar, utilizan lo que podríamos llamar retrieval agéntico:

• Navegación por carpetas
• Búsqueda con herramientas tipo grep o glob
• Lectura selectiva de archivos
• Exploración iterativa del contexto

Esto tiene ventajas técnicas muy reales.

1. Coherencia con sistemas estructurados

El código y las arquitecturas software tienen nombres exactos, rutas y relaciones explícitas. No hay la misma ambigüedad que en el lenguaje natural.

Un buen grep puede ser más preciso que una búsqueda semántica en muchos casos.

2. Menor complejidad operativa

Mantener un índice vectorial actualizado en sistemas que cambian constantemente (como repositorios o documentación viva) introduce fricción:

• pipelines de reindexación
• costes de cómputo
• riesgo de desincronización

En producción, esto no es trivial.

3. Retrieval dirigido en lugar de probabilístico

La similarity search devuelve fragmentos “probablemente relevantes”.

El retrieval agéntico permite algo distinto:

• localizar un archivo exacto
• inspeccionar una función concreta
• recorrer la arquitectura paso a paso

Menos ruido. Más control.

Pero no: el RAG clásico no ha muerto

Decir que el RAG ha muerto es, técnicamente, incorrecto.

Intenta resolver solo con búsqueda por keywords o exploración iterativa problemas como:

• miles de documentos legales
• bases de conocimiento empresariales
• repositorios documentales masivos
• atención al cliente basada en documentación

La latencia y el coste se disparan.

Y, más importante aún, pierdes la capacidad de recuperar información por similitud conceptual: sinónimos, referencias indirectas, contexto implícito.

Ahí los embeddings siguen siendo críticos.

El cambio real: del RAG estático al retrieval agéntico

Lo que estamos viendo no es una sustitución, sino una evolución arquitectónica.

Antes:

Query → Vector Search → Contexto

Ahora, en sistemas más avanzados:

Query → Planificación → Selección de herramientas → Retrieval iterativo → Síntesis

El agente ya no solo busca información. Decide cómo buscarla según la naturaleza del problema.

Puede combinar dinámicamente:

• búsqueda semántica
• búsqueda estructurada
• navegación jerárquica
• lectura incremental

Implicaciones reales para sistemas empresariales

Desde la experiencia construyendo soluciones para organizaciones (con documentación institucional, normativa y bases de conocimiento complejas), esta distinción no es académica. Es de arquitectura.

Cuándo usar RAG clásico

• Soporte basado en documentación extensa
• Compliance y normativa
• Atención al cliente con base documental
• Conocimiento corporativo difuso

Cuándo usar retrieval estructurado o agéntico

• Sistemas que interactúan con código
• Automatizaciones sobre APIs y workflows
• Herramientas internas con datos bien definidos
• Agentes que operan sobre arquitecturas claras

Qué funciona mejor en producción (casi siempre)

Un enfoque híbrido.

Un buen agente debería poder:

• usar embeddings cuando el conocimiento es difuso
• usar retrieval estructurado cuando la información es precisa
• elegir la estrategia de recuperación según la tarea

Reflexión final: menos obsesión con el modelo, más con el retrieval

En muchos proyectos de IA, el foco sigue estando casi exclusivamente en el modelo.

Pero en la práctica, el rendimiento real de un sistema depende muchísimo más de cómo accede a la información que del LLM que utilice.

La pregunta clave ya no es:

“¿Qué modelo usamos?”

Sino:

“¿Cómo diseñamos el sistema de retrieval que alimenta a ese modelo?”

Porque, al final, un modelo sin buen acceso a información relevante es solo un generador elegante de respuestas plausibles.

Desde la experiencia construyendo agentes en entornos reales, la conclusión es bastante clara:

El RAG no ha muerto.

Se está volviendo más inteligente y eficiente.