En el módulo 10 montamos el stack completo y lo dejamos corriendo en CI. Con eso tienes una suite que protege cada cambio antes de publicarlo. Pero fíjate en el supuesto que ha sostenido los diez módulos anteriores sin que lo dijéramos en voz alta: existe un dataset con la respuesta correcta escrita al lado. Todo el aparato — el juez calibrado, las métricas de trayectoria, los umbrales — descansa sobre ese archivo curado a mano.

En producción ese supuesto se cae entero. Llegan diez mil conversaciones al día y ninguna trae la respuesta ideal adjunta. Nadie va a escribirla. El eval offline te dice si el sistema sigue igual de bueno en los casos que ya conocías; no te dice nada de los casos que nadie imaginó, que son los que están rompiendo el producto ahora mismo.

La tesis del módulo

El eval offline mide lo que sabías que había que medir; el eval online descubre lo que no sabías. Los dos son necesarios y ninguno reemplaza al otro: offline protege contra las regresiones conocidas, online descubre las categorías de falla nuevas — y la única forma de que ese descubrimiento sirva es convertirlo en casos del dataset offline. El circuito entre ambos es el módulo entero.

Qué cambia cuando pasas a producción

	Eval offline	Eval online
Datos	Dataset curado, fijo	Tráfico real, cambiante
Ground truth	Sí, escrito por un humano	No existe
Volumen	50-500 casos	Miles o millones al día
Cuándo corre	Antes de publicar (gate)	Continuo, después del hecho
Qué detecta	Regresiones en lo conocido	Fallas nuevas, deriva, casos raros
Consecuencia	Bloquea el merge	Abre un ticket, agrega un caso
Costo	Acotado y predecible	Proporcional al tráfico (por eso se muestrea)

La fila que define el módulo es la tercera. Sin ground truth, todas las métricas cambian de naturaleza: dejas de preguntar “¿acertó?” y empiezas a preguntar “¿hay indicios de que esto salió mal?”. Son preguntas distintas y se responden con instrumentos distintos.

Muestreo: no puedes juzgar todo

Si juzgas cada conversación con un LLM, el costo del eval iguala o supera al costo del producto. Con 10.000 conversaciones diarias y dos llamadas de juez cada una, son 20.000 llamadas al día solo para mirarte al espejo. Nadie hace eso. Se muestrea, y cómo se muestrea es la decisión de diseño más importante del módulo.

Muestreo aleatorio. Un porcentaje fijo del tráfico, elegido al azar. Es el único que da una estimación no sesgada de la calidad general: si tu muestra aleatoria dice 87% de respuestas aceptables, ese número describe honestamente al sistema completo. Es el termómetro. Con 1-2% del tráfico ya tienes suficiente para una tendencia diaria en un servicio con volumen.

Muestreo estratificado. Aleatorio, pero garantizando representación de segmentos que te importan y que el azar dejaría fuera. Si el 3% de tus conversaciones son del flujo de reembolsos y ese flujo es el más riesgoso, un muestreo aleatorio del 1% te va a dar casi nada de reembolsos. Estratificar significa: aleatorio dentro de cada segmento, con una cuota mínima por segmento. Segmentos típicos: por intención, por tipo de usuario, por tool usada, por idioma, por canal.

Muestreo dirigido. No es aleatorio ni pretende serlo: pesca los casos que ya huelen mal. Conversaciones con latencia alta, con reintentos de tool, con errores, con feedback negativo, con muchos turnos, con palabras de frustración, con respuestas sospechosamente cortas o largas. Es el que más bugs por peso invertido produce — y es el que no debes usar para reportar calidad general, porque por construcción está sesgado hacia lo malo.

"""Muestreo por capas para evals online.

Las tres capas conviven: la aleatoria da el número honesto, la
estratificada asegura cobertura, la dirigida caza bugs. Cada
conversación muestreada lleva la etiqueta de POR QUÉ entró, porque
mezclarlas al calcular métricas arruina las tres.
"""
import hashlib
import random

CUOTA_ESTRATO = {          # mínimo diario por segmento crítico
    "reembolso": 50,
    "reclamo_formal": 50,
    "cambio_datos": 30,
}


