Flujo de trabajo de RAG de extremo a extremo: cómo funciona la generación aumentada por recuperación

La generación aumentada por recuperación (RAG) es un patrón de arquitectura de AI que conecta modelos de lenguaje grandes con fuentes de conocimiento externas en el momento de la inferencia, lo que permite a esos modelos generar respuestas precisas y conscientes del contexto que van más allá de sus datos de entrenamiento estáticos. En lugar de depender del conocimiento codificado durante el preentrenamiento, un sistema RAG recupera documentos relevantes de una base de datos externa en respuesta a cada consulta del usuario e inyecta ese contenido en el prompt del LLM antes de la generación. El resultado es un sistema de AI generativa que produce respuestas precisas y específicas del dominio basadas en fuentes verificadas, sin requerir un reentrenamiento completo del modelo cada vez que cambia el conocimiento subyacente.

Los LLMs a menudo proporcionan respuestas desactualizadas debido a los límites de conocimiento y no pueden acceder a documentos internos de propiedad exclusiva o fuentes de datos externas en tiempo real. RAG aborda directamente esta limitación. Más del 60 % de las organizaciones están desarrollando activamente herramientas de recuperación impulsadas por AI, lo que refleja un cambio fundamental de depender únicamente de la memoria del modelo a conectar dinámicamente la AI a bases de conocimiento activas que contienen documentos internos, documentación de productos y datos actuales.

Esta guía recorre el flujo de trabajo completo de RAG, desde los componentes de la arquitectura y la ingesta de datos hasta la recuperación híbrida, el diseño de prompts, la evaluación y el despliegue, con orientación práctica para los equipos que crean pipelines de RAG en producción.

Componentes clave de una arquitectura RAG

Los sistemas RAG contienen cuatro componentes principales: una base de conocimiento que almacena conocimiento externo, un componente de recuperación de información (el recuperador) que encuentra documentos relevantes para cada consulta, una capa de integración que ensambla el contexto recuperado en un prompt de LLM y un generador (el LLM) que produce la respuesta final. Cada componente se puede optimizar de forma independiente, y la calidad general del pipeline está limitada por el eslabón más débil: un LLM de alta calidad no puede compensar a un recuperador que muestra constantemente documentos irrelevantes.

El recuperador y la base de datos vectorial

El recuperador acepta una consulta de usuario, la convierte en una representación comparable y devuelve los documentos más relevantes de la base de conocimiento. La calidad del recuperador es el factor determinante más importante de la calidad de salida de RAG. La base de datos vectorial almacena representaciones numéricas de fragmentos de documentos, llamados embeddings, lo que permite una búsqueda rápida de similitud a escala. A diferencia de las bases de datos relacionales que coinciden en valores exactos, las bases de datos vectoriales encuentran documentos cuyo significado es semánticamente más cercano a la consulta utilizando métricas de distancia como la similitud de coseno.

El generador y la capa de orquestación

El generador es el modelo de lenguaje grande que recibe el prompt aumentado (la pregunta original del usuario combinada con el contexto recuperado) y produce la respuesta final. La capa de orquestación conecta todos los componentes en un pipeline de RAG coherente, gestionando el ensamblaje de prompts, el historial de conversaciones y el manejo de errores. Los frameworks como LangChain y LlamaIndex proporcionan primitivas de orquestación comunes, mientras que las plataformas como Databricks ofrecen infraestructura gestionada para todo el stack.

Fuentes de datos y conocimiento externo

La gama de fuentes de datos válidas para un sistema RAG es amplia: datos estructurados en tablas relacionales, texto no estructurado en PDFs y archivos markdown, documentos internos como runbooks de ingeniería y políticas de HR, documentación de productos y bases de conocimiento externas. Los datos específicos del dominio (contenido directamente relevante para las preguntas que harán los usuarios) deben ingesarse primero y mantenerse con el mayor cuidado. Los datos internos, incluidos la investigación de propiedad exclusiva y los documentos internos, generan la ventaja más defendible en una implementación de RAG porque representan un conocimiento con el que ningún LLM público fue entrenado.

