A bordoMapa de misión
Cuando cambiás algo en una cadena LLM (prompt nuevo, modelo distinto, paso reordenado), ¿cómo sabés si el cambio es bueno? La respuesta natural es "lo despliego y miro las métricas". El problema: comparar el "antes" con el "después" mide mucho más que tu cambio.
Cualquiera de esos puede explicar la "mejora" o "empeora" que ves, sin que tu cambio haya hecho nada.
Dividís el tráfico en dos grupos simultáneos:
Ambos corren al mismo tiempo, con los mismos usuarios distribuidos por hash determinístico. La única diferencia entre los dos grupos es la versión de tu cadena. Cualquier diferencia en métricas se debe a tu cambio, no al ruido del mundo.
arm = hash(user_id || trace_id) % 2 == 0 ? 'control' : 'variant'Sin determinismo, un usuario podría ver respuestas inconsistentes (a veces control, a veces variant), lo cual deteriora la experiencia y contamina las métricas con varianza no-explicada.
Para detectar una mejora del 5% en accuracy con confianza estadística, típicamente necesitás miles de eventos por brazo. Para detectar una mejora del 1%, decenas de miles. El A/B con 30 eventos no te dice nada útil.
Definí antes de ver resultados qué vas a medir y qué umbral cuenta como "ganadora". Si las decidís después, vas a encontrar la métrica que confirma lo que ya querés creer. Esto se llama p-hacking y arruina A/Bs serios.
| Métrica | Cómo medirla |
|---|---|
| Eval pass rate | Eval set corriendo sobre cada brazo, % que pasa |
| Latencia p50/p95 | Trace duration_ms, percentil 50 y 95 |
| Costo medio por request | Sumar cost_usd de spans, promediar |
| Tasa de degradación | % de traces con status partial |
| Satisfaction (proxy) | Thumbs up/down del usuario, follow-up rate |
Eval offline mide el techo de calidad (¿el cambio podría ser mejor?). A/B mide el comportamiento real (¿el cambio realmente es mejor con usuarios reales?). Los dos son necesarios; ninguno reemplaza al otro.
A la derecha, dos estrategias para evaluar el mismo cambio en una cadena. Elegí la que vas a usar en producción.