Elegir una arquitectura RAG: Naive, Advanced, CRAG, GraphRAG, Agentic

¿Por qué RAG y por qué un solo diseño no es suficiente?

Los agentes de IA son capaces, pero generan alucinaciones y no pueden acceder por sí solos a datos especializados o en tiempo real. La generación reforzada por recuperación de información (RAG) aborda ambos problemas al basar las respuestas del agente en una base de conocimientos verificada. Sin embargo, RAG no es una solución única. La búsqueda vectorial simple es suficiente para un bot de preguntas frecuentes básico, pero falla gravemente en tareas de razonamiento o análisis complejos que involucran muchos documentos. A continuación se describen las arquitecturas comunes de RAG y un proceso de toma de decisiones para elegir entre ellas según los requisitos de la tarea.

Qué hace RAG

RAG recupera documentos de una base de conocimientos y los utiliza para generar respuestas más relevantes. El diagrama a continuación muestra el flujo desde el almacenamiento de documentos, pasando por la recuperación vectorial, hasta la generación por LLM.

La idea central combina la recuperación de información, que en el diagrama va desde el almacenamiento hasta la recuperación, con la IA generativa. Al incorporar contexto relevante en la instrucción, se mantiene al modelo de lenguaje vinculado a información real. Puede analizar páginas de material específico de un dominio en segundos, lo que permite que el modelo de lenguaje grande responda a las consultas de los usuarios de manera precisa y rápida.

Un flujo de trabajo típico consta de dos fases. La fase offline ingiere datos brutos y los prepara como datos estructurados y buscables. La fase online recupera los datos relevantes y responde a la consulta. Vale la pena añadir una tercera fase: un bucle de retroalimentación en el que el contexto recuperado se evalúa una y otra vez.

Fase 1: ingestión

La primera fase convierte los archivos brutos en registros estructurados y buscables en una base de datos:

1. Cargar datos de fuentes como PDF, Notion, SQL y Slack, con una herramienta como LlamaIndex o LangChain.
2. Limpiar el ruido, como encabezados, pies de página y etiquetas HTML.
3. Dividir los documentos largos en partes significativas, por ejemplo, de 500 palabras cada una. Las partes demasiado grandes confunden al modelo, y las demasiado pequeñas pierden el contexto.
4. Incrustar cada parte con un modelo de incrustación (por ejemplo, text-embedding-3-small de OpenAI) para convertir el texto en vectores.
5. Indexar los vectores en una base de datos vectorial como Pinecone o Chroma, lo que permite búsquedas semánticas por significado.

Fase 2: recuperación y generación

Cuando un usuario hace una consulta, todo esto se procesa en milisegundos:

1. Transformación de la consulta. El sistema convierte la pregunta, por ejemplo “¿Cómo restablezco mi contraseña?”, en un vector utilizando el mismo modelo de embedding empleado en la Fase 1.
2. Recuperación. Busca en la base de datos de vectores los 3 a 5 fragmentos matemáticamente más cercanos a la pregunta.
3. Reclasificación. Un modelo de reclasificación verifica nuevamente los resultados para que la mejor coincidencia quede en la parte superior.
4. Augmentación. Los fragmentos recuperados se incluyen en el prompt del LLM. Uno típico le indica al modelo que es un asistente útil, le proporciona los fragmentos como contexto y luego plantea la pregunta sobre el restablecimiento de la contraseña.
5. Generación. El LLM lee el prompt junto con el contexto y escribe una respuesta basada únicamente en la información que le fue proporcionada.

Fase 3: retroalimentación

Los resultados de recuperación deben evaluarse de forma continua para evitar las alucinaciones. La evaluación determina si una respuesta se basó realmente en el contexto, y la observabilidad muestra exactamente qué fragmento causó una respuesta incorrecta. Esos hallazgos sirven para mejorar la estrategia de fragmentación de la Fase 1.

Herramientas por fase

Las herramientas RAG son los componentes básicos que conectan tus datos con un modelo de lenguaje, y se clasifican según la etapa del proceso en la que se utilizan. La elección adecuada depende de la fase en la que estés trabajando.

La tabla ordena la tecnología RAG según la fase del proceso.

¿Se requiere una base de datos vectorial?

