las ecuaciones de esta slide
Cpet = Σe∈etapas (nine106 pinm(e) + noute106 poutm(e))(coste por etapa)
cada etapa e del pipeline (router → recuperador → generador → validador) consume nin tokens de entrada y produce nout de salida, facturados a los precios por millón pin, pout del modelo m(e) asignado a esa etapa. El coste de la petición es la suma de etapas.
Cdía = Q·(C̄LLM + C̄tool),    C̄LLM = n̄in106 pin + n̄out106 pout(nota técnica)
a escala: Q peticiones/día por el coste medio de cada una. El ejemplo a mano del deck: 0,0001 + 0,001 + 0,0005 + 0,012 + 0,008 + 0,0001 = $0,022 por petición; con 110 000 peticiones/mes salen $2 420/mes.
guion paso a paso
  1. Con los valores por defecto, mira qué barra domina el panel superior. El generador se lleva más del 80% del coste: el router y el recuperador son casi gratis. Optimizar lo barato no mueve la factura.
  2. Sube el contexto RAG de 6 000 a 20 000 tokens. El coste por petición casi se duplica sin tocar la respuesta: la entrada también se factura, y el RAG generoso se paga.
  3. Activa el validador caro. Una segunda llamada cara añade varios milidólares por petición; en el panel inferior la recta mensual se encarece miles de euros al año. Cada LLM extra en el pipeline es una decisión de presupuesto.
  4. Lleva Q a 50 000 peticiones/día. El coste mensual escala lineal con el volumen: el punto dorado sube por la recta. Tu pitch al CFO depende de estos dos sliders, no de la demo del laboratorio.
Comprueba que entiendes: ¿por qué duplicar el contexto RAG encarece más que duplicar la respuesta?
Porque aunque el token de salida es ~5 veces más caro que el de entrada, aquí la entrada son 6 000–20 000 tokens y la salida solo 100–2 000: el volumen gana al precio unitario. Con 12 000 de contexto y 600 de salida en el modelo caro, la entrada cuesta 12 000/106×3 = $0,036 y la salida 600/106×15 = $0,009. Por eso el prompt caching y el filtrado de contexto (re-ranking, top-k pequeño) son las palancas reales de coste en un RAG corporativo.

Setup. El asistente comercial de BBVA del deck: una petición atraviesa router (clasifica, modelo barato, ~300 tokens), recuperador (embedding + búsqueda vectorial, coste fijo pequeño), generador (el LLM grande que redacta con el contexto RAG) y validador (segunda pasada que revisa cumplimiento). Cada barra del panel superior es el coste real de esa etapa con los precios por millón de tokens del modelo asignado; el panel inferior proyecta el coste mensual (22 días laborables) según el volumen Q.

Juega. Mueve los sliders y observa que el desglose no es uniforme: el pipeline tiene un cuello de coste claro (el generador) y dos etapas casi gratuitas. La decisión cara no es "usar IA", es cuántos tokens caros pasan por el modelo caro.

Lee así. El lector da el coste por petición, el reparto porcentual y la factura mensual en dólares. Compáralo con la alternativa humana: una gestión del call center de ING cuesta ~€5,50; aquí hablamos de céntimos.

Mensaje. Conocer el desglose es imprescindible para saber dónde cortar: caché de prompt para el contexto repetido, modelo pequeño donde baste, validador solo para respuestas de riesgo. Las tres slides siguientes cuantifican cada palanca.

Términos. etapa: cada paso del pipeline con su modelo y sus tokens. pin, pout: precio por millón de tokens de entrada / salida. Q: volumen de peticiones por día. Mtok: millón de tokens.

las ecuaciones de esta slide
E[C] = p·Cb + (1−p)·(Cb + Cc)(cascada de dos niveles)
todas las consultas pasan primero por el modelo barato (coste Cb); la fracción p se resuelve ahí y la 1−p restante escala al caro y paga ambos: Cb + Cc. El ahorro frente a enviarlo todo al caro es 1 − E[C]/Cc.
E[coste] = 0,70×0,001 + 0,25×0,03 + 0,05×0,15 = $0,016(deck: tres niveles)
la versión del deck con router de tres niveles: 70% simple → Haiku ($0,001), 25% media → Sonnet ($0,03), 5% compleja → Opus ($0,15). Frente a siempre-Sonnet ($0,03), ahorro del 47%.
Q̄ = (1 − (1−p)·e)·qok + (1−p)·e·qmal(calidad esperada)
el detector de insuficiencia falla con tasa e: una fracción (1−p)·e de consultas complejas se queda en el barato y sale con calidad qmal en vez de qok. El ahorro tiene un precio en calidad, y este es su modelo.
guion paso a paso
  1. Con p = 0,70, lee el ahorro en el lector. Cerca del 60% con Cc = $0,03: más de la mitad de la factura desaparece sin tocar las consultas difíciles.
  2. Mueve p de 0 a 1 mirando el panel superior. La recta dorada baja linealmente desde Cb+Cc (todo escala) hasta Cb (nada escala). Cada punto de p que ganas con un router mejor es ahorro directo.
  3. Sube e hasta 0,30 con p = 0,70. En el panel inferior la calidad esperada cae: el 9% del tráfico (30% de errores sobre el 30% complejo) sale mal. El badge se pone rojo al cruzar el umbral de calidad 0,90.
  4. Busca la p máxima que mantiene la calidad ≥ 0,90 con e = 0,10. No es 1: enviar todo al barato es gratis pero falla. El router óptimo equilibra euros y calidad, no minimiza solo euros.
Comprueba que entiendes: en la cascada, la consulta compleja paga Cb + Cc. ¿Cuándo compensa aún así?
Compensa siempre que p·Cc > Cb: lo que ahorras en las p consultas que NO escalan supera el peaje Cb que pagan todas. Con Cb = $0,001 y Cc = $0,03 basta p > 3,3%: casi cualquier router razonable compensa. Por eso el routing es la palanca de coste más potente en producción: el peaje del intento barato es despreciable frente al precio del caro.

Setup. El patrón de fallback en cascada del deck: un clasificador de complejidad (o el propio modelo barato con autoevaluación) intenta resolver cada consulta del asistente; si la confianza es baja, escala al modelo caro. Panel superior: coste esperado por consulta E[C] en función de p, con las líneas de referencia "todo al caro" y "todo al barato"; el punto dorado es tu configuración. Panel inferior: la calidad esperada Q̄ en función de la tasa de error e del detector, con qok = 0,95 y qmal = 0,55.

Juega. El triángulo de la slide es (p, Cc, e): más p = más ahorro; más Cc = más incentivo a la cascada; más e = más consultas complejas mal atendidas. En un churn telco con 80% de consultas repetitivas ("¿cuánto pago este mes?") la cascada es oro; en un asesor fiscal con todo complejo, no.

Mensaje. El routing inteligente es la palanca de coste más potente en producción, pero se dimensiona con dos números (p y e) que hay que medir sobre tráfico real, no suponer.

Términos. cascada: intentar primero el modelo barato y escalar si no basta. p: fracción de consultas que el barato resuelve bien. e: tasa de fallo del detector de insuficiencia. qok/qmal: calidad cuando la consulta acaba en el modelo adecuado / inadecuado.

las ecuaciones de esta slide
Q($) ≈ Qmax·(1 − e−$/$0)(saturación coste-calidad)
la calidad de respuesta satura con el coste por consulta: Qmax es el techo alcanzable en la tarea y $0 es la escala del codo, específica de cada tarea: gastar $0 compra el 63% del techo; gastar 3·$0, el 95%.
dQd$ = Qmax$0·e−$/$0(calidad marginal por dólar)
la derivada decae exponencialmente: cada dólar extra compra cada vez menos calidad. Pasar de Haiku ($0,005) a Sonnet ($0,03) sube mucho; de Sonnet a Opus ($0,15) sube poco salvo razonamiento complejo. La elección por defecto en 2026 es Sonnet (nota técnica).
guion paso a paso
  1. Con $0 = 0,02, mueve el presupuesto de 0,001 a 0,20. El punto dorado sube rápido hasta ~$0,05 y luego repta: a la derecha del codo, cada dólar compra décimas de punto.
  2. Lee la calidad marginal en el lector con $ = 0,005, 0,03 y 0,15. Cae un orden de magnitud entre Haiku y Opus: el mismo dólar compra ~30 veces menos calidad en el extremo caro.
  3. Sube $0 a 0,08 (tarea de razonamiento difícil). El codo se desplaza a la derecha y Opus vuelve a tener sentido: la curva es de la TAREA, no del proveedor. Por eso hay que medirla con tu golden set.
  4. Con $0 = 0,01, compara Q(0,03) y Q(0,15) en el lector. Diferencia de ~5 puntos porcentuales por 5 veces el precio: en tareas fáciles, pagar Opus es tirar el presupuesto.
Comprueba que entiendes: ¿qué significa operativamente que $0 sea pequeño?
Que la tarea es barata de saturar: con muy poco gasto ya estás cerca del techo Qmax, y subir de modelo no añade casi nada. Un $0 pequeño (FAQ de empleados, clasificación de tickets) pide modelo barato + cascada; un $0 grande (análisis regulatorio, SQL complejo) justifica el modelo caro. Estimar $0 con 50–500 golden conversations es la primera decisión económica del proyecto, antes de elegir proveedor.

Setup. La curva coste-calidad de la nota técnica, con los tres puntos de referencia del mercado 2026 marcados sobre ella: Haiku ($0,005/consulta), Sonnet ($0,03) y Opus ($0,15). La línea discontinua es el techo Qmax = 1; el punto dorado es tu presupuesto elegido y la zona sombreada es la calidad que ya has comprado.

Juega. El slider de $0 cambia de tarea: con el codo a la izquierda (tareas simples) los tres modelos están casi al mismo nivel de calidad y gana el barato; con el codo a la derecha (razonamiento), la brecha entre puntos se abre y el caro se justifica.

Mensaje. "¿Qué modelo uso?" es una pregunta mal planteada; la buena es "¿dónde está el codo de MI tarea?". Se responde midiendo calidad sobre un golden set a varios niveles de gasto, y de ahi sale la cascada de la slide anterior con números propios.

Términos. Qmax: techo de calidad alcanzable en la tarea. $0: escala del codo; gasto que compra el 63% del techo. golden set: conjunto de conversaciones ideales con las que se mide la calidad (Día 16).

las ecuaciones de esta slide
TLLM = TTFT + Nouttps,    T ∼ LogNormal(μ, σ²):  T = eμ+σZ,  Z∼N(0,1)(nota técnica + modelo)
la llamada al LLM tarda el time-to-first-token (red + prefill) más la decodificación a tps tokens/segundo. La latencia total observada es aleatoria y asimétrica: el modelo lognormal (exponencial de una normal) reproduce su cola derecha larga. eμ es la mediana; σ controla cuánto pesa la cola.
p95: P(T ≤ t95) = 0,95  ⇒   t95 = eμ+1,645σ,    E[T] = eμ+σ²/2(percentil vs media)
el percentil 95 es el valor que el 95% de las peticiones no supera: es lo que se firma en el SLA (p95 < 3 s en el caso ING del deck). La media está SIEMPRE por debajo del p95 en una lognormal: prometer la media es engañarse, porque 1 de cada 20 usuarios vive en la cola.
Ttotal = Σt=1..N (TLLMt + Ttoolt)(Ec. 1 de la nota)
una sesión de N turnos suma latencias de LLM y de tools: las colas se acumulan turno a turno. El ejemplo a mano del deck: 40 + 280 + 350 + 520 + 460 + 80 = 1 730 ms end-to-end. El panel inferior muestra cómo crece el p95 de la suma al encadenar S etapas.
guion paso a paso
  1. Con mediana 500 ms y σ = 0,5, lee p50, media, p95 y p99. La media ya supera la mediana y el p95 casi duplica la mediana: en una lognormal la cola tira de todo hacia arriba.
  2. Sube σ a 1,0 sin tocar la mediana. El p50 apenas se mueve pero el p99 se multiplica: la mitad "típica" de tus usuarios no nota nada y el 1% espera 10 segundos. El SLA se rompe por la cola, no por el centro.
  3. Con S = 3 etapas, mira el panel inferior. El p95 de la suma crece más que 3 veces el p50 de una etapa: las colas de las etapas se suman y alguna siempre sale lenta.
  4. Pulsa "otra muestra" varias veces. p50 estable, p99 bailando: los percentiles profundos se estiman con pocas observaciones efectivas, igual que los cuantiles extremos en riesgo. Monitorizar p99 exige volumen.
Comprueba que entiendes: ¿por qué el SLA se firma en p95 y no en la media?
Porque la media es invisible para el usuario individual: nadie experimenta "la media", cada uno experimenta SU petición. Con cola lognormal, la media puede ser excelente mientras el 5% de los usuarios espera el triple: exactamente los que abandonan, llaman al call center (€5,50 en ING) o tuitean la captura. El p95 acota la experiencia del 95% de las peticiones reales; el p99 protege a los heavy users, que suelen ser los clientes más valiosos.

Setup. Simulo 4 000 peticiones reales del chatbot (muestreadas con generador reproducible, semilla fija) cuya latencia por etapa es lognormal: mediana eμ y dispersión σ. Arriba: el histograma de latencias de UNA etapa con las marcas p50 (tinta), media (gris), p95 (dorado) y p99 (dorado oscuro), y la línea del SLA en 3 000 ms. Abajo: el p50 y el p95 del pipeline completo al encadenar S etapas en secuencia (cada punto se calcula sumando S muestras independientes, no con una fórmula pre-cocinada).

