Hablemos de RAG: diseñando una buena arquitectura

Conectar un LLM a una base documental puede crear una buena demostración. Convertirlo en un producto fiable, seguro y escalable exige muchas más decisiones. 

De la búsqueda a la respuesta: por qué RAG es una cuestión de arquitectura 

En esta nueva entrega de la serie “Hablemos de…”, ponemos el foco en RAG, uno de los conceptos más repetidos actualmente en presentaciones comerciales, demos de asistentes corporativos y conversaciones sobre inteligencia artificial. 

La explicación suele parecer sencilla: cargamos documentos, generamos embeddings, los almacenamos en una base vectorial y dejamos que un modelo de lenguaje responda utilizando la información recuperada. 

La explicación no es falsa. El problema es que está incompleta. 

Ese flujo describe el punto de partida, no una arquitectura preparada para producción. No explica cómo recuperar la evidencia correcta, cómo conservar el contexto de documentos extensos, cómo respetar los permisos de acceso, cómo mantener actualizado el conocimiento, cómo medir la calidad de las respuestas ni qué hacer cuando las fuentes son insuficientes, contradictorias o poco fiables. 

Por eso, cuando un piloto funciona con veinte documentos y comienza a fallar al llegar a miles, el problema rara vez se resuelve simplemente cambiando de modelo. Normalmente hay que revisar cómo se ingesta la información, cómo se representa, cómo se recupera, cómo se valida y cómo se protege. 

En Raona lo vemos con frecuencia: lo que funciona en una demostración no siempre está preparado para convertirse en un producto empresarial. Y es precisamente ahí donde elegir la arquitectura adecuada marca la diferencia. 

RAG, de verdad: recuperar evidencia para generar una respuesta 

Retrieval-Augmented Generation combina dos capacidades. Primero, recuperar información relevante desde fuentes externas: documentos, bases de datos, APIs, grafos de conocimiento, imágenes o repositorios corporativos. Después, utilizar esa evidencia para que un modelo genere una respuesta contextualizada. 

El objetivo no es que el modelo “sepa más”, sino que pueda responder utilizando conocimiento que no forma parte de sus parámetros, que cambia con el tiempo o que pertenece exclusivamente a la organización. 

Ahora bien, proporcionar contexto no elimina automáticamente las alucinaciones. El sistema puede recuperar fragmentos irrelevantes, incompletos, desactualizados o contradictorios. El modelo también puede interpretar mal la evidencia o añadir conclusiones que no están respaldadas por ella. RAG reduce el riesgo de respuestas no fundamentadas, pero no garantiza por sí solo exactitud. 

De Naive RAG a Modular RAG 

La literatura suele describir tres grandes paradigmas. El Naive RAG sigue el flujo más simple: indexar, recuperar y generar. Advanced RAG mejora la preparación del conocimiento, la búsqueda y el tratamiento posterior de los resultados. Modular RAG descompone el sistema en módulos intercambiables para routing, memoria, recuperación, verificación, herramientas y generación. 

Esta clasificación es mucho más útil que afirmar que existen exactamente nueve, catorce o veinticinco tipos de RAG. En la práctica, las soluciones empresariales combinan patrones y técnicas de varios niveles. La pregunta no es “qué RAG compro”, sino “qué decisiones necesita mi caso de uso”. 

Las familias de RAG que realmente conviene distinguir 

Mapa conceptual de las principales familias de arquitecturas RAG: Naive, Advanced e Hybrid, Contextual y Hierarchical, Self y Corrective, GraphRAG, Multimodal y Agentic RAG. 

1. Naive RAG: el punto de partida, no el destino 

Es la arquitectura mínima: fragmentar documentos, generar embeddings, recuperar los fragmentos más parecidos a la consulta y enviarlos al modelo. Es adecuada para validar una idea, construir una FAQ controlada o probar rápidamente la utilidad de una fuente documental. 

El riesgo aparece cuando el prototipo se convierte, sin rediseño, en la solución final. A medida que crecen el volumen, la heterogeneidad y la complejidad de las preguntas, una similitud vectorial básica suele recuperar demasiado ruido o perder información esencial. 

2. Advanced e Hybrid RAG: mejorar la recuperación antes de añadir complejidad 

En muchos proyectos, el salto de calidad no llega incorporando agentes, sino construyendo mejor el pipeline de recuperación. Advanced RAG combina limpieza documental, chunking adaptado, metadatos, búsqueda híbrida y reranking. 

La búsqueda semántica encuentra contenido por significado. La búsqueda léxica localiza términos exactos, códigos, nombres de producto o referencias normativas. El reranker reordena los candidatos utilizando una evaluación más precisa de la relación entre pregunta y documento. 

Esta familia suele ser la base más sensata para una primera versión empresarial: suficientemente robusta para producción, pero todavía comprensible, medible y controlable. 

3. RAG contextual y jerárquico: cuando un chunk aislado pierde el sentido 