def muestreo_aleatorio(conv: dict, tasa: float = 0.01) -> bool:
    """Hash determinista del id: la misma conversación entra o no
    siempre igual, así el muestreo es reproducible al re-analizar."""
    h = int(hashlib.sha256(conv["id"].encode()).hexdigest()[:8], 16)
    return (h % 10_000) < tasa * 10_000


def es_sospechosa(conv: dict) -> str | None:
    """Heurísticas baratas y deterministas. Cada una devuelve el
    motivo, que después sirve para agrupar los hallazgos."""
    if conv["latencia_ms"] > 15_000:
        return "latencia_alta"
    if conv["errores_tool"] > 0:
        return "error_tool"
    if conv["turnos"] >= 6:
        return "conversacion_larga"
    if conv.get("feedback") == "negativo":
        return "pulgar_abajo"
    if conv.get("escalo_a_humano"):
        return "escalamiento"
    if len(conv["respuesta_final"]) < 40:
        return "respuesta_muy_corta"
    return None


def seleccionar(conversaciones: list[dict], tasa: float = 0.01) -> list[dict]:
    seleccion, cuotas = [], dict(CUOTA_ESTRATO)

    for c in conversaciones:
        motivo = es_sospechosa(c)
        if motivo:                                   # capa 3: dirigido
            seleccion.append({**c, "capa": "dirigido", "motivo": motivo})
        elif muestreo_aleatorio(c, tasa):            # capa 1: aleatorio
            seleccion.append({**c, "capa": "aleatorio", "motivo": None})

    # capa 2: estratificado — rellena las cuotas que el azar no cubrió
    ya = {c["id"] for c in seleccion}
    for segmento, cuota in cuotas.items():
        faltan = [c for c in conversaciones
                  if c["segmento"] == segmento and c["id"] not in ya]
        for c in random.sample(faltan, min(cuota, len(faltan))):
            seleccion.append({**c, "capa": "estratificado",
                              "motivo": segmento})
    return seleccion

Ojo: nunca mezcles las tres capas al reportar. “Nuestra calidad online es 74%” calculado sobre una muestra que incluye la capa dirigida es un número falso y alarmante — la capa dirigida está llena de casos malos a propósito. La métrica de calidad se calcula solo sobre la capa aleatoria; las otras dos alimentan el backlog de bugs, no el dashboard.

Cuánto juzgar. La respuesta práctica: empieza con 200-500 conversaciones juzgadas al día, repartidas 60% aleatorio, 20% estratificado, 20% dirigido, y ajusta según lo que encuentres. Si el juicio automático te sale casi siempre bien, baja la tasa aleatoria; si aparecen categorías nuevas de falla cada semana, súbela.

Señales sin ground truth

Con la muestra elegida, ¿cómo sabes si estuvo buena si nadie escribió la respuesta correcta? Hay tres fuentes, y su utilidad es inversa a lo obvias que parecen.

Feedback explícito: el pulgar que casi nadie aprieta

El pulgar arriba/abajo es la primera idea de todo el mundo y la de menor rendimiento. Tres problemas, en orden de gravedad:

Tasa de respuesta ridícula. En la mayoría de los productos conversacionales el porcentaje de mensajes que reciben feedback explícito está en el rango de unos pocos por ciento. La enorme mayoría de las interacciones no genera ninguna señal.
Sesgo de selección brutal. Los que responden no son una muestra: son los muy enojados y los muy encantados. La distribución del feedback explícito no se parece a la distribución de la experiencia.
Ambigüedad del “por qué”. Un pulgar abajo puede significar: la respuesta era incorrecta, era correcta pero grosera, era correcta pero larguísima, o el usuario está molesto con la empresa y le pegó al botón que tenía cerca. Sin el motivo, la señal no es accionable.

El arreglo parcial es pedir el motivo con opciones cerradas (“incorrecta / incompleta / no entendió / tono”). Sube muchísimo la utilidad de cada pulgar abajo, aunque baja aún más la tasa de respuesta. Trátalo así: el feedback explícito es un detector de casos para revisar, no una métrica de calidad. Cada pulgar abajo es un candidato a caso de dataset; el promedio de pulgares no describe a nadie.

Feedback implícito: las señales honestas

Estas son las buenas. El usuario no sabe que está evaluando, y por eso no miente.