No estrictamente. No es obligatorio utilizar un almacén de vectores dedicado para crear RAG, ya que existen dos alternativas más sencillas. Con un enfoque sin base de datos, unos pocos documentos se dividen en fragmentos y se almacenan en RAM. Esto es rápido, gratuito y no requiere configuración, pero la memoria se borra al reiniciar, y los documentos grandes son lentos. Un enfoque con base de datos tradicional almacena los fragmentos de texto en sistemas como PostgreSQL y realiza búsquedas por palabras clave basadas en reglas. Es eficaz para frases únicas como el nombre de una persona o un ID, pero carece de comprensión semántica: un usuario que busque “mamíferos” no encontrará un documento que solo diga “perros.”

Se comparan seis arquitecturas

No existe una configuración única que sea adecuada en todos los casos. Algunas tareas requieren rapidez y simplicidad, otras necesitan un análisis más profundo, varias fuentes o entradas no textuales como imágenes o gráficos. Seis diseños principales cubren la mayoría de las necesidades: Naive RAG, Advanced RAG, Modular RAG, Corrective RAG (CRAG), GraphRAG y Agentic RAG.

Naive RAG

La forma más simple extrae documentos según la consulta y los pasa al modelo sin realizar ajustes.

El diagrama muestra un sistema de coincidencia de similitud vectorial top-K sencillo. La consulta se convierte en un vector, los fragmentos más similares de top-K provienen de una base de datos vectorial y llegan al LLM. La búsqueda es semántica y su complejidad es baja.

• Fortalezas: ofrece las respuestas más rápidas y el menor costo de procesamiento, es fácil de configurar con bibliotecas como LangChain o LlamaIndex, y funciona para la recuperación básica de datos de documentos limpios.
• Debilidades: los fragmentos irrelevantes pueden generar ruido que confunde al LLM, tiene dificultades con preguntas complejas o de múltiples partes, y no puede corregirse a sí mismo, por lo que un error en la recuperación se convierte en una respuesta falsa.
• Mejor para: preguntas y respuestas simples con conjuntos de datos pequeños y ordenados, como preguntas y respuestas sobre documentos personales, Preguntas Frecuentes internas de empresas y aplicaciones simples de chat con documentos.

RAG avanzado

Esta variante añade lógica como la enrutación de consultas y el reclasificado de resultados después de la fase de recuperación para lograr una mayor precisión.

La figura muestra la transformación de la consulta antes de la recuperación y el reclasificado de resultados después de ella. Antes de recuperar los datos, la consulta se reescribe para que sea más clara. Después de la recuperación, los resultados se clasifican y se verifican para que la respuesta generada sea lo más relevante y precisa posible. La búsqueda es híbrida (vectorial más por palabras clave) con reclasificado, y su complejidad es media.

• Fortalezas: maneja mejor las preguntas complejas, elige enfoques adecuados para diferentes situaciones y brinda más control sobre la generación del texto.
• Debilidades: el reordenamiento de resultados aumenta la latencia, varias llamadas al modelo por consulta elevan los costos, hay más componentes que mantener, y los componentes necesitan ajustes para funcionar bien juntos.
• Mejor para: sistemas de alta fidelidad en los que los errores no son aceptables, como bases de conocimiento profesionales y bots de atención al cliente.

Modular RAG

Modular RAG utiliza una estructura lista para usar en la que módulos separados se encargan de diferentes partes del flujo de trabajo.

Los componentes resaltados incluyen los módulos de Búsqueda y Memoria. Al dividir el sistema de esta manera, cualquier parte puede personalizarse sin necesidad de reconstruir el resto: un equipo puede instalar un recuperador diferente, un reordenador más potente u otro generador. La recuperación puede abarcar múltiples fuentes como APIs, bases de datos y la web, y su complejidad es alta porque requiere una capa de orquestación sofisticada.

• Fortalezas: cada componente es fácil de ajustar, y las partes pueden actualizarse o reemplazarse sin tener que empezar de nuevo.
• Debilidades: el costo de configuración y la complejidad arquitectónica son muy altos y exigen planificación previa; se necesita un equipo de ingeniería sólido para gestionar la orquestación, y las diferentes versiones de los módulos pueden entrar en conflicto.

Mejor para: sistemas empresariales complejos que requieren una personalización profunda, como un asistente que verifica simultáneamente Jira, Slack y Google Drive.

RAG correctivo (CRAG)

