Style Guide de evaluación: la vara que un cambio pasa antes de salir

Esta es la página donde Cleon deja de describir qué es la evaluación y dice qué hacemos antes de que un cambio salga. Las páginas de referencia exponen las partes — qué es la evaluación y el loop que corre, los datasets y métricas que hacen del test set un spec de producto, y el LLM-as-judge que califica lo que una regla no alcanza. Los gotchas exponen las diez maneras en que una medición miente. Este Style Guide es la disciplina que decide qué medir, dónde y cómo — y la compuerta que un cambio tiene que pasar antes de que su salida toque a un cliente o un registro.

Las reglas son cortas a propósito. Cuando una regla necesita explicación, la explicación vive en la página que enlaza. Esta es la forma operativa de los principios de AI Engineering — cada regla de abajo es uno de esos principios con las mangas arremangadas, y citamos el número para que puedas rastrear la regla hasta su razonamiento. Es la compañera del lado de la medición del Style Guide de agentes, del Style Guide de grounding y del Style Guide de prompting: cada uno de esos termina una oración con "eval en cada cambio", y esta es la página a la que esa oración apunta. La red de regresión de la que cuelgan los tres se construye acá.

La primera decisión: ¿qué medís, y dónde?

Antes de elegir una métrica o una herramienta, ubicá el sistema en la superficie sobre la que realmente corre. La evaluación no es un solo producto — como el grounding y el prompting antes que ella, las superficies se componen, elegidas según dónde corre el sistema, nunca bandos rivales entre los que elegís (principio 7). El hilo conductor que cada Style Guide de este catálogo invoca — eval en cada cambio — se sostiene idéntico en las tres; solo difiere el herramental. Hacé coincidir la situación con la superficie:

El sistema es…	A qué recurrís	Por qué
Un agente Agentforce dentro del modelo de seguridad de Salesforce	Agentforce Testing Center (pre-release) + Agentforce Observability (en producción)	Lo evaluás donde vive. Testing Center corre casos contra el agente antes del release; Observability exporta los traces de producción — turnos, llamadas al LLM, acciones y metric scores — en OpenTelemetry (OTLP) hacia Data 360 o cualquier collector. La eval hereda el modelo de seguridad de la plataforma y queda al lado de los datos sobre los que el agente actúa.
Un sistema Claude o LangGraph corriendo off-platform	LangSmith (datasets + eval offline + online sobre traces) — con Claude como el judge adentro	El loop de eval del agente off-platform y su monitoreo de producción viven en un solo lugar: datasets de ejemplos con reference outputs, una corrida offline antes de sacar, y scoring online sobre traces en vivo. El modelo judge es Claude; el harness a su alrededor es LangSmith.
La capa del modelo, sin importar el harness	Las herramientas de eval de Anthropic + el Console Evaluation tool	Cuando calificás el comportamiento crudo del modelo — un cambio de prompt, un swap de modelo — evaluás contra el loop de Anthropic de definir-criterios-y-después-calificar, con la pestaña Evaluate de la Console comparando dos versiones de prompt lado a lado. Esto califica al modelo independiente de dónde se embebe después.

No elegís una superficie y le jurás lealtad. Un agente con grounding sobre Data 360 y orquestado off-platform podría testearse en Testing Center, calificarse en la capa del modelo con un judge Claude, y trazarse en LangSmith — cada superficie haciendo la parte para la que está hecha. La habilidad es componerlas al sistema que realmente construiste. La profundidad de cada superficie es una página hermana: Agentforce testing y observability para la plataforma, tracing y monitoreo para el trace del que depende el lado online.

Offline y online: antes de sacar, y después

La evaluación pasa en dos lugares, y responden preguntas distintas. Ambos pertenecen a un sistema maduro — no son una elección entre, se componen (principio 11 — no podés evaluar lo que no podés reproducir). Salteá el primero y sacás a ciegas; salteá el segundo y un cliente te avisa del deterioro.

	Offline	Online
Corre	Antes de sacar	Después de sacar
Contra	Un eval set congelado con respuestas conocidas	Traces de producción en vivo, sin respuesta de referencia
La pregunta	¿Es seguro sacar este cambio?	¿El sistema sacado sigue funcionando ahora?
Calificador	Compara la salida contra el ground truth	Sin referencia — juzga la respuesta en vivo por sus propias propiedades
Atrapa	Una regresión, antes de que un usuario la vea	El deterioro silencioso que un set congelado no puede contener

La división honesta del trabajo: offline prueba que un cambio es seguro de sacar; online prueba que se mantuvo bien una vez sacado. Una eval offline en verde es necesaria y no suficiente — producción corre sobre una distribución que vos no curaste, y un sistema que pasa la suite offline con honores igual puede deteriorarse en vivo. Mirá qué es la evaluación para el loop detrás de ambas, y tracing y monitoreo para el trace sobre el que corre el lado online.

Cómo calificar: determinista, judge o humano

