Las cinco arquitecturas RAG que explican por qué muchos proyectos de IA se quedan en la demo

Durante mucho tiempo, hablar de RAG parecía hablar de una receta sencilla: coges unos documentos, los troceas, los conviertes en vectores, haces una búsqueda semántica y le pasas los fragmentos más relevantes a un modelo de lenguaje para que responda.

La secuencia era elegante: embed, retrieve, generate. Convertir, recuperar, generar.

Y en una demo funciona.

Funciona cuando el documento es limpio, cuando la pregunta es sencilla, cuando la respuesta está contenida en un único fragmento y cuando el usuario pregunta más o menos con las mismas palabras con las que está escrito el contenido original.

Pero las empresas no trabajan así.

Las empresas tienen PDFs mal estructurados, tablas incrustadas, anexos, imágenes, contratos, correos, bases de datos, informes, normativas, notas internas, excepciones, decisiones previas y conocimiento distribuido entre personas, sistemas y documentos. Y, sobre todo, tienen preguntas reales. Preguntas ambiguas, incompletas, mal formuladas o que requieren conectar información dispersa.

Ahí es donde el RAG ingenuo empieza a fallar.

No porque el concepto sea malo. Al contrario. RAG sigue siendo una de las piezas fundamentales de la inteligencia artificial aplicada a empresas. Pero la versión simple de RAG no basta para entornos reales. Es un punto de partida, no una arquitectura final.

La diferencia entre un prototipo bonito y un sistema útil está precisamente en cómo se diseña la recuperación de información. No se trata solo de “buscar documentos”. Se trata de construir una forma fiable de encontrar, validar, relacionar y usar contexto empresarial.

Por eso empiezan a imponerse arquitecturas RAG más avanzadas. No como modas técnicas, sino como respuestas a problemas muy concretos que aparecen cuando los usuarios reales empiezan a utilizar el sistema.

El problema del RAG ingenuo

El RAG básico parte de una idea razonable: si el modelo no sabe algo, le damos información externa antes de responder. Para ello se crea un índice vectorial de documentos y, cuando el usuario pregunta, el sistema busca los fragmentos más parecidos semánticamente.

El problema es que “parecido semánticamente” no siempre significa “correcto”.

Una pregunta puede depender de varias partes de varios documentos. Puede contener términos técnicos que el modelo de embeddings interpreta mal. Puede necesitar una palabra exacta, un código, una referencia normativa o el nombre concreto de un producto. Puede requerir entender una relación entre entidades, no solo encontrar un párrafo. O puede estar en una tabla, en una imagen o en un gráfico que el sistema nunca ha entendido realmente.

En esos casos, el RAG básico recupera algo que parece razonable, el modelo genera una respuesta plausible y el usuario recibe una contestación que puede ser incompleta, imprecisa o directamente equivocada.

Ese es el gran riesgo: no siempre falla de forma evidente. A veces falla con seguridad.

Y en una empresa eso es mucho más peligroso que no responder.

La evolución de RAG consiste, por tanto, en introducir más inteligencia en la recuperación. No solo más inteligencia en el modelo que responde, sino en todo el proceso anterior: cómo se busca, cómo se combina, cómo se valida, cómo se corrige y cómo se interpreta el contexto.

A partir de ahí aparecen cinco arquitecturas especialmente relevantes.

1. Hybrid RAG: cuando buscar por significado no es suficiente

La primera evolución natural es el RAG híbrido.

El RAG tradicional suele apoyarse en búsquedas vectoriales. Es decir, convierte los textos en representaciones matemáticas que permiten encontrar fragmentos parecidos por significado. Esto es muy útil cuando el usuario no utiliza las mismas palabras que aparecen en el documento.

Si alguien pregunta “¿qué obligaciones tiene el proveedor tras la firma?”, el sistema puede encontrar una cláusula que habla de “compromisos posteriores a la formalización del contrato”, aunque no coincidan exactamente las palabras.

Eso es potente.

Pero también tiene límites.

Hay casos en los que las palabras exactas importan mucho. Un número de expediente. Una referencia legal. Una marca. Un código interno. El nombre de una tecnología. Un acrónimo. Un concepto sectorial que los embeddings no interpretan bien.

Ahí entra BM25, la búsqueda clásica por palabras clave. BM25 no “entiende” como un modelo vectorial, pero encuentra términos concretos con mucha precisión. Si buscas “ISO 27001”, “CEGID”, “Plan BOOST” o “artículo 17.3”, quieres que el sistema encuentre exactamente eso, no algo semánticamente parecido.