La pregunta práctica al seleccionar fuentes de datos es la densidad de relevancia: ¿qué porcentaje de documentos indexados se recuperará realmente en respuesta a consultas reales? Las fuentes de alta relevancia justifican los costes computacionales y financieros de la generación de embeddings y la indexación; las fuentes de baja relevancia diluyen la calidad de la recuperación al aumentar el ruido que el recuperador debe filtrar.

Se pueden combinar múltiples fuentes de datos en un solo sistema RAG (por ejemplo, emparejar un corpus de documentación de productos con una base de datos de clientes en tiempo real) siempre que el pipeline de ingesta normalice cada fuente a un formato de texto coherente. Los equipos deben documentar el linaje de datos de cada fuente indexada para que el origen de cualquier documento recuperado pueda rastrearse hasta su origen autorizado, lo que permite flujos de trabajo de auditoría y cumplimiento en industrias reguladas.

Modelo de embedding y almacén de vectores

Selección de un modelo de embedding

Un modelo de embedding es un modelo de lenguaje especializado que convierte texto en representaciones numéricas: vectores de alta dimensión que codifican el significado semántico. Cuando un usuario envía una consulta, el mismo modelo de embedding convierte esa entrada del usuario en un vector comparable, lo que permite la comparación matemática entre la consulta y todos los embeddings de documentos almacenados. El modelo de embedding utilizado durante la ingesta debe ser idéntico al utilizado en el momento de la consulta.

La selección del modelo implica equilibrios entre la calidad de la representación, la dimensionalidad del vector, la latencia de inferencia y los costes financieros. Los modelos de propósito general como bge-large-en producen vectores de 1,024 dimensiones que funcionan en diversos dominios. Los modelos de embedding específicos del dominio ajustados en texto técnico a menudo superan a los modelos generales en tareas de recuperación estrechas. Los modelos de embedding transforman el texto sin formato en las representaciones numéricas que hacen posible la búsqueda de similitud vectorial.

Los modelos de embedding también se pueden evaluar por su capacidad para manejar consultas que se formulan de manera diferente a los documentos que deben recuperar, una propiedad llamada robustez multilingüe o de paráfrasis. En entornos empresariales donde los usuarios formulan preguntas de manera conversacional mientras que la documentación se escribe de manera formal, este puente semántico es fundamental. Probar el modelo de embedding con una muestra representativa de consultas de usuarios reales antes de comprometerse con una ejecución de indexación en producción puede evitar una costosa regeneración de embeddings de todo el corpus más adelante.

Estrategia de fragmentación e indexación

Los documentos grandes deben dividirse en fragmentos más pequeños antes de la generación de embeddings porque la ventana de contexto del modelo de embedding es finita y porque los fragmentos más pequeños producen una recuperación más precisa. El tamaño del fragmento afecta directamente a la calidad de la salida: los fragmentos que son demasiado pequeños pierden el contexto circundante, mientras que los fragmentos que son demasiado grandes diluyen el pasaje específico más relevante para la pregunta del usuario. Las estrategias comunes incluyen la división de tamaño fijo por recuento de tokens y la división por límites de oraciones con bordes superpuestos para reducir el riesgo de que el contexto clave quede en un límite.

Una vez generados los embeddings, los vectores se almacenan e indexan en el almacén de vectores. Un índice de vectores que utiliza algoritmos como HNSW organiza los embeddings para permitir la búsqueda aproximada de vecinos más cercanos a escala, lo que reduce la recuperación de un escaneo lineal de todos los embeddings a una búsqueda de menos de un milisegundo.

Recuperación de información y búsqueda híbrida

La búsqueda semántica, la columna vertebral de la mayoría de los sistemas RAG, encuentra documentos cuyo significado es más cercano a la consulta del usuario, manejando la paráfrasis y los sinónimos de forma natural. Databricks AI Search implementa la búsqueda de vectores semánticos con sincronización automática desde las tablas Delta para que la base de conocimiento refleje los nuevos datos sin necesidad de una reindexación manual.

