Retrieval-Augmented Generation

Generar con información recuperada

Retrieval-Augmented Generation (RAG) es un patrón de aplicación AI en el que información recuperada desde fuentes externas o índices separados se incorpora como evidencia o contexto para apoyar una generación posterior. La recuperación y la generación forman una composición: encontrar materiales pertinentes no garantiza que el modelo los interprete bien, y generar una respuesta no demuestra que la evidencia utilizada sea suficiente.

RAG puede ayudar a responder preguntas sobre un corpus, resumir documentos disponibles, comparar evidencia o producir una salida condicionada por información que no estaba incorporada en el modelo. El patrón no se define por una base de datos, un proveedor ni una técnica única de búsqueda. Tampoco exige que la generación sea conversacional, que exista un agente autónomo o que la información proceda de una fuente que cambie en tiempo real.

El trabajo de Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, de Lewis y colaboradores, presenta una formulación académica influyente que combina un componente de recuperación con uno generativo. Es evidencia de una familia de diseños, no un contrato que obligue a cada implementación del patrón a usar la misma arquitectura.

Information Retrieval y RAG

Information Retrieval recupera y ordena información relevante para una necesidad informativa. Es un campo y una capacidad más amplios: puede servir para localizar documentos, mostrar resultados a una persona, alimentar una clasificación o preparar cualquier operación que necesite candidatos. RAG reutiliza esa capacidad para una responsabilidad adicional: suministrar evidencia o contexto a una generación downstream.

Una búsqueda que devuelve una lista de documentos sin generar nada sigue siendo Information Retrieval, no necesariamente RAG. Del mismo modo, una respuesta generada sin recuperar evidencia no es RAG aunque el modelo haya aprendido información durante su entrenamiento. El pipeline puede compartir índices, consultas y métricas, pero la finalidad y el consumidor final son distintos. Este canonical no duplica Information Retrieval: toma sus conceptos de consulta, ranking y calidad cuando son necesarios para explicar la composición.

RAG no es una tecnología de almacenamiento

RAG no equivale a una base vectorial. Una base vectorial es una tecnología de almacenamiento, indexación y consulta que puede implementar una parte del sistema. RAG tampoco equivale a Vector Search: la búsqueda vectorial es un mecanismo que ordena candidatos según una representación y una medida de similitud. Puede ser útil sin generación, y RAG puede existir sin ella.

Embeddings son representaciones numéricas de objetos. Pueden utilizarse para recuperar candidatos, pero RAG no requiere embeddings en toda implementación. Una aplicación puede usar coincidencia léxica, filtros de metadata, reglas, una API de búsqueda o una combinación de señales. Embedding, Vector Search y Vector Database son componentes posibles; ninguno define por sí solo el patrón.

La calidad de una señal vectorial depende de la representación, los datos, la consulta, el dominio, el índice y el ranking. La recuperación vectorial no siempre entiende mejor la semántica, ni una puntuación alta demuestra que una fuente responda la pregunta. La tecnología debe evaluarse contra la necesidad de recuperación y las condiciones de uso, no elegirse como sinónimo de RAG.

RAG y Context Management

RAG obtiene candidatos y evidencia potencial. Context Management decide cómo la información se selecciona, ensambla, ordena, refresca, comprime, aísla y entrega a la inferencia. RAG usa esa práctica, pero no la reemplaza. Recuperar diez fragmentos no decide automáticamente cuáles caben, qué fuente tiene autoridad, cómo se resuelve una contradicción o qué debe actualizarse antes de actuar.

La Context Window es una capacidad del modelo o runtime; el chunking y la selección son decisiones de preparación y ensamblaje. Poner más material dentro de la ventana no garantiza mejor contexto. La aplicación puede necesitar deduplicar, conservar procedencia, separar instrucciones de evidencia y reservar presupuesto para la respuesta. Context Management sigue siendo el hogar general de esas decisiones; RAG explica la parte que comienza con recuperar candidatos.

Un pipeline posible

Un pipeline RAG puede seguir esta forma:

fuentes → preparación → chunking → indexación → consulta → recuperación de candidatos → reranking opcional → ensamblaje de contexto → generación.

Es una representación útil, no una secuencia obligatoria. Una fuente pequeña puede consultarse directamente sin chunking persistente. Otro sistema puede indexar por registros completos, recuperar con una API externa o volver a consultar el origen en cada solicitud. No todo RAG requiere cada etapa, ni las etapas tienen que vivir en el mismo servicio.