Una parte importante de los fallos no se origina durante la búsqueda, sino antes: al fragmentar los documentos. Una frase como “esta medida entrará en vigor el próximo trimestre” puede ser inútil si el chunk no conserva qué medida se está describiendo. 

Contextual Retrieval añade a cada fragmento una breve explicación de su posición y significado dentro del documento antes de indexarlo. Late Chunking genera representaciones conservando primero el contexto amplio. RAPTOR crea estructuras jerárquicas de fragmentos, clusters y resúmenes para recuperar información con distintos niveles de abstracción. 

Estos patrones son especialmente relevantes en contratos, normativa, informes extensos, manuales técnicos y repositorios donde una respuesta exige combinar varias secciones del mismo documento. 

4. Self-RAG, Corrective RAG y Adaptive RAG: recuperar no siempre es suficiente 

Self-RAG introduce mecanismos para decidir cuándo recuperar información y para reflexionar sobre la relevancia de la evidencia y la calidad de la generación. Corrective RAG evalúa los documentos recuperados y activa acciones de corrección cuando la evidencia es débil, ambigua o incorrecta. Adaptive RAG selecciona una estrategia distinta según la complejidad de la consulta: no recuperar, realizar una búsqueda directa o ejecutar un proceso iterativo. 

La idea común es sencilla: no todas las preguntas necesitan el mismo esfuerzo. Una consulta factual puede resolverse en un paso; una pregunta comparativa o multi-hop puede requerir varias búsquedas y validaciones. 

El beneficio es una mayor robustez. El coste es más latencia, más consumo y más puntos de fallo. Por eso deben incorporarse cuando el riesgo del caso de uso lo justifica, no porque el nombre de la arquitectura resulte atractivo. 

5. GraphRAG: cuando las relaciones importan tanto como los documentos 

La recuperación vectorial funciona bien para localizar fragmentos similares a una consulta, pero no siempre comprende la estructura global de un corpus. GraphRAG extrae entidades y relaciones, construye representaciones en forma de grafo y permite responder preguntas sobre conexiones, comunidades, tendencias o temas distribuidos entre muchas fuentes. 

Resulta especialmente útil en inteligencia de negocio, investigación, due diligence, análisis regulatorio y dominios donde el valor está en conectar hechos dispersos. Sin embargo, construir y mantener un grafo aumenta el coste de indexación y exige una estrategia clara de actualización y calidad. 

6. Multimodal y Visual RAG: porque un documento no es solo texto 

En la empresa, buena parte del conocimiento vive en tablas, diagramas, planos, capturas, firmas, diseños y distribuciones visuales. Un pipeline basado únicamente en extracción de texto puede destruir precisamente la información que necesitamos recuperar. 

Multimodal RAG combina diferentes modalidades. Visual Document RAG puede indexar directamente páginas como imágenes y aprovechar su composición, tipografía y elementos gráficos. Este enfoque es especialmente valioso en facturas, documentación técnica, presentaciones, expedientes y manuales donde la estructura visual forma parte del significado. 

7. Agentic y Multi-Agent RAG: cuando recuperar se convierte en una tarea 

En Agentic RAG, un agente decide qué fuente consultar, cómo reformular la pregunta, qué herramienta utilizar y si necesita continuar buscando. En una variante multiagente, varios agentes especializados pueden consultar documentos, bases de datos, APIs o grafos y colaborar en una síntesis final. 

Es un patrón potente para investigación compleja, análisis multifuente y procesos que requieren planificación. También es fácil sobredimensionarlo. Utilizar una orquestación de agentes para responder una FAQ aumenta la latencia, el coste y la dificultad de observación sin aportar valor real. 

La arquitectura no termina en la recuperación 

Dos sistemas pueden utilizar el mismo modelo, la misma base vectorial y los mismos documentos, y aun así ofrecer resultados radicalmente distintos. La diferencia suele estar en cuatro capacidades que con frecuencia se dejan para el final. 

Seguridad, actualización, evaluación y observabilidad convierten un flujo RAG en una solución empresarial. 

Seguridad y permisos 

Una respuesta puede ser correcta y, al mismo tiempo, constituir una fuga de información. El sistema debe preservar los permisos de las fuentes y aplicar la autorización durante la recuperación. No basta con ocultar un enlace o confiar en una instrucción dentro del prompt. La identidad, las ACL, los grupos y las etiquetas de sensibilidad forman parte de la arquitectura RAG. 

Actualización del conocimiento 

Un índice es una fotografía del conocimiento en un momento determinado. Sin sincronización, reindexación incremental, control de versiones y tratamiento de eliminaciones, el asistente comenzará a responder con información obsoleta aunque el documento original ya haya cambiado. 

Evaluación continua 

