Experimentar de verdad: shadow, canary, A/B

4.1Tres puntos que quizá no son nada

Son las 18:40 de un jueves. Cambiaste el prompt de Aurora —la tienda online ficticia que es tu banco de pruebas—. Querías reducir los reembolsos fantasma que viste en el N0·L1.

Despliegas a las 9:00. A medianoche miras el dashboard. Los thumbs up del nuevo prompt suben del 71% al 74%. Tres puntos. En un día.

El instinto dice "funciona, déjalo". Tu jefe pregunta si ya lo desplegamos a todo el mundo.

Pero piensa en cuántas conversaciones miraste: unas pocas decenas. Tres puntos sobre una muestra pequeña pueden ser una mejora real. O pueden ser ruido de muestreo: el mismo prompt, otro día, daría 69% o 73% por puro azar de qué clientes escribieron.

Decidir "a ojo" con tres puntos es exactamente la vibe que el curso entero combate. La pregunta no es "¿subió?". Es "¿subió más de lo que sube el azar?".

4.2Qué vas a poder hacer

Al terminar esta lección sabrás:

• Diseñar una escalera de rollout —shadow, canary, A/B— para una mejora concreta de Aurora.
• Decidir si desplegar usando el intervalo de confianza bootstrap del delta, en lugar de comparar dos medias.
• Estratificar por tipo de request para no caer en la paradoja de Simpson.
• Distinguir qué umbrales son fórmula estándar y cuáles son heurísticos de blog.

Necesitas saber antes:

• Por qué el gate offline del N4 protege el deploy pero no decide qué versión gana en producción.
• Qué señales de prod tienes a mano: el juez online del N5·L2 y el feedback de usuario del N5·L3.
• La pirámide de coste del N2 (Husain, A.5): L1 assertions, L2 LLM-judge, L3 A/B en producción.
• Python a nivel de leer funciones y numpy básico.

Esta lección no monta toda la estadística inferencial. Construye una regla de decisión defendible para tu caso de uso, marcando con honestidad qué números son estándar y cuáles orientativos.

4.3Recupera

Antes de seguir, responde mentalmente. No mires lo de abajo hasta tener una respuesta.

1. Del N4: el gate de CI está verde tras tu cambio de prompt. ¿Por qué eso no demuestra que la nueva versión gana en producción?
2. Del N5·L2 y L3: nombra dos señales de producción que podrías usar como métrica de un experimento.
3. De la pirámide de coste del N2 (A.5): de los tres niveles L1/L2/L3, ¿cuál es el más caro y por qué se reserva "para cambios significativos"?

La respuesta a la 1: el gate offline mide regresión contra tu dataset versionado, una distribución fija que tú elegiste. No ve la distribución real de inputs de producción ni el comportamiento de usuarios reales. Pasa el gate y aun así puede perder en vivo.

La respuesta a la 3: el más caro es L3, el A/B en producción (Husain, evals, mar 2024). Cuesta más porque expone tráfico real al candidato y tarda días en acumular muestra. Por eso se reserva para cambios grandes, no para cada retoque.

4.4El concepto: de "subió" a "subió de verdad"

Esta sección tiene dos partes densas: la escalera de rollout y la decisión estadística. Lee primero la escalera entera; luego entramos en la estadística despacio, con un ejemplo numérico.

La escalera de rollout: shadow → canary → A/B

No despliegas un cambio a todo el tráfico de golpe. Subes una escalera de exposición creciente. Cada peldaño limita el daño si el candidato es peor de lo que crees.

Shadow testing (prueba en sombra): el candidato corre en paralelo al de producción sobre las mismas requests, pero su respuesta no se sirve al usuario. Comparas ambas salidas con tu juez. La analogía: un piloto en prácticas en la cabina que vuela el avión "en su cabeza" sin tocar los mandos. El límite de la analogía: el shadow sí consume cómputo real y factura, aunque no afecte al cliente.

Canary (canario, por los canarios en las minas que detectaban gas antes que los humanos): sirves el candidato a una fracción creciente del tráfico —1% → 5% → 20% → 50% → 100%, o 0,1% para casos de alto riesgo— y vigilas las métricas en cada peldaño. Si algo se degrada, paras antes de afectar a todos.

A/B testing: divides el tráfico en dos grupos —A con la versión vieja, B con la nueva— con asignación consistente por sesión (un mismo cliente ve siempre la misma versión en su conversación) y comparas la métrica entre brazos.