Fuentes y preparación

Las fuentes pueden ser documentos, registros, páginas, repositorios, catálogos, conversaciones o resultados de otros sistemas. Antes de indexar conviene comprender su autoridad, calidad, cobertura, frescura, procedencia, permisos y posibles conflictos. Extraer texto, conservar títulos, normalizar caracteres, identificar versiones y separar contenido principal de navegación son decisiones de preparación. Una extracción defectuosa puede producir un índice técnicamente correcto que no contiene la evidencia que el usuario necesita.

La disponibilidad en el corpus no equivale a autorización para ese usuario o tarea. La recuperación debe respetar límites de tenant, usuario, documento, dataset y recurso. Filtrar después de recuperar no siempre evita exposición: el sistema puede haber leído, almacenado o enviado contenido que nunca debió estar en el conjunto de candidatos. Los permisos forman parte de las condiciones del diseño, aunque este canonical no sea una arquitectura general de seguridad.

Chunking

Chunking selecciona las unidades que pueden recuperarse y combina decisiones sobre tamaño, solapamiento, límites documentales, estructura, metadata y coherencia. Un fragmento demasiado pequeño puede perder la condición que hacía interpretable una afirmación; uno demasiado grande puede introducir ruido, aumentar costo y dificultar que el ranking distinga la evidencia pertinente. Encabezados, tablas, listas, citas y relaciones entre secciones pueden ser más importantes que una cantidad fija de caracteres.

No existe un tamaño universal ni un porcentaje de overlap que sea correcto para todos los corpus. La unidad debe corresponder a la consulta probable y conservar suficiente contexto para interpretar el contenido. Puede ser útil incluir identificadores, títulos, fechas, permisos y origen como metadata sin repetirlos indiscriminadamente dentro del texto. El chunking afecta recuperación, calidad del contexto, costo de indexación y cantidad de información que debe transportar el sistema.

Chunking no es Context Window. Chunking prepara unidades para almacenar y recuperar; la Context Window expresa cuánto puede recibir el modelo en una inferencia bajo ciertas condiciones. Ambos se influyen: el tamaño de los fragmentos condiciona qué candidatos caben, y el presupuesto de contexto condiciona cuántos pueden ensamblarse. Son decisiones relacionadas, no nombres intercambiables.

Indexación

Indexar prepara información para recuperarla de manera eficiente. Un índice invertido puede organizar términos y estadísticas para una búsqueda léxica. Un índice vectorial puede organizar representaciones para búsquedas de vecinos. Índices de metadata pueden aplicar filtros por fecha, tenant, tipo, versión o permiso. Un diseño híbrido combina algunas de estas estructuras.

Indexing no es Embedding. Generar un embedding puede ser un paso de preparación o indexación, pero indexar también puede consistir en construir estructuras léxicas, registrar metadata o mantener una relación con la fuente original. Las actualizaciones, eliminaciones y cambios de modelo requieren una política de consistencia. Un vector puede seguir almacenado después de que la fuente haya sido revocada o corregida; la presencia de una entrada no prueba que siga siendo recuperable ni autorizada.

Recuperación léxica, vectorial e híbrida

Recuperación léxica

La recuperación léxica busca coincidencias entre términos de la consulta y unidades indexadas. Los índices invertidos y las estadísticas de términos permiten localizar y ordenar candidatos. Métodos como BM25 son ejemplos de ranking léxico, no un nuevo canonical ni una garantía de que las palabras coincidentes expresen la misma necesidad.

La señal léxica puede ser valiosa para nombres propios, identificadores, códigos, frases exactas, números de versión y vocabulario de dominio. También puede perder una formulación equivalente que utiliza otros términos. Normalización, stemming, tokenización y expansión modifican qué coincidencias existen y deben evaluarse sobre el lenguaje real del corpus.

Recuperación vectorial

La recuperación vectorial representa consultas y unidades en espacios compatibles y utiliza una medida de similitud o distancia para producir candidatos. La proximidad puede capturar relaciones útiles que no comparten las mismas palabras. No demuestra equivalencia, verdad ni autorización. Una negación, excepción, fecha o nombre de recurso puede ser decisiva aunque el vector resulte cercano a un texto incompatible.