No es suficiente preguntar a cinco usuarios si “les gusta” la respuesta. Hay que medir por separado la calidad de la recuperación, la relevancia, la cobertura, el groundedness, la presencia de citas, la latencia, el coste y la seguridad. Si no sabemos si el fallo está en el índice, el recuperador, el contexto o el modelo, tampoco sabremos qué mejorar. 

Observabilidad y trazabilidad 

Una solución empresarial debe registrar qué consulta se ejecutó, qué documentos se recuperaron, qué filtros se aplicaron, qué versión del contenido se utilizó, qué herramientas participaron y por qué se decidió responder o abstenerse. La confianza no nace de que el sistema parezca inteligente, sino de que podamos explicar y auditar su comportamiento. 

La decisión más madura: saber cuándo no necesitas RAG 

Elegir bien también significa reconocer cuándo una búsqueda, una API, el contexto largo o una arquitectura de agentes resuelven mejor el problema. 

RAG no es la respuesta automática para cualquier problema de conocimiento. En algunos escenarios, otra solución es más simple y fiable: 

• Si el corpus es pequeño, estable y cabe de forma razonable en el contexto, puede ser mejor utilizar contexto largo o caché de prompts. 

• Si la respuesta debe ser exacta y determinista, como un saldo, un precio vigente o un estado de pedido, conviene consultar directamente la base de datos o la API. 

• Si el usuario quiere localizar un documento por su código o título, un motor de búsqueda clásico puede resolver el problema sin generación. 

• Si el objetivo principal es ejecutar acciones, quizá necesitamos una arquitectura de agentes y herramientas con una capa de conocimiento, no un RAG como centro del sistema. 

Incluso los modelos con ventanas de contexto muy amplias pueden utilizar de forma desigual la información situada en distintas posiciones. Por eso, la comparación entre RAG, contexto largo, caché y acceso directo debe hacerse con datos y consultas reales, no basándose únicamente en la capacidad máxima anunciada por el modelo. 

Cómo elegimos una arquitectura RAG en Raona 

Framework de cinco dimensiones para elegir una arquitectura RAG: consultas, conocimiento, riesgo, restricciones y evaluación y evolución. 

Antes de seleccionar modelos (LLM’s), embeddings o bases vectoriales, necesitamos responder cinco preguntas: 

Con esas respuestas podemos diseñar una solución proporcionada. A veces será un Advanced RAG con búsqueda híbrida y reranking. En otros casos necesitaremos una representación jerárquica, un grafo, recuperación visual o un agente capaz de consultar varias fuentes. La sofisticación no es el objetivo: lo es resolver el problema con el menor nivel de complejidad que permita cumplir los requisitos. 

Del piloto al producto 

La mayoría de los proyectos RAG no fracasa porque el modelo sea insuficiente. Fracasa porque se trató un problema de arquitectura, conocimiento y gobierno como si fuera una integración rápida entre un buscador y un LLM. 

Un buen piloto demuestra que la idea tiene valor. Un buen producto añade calidad de datos, recuperación adecuada, permisos, actualización, evaluación, observabilidad y un modelo operativo que permita evolucionar la solución. 

¿Tu piloto RAG está listo para producción? 

¿Tu organización ya tiene un asistente o un Copilot RAG, pero todavía no confía en llevarlo a producción? Podemos ayudarte a evaluar la arquitectura, la calidad de la recuperación, la seguridad, la trazabilidad y su capacidad real para escalar. 

RAG no es una receta única ni una simple integración entre documentos y un LLM. Es una decisión de arquitectura. Y como ocurre con cualquier decisión de arquitectura, lo que funciona en una demo no siempre funciona en producción. 

En Raona ayudamos a las organizaciones a diseñar, evaluar e implantar arquitecturas RAG adaptadas a sus necesidades reales: desde asistentes documentales y buscadores inteligentes hasta soluciones más avanzadas basadas en agentes, grafos o recuperación multimodal. 

Si tu organización está explorando este tipo de soluciones, o si ya dispone de un piloto y quiere llevarlo a producción con garantías, hablemos. 

Fuentes consultadas 

1. Gao et al.| Retrieval-Augmented Generation for Large Language Models: A Survey. 
2. Asai et al.| Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection. 
3. Yan et al.| Corrective Retrieval Augmented Generation. 
4. Jeong et al.| Adaptive-RAG: Learning to Adapt Retrieval-Augmented Large Language Models through Question Complexity. 
5. Sarthi et al.| RAPTOR: Recursive Abstractive Processing for Tree-Organized Retrieval. 
6. Microsoft Research| From Local to Global: A Graph RAG Approach to Query-Focused Summarization. 
7. Anthropic| Contextual Retrieval. 
8. Faysse et al.| ColPali: Efficient Document Retrieval with Vision Language Models. 
9. Liu et al.| Lost in the Middle: How Language Models Use Long Contexts. 
10. Microsoft Foundry| Evaluadores para sistemas RAG. 
11. Azure AI Search| Control de acceso a nivel de documento.