Generación Aumentada por Recuperación

La generación aumentada por recuperación es un patrón que recupera información relevante de fuentes fuera de los parámetros aprendidos por el modelo y la suministra como contexto antes de que el modelo genere una respuesta [1].

RAG es una forma de hacer que una IA responda usando información externamente recuperada en el momento de la generación, ya sea o no que material similar haya aparecido en los datos de entrenamiento del modelo. En lugar de pedirle al modelo que responda a partir de sus parámetros aprendidos y el prompt solo, el sistema primero busca en un almacén de documentos, recupera pasajes relevantes, los agrega al prompt o contexto y pide al modelo que responda a partir de ellos.

Esto puede hacer que los sistemas de IA sean más útiles para políticas de empresa, documentación de productos, bases de conocimiento de soporte, notas de investigación y procedimientos internos. También puede reducir cierto riesgo de alucinación al fundamentar las respuestas en material proporcionado. No garantiza la corrección. El sistema puede recuperar un pasaje equivocado, omitir el documento correcto, usar contenido obsoleto, exponer datos que el usuario no debería ver o ser manipulado por instrucciones ocultas dentro de los documentos recuperados.

Muchas tareas útiles de inteligencia artificial dependen de información que no estaba en los datos de entrenamiento del modelo o que cambia con frecuencia. Un política de soporte cambia. Un manual escolar se actualiza. Un producto tiene un nuevo paso de configuración. Un modelo de contrato tiene excepciones locales. RAG ofrece a los desarrolladores una forma práctica de conectar un modelo con conocimientos seleccionados sin reentrenar el modelo cada vez.

El artículo original de RAG de Lewis y sus colegas combinó recuperación y generación para tareas NLP intensivas en conocimiento, mostrando la arquitectura como un patrón de investigación en lugar de una garantía de verdad [1]. La guía de proveedores de AWS es útil para elecciones prácticas de implementación, como opciones de recuperación y tradeoffs de arquitectura, pero debe tratarse como guía de implementación, no como la única autoridad neutral para el concepto [2].

Para organizaciones, RAG es atractivo porque la fuente de conocimiento puede gestionarse por separado del modelo. Un equipo puede actualizar documentos, eliminar páginas obsoletas, mejorar la fragmentación y cambiar permisos sin entrenar un nuevo modelo base. Eso hace que RAG sea práctico, pero también significa que la calidad de la respuesta depende del trabajo ordinario de gestión de información: documentos limpios, propiedad clara, políticas actualizadas y recuperación probada.

Un sistema RAG básico tiene tres partes. Primero está la recuperación. El sistema toma la pregunta del usuario y busca documentos o registros estructurados, a menudo usando búsqueda de palabras clave, incrustaciones vectoriales, filtros de metadatos, consultas estructuradas o una combinación de métodos. Segundo es la ampliación, a menudo mejor descrita como ensamblaje de contexto. El sistema agrega el material recuperado al prompt del modelo, generalmente con instrucciones sobre cómo usarlo. Tercero es la generación. El modelo de lenguaje escribe una respuesta usando la pregunta del usuario, las instrucciones y el contexto recuperado.

Una respuesta RAG puede incluir citas o etiquetas de fuentes, pero la procedencia solo es útil cuando es precisa. Una cita puede apuntar a un documento recuperado pero que no respalde la oración exacta. Un pasaje puede ser relevante para el tema pero no para la afirmación. Un modelo también puede mezclar texto recuperado con lenguaje no respaldado. Por eso, la verificación de fuentes sigue siendo parte del flujo de trabajo.

RAG también genera preguntas de seguridad y gobernanza. NIST trata a los sistemas de IA generativa como sistemas gestionados por riesgos a lo largo de su ciclo de vida, no como llamadas de modelo aisladas [3]. La lista de los 10 principales de OWASP para aplicaciones de LLM y IA generativa en 2025 destaca riesgos incluyendo divulgación de información sensible, agencia excesiva, debilidades en vectores y embellos, y desinformación [4]. Su guía sobre inyección de comandos también describe ataques indirectos donde instrucciones maliciosas se ocultan en contenido externo que un sistema de IA procesa [5]. Los documentos recuperados son un lugar donde ese riesgo puede aparecer.

