Cuando una empresa conecta un asistente de inteligencia artificial a su documentación, surge un problema práctico: el modelo puede escribir con soltura, pero no conoce necesariamente el último contrato, la versión vigente del manual o el procedimiento actualizado de atención al cliente. La generación aumentada mediante recuperación, conocida como RAG, intenta resolver esa separación entre lenguaje y conocimiento disponible.
Su propuesta es sencilla de formular y más compleja de implementar correctamente: buscar primero información pertinente en fuentes controladas y utilizarla después como contexto de la respuesta. El resultado puede ser más preciso y comprobable que una contestación basada únicamente en los conocimientos previos del modelo. Sin embargo, una respuesta con citas no es automáticamente verdadera.
Qué significa RAG y cómo funciona realmente
RAG combina recuperación de información con generación de texto. Primero un sistema recibe una pregunta, localiza documentos potencialmente relacionados y recupera fragmentos. Después presenta los extractos al modelo, que redacta una explicación utilizando ese material como referencia. La arquitectura puede apoyarse en búsqueda por palabras clave, vectores semánticos, métodos híbridos o filtros de metadatos.
Google Cloud describe ese flujo en su explicación oficial sobre generación aumentada mediante recuperación. El beneficio esperado no nace de añadir más texto indiscriminadamente, sino de recuperar los datos apropiados y conectarlos correctamente con la respuesta.
Primera fase: preparar una base documental confiable
Antes de hablar de modelos o bases de datos vectoriales conviene revisar la materia prima: documentos duplicados, procedimientos desactualizados, archivos inaccesibles y páginas con versiones contradictorias. Si dos manuales proporcionan cifras diferentes, el asistente necesita saber cuál tiene prioridad y por qué.
Una estrategia útil consiste en conservar metadatos mínimos: título, fecha de edición, fuente, responsable, versión, ámbito de aplicación y permisos de acceso. Esta información permite filtrar resultados y detectar cuándo se ha recuperado una versión antigua o un documento destinado a otro departamento.
Segunda fase: dividir los documentos sin perder el contexto
Las bases RAG suelen fragmentar los textos en unidades recuperables. No existe un tamaño universal que sirva para todos los casos. Un fragmento excesivamente corto puede separar una excepción de la regla a la que afecta; uno enorme puede introducir ruido y empeorar la recuperación.
En textos jurídicos, por ejemplo, es importante preservar los apartados y referencias cruzadas. En manuales técnicos suele ayudar mantener juntos una instrucción, sus condiciones previas y sus advertencias. Los encabezados y la estructura del documento no son un adorno: influyen en la calidad de lo que después se encuentra.
Tercera fase: buscar por significado y por términos exactos
Las búsquedas semánticas son capaces de relacionar expresiones similares aunque utilicen palabras diferentes. Eso resulta útil cuando el usuario pregunta «¿cómo doy de baja el servicio?» y el manual habla de «cancelación de suscripción».
Pero los términos exactos también importan. Un número de factura, un nombre de producto, un código de error o una cláusula identificada no siempre se localizan mejor mediante similitud. Por eso los sistemas híbridos que combinan búsqueda textual y semántica pueden ser especialmente prácticos.
La búsqueda debe respetar además los permisos del usuario. Una buena clasificación no justifica recuperar documentos privados de otro equipo. El control de acceso debe aplicarse durante la recuperación, no confiarse únicamente a una petición posterior al modelo para que oculte lo que no debía haber leído.
Cuarta fase: exigir respuestas vinculadas a pruebas
Un asistente puede incluir enlaces y aun así afirmar algo que no aparece en ellos. La mera presencia de una cita no demuestra que la fuente respalde la frase. Conviene exigir que las respuestas identifiquen las referencias concretas y que reconozcan cuándo un dato no está disponible.
En su documentación oficial, Google Cloud presenta una función para comprobar el apoyo factual de una respuesta frente a un conjunto de referencias. Ese análisis ayuda a detectar afirmaciones poco sustentadas, aunque tampoco sustituye la comprobación humana en decisiones de alto impacto.
Ejemplo práctico: un agente que responde preguntas sobre cursos
Imagina un catálogo con veinte formaciones de inteligencia artificial. Cada ficha tiene temario, precio, condiciones de acceso, actualizaciones, nivel recomendado y enlace comercial. Un usuario pregunta qué curso le conviene para aprender automatizaciones sin programar.
Un sistema RAG responsable no debería elegir el producto con mayor comisión por defecto. Primero recuperaría fichas pertinentes, distinguiría formación introductoria de avanzada, comprobaría qué condiciones son públicas y, solo entonces, prepararía una recomendación con sus límites. Si una ficha no especifica la duración del soporte, la respuesta debería decirlo en lugar de inventarla.
Como ejemplos de contenido que puede analizarse con ese criterio están nuestra reseña de Domina n8n desde Cero y el análisis de una formación para automatizar con n8n en local. Ambos artículos describen productos concretos y se deben consultar respetando sus condiciones actuales; no son bases de datos oficiales de los vendedores.
Ejemplo práctico: buscar información dentro del blog
Un blog especializado puede utilizar sus artículos para ayudar a encontrar respuestas. El visitante pregunta qué ha cambiado en los permisos de los agentes. La recuperación debería localizar contenidos de seguridad y automatización, filtrar artículos por pertinencia y presentar enlaces reales, no URLs inventadas.
El historial editorial también importa: si una entrada de actualidad quedó superada por un anuncio más reciente, no debería presentarse como la única referencia. Es necesario distinguir información histórica, normativa vigente, resultados experimentales y opiniones.
Para entender los riesgos de mezclar fuentes y órdenes se puede consultar nuestro artículo sobre inyección de instrucciones en agentes. También es relevante la explicación sobre modelos de embeddings y búsqueda multimodal en dispositivos, porque recuperar documentos requiere representar y comparar contenidos de una forma útil.
Cinco errores habituales en un proyecto RAG
1. Alimentarlo con información sin revisar
Una colección desordenada puede devolver documentos obsoletos o contradictorios. Conviene establecer reglas de revisión, caducidad y prioridad entre fuentes.
2. Suponer que más fragmentos significan mejores respuestas
Introducir grandes cantidades de texto poco relevante diluye la información importante. La selección y el orden de los resultados afectan a la calidad final.
3. Evaluar solo si la respuesta parece convincente
La fluidez no demuestra exactitud. Deben comprobarse las fuentes recuperadas, la correspondencia entre afirmación y evidencia y los casos en que el sistema debería abstenerse.
4. Mezclar documentos privados y públicos sin controles
Los permisos no pueden basarse en que el modelo recuerde ocultar determinada información. La restricción debe aplicarse antes de entregar los datos a la fase de generación.
5. Olvidarse de los cambios
Las preguntas, los productos y los procedimientos evolucionan. Sin un proceso para actualizar o retirar documentos, la base termina generando respuestas coherentes pero desfasadas.
Cómo medir si RAG aporta valor
Las pruebas deberían separar al menos tres resultados: calidad de la recuperación, apoyo factual de la respuesta y utilidad para completar la tarea. Un sistema puede recuperar el documento correcto y redactar mal la conclusión; también puede responder bien a una pregunta habitual porque acertó por casualidad sin recuperar nada útil.
Es aconsejable construir una pequeña colección de preguntas reales con respuestas comprobables y casos ambiguos. Por ejemplo: «¿qué condiciones incluye el plan?», «¿cuándo se actualizó?», «¿qué ocurre si el documento no menciona reembolso?» o «¿puedo ver un contrato de otra cuenta?». Cada pregunta debe tener criterios de éxito y fracaso.
Además de la precisión, conviene observar el tiempo de respuesta, el coste de las consultas, el mantenimiento documental y la proporción de ocasiones en que un humano debe corregir la información. Un proyecto RAG puede tener sentido para una base de conocimiento estable y ser innecesario para una web pequeña cuyas páginas ya se encuentran fácilmente mediante un buscador convencional.
¿Es mejor RAG que entrenar de nuevo un modelo?
No se trata exactamente del mismo objetivo. RAG proporciona información recuperada durante la consulta; un ajuste fino modifica patrones de comportamiento del modelo a partir de entrenamiento adicional. La recuperación suele ser más conveniente cuando los datos cambian con frecuencia, se necesita trazabilidad de fuentes o hay documentación privada que no debe incorporarse indiscriminadamente al entrenamiento.
El ajuste fino puede ayudar en tareas de formato, estilo o clasificación, pero no garantiza conocimiento actualizado ni elimina la necesidad de controlar la calidad de los datos. Ambos enfoques pueden coexistir cuando existe una justificación concreta.
Conclusión: recuperar bien vale más que responder con seguridad
RAG es una pieza útil para conectar modelos de lenguaje con información reciente, especializada o interna. Su éxito depende menos de las siglas que de cuatro decisiones: qué documentos se permiten, cómo se buscan, qué pruebas se presentan y cómo se evalúa la respuesta.
Antes de invertir en infraestructura compleja, lo más razonable es probar una versión pequeña con fuentes bien preparadas. Si el sistema recupera datos correctos, reconoce sus límites y ayuda al usuario a verificar lo que recibe, entonces puede ser una mejora real. Si solo añade citas decorativas a respuestas poco fiables, no ha resuelto el problema.
Fuentes primarias: documentación de Google Cloud sobre RAG y comprobación de apoyo factual. Texto educativo; las posibilidades técnicas dependen de los proveedores y de la arquitectura elegida.