Evaluar un sistema con LLM sin depender solo de otro LLM como juez

Con 100 casos de prueba y un 80% de aciertos, el intervalo de confianza del 95% va aproximadamente del 72% al 88%. Si cambias el prompt y pasas al 83%, no sabes si mejoraste. La mayoría de las decisiones de «este prompt es mejor» se toman sobre diferencias que están dentro del ruido, y con un juez LLM sin calibrar como única métrica, encima de un ruido que nadie midió.

Primero, lo que se puede comprobar sin modelo

Antes de pedirle a un LLM que juzgue, revisa cuánto de la calidad se puede verificar con código. Es gratis, determinista y no discute.

• Formato: ¿el JSON es válido y cumple el esquema? ¿la respuesta tiene menos de N palabras?
• Contenido obligatorio o prohibido: ¿menciona el número de pedido? ¿incluye datos personales que no debería?
• Extracción y clasificación: si tienes la respuesta correcta, compara campo a campo (coincidencia exacta, o precisión y recall por campo).
• Código generado: ¿compila? ¿pasan los tests?
• RAG: ¿el fragmento correcto estaba entre los recuperados? Eso es recall@k y no necesita juez.

En muchos sistemas, estas comprobaciones cubren más de la mitad de los fallos reales. Lo que queda (si la respuesta es útil, correcta en el fondo, con el tono adecuado) es lo que justifica un juez.

Cómo escribir un juez que sirva

Una escala del 1 al 10 para «calidad general» produce números que parecen precisos y no significan nada estable. Funcionan mejor los criterios binarios, uno por pregunta, cada uno con definición explícita.

Evalúa la RESPUESTA a la PREGUNTA usando solo el CONTEXTO proporcionado.

Responde en JSON con estos campos, cada uno true o false:
- "fiel_al_contexto": todas las afirmaciones factuales de la respuesta
  aparecen en el contexto o se deducen directamente de él.
- "responde_la_pregunta": la respuesta aborda lo que se preguntó,
  no un tema relacionado.
- "admite_falta_de_datos": si el contexto no contiene la respuesta,
  la respuesta lo dice en lugar de inventar. Si el contexto sí la contiene, true.

Antes de los campos, incluye "justificacion" con una o dos frases.

PREGUNTA: {pregunta}
CONTEXTO: {contexto}
RESPUESTA: {respuesta}

Pedir la justificación antes del veredicto mejora la consistencia y, sobre todo, te permite leer por qué el juez decidió algo cuando no estás de acuerdo.

Calibra el juez contra personas

Un juez LLM es un clasificador más, y como cualquier clasificador hay que medir cuánto acierta. Toma entre 50 y 100 casos, haz que una persona que conozca el dominio los etiquete con los mismos criterios, y compara.

def acuerdo(etiquetas_humanas, etiquetas_juez):
    pares = list(zip(etiquetas_humanas, etiquetas_juez))
    coincidencias = sum(h == j for h, j in pares)
    falsos_aprobados = sum(h is False and j is True for h, j in pares)
    falsos_rechazos = sum(h is True and j is False for h, j in pares)
    return {
  "acuerdo": coincidencias / len(pares),
  "falsos_aprobados": falsos_aprobados,
  "falsos_rechazos": falsos_rechazos,
    }

No te quedes con el porcentaje de acuerdo. Mira los falsos aprobados: casos que la persona marcó como incorrectos y el juez dio por buenos. Si tu criterio es «fiel al contexto» y el juez aprueba respuestas con datos inventados, el juez es inútil justo para lo que lo querías. Lee esos casos, ajusta la definición del criterio y vuelve a medir.

Si el acuerdo entre dos personas en un criterio ya es bajo, el criterio está mal definido. Arregla la definición antes de pedirle a un modelo que la aplique.

Sesgos conocidos de los jueces LLM

En comparaciones de dos respuestas, los jueces tienden a favorecer una posición (la primera o la segunda, según el modelo). La corrección es simple: evalúa cada par dos veces con el orden invertido y cuenta como victoria solo si gana en ambos órdenes; si cada orden da un ganador distinto, es empate.

También tienden a preferir respuestas más largas y más formateadas aunque no sean más correctas, y pueden favorecer textos generados por su propia familia de modelos. Los criterios binarios específicos reducen estos efectos frente a una nota global, y usar como juez un modelo distinto del que genera las respuestas evita el segundo.

Cuánto ruido tiene tu medición

Para una tasa de acierto p medida sobre n casos, el intervalo aproximado del 95% es p ± 1,96 × √(p(1 − p) / n).

Cuando comparas dos versiones sobre los mismos casos, mira además los casos que cambian: cuántos pasaron de fallo a acierto y cuántos al revés. Si son 6 y 4, el saldo de +2 no dice nada. Si son 15 y 1, sí.

Y la variación del propio sistema: con temperatura mayor que cero, ejecutar el mismo conjunto dos veces da resultados distintos. Ejecuta cada versión al menos dos veces antes de comparar, o fija la temperatura a cero durante la evaluación si tu caso de uso lo permite.

Errores frecuentes y limitaciones

Construir el conjunto de evaluación con casos inventados por el equipo. Los usuarios reales escriben con faltas, mezclan dos preguntas en una y preguntan cosas que nadie anticipó. Toma la mayoría de los casos de registros reales y actualízalos cada cierto tiempo.

Optimizar contra el juez. Si iteras el prompt hasta maximizar la nota del juez sin revisar ejemplos, acabarás explotando sus sesgos (respuestas más largas, más listas) en lugar de mejorar. Cada cierto número de iteraciones, lee 20 respuestas a mano.

No guardar los resultados por caso. Una cifra agregada por versión no permite saber qué se rompió. Guarda entrada, salida, veredicto y justificación de cada caso para poder comparar versiones línea a línea.

El juez también cuesta. Evaluar 500 casos con tres criterios es otra carga de llamadas a un modelo en cada cambio. Ejecuta primero las comprobaciones deterministas y llama al juez solo para los casos que las superan.

Configuración mínima

Un archivo con 100 casos reales, un script que aplique las comprobaciones deterministas, un juez con tres criterios binarios calibrado contra 50 etiquetas humanas, y una tabla que compare cada versión con la anterior caso por caso. Ejecútalo en cada cambio de prompt, de modelo o de recuperación antes de desplegar.