Cada caso necesita una forma de convertir una salida en un score. No hay un solo calificador para un set entero — elegís el método que encaja con la forma de cada caso, y un eval set rutinariamente usa varios. La regla es una línea: usá el calificador más barato que pueda expresar el criterio. Determinista donde la respuesta es exacta, un modelo donde necesita juicio que podés especificar en una rúbrica, un humano donde necesita juicio que no podés.

Método	Bueno para	Costo
Métrica determinista	Respuestas tajantes que una regla puede expresar — una categoría, un campo, JSON válido, un número en rango, una frase requerida presente	El más barato, el más rápido, perfectamente repetible. Su límite es el matiz: chequea una coincidencia, no si la prosa es buena.
LLM-as-judge	Salida abierta que una regla no alcanza — tono, coherencia, fidelidad a una fuente — calificada contra una rúbrica que vos escribís	Barato y escalable, pero el judge es él mismo un modelo que hay que calibrar antes de confiar en él. Un judge que no chequeaste es un número que decidiste creer.
Humano	La fuente de verdad contra la que se validan los otros dos — armar el golden set, calibrar un judge, dirimir casos genuinamente ambiguos	La calidad más alta, el costo más alto. Gastalo donde se gana su lugar; nunca el método que escalás a miles de corridas.

La guía de Anthropic ordena los métodos por exactamente este intercambio — code-based es el más rápido y confiable pero "lacks nuance for more complex judgements"; la calificación humana es la más flexible y de mayor calidad pero "slow and expensive"; la calificación LLM-based es "fast and flexible, scalable and suitable for complex judgement". La profundidad de armar cada uno bien vive en eval datasets y métricas (un método por caso) y LLM-as-judge (el caso calificado por modelo, y la calibración que lo hace confiable). Elegí el judge más barato que realmente pueda responder la pregunta que este caso hace — y mantené el juicio humano debajo, porque los otros dos son solo tan confiables como el ground truth que una persona estableció.

La compuerta "eval en cada cambio"

Esta es la página que le da a la disciplina su hogar. Cada otro Style Guide de este catálogo termina una regla con "eval en cada cambio" y apunta acá — esto es a lo que apuntan. Antes de que un cambio de prompt, modelo, agente, retriever o herramienta salga, cada casilla de abajo es verdadera, o el cambio no está listo. Cada una cierra un gotcha que convirtió un dashboard en verde en un sistema que estaba en silencio peor.

Existe un set de regresión, y está held out. Hay un set de casos reales contra el que se califica el cambio — armado desde las fallas que de verdad te mordieron, no inventado en un escritorio — y ni uno de esos casos aparece en los ejemplos del prompt, en los datos de tuning, ni en nada que el sistema recupera en tiempo de corrida. Un set que se filtró en lo que el sistema aprendió mide memoria, no capacidad. (Principio 3 · gotchas 1, 6.)
Corrió sobre este cambio. El set de regresión volvió a correr automáticamente sobre esta edición — el prompt, la versión del modelo, la herramienta, el retriever — antes de que el cambio saliera, no después de que un cliente encontró la rotura. Si un cambio a cualquier parte del sistema no dispara el set, el set no es una compuerta. (Principio 3 · gotcha 6.)
El baseline se supera o se sostiene. Tenés un score registrado de la versión que estás reemplazando, y este cambio puntúa al menos tan bien sobre casos reales — no solo se ve mejor en el único input que probaste. "Mejor" sin un antes medido es una sensación, y el set es lo bastante grande para que unos pocos casos para un lado u otro no muevan el veredicto. (Principio 3 · gotchas 4, 5.)
El judge está calibrado. Si un LLM-as-judge produjo alguno de estos scores, se chequeó contra labels humanos sobre una muestra primero, se ancló a una rúbrica explícita, se le pidió razonar antes de puntuar, y se calificó con un modelo distinto al que está bajo prueba. Un judge sin calibrar califica por largo y por orden, y nunca lo verías desde adentro del score. (Principio 4 · gotcha 3.)
El eval set está versionado. El set está fijado como código, y cada score registra la versión contra la que corrió, para que el número del mes pasado y el de este mes sean realmente comparables. Una regla cuyas marcas se mueven no puede detectar el cambio — la única cosa para la que existe. (Principio 11 · gotcha 9.)
El monitoreo online está prendido. Los traces del sistema sacado están puntuados, no solo recolectados — métricas y juicios adjuntos para que una caída de calidad dispare una alerta en lugar de esperar un pico de soporte. Offline despejó el cambio; online confirma que se mantuvo bien contra tráfico que el set nunca contuvo. (Principio 11 · gotchas 7, 10.)

Si alguna casilla está sin marcar, el cambio no está listo — y una falla de evaluación se ve exactamente como una que pasa hasta que actuás sobre el número. Mirá debugging de evals para encontrar qué parte de la medición mintió cuando el score y la realidad no coinciden.

Patrones a preferir