Juega. σ es el slider importante: representa tools externos inestables, reintentos ocultos, picos de carga del proveedor. Con σ alta, la distancia media–p99 se abre; eso es lo que el dashboard de producción vigila y lo que el incidente de ING del deck (picos a 12 s) ilustra.

Mensaje. En producción se piensa en percentiles. La media es una métrica de coste (factura = volumen × media); la experiencia y el SLA son percentiles. Y al encadenar etapas, la cola de la suma la domina la etapa más dispersa: optimiza la varianza, no solo la media.

Términos. TTFT: time-to-first-token, latencia antes del primer token (~0,7 s en Sonnet vía API). tps: tokens por segundo de decodificación (~60). p50/p95/p99: percentiles de latencia. SLA: acuerdo de nivel de servicio, contractual.

las ecuaciones de esta slide
Tsec = Σi=1..n Ti,    Tpar = máxi=1..n Ti(orquestación)
si el orquestador lanza los n subagentes uno tras otro, la latencia es la suma; si los lanza a la vez (son independientes), espera solo al más lento: el máximo. La suma crece lineal con n; el máximo crece despacio (como el percentil 1−1/n de una etapa).
Csec = Cpar = Σi=1..n Ci(el coste no cambia)
paralelizar no ahorra dinero: se consumen los mismos tokens en ambos casos. Compra latencia, no coste. Es la estrategia "tools en paralelo" de la nota técnica: lanzar concurrentemente las k tools independientes que el agente decida invocar.
guion paso a paso
  1. Con n = 4, compara las dos curvas del panel superior. La secuencial (tinta) ya cuadruplica la mediana de una etapa; la paralela (dorada) apenas la duplica. Misma factura, mitad de espera.
  2. Sube n hasta 12. La suma sigue recta hacia arriba; el máximo se aplana: pasar de 8 a 12 subagentes paralelos casi no añade latencia. El máximo crece como un percentil, no como una suma.
  3. Sube σ a 1,0 con n = 6. La ventaja del paralelo se ESTRECHA en términos relativos al p95: con colas pesadas, el más lento de 6 es lento de verdad. Paralelizar no te exime de vigilar la cola de cada subagente.
  4. Mira el histograma inferior con n = 6. La distribución del máximo (dorada) está pegada a la derecha de la de UNA etapa pero lejos de la suma: pagas "el peor de n", nunca "n veces uno".
Comprueba que entiendes: ¿por qué el máximo de n lognormales crece tan despacio con n?
Porque P(máx ≤ t) = P(T ≤ t)n (independencia): el máximo de n muestras se comporta como el percentil 1−1/n de una sola. Pasar de n = 4 a n = 8 mueve ese percentil del 75% al 87,5%: unos cientos de ms en una lognormal moderada. La suma, en cambio, añade una mediana entera por subagente. De ahí la regla de diseño: todo lo que sea independiente (buscar en CRM, buscar en Confluence, consultar BigQuery) se lanza a la vez; solo lo dependiente se encadena.

Setup. El asistente corporativo BBVA del deck tiene 4 subagentes (buscador, investigador, analista, redactor). Cuando el orquestador necesita varios a la vez puede encadenarlos o lanzarlos en paralelo. Simulo 3 000 peticiones (semilla reproducible): cada subagente tarda una lognormal con mediana 500 ms y la σ del slider. Arriba: latencia p50 y p95 de ambas estrategias en función de n, calculadas sobre la simulación. Abajo: las tres distribuciones para el n elegido (una etapa, máximo de n, suma de n).

Juega. El contraste es la imagen del día 15 (orquestador-subagentes) hecha número: la arquitectura en estrella no es estética, es la que permite paralelizar; una cadena lineal de subagentes hereda la suma de latencias completa.

Mensaje. El paralelismo es la única optimización de latencia que es gratis en coste. Su límite es la dependencia lógica (el redactor necesita lo que encuentre el buscador) y el rate limit del proveedor.

Términos. orquestador: agente principal que delega en subagentes (Día 15). fan-out: lanzar n subagentes a la vez. máx de n: latencia del paralelo; equivale al percentil 1−1/n de una etapa.

