En el módulo 1 quedó claro que un eval mide qué tan buena es la salida sobre muchos casos. Lo que dejamos abierto es la palabra más importante de esa frase: buena. Ahora aparece el problema de verdad, y es que casi nadie lo enfrenta. Le preguntas a un equipo qué quiere de su agente y la respuesta es “que funcione bien”, “que sea útil”, “que no invente”. Ninguna de esas tres frases se puede medir, y como no se puede medir, cada persona del equipo tiene en la cabeza una definición distinta de éxito y nadie lo sabe hasta que se pelean en una reunión de revisión. Este módulo es el trabajo de traducción: de esas frases a una ficha con números y umbrales.

La tesis del módulo

Un eval nunca es mejor que la definición de éxito que tiene detrás. Puedes tener el juez más sofisticado, el dataset más grande y el framework más caro: si “bueno” no está escrito en criterios verificables antes de medir, estás automatizando una opinión.

Por qué esto es tan difícil (y por eso se salta)

Definir el éxito es aburrido, no tiene código, y obliga a tomar decisiones incómodas delante de otras personas. Es exactamente por eso que se salta. Tres razones concretas por las que cuesta:

Es un trabajo de negocio disfrazado de trabajo técnico. Quién decide si “el agente respondió bien” no es el ingeniero: es quien conoce el dominio. El ingeniero sabe medir; el negocio sabe qué es correcto. La traducción entre los dos es un contrato, y es incómodo negociar contratos.

Obliga a admitir trade-offs. “Que nunca se equivoque y que responda al tiro y que sea barato” son tres deseos que compiten. Escribir la ficha te fuerza a decir cuál cede.

Expone criterios implícitos. Todo dominio tiene reglas que nadie verbaliza porque son “obvias” — hasta que el agente las rompe y alguien dice “¡pero obviamente no debía ofrecer horas en feriado!”. Esas reglas implícitas son la principal fuente de fallas en producción, y el único momento en que salen a la luz es cuando alguien se sienta a escribir qué significa “bien”.

Paso 1: descomponer la tarea vaga

La técnica es simple y mecánica: toma la frase vaga y pregúntale “¿cómo lo verificarías tú, mirando una sola conversación?” hasta que la respuesta sea algo que puedas comprobar sin discutir.

Ejemplo con “el agente de soporte debe funcionar bien”:

        DESCOMPOSICIÓN DE UNA TAREA VAGA

  "que funcione bien"
        │
        ├──► ¿resuelve el problema?
        │       ├── da la información correcta
        │       └── ejecuta la acción correcta
        │
        ├──► ¿es confiable?
        │       ├── no inventa datos
        │       ├── no promete lo que no controla
        │       └── deriva a humano cuando no sabe
        │
        ├──► ¿es adecuado?
        │       ├── tono de la marca
        │       └── largo apropiado al canal
        │
        └──► ¿es usable?
                ├── responde a tiempo
                └── cuesta lo que puede costar

  Regla de corte: bajas hasta que una persona
  distinta a ti verifique la hoja SIN preguntar.

Ese último renglón es el criterio de parada. Si dos personas leen el criterio y pueden aplicarlo a la misma conversación llegando al mismo veredicto, ya está lo bastante descompuesto. Si necesitan preguntarse cosas entre ellas, todavía es vago.

Un criterio bien escrito tiene tres propiedades:

Es verificable sobre una salida concreta, no sobre “el sistema en general”.
Es binario o graduado con niveles definidos, no una impresión.
Tiene un dueño: alguien que puede decidir en caso de duda.

Criterio vago	Criterio verificable
”Que no invente”	Toda cifra, fecha o política citada aparece en el contexto recuperado
”Que sea útil”	La respuesta contiene el dato pedido o una derivación explícita
”Buen tono”	Trata de usted, no usa emojis, no promete descuentos
”Rápido”	Primera respuesta visible en menos de 3 s en el p95
”Que sepa cuándo no sabe”	Ante pregunta fuera de alcance, deriva y no improvisa

Paso 2: escribir la rúbrica

Una rúbrica es la definición escrita de qué significa cada nivel de puntaje. Es el documento que convierte “califica del 1 al 5” en algo reproducible.

El error universal es pedir “del 1 al 5 qué tan buena es la respuesta”. Ese pedido tiene un problema fatal: el 3 no significa nada. No significa lo mismo para ti que para mí, ni para ti hoy que para ti el viernes a las 7 de la tarde. Una escala sin descripciones no es una escala, es una encuesta de humor.

La rúbrica correcta describe cada nivel con una condición observable. Compara:

Rúbrica mala:

5 = excelente
4 = buena
3 = aceptable
2 = mala
1 = pésima

Rúbrica utilizable:

5 = Responde exactamente lo preguntado, cada dato
    citado aparece en el contexto, y confirma los
    datos del cliente antes de actuar.
4 = Responde lo preguntado y todo es verificable,
    pero omite un matiz relevante o no confirma.
3 = Responde parcialmente: falta una parte de lo
    preguntado, sin errores factuales.
2 = No responde lo preguntado, o responde con un
    dato que no está en el contexto (sin dañar).
1 = Afirma algo falso, promete lo que la empresa
    no controla, o entrega datos de otro cliente.

La diferencia práctica: con la segunda, dos personas que puntúan la misma respuesta llegan al mismo número la mayor parte del tiempo. Con la primera, no. Y esa concordancia es literalmente medible — lo veremos en el módulo 4 con el acuerdo inter-anotador.

Tres reglas para escribir niveles que funcionen:

Los extremos primero. Escribe el 5 y el 1 antes que nada: son los más fáciles de describir y anclan la escala.
Cada nivel se distingue por UNA cosa. Si el salto de 4 a 3 depende de dos condiciones a la vez, vas a tener empates irresolubles.
Menos niveles es mejor. Una escala de 3 niveles bien descritos rinde más que una de 10 mal descritos. Si dudas, usa 1–5; si el criterio es de riesgo, usa binario (cumple / no cumple) y punto.

Ojo: las escalas de 0 a 10 se sienten más precisas y son peores. Nadie puede describir de forma distinguible diez niveles de calidad, así que en la práctica todos usan 7, 8 y 9, y el resto del rango queda muerto. Si vas a usar 0–10, ancla al menos tres puntos (0, 5, 10) con descripciones concretas y asume que el resultado real es una escala de tres niveles con decimales de adorno.

Paso 3: pocas métricas con consecuencias

Aquí está la regla dura del módulo, y es la que más resistencia genera: tres métricas que bloquean algo valen más que quince en un dashboard.

Que una métrica tenga consecuencia significa una cosa muy concreta y verificable: existe un umbral escrito, y cuando el número lo cruza, algo deja de pasar automáticamente. No “alguien lo revisa”. No “lo conversamos en la reunión del lunes”. Algo se detiene: el merge no entra, el deploy no sale, el rollout se pausa, se activa el rollback.

La prueba para saber si una métrica tiene consecuencia es una sola pregunta: si mañana este número baja 10 puntos, ¿qué pasa distinto sin que nadie decida nada? Si la respuesta es “nada” o “lo veríamos en el dashboard”, esa métrica es decoración. Bórrala o dale un umbral.

Métrica	Umbral	Consecuencia automática	¿Tiene consecuencia?
Tasa de resolución	≥ 0.85	El PR no mergea	Sí
Casos bloqueantes	100%	El deploy se detiene	Sí
Latencia p95	≤ 4 s	El rollout se pausa	Sí
”Satisfacción general”	—	Aparece en un gráfico	No
”Calidad del tono”	—	Se comenta si alguien lo mira	No

Por qué muchas métricas es peor que pocas, y no solo “menos eficiente”:

Diluyen la responsabilidad. Con quince métricas, cuando algo va mal siempre hay tres que están bien para citar.
Se contradicen sin resolver. Dos métricas que se mueven en direcciones opuestas y ninguna manda: la decisión vuelve a ser una opinión, con pasos extra.
Nadie las mira. Un dashboard de quince gráficos se revisa la primera semana y nunca más.
Cuestan. Cada métrica basada en juez cuesta tokens por caso y por corrida.

Cuidado: “pocas métricas” no significa “una sola”. Un sistema medido por un único número se optimiza hasta romper todo lo que ese número no mira — el agente que sube su tasa de resolución cerrando conversaciones antes de tiempo, por ejemplo. Por eso vienen los guardrails.

Métricas objetivo vs métricas guardrail

Esta distinción es la que evita el desastre anterior y casi nadie la usa explícitamente.

Métrica objetivo: la que quieres maximizar. Es la que justifica el proyecto. Suele haber una, a lo más dos. Ejemplo: tasa de resolución sin intervención humana.

Métrica guardrail (barrera de contención): la que no puede empeorar mientras persigues el objetivo. No la maximizas — le pones un piso o un techo y verificas que se respete. Ejemplo: tasa de promesas no autorizadas ≤ 0%, latencia p95 ≤ 4 s, costo por conversación ≤ US$0.05.

     OBJETIVO Y GUARDRAILS

              ▲ maximizar
              │
   ┌──────────┴──────────┐
   │   MÉTRICA OBJETIVO  │
   │  tasa de resolución │
   └──────────┬──────────┘
              │
   ─ ─ ─ ─ ─ ─┼─ ─ ─ ─ ─ ─  techo costo
   ─ ─ ─ ─ ─ ─┼─ ─ ─ ─ ─ ─  techo latencia
   ─ ─ ─ ─ ─ ─┼─ ─ ─ ─ ─ ─  piso seguridad
              │
        GUARDRAILS: no se optimizan,
        se respetan. Si uno se cruza,
        la mejora del objetivo no vale.

