RAG (Retrieval-Augmented Generation), o generación aumentada por recuperación, es una arquitectura que busca información relevante en fuentes externas antes de pedir a un modelo de lenguaje que responda. Los fragmentos recuperados se añaden al contexto del modelo para producir una respuesta fundamentada, más fácil de actualizar y potencialmente citable sin reentrenar el LLM.
Respuesta corta
RAG ejecuta dos tareas: recuperar evidencia y generar una respuesta con esa evidencia. Es útil cuando el modelo debe consultar manuales, políticas, tickets, contratos, catálogos o documentación reciente. No garantiza exactitud: hay que comprobar tanto la calidad de lo recuperado como la fidelidad de la respuesta final.
Qué significa RAG en inteligencia artificial
RAG son las siglas de Retrieval-Augmented Generation. En español suele traducirse como generación aumentada por recuperación. El nombre describe el flujo:
- Retrieval o recuperación: el sistema localiza información relacionada con la pregunta.
- Augmentation o aumento: inserta esa información dentro del contexto que recibirá el modelo.
- Generation o generación: el modelo redacta una respuesta usando la pregunta y la evidencia recuperada.
El trabajo fundacional de Lewis y su equipo, aceptado en NeurIPS 2020, combinó una memoria paramétrica —el conocimiento almacenado en los pesos del modelo— con una memoria no paramétrica basada en un índice de documentos. La idea central sigue vigente: separar el motor generativo de una fuente de conocimiento que se puede consultar y actualizar.
RAG no es un modelo concreto ni una única herramienta. Es un patrón de arquitectura. Puede usar diferentes modelos de lenguaje, buscadores, bases de datos, APIs, técnicas de fragmentación y métodos de ordenación.
Cómo funciona RAG paso a paso
Un sistema RAG suele dividirse en una fase de preparación y otra de consulta.
1. Preparar las fuentes
Primero se seleccionan documentos confiables: artículos de ayuda, manuales, páginas web, archivos, registros de producto o datos estructurados. En esta fase también se limpian duplicados, encabezados repetidos, contenido obsoleto y texto que el usuario no debería poder consultar.
La procedencia importa tanto como el volumen. Indexar muchas páginas contradictorias no produce una fuente de verdad; solo hace que el buscador encuentre contradicciones con más rapidez.
2. Dividir el contenido en fragmentos
Los documentos extensos se separan en fragmentos o chunks. Un fragmento debe contener suficiente contexto para ser interpretable, pero no tanto como para mezclar temas distintos. Los límites naturales —títulos, párrafos, tablas o secciones— suelen ser mejores que cortar cada cantidad fija de caracteres.
También se guardan metadatos: URL, título, fecha, propietario, idioma, categoría y permisos. Esos campos permiten filtrar resultados antes de que el contenido llegue al modelo.
3. Crear el índice
Muchos sistemas convierten cada fragmento en un embedding: un vector numérico que representa aspectos de su significado. Los vectores se almacenan en una base de datos vectorial o en un motor que admita búsqueda por similitud.
No es la única opción. La recuperación puede usar palabras clave, BM25, SQL, filtros por metadatos, una API, un grafo de conocimiento o una mezcla. La documentación de OpenAI Retrieval muestra, por ejemplo, búsqueda semántica sobre almacenes vectoriales y búsqueda híbrida que equilibra similitud semántica y coincidencia textual.
4. Recuperar candidatos
Cuando llega una pregunta, el sistema la transforma en una consulta y busca los fragmentos más pertinentes. Puede aplicar filtros como organización, proyecto, fecha, idioma o nivel de acceso.
Aquí aparecen dos métricas básicas:
- Recall o cobertura: si la evidencia necesaria aparece entre los candidatos recuperados.
- Precisión o relevancia: qué proporción de esos candidatos realmente ayuda a responder.
Recuperar demasiados fragmentos puede aumentar la cobertura, pero también introduce ruido, coste y distracciones. Recuperar muy pocos reduce el ruido, pero puede dejar fuera una excepción importante.
5. Reordenar y construir el contexto
Un re-ranking puede volver a puntuar los candidatos respecto de la pregunta y conservar solo los mejores. Después, el sistema arma el contexto con instrucciones claras, evidencia, identificadores de fuente y la consulta original.
El prompt debería distinguir entre instrucciones y documentos. Además, debe indicar qué hacer si la evidencia es insuficiente: pedir aclaración, declarar que no encontró respuesta o derivar a una persona. Forzar al modelo a responder siempre aumenta el riesgo de invención.
6. Generar, citar y registrar
El LLM redacta la respuesta. Un sistema bien diseñado conserva la relación entre cada fragmento y su origen para mostrar citas o enlaces verificables. También registra la consulta, los resultados recuperados, sus puntuaciones y la respuesta, respetando las políticas de privacidad. Sin esa trazabilidad es difícil diagnosticar un fallo.
Ejemplo de RAG aplicado a una búsqueda de contenidos
Imagina un asistente para una plataforma educativa. Un alumno pregunta: “¿Cuánto tiempo tengo para completar el proyecto final y qué debo entregar?”.
Sin RAG, el modelo responde según su entrenamiento general o según información pegada manualmente en el prompt. Puede inventar un plazo plausible.
Con RAG, el flujo sería:
- Filtrar la búsqueda al curso y la matrícula del alumno.
- Recuperar la sección vigente del proyecto final y la rúbrica de entrega.
- Reordenar los fragmentos para priorizar la política actual sobre versiones antiguas.
- Generar una respuesta breve con enlaces a la lección y la rúbrica.
- Declarar que no hay un plazo visible si la fuente no lo especifica.
La mejora no consiste solo en “buscar mejor”. El sistema convierte resultados dispersos en una respuesta y mantiene un camino hacia la evidencia original.
Cómo mejora RAG la búsqueda de contenidos
RAG puede mejorar la experiencia de búsqueda en cuatro niveles.
Recupera por significado, no solo por palabras
La búsqueda semántica puede relacionar una consulta como “cancelar mi plan” con un documento titulado “procedimiento de baja”, aunque no compartan las mismas palabras. La búsqueda léxica sigue siendo valiosa para códigos, nombres propios, cifras y frases exactas; por eso muchos sistemas combinan ambas.
Sintetiza varios resultados
Un buscador tradicional devuelve enlaces. RAG puede comparar fragmentos, reunir pasos y redactar una respuesta. Esa síntesis ahorra navegación, pero debe conservar las fuentes para que el usuario pueda verificarla.
Actualiza el conocimiento sin reentrenar
Si cambia una política, se actualiza o reindexa el documento correspondiente. No es necesario modificar los pesos del modelo. La actualización no siempre es instantánea: depende de la canalización de ingesta, el estado del índice y las cachés.
Aplica contexto y permisos
La recuperación puede limitarse a los documentos que una persona puede ver. Este control debe suceder antes de enviar fragmentos al LLM. Ocultar una cita en la interfaz no corrige una filtración si el contenido privado ya entró en el contexto.
| Enfoque | Qué devuelve | Ventaja principal | Límite principal |
|---|---|---|---|
| Búsqueda por palabras | Documentos con coincidencias textuales | Precisa para términos exactos | Puede perder sinónimos y paráfrasis |
| Búsqueda semántica | Fragmentos cercanos por significado | Encuentra contenido conceptualmente relacionado | Puede confundir conceptos próximos |
| RAG | Respuesta generada a partir de fragmentos recuperados | Síntesis con contexto y posibles citas | Añade errores posibles en recuperación y generación |
Componentes de una arquitectura RAG
| Componente | Función | Pregunta de control |
|---|---|---|
| Fuentes | Proporcionan el conocimiento consultable | ¿Son vigentes, confiables y atribuibles? |
| Ingesta y chunking | Limpian y dividen los documentos | ¿Cada fragmento conserva el contexto necesario? |
| Índice | Permite localizar candidatos | ¿Admite filtros y el tipo de consulta real? |
| Recuperador | Selecciona fragmentos relevantes | ¿Encuentra la evidencia en el top-k? |
| Re-ranker | Reordena candidatos | ¿Mejora la relevancia sin demasiada latencia? |
| Constructor de contexto | Combina instrucciones, fuentes y pregunta | ¿Separa evidencia de instrucciones no confiables? |
| LLM | Redacta la respuesta | ¿Se mantiene fiel al contexto? |
| Evaluación y observabilidad | Miden y explican el resultado | ¿Podemos reproducir cada fallo? |
Una base de datos vectorial es común, pero no define por sí sola a RAG. La pieza esencial es que el sistema recupere conocimiento externo y lo use durante la generación.
¿RAG elimina las alucinaciones?
No. RAG puede reducir errores relacionados con información ausente, privada o desactualizada, pero crea una cadena con varios puntos de fallo:
- La fuente puede estar equivocada o desactualizada.
- El fragmento correcto puede no recuperarse.
- El re-ranker puede priorizar evidencia secundaria.
- El contexto puede perder una condición o una tabla importante.
- El modelo puede ignorar, mezclar o interpretar mal la evidencia.
- Una instrucción maliciosa dentro de un documento puede intentar desviar al modelo.
Por eso conviene separar dos preguntas: “¿recuperamos la evidencia correcta?” y “¿la respuesta representa fielmente esa evidencia?”. El trabajo de Ragas formaliza esta separación al evaluar dimensiones de recuperación, fidelidad y calidad de generación.
Para decisiones médicas, legales, financieras o de seguridad, una respuesta con cita no sustituye la revisión profesional. La cita ayuda a auditar; no convierte automáticamente la conclusión en correcta.
Cómo evaluar un sistema RAG
Empieza con un conjunto de preguntas reales, no solo ejemplos fáciles creados por el mismo equipo que construyó el sistema. Incluye consultas ambiguas, preguntas sin respuesta, documentos contradictorios, cambios recientes y usuarios con permisos distintos.
Mide al menos:
- Cobertura de recuperación: porcentaje de preguntas para las que aparece la evidencia necesaria.
- Relevancia del contexto: proporción de fragmentos útiles frente al ruido.
- Fidelidad: si cada afirmación importante está respaldada por el contexto.
- Corrección de citas: si el enlace señalado contiene realmente la evidencia.
- Tasa de abstención: si el sistema reconoce cuándo no puede responder.
- Latencia y coste: tiempo y recursos consumidos por búsqueda, re-ranking y generación.
- Seguridad: ausencia de filtraciones entre usuarios, proyectos o fuentes.
La evaluación debe repetirse cuando cambian el modelo, los embeddings, el índice, el tamaño de fragmento o las fuentes. Un resultado obtenido con un conjunto concreto no garantiza el mismo comportamiento en otro dominio.
RAG vs. fine-tuning vs. contexto largo
Estas opciones resuelven problemas diferentes.
| Necesidad | RAG | Fine-tuning | Contexto largo |
|---|---|---|---|
| Consultar datos recientes o privados | Adecuado | No actualiza conocimiento por sí solo | Adecuado si el material cabe y se controla |
| Mostrar procedencia | Facilita citas por fragmento | Difícil atribuir una salida a un ejemplo | Posible si se conserva la referencia |
| Cambiar estilo o formato estable | No es su objetivo principal | Adecuado | Se puede instruir, con coste repetido |
| Actualizar contenido | Reindexar la fuente | Volver a preparar y entrenar | Sustituir el contexto enviado |
| Colección muy pequeña | Puede ser complejidad innecesaria | Normalmente innecesario | Suele ser la opción más simple |
La regla práctica es: usa RAG para aportar conocimiento, fine-tuning para ajustar comportamiento y contexto largo cuando la colección completa cabe, es estable y enviarla resulta aceptable. Anthropic señala precisamente que, para bases pequeñas que caben en la ventana de contexto, incluir el material completo puede ser más sencillo que construir recuperación.
Variantes: RAG híbrido, contextual, agentic y GraphRAG
- RAG híbrido: combina búsqueda semántica y léxica. Ayuda cuando una consulta mezcla conceptos con identificadores exactos.
- RAG contextual: añade a cada fragmento una breve explicación de su posición dentro del documento antes de indexarlo. En sus experimentos publicados, Anthropic midió menos fallos de recuperación al combinar contexto, BM25 y re-ranking; el porcentaje es específico de sus conjuntos y configuración, no una garantía universal.
- Agentic RAG: un agente decide si necesita buscar, reformula consultas, usa varias fuentes y puede repetir la recuperación antes de responder. Aporta flexibilidad, pero también más coste, latencia y superficie de error.
- GraphRAG: organiza entidades y relaciones en un grafo. La documentación de Microsoft Research lo orienta a preguntas que necesitan conectar información distribuida o resumir patrones globales en colecciones grandes.
No conviene elegir una variante por moda. Primero identifica el fallo del sistema básico: si faltan coincidencias exactas, prueba búsqueda híbrida; si los fragmentos pierden significado, revisa chunking o contexto; si la pregunta requiere relaciones globales, evalúa un grafo.
Riesgos de seguridad, privacidad y rendimiento
Un sistema RAG trata los documentos recuperados como entrada no confiable. Un archivo puede contener instrucciones que intenten cambiar el comportamiento del modelo. Separa instrucciones de datos, limita herramientas, valida salidas y no permitas que el texto recuperado otorgue permisos.
Aplica controles de acceso en la consulta, no después de generar. Cifra datos sensibles, define retención de registros y revisa qué contenido se envía a cada proveedor. En entornos regulados, conserva evidencia de la versión del documento usada.
En rendimiento, cada etapa añade tiempo: reescritura de consulta, búsqueda, filtros, re-ranking y generación. Mide el presupuesto de latencia completo. Cachear respuestas solo es seguro si la clave incluye usuario, permisos, versión de fuente y demás contexto que cambie el resultado.
Cuándo usar RAG y cuándo evitarlo
RAG suele encajar cuando:
- El conocimiento cambia con frecuencia.
- Las respuestas deben basarse en documentación privada o especializada.
- Es importante enlazar o citar la fuente.
- La colección es demasiado grande para enviarla completa en cada consulta.
- Se necesitan filtros por fecha, producto, cliente o nivel de acceso.
Puede ser innecesario cuando:
- La tarea es creativa y no requiere conocimiento externo.
- La base es pequeña y cabe de forma segura en el contexto.
- Una consulta SQL o un filtro determinista responde mejor que un LLM.
- No existe una fuente confiable que indexar.
- No hay capacidad para evaluar, observar y mantener la canalización.
Checklist para empezar con RAG
- Define qué preguntas debe responder y cuáles debe rechazar.
- Elige una fuente de verdad con propietario y fecha de actualización.
- Crea un conjunto inicial de preguntas y respuestas verificables.
- Prueba primero la recuperación más simple que pueda funcionar.
- Añade búsqueda semántica, filtros o re-ranking solo si mejoran las métricas.
- Exige citas y una conducta explícita ante evidencia insuficiente.
- Prueba permisos, documentos maliciosos y consultas sin respuesta.
- Registra resultados de recuperación y versión de las fuentes.
- Mide calidad, latencia y coste antes y después de cada cambio.
- Revisa el sistema de forma continua; el índice también envejece.
Para recordar el concepto, piensa así: RAG no hace que el modelo “sepa” permanentemente tus documentos; le entrega evidencia relevante justo antes de responder. Si quieres la versión breve, consulta la definición de RAG en el glosario. Para decidir entre técnicas, continúa con RAG vs. fine-tuning.
Actualizado: 13 de julio de 2026.