RAG y recuperación de información empresarial

Qué es RAG y qué problema resuelve

La generación aumentada por recuperación, o RAG, es una arquitectura que incorpora evidencia recuperada a la entrada de un modelo generativo. Ante una pregunta, el sistema busca fragmentos pertinentes en un corpus, construye un contexto y solicita una respuesta al modelo. El enfoque permite trabajar con documentación más reciente o específica que el conocimiento incorporado durante el entrenamiento.

El artículo original de Lewis y colaboradores separa una memoria paramétrica —el conocimiento aprendido por el modelo— de una memoria no paramétrica recuperable. En una empresa, esa segunda memoria puede representar políticas, manuales, catálogos o procedimientos. La separación es útil porque el corpus puede actualizarse sin volver a entrenar el modelo completo.

RAG no es una base de datos conversacional infalible. El recuperador puede omitir la fuente correcta, el fragmento puede carecer de contexto y el modelo puede interpretar mal la evidencia. Su ventaja es hacer posible una respuesta apoyada en información identificable; su obligación es conservar permisos, procedencia y una forma de evaluar el resultado.

Del documento a la respuesta

1. Ingesta. Se seleccionan fuentes autorizadas, se extrae su contenido y se conserva procedencia, versión y dueño.
2. Fragmentación. El contenido se divide en unidades que puedan recuperarse sin perder su significado.
3. Representación. Cada fragmento puede convertirse en un embedding, una representación numérica útil para comparar similitud.
4. Recuperación. La consulta se compara con el índice y se eligen candidatos mediante búsqueda semántica, textual o híbrida.
5. Construcción de contexto. El sistema aplica filtros, ordena fragmentos y los incorpora a una instrucción dentro del límite de tokens.
6. Generación y presentación. El modelo redacta; la aplicación muestra fuentes, límites y acciones permitidas.

Cada etapa introduce decisiones. Un índice excelente no compensa documentos incorrectos; un buen modelo no compensa permisos ignorados. La arquitectura debe registrar qué versión del corpus, consulta, filtros, fragmentos y modelo participaron para investigar fallas sin almacenar información innecesaria.

El corpus es un producto gobernado

Un corpus útil no es una carpeta con todos los archivos disponibles. Cada fuente necesita propósito, responsable, audiencia, estado, fecha de revisión y reglas de exclusión. Se eliminan duplicados, borradores superados y contenido sin autoridad clara. Cuando dos documentos se contradicen, el sistema necesita una regla editorial; la similitud por sí sola no decide cuál gobierna.

La fragmentación debe respetar estructura. Cortar sólo por número de caracteres puede separar una condición de su excepción o una tabla de su encabezado. Títulos, secciones, listas y metadatos ayudan a formar unidades autosuficientes. Fragmentos demasiado pequeños pierden contexto; demasiado grandes reducen precisión y consumen la ventana disponible.

Permisos antes de similitud

El recuperador debe aplicar autorización antes de exponer fragmentos al modelo. Que un usuario pueda formular una pregunta no implica que pueda consultar toda fuente relacionada. Los filtros se derivan de identidad, rol, pertenencia, clasificación o reglas del repositorio; no de una instrucción en lenguaje natural.

También se separan credenciales y responsabilidades. El proceso de ingesta requiere lectura de fuentes; la aplicación de consulta quizá sólo necesite leer el índice; una acción posterior necesita un permiso distinto. Conceder a todos los componentes una credencial amplia convierte una falla de búsqueda o una inyección de instrucciones en un problema de acceso.

Los documentos pueden contener texto que intente cambiar el comportamiento del sistema. Se tratan como datos no confiables, no como instrucciones privilegiadas. La aplicación limita herramientas, valida parámetros y solicita confirmación cuando una respuesta podría producir un cambio material.

Cómo evaluar recuperación y respuesta

La evaluación separa recuperación de generación. Para recuperación se prepara un conjunto de preguntas y fuentes esperadas; se mide si un fragmento pertinente aparece entre los primeros resultados y si aparecen fragmentos irrelevantes. Para generación se revisan fidelidad a la evidencia, cobertura, utilidad, citas y conducta cuando el corpus no contiene respuesta.

También se prueban permisos: usuarios distintos deben recibir conjuntos distintos cuando corresponde. Se incluyen documentos obsoletos, preguntas ambiguas, términos internos, instrucciones hostiles y consultas fuera de alcance. Una respuesta honesta que declara falta de evidencia puede ser mejor que una frase convincente sin respaldo.

La evaluación no termina al publicar. Cambios de corpus, fragmentación, embeddings, modelo o instrucciones pueden modificar el resultado. Versionar la configuración y conservar un conjunto de regresión permite comparar antes de promover cambios.

Límites y alternativas

RAG no es necesario cuando una consulta estructurada, una regla o un filtro exacto resuelven el problema. Para obtener el saldo de una factura, SQL o una API autorizada ofrecen una respuesta determinista; un modelo puede ayudar a explicar el resultado, pero no debería inventarlo. Tampoco sustituye gestión documental: si nadie mantiene la política, recuperarla con rapidez sólo acelera la difusión de contenido vencido.

El costo incluye preparación, indexación, almacenamiento, consultas, observabilidad y revisión. La latencia aumenta porque existen varias etapas. Además, los proveedores y modelos cambian. La decisión debe partir de preguntas reales, fuentes disponibles, riesgo y una métrica de utilidad, no de la expectativa de que conectar documentos produzca automáticamente conocimiento.

Ruta de implementación controlada

1. Definir alcance. Precisar audiencia, preguntas, fuentes permitidas y decisiones excluidas.
2. Gobernar el corpus. Asignar dueño, estado, revisión y reglas de baja.
3. Construir una línea base. Probar búsqueda textual y respuestas sin generación antes de añadir complejidad.
4. Aplicar autorización. Filtrar antes de recuperar y volver a validar antes de ejecutar cualquier acción.
5. Evaluar por componentes. Medir recuperación, fidelidad, utilidad, seguridad y abstención.
6. Operar con trazabilidad. Supervisar fallas, costos, cambios y calidad con responsables definidos.

Una prueba pequeña con evidencia y criterios de salida ofrece más aprendizaje que indexar todo el repositorio. RAG es una arquitectura de información y control, no una función que se activa con un botón.