Objetivos de aprendizaje:
- Escribir una rúbrica multidimensional para salidas de texto de forma libre, dejar clara la pregunta de cada dimensión y entender que un mismo criterio de éxito suele necesitar varias rúbricas para evaluarse por completo
- Ajustar la salida del juez a una forma que los programas puedan procesar: primero el razonamiento y después la puntuación, 0.0–1.0 más aprobado/fallido, y explicar por qué una sola llamada suele ser más estable que varios jueces evaluando aspectos separados
- Reconocer tres modos de fallo de los jueces —calificar su propio trabajo, encontrar problemas siempre porque se les pidió encontrarlos, creerle solo al autorreporte del agente— y dar una mitigación accionable para cada uno
Requisitos: Lecciones 1–3, entender la evaluación «primero el estado final» y la prioridad de los verificadores deterministas | Anterior: << Lección 3 | Siguiente: Lección 5 >>
Le diste una tarea a tu agente de investigación: resumir cómo cambiaron los subsidios nacionales a la carga de vehículos eléctricos en los últimos tres años y producir un informe de dos páginas. Corrió quince minutos, llamó herramientas de búsqueda, descargó PDF, escribió 1.800 palabras. Se lee plausible.
Ahora quieres verificarlo. Ninguna de las verificaciones deterministas de la Lección 3 aplica aquí: no hay suite de pruebas que ejecutar, no hay código de salida de compilación que leer, no hay golden_answer para output == golden_answer porque no puedes escribirlo — pon a dos analistas humanos frente al mismo informe y no producirán textos idénticos.
Esto no es falta de imaginación. Así son estas salidas. Cuando Anthropic reflexionó sobre su sistema multiagente de investigación, fueron directos: las salidas de investigación son texto de forma libre, rara vez tienen una única respuesta correcta, así que son difíciles de evaluar programáticamente — los LLM encajan naturalmente para calificar salidas de este tipo1.
Pero antes de lanzarle el informe a la ligera a otro modelo y preguntarle «¿cómo se ve esto?», entiende dónde se sitúan los jueces LLM dentro del ranking oficial. El principio para elegir un método de calificación es "fastest, most reliable, most scalable" (el más rápido, el más confiable, el más escalable)2: la calificación basada en código es la más rápida y la más confiable, extremadamente escalable, pero le falta matiz para juicios complejos que requieren menos rigidez basada en reglas2; la calificación basada en LLM es rápida, flexible, escalable y apta para juicios complejos — y la guía oficial acompaña eso con un requisito previo en la misma oración: primero prueba para asegurar que es confiable, y después escala2; la calificación humana es la más flexible y de mayor calidad, pero lenta y cara, así que evítala si es posible2.
Trata ese requisito previo de la opción intermedia como una exigencia dura, no como un descargo de responsabilidad. Un juez LLM no es «una verificación más inteligente», es una llamada al modelo: puede equivocarse, cuesta dinero, y podría puntuar la misma entrada de forma distinta en ejecuciones sucesivas. Su valor es uno solo — alcanza cosas que las verificaciones deterministas no pueden alcanzar.
Así que esta lección no trata de «cómo hacer que un modelo puntúe tu salida». Eso es trivial — cualquier prompt te devuelve un número. Trata de hacer que ese número valga la pena de creerse: cómo estructurar rúbricas, cómo restringir la salida, quién ejecuta el juez, cómo se rompe y cuándo directamente no deberías preguntarle.
La palabra rúbrica suena formal. En términos llanos, es una planilla de calificación: descomponer el vago «¿esto está bien?» en preguntas específicas, responder cada una por separado y puntuar cada una por separado.
¿Por qué descomponer? Pregunta «¿este informe está bien?» y el modelo te da elogios vagos o críticas vagas. Pregunta «¿cada afirmación del informe aparece en las fuentes que cita?» y el modelo puede revisar afirmación por afirmación. La mayoría de los casos de uso necesitan evaluación multidimensional a lo largo de varios criterios de éxito2.
El agente de investigación de Anthropic usó una rúbrica de cinco dimensiones1, y detrás de cada dimensión hay un modo de fallo real:
Estas cinco dimensiones son para tareas de investigación. Tareas distintas necesitan conjuntos distintos. Lo que sí puedes llevarte es el método de descomposición: parte de «si esta salida se rompe, ¿cómo se rompe?», deriva las dimensiones desde ahí, un modo de fallo por dimensión. Y no te pierdas esto: un caso de uso dado, o incluso un criterio de éxito específico de ese caso de uso, podría requerir varias rúbricas para una evaluación integral2. No esperes que una sola planilla lo cubra todo.
Primero, la forma del veredicto. Anthropic probó con varios jueces evaluando componentes distintos — un juez por componente. El resultado: una sola llamada al LLM con un solo prompt que emite puntuaciones de 0.0 a 1.0 y una calificación de aprobado/fallido fue lo más consistente y lo más alineado con los juicios humanos1.
Para ser justos: dividir la evaluación en varias llamadas al LLM, cada una evaluando un aspecto, también es en sí un patrón de automatización de evaluaciones que la guía oficial ha descrito3. Ninguno de los dos enfoques está mal. La diferencia es que «una sola llamada es mejor» proviene de la comparación que Anthropic hizo sobre su propio sistema real1. Enfoque recomendado: empieza con una sola llamada y divide solo cuando tengas evidencia de que dividir mejora la precisión.
Después, qué tan apretado restringir la salida. La guía oficial para prompts de juez es "empirical or specific" (empírico o específico): por ejemplo, instruye al LLM a emitir únicamente 'correct' o 'incorrect', o a juzgar en una escala de 1 a 5; las evaluaciones puramente cualitativas son difíciles de valorar rápido y a escala2. En términos llanos: si el juez devuelve «la calidad general es aceptable, pero algunos detalles quedaron algo toscos», no tienes nada — no puedes promediar 200 respuestas así, no puedes decir si hoy salió mejor que ayer, y de todos modos tienes que leerlas una por una. Entonces, ¿para qué le preguntaste al juez?
La técnica decisiva: primero razona, después puntúa, y luego descarta el razonamiento. La guía oficial lo dice explícitamente: pídele al LLM que razone antes de producir una puntuación de evaluación, y después descarta ese razonamiento — esto mejora el desempeño de la evaluación, en particular para tareas que requieren juicios complejos2. «Descartar» no significa «no lo mires». El razonamiento es el andamio del juez — necesita escribir «la afirmación del párrafo 3 corresponde a qué segmento de la transcripción» antes de poder juzgar con exactitud. Pero ese texto no debería entrar a tus estadísticas aguas abajo. El reporte quiere puntuaciones y veredictos; el razonamiento va a los logs, esperándote para cuando una puntuación se vea sospechosa.
¿Y las dimensiones subjetivas? Algunas dimensiones no pueden ser binarias, como «¿el tono de este informe es apropiado para enviárselo a clientes?». La guía oficial ofrece una herramienta: la escala Likert basada en LLM, que usa un LLM para juzgar actitudes o percepciones subjetivas2 — una escala Likert es ese formato de cuestionario con incrementos fijos, tipo «muy en desacuerdo / en desacuerdo / neutral / de acuerdo / muy de acuerdo» (la cantidad de puntos es una convención de diseño de encuestas, no un mandato oficial). El principio clave sigue siendo el mismo: dale incrementos fijos, no lo dejes escribir libre.
Juntando todo, la salida del juez se ve más o menos así (el ejemplo muestra solo las primeras tres dimensiones; source_quality y tool_efficiency tienen la misma forma y se omiten por brevedad). Los programas leen score y verdict; reasoning se persiste para revisión:
Llegado este punto aparece un atajo tentador: que el agente se califique a sí mismo al final. Nadie sabe mejor que él lo que acaba de hacer.
Reprime esa tentación. Dos razones. Primera, la experiencia oficial: implementar salvaguardas donde una instancia del modelo procesa las consultas del usuario mientras otra las filtra por contenido o solicitudes inapropiadas tiende a funcionar mejor que hacer que la misma llamada al LLM se encargue tanto de las salvaguardas como de la respuesta principal3 — esa experiencia describía originalmente moderación de contenido (una instancia responde, otra filtra), pero el principio «no le pongas dos sombreros a la misma llamada» aplica aquí. Fíjate que dice «la misma llamada» — el problema es el contexto compartido, no la falta de inteligencia. Segunda, el mecanismo: la documentación oficial de Claude Code describe una práctica donde un revisor que corre en el contexto fresco de un subagente ve únicamente el diff y los criterios que le das, no el razonamiento que produjo el cambio, así que evalúa el resultado en sus propios términos4.
Léelo al revés y verás por qué falla la autocalificación: la cadena de razonamiento que produjo la salida sigue colgada en el contexto. El modelo acaba de convencerse a sí mismo de que «escribirlo así es correcto», tú le sigues inmediatamente con «¿esto es correcto?», y lo más probable es que repita el mismo razonamiento. Lo que obtienes no es un juicio independiente, es autorrepetición.
Si te preocupa que el juez sea demasiado laxo o demasiado estricto, la guía oficial ofrece una perilla: evaluar si un contenido dado es inapropiado, con varios prompts evaluando aspectos distintos o exigiendo umbrales de voto distintos para balancear falsos positivos y negativos3. En un escenario de verificación, un falso positivo es «marcar como roto algo que está bien» — te van a matar a falsas alarmas; un falso negativo es «dejar pasar algo roto» — trabajo malo llega a producción. Tres jueces donde dos deben decir fallido para que cuente como fallido es más laxo que un solo juez cuyo fallido ya cuenta — cuál configuración eliges depende de qué tipo de error cuesta más en tu escenario.
Ya cambiaste a una instancia distinta, ya escribiste una rúbrica, y el juez se rompe igual. Se rompe de maneras predecibles.
Uno: a un revisor al que le piden encontrar problemas siempre encontrará problemas. El más contraintuitivo y el más caro. La documentación oficial es clara: un revisor al que se le pide encontrar huecos normalmente reportará algunos, incluso cuando el trabajo está sólido, porque eso es lo que se le pidió4. La consecuencia no es solo «unas cuantas sugerencias inútiles»: el mismo pasaje señala que perseguir cada hallazgo lleva a sobreingeniería — capas extra de abstracción, código defensivo y pruebas para casos que no pueden ocurrir4. Tu agente entra en un bucle de autoescalada: el revisor sugiere tres cosas, tú las arreglas, la re-revisión sugiere tres más, el código se engorda, los problemas reales siguen sin resolverse.
Seguro has visto estos reportes: «se sugiere agregar defensa de cadena vacía a parseDate» — pero río arriba ya se garantiza que no viene vacía; «se sugiere extraer estas tres constantes a configuración» — pero no cambian desde hace tres años; «se sugiere agregar pruebas de reintento para timeout de red» — pero esta ruta no tiene llamadas de red. Ninguna de las tres está equivocada, ninguna de las tres vale la pena hacer, pero mezcladas en un reporte de revisión se ven idénticas a los problemas reales.
La guía oficial ofrece la mitigación: dile al revisor que marque únicamente los huecos que afectan la corrección o los requisitos declarados, y que trate el resto como opcional4. Escribe eso textualmente en el prompt del juez, y dale a las «otras sugerencias» un lugar a dónde ir — agrega un campo optional_notes y declara explícitamente que no participa en la puntuación. Tener dónde escribirlas significa que no tiene que meter sus preferencias de estilo dentro de las justificaciones de los descuentos.
Dos: los autorreportes del agente no son evidencia. Mucha gente toma el atajo de pasarle al juez solo el resumen final del agente: «recuperé tres fuentes autorizadas y las contrasté antes de confirmar la tasa del subsidio». El juez lo lee, le parece que el proceso suena sólido y da una puntuación alta. Pero esa declaración no es evidencia. La guía oficial sobre evaluación de herramientas lo plantea así: lo que los agentes omiten en su retroalimentación y sus respuestas suele ser más importante que lo que incluyen — los LLM no siempre dicen lo que quieren decir5. Dice «contrasté tres fuentes» pero pudo haber llamado la búsqueda una sola vez; el reintento fallido que no menciona, el momento en que obtuvo resultados vacíos y siguió fabricando, eso es lo que más necesitas ver. La solución también es directa: revisa las transcripciones crudas (incluidas las llamadas a herramientas y sus respuestas) para detectar cualquier comportamiento que no esté descrito explícitamente en la cadena de pensamiento del agente5. Traducido a solución: la entrada del juez debe incluir los logs crudos, no solo el autorreporte. La dimensión «eficiencia de herramientas» necesita esto especialmente — evalúa el número real de llamadas y si fueron correctas; esa información solo existe en los logs.
Tres: la pregunta misma es ambigua. Estrictamente hablando esto no es que el juez se rompa, es que le diste una pregunta rota. La guía oficial sobre diseño de evaluaciones nombra una categoría a evitar: casos de prueba ambiguos en los que hasta a los humanos les costaría llegar a un consenso de valoración2. Los vas a reconocer al validar el juez: tú y un colega juzgan la misma salida y obtienen resultados opuestos. No corras a arreglar el prompt del juez — el juez es «inexacto» porque esta pregunta no tiene respuesta exacta. O afinas los criterios hasta que los humanos puedan ponerse de acuerdo, o eliminas el caso. Usarlo para calcular la tasa de consistencia del juez solo produce un número autoengañoso.
¿El juez termina y ya está, o le pasas su retroalimentación al agente para que corrija y luego vuelves a juzgar? Este bucle es tentador, y se convierte fácilmente en una máquina de movimiento perpetuo que quema tokens.
La guía oficial ofrece dos señales de cuándo este flujo de trabajo encaja de verdad3: primera, que las respuestas del LLM pueden mejorarse demostrablemente cuando un humano articula su retroalimentación; y segunda, que el LLM puede proveer esa retroalimentación. El mismo pasaje agrega un requisito previo: este flujo de trabajo es particularmente efectivo cuando tenemos criterios de evaluación claros y cuando el refinamiento iterativo aporta valor medible3.
Usa esas dos condiciones como pruebas de admisión. El procedimiento es directo: sé tú el juez primero, escríbele retroalimentación al agente y observa si de verdad mejora tras corregir. Si la retroalimentación escrita por un humano no lo mueve, la escrita por un LLM lo moverá todavía menos. En ese punto lo que necesita arreglo es el prompt o las herramientas, no agregar una capa de revisión. A la inversa, si la retroalimentación humana claramente funciona, revisa la segunda condición — haz que un LLM escriba retroalimentación contra la rúbrica y compárala con la tuya. Si ambas pasan, vale la pena construir el bucle.
Volvamos al ranking de la Lección 3. El principio para elegir un método de calificación es el más rápido, el más confiable, el más escalable2; la calificación basada en código va por delante de la basada en LLM en los tres ejes2. Así que los jueces van donde las verificaciones deterministas no alcanzan, no como reemplazo de ellas. Para el mismo informe, la estratificación correcta se ve así:
No mandes a la Capa 2 a pagar lo que la Capa 1 ya atrapó — una salida que ni siquiera tiene formato válido no necesita una llamada al modelo para saber que es inaceptable. La Capa 3 no se puede saltar: las personas que prueban agentes encuentran casos límite que las evaluaciones no ven1; el sesgo de «preferir consistentemente granjas de contenido» que vimos antes lo atrapó la prueba humana1.
El límite de esta lección: cómo organizar conjuntos de evaluación, contra cuántos casos ejecutar este juez — eso es la Lección 5. Cablear el juez dentro de un arnés de evaluación repetible que produzca reportes — eso es la Lección 6. Esta lección solo resuelve cómo hacer que un juicio individual sea digno de confianza.
>> Lección 5: Conjuntos de evaluación: empieza con 20 tareas reales
How we built our multi-agent research system — Anthropic Engineering — https://www.anthropic.com/engineering/multi-agent-research-system ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11
Define success criteria and build evaluations — Claude API documentation — https://platform.claude.com/docs/en/test-and-evaluate/develop-tests ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14 ↩15 ↩16 ↩17 ↩18
Building Effective AI Agents — Anthropic Engineering — https://www.anthropic.com/engineering/building-effective-agents ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8
Best practices for Claude Code — Claude Code official documentation — https://code.claude.com/docs/en/best-practices ↩ ↩2 ↩3 ↩4 ↩5 ↩6
Writing effective tools for agents — with agents — Anthropic Engineering — https://www.anthropic.com/engineering/writing-tools-for-agents ↩ ↩2 ↩3 ↩4
Tu tarea: ① Enumera al menos 4 defectos de este prompt, cada uno correspondiente a una regla cubierta en esta lección (escribe qué regla es y por qué esto la viola); ② Reescríbelo en una versión funcional directamente utilizable, no una descripción de «cómo debería escribirse».
Tu tarea: ① Diseña una rúbrica de tres dimensiones (fidelidad a los hechos, cobertura de los puntos clave, ningún ítem de acción faltante), cada dimensión de 0.0 a 1.0 más un aprobado/fallido global, escribiendo con claridad qué pregunta cada dimensión y qué cuenta como descuento; ② Escribe el prompt de juez completo, incluyendo el orden de primero razonar y después puntuar, y restricciones estrictas de formato de salida; ③ Diseña los pasos para «validar al juez mismo»: prepara un conjunto pequeño de ejemplos buenos/malos etiquetados por humanos, ejecuta el juez, compara la tasa de concordancia y especifica qué arreglar primero y qué después cuando la concordancia sea insuficiente. No hace falta llamar APIs de verdad; los entregables son el prompt, el JSON y los pasos en sí.
{
"factual_accuracy": { "reasoning": "El «30% de reducción» del párrafo 2 aparece textual en la página 4 de la fuente A; el «varias regiones suspendieron los pagos» del párrafo 4 no tiene respaldo en ninguna de las tres fuentes.", "score": 0.5 },
"citation_accuracy": { "reasoning": "4 de 5 citas coinciden con sus afirmaciones; el enlace de la cita 3 lleva a otro artículo del mismo sitio.", "score": 0.8 },
"completeness": { "reasoning": "La tarea pedía los últimos tres años, el informe solo cubre 2024 y 2025.", "score": 0.6 },
"verdict": "fail"
}
Capa 1 (determinista, milisegundos, costo cero) ¿JSON / Markdown válido? ¿Longitud dentro del rango requerido? ¿Enlaces de las citas alcanzables (estado HTTP)? ¿Cantidad de citas >= 3? Cualquier ítem que falle → fallido inmediato, no invocar al juez
Capa 2 (juez LLM, segundos, facturado por token) Puntuación con rúbrica de cinco dimensiones + aprobado/fallido Entrada: requisitos de la tarea + salida + logs crudos (llamadas y respuestas de herramientas)
Capa 3 (humano, lento y caro, solo muestreo) El juez dijo fallido pero tú sospechas Muestra aleatoria de los que el juez aprobó, para cuidarte de una laxitud sistemáticaAcabas de terminar de escribir este informe sectorial. Ahora evalúa tu propio resumen:¿Te parece que este resumen es bueno? Evalúa en detalle sus fortalezas y debilidades,sé lo más exhaustivo posible y enumera todas las sugerencias de mejora que se te ocurran.¡Gracias!