Medir, no muestrear — convertí "se veía bien en tres intentos" en un score sobre un set real con una rúbrica; una muestra de tres que vos elegiste es una impresión, no un test. (Principio 3 · gotcha 8.)
El calificador más barato que encaje — determinista donde la respuesta es exacta, un judge donde necesita juicio especificable, un humano donde no; no le pagues a un modelo para chequear lo que == puede. (Principio 4 · gotcha 3.)
Eval set desde fallas reales — los primeros diez casos que te mordieron en testing valen más que cien sintéticos; surtí el set deliberadamente con los bordes, porque los casos que dejás afuera rompen primero. (Principio 3 · gotcha 6.)
Medir sobre más de un eje — emparejá la fidelidad de la tarea con un chequeo separado de seguridad o latencia para que ningún número solo se pueda gamear aislado; una métrica optimizada sola sube abandonando el objetivo. (Principio 3 · gotcha 2.)
Calibrar el judge antes de confiar en él — chequeá un judge modelo contra labels humanos sobre una muestra, anclalo a una rúbrica, calificá con un modelo distinto; solo un judge calibrado es evaluación en lugar de un número que decidiste creer. (Principio 4 · gotcha 3.)
Puntuar los traces, no solo guardarlos — adjuntá métricas al stream de producción para que un deterioro dispare una alerta; logs crudos sin nada calculado encima son material forense, no un monitor. (Principio 11 · gotcha 10.)

Patrones a rechazar

Sacar un cambio sin puntuar — "funcionó en tres intentos" es una sensación, y la regresión sale en silencio junto al arreglo; cambiá una cosa, puntuala contra el set, quedate con lo que gana. (Gotcha 8 · principio 3.)
Reclamar "mejor" sin baseline — una mejora que nadie midió es un release que no podés defender, y tres sprints después nadie puede decir si el sistema está mejor o peor que donde empezó. (Gotcha 4 · principio 3.)
Confiar en un judge sin calibrar — "calificá esto del 1 al 5" sin rúbrica califica por verbosidad y orden, y el sesgo queda horneado en cada decisión que la eval guió. (Gotcha 3 · principio 4.)
Optimizar un número hasta matarlo — hacé de una sola métrica el único objetivo y el sistema la sube por la ruta más barata, incluyendo las rutas que abandonan el objetivo que el número representaba. (Gotcha 2 · principio 3.)
Una regla que se mueve bajo la medición — editar el eval set sin una versión hace el score del mes pasado incomparable con este, así que una "regresión" puede ser solo un set más difícil. (Gotcha 9 · principio 11.)
Loguear todo, medir nada — un depósito de traces sin puntuar es un pajar que buscás a mano después de un incidente, no un monitor que te avisa antes de uno. (Gotcha 10 · principio 11.)

Cierre

Ninguna de estas reglas es difícil de aplicar de entrada; todas son caras de descubrir en vivo, porque una falla de evaluación se ve exactamente como una que pasa hasta que alguien actúa sobre el número. El hilo conductor es el que recorre cada página de esta subcategoría: una medición en la que podés confiar está held out de lo que el sistema aprendió, puntuada sobre más de un eje, juzgada por un judge calibrado, comparada contra un baseline, dimensionada para que el ruido no la mueva, versionada para que se mantenga comparable, y adjunta a los traces que vigila — o es un número que se ve como prueba y miente, lo cual es peor que ningún número, porque sacás sobre él. El eval set es la red de regresión de la que cuelgan los trabajos de agentes, grounding y prompting; un agujero en esa red no es local a la evaluación, es un agujero debajo de todo lo de aguas arriba. El principio 3, tomado en serio: si no podés evaluarlo, no podés sacarlo.

Si ves una regla que falta — o una de estas reglas siendo violada en nuestro trabajo público — escribí a hello@wearecleon.com. La agregamos, o la arreglamos y lo decimos.

Evaluation gotchas — las diez maneras en que una medición miente que este Style Guide está diseñado para prevenir
What is evaluation — el loop de eval, offline versus online, y el vocabulario detrás de la primera decisión
Eval datasets and metrics — el test set como spec de producto, y un método de calificación por caso
LLM-as-judge — calificar salida abierta, y la calibración detrás de "confiar en un judge"
Agentforce testing and observability — la superficie de plataforma de la tabla de la primera decisión
Tracing and monitoring — el trace sobre el que corre la mitad online de la compuerta
Debugging evals — encontrar qué parte de la medición mintió cuando score y realidad no coinciden
Agent Style Guide — el ancla del lado del agente cuyos cambios califica esta compuerta
Grounding Style Guide — el ancla del lado del retrieval cuyos cambios califica esta compuerta
Prompting Style Guide — el ancla del lado del prompt cuyo "eval en cada cambio" apunta acá
AI Engineering principles — las meta-reglas que estas particularidades operativizan
Marketing Cloud AI Style Guide — la decisión de qué-superficie, una capa más afuera

Reference: