Resumen — Un LLM-as-a-judge funcional tiene cuatro partes en este orden: una definición del criterio en el vocabulario de tu dominio, una estructura de razonamiento explícita que fuerce una verificación paso a paso o afirmación por afirmación, una regla de puntuación que asigne el resultado del razonamiento a un veredicto determinista, y una cláusula que gestione los casos extremos que tu pipeline de recuperación o de agentes realmente produce. Si omites cualquiera de estas cuatro partes, el juez recurrirá a comprobaciones de plausibilidad, que es lo que hace que los prompts genéricos pasen por alto los fallos importantes. Las plantillas a continuación cubren la fidelidad, la relevancia, el cumplimiento de formato y la corrección de herramientas de agentes: los cuatro criterios que la mayoría de los pipelines de producción necesitan primero.
Este artículo está dirigido a ingenieros que ya han construido o utilizado un juez y desean un prompt que sobreviva a una ejecución de calibración, no un fragmento de inicio. Si aún no has construido el pipeline en el que se integra el juez, comienza con la guía completa y regresa después.
La estructura de cuatro partes de un prompt de juez funcional
La guía completa nombra los cuatro elementos de un vistazo. Este artículo es la versión con el modo de fallo que cada uno previene, y la reescritura de malo a bueno para cada uno. Un prompt de juez es un pequeño programa escrito en inglés que el modelo ejecuta contra una entrada específica. Las cuatro partes a continuación son fundamentales. Eliminar cualquiera de ellas cambia el comportamiento en producción, no solo en el conjunto de desarrollo.
Definición del criterio. Escribe el criterio con las palabras que utiliza tu dominio, no con vocabulario genérico de ML. "Cada afirmación fáctica en la respuesta está directa y explícitamente respaldada por el contexto recuperado" es una definición de dominio. "La respuesta es de alta calidad" no es una definición; es un marcador de posición que el juez rellenará con los sesgos que tenga. Si tu equipo no está de acuerdo sobre lo que significa el criterio, ese desacuerdo es lo que el prompt debe resolver. Las rúbricas vagas producen veredictos vagos a escala.
Estructura de razonamiento. Indica al juez que enumere las unidades discretas de evaluación antes de asignar una puntuación. El razonamiento de cadena de pensamiento solo ayuda cuando el juez enumera las unidades correctas; lo que importa a nivel de prompt es especificar exactamente cuáles son esas unidades. Afirmaciones para la fidelidad. Intenciones para la relevancia. Llamadas a herramientas más argumentos para la calificación de agentes. Elementos requeridos y prohibidos para el cumplimiento de formato. Sin un paso de enumeración, el juez realiza una coincidencia de patrones superficial: ¿esta respuesta parece una respuesta fiel? Con uno, el juez realiza la comprobación que realmente deseas: ¿está cada afirmación respaldada, sí o no?
Regla de puntuación. Asigna el resultado del razonamiento a un veredicto con una regla determinista. "Si alguna afirmación enumerada no está directamente respaldada por el contexto recuperado, puntúa 0" es una regla. "Usa tu criterio para sopesar la fidelidad general" no lo es. El objetivo de la regla de puntuación es eliminar el juicio del paso de puntuación; el juicio reside en la estructura de razonamiento, la puntuación es mecánica. Esto es lo que hace que las ejecuciones sean reproducibles a temperatura 0.
Gestión de casos extremos. Los pipelines de recuperación en producción generan entradas que los ejemplos de prueba nunca producen. Contexto truncado en los límites de los fragmentos. Recuperaciones vacías cuando la consulta queda fuera del índice. Respuestas parciales. Rechazos. Respuestas de múltiples turnos donde parte de la respuesta es fiel y parte no. Especifica cómo debe tratar el juez cada uno. El contexto truncado cuenta como soporte cero para cualquier cosa posterior al corte. Las recuperaciones vacías hacen que cualquier afirmación externa sea infiel por definición. Un rechazo es fiel si el rechazo en sí mismo está respaldado por la política. Sin estas cláusulas, el juez recurrirá a la plausibilidad y los puntuará según los sesgos del modelo.
Patrones de diseño de rúbricas que sobreviven en producción
El diseño de la rúbrica es donde realmente residen la mayoría de las mejoras en la calidad del juez. El mismo modelo con la misma definición de criterio puede puntuar 0.40 de alineación o 0.75 de alineación frente a las mismas etiquetas de referencia, dependiendo de cómo esté estructurada la rúbrica.
Elige la escala de menor precisión que capture la distinción que te interesa. Utilice una evaluación binaria (aprobado/suspendido) cuando la pregunta sea "¿la respuesta infringe la rúbrica, sí o no?". Emplee una escala de tres puntos (suspendido / parcial / aprobado) cuando los grados de error sean relevantes para la clasificación. Solo recurra a escalas de 1 a 5 o de 1 a 10 si dispone de un conjunto de datos de referencia (gold-set) que valide que el evaluador puede utilizar esa resolución. Las escalas detalladas invitan al evaluador a inventar distinciones que no puede justificar, y el ruido resultante anula la señal. Según nuestra experiencia y los resultados publicados en MT-Bench, los evaluadores binarios se alinean con los humanos de forma más fiable que los de 5 puntos en la misma tarea. Un evaluador de 5 puntos le ofrece más números, pero no más información.
Una rúbrica por dimensión. Un único prompt que califique la fidelidad, la relevancia, la fluidez y el cumplimiento del formato en una sola pasada genera puntuaciones correlacionadas y poco fiables. El modelo se ancla en la primera dimensión y permite que ese anclaje contamine a las demás. Califique un criterio a la vez, en llamadas independientes, y promedie o agregue los resultados en la capa de aplicación. El coste de una llamada de inferencia adicional es insignificante comparado con el coste de no poder atribuir una regresión a una dimensión específica.
Operativice los criterios ambiguos. "Útil" es una sensación, no una rúbrica. "La respuesta aborda directamente cada restricción de la consulta del usuario, incluidas las restricciones negativas" es una rúbrica. Si se encuentra escribiendo un adjetivo en la rúbrica ("útil", "preciso", "profesional"), sustitúyalo por el procedimiento que un evaluador humano realizaría realmente para determinar si el adjetivo es aplicable. El evaluador ejecutará el procedimiento; no ejecutará el adjetivo.
Incorpore la neutralidad respecto a la longitud. Una rúbrica que no indique explícitamente que "las respuestas concisas puntúan igual o mejor que las prolijas con un nivel de corrección equivalente" es una rúbrica que optimiza implícitamente la longitud. El sesgo de verbosidad es una propiedad medible de los evaluadores LLM: ante respuestas de calidad equivalente, los evaluadores puntúan sistemáticamente mejor las respuestas más largas. Cualquier recompensa por "integridad" o "exhaustividad" necesita un límite superior explícito, o el evaluador tratará por defecto las respuestas más largas como más exhaustivas.
Espere que la rúbrica derive. Shankar et al. (2024) documentaron la deriva de criterios: los evaluadores humanos revisan rutinariamente los criterios tras ver los resultados del modelo. Una rúbrica escrita de antemano es una hipótesis, no un artefacto final. Trátela como a un código: cree versiones, realice un seguimiento de qué etiquetas de referencia se produjeron bajo qué versión y recalibre tras realizar cambios importantes.
Ejemplo práctico: evaluador de fidelidad para RAG
La fidelidad es el criterio de mayor valor a acertar, ya que es el modo de fallo que más cuesta en producción. Un evaluador que pasa por alto fallos de fidelidad es uno que distribuye alucinaciones con confianza. La plantilla siguiente amplía un prompt de fidelidad mínimo de dos formas: una lista de unsupported_claims en el esquema de salida y pasos de razonamiento explícitos que gestionan los casos de afirmaciones implícitas y recuperación vacía que la mayoría de las líneas base pasan por alto.
Vale la pena mencionar los aspectos menos evidentes. El evaluador enumera antes de puntuar, no después; invertir el orden permite que el modelo se comprometa con un veredicto y lo racionalice a posteriori. El esquema de salida solicita unsupported_claims como una lista, lo que obliga al evaluador a completar la lista o a admitir que no hay nada en ella. Esto detecta el modo de fallo más común en la evaluación de fidelidad: la atribución entre documentos, donde la respuesta contiene un hecho que es cierto en otro lugar pero no en el pasaje recuperado. Un evaluador que solo devuelve {"veredicto": "infiel", "razón": "..."} ocultará esto; un evaluador que deba enumerar las afirmaciones no respaldadas específicas lo sacará a la luz.
El caso en el que esta plantilla sigue fallando es cuando la afirmación no respaldada es implícita en una construcción más larga ("el plazo de devolución es generoso" cuando el contexto especifica un número pero no un adjetivo). Para las afirmaciones implícitas, añada un paso en la estructura de razonamiento: "si la respuesta utiliza una frase evaluativa o comparativa sobre una propiedad cuantificable, la cantidad subyacente debe aparecer en el contexto". Vea cómo un bucle de calibración encuentra estas lagunas automáticamente en la guía de optimización de evaluadores.
Ejemplo práctico: evaluador de relevancia para RAG y chat
La relevancia plantea una pregunta distinta a la de la fidelidad. La fidelidad comprueba si la respuesta se mantiene dentro de la evidencia recuperada; la relevancia comprueba si responde a lo que el usuario realmente preguntó. Una respuesta puede ser perfectamente fiel y completamente irrelevante, citando textualmente un párrafo no relacionado del contexto. También puede ser relevante e infiel.
El modo de fallo clásico de los prompts de relevancia ingenuos es que premian la similitud temática. La consulta es "¿cuál es el plazo de reembolso para suscripciones no utilizadas?" y la respuesta describe los niveles de suscripción en detalle sin mencionar el plazo de reembolso. Un juez que califique basándose en la superposición temática aprobará esto. Un juez que califique basándose en la cobertura de la intención no lo hará.
Esta plantilla acierta en dos aspectos en los que los prompts de relevancia genéricos fallan. Primero, el paso de descomposición es obligatorio y el esquema lo impone: el juez no puede emitir un veredicto sin enumerar las intenciones y marcar cada una. Segundo, las restricciones negativas se señalan explícitamente, ya que son el fallo silencioso más común. Una respuesta que maneja cuatro de las cinco intenciones e ignora la restricción negativa ("no X") parecerá relevante para un juez que solo busca coincidencias temáticas.
La combinación de un juez de fidelidad y un juez de relevancia cubre los dos ejes de fallo de una respuesta RAG: una respuesta fiel pero irrelevante significa que el sistema recuperó el contexto equivocado; una respuesta infiel pero relevante significa que el modelo inventó información fuera del contexto. Ambos deben detectarse, y un solo juez no puede realizar ambas tareas sin confundirlas.
Ejemplo práctico: juez de cumplimiento de formato
El cumplimiento de formato es el criterio donde es más probable que un juez LLM sea la herramienta equivocada, y donde los equipos lo usan de todos modos. Si su salida debe ser un JSON válido según un esquema, una comprobación de esquema determinista es más rápida, barata y fiable que cualquier juez. Ejecute pydantic o jsonschema primero. El juez se encarga de los casos que el esquema no puede cubrir.
Donde un juez sí aporta valor: salidas semiestructuradas donde la estructura está definida de forma flexible (por ejemplo, "una lista numerada de tres a cinco recomendaciones, cada una con una frase de apoyo"), cumplimiento parcial donde el esquema pasa pero el contenido viola una regla implícita, o salidas en lenguaje natural que deben seguir una guía de estilo (formato de citas, tono, redacción de información de identificación personal).
La cláusula explícita de "no evaluar aspectos no enumerados anteriormente" es importante. Sin ella, un juez de formato empezará a calificar también la relevancia y la fidelidad, porque el modelo quiere ser útil, y las puntuaciones de este juez terminarán correlacionadas con las de los otros dos. Esta correlación rompe la alineación con los humanos y hace imposible diagnosticar qué dimensión está empeorando.
Combine este juez con una comprobación de esquema determinista previa. El flujo es: comprobación de esquema → si pasa, ejecutar el juez de formato para los requisitos flexibles → si pasa, ejecutar los jueces de contenido. Cada paso filtra al siguiente, y solo paga por la llamada al LLM cuando la comprobación determinista ya ha dado el visto bueno.
Ejemplo práctico: juez de corrección de herramientas de agente
La evaluación de agentes tiene una forma distinta a la evaluación RAG. La unidad de análisis es una trayectoria: cada llamada a herramienta que hizo el agente, con argumentos y resultados, más la respuesta final. Existen tres subcriterios dentro de la "corrección de herramientas", y confundirlos produce un juez que no puede distinguir entre los modos de fallo.
Selección de herramientas. ¿Llamó el agente a las herramientas correctas para la solicitud del usuario? Un agente que llama a search_kb cuando debería haber llamado a query_database está cometiendo un error de selección.
Corrección de argumentos. ¿Completó el agente los argumentos de la herramienta correctamente? Un agente que llama a query_database(start_date="2024-01-01") cuando el usuario preguntó por "la semana pasada" está cometiendo un error de argumentos, incluso si la herramienta elegida era la correcta.
Coherencia de la trayectoria. ¿Tenía sentido la secuencia de llamadas? Un agente que llama a la misma herramienta tres veces con argumentos idénticos, o que recupera datos y luego los ignora en la respuesta, está cometiendo un error de trayectoria.
Evalúelos como tres jueces independientes, no como un megajuez. Las estructuras de razonamiento son distintas y una rúbrica única hará que el modelo se ande con rodeos entre las tres preocupaciones.
La evaluación de la corrección de herramientas es un ámbito donde Galtea codifica el patrón como una métrica de primer nivel: la métrica de corrección de herramientas toma la trayectoria capturada del decorador @trace y califica la selección, los argumentos y el orden en comparación con una trayectoria esperada. La razón para usar una métrica integrada en lugar de crear su propio juez es que la captura del rastro es la parte difícil, el prompt del juez es la parte fácil y ambos deben compartir un esquema.
Para agentes de varios pasos con trayectorias ramificadas, el enfoque de comparación con lo esperado no funciona porque no existe una única trayectoria correcta. En esos casos, la rúbrica cambia de "¿el agente siguió la ruta esperada?" a "¿cada paso tuvo una justificación coherente con el estado anterior?", lo cual es un prompt diferente y un problema de evaluación distinto. Un artículo posterior de esta serie trata sobre la calificación de trayectorias para agentes de final abierto.
Formas comunes en las que fallan los prompts de los jueces en producción
Cinco antipatrones aparecen en casi todos los prompts de jueces que no han sido calibrados. Las soluciones no son sutiles.
Lenguaje vago en la rúbrica. "Califica la respuesta en una escala del 1 al 5, donde 5 es excelente y 1 es deficiente". El juez producirá un número. El número no significará nada entre distintas ejecuciones. La solución es definir a qué corresponde cada nivel de la escala en términos de una propiedad observable de la respuesta.
Especificar demasiado el formato del veredicto. El problema de pedir justificaciones estructuradas largas antes del veredicto es lo suficientemente específico como para tener nombre. Pedirle al juez que "primero analice X, luego considere Y, después pondere Z, redacte un párrafo final de razonamiento y finalmente devuelva la puntuación" no solo cuesta tokens. El razonamiento se genera token a token, y los primeros tokens comprometen al modelo con una dirección antes de que haya pensado en el problema; todo lo que sigue es una justificación post-hoc anclada en la primera frase. Mantenga la estructura de razonamiento dentro del prompt, no dentro de la salida.
Preferencia implícita por la longitud. Si la rúbrica premia la "exhaustividad", la "profundidad" o la "integridad" sin ponerles límites, el juez preferirá respuestas más largas. Limite esos criterios explícitamente o añada una cláusula de neutralidad respecto a la longitud.
"Usa tu criterio" en cualquier parte del prompt. Esta frase es una señal de que la rúbrica está incompleta. El juez usará su criterio; cómo sea ese criterio es precisamente lo que la calibración intenta medir. Reemplace cada instancia con una regla determinista.
Mezclar las instrucciones del generador con las instrucciones del juez. Copiar y pegar el prompt del sistema del generador en el juez ("eres un asistente útil y honesto...") hace que el juez evalúe las respuestas basándose en la personalidad del generador en lugar de en la rúbrica. El juez tiene una sola función: aplicar la rúbrica. Elimina todo lo demás.
Evaluar el prompt en sí, no solo el modelo
Un prompt de juez que parece razonable en tres ejemplos producirá veredictos diferentes en los siguientes treinta. La forma de descubrirlo antes de que el prompt se acerque a producción es puntuarlo frente a un conjunto de referencia (gold set) etiquetado y medir la alineación con las etiquetas humanas. La precisión agregada no es suficiente; informa sobre el coeficiente Kappa de Cohen, la exhaustividad (recall) por clase y al menos una métrica basada en rangos (Spearman) para que los conjuntos de referencia desequilibrados no enmascaren la realidad del prompt.
El ciclo completo de calibración, el conjunto de siete métricas y un caso de producción donde este enfoque mejoró la alineación de un juez de fidelidad de 0,40 a 0,75 con nueve anotaciones humanas se detallan en la guía de optimización de jueces. Lo que debes tener en cuenta al redactar el prompt es que este es una hipótesis, no un entregable final. Deberá medirse, reescribirse y volver a medirse antes de que pueda autorizar un despliegue.
Dentro de Galtea, los prompts de los jueces se versionan junto con la métrica de LLM-como-juez a la que pertenecen, y cada versión de la métrica está vinculada al conjunto de referencia con el que fue calibrada. La razón para versionar a los jueces de esta manera no es por llevar un registro, sino porque una regresión en la alineación tras editar un prompt debe ser atribuible a dicha edición, y una regresión tras el lanzamiento de un modelo debe ser atribuible al modelo. Sin versionado, ambos se confunden y pierdes la capacidad de diagnosticar cuál de los dos ha fallado.
Cuándo NO escribir un prompt de juez personalizado
Tres casos en los que un prompt personalizado es una mala idea, y donde los equipos escriben uno de todos modos.
Cuando una comprobación determinista cubre el criterio, no escribas un prompt de juez para ello. La equivalencia SQL, la validación de esquemas JSON, las coincidencias mediante expresiones regulares y la correspondencia de argumentos de llamadas a herramientas con una trayectoria conocida como correcta tienen respuestas cerradas. Un juez LLM es la herramienta equivocada en estos casos; la implicación en el diseño del prompt es más clara. El ciclo de calibración que dedicarías a un prompt personalizado (escribir la rúbrica, etiquetar el conjunto de referencia, ejecutar la optimización, volver a medir) nunca se amortiza, porque la pregunta subyacente no es ambigua. Escribir el prompt es, en sí mismo, un desperdicio.
Cuando el criterio está bien cubierto por un prompt de juez publicado y calibrado, utiliza ese. Los prompts de fidelidad, relevancia y corrección de herramientas documentados en Galtea han sido calibrados frente a múltiples conjuntos de referencia en despliegues de clientes. Empezar desde una base calibrada y editar según tus modos de fallo específicos es más rápido que empezar desde cero.
Cuando el equipo aún no ha creado un conjunto de referencia, tampoco escribas un prompt personalizado todavía. La calibración sin un conjunto de referencia no es calibración. Crea primero el conjunto de referencia, ejecuta un prompt estándar para establecer una línea base y solo entonces itera sobre el prompt. El orden importa: un prompt iterado basándose en "intuiciones" se verá genial en los casos que el autor eligió considerar y fallará en los que no. Para construir el conjunto de referencia, consulta los seis marcos de trabajo de preguntas y respuestas para crear conjuntos de evaluación de referencia.
El prompt del juez es la parte más pequeña, barata y editable de un proceso de evaluación. Esa es también la razón por la que es la parte que recibe menos escrutinio y produce más sorpresas en producción. Trátalo como tratarías cualquier otra pieza de código que decide si se lanza o no: escríbelo explícitamente, versiona, mídelo frente a la realidad y reescríbelo cuando la medición indique que debes hacerlo.