las ecuaciones de esta slide
Péxito(r) = 1 − (1−q)r(reintentos independientes)
si cada intento tiene probabilidad q de funcionar (el error 429 o 503 es transitorio), fallar r veces seguidas tiene probabilidad (1−q)r: con q = 0,90 y r = 3, el fallo compuesto baja al 0,1%. La disponibilidad compuesta sube exponencialmente con r... si los fallos son independientes.
esperai = b·2i−1,    E[T] = Σi=1..r (1−q)i−1[q·Tiok + 1{i=r}(1−q)·Trfail](backoff exponencial)
tras el intento i fallido se espera b·2i−1 (1×, 2×, 4×... la base b) antes de reintentar: el backoff exponencial de la nota técnica, que evita martillear un servicio caído. La latencia esperada pondera cada escenario (éxito al intento i, o agotar los r intentos) por su probabilidad exacta.
E[intentos] = 1 − (1−q)rq  ⇒   E[C] = E[intentos]·Cllamada(coste de reintentar)
cada reintento se factura: el coste esperado es el número esperado de intentos por el precio de la llamada. Con q alto apenas se nota; con q bajo, reintentar es pagar varias veces por la misma respuesta.
guion paso a paso
  1. Con q = 0,90, sube r de 1 a 3 mirando el panel superior. La disponibilidad salta de 90% a 99,9%: dos reintentos convierten un servicio mediocre en uno respetable. El badge pasa a verde al cruzar el 99,5% del SLA.
  2. Sigue subiendo r hasta 6. La curva ya está plana: el cuarto reintento añade casi nada de disponibilidad pero sí cola de latencia (panel inferior, esperas 8b y 16b). Reintentar más no siempre es mejor.
  3. Baja q a 0,50 (proveedor degradado). Ni con r = 6 llegas al 99,5%, la latencia esperada se dispara por las esperas y el coste esperado casi duplica el de una llamada: reintentar contra un servicio roto es pagar más por esperar más. Eso pide circuit breaker, no más paciencia.
  4. Con q = 0,90 y r = 3, sube b a 2 000 ms. La disponibilidad no cambia (b no toca la probabilidad) pero el p-latencia del caso "éxito al 3.º intento" suma 6 segundos de esperas: el backoff se dimensiona contra el SLA, no al azar.
Comprueba que entiendes: ¿por qué el backoff es exponencial y no espera fija?
Por dos razones. Primera: si el servicio está caído, mil clientes reintentando cada 500 ms fijos lo rematan en cuanto vuelve (thundering herd); duplicar la espera dispersa la carga y le da aire para recuperarse. Segunda: los fallos transitorios reales no son independientes, vienen en ráfagas; esperar 1b, 2b, 4b hace que los intentos sucesivos muestreen momentos cada vez más alejados de la ráfaga, y la independencia que asume 1−(1−q)r se vuelve aproximadamente cierta. El backoff no solo espera: hace verdadera la fórmula.

Setup. El patrón retry-con-backoff de la nota técnica, con su aritmética completa. Arriba: la disponibilidad compuesta 1−(1−q)r en función de r, con la línea del SLA de disponibilidad (99,5%, el contrato del caso ING del deck). Abajo: la latencia de cada escenario (éxito al intento 1, 2, ..., r) con sus probabilidades como barras, y la latencia esperada total. Todo se calcula con la enumeración exacta de escenarios, no por aproximación.

Juega. La política de reintentos tiene tres mandos y esta slide los hace visibles: r compra disponibilidad con rendimientos decrecientes, b compra estabilidad del proveedor a costa de latencia de cola, y q no lo controlas tú: lo controla el circuit breaker, que corta cuando q se hunde para no pagar la zona roja de esta slide.

Mensaje. Los cinco patrones del deck (timeout, retry, circuit breaker, fallback de modelo, mensaje canónico) son capas de la misma cebolla: cada una corta las pérdidas cuando la anterior no basta. Reintentar errores 4xx (lógicos) no entra: si el JSON era inválido, lo seguirá siendo a la tercera.

Términos. q: probabilidad de éxito de un intento. r: máximo de intentos. backoff: espera creciente entre reintentos (b, 2b, 4b...). circuit breaker: dejar de llamar a un servicio que falla repetidamente. 429/503: errores transitorios (rate limit / servicio no disponible); sí se reintentan.