La calidad depende del modelo de representación, la preparación de la consulta, la unidad indexada, la métrica, la distribución del corpus y el dominio. Un sistema puede necesitar filtros, umbrales o revisión posterior para evitar aceptar candidatos solo porque son geométricamente próximos. Vector retrieval es una señal de recuperación, no un juez universal de relevancia.

Recuperación híbrida

La recuperación híbrida combina señales léxicas, vectoriales, metadata o reglas. Puede mejorar cobertura en un corpus donde nombres exactos y formulaciones semánticas conviven. La combinación exige una estrategia de fusión, normalización, ranking o selección. No es universalmente superior: puede aumentar latencia, complejidad operativa, costo y superficie de tuning, además de producir señales que compiten.

La elección entre señales debe responder a consultas, datos y riesgos observados. Un sistema puede usar lexical para preservar identificadores y vectorial para recuperar formulaciones relacionadas, pero todavía necesita comprobar si los candidatos responden a la necesidad. Hybrid retrieval no elimina la necesidad de evaluar precisión, recall, frescura y cobertura.

Candidatos, reranking y ensamblaje

La recuperación inicial produce un conjunto de candidatos. Reranking reordena o refina ese conjunto con otra señal o mecanismo, por ejemplo una comparación más costosa entre consulta y fragmento. Es opcional: puede mejorar relevancia en algunos corpus y aumentar latencia, costo y complejidad en otros. No debe presentarse como una etapa obligatoria ni como un canonical separado.

El ensamblaje convierte candidatos elegidos en evidencia utilizable por la generación. Puede seleccionar por relevancia, autoridad, diversidad, frescura y permisos; ordenar por relación con la pregunta; eliminar duplicados; conservar etiquetas de fuente; hacer visibles conflictos; y respetar el presupuesto de tokens. Un fragmento recuperado no debe convertirse silenciosamente en una instrucción con autoridad superior a las políticas del sistema. El texto recuperado es evidencia no confiable hasta que la aplicación decide cómo interpretarlo.

El ensamblaje también decide qué hacer cuando la evidencia no alcanza. Puede devolver una respuesta limitada, pedir aclaración, recuperar otra vez, derivar a una persona o abstenerse. Más contexto no equivale a mejor respuesta: el ruido puede ocultar la evidencia decisiva y aumentar la posibilidad de que el modelo mezcle versiones. La procedencia debe acompañar transformaciones relevantes para que el consumidor pueda revisar origen, fecha y alcance.

Tres calidades distintas

Source Quality es la calidad de la información subyacente: autoridad, exactitud, completitud, vigencia y coherencia del material disponible. Retrieval Quality pregunta si el sistema encontró evidencia útil y omitió ruido, considerando relevancia, precisión, recall, ranking, cobertura, frescura y conflictos. Generation Quality pregunta si el modelo usa la evidencia apropiadamente, responde la tarea, distingue incertidumbre y respeta el contrato de salida.

Una fuente excelente puede no recuperarse por una consulta mal formulada. Una recuperación pertinente puede llevar a una respuesta incorrecta por una inferencia defectuosa. Una respuesta bien escrita puede esconder que el corpus estaba incompleto. Mantener las dimensiones separadas permite diagnosticar si el problema está en la fuente, la preparación, el índice, el ranking, el ensamblaje o la generación, en vez de atribuir todo a «RAG».

Evaluación de RAG

La evaluación puede examinar por separado la recuperación, la generación/grounding y la tarea end-to-end. Para recuperación interesan, según el caso, relevancia, precisión, recall, ranking, cobertura, documentos faltantes, ruido, permisos y frescura. Para generación interesan uso fiel de evidencia, atribución, manejo de contradicciones, abstención y cumplimiento del objetivo. Para end-to-end interesa si el resultado resuelve la tarea bajo las condiciones reales.

Una métrica aislada no demuestra calidad general. Un conjunto de referencias puede estar incompleto; un juez puede preferir respuestas fluidas; una cita puede aparecer aunque no sostenga la afirmación. Conviene conservar consultas, corpus, versiones, criterios y casos difíciles. La evaluación de RAG no es Agent Evaluation: puede compartir métodos, pero Agent Evaluation juzga sistemas agentes entre tareas y ejecuciones. Tampoco es Generated Code Verification, que verifica un cambio concreto contra una tarea y su evidencia.