CRAG está diseñado para verificar sus respuestas y corregirlas cuando algo no está correcto.

El flujo muestra un paso de evaluación con búsqueda en la web como recurso de respaldo. Un modelo evaluador califica los documentos recuperados. Cuando la puntuación es demasiado baja, el sistema descarta la base de datos interna y realiza una búsqueda en la web para encontrar la respuesta en otro lugar, representado por la ruta discontinua en la figura. Es de alta complejidad debido a las ramificaciones basadas en lógica y las llamadas a APIs externas.

• Fortalezas: los resultados de búsqueda deficientes se corrigen antes de que los vea el usuario, y la capa adicional de control de calidad hace que las respuestas sean más fiables y precisas.
• Debilidades: la búsqueda de respaldo consume tiempo y recursos informáticos, y el sistema puede entrar en un bucle infinito si nunca está satisfecho con lo que encuentra.
• Mejor para: trabajos de alta importancia en los que la información incorrecta o desactualizada es inaceptable, como la investigación médica y legal.

GraphRAG

GraphRAG utiliza un grafo de conocimiento para estructurar las relaciones entre los datos y no se basa únicamente en la similitud textual.

El diagrama muestra el recorrido por el grafo de conocimiento y la generación de resúmenes de comunidades. Una vez construido el grafo, el sistema lo recorre en busca de patrones en los datos y no solo de coincidencias de palabras, lo que le permite determinar cómo se relaciona la Entidad A con la Entidad B incluso cuando aparecen en documentos diferentes. La complejidad es muy alta, ya que es necesario crear y mantener una base de datos de grafo estructurada.

Una segunda ilustración, tomada de una representación de Microsoft Research, muestra un grafo de conocimiento generado por un LLM basado en un conjunto de datos privado con GPT-4 Turbo.

• Fortalezas: puede abordar preguntas complejas que conectan varios conceptos, evita respuestas dispersas y puede revelar resultados inesperados pero relevantes al relacionar información.
• Debilidades: la creación del grafo requiere un esfuerzo considerable, es más lento que los métodos RAG básicos y su calidad limita el rendimiento, ya que solo es tan bueno como las conexiones presentes en el grafo.
• Mejor para: comprender el panorama general y realizar razonamientos a través de varias fuentes de datos, como en el periodismo de investigación, la detección de fraudes o el descubrimiento de fármacos.

RAG agente

En este diseño dinámico, un agente de IA actúa como coordinador para planificar, recuperar y perfeccionar la respuesta.

El flujo de trabajo muestra a un agente coordinador que utiliza herramientas para el razonamiento en múltiples pasos. En lugar de tomar los primeros documentos relevantes, planifica un enfoque, decide qué investigar y actúa a través de sus herramientas. Divide la tarea en pasos más pequeños, busca en diversas fuentes de datos, verifica si los hallazgos responden a la consulta y continúa buscando si no es así.

• Fortalezas: es adecuado para el razonamiento en múltiples pasos, toma decisiones inteligentes sobre la recopilación de información y puede mejorar los resultados en consultas complejas.
• Debilidades: las búsquedas múltiples aumentan el costo, y el trabajo de tipo de investigación ralentiza las respuestas.
• Mejor para: tareas que requieren una planificación metódica, como el análisis exhaustivo de casos en la investigación jurídica o el análisis financiero que combina datos de mercado con información regulatoria.

Un camino de decisión de cuatro pasos

Ninguna regla sirve para todo, pero un enfoque común ayuda en la tarea que se tiene entre manos.

El diagrama de flujo guía a los arquitectos entre las opciones Simple, Graph, Corrective y Advanced RAG según las restricciones de la tarea. Los pasos son:

Paso 1: la prueba de complejidad. ¿La respuesta está dentro de un único documento? Si es así, No-DB RAG para documentos pequeños, o Simple RAG, es la mejor opción, ya que es rápido, económico y casi sin esfuerzo de implementar.

Paso 2: la prueba de relaciones. ¿Para responder es necesario comprender jerarquías profundas o conexiones ocultas entre varias fuentes de datos? Si es así, GraphRAG mapea esos recursos y enlaces, que la búsqueda de texto plano no detecta. Por ejemplo, en la pregunta “¿Qué departamentos se ven afectados por la Política A y quiénes son sus gerentes?”, es necesario combinar los datos de los departamentos con los datos de los empleados, y GraphRAG representa ambos como entidades vinculadas.

Paso 3: la prueba de fiabilidad y razonamiento. ¿Puede permitirse el sistema cometer errores? En situaciones donde es crucial la precisión extrema, Corrective RAG o Self-RAG incluyen un paso específico que verifica si los datos recuperados realmente responden a la pregunta antes de que lleguen al usuario. Si dicha tarea también requiere razonamiento en múltiples pasos, Agentic RAG utiliza sus agentes para realizar la planificación y el autoperfeccionamiento.

Paso 4: el equilibrio entre rendimiento y costo. Cuando la latencia es la prioridad, una configuración más simple como No-DB, Naive o Simple RAG funciona mejor. Sin embargo, cuando la calidad prevalece sobre el costo, aunque no al nivel de precisión extrema del Paso 3, Advanced RAG comprende mejor la intención detrás de una consulta que los diseños más simples, a costa de un mayor tiempo de procesamiento.

Cuándo no usar RAG

RAG permite a los LLM dar respuestas conscientes del contexto a partir de enormes conjuntos de datos privados sin necesidad de un reentrenamiento constante. Sin embargo, no es útil en todos los casos, especialmente cuando una tarea depende de un razonamiento profundo, síntesis creativa o dominio de patrones lingüísticos y no de la consulta de un documento. En estos escenarios, por lo general, es mejor prescindir de él:

• Razonamiento amplio sobre el sentido común, las matices éticos o el comportamiento humano general. Se deben utilizar los pesos internalizados del modelo preentrenado.
• Preguntas de conocimiento general sobre temas que no han cambiado en décadas. El modelo preentrenado es suficiente, y RAG solo añadiría demoras sin mejorar la precisión.
• Escripción creativa con un tono y estilo específicos. Se recomienda usar modelos preentrenados o realizar un ajuste fino, ya que RAG es un exceso.

Problemas matemáticos o lógicos complejos que requieren cálculos en múltiples pasos. La adaptación personalizada o los estímulos de tipo Chain-of-Thought (CoT) son más adecuados.

Necesidades de baja latencia extrema que exigen respuestas casi instantáneas. Los procesos de embedding, búsqueda e inserción añaden carga adicional.

Conjuntos de datos pequeños que caben completamente en el prompt. Pegar los datos es mejor que crear un pipeline.

La tabla final compara el rendimiento entre los modelos RAG, de adaptación personalizada y de razonamiento.

Leer más

• AegisOps: Un agente SRE autónomo con cuatro capas de memoria — Cómo un agente LangGraph ReAct resuelve incidentes en Kubernetes, con memoria episódica pgvector, niveles de autonomía controlados por políticas, dieciséis herramientas y un registro de auditoría completo.
• Creación de una tubería ETL de producción para RAG con LangChain y FAISS — Diseño de procesos de fragmentación, incrustación e indexación vectorial para 40,000 PDFs relacionados con cumplimiento, con mecanismos de reintentos, colas de mensajes no procesados, métricas de Prometheus y pruebas de rendimiento medibles.
• Notas prácticas: Creación de un sistema de detección de fraudes basado en agentes listo para producción — Guía paso a paso para la implementación de un sistema de detección de fraudes basado en agentes listo para producción: contratos, verificaciones y espacios de código listos para usar para los equipos que desean adoptar este enfoque.
• Dartboard RAG: Qué hacer cuando Top-K devuelve el mismo fragmento tres veces — La recuperación simple con top-k puede devolver fragmentos casi idénticos. Dartboard RAG selecciona tanto la relevancia como la diversidad; aquí se explica el algoritmo, el código y cuándo utilizarlo.
• Ingeniería de Agent Harness: Presupuestos, permisos y evaluaciones para agentes en producción — La mayoría de los agentes fallan en producción debido a un sistema de soporte deficiente, no al modelo en sí. Aprenda el ciclo de trabajo, los niveles de riesgo, los presupuestos, la capa de contexto y las evaluaciones de seguridad que mantienen seguros a los agentes.
• Cómo funciona RAG en el interior: fragmentación, embeddings, búsqueda vectorial y reclasificación — Una explicación paso a paso de la generación aumentada por recuperación de información: fragmentación, embeddings, bases de datos vectoriales, montaje de prompts, reclasificación, límites de las alucinaciones y una breve nota sobre KAG.