Marca clara y honesta: los porcentajes de rollout (1/5/20/50/100, 0,1%) son heurísticos de un blog de ingeniería tier 3 (tianpan.co, llm-gradual-rollout, abr 2026). El patrón de subir exposición por peldaños es sólido. Los números concretos son orientativos, no una ley. Ajústalos a tu tolerancia al riesgo.

Anclaje al curso: el A/B en producción es el nivel L3 de la pirámide de coste de Husain (A.5). El más caro de los tres. Por eso no lanzas un A/B por cada cambio: shadow y canary filtran lo obvio antes, barato.

La estadística: decidir con el intervalo, no con la media

Aquí está el corazón de la lección. Es común que un ingeniero competente compare dos medias —74% vs 71%— y concluya. Casi todo el mundo lo hace la primera vez. La diferencia clave: una media es un punto; no te dice cuánta incertidumbre lo rodea.

Defino el término que sostiene la decisión.

Un intervalo de confianza al 95% (95% CI) es un rango de valores compatible con tus datos. Si repitieras el experimento muchas veces, el verdadero efecto caería dentro de ese rango el 95% de las veces. La analogía: no apuntas con un láser a un número exacto, apuntas con una linterna a una zona. El límite de la analogía: el CI no dice "hay 95% de probabilidad de que el efecto esté aquí" en sentido bayesiano. Es una propiedad del procedimiento, no de este intervalo concreto.

El bootstrap es la forma de calcular ese intervalo sin asumir una distribución teórica. Remuestreas tus datos con reemplazo miles de veces, recalculas el delta cada vez y miras dónde caen los percentiles 2,5 y 97,5. La analogía: en vez de confiar en una fórmula que asume forma de campana, dejas que tus propios datos te digan cuánto varía el resultado.

La regla de decisión, con su fuente: despliega si el 95% CI bootstrap del delta pareado está por encima de 0 (futureagi.com, ab-testing-llm-prompts, 2026 — tier 4). Si el intervalo cruza 0, no despliegas todavía: el azar todavía explica el resultado. "Delta pareado" significa que comparas A y B sobre la misma request y restas. Eso reduce la varianza frente a comparar dos grupos independientes.

¿Cuántas muestras necesitas? La fórmula estándar para métricas continuas es:

n_por_brazo ≈ 16 · σ² / MDE²

donde σ es la desviación de la métrica. El MDE (Minimum Detectable Effect, efecto mínimo detectable) es la mejora más pequeña que quieres poder distinguir del ruido. El 16 sale de fijar potencia 80% y α 5% con un test bilateral.

Marca clara: la fórmula es estadística estándar; los valores de ejemplo (σ=0,18, un MDE concreto) son heurísticos del mismo blog tier 4 (futureagi.com). Usa tu propia σ medida, no la del ejemplo.

Estratificar: la paradoja de Simpson

Un último peligro. Aurora atiende tres tipos de request muy distintos: pedidos (buscar_pedido), políticas (consultar_politica, el paso RAG) y escalados (escalar_a_humano). Mezclarlos en un solo número puede mentirte.

La paradoja de Simpson es el fenómeno por el que una tendencia aparece en los datos agregados y se invierte —o desaparece— al separar por subgrupos. Aplicado aquí: el agregado puede decir "B mejora" mientras B empeora en políticas y solo gana en pedidos porque ese día llegaron más preguntas de pedidos.

La defensa: pre-estratificar por tipo de request y mirar el CI de cada estrato, no solo el global (futureagi.com, tier 4). Si un estrato empeora, lo ves antes de desplegar a todos.

4.5Míralo funcionar: A/B del prompt de Aurora con CI bootstrap

Vamos a comparar dos versiones del prompt de Aurora sobre la métrica groundedness del juez (la del N2, validada con TPR/TNR>90%). Cada versión produce un score 0-1 por conversación.

El experimento offline pre-deploy se monta sobre tu dataset versionado con la API de Langfuse. Cada variante es un run_experiment sobre el mismo dataset, lo que te da diseño pareado por construcción: cada item se evalúa con ambos prompts.

Lee primero los dos bloques enteros. Después analizamos la decisión.