Señal implícita	Qué indica	Cómo se detecta
Reformulación	La respuesta no sirvió; lo intenta de otro modo	Turno siguiente semánticamente similar al anterior
Abandono	Se rindió	Última respuesta sin turno siguiente y sin cierre
Escalamiento a humano	El agente no resolvió	Se disparó la tool de derivación o el usuario la pidió
Repetición de la pregunta	No entendió o no le creyó	Misma intención repetida en la sesión
Corrección explícita	El agente se equivocó y el usuario lo sabe	”no, yo dije…”, “eso no es”, “te equivocas”
Copia de la respuesta	La respuesta sirvió (señal positiva)	Evento de copiado en la interfaz
Tiempo hasta el turno siguiente	Muy corto: no la leyó, la descartó	Delta de timestamps
Cierre satisfecho	Resolvió (señal positiva)	“gracias”, “perfecto”, y fin de la sesión

La reformulación es la reina de estas señales. Es frecuente, es barata de detectar y su interpretación es casi inequívoca: si el usuario vuelve a preguntar lo mismo con otras palabras, tu respuesta anterior no le sirvió. No necesitas un juez para saberlo.

"""Detección de reformulación: la señal implícita de mejor rendimiento.

No usa LLM. Compara la similitud semántica entre turnos consecutivos
del usuario: alto parecido + poco tiempo entre ambos = la respuesta
intermedia no sirvió.
"""
import numpy as np


def coseno(a, b) -> float:
    return float(np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b)))


def detectar_reformulaciones(conv: dict, embed) -> list[int]:
    """Devuelve los índices de turno donde el usuario reformuló.
    `embed(texto)` devuelve el vector de embedding del texto."""
    turnos = [t for t in conv["turnos"] if t["rol"] == "usuario"]
    vectores = [embed(t["texto"]) for t in turnos]
    marcados = []

    for i in range(1, len(turnos)):
        sim = coseno(vectores[i - 1], vectores[i])
        delta_s = turnos[i]["ts"] - turnos[i - 1]["ts"]
        # Umbrales a calibrar con tus propios datos: mirar 50
        # conversaciones a mano y ajustar hasta que no haya
        # falsos positivos obvios.
        if sim > 0.85 and delta_s < 90:
            marcados.append(i)
    return marcados


def tasa_reformulacion(conversaciones: list[dict], embed) -> float:
    """La métrica online más barata y más honesta que existe.
    Sube cuando el sistema empeora, sin que nadie tenga que opinar."""
    con_reform = sum(
        1 for c in conversaciones if detectar_reformulaciones(c, embed)
    )
    return con_reform / len(conversaciones)

La tasa_reformulacion es una de esas métricas que vale más que un dashboard entero. No cuesta llamadas a un LLM, no tiene sesgo de auto-preferencia, no depende de que nadie opine, y se mueve cuando el sistema se degrada. Es la métrica que yo pondría primero si tuviera que elegir una sola señal online.

Juicio automático de la muestra

La tercera fuente es el juez del módulo 4, aplicado a la muestra. La diferencia con el uso offline es que no hay respuesta ideal contra qué comparar, así que las métricas que dependen de referencia (answer correctness) desaparecen. Sobreviven las que se calculan solo con lo que hay en la traza:

Fidelidad al contexto — ¿la respuesta se deduce de lo que devolvieron las tools o el retrieval? No necesita referencia, solo la traza.
Relevancia a la pregunta — ¿contesta lo que se preguntó?
Cumplimiento de reglas de negocio — ¿prometió algo que no debía? Es una rúbrica, no una comparación.
Seguridad y tono — las mismas rúbricas del módulo 9.
Resolución aparente — ¿la conversación terminó resolviendo?

Cuidado: un juez calibrado offline no está automáticamente calibrado online. Lo calibraste contra casos curados, bien redactados, del dataset; el tráfico real trae mensajes a medias, sin tildes, con contexto implícito y con temas que el dataset no cubría. Antes de creerle al juez sobre producción, recalíbralo: toma 30 conversaciones reales, que dos personas las puntúen a ciegas y mide la correlación. Es media jornada y evita meses de perseguir un número que no significa lo que crees.

El circuito completo: la idea central del módulo