las ecuaciones de esta slide
L = λ·W(ley de Little)
válida para CUALQUIER sistema estable, sin supuestos de distribución: el número medio de peticiones dentro del sistema (L) es la tasa de llegadas (λ, peticiones/s) por el tiempo medio que cada una pasa dentro (W, segundos). Si miras el dashboard y hay 40 sesiones vivas con λ = 10/s, cada una está tardando 4 s: Little te deja inferir lo que no mides.
ρ = λμ,    W = 1μ−λ,    Lq = ρ²1−ρ(cola M/M/1)
con llegadas Poisson y servicio exponencial a capacidad μ (peticiones/s): la utilización ρ es la fracción de la capacidad usada, y el tiempo total en el sistema W tiene un denominador μ−λ que explota cuando ρ→1: al 50% de uso esperas 2/μ; al 90%, 10/μ; al 99%, 100/μ. La curva no es lineal: es un codo.
guion paso a paso
  1. Con λ = 8 y μ = 10 (ρ = 0,8), lee W. 500 ms: el quíntuple del tiempo de servicio puro (100 ms). Al 80% de utilización ya pagas un 400% de espera extra. La cola cuesta antes de saturar.
  2. Sube λ de 8 a 9,5 (un +19% de tráfico). W salta de 0,5 s a 2 s: +300%. Cerca del codo, un incremento pequeño de demanda multiplica la espera. Este es el mecanismo exacto del incidente ING del deck: un pico desborda y la latencia pasa a 12 s.
  3. Restaura λ = 8 y baja μ a 8,5. Mismo efecto por el otro lado: perder capacidad (una zona del proveedor caída, rate limit reducido) te empuja al codo aunque el tráfico no cambie.
  4. Busca la μ mínima que mantiene W ≤ 300 ms con λ = 8. Sale μ ≈ 11,3: dimensionar es despejar μ ≥ λ + 1/Wobjetivo, no "μ = λ y que aguante". El margen sobre la demanda ES el producto que compras.
Comprueba que entiendes: ¿por qué W explota en ρ = 1 si "en media" la capacidad da exactamente para la demanda?
Porque las llegadas no vienen en media: vienen en ráfagas aleatorias. Cuando ρ < 1, los ratos tranquilos permiten vaciar la cola que las ráfagas crean; cuando ρ = 1 no hay ratos tranquilos que compensen: cada ráfaga deja un poso de cola que nunca se drena, y la espera crece sin límite aunque el sistema "dé abasto" en media. Por eso ningún equipo de infraestructura serio planifica por encima del 70–80% de utilización sostenida: el 20–30% restante no es derroche, es el amortiguador que mantiene W finito.

Setup. El asistente de BBVA en hora punta: las peticiones llegan a tasa λ y el despliegue (instancias del orquestador + cuota de API) procesa a capacidad μ. Arriba: la curva codo W(λ) con tu punto de operación dorado y la asíntota vertical en λ = μ; la línea discontinua es el objetivo de 300 ms de espera interna. Abajo: L = λW y Lq (en cola) en función de la utilización ρ, con tu ρ marcada.

Juega. La pareja (λ, μ) resume todas las decisiones de capacidad: autoscaling (sube μ con la demanda), rate limiting (recorta λ para proteger W), colas de prioridad (reparte el W disponible). Fíjate en que TODO pasa cerca de ρ = 1; lejos del codo, la infraestructura es aburrida, que es como debe ser.

Mensaje. El SLA de latencia de las slides anteriores se gana o se pierde aquí: puedes tener el pipeline más rápido del mundo y arruinarlo con ρ = 0,95. Dimensionar = fijar W objetivo en el p95 y despejar μ con margen para la ráfaga.

Términos. λ: tasa de llegadas. μ: capacidad de servicio. ρ: utilización λ/μ. W: tiempo medio en el sistema (espera + servicio). L, Lq: peticiones dentro del sistema / esperando en cola. M/M/1: cola con llegadas Poisson, servicio exponencial, un servidor.

las ecuaciones de esta slide
Cef = (1−h)·C,    Tef = h·Tcache + (1−h)·TLLM(coste y latencia efectivos)
con tasa de acierto h, solo la fracción 1−h de consultas paga el LLM completo; los aciertos salen de la caché en ~30 ms. El ahorro mensual es h·C·volumen: lineal en h, y h se compra con TTL.
h(TTL) = hmax·(1 − e−TTL/τrep),    s(TTL) = 1 − τupdTTL(1 − e−TTL/τupd)(frescura vs ahorro)
subir el TTL captura más repeticiones (h crece hacia el techo hmax, la repetitividad real del tráfico, con escala τrep = tiempo típico entre repeticiones) pero sirve respuestas más viejas: s es la probabilidad de servir contenido obsoleto si la fuente cambia cada τupd en media (entrada de edad uniforme en [0,TTL], cambios Poisson). Las dos curvas se cruzan: ese cruce es la decisión.
guion paso a paso
  1. Con TTL = 24 h, lee h y el ahorro mensual. Con hmax = 0,6 y tráfico que se repite en horas, h ronda 0,5: la mitad de la factura LLM desaparece por guardar respuestas ya pagadas.
  2. Sube TTL hacia 168 h mirando el panel inferior. h ya está saturada en hmax pero la curva de obsolescencia sigue subiendo: a partir del codo, más TTL no compra ahorro, solo respuestas viejas.
  3. Baja τupd a 6 h (contenido que cambia a diario: precios, disponibilidad). La curva de obsolescencia se dispara y el cruce con h se mueve a TTL de minutos-horas: la política de caché depende del contenido, no es un número global.
  4. Sube el volumen a 500 000. El ahorro escala lineal: con volumen alto, la caché es la optimización con mejor ratio esfuerzo/euros de toda la slide-deck. Por eso se implementa ANTES que el fine-tuning.