Hybrid RAG combina ambos enfoques: búsqueda densa por significado y búsqueda dispersa por palabras exactas. Después fusiona los resultados mediante técnicas como Reciprocal Rank Fusion, que permite combinar rankings distintos y priorizar los fragmentos que aparecen bien posicionados en ambas búsquedas.

La lógica es sencilla: los vectores ayudan a encontrar sentido; BM25 ayuda a encontrar precisión.

En empresas, esta arquitectura suele ser una base mucho más sólida que el RAG puramente vectorial. Porque la información empresarial está llena de lenguaje específico, referencias internas, códigos, nombres propios y términos que no pueden depender solo de una aproximación semántica.

Un ejemplo claro sería un chatbot interno para resolver dudas sobre procedimientos de compras. Si un empleado pregunta por “proveedores homologados para mantenimiento industrial”, la búsqueda vectorial puede encontrar documentos relacionados con compras, proveedores y mantenimiento. Pero si el procedimiento contiene una referencia concreta como “PR-COM-042”, la búsqueda por palabras exactas puede ser decisiva.

Hybrid RAG no es la arquitectura más sofisticada, pero probablemente es una de las más sensatas para empezar. Es una mejora práctica, robusta y aplicable a casi cualquier equipo.

No intenta convertir la recuperación en un sistema inteligente completo. Simplemente reconoce una verdad básica: en la información empresarial, el significado importa, pero las palabras exactas también.

2. GraphRAG: cuando la respuesta está en las relaciones

Hay preguntas cuya respuesta no vive en un fragmento concreto.

Vive en la relación entre varios elementos.

Este es el territorio de GraphRAG.

En un RAG tradicional, los documentos se dividen en chunks. Cada fragmento se guarda en un índice y se recupera cuando parece relevante. Pero muchas preguntas empresariales no consisten en encontrar un párrafo aislado, sino en entender cómo se conectan personas, proyectos, clientes, tecnologías, incidencias, proveedores, productos o decisiones.

GraphRAG intenta resolver ese problema construyendo un grafo de conocimiento.

Un grafo de conocimiento representa entidades y relaciones. Las entidades pueden ser personas, empresas, proyectos, ubicaciones, productos o conceptos. Las relaciones explican cómo se conectan entre sí: trabaja en, pertenece a, depende de, está relacionado con, suministra a, afecta a, compite con, deriva de.

La diferencia es importante.

Un índice vectorial responde buscando similitud. Un grafo responde explorando conexiones.

Por ejemplo, imaginemos una empresa industrial que quiere preguntar: “¿Qué clientes podrían verse afectados si cambiamos este proveedor?”. Es posible que ningún documento contenga exactamente esa respuesta. Pero puede haber contratos, pedidos, incidencias, albaranes, referencias técnicas y relaciones entre productos y proveedores que, conectadas, permiten construirla.

GraphRAG no recupera únicamente fragmentos. Recupera subgrafos, comunidades de entidades y resúmenes de relaciones. Es decir, puede identificar zonas del conocimiento donde varios elementos están conectados y ofrecer una respuesta más estructural.

Esto es especialmente útil cuando el valor no está en el dato individual, sino en el mapa.

En consultoría, estrategia, innovación, gestión de clientes, análisis de riesgos o inteligencia competitiva, muchas veces la pregunta importante no es “dónde aparece esta palabra”, sino “qué está relacionado con esto”. Y ahí el RAG clásico se queda corto.

GraphRAG tiene también una lectura muy empresarial: convierte documentación dispersa en una estructura navegable de conocimiento. No solo permite responder mejor. Permite descubrir conexiones que antes estaban implícitas.

Pero también tiene más complejidad. Hay que extraer entidades, definir relaciones, evitar grafos ruidosos, mantenerlos actualizados y decidir qué nivel de abstracción interesa. No todo proyecto necesita GraphRAG. Pero cuando las respuestas dependen de relaciones, procesos o redes de dependencias, puede marcar una diferencia enorme.

GraphRAG encaja muy bien con una idea que cada vez será más importante: la inteligencia artificial no solo necesita información, necesita contexto organizado.

3. Agentic RAG: cuando recuperar información se convierte en un plan

En el RAG básico, la recuperación es un paso.

El usuario pregunta, el sistema busca, el modelo responde.

En Agentic RAG, la recuperación deja de ser un paso y se convierte en una estrategia.

