Pruebas de calidad en RAG: métricas y métodos

Qué cubre este artículo sobre pruebas de calidad en RAG

• Aprenderás por qué las pruebas de calidad son imprescindibles para sistemas RAG y qué sucede si las omites
• Comprenderás las métricas clave como Recall, Precision, Faithfulness y Answer Relevance a través de ejemplos concretos
• Descubrirás cómo funciona el framework RAGAS y cómo utilizarlo para evaluar tu sistema
• Obtendrás una guía paso a paso para crear y ejecutar tu propio conjunto de pruebas
• Identificarás los obstáculos típicos y cómo evitarlos

Introducción: pruebas de calidad en RAG explicadas de forma clara

Has construido un sistema RAG, quizás con Ollama y una base de datos vectorial local. A primera vista, todo funciona. Haces una pregunta, obtienes una respuesta que parece plausible. Pero ¿qué tan bueno es realmente el sistema? ¿Con qué frecuencia hay respuestas incorrectas? ¿Los errores provienen de la búsqueda de los fragmentos correctos o de la generación de la respuesta?

Aquí es donde entran en juego las pruebas de calidad. En este artículo te explicaré cómo medir y mejorar sistemáticamente la calidad de tu sistema RAG. Examinaremos tanto las métricas como la implementación práctica. Si aún no tienes claro qué es RAG, conviene que leas primero el artículo sobre fundamentos de RAG.

¿Por qué necesito pruebas de calidad?

Imagina que operas un sistema RAG para el soporte interno de tu empresa. Los empleados hacen preguntas sobre solicitudes de vacaciones, políticas de gastos y problemas de TI. El sistema responde correctamente el 80 por ciento de las preguntas. El 20 por ciento restante tiene respuestas incorrectas o incompletas.

Sin pruebas sistemáticas, no sabes cuál es ese 20 por ciento. Un empleado pregunta cuánto tiempo antes debe solicitar vacaciones y recibe la respuesta “tres semanas antes del inicio”. Suena plausible, pero la respuesta correcta es “cuatro semanas”. Nadie se queja porque la respuesta está bien formulada. El error se descubre solo cuando alguien presenta una solicitud demasiado tarde y es rechazada.

Las pruebas de calidad resuelven este problema. Te muestran dónde tiene debilidades tu sistema antes de que cause problemas en producción. Identificas patrones en los errores y puedes derivar mejoras específicas, como expandir el conocimiento en un área determinada u optimizar el reranking.

Pruebas de calidad en RAG explicadas brevemente

Imagina un estudiante preparándose para un examen. Podría simplemente afirmar que está listo. O practica con exámenes anteriores y cuenta cuántas preguntas responde correctamente. Solo así sabe si realmente está preparado.

Así funciona una prueba de calidad para RAG. Tomas una colección de preguntas cuya respuesta correcta conoces, las sometes a tu sistema y comparas la salida con la respuesta esperada. Del resultado del comparación, calculas métricas que te indican qué tan bien funciona el sistema. Un único número no es suficiente porque RAG consta de varios pasos. La búsqueda puede ser buena y la generación mala, o viceversa. Por eso mides ambos pasos por separado.

¿Para quién están diseñadas las pruebas de calidad?

Las pruebas de calidad se dirigen a varios grupos:

• Desarrolladores que construyen un sistema RAG y quieren saber si su configuración funciona bien
• Operadores de sistemas pequeños y medianos que no pueden permitirse equipos de evaluación caros, pero aun así quieren asegurar que su sistema funciona de manera confiable
• Equipos que migran de una solución basada en API a IA local y quieren comparar la calidad
• Principiantes que construyen un sistema RAG por primera vez y quieren entender cómo reconocer la calidad

No necesitas un doctorado en estadística. Las ideas fundamentales son simples, y las herramientas como RAGAS te ahorran mucho trabajo.

Términos importantes en torno a la calidad de RAG

Término	Significado
Recall	Proporción de fragmentos de texto relevantes que encontró el sistema. Un Recall alto significa que encuentra casi todo lo importante.
Precision	Proporción de fragmentos encontrados que son realmente relevantes. Una Precision alta significa poco contenido innecesario.
F1	Combinación de Recall y Precision en un solo valor. Útil cuando necesitas un número para comparar.
Faithfulness	Mide si la respuesta solo contiene afirmaciones que están respaldadas por las fuentes encontradas. Sin alucinaciones.
Answer Relevance	Mide si la respuesta realmente contesta la pregunta formulada, no solo algo relevante.
Context Precision	Evalúa si los fragmentos encontrados son útiles para la respuesta.
Context Recall	Evalúa si se encontró toda la información necesaria de las fuentes.
RAGAS	Framework para evaluación automática de sistemas RAG que calcula múltiples métricas.
Ground Truth	La respuesta de referencia establecida como correcta contra la que pruebas el sistema.
Evaluation Set	Una colección de preguntas de prueba con respuestas de referencia y fuentes esperadas asociadas.

