Cómo se mide un RAG: las tres capas de métricas

Arranca el bloque 6 de la serie, dedicado a evaluación y calidad. Después de treinta y cinco entregas construyendo el sistema, toca la pregunta incómoda: cómo saber si funciona. Y sobre todo, cómo saber qué falla cuando no funciona.

El problema de la nota global

La forma habitual de evaluar un RAG en sus primeras semanas de vida es abrir la interfaz, escribir diez preguntas, leer las respuestas y decidir si «va bien». Es un método legítimo para detectar un desastre, y bastante inútil para todo lo demás.

El motivo es estructural. Un sistema RAG —recuperación aumentada por generación, la arquitectura que busca fragmentos en tu corpus y se los entrega a un modelo para que redacte con ellos— es una cadena de al menos dos etapas independientes. Cuando la respuesta final es mala, la causa puede estar en cualquiera de las dos, y los remedios no se parecen en nada.

Supón que un usuario pregunta por el plazo de devolución de un pedido internacional y el sistema responde con el plazo nacional. Hay dos historias posibles detrás de ese fallo. En la primera, la recuperación entregó al modelo cinco fragmentos que hablaban de devoluciones nacionales y ninguno del anexo internacional: el modelo hizo lo único que podía hacer con lo que tenía. En la segunda, el fragmento correcto estaba entre los recuperados, en la posición cuatro, y el modelo lo ignoró porque los tres primeros hablaban de lo otro con más insistencia.

La respuesta final es idéntica en ambos casos. El arreglo no lo es. En el primero hay que trabajar el troceado, los metadatos o la búsqueda híbrida; en el segundo, el prompt, el orden de los fragmentos o el modelo generador. Cambiar de modelo generador para arreglar un fallo de recuperación es una de las formas más caras de no arreglar nada, y se hace constantemente.

De ahí la idea que organiza todo este bloque: un RAG se mide por capas, y cada capa responde a una pregunta distinta.

Capa 1: recuperación

Pregunta que responde: ¿estaba el fragmento correcto entre los que se recuperaron?

Es la capa más ignorada y la que más determina el resultado, porque encarna el principio que atraviesa la serie entera: la calidad de la recuperación pone el techo a la calidad del sistema. Si el fragmento con la respuesta no llega al prompt, ningún modelo, ninguna plantilla y ningún parámetro de temperatura lo van a recuperar por telepatía.

Se mide comparando lo que el sistema devuelve con lo que debería haber devuelto, lo cual exige tener anotado, para un conjunto de preguntas, cuál es el fragmento o los fragmentos que contienen la respuesta. Eso es el golden dataset, y le dedicamos la entrega 40 entera porque es el paso que casi nadie da y el que hace posible todo lo demás.

Las métricas típicas son recall@k (qué proporción de los fragmentos relevantes aparece entre los k primeros), precision@k, MRR (a qué altura aparece el primer resultado bueno) y nDCG (cómo de bien ordenado está el ranking completo). La entrega 37 las define con fórmula y las calcula sobre un mismo ejemplo numérico.

Lo importante de esta capa es que se puede medir sin llamar al modelo generador. Es barata, es rápida, es determinista y se puede ejecutar sobre cientos de preguntas en segundos. Un cambio en el tamaño de chunk, en el modelo de embeddings o en la mezcla de búsqueda densa y BM25 se evalúa aquí, en un ciclo de minutos, antes de tocar nada más.

Capa 2: generación

Pregunta que responde: dado lo que se recuperó, ¿la respuesta se apoya en ello y contesta lo que se preguntaba?

Esta capa mide al modelo generador con el contexto dado por bueno. Es una distinción que conviene interiorizar: aquí no se juzga si el contexto era el adecuado, sino si el modelo se ha comportado bien con el contexto que recibió. Un sistema puede sacar una puntuación excelente en fidelidad y dar respuestas equivocadas todo el día, si lo que se le entrega es material equivocado. Fidelidad alta sobre contexto malo es exactamente eso: fidelidad al error.

Las métricas habituales son la fidelidad al contexto o faithfulness (qué proporción de las afirmaciones de la respuesta están respaldadas por los fragmentos), la relevancia de la respuesta (si contesta a la pregunta formulada y no a otra parecida) y la relevancia del contexto (qué proporción de lo recuperado se ha usado realmente, que es una métrica bisagra entre las dos capas). La entrega 38 explica cómo se calculan con un modelo actuando de juez, y por qué ese juez tiene sesgos que hay que conocer.