La diferencia está en que un agente no tiene por qué limitarse a una única búsqueda. Puede planificar, decidir qué herramienta utilizar, comprobar si la información es suficiente, reformular la búsqueda, consultar una base de datos, llamar a una API, navegar por documentos, contrastar resultados y volver a intentarlo.

Esto cambia completamente la naturaleza del sistema.

En lugar de una tubería fija, tenemos un bucle de trabajo.

Un planner agent puede decidir qué camino seguir. Si la pregunta parece documental, usa búsqueda vectorial. Si requiere datos estructurados, consulta SQL. Si necesita información actualizada, utiliza búsqueda web o una fuente externa autorizada. Si la respuesta no es suficiente, vuelve a buscar. Si detecta contradicciones, intenta resolverlas.

Después, un reasoner agent puede organizar la información, evaluar la solidez de la respuesta y producir una conclusión.

Esto se parece mucho más a cómo trabaja una persona competente.

Cuando alguien en una empresa recibe una pregunta compleja, no busca una vez y responde. Primero entiende qué le están preguntando. Luego decide dónde mirar. Consulta un documento, revisa una hoja de cálculo, pregunta a alguien, vuelve al documento, compara versiones y solo entonces responde.

Agentic RAG intenta llevar esa lógica al sistema.

Un ejemplo: un director financiero pregunta “¿qué clientes tienen mayor riesgo de retraso en el pago este trimestre y qué acciones deberíamos priorizar?”. La respuesta probablemente no está en un PDF. Puede requerir consultar facturas, vencimientos, histórico de pagos, notas comerciales, emails, incidencias abiertas y criterios internos de riesgo. Un RAG básico no basta. Un agente puede decidir qué fuentes consultar y en qué orden.

Esta arquitectura es especialmente importante en la era de los agentes porque conecta RAG con acción. Ya no hablamos solo de responder preguntas sobre documentos. Hablamos de sistemas capaces de usar información para ejecutar procesos, tomar decisiones asistidas o proponer acciones.

Pero también exige más control.

Cuanta más autonomía tiene el sistema, más importante es diseñar bien sus límites, sus herramientas, sus criterios de decisión y su observabilidad. Un Agentic RAG mal diseñado puede volverse errático. Uno bien diseñado puede convertirse en una capa operativa muy poderosa para la empresa.

La clave está en entender que el agente no sustituye a la recuperación. La orquesta.

4. Corrective RAG: no basta con recuperar, hay que comprobar

Uno de los grandes errores del RAG ingenuo es asumir que lo recuperado es útil.

Pero no siempre lo es.

A veces el sistema recupera documentos relacionados pero no suficientes. A veces encuentra información antigua. A veces el chunk contiene parte de la respuesta, pero falta una condición importante. A veces la pregunta está mal formulada y la búsqueda inicial no sirve. A veces los documentos recuperados son directamente irrelevantes.

Corrective RAG introduce una idea fundamental: antes de confiar en la información recuperada, hay que evaluarla.

El sistema incorpora un evaluador o grader que revisa si los documentos recuperados permiten responder bien. Si la recuperación es correcta, se pasa al modelo para generar la respuesta. Si es ambigua, el sistema reformula la consulta. Si es incorrecta o insuficiente, puede activar una búsqueda alternativa, acudir a otra fuente o incluso escalar el caso.

Esta arquitectura se parece mucho más a producción real.

Porque en producción no basta con que el sistema “encuentre algo”. Tiene que saber si lo que ha encontrado sirve.

En una demo, recuperar tres fragmentos aparentemente relevantes puede parecer suficiente. En una empresa, puede no serlo. Si el sistema responde a una pregunta legal, financiera, técnica o contractual con información mal recuperada, el problema no está en la generación; está en la confianza concedida al contexto equivocado.

Corrective RAG introduce una capa de prudencia.

Por ejemplo, si un empleado pregunta por la política de gastos de viaje y el sistema recupera una versión antigua del documento, el grader debería detectar que la información no es fiable o que no coincide con la versión vigente. Si la pregunta habla de “dietas internacionales” y los documentos recuperados solo tratan de “desplazamientos nacionales”, el sistema debería reformular o buscar mejor antes de responder.

Esto es especialmente relevante para empresas que necesitan trazabilidad y control. No se trata solo de tener respuestas. Se trata de saber con qué evidencia se han construido.

Corrective RAG convierte la recuperación en un proceso evaluado. Añade una pregunta crítica antes de generar: “¿tenemos de verdad el contexto correcto?”.

Esa pregunta separa muchos prototipos de los sistemas que pueden utilizarse en entornos reales.