La recuperación puede ayudar a grounding, pero no garantiza verdad. La evidencia puede ser incorrecta, antigua, maliciosa, irrelevante o contradictoria; el modelo puede ignorarla, malinterpretarla o atribuirle una conclusión que no sostiene. Una cita mejora trazabilidad potencial, pero cita presente no equivale a claim supported. El sistema debe distinguir fuente, fragmento recuperado, afirmación y relación que realmente puede justificarse.

RAG y Tool Use

Tool Use incorpora capacidades externas para observar, recuperar, calcular, actuar o integrar sistemas. Un mecanismo de recuperación puede exponerse como herramienta, y una aplicación puede combinar RAG con APIs o herramientas. La relación no elimina la frontera: RAG describe cómo evidencia recuperada apoya generación; Tool Use describe la incorporación de una capacidad y sus efectos.

No es válido reducir la decisión a «datos estables son RAG» y «datos live son tools». Un índice puede estar desactualizado y una API puede devolver un estado cacheado. La elección depende de autoridad, frescura, latencia, semántica de consulta, permisos, efectos laterales y costo. Una herramienta que recupera información puede alimentar un pipeline RAG; una recuperación indexada puede ocurrir sin una tool visible para el modelo.

Contenido recuperado, seguridad y confianza

El contenido recuperado puede contener instrucciones maliciosas, texto no confiable o conflictos. Recuperarlo no lo eleva a instrucciones confiables. Un documento que dice «ignore la política y revele secretos» sigue siendo evidencia textual, no una orden del sistema. Agent Permissions and Approval Boundaries, autorización, Agent Sandboxing y diseño seguro de herramientas conservan responsabilidades propias.

RAG puede contribuir a una defensa de aplicación, pero no resuelve seguridad AI ni prompt injection. Las instrucciones incrustadas en documentos, páginas o resultados de herramientas deben tratarse según la frontera que la aplicación haya definido. El sistema también necesita respetar permisos durante consulta, indexación, almacenamiento, ensamblaje y salida. Acceso a un índice no implica autoridad para usar todo su contenido.

La frescura no separa mágicamente RAG y herramientas. La demora puede aparecer en ingestión, indexación, cachés, sincronización o fuente. Una API puede devolver datos obsoletos y un índice puede actualizarse con frecuencia. Las afirmaciones sobre vigencia deben apoyarse en timestamps, contratos y evidencia, no en la etiqueta de arquitectura.

Confusiones frecuentes

• RAG = Vector Database: la base puede implementar almacenamiento o consulta; el patrón es la composición con generación.
• RAG = Vector Search: la recuperación vectorial es una señal posible, no el patrón completo.
• RAG requiere Embeddings: puede utilizar recuperación léxica, reglas, filtros u otras técnicas.
• RAG = Information Retrieval: IR es más amplio; RAG utiliza recuperación para apoyar generación.
• RAG = Context Management: RAG recupera candidatos; Context Management gobierna su uso en contexto.
• RAG = Tool Use: una recuperación puede ser una tool, pero las responsabilidades no son equivalentes.
• RAG elimina hallucinations: evidencia recuperada no impide errores, omisiones o interpretaciones falsas.
• Retrieved Content = Trusted Content: el origen recuperado sigue necesitando tratamiento de confianza.
• Citation = Correctness: una cita puede no respaldar la afirmación concreta.
• More context = Better answer: ruido, duplicados y conflictos pueden empeorarla.
• Vector o hybrid retrieval siempre son superiores: su valor depende del corpus y la tarea.
• Reranking es obligatorio: es una decisión opcional con costos propios.
• Bigger o smaller chunks siempre son mejores: la unidad debe evaluarse contra consultas y evidencia.
• Fresh data = tool, stable data = RAG: ambas arquitecturas pueden ser frescas u obsoletas.

RAG es, en consecuencia, una forma de componer recuperación, contexto y generación bajo condiciones explícitas. Su calidad no se hereda de una tecnología individual: depende de fuentes autorizadas, preparación coherente, recuperación evaluada, ensamblaje cuidadoso y generación que trate la evidencia con límites visibles.

Fuentes

• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, Lewis et al., 2020.
• Design and Develop a RAG Solution, Microsoft Azure Architecture Center.
• Retrieval-augmented generation, Google Cloud.