Comprueba que entiendes: ¿por qué h no llega nunca a 1 por mucho TTL que pongas?
Porque el techo es hmax, la repetitividad intrínseca del tráfico: la fracción de consultas que son repetición (semántica) de otra ya vista. Una consulta genuinamente nueva ("¿puedo amortizar mi hipoteca parcialmente si...?") no está en ninguna caché por definición. El TTL solo decide cuántas de las repeticiones ATRAPAS antes de que caduquen. Medir hmax (agrupando consultas por embedding y contando duplicados) es lo primero: si tu tráfico es 90% único, la caché no es tu palanca.

Setup. El asistente interno de empleados (caso 1 de la tabla del deck): muchas consultas se repiten ("¿días de vacaciones?", "¿cómo pido el certificado?"). Una caché semántica guarda la respuesta y la sirve en ~30 ms sin tocar el LLM ($0,022/petición, el ejemplo a mano del deck). Arriba: factura mensual sin caché vs con caché para tu TTL (barras), con el ahorro en euros. Abajo: las dos curvas enfrentadas en función del TTL, acierto h (dorado) y obsolescencia s (tinta), con tu TTL marcado.

Juega. Los cuatro sliders son las cuatro preguntas de negocio: ¿cuánto se repite mi tráfico? (hmax), ¿cada cuánto cambia la verdad? (τupd), ¿cuánto arriesgo a servir viejo? (TTL) y ¿cuánto facturo? (volumen). El cruce del panel inferior responde la pregunta del TTL para CADA tipo de contenido: FAQ de RRHH, TTL semanas; precios de Inditex, TTL minutos.

Mensaje. La caché es la palanca de coste n.º 2 tras el routing, y además mejora la latencia (los aciertos son instantáneos: suben el p50 de experiencia sin tocar el p95). Su riesgo no es técnico sino de frescura, y se gestiona por tipo de contenido.

Términos. h: tasa de acierto de caché. TTL: time-to-live, caducidad de cada entrada. hmax: repetitividad del tráfico (techo de h). obsolescencia s: probabilidad de servir una respuesta cuya fuente ya cambió. caché semántica: indexa por embedding, no por igualdad literal.

las ecuaciones de esta slide
ēt = 1wΣi=t−w+1..t ei,    alertat = 1{ēt > θ}(media móvil + umbral)
el monitor más simple que funciona: suaviza la tasa de error con una ventana móvil de w minutos y dispara cuando cruza el umbral θ. La ventana filtra el ruido minuto a minuto; el umbral decide qué es "anormal". Toda la slide es la tensión entre esas dos decisiones.
FP(θ) = #{t < tdeg : ēt > θ},    D(θ) = mín{t ≥ tdeg : ēt > θ} − tdeg(falsos positivos vs detección)
subir θ reduce los falsos positivos (alertas sin incidente, que queman al equipo de guardia) pero alarga el tiempo de detección D del incidente real, y cada minuto sin detectar cuesta dinero medible (€27,50/min en el caso ING del deck: 5 llamadas overflow × €5,50). El panel inferior calcula ambas curvas sobre ESTA serie, punto a punto.
guion paso a paso
  1. Con θ = 3% y w = 5, mira el panel superior. La serie cruda (gris) es ruidosa; la media móvil (tinta) la sigue limpia; tras t = 120 la degradación inyectada la lleva a ~6% y aparecen los rombos dorados de alerta. Lee FP y D en el lector.
  2. Baja θ a 1,5%. Detectas el incidente en 1–2 min... y acumulas falsos positivos en la mañana tranquila. Un equipo que recibe 8 alertas falsas al día deja de mirar la novena: el coste del FP es la credibilidad del monitor.
  3. Sube θ a 8%. Cero falsos positivos y detección tardía o nula: el incidente corre minutos facturando llamadas a €5,50. El panel inferior muestra el codo donde las dos curvas se cruzan: ahí vive el θ razonable.
  4. Desactiva la degradación y pulsa "otro día" varias veces con tu θ elegido. Estimas la tasa de falsas alarmas en días sanos: la prueba de fuego de un umbral es el día SIN incidente.
  5. Sube w a 12 con θ = 3%. Los FP bajan (más suavizado) pero D crece: la ventana es un segundo umbral disfrazado. (FP, D) se elige en pareja (w, θ), no por separado.