Un constructor debe probar cada parte por separado. Las pruebas de recuperación preguntan si se encuentran los pasajes correctos. Las pruebas de fundamentación preguntan si la respuesta se mantiene dentro de esos pasajes. Las pruebas de citas preguntan si cada marcador de fuente respalda la oración junto a la cual aparece. Las pruebas de permisos preguntan si al usuario se le permitió recuperar el material en primer lugar. Las pruebas de todo el sistema preguntan si el sistema completo maneja preguntas reales de usuarios y casos de fallo.

Imagina un asistente de soporte al cliente para una empresa de software. Un cliente pregunta: "¿Puedo obtener un reembolso después de 45 días si el producto nunca se activó?" El sistema RAG convierte la pregunta en una búsqueda, recupera fragmentos de la política de reembolso y la guía de solución de problemas de activación, y agrega esas pasajes al contexto del modelo.

El modelo luego genera una respuesta: "La política dice que los reembolsos normalmente están disponibles dentro de 30 días, pero la activación fallida puede ser escalada para revisión. Pida al cliente el error de activación y el ID de pedido." Una buena interfaz mostraría los pasajes de la política utilizados para esa respuesta. Un trabajador de soporte humano aún debe verificar que la política recuperada esté actualizada, que la cuenta del cliente tenga la fecha de compra correcta y que la respuesta no exponga notas solo internas.

La mayor equivocación es que RAG hace desaparecer las alucinaciones. RAG puede reducir ciertos riesgos porque el modelo tiene contexto relevante para trabajar. También puede hacer que los fallos sean más fáciles de inspeccionar, ya que los usuarios pueden revisar los pasajes recuperados. Pero el sistema aún puede fallar antes de la generación, durante la generación o después de la generación.

Otra equivocación es pensar que un enlace de fuente significa que la respuesta está probada. La fuente recuperada debe respaldar realmente la afirmación. Si la respuesta dice "los reembolsos se permiten después de 45 días", pero la fuente dice "los reembolsos normalmente se permiten dentro de 30 días", la citación no es suficiente.

El fallo de recuperación es el primer gran riesgo. El sistema puede recuperar una página popular pero irrelevante, omitir una excepción rara o elegir un fragmento que carezca del contexto necesario. Documentos obsoletos o faltantes son otro riesgo. Una búsqueda perfecta sobre una política obsoleta aún produce una fundamentación obsoleta.

El control de acceso también es fundamental. Un sistema RAG no debe recuperar documentos de salario, registros de clientes, notas legales o procedimientos de seguridad internos para usuarios que no están autorizados a verlos. La inyección de comandos en documentos recuperados es un riesgo separado: un documento malicioso o comprometido puede contener instrucciones que intenten sobrescribir la tarea del sistema, revelar datos o cambiar la respuesta. RAG necesita higiene de documentos, permisos, monitoreo y revisión humana para usos de alto riesgo.

Otra limitación es la evaluación. Un demo puede parecer fuerte con unas pocas preguntas seleccionadas a mano, mientras que el sistema real falla en casos límite, sinónimos, documentos largos, políticas contradictorias o información faltante. Un sistema RAG útil necesita ejemplos de buenas respuestas, recuperaciones malas, casos sin respuesta, documentos obsoletos y límites de permisos. Los equipos también deben decidir cómo se comporta el producto cuando los resultados de recuperación son débiles, contradictorios o inexistentes: responder con incertidumbre, hacer una pregunta de seguimiento, derivar a una persona o rechazar responder por evidencia débil.

Antes de confiar en una respuesta de RAG, pregunta: ¿Se recuperaron los documentos correctos? ¿Están actualizados? ¿La respuesta está limitada a lo que respaldan las fuentes? ¿Están adjuntas las citas a las afirmaciones exactas que respaldan? ¿Podría algún documento recuperado contener instrucciones hostiles? ¿El usuario tiene permiso para ver cada fuente recuperada? ¿Qué debe hacerse si la recuperación no encuentra nada?

Para redacciones de baja importancia, una respuesta RAG puede ser un buen punto de partida. Para decisiones de política, seguridad, clientes, legales, financieras, médicas o de empleo, exija revisión de fuentes y un dueño de aprobación claro. RAG reduce algunos riesgos al acercar la evidencia al modelo, pero no reemplaza la verificación. Los buenos sistemas hacen visible la incertidumbre en lugar de ocultarla durante el uso real y la revisión.