Cómo probar un sistema RAG antes de que tu equipo confíe en él
Una demo de RAG responde las preguntas que se les ocurrieron a quienes la construyeron. Cómo probar la recuperación y las respuestas por separado, verificar las citas automáticamente y acordar el umbral de aprobación por adelantado, para que tu equipo pueda confiar en lo que dice.
Un sistema RAG que se ve bien en una demo respondió las preguntas que se les ocurrieron a quienes lo construyeron. Tu equipo va a hacer otras, y va a dejar de usarlo la primera vez que responda con total seguridad desde el documento equivocado. La confianza se gana antes del lanzamiento, con una prueba que puedas correr una y otra vez.
Si lideras el equipo: qué preguntar
- ¿Se probó con preguntas reales de nuestra gente, con respuestas revisadas por alguien que conoce el tema?
- ¿Qué cuenta como suficientemente bueno, y lo acordamos antes de probar?
- Cuando cambia el prompt, el modelo o los documentos, ¿se vuelve a correr la prueba completa?
Empieza con preguntas reales y respuestas conocidas
Reúne las preguntas que tu gente hace de verdad: de los tickets de soporte, del chat interno y de los expertos que hoy las responden. Para cada una, anota la respuesta correcta y los documentos de origen que la contienen. Incluye casos difíciles a propósito:
- respuestas repartidas entre dos documentos;
- preguntas que dependen de un número de referencia o un nombre exacto;
- temas en los que dos documentos se contradicen;
- preguntas que la base de conocimiento no puede responder, donde lo correcto es decir “no sé”.
Pide que alguien que conoce el tema apruebe las respuestas. Ese conjunto es tu respuesta conocida, y vale más que cualquier benchmark genérico porque está hecho de tus preguntas y tus documentos.
Mide la recuperación y las respuestas por separado
Cuando una respuesta está mal, necesitas saber cuál de las dos mitades falló.
- Recuperación: para cada pregunta, ¿el sistema trajo los documentos de origen que anotaste, y en qué posición? Si la recuperación falla, ningún prompt va a arreglar la respuesta.
- Respuesta: con lo que se recuperó, ¿la respuesta es correcta, está fundamentada (cada afirmación respaldada por los pasajes recuperados) y tiene citas? Una respuesta correcta que no está respaldada por sus fuentes es un accidente, y no se va a repetir.
Medir las dos cosas por separado te dice dónde trabajar: en el chunking y la búsqueda, o en el prompt y el modelo.
Verifica las citas automáticamente
Cada pasaje citado debería existir, pertenecer a un documento que el usuario tiene permiso de ver y contener de verdad la afirmación a la que va pegado. Lo primero y lo segundo son verificaciones simples en código. Lo tercero se puede revisar comparando el texto citado con la fuente, o con un segundo modelo, y con una persona revisando muestras del resultado. Corre estas verificaciones en cada respuesta del conjunto de prueba. Una cita que no apunta a nada es un defecto, no un detalle de estilo.
Corre el conjunto completo en cada cambio
Un prompt nuevo, una versión nueva del modelo, un índice con otro chunking o un lote nuevo de documentos pueden mejorar algunas respuestas y romper otras sin que nadie lo note. Corre el conjunto completo como prueba de regresión en cada uno de esos cambios, y compáralo con la última corrida aceptada. Mira lo que empeoró, no solo el promedio. Guarda el historial de corridas, para saber cuándo empezó a fallar una pregunta y qué cambió ese día.
Revisa muestras de respuestas reales
Las verificaciones automáticas detectan lo que pensaste revisar. Cuando el sistema ya está en uso, pide que alguien que conoce el tema revise con regularidad una muestra de respuestas reales, con sus fuentes. Cada error que encuentre se convierte en una pregunta nueva del conjunto de prueba, para que la misma falla no pueda volver sin que nadie la vea.
Acuerda el umbral antes de probar
Decide con las personas que van a depender del sistema qué significa “suficientemente bueno”, y déjalo por escrito antes de la primera corrida: con qué frecuencia la recuperación tiene que encontrar la fuente correcta, con qué frecuencia las respuestas tienen que ser correctas y citadas, y qué preguntas no se pueden responder mal nunca, como todo lo que toque dinero, salud o plazos legales. Fijar el umbral después de ver los resultados convierte una prueba en una negociación.
La misma disciplina en un producto que construimos
En el producto de coaching de ventas con IA que construimos, cada calificación muestra la evidencia citada de la llamada, para que un gerente la pueda verificar en segundos. Las salidas son estructuradas y se validan antes de guardarse, y un calificador basado en reglas corre junto a la IA como referencia determinista. Cuando probamos las métricas del producto contra una respuesta conocida, la prueba detectó errores antes de que algún gerente dependiera de ellas. Ese es el hábito que hay que llevar a RAG: evidencia en cada salida, y una respuesta conocida contra la cual verificarla.
Lista para probar un sistema RAG
- Preguntas reales, con respuestas aprobadas por un experto y sus documentos de origen
- Casos difíciles, incluidas preguntas sin respuesta
- Recuperación medida por separado de las respuestas
- Respuestas revisadas por exactitud, fundamento y citas
- Verificación automática de citas en cada respuesta
- Una regresión completa en cada cambio de prompt, modelo o índice
- Revisión humana regular de respuestas reales, que alimenta el conjunto de prueba
- Un umbral acordado por escrito antes de probar
Probar así es parte de cómo trabajamos la IA con tus datos.
Este artículo se basa en un proyecto real. Datos del cliente reservados; cada cifra proviene de los datos del propio cliente.
Leer el caso de estudio completo →