Jueces LLM y evaluación de prompts
Retomemos algo del capítulo anterior. Armamos dos versiones de un clasificador de opiniones (zero-shot y few-shot) y dijimos que el few-shot “funciona mejor” — pero hicimos esa afirmación con un solo ejemplo. Aquí está la pregunta incómoda que este capítulo existe para responder: ¿cómo sabes que no tuviste suerte con ese ejemplo?
El problema de fondo, y por qué ya lo conoces
Esto debería sonarte familiar. En el capítulo de loss de Parte I dijimos algo casi idéntico: una predicción no es suficiente para juzgar a un modelo — pudo haber acertado por pura suerte. Por eso corremos el modelo sobre un lote de texto real y promediamos. Evaluar prompts tiene exactamente el mismo problema, a otra escala: si comparas dos prompts con un solo caso de prueba, no sabes si la diferencia que ves es real o es ruido. Necesitas muchos casos de prueba y algo que los califique de forma consistente.
La diferencia es que ahora no tenemos un “token verdadero” contra el cual calcular cross-entropy — la respuesta correcta a “¿esta opinión es negativa?” no viene con una etiqueta matemática limpia. Necesitamos algo que haga ese trabajo de calificación por nosotros: un juez. Y ese juez, cada vez más frecuentemente, es otro LLM.
Las tres formas de evaluar, con el mismo ejemplo trabajado
Sigamos con el clasificador de sentimiento. Imaginemos cinco opiniones de prueba:
| # | Opinión |
|---|---|
| 1 | “El portátil está bien, pero esperaba más.” |
| 2 | “Nunca había tenido un producto tan malo.” |
| 3 | “Cumple exactamente lo que promete, sin sorpresas.” |
| 4 | “La batería dura poco, aunque la pantalla es excelente.” |
| 5 | “Superó todas mis expectativas, lo recomiendo totalmente.” |
Comparación por pares (pair-wise): corremos las cinco opiniones por ambas versiones del prompt, y le pedimos a un juez LLM que compare, caso por caso, cuál clasificación le parece más alineada con el criterio de negocio.
| # | Zero-shot dice | Few-shot dice | ¿Cuál prefiere el juez? |
|---|---|---|---|
| 1 | Neutra | Negativa | Few-shot |
| 2 | Negativa | Negativa | Empate |
| 3 | Positiva | Positiva | Empate |
| 4 | Positiva | Negativa | Few-shot |
| 5 | Positiva | Positiva | Empate |
Few-shot gana 2, empatan 3, zero-shot no gana ninguna. Esto sí es una comparación real — no la afirmación basada en un solo caso del capítulo anterior, sino un conteo verificable sobre varios casos.
Calificación de respuesta única (1 a 5): aquí calificamos una sola salida contra una escala absoluta, sin comparar dos versiones. Útil cuando no tienes una “versión anterior” con la cual comparar. Para el caso 4 (“la batería dura poco, aunque la pantalla es excelente” → few-shot dice “Negativa”), un juez podría calificar esa clasificación con un 3/5: técnicamente razonable, pero la opinión es mixta y “negativa” pierde el matiz positivo sobre la pantalla.
Evaluación guiada por rúbrica: añade precisión sobre la calificación 1-5 — en vez de dejar que el juez decida libremente qué significa “3” o “5”, le das reglas explícitas:
“Calificación 5: la clasificación coincide exactamente con lo que un analista humano de la empresa asignaría. Calificación 3: la clasificación es defendible pero pierde matices (como sentimiento mixto). Calificación 1: la clasificación contradice claramente el sentimiento expresado.”
Con esta rúbrica, el caso 4 sigue siendo un 3 — pero ahora cualquier persona que lea la rúbrica entiende por qué, y si corres la misma evaluación mañana con el mismo juez, es mucho más probable que llegue al mismo número.
Trampas comunes al usar un juez LLM
Un juez LLM no es un árbitro neutral perfecto — hereda sesgos reales:
- Sesgo de posición: en comparaciones por pares, algunos jueces prefieren sistemáticamente la respuesta que se les muestra primero, sin importar cuál es mejor. Mitigación estándar: correr la comparación dos veces, invirtiendo el orden, y solo confiar en el resultado si el juez es consistente en ambos sentidos.
- Sesgo de verbosidad: los jueces tienden a preferir respuestas más largas, incluso cuando la corta es igual de correcta.
- Sesgo de autopreferencia: un juez tiende a calificar mejor las respuestas que se parecen a cómo él mismo respondería, favoreciendo artificialmente a un modelo de la misma familia que el juez.
Así como no confiamos en el loss de una sola predicción (Parte I), tampoco confiamos en el veredicto de una sola comparación aquí.
¿Qué tan bien concuerda un juez LLM con humanos?
Hasta ahora hemos explicado cómo usar un juez LLM, pero no qué tan confiable es comparado con el estándar que intenta reemplazar: el juicio humano. Aquí hay un dato real que vale la pena conocer, con la precisión de qué exactamente midió.
El paper “Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena” (Zheng et al., 2023) puso a prueba esto directamente: usando el benchmark MT-Bench (80 preguntas de conversación de varios turnos, cubriendo escritura, razonamiento, matemáticas, código, y más), midieron qué tan seguido GPT-4, actuando como juez en modo de comparación por pares, coincidía con el veredicto de evaluadores humanos expertos — y compararon eso contra qué tan seguido los propios humanos coinciden entre sí en la misma tarea.
El resultado: GPT-4 coincidió con los humanos el 85% de las veces — por encima del 81% de concordancia que los propios evaluadores humanos tuvieron entre sí. Dicho de otra forma: en esta tarea específica, GPT-4 como juez fue tan confiable (o más) que pedirle a un segundo humano que revisara el trabajo de un primero.
La precisión importa aquí — qué NO dice este resultado: esta cifra es específica de comparación por pares, sobre MT-Bench, con GPT-4 como juez. No es una garantía universal de que “cualquier LLM como juez, en cualquier tarea, va a igualar a los humanos” — recuerda los sesgos que ya vimos (posición, verbosidad, autopreferencia), que siguen aplicando y pueden degradar esta concordancia en tareas o configuraciones distintas. Lo que sí demuestra, de forma concreta y medida, es que un juez LLM bien configurado puede alcanzar un nivel de confiabilidad comparable al de un segundo revisor humano — no es una aproximación burda, es una herramienta que, usada con criterio, compite genuinamente con el estándar que reemplaza.
Eligiendo el método correcto: una guía rápida
Con las tres técnicas ya cubiertas (comparación por pares, calificación única, rúbrica guiada), aquí una guía de decisión rápida:
| Tu situación | Método recomendado |
|---|---|
| Quiero saber si el prompt nuevo es mejor que el anterior | Comparación por pares |
| Quiero un puntaje absoluto de calidad, sin una versión anterior con qué comparar | Calificación única (1-5) |
| Necesito que la evaluación sea reproducible y bien definida entre distintas corridas | Rúbrica guiada |
| Voy a correr esto cientos de veces en CI/CD, necesito consistencia | Rúbrica guiada — el criterio explícito reduce la varianza entre corridas |
| Solo necesito una revisión rápida y exploratoria, no automatizada aún | Comparación por pares — la más simple de improvisar sin preparación previa |
¿El juez debe ser el mismo modelo que genera, o uno distinto?
Técnicamente puede ser el mismo modelo — no hay restricción que lo impida, y en la práctica es más simple de integrar. Pero hay una razón real para preferir uno distinto, y conecta directo con el sesgo de autopreferencia: si el mismo modelo genera y evalúa, cualquier punto ciego sistemático que tenga se cuela en ambos lados del proceso. Si el modelo tiene una tendencia sistemática a clasificar como “neutra” cualquier opinión mixta sin importar el peso relativo, esa misma tendencia va a estar presente cuando evalúe si “neutra” fue la clasificación correcta — el juez y el generador comparten el mismo sesgo, sin una segunda perspectiva genuina revisando el trabajo.
Un patrón muy común en la industria: usar un modelo más grande y más caro como juez, para evaluar las salidas de un modelo más pequeño y más barato que es el que realmente corre en producción. Tiene sentido económico porque generar ocurre constantemente, mientras que evaluar suele ocurrir con mucha menor frecuencia — en un conjunto de prueba, durante desarrollo, o como muestreo periódico sobre producción. Puedes permitirte pagar el precio de un modelo caro para el juez precisamente porque no lo llamas en cada interacción, solo cuando evalúas.
Vale la pena notar también que, de vez en cuando, un humano revisa una muestra de los veredictos del juez para confirmar que está calificando bien — si se equivoca sistemáticamente en cierto tipo de caso, esa retroalimentación permite recalibrarlo, algo que veremos formalizado como “auto-tuning de jueces” en el capítulo de observabilidad de Parte III.
Dónde vive todo esto: rúbricas, código, y herramientas
La rúbrica en sí siempre es texto plano — no importa qué herramienta uses después, es lenguaje natural que se convierte en parte del prompt que le mandas al juez. En su forma más cruda, sin ninguna herramienta de por medio:
prompt_juez = f"""
Eres un evaluador. Calificación 5: la clasificación coincide exactamente
con lo que un analista humano asignaría. Calificación 3: es defendible
pero pierde matices. Calificación 1: contradice el sentimiento expresado.
Pregunta original: {opinion}
Respuesta a evaluar: {clasificacion_del_modelo}
Da tu calificación (1-5) y explica tu razonamiento.
"""
respuesta_juez = llamar_al_modelo_juez(prompt_juez)
Eso ya es un “LLM como juez” funcionando, sin YAML ni plataformas externas. Herramientas como PromptFoo (que usa archivos de configuración YAML) automatizan la repetición de este patrón sobre muchos casos de prueba a la vez, sin que tengas que escribir el ciclo tú mismo — el campo llm-rubric de su configuración es exactamente nuestra rúbrica de texto. Plataformas como LangSmith cambian el formato (datasets y funciones evaluadoras en Python en vez de YAML), pero internamente hacen lo mismo: arman un prompt al juez con la rúbrica embebida, y además se encargan de trazabilidad — guardar cada corrida, comparar versiones a través del tiempo.
Pedirle al juez que explique su razonamiento antes de dar el veredicto es, literalmente, aplicar chain-of-thought (Capítulo 2) al propio acto de evaluar — y no es solo un extra: esa explicación es lo que permite detectar los sesgos de arriba. Si el juez dice “prefiero la respuesta B porque es más larga y detallada”, ahí mismo se ve el sesgo de verbosidad operando, en vez de recibir un veredicto ciego sin justificación.
El ecosistema de herramientas, más allá de PromptFoo
Frameworks de testing en código, para desarrollo activo:
- DeepEval (de Confident AI): se integra de forma nativa con pruebas estilo
pytest— la versión con herramienta real de “evals as code” que veremos formalizada en el capítulo de observabilidad de Parte III: cada evaluación se convierte en un test que corre en tu pipeline de CI, igual que cualquier prueba unitaria de software. Ofrece más de 50 métricas ya construidas (fidelidad, alucinación, relevancia, sesgo, toxicidad, precisión en selección de herramientas, entre otras) — rúbricas ya escritas y calibradas por otros, para no tener que redactar la tuya desde cero cada vez. - RAGAS: especializado específicamente en evaluar sistemas RAG (Capítulo 5) — algo que un juez genérico no sabría evaluar bien de fábrica. Sus cuatro métricas centrales separan limpiamente el problema de retrieval del problema de generación: fidelidad (¿la respuesta está realmente respaldada por el contexto recuperado, o el modelo alucinó de todas formas?), relevancia de la respuesta (¿la respuesta realmente atiende la pregunta?), precisión de contexto (¿lo que se recuperó es relevante?), y recall de contexto (¿se recuperó todo lo necesario para responder bien?). Esta separación te dice en qué etapa falló tu sistema RAG — si el problema es de recuperación o de generación.
Plataformas de observabilidad en producción — van más allá de “evaluar antes de lanzar”, correspondiendo a la evaluación “desde plataforma” que veremos en el capítulo de EDD (Parte III): evaluaciones automáticas sobre trazas reales de producción, no solo sobre un dataset fijo de prueba.
- LangSmith (comercial, de LangChain): tracing, depuración, y automatización de evaluaciones.
- Langfuse: alternativa de código abierto a LangSmith, para equipos que prefieren autoalojar su propia infraestructura.
- Braintrust: pensado para equipos que ya superaron pruebas locales y necesitan evaluar y monitorear agentes en producción — conecta con el “agentic tracing” de Parte III, que insiste en capturar no solo la respuesta final sino las llamadas a herramientas y transformaciones intermedias del agente.
- Arize Phoenix: de código abierto, con detección de anomalías incluida — la pieza que reaparece como estrategia detectiva en el capítulo de seguridad agéntica (Parte III).
Herramientas de seguridad especializadas:
- Garak: enfocado en red-teaming — probar modelos contra una biblioteca de ataques y vulnerabilidades conocidas, en vez de evaluar calidad en casos normales. Desarrollamos esta técnica a fondo en el capítulo de seguridad agéntica de Parte III, junto al caso Finnbot.
La progresión completa: prototipar con PromptFoo/DeepEval → especializar para RAG con RAGAS → llevar a producción con LangSmith/Langfuse/Braintrust/Phoenix → endurecer contra ataques con Garak.
Por qué esto es la base de todo lo que viene después
Sin evals sistemáticos, “mejorar un prompt” se reduce a “probé un par de ejemplos y se veía mejor” — una intuición que no se sostiene cuando el prompt corre miles de veces al día contra entradas que nunca viste. Los evals convierten ese juicio subjetivo en un número que puedes comparar objetivamente entre versiones de un prompt, entre modelos distintos (por ejemplo, comparando el rendimiento de un modelo contra otro para la misma tarea), o entre distintas descripciones de herramientas en un flujo agéntico.
Este es el primer paso hacia algo mucho más completo que veremos en Parte III: convertir la evaluación en una práctica de ingeniería sistemática, no en una revisión manual ocasional.
LinkedIn nelson.zepeda@simov.io SIMOV LABS
¿Encontraste un error? Sugerir una corrección