La búsqueda semántica pura tiene una debilidad conocida con las consultas de coincidencia exacta: códigos de error específicos, números de versión o entidades nombradas. La búsqueda híbrida aborda esto al combinar la búsqueda de vectores semánticos con la búsqueda de palabras clave BM25, un modelo probabilístico de frecuencia de términos que destaca en la coincidencia de términos exactos y raros. Ejecutar ambas rutas de búsqueda en paralelo y fusionar los resultados mediante la fusión de rango recíproco mejora la eficiencia de la recuperación en una distribución de consultas más amplia.

Un paso de reranking puede mejorar aún más los resultados al aplicar un modelo cross-encoder para puntuar cada documento recuperado en relación con la consulta y reordenar los resultados para que los documentos más relevantes aparezcan en la parte superior. Los métodos de recuperación como el reranking mejoran significativamente la precisión y son especialmente valiosos cuando la ventana de contexto del LLM limita la cantidad de documentos que se pueden pasar al generador.

Los umbrales de similitud añaden un filtro de calidad final: los documentos cuya puntuación de relevancia cae por debajo de un límite mínimo deben filtrarse por completo en lugar de pasarse al generador como contexto de baja calidad. Pasar un contexto irrelevante es peor que no pasar ningún contexto: consume la ventana de contexto y aumenta el riesgo de que el LLM mezcle información correcta e incorrecta en la respuesta generada. Establecer umbrales conservadores y supervisar la tasa de filtrado a lo largo del tiempo es una forma sencilla de mantener la calidad de la recuperación sin cambios arquitectónicos.

Cómo funciona RAG: de la ingesta a la generación

El flujo de trabajo de RAG sigue cinco etapas secuenciales que transforman la pregunta de un usuario en una respuesta fundamentada y precisa.

Etapa 1: Ingestar y normalizar datos externos

El pipeline de RAG comienza con la ingesta de datos. Los documentos sin procesar se cargan en un pipeline de ETL que limpia y normaliza el texto: elimina el contenido de relleno, estandariza los espacios en blanco y extrae contenido estructurado de tablas y código. La arquitectura de lakehouse de datos centraliza la ingesta de contenido tanto estructurado como no estructurado bajo un gobierno unificado, lo que la convierte en una base natural para la base de conocimiento de RAG.

Etapa 2: Fragmentar, generar embeddings e indexar

Los documentos limpios se dividen en fragmentos, cada fragmento se pasa por el modelo de embedding para generar un vector, y los embeddings resultantes se escriben en el almacén de vectores junto con el texto original y los metadatos (título del documento, fecha, URL de origen). Los metadatos permiten la recuperación filtrada, lo que restringe los resultados a los documentos publicados dentro de un rango de fechas o accesibles para un rol de usuario específico. RAG requiere actualizaciones continuas para mantener la relevancia de los datos; los sistemas de producción necesitan pipelines automatizados que detecten los documentos de origen actualizados y activen el re-embedding de forma programada o basada en eventos.

Stage 3: Recuperar documentos relevantes

Cuando un usuario envía una consulta, el sistema RAG aplica el mismo modelo de embedding para convertir la entrada del usuario en una representación vectorial y consulta el almacén de vectores, ejecutando una búsqueda de similitud que devuelve los top-k fragmentos de documentos más relevantes. El valor k (cuántos fragmentos recuperar) equilibra la cobertura de la recuperación con el consumo de la ventana de contexto y debe ajustarse para el LLM de destino.

Stage 4: Aumentar el prompt del LLM

Los documentos recuperados se ensamblan en el prompt aumentado. Una estructura típica coloca primero una instrucción del sistema ("Responda a la pregunta del usuario basándose únicamente en el contexto proporcionado. Si no puede encontrar la respuesta en el contexto, dígalo."), seguida de los fragmentos de texto recuperados y, a continuación, la pregunta original del usuario. Colocar los documentos más relevantes al principio suele mejorar el enfoque, especialmente en el caso de modelos propensos al fenómeno de "perdido en el medio" (lost in the middle), donde el contexto cercano al principio y al final recibe más atención que el contenido del centro.

Stage 5: Generar la respuesta final

El generador recibe el prompt aumentado y produce la respuesta final. El postprocesamiento puede añadir citas de fuentes, filtrar resultados fuera de tema o estructurar los resultados en un formato coherente. El LLM genera respuestas precisas porque tiene acceso al contexto recuperado en lugar de depender únicamente de los datos de entrenamiento estáticos del preentrenamiento.