5. Multimodal RAG: porque la empresa no vive solo en texto

Muchos sistemas RAG nacieron pensando en texto.

Pero la información empresarial no está solo en texto.

Está en PDFs con tablas, imágenes, gráficos, diagramas, planos, facturas escaneadas, presentaciones, capturas, fichas técnicas, hojas de producto, informes con visualizaciones y documentos donde el significado depende del diseño.

Un RAG que solo indexa texto pierde una parte enorme del conocimiento.

Puede extraer el texto de un PDF, sí. Pero eso no significa que haya entendido la tabla. Puede leer los encabezados, pero no interpretar la relación entre filas y columnas. Puede capturar palabras de una imagen mediante OCR, pero no comprender un gráfico. Puede ignorar por completo elementos visuales que son decisivos para responder bien.

Multimodal RAG intenta resolver este problema creando índices capaces de trabajar con texto, imágenes y tablas de forma integrada.

Modelos como CLIP, ColPali u otros enfoques multimodales permiten representar diferentes tipos de contenido en un espacio común. Así, el sistema puede recuperar no solo fragmentos de texto, sino también páginas, imágenes, tablas o zonas visuales relevantes de un documento.

Después, un modelo multimodal puede interpretar ese contexto y responder teniendo en cuenta tanto texto como imagen.

Esto es crucial en sectores donde los documentos no son simples páginas escritas: ingeniería, construcción, logística, salud, industria, seguros, administración, formación técnica o análisis financiero.

Pensemos en una empresa que tiene manuales técnicos con diagramas, tablas de compatibilidad, esquemas eléctricos y fotografías de componentes. Un RAG textual puede encontrar el apartado correcto, pero no interpretar el esquema. Un Multimodal RAG puede recuperar la página relevante como objeto visual y permitir que el modelo razone sobre ella.

También es clave para facturas, albaranes, presupuestos, informes de obra, catálogos, documentación técnica o presentaciones estratégicas.

En la práctica, Multimodal RAG responde a una realidad muy sencilla: si el conocimiento de la empresa está en formatos visuales, el sistema de IA también tiene que poder verlos.

No basta con convertir todo a texto de forma pobre. Hay que conservar la estructura, la posición y la semántica visual.

La arquitectura real probablemente será una combinación

Lo más importante de estas cinco arquitecturas es que no son excluyentes.

Una empresa no tiene por qué elegir entre Hybrid RAG, GraphRAG, Agentic RAG, Corrective RAG o Multimodal RAG como si fueran productos cerrados. En muchos casos, la arquitectura más potente será una combinación.

Una solución avanzada puede usar búsqueda híbrida como base, incorporar un índice multimodal para documentos complejos, apoyarse en un grafo de conocimiento para relaciones críticas, ejecutar todo dentro de un bucle agéntico y añadir un grader correctivo que evalúe si la recuperación es suficiente antes de responder.

Esa es probablemente la dirección de los sistemas serios.

No un RAG simple, sino una arquitectura de contexto.

Y esta diferencia es importante. Porque muchas empresas creen que su problema es “poner un chatbot sobre unos documentos”. Pero el verdadero reto no es el chatbot. El verdadero reto es diseñar una infraestructura de conocimiento que permita a la IA trabajar con información real, dispersa, incompleta y cambiante.

El chatbot es solo la interfaz visible.

Debajo está la arquitectura.

Por qué esto importa para las empresas

La evolución de RAG explica muy bien una de las grandes lecciones de la inteligencia artificial empresarial: los modelos no bastan.

Puedes tener un modelo excelente y obtener respuestas malas si el contexto es malo. Puedes tener una interfaz atractiva y fracasar si la recuperación no está bien diseñada. Puedes hacer una demo brillante con veinte documentos y no ser capaz de escalar a miles de archivos, bases de datos, versiones y usuarios reales.

En la práctica, la calidad de un sistema de IA empresarial depende cada vez más de su capacidad para acceder al contexto correcto.

Y el contexto correcto no es simplemente “más documentos”.

Es información bien recuperada, bien evaluada, bien conectada y bien presentada al modelo.

Esto conecta directamente con una idea más amplia: la inteligencia artificial aplicada a empresas no consiste solo en automatizar tareas. Consiste en convertir información dispersa en capacidad operativa.

Una empresa puede tener miles de documentos y seguir sin poder usarlos bien. Puede tener datos en muchos sistemas y seguir tomando decisiones con información incompleta. Puede haber acumulado conocimiento durante años y no tener una forma eficaz de activarlo en el momento adecuado.

