Gramax muestra cómo comparar la calidad de las respuestas de RAG sin evaluarlas «a ojo»

Gramax ha descrito una transición práctica de la evaluación subjetiva de los sistemas RAG a una comparación reproducible de respuestas. El equipo propone no fijarse en lo bien que lucen las métricas de recuperación, sino en si el usuario obtiene de la base de conocimientos una respuesta precisa, completa y comprensible.

El motivo para revisar el enfoque fue un problema típico de casi cualquier búsqueda RAG sobre documentación o una base de conocimientos interna. Aunque el sistema encuentre bien los chunks relevantes, eso no garantiza una buena respuesta final. El usuario no ve DCG, Recall@10, reranking ni otros indicadores internos. Solo ve el texto final. Ahí es donde afloran los principales fallos: el modelo puede ignorar parte del contexto encontrado, responder en un idioma equivocado, añadir detalles no confirmados o producir un texto seguro de sí mismo pero difícil de leer.

En Gramax señalan que ya habían trabajado antes en mejorar la capa de recuperación: ajustaron el esquema de chunking, añadieron metadatos, combinaron distintos tipos de búsqueda y usaron reordenación de resultados. Este conjunto de técnicas sí aumenta la probabilidad de extraer los fragmentos necesarios de la base de conocimientos. Pero cuando la búsqueda se estabiliza surge la siguiente pregunta: ¿cómo saber que toda la cadena funciona para el usuario final y no solo para el ingeniero que mira un panel técnico? En la práctica, esta brecha entre la calidad de la búsqueda y la de la respuesta suele generar un falso optimismo en el desarrollo de RAG.

La idea clave del artículo es que la evaluación debe estar ligada al escenario del usuario. Cuando alguien hace una pregunta sobre documentación, no le interesa una lista de chunks bien extraídos, sino una respuesta concreta: si contiene el dato necesario, si se ha perdido algún matiz importante, si hay alucinaciones, si se respeta el idioma de la consulta y si se puede confiar en la formulación.

Este cambio de enfoque obliga a construir la verificación de calidad de otra manera. En lugar de evaluar «a ojo», el equipo propone fijar un conjunto de criterios y comparar modelos y configuraciones con la misma muestra de preguntas. Esto es especialmente importante cuando las diferencias entre variantes no son evidentes y la impresión subjetiva de un par de ejemplos acertados puede distorsionar fácilmente el panorama.

Una conclusión práctica aparte se refiere a la comparación de modelos. En su material, Gramax subraya que para tareas de RAG no basta con apoyarse en benchmarks generales ni en la reputación del modelo en el mercado. Un mismo modelo puede ser fuerte generando texto y más débil en la disciplina de responder según el contexto encontrado. Por eso hay que comparar en un planteamiento aplicado: con preguntas propias, sobre la propia base de conocimientos y con reglas de verificación claras. Así se puede ver qué modelo retiene mejor los hechos, no se va por las ramas, trabaja correctamente con el idioma y responde de forma estable a consultas del mismo tipo.

Para el mercado es una señal importante. Los proyectos RAG se implantan cada vez más en soporte, manuales internos, bases de reglamentos y documentación de producto, donde un error en la respuesta cuesta más que una caída en una métrica abstracta de búsqueda. El enfoque que describe Gramax traslada de hecho la conversación sobre calidad del plano de la ingeniería al del producto: un buen sistema no es el que luce bien en un informe de recuperación, sino el que entrega de forma estable una respuesta útil y verificable a la persona.

Cuanto antes empiecen los equipos a medir precisamente esta capa, antes dejarán de confundir el contexto encontrado con una tarea del usuario realmente resuelta. Esto significa que la siguiente etapa del desarrollo de los sistemas RAG estará ligada no solo a mejorar la búsqueda, sino también a normalizar la evaluación de la respuesta como un producto independiente. Para los equipos que ya han configurado chunking, búsqueda híbrida y reranking, esta metodología puede convertirse en la principal vía para entender qué combinación de modelos y prompts funciona de verdad en producción.