Cómo validar un sistema RAG: Guía práctica para Product Managers

A medida que los sistemas de Inteligencia Artificial reconfiguran nuestra forma de interactuar con la información, la Generación Mejorada por Recuperación (RAG) se perfila como una potente arquitectura que combina el conocimiento interno con modelos de lenguaje generativos. Pero las grandes capacidades vienen acompañadas de un reto crítico: ¿cómo sabemos si un sistema RAG funciona?

Este artículo describe un enfoque estructurado y realista para validar un sistema RAG, basado en nuestra experiencia en la creación y el mantenimiento de COGNOS, un producto impulsado por RAG en Apiumhub.

¿Qué es un sistema RAG?

Un sistema RAG combina un motor de recuperación de información (por ejemplo, una base de datos de búsqueda o vectorial) con un modelo generativo de gran lenguaje (LLM), lo que le permite responder a preguntas basadas tanto en datos propios como en conocimientos generales externos.

¿Por qué es difícil la validación RAG?

A diferencia de los sistemas tradicionales basados en reglas, los sistemas RAG no son deterministas. Las respuestas dependen de:

• El modelo que utiliza
• Los documentos recuperados
• El enunciado de la pregunta de entrada

En nuestro caso con COGNOS, el reto es aún mayor: los usuarios cargan sus archivos o conectan fuentes de conocimiento privadas. No podemos acceder al contenido real utilizado en el momento de la inferencia. A pesar de ello, debemos garantizar un nivel mínimo de fiabilidad.

¿Se puede automatizar la validación?

Sí, herramientas como MLflow, RAGAS, UpTrain, Opik o marcos personalizados que utilizan LangChain pueden ayudar a automatizar el proceso. Sin embargo, antes de automatizar, hay que saber qué validar y por qué.

Este post se centra en la base manual que debe establecer antes de la automatización.

Flujo de validación de un sistema RAG

Dividamos este proceso en dos grandes etapas. La primera, la preparación, es la base de toda la validación. Hay que preparar datos de muestra, pero también las preguntas que se quieren hacer y las respuestas que se esperan.

1. Preparación de los datos

Empieza por reunir muestras realistas de documentos: políticas, facturas, requisitos, CV, etc. Evite en lo posible los ejemplos sintéticos.

Una característica que hace clave la privacidad de COGNOS es que garantiza que no se compartirá ningún dato con terceros durante el proceso de validación.

Ejemplo: Un documento de política de empresa que regule los permisos retribuidos, el trabajo a distancia o las revisiones de los empleados: documentos reales con un lenguaje técnico y denso.

2. Diseño de la pregunta

Para cada documento o conjunto de documentos:

• Empieza con preguntas sencillas y ve aumentando la complejidad.
• Define las condiciones previas (por ejemplo, «Requiere política_empresa.pdf»).
• Especifica el contexto previsto del que debe partir el modelo.

Sugerencias:

• Parafrasea preguntas para comprobar la comprensión semántica.
• Incluye prompts multilingües si el sistema admite varios idiomas.
• Añade casos de prueba negativos (por ejemplo, preguntas que no deben responderse).
• Refleja las preocupaciones reales de los usuarios y define las preguntas por persona si el sistema desempeña múltiples funciones.

Ejemplo:

• Pregunta: ¿A cuántos días de vacaciones tengo derecho?
• Documento requerido: «politica_empresa.pdf»
• Contexto esperado: «Cada trabajador tiene derecho a disfrutar de hasta 23 días de vacaciones».

3. Ejecución de la prueba

Una vez que el conjunto de datos y el conjunto de preguntas estén listos, ejecute las consultas. Aunque este paso puede automatizarse, la clave está en obtener registros completos de entrada-salida para su validación.

Criterios de evaluación RAG

Relevancia del contexto

Antes de juzgar el resultado, confirma que el contexto recuperado es correcto. ¿Ha localizado el sistema la parte pertinente del documento?

Herramientas como COGNOS proporcionan una «vista de origen» para que pueda inspeccionar lo que se recuperó antes de que el modelo generara una respuesta.

Valida que el contenido recuperado coincide con la sección esperada. Esto ayuda a aislar los fallos en la recuperación de los errores de generación.

Precisión de la respuesta

Una vez verificado el contexto, evalua la calidad de la respuesta generada utilizando las siguientes categorías:

1. Exacto / Inexacto: ¿Es la respuesta objetivamente correcta?
2. Completo / Incompleto: ¿Incluye toda la información crítica?

Generado / Fallido: ¿Generó el modelo una respuesta coherente, o pasó por defecto a una respuesta alternativa o falló silenciosamente?

Ejemplo:

• Documento: «Todos los empleados recibirán cuentas de Microsoft 365 excepto el personal de almacén».
• Pregunta: «¿Todos los empleados tienen cuentas de Microsoft 365?».
• Respuesta: «Sí, todos lo hacen». → Incorrecto por omisión.

Buenas prácticas

• Iterar con frecuencia: Los sistemas RAG evolucionan, por lo que también deberían hacerlo sus pruebas de validación.
• Aprende de las consultas de usuarios reales: te guiarán hacia casos de validación del mundo real.
• Supervisa el rendimiento en producción para detectar regresiones y casos extremos.

Conclusión

Validar un sistema RAG no es trivial. Requiere un profundo conocimiento de todo el proceso, desde la recuperación y la gestión del contexto hasta la generación de la respuesta final. Pero con un proceso de validación estructurado, los jefes de producto pueden confiar en la fiabilidad del comportamiento de su sistema, incluso en entornos complejos y dinámicos.