Comprueba que entiendes: ¿por qué no poner θ justo encima del máximo histórico de los días sanos?
Porque el máximo histórico es una muestra de la cola de la distribución sana: el próximo día sano lo superará con probabilidad no despreciable (es la misma lección del p99 de latencia: los extremos muestrales bailan). Además, una degradación real puede ser PEQUEÑA (del 1% al 2,5% de error: miles de usuarios afectados) y quedar por debajo de ese máximo para siempre. Lo correcto es elegir θ sobre las curvas FP/D como aquí, y complementar el umbral fijo con detección de cambio relativo (¿ha doblado la media móvil su nivel de la última hora?).

Setup. Ocho horas (480 min) del dashboard del asistente en producción, generadas con semilla reproducible: tasa de error por minuto con base 1% + ruido + un pico esporádico inocuo, y una degradación real inyectable en t = 120 (un MCP externo caído que eleva la tasa a ~6% con rampa de 10 min). Arriba: serie cruda, media móvil, umbral θ y alertas. Abajo: las curvas FP(θ) y D(θ) calculadas barriendo θ sobre esta misma serie, con tu θ marcado. Nada está pre-cocinado: cambiar la semilla recalcula todo.

Juega. Esto es el panel de "tasa de error" del dashboard de cuatro paneles del deck (faithfulness, latencia p95, coste/sesión, fallbacks). Cada panel tiene su versión de esta misma tensión FP/D; el de coste, por ejemplo, vigila el presupuesto por sesión del error 2 del deck (loops que queman $1 por conversación).

Mensaje. "No usar nunca un agente sin observabilidad en producción: depurar a oscuras es imposible" (nota técnica). Y observar no es solo loggear: es elegir umbrales con criterio económico explícito. El equipo que mide gana al equipo que improvisa.

Términos. θ: umbral de alerta. w: ventana de la media móvil. FP: falsos positivos (alertas sin incidente). D: tiempo de detección del incidente real. traza: registro completo {(contexto, acción, resultado)} de cada sesión (Langfuse, Phoenix, Helicone).

Arquitectura — orquestador + subagentes + MCP + monitor
Slides: Coste · Paralelo
"Un asistente corporativo serio es un grafo: router → recuperador → generador → validador, con subagentes en paralelo donde no hay dependencia lógica. La forma del grafo determina la latencia (máx vs suma) y la factura (qué tokens pasan por qué modelo)."
↓
Coste — desglose por etapa y palancas
Slides: Coste · Cascada · Calidad · Caché
"Cdía = Q·(C̄LLM+C̄tool); el generador domina. Palanca 1: routing en cascada, E[C] = p·Cb+(1−p)(Cb+Cc), ahorro ~47%. Palanca 2: caché, Cef = (1−h)·C. Y la calidad satura: Q($) = Qmax(1−e−$/$₀), no pagues a la derecha del codo."
↓
Latencia — percentiles, paralelismo y colas
Slides: Percentiles · Paralelo · Colas
"El SLA se firma en p95 = eμ+1,645σ, no en media: la cola manda. Subagentes independientes en paralelo: latencia = máx, coste idéntico. Y bajo carga, W = 1/(μ−λ) explota cuando ρ→1: dimensiona con margen o el codo te dimensiona a ti."
↓
Robustez — reintentos, backoff y cortafuegos
Slides: Reintentos
"Péxito = 1−(1−q)r con backoff b·2i−1: dos reintentos convierten 90% en 99,9%. Pero contra un servicio roto, reintentar es pagar más por esperar más: timeout, circuit breaker, fallback de modelo y mensaje canónico, en ese orden."
↓
Monitor — observabilidad con criterio económico
Slides: Monitor
"Media móvil + umbral θ: los falsos positivos queman al equipo, la detección tardía quema dinero (€27,50/min en ING). θ y w se eligen sobre las curvas FP/D medidas, no a ojo. Sin observabilidad no hay producción: el equipo que mide gana al que improvisa."

En una frase. Producción no es "funciona en el lab": es un sistema con factura desglosada por etapa, latencia prometida en percentiles, fallbacks en capas y un monitor cuyos umbrales tienen justificación económica. Todo lo de hoy son seis fórmulas cortas y la disciplina de medirlas sobre TU tráfico.

Garrido-Merchán — ecgarrido@comillas.edu — Deep Learning para Business Analytics — Día 17 · Multi-agente en producción