Por qué es difícil medir la calidad de RAG

RAG consta de dos pasos principales: Retrieval y Generación. Cada paso puede ser bueno o malo, y la combinación hace que la evaluación sea compleja. Un sistema puede encontrar los fragmentos de texto perfectos y aun así generar una respuesta incorrecta. O encuentra fuentes mediocres pero formula una respuesta útil a partir de ellas.

Además, la calidad es subjetiva. Lo que cuenta como “buena respuesta” depende del contexto. Una respuesta concisa puede ser ideal para una consulta rápida, pero es insuficiente para una pregunta compleja. Las métricas solo pueden capturar parcialmente esta subjetividad.

Otro problema es distinguir entre alucinación y retrieval incorrecto. Si la respuesta es falsa, ¿se debe a que el modelo inventa algo o a que se encontraron los fragmentos de texto equivocados? Sin medir ambos pasos por separado, quedas a oscuras. Por eso se utilizan múltiples métricas simultáneamente, cada una iluminando aspectos diferentes.

Métricas de Retrieval

La fase de Retrieval es el primer paso: el sistema busca en la base de datos vectorial fragmentos de texto que coincidan con la pregunta. Dos métricas son centrales aquí.

Recall: ¿Encontramos los fragmentos correctos?

Recall mide cuántos de los fragmentos de texto relevantes encontró el sistema. Supongamos que en tu base de datos hay cinco fragmentos importantes para una pregunta. El sistema encuentra tres. El Recall es del 60 por ciento.

Un Recall alto es importante porque la generación solo puede basarse en lo que se encontró. Si falta un fragmento crítico, el modelo no puede usarlo y la respuesta será incompleta o incorrecta.

Precision: ¿Son relevantes los fragmentos encontrados?

Precision mide cuántos de los fragmentos encontrados son realmente relevantes. El sistema encuentra diez fragmentos, pero solo cuatro son importantes para la pregunta. La Precision es del 40 por ciento.

Una Precision baja significa que el modelo debe trabajar con muchos fragmentos irrelevantes. Esto puede deteriorar la respuesta porque el modelo se confunde o pierde el enfoque. También cuesta poder computacional y tiempo porque se procesan innecesariamente muchos fragmentos.

Métodos como Hybrid Search y Reranking ayudan a mejorar la Precision sin reducir el Recall. Hybrid Search combina búsqueda semántica y basada en palabras clave, mientras que Reranking reordena los fragmentos encontrados según su relevancia.

Métricas de Generación

Una vez que el modelo de lenguaje ha recuperado los fragmentos de texto, genera la respuesta a partir de ellos. Aquí también hay dos métricas clave que debes considerar.

Faithfulness: ¿La respuesta es coherente con las fuentes?

Faithfulness mide si todas las afirmaciones en la respuesta están respaldadas por las fuentes encontradas. Si la respuesta afirma que el plazo para solicitudes de vacaciones es de tres semanas, pero las fuentes indican cuatro semanas, entonces la respuesta no es faithful. El modelo ha malinterpretado algo o ha añadido información inexacta.

Una faithfulness baja es una señal de alarma sobre alucinaciones. El modelo inventa hechos que no aparecen en las fuentes. Esto es particularmente peligroso porque las respuestas suelen sonar convincentes. Las citas de fuentes en la salida ayudan a transparentar este problema para los usuarios, pero no lo resuelven.

Answer Relevance: ¿La respuesta contesta la pregunta?

Answer Relevance mide si la respuesta realmente aborda la pregunta formulada. Una respuesta puede ser completamente faithful y aun así no responder a la cuestión planteada. Si alguien pregunta “¿Cuál es el plazo de rescisión?” y la respuesta explica detalladamente el proceso de terminación de un contrato pero no menciona ningún plazo específico, entonces la respuesta no es relevante.

Medir Answer Relevance es más difícil que Faithfulness porque la “relevancia” es más subjetiva. RAGAS utiliza un enfoque en el que se generan nuevas preguntas a partir de la respuesta y luego se mide qué tan similares son esas preguntas generadas a la pregunta original. Una buena respuesta debería permitir reconstruir la pregunta inicial.

