LLM como juez: cómo calibrarlo antes de aprobar un cambio

Un LLM —un modelo de lenguaje— puede ayudar a revisar miles de respuestas, pero antes hay que comprobar que aplica el criterio que necesitas. Un juez que premia una respuesta amable y acepta una condición inventada puede hacer que un cambio parezca mejor cuando en realidad es peor.

Esta guía propone un protocolo de calibración; no hemos ejecutado un modelo ni medido acuerdo humano en este artículo. Partimos de los riesgos descritos en MT-Bench y del enfoque de evaluación orientado al dominio de Hamel Husain. Si estás empezando, consulta primero cómo evaluar un agente.

Caso hipotético

Consideremos un asistente de devoluciones, cuya política ficticia establece que las devoluciones son permitidas durante 14 días, salvo en el caso de productos personalizados. Un ejemplo de respuesta equivocada podría ser la siguiente: “Claro, le podemos devolver el producto personalizado dentro de los 14 días”. Aunque la respuesta es amable, incumple la política al prometer precisamente una devolución excluida. El estilo no debe compensar un incumplimiento.

Rúbrica binaria

La rúbrica propuesta consta de tres criterios:

No inventar condiciones: La respuesta no debe incluir condiciones que no estén definidas en la política.
No omitir exclusión relevante: Cuando la consulta afecta a un producto personalizado, debe aplicar esa exclusión; no es necesario enumerar restricciones irrelevantes en cada respuesta.
Ofrecer siguiente paso permitido: Debe indicar una acción válida según la política, como solicitar la fecha de recepción cuando falte; cualquier excepción deberá estar documentada, no inventada.

Este JSON es una salida hipotética diseñada para ilustrar el formato, no el resultado de una llamada a un modelo:

{
  "approved": false,
  "failed_checks": ["exclusion_personalizados"],
  "evidence": "La respuesta menciona devolución de un producto personalizado dentro de los 14 días."
}

Protocolo de piloto

Se propone un piloto con 80 casos ficticios, divididos en 40 para desarrollo y 40 reservados. Estos casos son de tamaño ilustrativo, no se recomienda un umbral universal. Dos personas con conocimiento de la política etiquetarían los casos por separado y resolverían las discrepancias antes de fijar la referencia. Reservaríamos los mismos casos para comparar versiones, sin usarlos para ajustar la rúbrica. Si una política cambia, habrá que revisar sus etiquetas: un conjunto antiguo puede dejar de representar lo correcto.

El dataset sintético puede ser útil, pero debe completarse con casos reales autorizados y anonimizados. Se calcula la aprobación incorrecta entre respuestas que los humanos rechazan y los rechazos incorrectos entre respuestas aprobables, contando las abstenciones por separado. No se considera solo el acuerdo global.

Imagina 100 casos hipotéticos: el juez acierta los 90 sencillos y aprueba incorrectamente los 10 que incumplen una exclusión. Su acuerdo global sería del 90%, aunque fallaría en todos los casos peligrosos. Por eso interesa contar los errores por tipo y mirar ejemplos concretos. Estas cifras ilustran el problema; no son resultados de Puntoes.

También probaríamos respuestas correctas cortas frente a errores largos, repetición de una misma entrada y, si se comparan dos respuestas, intercambio de su orden. El estudio MT-Bench analiza esos sesgos; no permite asumir que nuestro juez los tendrá con la misma intensidad.

Versionado

Guarda la versión exacta del modelo, instrucciones del juez, rúbrica, conjunto de casos y parámetros de generación. Repite la evaluación antes de sustituir alguno. Un JSON válido solo confirma el formato, no que el veredicto sea correcto.

La regla de aprobación debe depender del riesgo del producto: una devolución indebida y un tono mejorable no tienen el mismo coste. Define qué errores bloquean una entrega y cuáles necesitan revisión humana; no adoptes un porcentaje universal porque suene exigente.

Medir el error que importa

Para cada caso guardamos la etiqueta humana y la decisión del juez. Este fragmento calcula los dos errores sobre su grupo correcto. Devuelve None cuando no hay casos en un grupo; ausencia de datos no equivale a cero errores. Las abstenciones se cuentan aparte y las tasas se calculan sobre decisiones emitidas.

def rates(cases):
    decided = [c for c in cases if c["judge"] is not None]
    bad = [c for c in decided if not c["human"]]
    good = [c for c in decided if c["human"]]
    return {
        "false_approval": sum(c["judge"] for c in bad) / len(bad) if bad else None,
        "false_rejection": sum(not c["judge"] for c in good) / len(good) if good else None,
        "abstentions": len(cases) - len(decided),
    }

El cálculo se ha comprobado con datos ficticios; no implica haber ejecutado un LLM. Conviene desglosar también las abstenciones por tipo de caso para que no oculten un fallo.

Limitaciones

Este protocolo no garantiza inmunidad a prompt injection ni asegura que los modelos no muestren sesgos de posición, longitud o preferencia por respuestas propias, según el estudio MT-Bench. Los riesgos mencionados no son universales ni garantías.

Del piloto a una decisión de entrega

Empieza con un solo fallo concreto. Pide al juez evidencias de la política y de la respuesta que justifican su decisión, sin confundir esa explicación con una prueba de verdad. Si discrepa sistemáticamente del experto, revisa casos, instrucciones y rúbrica antes de aumentar el volumen. Mantén supervisión humana para decisiones de riesgo.

En un RAG también habrá que separar calidad de recuperación y fidelidad de la respuesta: evaluar un RAG explica esa distinción. Un juez bien calibrado es una señal para decidir, no un sustituto del conocimiento del negocio.

Fuentes

Hamel Husain. Blog: LLM Judge
Study: MT-Bench: Evaluating Large Language Models

← Volver al blog