Todo lo anterior es plomería. Esto es el módulo:

        EL CIRCUITO DE EVALS ONLINE ── OFFLINE

  ┌──────────────────────────────────────────────┐
  │              PRODUCCIÓN                      │
  │   tráfico real · trazas · tool calls         │
  └───────────────────┬──────────────────────────┘
                      │ 1. instrumentar
                      ▼
            ┌───────────────────┐
            │     MUESTREO      │
            │ aleatorio 60%     │
            │ estratificado 20% │
            │ dirigido 20%      │
            └─────────┬─────────┘
                      │ 2. seleccionar
                      ▼
            ┌───────────────────┐
            │      JUICIO       │
            │ señales implícit. │
            │ + juez + humano   │
            └─────────┬─────────┘
                      │ 3. detectar fallas
                      ▼
            ┌───────────────────┐     ┌───────────┐
            │  TRIAGE SEMANAL   │ ──► │ arreglar  │
            │ agrupar por causa │     │  el bug   │
            └─────────┬─────────┘     └─────┬─────┘
                      │ 4. promover         │
                      ▼                     │
            ┌───────────────────┐           │
            │  GOLDEN DATASET   │           │
            │ + casos nuevos    │           │
            └─────────┬─────────┘           │
                      │ 5. proteger         │
                      ▼                     │
            ┌───────────────────┐           │
            │ GATE OFFLINE (CI) │ ◄─────────┘
            │ bloquea el merge  │
            └─────────┬─────────┘
                      │ 6. publicar
                      └───────────► vuelve a PRODUCCIÓN

El paso 4 es donde muere la mayoría de los programas de evals. Los equipos montan las cinco primeras cajas, miran los hallazgos en una reunión, arreglan el bug… y no promueven el caso al dataset. Resultado: seis meses después, un refactor reintroduce exactamente la misma falla, y como nunca quedó un caso que la cubriera, vuelve a producción. El circuito sin el paso 4 no es un circuito: es una línea recta que se apaga.

La regla que hay que escribir en el proceso del equipo, con esas palabras: ninguna falla de producción se cierra sin un caso en el golden dataset que la reproduzca. Es el equivalente exacto del test de regresión en software, y por alguna razón cuesta más instalarlo cuando el sistema es un LLM.

Guardrails en línea vs evals asíncronos

Hay una tentación obvia: si tengo un juez que detecta respuestas malas, ¿por qué no lo pongo antes de entregar la respuesta y bloqueo las malas? La respuesta es la latencia, y conviene tenerla clara porque define dos categorías de defensa distintas.

Un juez LLM tarda entre cientos de milisegundos y varios segundos. Ponerlo en el camino crítico de cada respuesta significa sumar ese tiempo a todas las interacciones, incluidas las 97% que estaban perfectas. En un chat de soporte eso puede ser tolerable; en voz, es inviable.

	Guardrail en línea	Eval asíncrono
Cuándo corre	Antes de entregar la respuesta	Después, sobre la traza guardada
Presupuesto de latencia	Decenas de ms a ~1 s	Ilimitado
Puede bloquear	Sí	No: ya se entregó
Cobertura	100% del tráfico	Una muestra
Técnicas viables	Regex, listas, clasificador chico, reglas de tool	Juez LLM, análisis de trayectoria, revisión humana
Qué detecta bien	Patrones conocidos y duros	Fallas sutiles, categorías nuevas

Qué sí se puede bloquear en línea, porque cuesta milisegundos:

PII en la salida — regex de RUT, tarjeta, correo, teléfono. Determinista y rápido.
Destinos de tools fuera de la allowlist — se valida en la tool misma, no cuesta nada.
Tools destructivas sin confirmación — es una regla, no un modelo.
Listas de términos prohibidos — precios, promesas, nombres de competidores.
Formato de salida inválido — JSON que no parsea, campos faltantes.
Clasificador pequeño de toxicidad o de injection — un modelo chico dedicado corre en decenas de milisegundos.

Qué solo se puede revisar después, porque requiere criterio:

Si la respuesta era factualmente correcta dado el contexto.
Si la trayectoria de tools fue eficiente o dio vueltas.
Si el tono fue apropiado para ese cliente específico.
Si apareció una categoría nueva de pregunta que el sistema no cubre.

La arquitectura práctica junta las dos: guardrails duros y baratos en el 100% del tráfico, evals con juez de forma asíncrona sobre la muestra. Y una nota operativa que se olvida: cuando un guardrail en línea bloquea algo, eso también es un evento a medir. Una tasa de bloqueo que sube de golpe significa que el sistema empezó a intentar algo que no hacía antes, o que el guardrail se volvió demasiado estricto y está rompiendo casos legítimos.