1from langfuse import get_client
2
3langfuse = get_client()
4dataset = langfuse.get_dataset("aurora-eval-dataset")
5
6def run_variante_a(*, item, **kwargs):
7    """Variante A: prompt original."""
8    return call_aurora_agent(item.input, prompt_version="v1")
9
10def run_variante_b(*, item, **kwargs):
11    """Variante B: prompt mejorado."""
12    return call_aurora_agent(item.input, prompt_version="v2")
13
14result_a = dataset.run_experiment(name="aurora-prompt-v1", task=run_variante_a)
15result_b = dataset.run_experiment(name="aurora-prompt-v2", task=run_variante_b)
16# Comparar en la UI: Experiments → seleccionar ambos runs.

Esos dos runs producen, por cada item del dataset, un score de groundedness para A y otro para B. Con esos pares calculamos el CI bootstrap del delta, estratificando por tipo de request.

1import numpy as np
2
3def ci_bootstrap_delta(scores_a, scores_b, n_boot=10_000, seed=0):
4    """95% CI del delta pareado (B - A) por bootstrap."""
5    rng = np.random.default_rng(seed)
6    deltas = np.asarray(scores_b) - np.asarray(scores_a)   # pareado: mismo item
7    n = len(deltas)
8    medias = np.empty(n_boot)
9    for i in range(n_boot):
10        muestra = rng.choice(deltas, size=n, replace=True)  # remuestreo con reemplazo
11        medias[i] = muestra.mean()
12    return float(np.percentile(medias, 2.5)), float(np.percentile(medias, 97.5))
13
14# Resultados por estrato (groundedness 0-1, pareado sobre el mismo item):
15estratos = {
16    "pedido":   {"a": scores_a_pedido,   "b": scores_b_pedido},
17    "politica": {"a": scores_a_politica, "b": scores_b_politica},
18    "escalado": {"a": scores_a_escalado, "b": scores_b_escalado},
19}
20
21for nombre, d in estratos.items():
22    lo, hi = ci_bootstrap_delta(d["a"], d["b"])
23    decision = "✓ sobre 0" if lo > 0 else "✗ cruza 0"
24    print(f"{nombre:9s}  delta CI95 = [{lo:+.3f}, {hi:+.3f}]  {decision}")

Imagina que imprime esto:

1global     delta CI95 = [+0.012, +0.058]  ✓ sobre 0
2pedido     delta CI95 = [+0.040, +0.090]  ✓ sobre 0
3politica   delta CI95 = [-0.061, -0.004]  ✗ cruza 0
4escalado   delta CI95 = [-0.020, +0.018]  ✗ cruza 0

Ahora la pregunta de auto-explicación. Antes de leer el análisis, responde: el global dice "✓ sobre 0", entonces ¿por qué este resultado debería frenarte?

Mira los estratos. El agregado mejora porque B gana fuerte en pedido. Pero en politica —el paso RAG, justo donde nacía el reembolso fantasma— el CI está entero por debajo de 0: B empeora la groundedness de las políticas. Eso es la paradoja de Simpson en directo. Desplegar B "porque el global subió" arreglaría los pedidos y degradaría exactamente el fallo que querías corregir.

Fíjate también en escalado: su CI cruza 0 (de −0,020 a +0,018). Ahí no hay señal: el azar explica la diferencia. No es ni mejora ni empeora; es "no sé todavía".

Esa es la diferencia entre "subió 3 puntos" y un diagnóstico. La media global te daba una opinión optimista. El CI por estrato te da un veredicto con un sospechoso concreto: el prompt nuevo rompe algo en el RAG de políticas.

4.6Hazlo tú

Ejercicio 1 — andamiaje parcial

Corriste un A/B de una mejora de Aurora. El CI bootstrap del delta de groundedness, global, salió:

1global  delta CI95 = [-0.008, +0.041]

La media del delta es +0,017 (positiva). Decide entre tres opciones y justifica:

• (a) Desplegar a todo el tráfico.
• (b) No desplegar; seguir recogiendo datos.
• (c) Revertir el cambio por completo.

Pista: ¿dónde está el límite inferior del intervalo respecto a 0?

Ejercicio 2 — autónomo

Diseña desde cero el plan de rollout de una mejora concreta de Aurora: cambiaste el reranker del RAG para que consultar_politica recupere mejor.

Sin mirar la solución, escribe:

1. La escalera completa shadow → canary → A/B, con qué mides en cada peldaño.
2. Qué métrica usarías como decisión y por qué.
3. Por qué estrato vigilarías especialmente (pista: ¿qué cambiaste?).
4. Marca explícitamente qué umbrales de tu plan son heurísticos.

Antes de seguir, una pregunta de interrogación elaborativa. Respóndela tú primero: ¿por qué el diseño pareado da un CI más estrecho que comparar dos grupos de clientes distintos? Piénsalo antes de leer la siguiente línea.

