Por qué dejamos que un modelo rival puntúe nuestro benchmark

Todo benchmark interno de modelos tiene el mismo problema de credibilidad. Elegiste tú al ganador. Escribiste tú las pruebas. Y cada vez con más frecuencia, usaste un LLM para puntuar las respuestas. Llegados a ese punto, quien lee tiene todo el derecho a preguntar qué impidió exactamente que el montaje entero acabara halagando la conclusión a la que ya habías llegado.

Así intentamos responder a esa pregunta al seleccionar el modelo que hay detrás de Seal AI.

El problema del LLM-as-a-judge

Usar un modelo de lenguaje para puntuar las respuestas de otro modelo es barato, rápido y escala a cientos de salidas. También está sesgado de maneras que se han documentado una y otra vez:

• Sesgo de autopreferencia. Los jueces valoran sus propias respuestas —y las de modelos de su misma familia— con más generosidad de la que aplicaría un evaluador neutral.
• Sesgo de posición. Cuando se les muestran dos respuestas, los jueces favorecen sistemáticamente uno de los dos huecos, con independencia del contenido.
• Sesgo de verbosidad. Las respuestas largas puntúan más alto, aunque lo que añaden no aporte nada.

Nada de esto es un problema de ingeniería de prompts. No puedes instruir a un juez para que deje de preferirse a sí mismo, igual que no puedes instruir a un testigo para que deje de ser el hermano del acusado. Se resuelve por estructura.

Paso uno: dejar al juez casi sin trabajo

La primera mitigación es recortar las competencias del juez hasta que lo que quede sea de verdad una cuestión de criterio.

En nuestro benchmark, todo lo objetivo lo puntúa código determinista antes de que ningún juez vea nada. Al empezar cada tanda calculamos la verdad de referencia directamente desde la base de datos de analítica —entradas, conversiones, tasa de rebote, ingresos, canal principal, fuente principal, dispositivo principal—, de modo que cada cifra que afirme el asistente pueda compararse con la realidad. Después, los evaluadores deterministas comprueban:

• Grounding (anclaje al dato): ¿cada número que se dice es el número real?
• Tool-calling: ¿llamó el modelo a las herramientas correctas del inventario de 63?
• Formato estructurado: ¿la respuesta valida contra el esquema que espera el producto?
• Negativas: ¿se negó el modelo a hacer algo que era perfectamente capaz de hacer?
• Trampas: entidades inexistentes, periodos vacíos y el canario de la instrucción inyectada.

Esos evaluadores tienen 26 tests unitarios propios, y un script aparte vuelve a puntuar tandas archivadas offline sin gastar un solo token, así que un cambio en la evaluación puede aplicarse de forma retroactiva sin volver a consultar a ningún modelo. Los evaluadores deciden el resultado.

Lo que le queda al juez es el residuo que el código realmente no puede medir: si la respuesta es útil, si es clara, si es formalmente precisa. Puntuado de 1 a 5, entre modelos, y etiquetado en el informe como una señal no determinista. Nunca como el veredicto.

Paso dos: nombrar un juez con motivos

La segunda mitigación es la que recomendaríamos a cualquiera que publique un benchmark interno, porque no cuesta nada y elimina una categoría entera de objeciones.

Pusimos de juez a qwen3-235b: uno de los dos modelos candidatos contra los que competía nuestro ganador, y el más fuerte de ellos en varias evaluaciones públicas. No un tercero neutral. El rival directo del modelo que acabamos poniendo en producción, ejecutado a temperatura cero para que fuera reproducible.

La lógica es sencilla. Si el sesgo de autopreferencia es real, ahora apunta en dirección contraria a nuestra conclusión. Un juez rival tiene todas las razones estructurales para valorar muy alto las respuestas de su propia familia y peor las del ganador. Cualquier sesgo que quede en el sistema trabaja en contra del resultado que esperábamos.

Puntuó a gpt-oss-120b con alrededor de 4,9 sobre 5,0 en utilidad, claridad y precisión formal. Ese número vale más que un 5,0 de un juez amistoso, precisamente por quién lo dio.

Lo que aun así no podemos afirmar

Un juez es una opinión. Con un único anotador no hay manera de calcular el acuerdo entre evaluadores, lo que significa que no podemos distinguir entre «esta respuesta era clara» y «a este juez en concreto le parece claro este estilo». Un segundo anotador independiente —otro modelo, o un panel humano sobre una muestra— nos permitiría publicar una medida de acuerdo en vez de pedirte que te fíes de la palabra de un solo modelo.

No lo hicimos. Es una limitación real, está declarada en la documentación del benchmark y es lo primero que arreglaríamos en la siguiente revisión.

Reglas para usar el LLM-as-a-judge con honestidad

1. Primero, lo determinista. Todo lo que se pueda comprobar contra la verdad de referencia hay que comprobarlo contra la verdad de referencia. Al juez le tocan las sobras, no el núcleo.
2. Nunca juzgues a tu propia familia. Como mínimo, usa un modelo de un linaje distinto al del modelo evaluado. Mejor todavía: usa el candidato contra el que compite.
3. Temperatura cero. Un juez cuya puntuación cambia entre tandas no es un instrumento de medida.
4. Aleatoriza el orden y vigila la longitud. El sesgo de posición y el de verbosidad son baratos de mitigar y bochornosos de ignorar.
5. Etiqueta la puntuación como señal. Publícala al lado de los resultados deterministas, nunca como titular y nunca como desempate en una cuestión de corrección.
6. Di cuántos evaluadores has usado. Un juez, sin medida de acuerdo: dilo. Quien te lee puede ponderar una limitación declarada. No puede ponderar la que te has callado.

En resumen

Un benchmark interno vale exactamente lo que valgan sus incentivos. Los nuestros estaban dispuestos para que la manera más fácil de obtener un resultado halagador fuera merecerlo de verdad: puntuación objetiva en código contra la verdad de referencia de la base de datos en vivo, puntuación subjetiva a cargo del modelo con más que ganar si nos bajaba la nota, y las carencias escritas dentro del informe en lugar de fuera.

El diseño completo, los evaluadores y las tandas archivadas están documentados en el informe de nuestro benchmark interno, incluida la primera tanda completa que tiramos a la basura por inválida.