Métricas de generación: fidelidad, relevancia y groundedness

Tercera entrega del bloque de evaluación. Medida la recuperación con fórmulas cerradas, toca la parte incómoda: juzgar texto. No hay aritmética que diga si una respuesta se apoya en su contexto, así que la industria ha acabado usando otro modelo de lenguaje como juez. Funciona mejor de lo que cabría esperar y peor de lo que se admite.

Las tres métricas que importan

La capa de generación —según el esquema de tres capas de la entrega 36— da por bueno el contexto recuperado y pregunta qué ha hecho el modelo con él. Tres métricas cubren casi todo el terreno, y conviene separarlas bien porque miden cosas distintas y fallan por motivos distintos.

Fidelidad al contexto (faithfulness)

Mide qué proporción de las afirmaciones contenidas en la respuesta están respaldadas por los fragmentos recuperados. Es la métrica que detecta la alucinación en un RAG: no si la respuesta es cierta en el mundo, sino si es derivable de lo que se le dio al modelo.

La distinción es fina y crucial. Una respuesta puede ser factualmente correcta y tener fidelidad cero, porque el modelo la sacó de su conocimiento paramétrico en lugar de leerla en el contexto. Eso, en un sistema con trazabilidad, es un fallo: significa que la próxima vez, cuando el conocimiento paramétrico esté desactualizado, inventará con la misma seguridad y nadie lo notará.

Relevancia de la respuesta (answer relevancy)

Mide si la respuesta contesta a la pregunta formulada. Es la métrica que caza las respuestas evasivas, las que responden a una pregunta parecida, las que se van por las ramas y las que contestan bien pero enterrando la respuesta en tres párrafos de contexto que nadie pidió.

Una implementación habitual, y bastante elegante, es indirecta: se pide al juez que genere varias preguntas a las que la respuesta serviría de contestación y se mide la similitud semántica entre esas preguntas generadas y la pregunta original. Si la respuesta es evasiva o desviada, las preguntas retro-generadas se parecerán poco a la real.

Relevancia del contexto (context relevancy)

Mide qué proporción de los fragmentos recuperados —o de las frases dentro de ellos— era realmente necesaria para responder. Es la métrica bisagra entre las dos capas: puntuaciones bajas aquí indican que estás gastando presupuesto de tokens y atención del modelo en ruido, aunque el fragmento bueno esté dentro.

Sirve además para ajustar k con criterio. Si la relevancia del contexto se desploma al pasar de 5 a 10 fragmentos y la fidelidad no mejora, el k grande sólo está encareciendo la consulta.

Cómo se calcula la fidelidad: descomposición en afirmaciones

El procedimiento estándar tiene dos pasos, y la clave está en no pedirle al juez una nota global sino una serie de decisiones pequeñas y verificables.

Paso 1: descomponer. Se pide a un modelo que parta la respuesta en afirmaciones atómicas: proposiciones simples, autocontenidas, cada una verificable por separado. «El plazo de devolución internacional es de 30 días naturales desde la entrega, y el coste del envío de vuelta corre a cargo del cliente salvo en productos defectuosos» se convierte en tres afirmaciones:

• El plazo de devolución internacional es de 30 días naturales.
• El plazo se cuenta desde la entrega.
• El coste del envío de vuelta corre a cargo del cliente, salvo si el producto es defectuoso.

Paso 2: verificar una a una. Para cada afirmación se pregunta al juez si el contexto la respalda, con tres salidas posibles: respaldada, contradicha o no mencionada. La fidelidad es el cociente entre afirmaciones respaldadas y afirmaciones totales.

fidelidad = afirmaciones respaldadas / afirmaciones totales

Ejemplo: 5 de 6 afirmaciones respaldadas → 0,83

Descomponer antes de juzgar mejora mucho la estabilidad del resultado, por dos motivos. Primero, porque una decisión binaria sobre una proposición corta es una tarea mucho más fácil que puntuar de 1 a 5 un párrafo entero. Segundo, porque el resultado es auditable: cuando la fidelidad sale 0,67 sabes exactamente qué dos afirmaciones fallaron, y puedes leerlas. Una nota global de 3 sobre 5 no te dice nada accionable.

Un prompt de evaluación de ejemplo

Este es el esqueleto del verificador del paso 2. La forma importa: rol acotado, categorías explícitas, prohibición de usar conocimiento externo, salida estructurada y justificación obligatoria antes del veredicto.

Eres un verificador de afirmaciones. Tu única fuente de verdad es el
CONTEXTO que aparece abajo. No uses conocimiento externo, aunque sepas
que una afirmación es cierta en el mundo real.

Para cada AFIRMACIÓN, decide una de estas tres etiquetas:
- RESPALDADA: el contexto afirma esto, explícitamente o por
  consecuencia directa e inmediata.
- CONTRADICHA: el contexto afirma lo contrario.
- NO_MENCIONADA: el contexto no dice nada al respecto.

Reglas:
- Una afirmación parcialmente respaldada es NO_MENCIONADA, no RESPALDADA.
- No penalices el estilo, la longitud ni el tono. Sólo el respaldo.
- Cita el fragmento exacto del contexto en el que te apoyas. Si no
  puedes citarlo literalmente, la etiqueta no puede ser RESPALDADA.