Porque elimina la varianza entre requests. Dos grupos de clientes distintos difieren por mil razones ajenas a tu cambio: unos preguntan cosas fáciles, otros difíciles. Al evaluar la misma request con ambos prompts y restar, esa varianza compartida se cancela. Queda solo la diferencia que causó tu cambio. Menos ruido, intervalo más estrecho, decisión con menos muestra.

4.7Comprueba

Sin pistas. Dos preguntas. Responde antes de abrir la solución.

Pregunta 1. Un experimento de Aurora arroja, para la métrica de helpfulness:

1delta CI95 = [-0.005, +0.072]   media = +0.034

Tu compañero dice: "la media subió 3,4 puntos, desplegamos". ¿Por qué NO se despliega todavía, aunque la media sea positiva?

Pregunta 2. Te pasan este agregado de un A/B y te piden el veredicto:

1global    win rate B = 58%   (B gana)

Identifica el riesgo que no puedes descartar con solo ese número, y di qué pedirías para descartarlo.

4.8Conecta

Vuelve al jueves a las 18:40 y a los tres puntos de thumbs up.

Si hubieras tenido la disciplina de esta lección, no habrías desplegado a medianoche. Habrías corrido el candidato en shadow, comparado con el juez, calculado el CI bootstrap del delta pareado y mirado los estratos. Quizá los tres puntos eran ruido —el CI cruzaba 0— y te ahorraste desplegar nada. O quizá eran reales en pedidos y un retroceso oculto en políticas, y te ahorraste romper el RAG.

En cualquiera de los dos casos, cambiaste una corazonada por una decisión. Eso es L3 de la pirámide de coste bien hecho: caro, sí, pero reservado para lo que lo merece y resuelto con datos.

¿Dónde lo aplicarías en tu trabajo? Piensa en el último cambio de prompt o de modelo que desplegaste. ¿Lo decidiste comparando dos medias en un dashboard, o con un intervalo? Si fue lo primero, ya sabes qué añadir a tu próximo cambio.

Esto encaja en el checkpoint C5, dimensión 3: un experimento (shadow/canary/A-B) decidido por datos, no por vibes. Lo construirás de extremo a extremo en el N5·L6.

Y queda un cabo suelto. Aunque despliegues la versión ganadora, no gana para siempre. La distribución de preguntas cambia, el proveedor actualiza el modelo bajo tus pies, la calidad se erosiona. La siguiente lección —N5·L5, drift y degradación— monta el monitor que detecta esa erosión antes de que la detecte un cliente en un tuit.

4.9Reflexiona

Tómate dos minutos. Estas preguntas consolidan más que releer.

• Con tus palabras: ¿por qué un intervalo de confianza es una regla de decisión más honesta que comparar dos medias?
• ¿Qué umbrales de esta lección son fórmula estándar y cuáles heurísticos de blog? Nómbralos.
• ¿Qué sigue sin estar claro? Anótalo. Si es "cuánta muestra necesito en mi caso concreto", es la pregunta correcta —la responde tu propia σ medida en la fórmula n ≈ 16·σ²/MDE²—.

Referencia rápida

• Escalera de rollout: shadow (candidato en paralelo, no servido, comparado con juez) → canary (exposición creciente) → A/B (dos brazos, asignación consistente por sesión). Patrón sólido; porcentajes heurísticos (tianpan.co, tier 3).
• Canary %: 1→5→20→50→100; 0,1% para alto riesgo. Heurísticos (tier 3), ajústalos a tu riesgo.
• Regla de decisión: despliega si el 95% CI bootstrap del delta pareado está sobre 0. Si cruza 0, no despliegues; sigue recogiendo datos (futureagi.com, tier 4).
• Tamaño muestral: n_por_brazo ≈ 16·σ²/MDE² (potencia 80%, α 5%, bilateral). Fórmula estándar; σ/MDE de ejemplo son heurísticos — usa tu σ medida.
• Diseño pareado: comparar A y B sobre la misma request reduce la varianza → CI más estrecho con menos muestra.
• Paradoja de Simpson: el agregado puede invertir la señal de los subgrupos. Estratifica por tipo de request (pedido/política/escalado) y mira el CI de cada estrato.
• Anclaje de coste: el A/B en producción es L3 de la pirámide de Husain (A.5), el nivel más caro; se reserva para cambios significativos.
• No usar nunca: decidir un deploy comparando dos medias sin su intervalo.