La gestión del historial de conversaciones es un aspecto importante de la capa de generación para las aplicaciones RAG multiturno. Cuando el sistema RAG debe recordar intercambios anteriores en una sesión (para que los usuarios puedan hacer preguntas de seguimiento que hagan referencia a respuestas anteriores), el historial de conversaciones debe incorporarse al prompt aumentado. Esto aumenta la longitud efectiva del prompt y reduce la ventana de contexto disponible para los documentos recién recuperados. Los equipos deben implementar una gestión explícita del presupuesto de contexto que asigne tokens entre el historial, el contexto recuperado y la consulta actual del usuario.

AI generativa, diseño de prompts de LLM y orquestación

Una plantilla de prompt de LLM reutilizable separa las instrucciones estáticas (rol del sistema, restricciones de comportamiento, formato de salida) del contenido dinámico insertado en tiempo de ejecución: el contexto recuperado y la consulta del usuario. La instrucción de responder "solo a partir del contexto proporcionado" es especialmente importante para los sistemas RAG. Sin ella, los modelos de AI generativa complementarán el contenido recuperado con datos de entrenamiento memorizados, lo que producirá respuestas que mezclan información verificada con conocimientos del modelo potencialmente incorrectos.

La inyección de citas (añadir metadatos del documento de origen a cada respuesta generada) permite a los revisores humanos verificar que las respuestas se basan en datos reales recuperados. En los despliegues empresariales, el soporte de citas y las instrucciones del sistema que restringen el alcance del tema, la longitud de la respuesta y el comportamiento de escalación son requisitos de producción para obtener respuestas precisas.

Ajuste fino, conocimiento del dominio y alternativas

El ajuste fino adapta un modelo preentrenado a un dominio específico modificando los pesos del modelo en un conjunto de datos seleccionado. A diferencia de RAG, el ajuste fino cambia el comportamiento del modelo subyacente (su vocabulario, tono y conocimiento implícito del dominio) en lugar de inyectar contexto en el tiempo de inferencia. El ajuste fino es adecuado cuando el modelo base no comprende de manera constante la terminología específica del dominio o cuando el estilo de respuesta requerido no se puede lograr únicamente mediante la ingeniería de prompts.

El ajuste fino no es un sustituto eficaz de RAG cuando el objetivo es acceder a información actualizada. El ajuste fino de LLMs con nuevos datos genera costos computacionales y financieros significativos y no puede mantener el ritmo de las bases de conocimientos en constante cambio. La mayoría de los sistemas de producción combinan ambos: un modelo ajustado maneja el tono y la terminología del dominio, mientras que el flujo de trabajo de RAG proporciona acceso al conocimiento. Confiar únicamente en el ajuste fino para el acceso al conocimiento es un error común y costoso.

La ingeniería de prompts (diseñar instrucciones del sistema y ejemplos few-shot para guiar el comportamiento del modelo) sigue siendo el punto de partida básico para cualquier personalización de LLM. No requiere infraestructura adicional y produce resultados de inmediato. Para los sistemas RAG, la ingeniería de prompts controla cómo se presenta el contexto recuperado al modelo y cómo este señala la incertidumbre cuando los documentos recuperados no responden por completo a la pregunta del usuario. Por definición, cada sistema RAG incorpora ingeniería de prompts, ya que el ensamblaje del prompt aumentado es en sí mismo una forma de diseño de prompts.

Evaluación de RAG y pruebas de recuperación

Medición de la calidad de la recuperación

La evaluación de RAG debe valorar el componente de recuperación de información y el componente de generación de forma independiente. La evaluación de la recuperación utiliza precisión@k: de los k documentos recuperados para una consulta determinada, ¿qué fracción es realmente relevante? Un conjunto de datos de evaluación de verdad fundamental (consultas emparejadas con documentos y respuestas correctas conocidas) es el requisito previo necesario. Crear este conjunto de datos requiere mucho trabajo pero es esencial; sin él, los equipos no pueden distinguir las mejoras reales de la evaluación de RAG de la variación aleatoria.

Medición de la fidelidad de la generación