La regla de decisión que se deriva de esto es limpia y evita discusiones enteras: una mejora del objetivo que cruza un guardrail no es una mejora, es un cambio rechazado. No se negocia caso a caso. Si el nuevo prompt sube la resolución de 0.83 a 0.89 pero mete una promesa no autorizada en un caso, se descarta, porque el guardrail de promesas está en cero por una razón legal.

Las métricas operacionales, que siempre se olvidan

Aquí hay un patrón tan consistente que vale la pena nombrarlo: los equipos miden calidad con enorme cariño y se olvidan de lo operacional hasta que explota. Y lo operacional es la mitad de la experiencia del usuario.

Latencia. Nunca en promedio, siempre en percentiles. El percentil 50 (p50 o mediana) es el usuario típico: la mitad espera menos que eso. El p95 es el 5% más lento — y ese 5% son cientos de personas al día. El promedio esconde la cola: un sistema con p50 de 1 s y p95 de 22 s tiene un promedio bonito y usuarios furiosos. En canales conversacionales la métrica que manda es el time to first token (cuánto tarda en aparecer la primera palabra), porque el streaming hace tolerable un total largo pero no un silencio inicial.

Costo por tarea. No costo total mensual, que no permite comparar nada: costo por unidad de trabajo resuelta. Y desagregado, porque un agente gasta en el modelo principal, en las tools, en las reintentos y — detalle que se omite siempre — en el juez de los evals, que es un costo real y recurrente.

Tasa de error. Los fallos duros: timeouts, excepciones, tool calls que revientan, respuestas que no parsean. Es la métrica más barata de todas porque sale de los logs sin llamar a ningún LLM, y por eso es la primera que deberías tener.

Tasa de abandono. Cuántos usuarios se van sin cerrar la tarea. Es la métrica de calidad más honesta que existe, porque no depende de ningún juez ni de ninguna rúbrica: es el usuario votando con los pies.

Tasa de escalamiento a humano. Cuidado con esta, porque es ambigua a propósito: subir puede ser bueno (el agente reconoce sus límites) o malo (el agente es inútil). Solo tiene sentido leída junto a la satisfacción del caso escalado.

Familia	Métrica	Cómo se obtiene	Costo de medirla
Calidad	Resolución, fidelidad, tono	Juez LLM o anotación	Alto
Operacional	Latencia p50/p95	Logs / traza	Cero
Operacional	Costo por tarea	Contador de tokens	Cero
Operacional	Tasa de error	Logs	Cero
Producto	Tasa de abandono	Analítica de sesión	Bajo
Producto	Escalamiento a humano	Evento del sistema	Cero

Mira la columna de la derecha: casi todo lo operacional es gratis. Sale de datos que tu sistema ya produce. Que se olviden no es un problema de presupuesto, es un problema de que nadie las escribió en la ficha.

Ojo: el trade-off entre calidad y operación es real y hay que decidirlo antes, no en caliente. Un modelo más grande sube la calidad y sube la latencia y el costo. Sin umbrales escritos, esa decisión se toma en una reunión donde gana quien habla más fuerte. Con la ficha, se toma sola: si el p95 se pasa del techo, no importa cuánto subió la calidad.

Ejemplo completo: de la frase a la ficha

Cerramos con el ejercicio completo. Punto de partida: “el agente de soporte del e-commerce debe funcionar bien”.

Contexto que hay que sacar antes de medir nada (esto se pregunta, no se adivina):

Canal: chat web, con streaming.
Volumen: 4.000 conversaciones al mes.
Herramientas conectadas: consulta de pedido, consulta de stock, creación de ticket.
Regla legal dura: no se comprometen fechas de despacho fuera del sistema de logística.
Presupuesto: US$200 al mes en modelo.

Descomposición acordada con negocio:

Resolver la consulta sin intervención humana.
No afirmar nada que no venga de una tool o del contexto.
Nunca comprometer fechas ni descuentos.
Derivar a humano cuando el caso está fuera de alcance.
Responder rápido y dentro del presupuesto.

La ficha de métricas resultante:

#	Métrica	Tipo	Cómo se mide	Umbral	Consecuencia si se cruza
1	Tasa de resolución	Objetivo	Juez, rúbrica 1–5, éxito si ≥ 4	≥ 0.85	El PR no mergea
2	Fidelidad factual	Guardrail	Juez: todo dato citado está en tool/contexto	≥ 0.97	El PR no mergea
3	Promesas no autorizadas	Guardrail	Regla + juez sobre 40 casos trampa	= 0	Bloqueante: deploy detenido
4	Derivación correcta	Guardrail	Determinista: evento de escalamiento vs etiqueta	≥ 0.95	El PR no mergea
5	Latencia p95	Guardrail	Traza, extremo a extremo	≤ 4 s	Rollout en pausa
6	Time to first token p95	Guardrail	Traza	≤ 1.5 s	Rollout en pausa
7	Costo por conversación	Guardrail	Tokens × precio, sin contar el juez	≤ US$0.045	Revisión antes de publicar
8	Tasa de error duro	Guardrail	Logs: excepciones y timeouts	≤ 0.5%	Alerta y rollback
9	Tasa de abandono	Observada	Analítica: sesiones sin cierre	Se reporta	Ninguna (aún)

Cinco cosas que hacen que esta ficha funcione y que conviene copiar tal cual:

Hay exactamente una métrica objetivo. La #1. Todo lo demás la limita. Eso hace que la pregunta “¿este cambio es mejor?” tenga una respuesta y no un debate.

El guardrail de riesgo legal está en cero y es bloqueante. La #3 no admite “0.98 está bastante bien”. Un caso que promete una fecha rompe la corrida completa aunque el promedio general sea excelente.

El costo por conversación se calcula contra el presupuesto real. US$200 dividido en 4.000 conversaciones da US$0.05 exactos; el umbral se puso en 0.045 para dejar margen. Un número que sale del negocio, no de la nada.

El juez se cuenta aparte. El umbral de costo excluye el costo de evaluar, porque si no, cada mejora del programa de evals se ve como una regresión del producto.

La métrica #9 no tiene consecuencia y está declarada como tal. Se observa mientras se acumula historia para saber qué valor es normal. Está bien tener métricas observadas — lo que no está bien es no marcarlas y que se confundan con las que mandan.

Con esa ficha en la mano, la pregunta “¿el agente funciona bien?” tiene una respuesta de una línea: sí, si las nueve filas están dentro de umbral en la última corrida contra el dataset vX. Eso es todo lo que este módulo quería lograr.

Errores comunes

Definir el éxito después de ver las salidas. Si escribes la rúbrica mirando lo que el agente ya hace, la rúbrica describe el sistema actual en vez de lo que necesitas. Escríbela antes, idealmente con el experto de negocio y antes de que interactúe con el bot: si primero chatea, sus expectativas se anclan a lo que vio.
Rúbricas sin descripción de niveles. “Del 1 al 5” sin decir qué es cada número produce ruido con apariencia de dato. Describe al menos el máximo, el mínimo y el punto de corte.
Una sola métrica y ningún guardrail. El sistema se optimiza hasta romper todo lo que esa métrica no mira. Objetivo más guardrails, siempre.
Métricas sin umbral. Si nadie escribió el número que separa “pasa” de “no pasa”, la discusión vuelve a ser subjetiva cada vez y el eval no sirvió de nada.
Olvidar lo operacional. Latencia, costo, errores y abandono son gratis de medir y son la mitad de la experiencia. El equipo que solo mide calidad publica un agente excelente que tarda 14 segundos.
Latencia en promedio. El promedio esconde la cola, que es justamente donde vive el usuario que se enoja. Usa p50 y p95, siempre.
Umbrales escritos en piedra. El negocio cambia — precios, políticas, canales. Los umbrales se revisan periódicamente y tienen dueño, o terminan validando el negocio de hace un año.
Quince métricas sin consecuencia. Un dashboard que nadie mira consume trabajo de mantención y no cambia ninguna decisión. Si baja y no pasa nada, no es una métrica: es un gráfico.

La frase para llevarse

“Una métrica sin umbral es un gráfico, y un umbral que no bloquea nada es una sugerencia. El programa de evals empieza el día en que un número puede detener una publicación sin que nadie tenga que dar permiso.”

Qué viene

Módulo 3: el primer eval, sin gastar un token. Con la ficha escrita ya sabes qué medir, y la sorpresa es cuánto de eso se mide gratis. Vamos a cubrir validación de esquema y JSON bien formado, cumplimiento de restricciones (largo, idioma, formato, campos obligatorios), exact match con normalización, clasificación con precision/recall/F1 y exactitud de enrutamiento — más una lista honesta de qué no usar y por qué. Y lo vamos a cerrar construyendo un runner de evals completo en unas sesenta líneas de Python sin frameworks, para que quede claro que por debajo de todas las herramientas del mercado no hay ninguna magia.

Evals — Módulo 2: traducir «que funcione bien» a algo medible