RAG (Retrieval-Augmented Generation, o generación aumentada por recuperación) es una arquitectura que combina la búsqueda de información con la capacidad generativa de un modelo de lenguaje. En lugar de responder solo con lo que el modelo aprendió durante el entrenamiento, primero recupera contexto relevante de una fuente externa y luego genera la respuesta. Ese mecanismo de doble fase es lo que hace que RAG sea útil en IA aplicada a datos reales.
Qué es RAG en IA: definición y mecanismo básico
RAG añade una etapa de recuperación antes de que el modelo de lenguaje genere una respuesta. La sigla corresponde a Retrieval-Augmented Generation: primero se recupera (retrieval) información de una base de conocimiento, y después esa información se inyecta en el prompt para que el modelo la use al generar (generation) la respuesta. El resultado es un sistema capaz de responder con información actualizada o privada que el modelo nunca vio durante el entrenamiento.
Un ejemplo concreto: si preguntas a un asistente interno de una empresa cuál es la política de devoluciones vigente, un modelo entrenado en datos públicos no lo sabe. Con RAG, el sistema busca ese documento en la base de conocimiento de la empresa, lo incluye en el contexto y el modelo genera una respuesta basada en ese texto, no en suposiciones.
La diferencia con el fine-tuning, que consiste en reentrenar el modelo con nuevos datos, es que RAG no modifica los pesos del modelo. Eso lo hace mucho más económico de mantener y más fácil de actualizar: cambias los documentos de la base de conocimiento sin tocar el modelo.
Cómo funciona RAG por dentro: las tres fases del proceso
El flujo tiene tres pasos diferenciados. Primero, la consulta del usuario se convierte en un vector mediante un modelo de embeddings (una representación numérica que captura el significado semántico de la pregunta). Segundo, ese vector se compara con los vectores de los documentos almacenados en una base de datos vectorial para recuperar los fragmentos más relevantes. Tercero, esos fragmentos se añaden al prompt junto con la pregunta original, y el modelo genera la respuesta final.
La calidad del resultado depende en gran medida del segundo paso. Si la recuperación devuelve fragmentos poco relevantes o ambiguos, el modelo genera una respuesta igualmente deficiente. Por eso la selección y la configuración de la base vectorial no son un detalle menor: son el núcleo del sistema.
Bases vectoriales: pgvector, MongoDB y Elasticsearch en RAG
Una base de datos vectorial almacena y recupera documentos por similitud semántica, no por coincidencia exacta de palabras clave. Las tres opciones más habituales en sistemas RAG tienen perfiles distintos, y conviene conocerlos antes de elegir.
pgvector es una extensión de PostgreSQL que añade capacidad vectorial a una base de datos relacional que quizás ya tienes en producción. Es una opción pragmática para equipos que quieren evitar infraestructura adicional y manejan volúmenes moderados. Su ventaja es la integración con el ecosistema SQL; su límite, el rendimiento a escala muy alta.
MongoDB con búsqueda vectorial permite combinar consultas estructuradas sobre documentos JSON con recuperación semántica. Es especialmente útil cuando los datos que alimentan el RAG ya viven en MongoDB y quieres evitar duplicar la información en otro sistema.
Elasticsearch, ampliamente usado en motores de búsqueda textuales, incorpora búsqueda densa (vectorial) junto a su búsqueda léxica tradicional. Esa combinación permite técnicas híbridas que mejoran la recuperación cuando ni la búsqueda semántica ni la exacta por sí solas son suficientes.
RAG Fusion y query routing: variantes que mejoran la recuperación
La arquitectura RAG básica tiene un problema conocido: una sola consulta puede no capturar todos los ángulos relevantes de una pregunta. RAG Fusion aborda esto generando varias versiones de la misma pregunta, ejecutando una búsqueda para cada una y combinando los resultados con un algoritmo de reordenación, habitualmente Reciprocal Rank Fusion. El sistema recupera más contexto y reduce el riesgo de que un matiz importante quede fuera.
Query routing es una capa de decisión que analiza la consulta entrante y decide a qué base de conocimiento o herramienta debe dirigirse. Si el sistema tiene documentos legales, datos de producto y una base de soporte técnico por separado, el router evita buscar en los tres cuando la pregunta solo concierne a uno. Eso reduce el ruido en el contexto y mejora la coherencia de la respuesta.
Ambas variantes forman parte del ecosistema que frameworks como LangChain y LangGraph permiten construir. LangChain facilita el encadenamiento de componentes (el embedding, la búsqueda, el prompt y el modelo), mientras que LangGraph permite definir flujos con bifurcaciones y bucles cuando la lógica es más compleja que una cadena lineal.
Límites reales de RAG que conviene conocer antes de construir un sistema
RAG no es una solución universal. El primer límite está en la calidad de los documentos: si la base de conocimiento contiene información desactualizada, mal estructurada o contradictoria, el modelo la usará igualmente. La recuperación mejora el acceso al contexto, pero no corrige el contenido.
El segundo límite es la ventana de contexto del modelo. Cada LLM (Large Language Model, modelo de lenguaje de gran escala) solo puede procesar una cantidad limitada de texto a la vez. Si los fragmentos recuperados son demasiado largos o hay demasiados, no todos caben en el contexto y el sistema tiene que priorizarlos o truncarlos.
El tercer límite es la latencia. Recuperar, reordenar y construir el prompt añade tiempo al proceso. Para aplicaciones que necesitan respuesta en menos de un segundo, ese coste hay que medirlo y gestionarlo desde el diseño, no como ajuste posterior.
La evaluación tampoco es trivial. Determinar si una respuesta RAG es correcta, completa y fiel al contexto recuperado requiere métricas específicas. La técnica conocida como LLM-as-Judge utiliza otro modelo de lenguaje para evaluar la calidad de las respuestas de forma automática, pero esa evaluación también tiene sus propios sesgos y limitaciones que hay que considerar.
Formación para construir sistemas RAG desde cero
Entender RAG conceptualmente es un punto de partida. Construirlo en producción, con bases vectoriales reales, pipelines de recuperación bien configurados y evaluación automatizada, requiere un nivel técnico concreto: dominio de Python, base en Data Science y conocimientos de machine learning y Docker.
Si tu perfil ya encaja con esos requisitos, el Curso IA Generativa Aplicada de Datahack trabaja exactamente este terreno: arquitectura RAG y RAG Fusion, bases vectoriales con pgvector, MongoDB y Elasticsearch, query routing, LangChain y LangGraph, y evaluación con LLM-as-Judge, entre otros contenidos. La metodología es práctica desde el primer módulo, con proyectos reales y profesorado que trabaja actualmente en el sector.
Si necesitas consolidar antes la base técnica, el itinerario natural es el Máster Experto en Data Science, Big Data e IA, un programa de nivel experto con 166 horas de contenido que cubre el terreno previo que el curso de IA Generativa presupone. Desde ahí, dar el salto a RAG y sistemas de generación aumentada tiene mucho más sentido.
Si quieres revisar el temario completo o valorar qué itinerario encaja mejor con tu punto de partida, puedes consultar directamente con Datahack.
Preguntas frecuentes
¿Para qué sirve RAG en la práctica y en qué se diferencia de un chatbot normal?
Un chatbot convencional responde solo con lo que el modelo aprendió en el entrenamiento, sin acceso a información nueva o privada. RAG añade una búsqueda previa en una base de conocimiento externa, de modo que el modelo puede responder sobre documentos internos de una empresa, datos actualizados o cualquier fuente que no formó parte del entrenamiento original.
¿Qué es una base de datos vectorial y por qué es necesaria en RAG?
Una base de datos vectorial almacena documentos como representaciones numéricas de su significado (vectores), lo que permite recuperarlos por similitud semántica en lugar de por coincidencia exacta de palabras. Esa capacidad es esencial en RAG porque la pregunta del usuario raramente usa las mismas palabras que el documento donde está la respuesta.
¿Cuáles son los principales problemas que tiene RAG en producción?
Los más frecuentes son: documentos de baja calidad o desactualizados en la base de conocimiento, limitaciones en la ventana de contexto del modelo cuando se recuperan muchos fragmentos, latencia añadida por la fase de búsqueda, y dificultad para evaluar si las respuestas son realmente fieles al contexto recuperado. Ninguno es insalvable, pero todos requieren diseño explícito.
¿Qué diferencia hay entre RAG y fine-tuning para personalizar un modelo de lenguaje?
El fine-tuning modifica los pesos internos del modelo mediante un nuevo entrenamiento con datos específicos. RAG no toca el modelo: inyecta información externa en el prompt en tiempo de inferencia. RAG es más barato de mantener y más fácil de actualizar, pero depende de que la recuperación funcione bien. El fine-tuning puede ser más adecuado cuando se quiere que el modelo adopte un estilo o dominio específico a fondo.
¿Qué nivel técnico necesito para aprender a construir un sistema RAG?
Hace falta dominar Python con soltura, tener base en Data Science y machine learning, y entender cómo funcionan los modelos de lenguaje a nivel general. Conocimientos de Docker son útiles para la parte de despliegue. Sin esa base, los conceptos de embeddings, recuperación semántica y evaluación son difíciles de aplicar más allá del nivel teórico.