Es una capa cara. Cada evaluación implica una o varias llamadas adicionales a un modelo de lenguaje, con su latencia y su factura, y los resultados tienen varianza entre ejecuciones. No se ejecuta en cada commit sobre mil preguntas; se ejecuta sobre un subconjunto, con criterio.

Capa 3: extremo a extremo y negocio

Pregunta que responde: ¿resolvió la consulta del usuario?

Las dos capas anteriores pueden salir impecables y el sistema seguir siendo inútil. Un asistente que recupera bien, redacta con fidelidad y tarda dieciocho segundos en responder no se usa. Uno que responde correctamente pero se niega a contestar en cuatro de cada diez consultas por exceso de prudencia tampoco. Y uno que hace todo bien sobre preguntas que nadie formula ha optimizado el sistema equivocado.

Aquí caben cosas de naturaleza muy distinta: corrección de la respuesta final frente a una respuesta de referencia, tasa de abstención («no consta en la documentación» cuando sí constaba, y al revés), latencia en percentil 95, coste medio por consulta, tasa de escalado a un humano, tasa de reformulación (el usuario vuelve a preguntar lo mismo con otras palabras, que es la señal implícita de fracaso más honesta que existe), y las señales explícitas de pulgar arriba y pulgar abajo, con la reserva de que quien vota es una minoría poco representativa.

Esta capa es la única que le importa a quien paga el proyecto, y la única que no se puede optimizar directamente. Se mueve moviendo las otras dos.

Las tres capas en una tabla

Cómo se usa esto para diagnosticar

El valor práctico del esquema aparece cuando se leen las tres capas juntas, en este orden.

• Recuperación mala, generación irrelevante: el problema está aguas arriba. No toques el prompt. Mira el troceado, los metadatos y la estrategia de búsqueda.
• Recuperación buena, fidelidad baja: el fragmento correcto llegó y el modelo se lo saltó o lo adornó. Toca prompt, orden de fragmentos, cantidad de contexto o modelo.
• Recuperación buena, fidelidad alta, respuesta final mala: normalmente significa que el corpus no contiene la respuesta, o que la contiene de forma contradictoria en dos documentos. Es un problema de contenido, no de sistema, y ninguna técnica lo resuelve.
• Todo bien salvo la capa 3: mira latencia, abstenciones y la distribución real de las preguntas de tus usuarios frente a las de tu conjunto de evaluación.

Ese último punto merece énfasis: las tres capas se miden sobre un conjunto de preguntas, y si ese conjunto no se parece a lo que la gente pregunta de verdad, las tres capas mienten a la vez y de forma coordinada.

Límites de este esquema

Medir por capas tiene un coste real: exige anotación. Alguien tiene que decidir, para cada pregunta del conjunto de evaluación, cuál es el fragmento correcto. Ese trabajo no se puede automatizar del todo, y quien lo evita acaba con métricas sintéticas que miden la capacidad del sistema para recuperar preguntas generadas a partir de sus propios fragmentos, un ejercicio circular que siempre sale bien.

Segundo límite: la relevancia no es binaria en la mayoría de los casos reales. Un fragmento puede contener media respuesta, o el contexto necesario para entender otro. Las métricas de la capa 1 asumen una etiqueta y castigan la ambigüedad.

Tercero: las tres capas no son independientes de verdad. Aumentar k mejora el recall y suele empeorar la fidelidad, porque el modelo recibe más ruido. Optimizar una capa aislada sin mirar las otras dos es la forma clásica de mejorar un número y empeorar el producto.

Y cuarto: nada de esto sustituye a leer respuestas. Una revisión manual de veinte casos concretos cada semana detecta modos de fallo que ninguna métrica agregada muestra, porque las métricas agregadas están diseñadas para esconder la cola.

Qué viene ahora

La siguiente entrega baja a la capa de recuperación y la desmonta con fórmulas: recall@k, precision@k, MRR y nDCG calculadas paso a paso sobre un mismo conjunto de resultados, para ver exactamente en qué se diferencian y por qué dan puntuaciones tan distintas al mismo ranking. Después llegarán las métricas de generación, las herramientas que las automatizan y la construcción del golden dataset que hace posible todo el bloque.

Los tres libros gratuitos de los que nace esta serie están disponibles en PDF y EPUB: RAG para tu negocio (nivel básico), RAG por dentro (intermedio) y RAG en producción (avanzado).

Aviso de contenido generado con inteligencia artificial.
Este artículo ha sido redactado con la asistencia de sistemas de inteligencia artificial y revisado antes de su publicación. Se informa de ello de forma expresa en cumplimiento de la normativa vigente sobre transparencia en el uso de IA.