- Escribe primero la justificación y después la etiqueta.

CONTEXTO:
{fragmentos_recuperados}

AFIRMACIONES:
{lista_numerada_de_afirmaciones}

Devuelve JSON, un objeto por afirmación:
[{"id": 1, "cita": "...", "justificacion": "...", "etiqueta": "..."}]

Tres detalles que no son decorativos. La obligación de citar literalmente es el mecanismo antialucinación del propio juez: si no encuentra la frase, no puede marcar respaldada. El orden justificación-antes-de-etiqueta aprovecha que el modelo razona al escribir; invertirlo degrada notablemente la calidad de la decisión. Y la instrucción explícita de ignorar estilo y longitud ataca de frente el sesgo más documentado de estos jueces.

Lo que cuesta

Evaluar así no es gratis y conviene tener el orden de magnitud claro antes de montarlo en integración continua.

Cada consulta evaluada implica, como mínimo: una llamada para descomponer la respuesta en afirmaciones, una llamada de verificación (o una por afirmación, según implementación) y, si mides también relevancia de la respuesta y del contexto, dos o tres llamadas más. Es decir, entre cuatro y diez llamadas al modelo por cada consulta que quieras evaluar, con el contexto completo en el prompt de varias de ellas.

Dicho de otro modo: evaluar una consulta cuesta bastante más que responderla, típicamente varias veces más en tokens de entrada. Un conjunto de doscientas preguntas evaluado en las tres métricas es un trabajo de minutos y de una factura no trivial, y ejecutarlo en cada commit es una decisión económica, no técnica. Las estrategias razonables: un subconjunto pequeño (veinte o treinta preguntas) en cada cambio y el conjunto completo antes de cada despliegue; o el conjunto completo por la noche, en un trabajo programado.

Varianza: el número que cambia sin que cambies nada

Un juez basado en modelo de lenguaje no es determinista, y dos ejecuciones sobre exactamente los mismos datos dan cifras distintas. Con temperatura cero se reduce, pero no desaparece del todo.

La consecuencia práctica es que una diferencia pequeña entre dos versiones del sistema puede ser ruido del juez. Antes de celebrar una mejora, mide su magnitud contra la variación del propio juez: ejecuta la evaluación dos o tres veces sobre la misma versión sin cambiar nada y mira cuánto se mueve el resultado. Esa es tu resolución mínima. Todo lo que quede por debajo no es una mejora, es una fluctuación.

Mitigaciones que funcionan: temperatura 0, prompt fijo y versionado junto al código, modelo juez fijado por versión exacta (una actualización silenciosa del modelo rompe la comparabilidad de toda tu serie histórica), y agregación por votación en las decisiones dudosas, que multiplica el coste pero estabiliza mucho.

Los sesgos del juez

Un modelo actuando de juez arrastra distorsiones sistemáticas, y son sistemáticas justamente porque no se cancelan al promediar sobre muchas consultas.

Hay una mitigación transversal que vale más que todas las anteriores: calibrar el juez contra anotación humana. Se toman cincuenta casos, se etiquetan a mano, se pasa el juez por encima y se mide el grado de acuerdo. Si el acuerdo es pobre, el juez no está midiendo lo que crees y ninguna cifra que produzca significa nada. Esta calibración hay que repetirla cuando cambies de modelo juez o toques el prompt de evaluación, y es el trabajo humano que ninguna herramienta elimina.

Límites y contraindicaciones

La fidelidad alta no implica respuesta correcta. Si el contexto recuperado es erróneo, una fidelidad de 1,00 certifica que el modelo ha reproducido fielmente un error. Por eso esta capa sólo se lee junto a la de recuperación, nunca sola.

La descomposición en afirmaciones funciona mal con texto que no es factual: razonamientos condicionales, recomendaciones, matices legales, respuestas que dependen del caso. «Podría aplicarse el plazo ampliado si el pedido se realizó durante campaña» no es una proposición verificable en términos binarios, y el juez la etiquetará de forma inconsistente.

El juez tampoco sabe evaluar lo que falta. Una respuesta que omite la excepción importante puede tener fidelidad perfecta y relevancia alta, porque todo lo que dice es cierto y pertinente. La omisión es un modo de fallo grave en dominios normativos y estas métricas son estructuralmente ciegas a él; sólo la comparación con una respuesta de referencia anotada lo detecta.

Y una advertencia de método: no optimices contra el juez. En cuanto una métrica se convierte en objetivo, se degrada como medida. Un prompt de generación afinado hasta subir la fidelidad del 0,84 al 0,93 puede haber aprendido, simplemente, a producir respuestas cortas y literales que el verificador aprueba con facilidad, sin que el usuario esté mejor servido.

Qué viene ahora

La siguiente entrega pasa de las métricas a las herramientas que las implementan: Ragas como biblioteca de métricas, ARES con jueces entrenados y estimación estadística, y LangSmith como plataforma de trazas y evaluación continua. Qué automatiza cada una, cómo se enganchan a un flujo de integración continua y qué parte del trabajo sigue exigiendo, inevitablemente, a una persona leyendo respuestas.

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.