La evaluación de la generación mide si las respuestas del modelo son fieles al contexto recuperado, es decir, si la respuesta generada contiene información incorrecta o inventada extraída de los datos de entrenamiento del modelo en lugar de las fuentes recuperadas. La evaluación de LLM como juez, donde un segundo LLM califica la fidelidad de cada respuesta, proporciona una cobertura escalable en grandes conjuntos de pruebas. La evaluación de LLM con MLflow integra las métricas de recuperación y generación en un marco unificado de seguimiento de experimentos. RAG reduce las alucinaciones en los modelos de AI generativa, pero no puede eliminar todas las alucinaciones de AI en las respuestas generadas.

Monitoreo, gobernanza y seguridad

Los sistemas RAG heredan los requisitos de gobernanza de sus fuentes de datos. Los usuarios solo deben recuperar los documentos a los que están autorizados a acceder. Unity Catalog proporciona una gobernanza detallada en toda la base de conocimientos de RAG: índices de vectores, tablas Delta y endpoints de modelos gobernados bajo un modelo de control de acceso común con un seguimiento completo del linaje de datos. El etiquetado de procedencia (asociar cada respuesta generada con los fragmentos de documentos específicos que la produjeron) permite a los revisores humanos verificar las fuentes citadas y auditar el contenido generado por AI. En las industrias reguladas, la procedencia suele ser un requisito de cumplimiento.

El monitoreo también debe realizar un seguimiento de la desactualización de la base de conocimientos: la brecha entre la última actualización de los documentos de origen y la última actualización del índice RAG. Una base de conocimientos que devuelve constantemente documentos desactualizados es operacionalmente equivalente a un LLM con un límite de entrenamiento obsoleto; ambos producen respuestas que eran precisas en algún momento pero que ya no reflejan la información actual. Las alertas automatizadas de desactualización que se activan cuando un documento de origen no se ha vuelto a indexar dentro de un SLA definido evitan la degradación silenciosa de la precisión de las respuestas a lo largo del tiempo.

Los almacenes de vectores deben estar cifrados en reposo, los endpoints de inferencia de LLM y embeddings deben desplegarse dentro de límites de red seguros, y los registros de auditoría deben capturar todas las consultas y eventos de recuperación para detectar accesos anómalos.

Los controles de acceso basados en roles en la capa de recuperación son especialmente importantes en los despliegues de RAG multiinquilino, donde diferentes usuarios o equipos solo deben recuperar documentos de sus dominios de datos autorizados. Sin controles de acceso en la capa de recuperación, una consulta de usuario podría revelar documentos confidenciales de una unidad de negocio no relacionada, un fallo de gobernanza de datos que es invisible en la respuesta generada pero que está presente en el registro de recuperación subyacente. Diseñar el control de acceso en la arquitectura de RAG desde el principio es significativamente más fácil que adaptarlo después de que se hayan indexado los datos.

Escalado operativo y mejores prácticas de despliegue

La ingesta inicial de una gran base de conocimientos requiere embeddings por lotes a escala. Después de la carga inicial, la ingesta incremental solo vuelve a generar embeddings para los documentos nuevos o actualizados. Los sistemas deben escalar automáticamente el cómputo de embeddings para las cargas iniciales y reducirlo para las actualizaciones incrementales en curso. El embedding por lotes es significativamente más económico por documento que el embedding en tiempo real; los sistemas de producción deben utilizar el procesamiento por lotes para las cargas de trabajo de ingesta y reservar el embedding en tiempo real para el procesamiento de consultas de los usuarios.

La inferencia de LLM suele dominar los costos operativos de RAG. Pasar más documentos recuperados al LLM aumenta proporcionalmente el costo de inferencia por consulta; los equipos deben establecer políticas explícitas sobre la cantidad máxima de documentos recuperados y la longitud del prompt para limitar los costos. Cada componente (inferencia de embedding, almacén de vectores, servicio de orquestación, endpoint de LLM) debe estar contenedorizado para un despliegue reproducible con lógica de reintento y patrones de disyuntor (circuit-breaker) para la conmutación por error.