Framework RAGAS

RAGAS (Retrieval Augmented Generation Assessment) es un framework de código abierto que automatiza la evaluación de sistemas RAG. Calcula las cuatro métricas más importantes en una única ejecución:

• Faithfulness: ¿Están todas las afirmaciones en la respuesta respaldadas por el contexto?
• Answer Relevance: ¿Contesta la respuesta la pregunta?
• Context Precision: ¿Son útiles los fragmentos de texto encontrados para la respuesta?
• Context Recall: ¿Se encontraron todas las informaciones necesarias?

Cómo funciona RAGAS

RAGAS utiliza un modelo de lenguaje como evaluador. Le proporcionas la pregunta, los fragmentos de texto encontrados, la respuesta generada y opcionalmente la respuesta de referencia. El modelo evaluador analiza estas entradas y produce puntuaciones para cada métrica, típicamente entre 0 y 1. RAGAS en sí mismo necesita un modelo de lenguaje. Con IA local, puedes usar un modelo local como evaluador, por ejemplo a través de Ollama. Esto requiere capacidad de procesamiento, pero mantiene todos tus datos en tu sistema.

Implementar RAGAS

El uso típico funciona así: creas un conjunto de evaluación, es decir, una lista de preguntas con respuestas de referencia. Para cada pregunta, ejecutas tu sistema RAG y guardas los fragmentos de texto encontrados y la respuesta generada. Proporcionas estos datos a RAGAS, que calcula las métricas. Al final, obtienes un informe con valores promedio e individuales por pregunta.

RAGAS está disponible en Python y se puede integrar en pipelines existentes. Para sistemas más pequeños, es suficiente ejecutar la evaluación manualmente. Para sistemas más grandes, automatizas el proceso y lo ejecutas regularmente, por ejemplo después de cada actualización del corpus de conocimiento.

Crear un conjunto de prueba

Un buen conjunto de prueba es la base de toda evaluación. Sin preguntas de prueba significativas, no medirás nada útil. Aquí están los pasos para crear un conjunto de prueba.

Paso 1: Recopilar preguntas

Recopila entre 20 y 50 preguntas que sean típicas del uso de tu sistema. Utiliza diferentes fuentes: preguntas reales de usuarios si tienes registros, tus propias preguntas de prueba, preguntas de diferentes áreas temáticas y una mezcla de preguntas simples y complejas. Asegúrate de que las preguntas cubran el espectro completo, no solo los casos más simples.

Paso 2: Escribir respuestas de referencia

Para cada pregunta, escribes la mejor respuesta posible basándote en tu conocimiento de las fuentes. Esta respuesta de referencia no necesita estar palabra por palabra en el corpus de conocimiento, pero debe ser correcta y completa. Esta referencia es tu verdad fundamental.

Paso 3: Anotar las fuentes esperadas

Para cada pregunta, anotas qué fragmentos de texto del corpus de conocimiento deberían ser relevantes. Esto ayuda más tarde a evaluar el retrieval. Si el sistema encuentra otros fragmentos, puedes identificar si la búsqueda necesita mejoras.

Paso 4: Incluir casos límite

Incluye deliberadamente preguntas difíciles: preguntas cuya respuesta debe combinarse a partir de múltiples fragmentos, preguntas con términos ambiguos, preguntas para las que no hay respuesta en el corpus de conocimiento. Especialmente los casos sin respuesta son importantes, porque el sistema idealmente debería decir “No tengo información sobre esto” en lugar de inventar algo.

Ejemplo: Evaluar un sistema RAG

Aquí hay un flujo concreto para evaluar con RAGAS.

Preparación

Has construido tu sistema RAG con RAG Local. Tu conjunto de prueba contiene 30 preguntas con respuestas de referencia y fuentes esperadas. RAGAS está instalado y has configurado un modelo evaluador local a través de Ollama.

Ejecución

Para cada pregunta en tu conjunto de prueba, formulas la pregunta a tu sistema RAG, guardas los fragmentos de texto encontrados (Context) y la respuesta generada (Answer), y anotas la respuesta de referencia (Ground Truth). Recopilas estos datos en una tabla o archivo JSON.

Evaluación con RAGAS

Proporcionas los datos recopilados a RAGAS. El framework calcula las cuatro métricas para cada pregunta y te proporciona valores promedio. Un resultado típico podría verse así:

• Faithfulness: 0,82
• Answer Relevance: 0,75
• Context Precision: 0,68
• Context Recall: 0,71

Interpretación

Los números muestran que el retrieval tiene debilidades. Context Precision y Context Recall son relativamente bajos. El sistema no siempre encuentra los mejores fragmentos de texto. Faithfulness es más alto, lo que significa que el modelo generalmente interpreta correctamente los fragmentos encontrados. Answer Relevance está en el medio, lo que sugiere que algunas respuestas no responden óptimamente a la pregunta, posiblemente porque las fuentes no eran ideales.

La conclusión: deberías trabajar primero en mejorar el retrieval, por ejemplo mediante reranking o búsqueda híbrida, antes de ajustar la generación.

Pruebas manuales

No todos necesitan un framework como RAGAS de inmediato. Las pruebas manuales son un buen punto de partida y a menudo más reveladoras de lo esperado.

Procedimiento

1. Toma 20 preguntas de tu conjunto de prueba
2. Formúla cada pregunta a tu sistema RAG
3. Compara la respuesta con tu respuesta de referencia
4. Anota: correcta, parcialmente correcta o incorrecta
5. Para respuestas incorrectas: anota la causa (fuentes incorrectas, generación incorrecta, pregunta no comprendida)

Evaluación

Después de 20 preguntas, tienes una estadística simple. Quizás 14 correctas, 4 parcialmente correctas, 2 incorrectas. Más importante que el porcentaje es el análisis de errores. Examina las respuestas incorrectas y parcialmente correctas. ¿Hay patrones? Tal vez todas las respuestas incorrectas fallan en preguntas sobre un tema específico, lo que indica una brecha en el corpus de conocimiento. O tal vez los fragmentos de texto encontrados eran correctos, pero la respuesta estaba mal formulada, lo que sugiere un problema en la generación.

Las pruebas manuales consumen tiempo, pero te dan una intuición sobre el sistema que ninguna métrica puede reemplazar. Para una evaluación inicial, son completamente suficientes.

Escollos frecuentes en pruebas de calidad

Las pruebas de calidad conllevan varios riesgos que pueden distorsionar tus resultados.

Conjuntos de prueba demasiado pequeños: Con cinco preguntas no obtienes valores significativos. Un solo valor atípico altera el resultado dramáticamente. Utiliza al menos 20, mejor 50 preguntas.

Preguntas poco realistas: Si todas tus preguntas de prueba son sencillas, el sistema parecerá mejor de lo que es. Incluye preguntas difíciles y ambiguas que realmente desafíen al sistema.

Falta de casos extremos: Las preguntas sin respuesta en la base de conocimientos se olvidan fácilmente. El sistema debe reconocer cuando no tiene información, en lugar de alucinar. Pruébalo explícitamente.

Respuestas de referencia obsoletas: Cuando tu base de conocimientos cambia, las respuestas de referencia pueden quedarse obsoletas. Actualiza el conjunto de pruebas regularmente, especialmente después de actualizaciones importantes.

Modelo evaluador demasiado débil: Si usas RAGAS con un modelo local pequeño como evaluador, las puntuaciones pueden ser poco confiables. Prueba con diferentes modelos evaluadores y compara resultados.

Sobreajuste a métricas: Optimizar el sistema solo para mejorar los números puede perjudicar la calidad real. Las métricas son herramientas, no el objetivo final. Siempre incluye también muestreos manuales.

Pruebas puntuales: Una única prueba tras la implementación no es suficiente. Cualquier cambio en el sistema, en la base de conocimientos o en los parámetros puede afectar la calidad. Realiza pruebas regularmente, idealmente después de cada cambio relevante.

Hardware, costos y seguridad en pruebas de calidad

Las pruebas de calidad consumen recursos, especialmente si usas RAGAS con un modelo evaluador local. Cada pregunta en el conjunto de pruebas requiere múltiples llamadas al modelo evaluador, porque RAGAS ejecuta análisis separados para cada métrica. Con 50 preguntas y cuatro métricas llegas a 200 llamadas al modelo por evaluación.

Para el hardware significa: necesitas suficiente RAM y VRAM para que el modelo evaluador funcione sin problemas. Un modelo con 7 a 8 mil millones de parámetros, como Llama 3 8B, es un buen equilibrio entre calidad y consumo de recursos. Funciona en un sistema con 16 GB de RAM, aunque no particularmente rápido. Para velocidad cómoda se recomiendan 32 GB de RAM y una GPU dedicada.