RAG, bien entendido, es una de las formas de activar ese conocimiento.

Pero para hacerlo bien hay que superar la visión ingenua.

El RAG como infraestructura, no como funcionalidad

Uno de los errores habituales es tratar RAG como una funcionalidad añadida a un chatbot.

“Le ponemos RAG y ya puede responder sobre nuestros documentos”.

Esa frase suele esconder una simplificación peligrosa.

RAG no es una casilla que se activa. Es una arquitectura que se diseña.

Hay que decidir cómo se ingieren los documentos, cómo se trocean, qué metadatos se conservan, qué versiones son válidas, qué fuentes tienen prioridad, qué permisos se respetan, qué tipo de búsqueda se utiliza, cómo se evalúa la calidad de la recuperación, cómo se gestionan las respuestas inciertas y cómo se audita lo que el sistema ha utilizado para responder.

En empresas, además, hay una cuestión fundamental: no todos los usuarios deben poder acceder a la misma información. Por tanto, la recuperación no puede ser solo inteligente; también tiene que ser segura y gobernada.

Esto convierte RAG en una pieza de infraestructura.

Una infraestructura de contexto para agentes, asistentes y sistemas de IA.

Cuando una empresa empieza a construir agentes que consultan correos, documentos, bases de datos, calendarios, ERPs o CRMs, RAG deja de ser un mecanismo de búsqueda y se convierte en una capa crítica de operación.

Ahí es donde estas arquitecturas cobran sentido.

Hybrid RAG mejora la precisión de búsqueda. GraphRAG organiza relaciones. Agentic RAG decide estrategias. Corrective RAG introduce validación. Multimodal RAG amplía el tipo de conocimiento accesible.

Cada una resuelve un fallo típico del RAG básico.

Qué arquitectura conviene empezar a usar

Para la mayoría de empresas, la respuesta razonable no es empezar por lo más complejo.

Lo lógico es empezar por un RAG híbrido bien diseñado. Es una base sólida, relativamente comprensible y con impacto inmediato. Combinar búsqueda vectorial con búsqueda por palabras clave reduce muchos errores habituales y mejora la calidad de las respuestas sin disparar la complejidad.

Después, si los documentos contienen muchas tablas, imágenes o PDFs complejos, tiene sentido incorporar capacidades multimodales. En muchos entornos empresariales esto no será opcional, porque buena parte del conocimiento útil no está en texto limpio.

Si el caso de uso requiere decisiones más complejas, consultas a diferentes sistemas o procesos de investigación, entonces Agentic RAG empieza a ser relevante. No para todo, pero sí para preguntas que no pueden resolverse en una única búsqueda.

Corrective RAG debería aparecer en cualquier sistema donde la fiabilidad importe. Cuanto más sensible sea el dominio, más necesario será evaluar la recuperación antes de responder.

GraphRAG tiene sentido cuando el conocimiento depende de relaciones: clientes y productos, proveedores y riesgos, proyectos y personas, tecnologías y capacidades, incidencias y causas, normativa y obligaciones.

No hay una única respuesta. Hay una arquitectura adecuada al tipo de conocimiento, al nivel de riesgo y al uso que se espera del sistema.

La idea clave: recuperar no es encontrar, es comprender lo suficiente para responder

El cambio de fondo es este: recuperar información ya no puede entenderse como “buscar fragmentos parecidos”.

Recuperar, en sistemas de IA empresariales, significa reunir el contexto suficiente para responder con fundamento.

A veces eso exigirá combinar búsqueda semántica y búsqueda exacta. A veces exigirá construir un grafo. A veces requerirá que un agente planifique varias consultas. A veces obligará a validar si lo recuperado sirve. Y a veces implicará interpretar una tabla o una imagen dentro de un PDF.

Por eso el RAG ingenuo falla cuando llegan usuarios reales.

No porque la idea de RAG sea débil, sino porque la realidad empresarial es mucho más compleja que una demo.

La buena noticia es que las arquitecturas están evolucionando justo en la dirección adecuada. Están pasando de recuperar texto a construir contexto. De buscar chunks a entender relaciones. De ejecutar un paso a seguir un plan. De confiar ciegamente a comprobar. De leer solo texto a interpretar documentos reales.

Esa evolución será decisiva para la inteligencia artificial aplicada a empresas.

Porque la próxima ventaja no estará solo en usar mejores modelos. Estará en construir mejores sistemas de contexto.

Y ahí es donde RAG deja de ser una técnica de moda para convertirse en una pieza central de la inteligencia operativa de la empresa.