Shadow evaluation: probar sin exponer

La shadow evaluation (evaluación en sombra) es la técnica más subestimada de este módulo. La idea: la versión nueva del sistema recibe el tráfico real, procesa cada request y produce su respuesta — pero esa respuesta nunca llega al usuario. Se guarda para compararla contra la que sí se entregó.

              SHADOW EVALUATION

  request ──► ┌──────────────┐
              │   ROUTER     │
              └──┬────────┬──┘
                 │        │ copia del request
                 ▼        ▼
       ┌──────────────┐  ┌──────────────┐
       │ VERSIÓN v3   │  │ VERSIÓN v4   │
       │ (producción) │  │  (sombra)    │
       └──────┬───────┘  └──────┬───────┘
              │                 │
              ▼                 ▼
       ┌──────────────┐  ┌──────────────┐
       │ respuesta al │  │ respuesta al │
       │   USUARIO    │  │  REGISTRO    │
       └──────────────┘  └──────┬───────┘
                                │
              ┌─────────────────┘
              ▼
   ┌──────────────────────────┐
   │ comparar v3 vs v4 sobre  │
   │ el MISMO tráfico real    │
   └──────────────────────────┘

  Riesgo para el usuario: cero. Costo: doble inferencia.

Qué te da que un eval offline no puede darte: la comparación ocurre sobre la distribución real de entradas, no sobre tu dataset curado. Descubres que la versión nueva es peor justo en el tipo de pregunta que representa el 30% de tu tráfico y que en el dataset solo tenía tres casos.

Cuándo usarla: cambios grandes de arquitectura (cambiar de modelo, reescribir el prompt entero, agregar un paso de retrieval), donde el dataset offline no te da confianza suficiente. Cuándo no: cambios menores, porque el costo es literalmente el doble de inferencia sobre el tráfico que le espejees.

Precauciones que se olvidan. En sombra el agente no debe ejecutar tools con efecto de escritura. Si el sistema en sombra manda correos, crea pedidos o hace cobros, no es una sombra: es un segundo sistema en producción haciendo cosas reales por duplicado. Las tools de escritura se mockean o se apuntan a un entorno aislado; las de lectura pueden ser reales. Es el error que convierte un experimento seguro en un incidente.

A/B tests de modelos y prompts

El A/B sí expone: reparte usuarios reales entre dos versiones y compara resultados. Es la única forma de medir el efecto sobre métricas de negocio (resolución, escalamiento, conversión), que ningún juez puede estimar.

Y aquí se conecta directamente con la estadística del módulo 8. Los mismos principios, con dos diferencias que cambian el cálculo:

El tamaño de muestra deja de ser el problema. Offline peleabas por llegar a 200 casos; en producción tienes miles al día. Eso te permite detectar diferencias chicas — pero también significa que vas a detectar diferencias chicas que no le importan a nadie. Con 50.000 conversaciones por brazo, una mejora de 0.4 puntos porcentuales sale estadísticamente significativa y es completamente irrelevante para el negocio. Define antes de correr el test cuál es el efecto mínimo que justificaría el cambio, y no celebres nada bajo esa línea.

La asignación tiene que ser por usuario, no por request. Si asignas al azar cada mensaje, el mismo usuario recibe respuestas de dos sistemas distintos dentro de una conversación, con estilos y memorias distintos. Se asigna por usuario o por sesión, con hash determinista del identificador, y se mantiene fijo durante todo el experimento.

Elemento del A/B	Regla	Por qué
Unidad de asignación	Usuario o sesión, hash determinista	Un usuario no puede saltar entre versiones
Métrica primaria	Una sola, definida antes	Mirar diez métricas garantiza un falso positivo
Efecto mínimo relevante	Definido antes de correr	Con volumen alto todo sale significativo
Duración mínima	Ciclos completos (semanas enteras)	El tráfico de lunes no se parece al de sábado
Métricas de guardia	Costo, latencia p95, tasa de escalamiento	Una mejora de calidad que duplica el costo no es mejora
Criterio de corte	Definido antes; nada de peek-and-stop	Mirar hasta que dé significativo es hacer trampa