Los costos se mantienen controlados con ejecución local porque no hay gastos de API. Solo pagas por electricidad y hardware. Con APIs en la nube, los costos pueden acumularse rápidamente con pruebas regulares y conjuntos de pruebas más grandes.

En términos de seguridad, la ejecución local es una ventaja. Tus preguntas de prueba, respuestas de referencia y fragmentos encontrados permanecen en tu sistema. Esto es importante cuando la base de conocimientos contiene datos sensibles de la empresa.

Enlaces e información adicional sobre pruebas de calidad

• La documentación oficial de RAGAS ofrece explicaciones detalladas de todas las métricas y ejemplos de integración
• En el artículo sobre Reranking aprenderás cómo mejorar la precisión de tu búsqueda
• Hybrid Search combina dos métodos de búsqueda para mejores resultados
• Cuando actualizas la base de conocimientos, el artículo sobre Actualizar la base de conocimientos te será de ayuda
• Encontrarás los fundamentos de IA local en el artículo ¿Qué es la IA local?

FAQ: Probar la calidad de RAG - Preguntas frecuentes

¿Cuántas preguntas debería contener mi conjunto de pruebas? Para una evaluación inicial, 20 preguntas son suficientes. Para métricas significativas se recomiendan 50 o más. Cuantas más, más confiables son los valores, pero también mayor el esfuerzo.

¿Necesito RAGAS o las pruebas manuales son suficientes? Para comenzar, las pruebas manuales son completamente adecuadas. Te dan una idea del sistema. RAGAS vale la pena si quieres comparar sistemáticamente, por ejemplo antes y después de un cambio, o si gestionas sistemas más grandes.

¿Qué modelo debo usar como evaluador en RAGAS? Un modelo con 7 a 8 mil millones de parámetros es un buen inicio. Los modelos más pequeños pueden evaluar de manera poco confiable. Si la calidad te importa más que la velocidad, usa un modelo más grande.

¿Con qué frecuencia debo realizar pruebas? Al menos después de cada cambio relevante, es decir, después de actualizar la base de conocimientos, cambios de parámetros o cambio del modelo de lenguaje. Con desarrollo activo, vale la pena hacer una prueba después de cada sprint.

¿Qué hago si las métricas son buenas pero las respuestas se ven mal? Es una señal de sobreajuste. Las métricas miden ciertos aspectos pero no todo. Usa muestreos manuales y examina respuestas directamente. No confíes ciegamente en los números.

¿Puedo usar RAGAS sin respuestas de referencia? RAGAS puede calcular algunas métricas sin respuestas de referencia, como Faithfulness y Answer Relevance. Para Context Recall necesitas respuestas de referencia. Sin ellas la validez es limitada.

¿Cómo distingo errores de búsqueda de errores de generación? Examina los fragmentos encontrados. Si las fuentes correctas se encontraron pero la respuesta es incorrecta, el problema está en la generación. Si se encontraron fuentes incorrectas, está en la búsqueda. RAGAS lo separa mediante Context Precision y Context Recall respecto a Faithfulness.

¿Cuál es un buen valor de Faithfulness? Valores superiores a 0,8 son sólidos, superiores a 0,9 muy buenos. Debajo de 0,7 debes mejorar urgentemente porque el modelo inventa demasiado. Ten en cuenta que el valor depende del modelo evaluador y puede variar ligeramente entre ejecuciones.

¿Ayudan las citas en la calidad? Las citas hacen que las respuestas sean más trazables para los usuarios y ayudan en la verificación manual. No mejoran directamente las métricas, pero hacen los errores más visibles.

¿Cuánto cuesta una prueba de calidad con RAGAS en hardware local? Solo electricidad y tiempo. Con 50 preguntas usando un modelo 8B en una GPU promedio, una ejecución toma aproximadamente 15 a 30 minutos. Sin GPU puede durar mucho más.

¿Puedo automatizar las pruebas? Sí, RAGAS se puede integrar en scripts Python. Puedes ejecutar automáticamente la evaluación después de cada actualización de la base de conocimientos y registrar los resultados. De esta forma detectas tendencias a lo largo del tiempo.

Fuentes y lecturas adicionales

• Documentación de RAGAS y repositorio GitHub
• Es, S., James, J., Espinosa-Anke, L., Schockaert, S. (2023): “RAGAS: Automated Evaluation of Retrieval Augmented Generation”
• Lewis, P. et al. (2020): “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks”
• Más artículos en BotServ.de sobre RAG local