Databricks MLflow proporciona seguimiento de experimentos, registro de modelos y herramientas de evaluación integradas con todo el stack de RAG, lo que permite a los equipos realizar un seguimiento de versiones de los modelos de embedding, rastrear experimentos de recuperación y gestionar el ciclo de vida del pipeline de RAG en producción.

Preguntas frecuentes

¿En qué se diferencia el flujo de trabajo de RAG del ajuste fino de un LLM?

El flujo de trabajo de RAG recupera documentos relevantes en el momento de la inferencia y los introduce en el prompt del LLM, mientras que el ajuste fino (fine-tuning) modifica los pesos del modelo mediante el entrenamiento con nuevos datos antes del despliegue. RAG proporciona acceso dinámico a información actualizada sin necesidad de volver a entrenar el modelo, lo que lo hace más rentable para conocimientos que cambian con frecuencia. El ajuste fino es más adecuado para adaptar el estilo de respuesta, el vocabulario del dominio o la especialización en tareas. La mayoría de los sistemas en producción combinan ambos: un modelo con ajuste fino para el tono del dominio, combinado con un flujo de trabajo de RAG para el acceso al conocimiento.

¿Cuál es el modo de fallo más común en un sistema RAG?

La mala calidad de la recuperación es el modo de fallo más común de RAG. Si el componente de recuperación de información devuelve documentos irrelevantes, el LLM genera respuestas que parecen seguras pero que no se basan en información correcta, un fallo que es más difícil de detectar que las alucinaciones obvias. Los fallos de recuperación se deben a un chunking inadecuado, a una discrepancia entre el espacio semántico del modelo de embedding y la distribución de las consultas, a una cobertura de búsqueda híbrida insuficiente o a una base de conocimientos que simplemente carece de la información por la que preguntan los usuarios. Evaluar la precisión de la recuperación por separado de la fidelidad de la generación es esencial para diagnosticar este tipo de fallos.

¿Cómo reduce RAG las alucinaciones de la AI?

RAG reduce las alucinaciones en los modelos de AI generativa al proporcionar al LLM un contexto específico y verificado para cada consulta, en lugar de requerir que el modelo responda de memoria. Cuando el prompt indica explícitamente al modelo que responda únicamente a partir del contexto recuperado, el modelo tiene menos margen para inventar información. La reducción es proporcional a la calidad de la recuperación: cuanto más relevantes y completos sean los documentos recuperados, menos tendrá que inferir el modelo. RAG no puede eliminar todas las alucinaciones de la AI, ya que los modelos ocasionalmente malinterpretan el contexto recuperado, pero reduce sustancialmente su frecuencia en comparación con la generación sin recuperación.

¿Qué fuentes de datos externas funcionan mejor con RAG?

Las fuentes de alta densidad y específicas de un dominio producen los mejores resultados de recuperación: documentación de productos, bases de conocimientos técnicos, documentos de políticas de la empresa y repositorios internos seleccionados. Las fuentes con un formato uniforme y límites de párrafo claros se dividen en fragmentos (chunking) y se convierten en embeddings de manera más confiable que el contenido con una estructura laxa. Las fuentes de conocimiento externas de proveedores externos (como presentaciones regulatorias, estándares de la industria y literatura académica) amplían la cobertura más allá del contenido propio. Los sistemas RAG dependen de la calidad de las fuentes de datos externas; los documentos de origen inexactos o con un formato inconsistente producen respuestas inexactas, independientemente de la calidad de la arquitectura de recuperación.

¿Cuáles son los componentes clave de una arquitectura RAG?

Una arquitectura RAG contiene cuatro componentes principales: la base de conocimientos (el almacén de datos externos indexados), el recuperador (el componente de recuperación de información que extrae los documentos relevantes), la capa de integración (la lógica de orquestación que ensambla el contexto en un prompt de LLM) y el generador (el modelo de lenguaje grande que produce la respuesta final). La base de datos vectorial es un elemento de infraestructura crítico de la base de conocimientos, que almacena representaciones numéricas de los fragmentos de documentos (chunks) y permite una búsqueda rápida de similitud semántica. Obtenga más información sobre los patrones de arquitectura de generación aumentada por recuperación en la página del glosario de Databricks.

(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original