Cuidado con parar el test cuando el resultado te gusta. Revisar los resultados a diario y detener el experimento el primer día que sale significativo es la forma más eficiente de convencerte de cosas falsas. Con suficientes miradas, un test sin ningún efecto real cruza el umbral de significancia en algún momento. Fija la duración y el criterio de corte antes de partir, y respétalos.

La conexión con el monitoreo clásico

Si vienes del mundo de MLOps, buena parte de esto te suena, y con razón: es el mismo esqueleto de monitoreo de modelos — capa operativa, capa de datos, capa de modelo — aplicado a un sistema generativo. No lo repetimos. Lo que sí conviene marcar es dónde el paralelo se rompe.

En un modelo tabular, el drift se mide comparando distribuciones de features numéricas contra una referencia, con tests como KS o PSI. Las features son columnas, la referencia es el set de entrenamiento, y el test estadístico es directo. En un agente LLM no hay columnas: la entrada es texto libre y el “modelo” no lo entrenaste tú. La deriva llega por tres puertas distintas:

Deriva de entrada — los usuarios preguntan cosas nuevas. Se detecta agrupando embeddings de las consultas por semana y viendo aparecer clusters que antes no existían. Es lo más cercano al data drift clásico.
Deriva del proveedor — el modelo cambió por debajo sin que tocaras nada. Se detecta re-corriendo el golden dataset offline sin cambiar una línea, con cadencia fija. Si el número se mueve solo, ya sabes por qué.
Deriva del mundo — el negocio cambió (precios, políticas, catálogo) y el sistema sigue respondiendo lo de antes. Ningún test estadístico lo detecta: se detecta con casos del dataset que el negocio mantiene al día.

La segunda es la específica de este mundo y la que más sorprende a los equipos. Un modelo tabular no cambia si no lo reentrenas; un modelo de proveedor sí. Fijar versiones con sufijo de fecha en lugar de alias flotantes tipo “latest” es la mitigación barata, donde el proveedor lo permita.

Errores comunes

Confiar en el pulgar arriba/abajo como métrica de calidad. Lo aprieta una fracción mínima de usuarios, y los que lo aprietan son los extremos. Sirve para pescar casos a revisar, no para describir el sistema.
Mezclar el muestreo dirigido con el aleatorio al calcular métricas. El dirigido está lleno de casos malos a propósito; mezclarlos produce un número catastrófico y falso. La métrica sale solo de la capa aleatoria.
No cerrar el circuito hacia el dataset. Arreglar el bug sin promover el caso garantiza que la falla vuelva. Ninguna falla de producción se cierra sin su caso de regresión.
Poner el juez LLM en el camino crítico. Sumas segundos al 100% del tráfico para atrapar el 3% malo. Guardrails baratos en línea, juez asíncrono sobre la muestra.
Shadow evaluation con tools de escritura reales. No es una sombra: es un segundo sistema haciendo cosas de verdad. Las tools con efecto se mockean o van a un entorno aislado.
Parar el A/B cuando el resultado gusta. Mirar hasta que dé significativo fabrica conclusiones. Duración y criterio de corte se fijan antes.
Usar el juez offline en producción sin recalibrar. El tráfico real no se parece a tu dataset curado. Media jornada de recalibración contra 30 conversaciones reales antes de creerle.
Instrumentar solo la respuesta final. Sin la traza de tools y del retrieval, el juicio online no puede evaluar fidelidad ni trayectoria — que es donde están las fallas interesantes.

La frase para llevarse

“El eval offline te protege de los errores que ya conoces; el eval online te presenta los que todavía no. Si el segundo no alimenta al primero, estás descubriendo el mismo bug para siempre.”

Qué viene

Módulo 12, el cierre del curso: hacer que el programa de evals sobreviva al primer trimestre. Tienes todas las piezas — datasets, jueces, trayectorias, seguridad, frameworks, producción — y ahora viene el problema que se lleva a la mayoría: los programas de evals no mueren por razones técnicas. Mueren porque nadie es dueño del dataset, porque el costo por corrida se dispara y alguien decide correr menos, y porque los umbrales se relajan de a poco hasta ser decorativos. Vamos a ver la propiedad, el presupuesto real y cómo bajarlo, los gates por criticidad, la cadencia de qué corre cuándo, y cómo reportar a negocio sin métricas de adorno.

Evals — Módulo 11: evaluar en producción, con tráfico real