Módulo 8: Proyecto — arquitecta una feature de IA en Mercado

El presupuesto, el cascade y la caché

Siguiente →

Descripción

Con el componente ubicado y su hoja emitida, el método pasa al paso 2: hacer la feature asequible. El agente de soporte es lento (cientos de milisegundos por turno) y cuesta dinero (cada llamada al modelo se cobra por token), así que antes de blindarlo hay que meterlo en su presupuesto de latencia y costo —porque una feature que no cabe en su presupuesto no llega a producción, por buena que sea—. Esta lección llena los campos latency_budget y cost_budget de la hoja con las dos palancas del módulo 2: el model cascade (barato primero, escalar solo si hace falta) y la caché (no repagar lo repetido), medidas sobre 1000 tickets del agente.

Y trae la lección honesta que el módulo 2 anticipó y que casi nadie explica: ninguna palanca sola es una bala de plata. Vas a ver tres estrategias —mandar todo al modelo caro, el cascade solo, y cascade + caché— comparadas contra el presupuesto de la feature, y vas a descubrir que el cascade solo recorta el costo pero se queda por encima del margen, y que hace falta componer el cascade con la caché para meter la feature dentro. Es la diferencia entre "apliqué una técnica de optimización" y "diseñé el presupuesto de la feature".

Conexión con el módulo. Esta es la primera capa de la cáscara que se construye sobre la hoja de la lección 2, y la más "operativa" —trata del costo y la latencia, no de la seguridad ni la calidad—. Es también donde aparecen dos piezas que las lecciones siguientes reusan: el clasificador del cascade (que vive antes del LLM y decide a cuál llamar) y la caché (que en la lección 6 cumplirá doble función como ruta de fallback). La frontera con AI Engineering se mantiene: aquí tratamos el costo y la latencia del componente como restricciones de arquitectura; la optimización de la inferencia por dentro —cuantización, batching, GPU— es infra/AI Engineering, no este módulo.

Una analogía: el call center con guion de respuestas frecuentes

Vuelve al call center del módulo 2, el que atiende con juniors baratos y escala al senior caro solo lo difícil. Ese es el cascade, y ya lo conoces. Pero un call center bien montado tiene una segunda economía, aún más poderosa, que el cascade no captura: un guion de respuestas frecuentes. La mayoría de las llamadas preguntan lo mismo —"¿cuál es su horario?", "¿cómo rastreo mi pedido?", "¿cómo devuelvo esto?"—, y para esas, el agente ni siquiera piensa: lee la respuesta ya escrita en el guion. No es que un junior barato la conteste; es que nadie la contesta de cero —la respuesta ya existía, calculada de antemano—.

Esa es la caché. El cascade abarata cada llamada (junior en vez de senior); la caché elimina llamadas enteras (la respuesta ya estaba escrita, no hay que generarla). Y fíjate en que las dos economías se componen: primero el guion atrapa las preguntas repetidas (gratis), y solo lo que no está en el guion pasa al cascade, que lo enruta al junior o al senior según su dificultad. Un call center que solo tuviera el cascade —sin guion— pondría a un junior a redactar desde cero la respuesta al horario mil veces al día; uno que solo tuviera el guion —sin cascade— mandaría todas las preguntas nuevas al senior. Los dos juntos son lo que hace que el call center sea económicamente viable. En el agente de soporte de Mercado, el cascade elige el modelo por dificultad y la caché sirve de un tirón las preguntas repetidas; esta lección mide cuánto ahorra cada uno y por qué se necesitan los dos.

Ejemplo trabajado: tres estrategias contra el presupuesto

Vamos a medir el agente de soporte sobre 1000 tickets y a comparar tres estrategias contra su presupuesto (latencia 4000 ms, costo $3000/mes). El workload es realista: el 30% de los tickets son difíciles (necesitan el modelo caro) y el 40% son preguntas repetidas (candidatas a caché). Medimos: all_strong (todo al modelo caro, el baseline), cascade (clasificar y enrutar), y cascade_cache (las dos palancas juntas). Todo con el modelo de costo/latencia del módulo 2, semilla fija.

# M8 Leccion 3 — presupuesto + model cascade + cache (M2), sobre el agente
# de soporte. Medimos tres estrategias sobre 1000 tickets y comparamos contra
# el latency/cost budget de la feature. STUB del LLM: todo SIMULADO, semilla fija.
import random

# Modelo de costo/latencia identico al del modulo 2 (consistencia).
MODELS = {
    "cheap":  dict(usd_in=0.0008, usd_out=0.004, base_ms=90,  ms_per_tok=0.4),
    "strong": dict(usd_in=0.008,  usd_out=0.040, base_ms=300, ms_per_tok=3.0),
}

# El presupuesto de la feature (M2). El componente debe caber aqui.
LATENCY_BUDGET_MS = 4000          # el cliente no espera mas de ~4 s
COST_BUDGET_USD_MONTH = 3000      # margen mensual para el agente de soporte


def call_llm(model, in_tokens, out_tokens):
    m = MODELS[model]
    latency_ms = m["base_ms"] + out_tokens * m["ms_per_tok"]
    cost_usd = (in_tokens / 1000) * m["usd_in"] + (out_tokens / 1000) * m["usd_out"]
    return latency_ms, cost_usd


random.seed(7)
N = 1000
IN_TOK = 300
OUT_EASY, OUT_HARD = 120, 300
CLASSIFIER_MS = 3

# El workload: 1000 tickets. 30% dificiles (razonamiento). Ademas, el 40% son
# preguntas REPETIDAS (rastreo, devoluciones, horarios) -> candidatas a cache.
tickets = []
for _ in range(N):
    true_hard = random.random() < 0.30
    repeated = (not true_hard) and (random.random() < 0.55)   # las faciles se repiten
    tickets.append((true_hard, repeated))


def classify(true_hard):
    # El clasificador barato: acierta el 92% (imperfecto, como en la realidad).
    return true_hard if random.random() < 0.92 else (not true_hard)


def out_tokens_for(true_hard):
    return OUT_HARD if true_hard else OUT_EASY


def pct(sorted_vals, p):
    return sorted_vals[int(len(sorted_vals) * p)]


def measure(strategy):
    total_cost, lats, cache_hits, model_calls = 0.0, [], 0, 0
    for true_hard, repeated in tickets:
        if strategy == "cascade_cache" and repeated:
            # Cache HIT: respuesta ya calculada. Sin llamada al modelo.
            lats.append(5.0)          # servir de cache: ~5 ms
            cache_hits += 1
            continue
        if strategy == "all_strong":
            model = "strong"
            extra_ms = 0.0
        else:  # cascade o cascade_cache
            model = "strong" if classify(true_hard) else "cheap"
            extra_ms = CLASSIFIER_MS
        lat, cost = call_llm(model, IN_TOK, out_tokens_for(true_hard))
        total_cost += cost
        lats.append(lat + extra_ms)
        model_calls += 1
    lats.sort()
    return total_cost, sum(lats) / len(lats), pct(lats, 0.95), cache_hits, model_calls


rows = []
for name in ("all_strong", "cascade", "cascade_cache"):
    rows.append((name,) + measure(name))

print(f"{'strategy':<16}{'cost_1k':>10}{'avg_ms':>9}{'p95_ms':>9}{'cache':>7}{'calls':>7}")
for name, cost, avg, p95, hits, calls in rows:
    print(f"{name:<16}{cost:>10.4f}{avg:>9.1f}{p95:>9.1f}{hits:>7}{calls:>7}")

base = rows[0][1]
best = rows[2][1]
print(f"\nAhorro de costo cascade+cache vs all_strong: "
      f"{(1 - best/base)*100:.1f}%  (${base:.4f} -> ${best:.4f} por {N} tickets)")

# Escala mensual: 20k tickets/dia (volumen realista de soporte).
DAILY_TICKETS = 20_000
scale = DAILY_TICKETS * 30 / N
print("\n=== Contra el presupuesto (M2) ===")
print(f"  latency_budget = {LATENCY_BUDGET_MS} ms   cost_budget = ${COST_BUDGET_USD_MONTH}/mes")
for name, cost, avg, p95, hits, calls in rows:
    monthly = cost * scale
    lat_ok = "OK" if p95 <= LATENCY_BUDGET_MS else "EXCEDE"
    cost_ok = "OK" if monthly <= COST_BUDGET_USD_MONTH else "EXCEDE"
    print(f"  {name:<16} ${monthly:>8,.0f}/mes [{cost_ok:<6}]   p95={p95:>6.0f}ms [{lat_ok}]")
print("\nSolo cascade+cache mete la feature en su presupuesto de costo. El cascade")
print("solo recorta, pero no basta: la cache —no repagar lo repetido— cierra la brecha.")

Qué esperar. Al correr el archivo, la salida es exactamente esta:

strategy           cost_1k   avg_ms   p95_ms  cache  calls
all_strong          9.5544    836.6   1200.0      0   1000
cascade             5.0638    479.5   1203.0      0   1000
cascade_cache       4.6454    415.8   1203.0    383    617

Ahorro de costo cascade+cache vs all_strong: 51.4%  ($9.5544 -> $4.6454 por 1000 tickets)

=== Contra el presupuesto (M2) ===
  latency_budget = 4000 ms   cost_budget = $3000/mes
  all_strong       $   5,733/mes [EXCEDE]   p95=  1200ms [OK]
  cascade          $   3,038/mes [EXCEDE]   p95=  1203ms [OK]
  cascade_cache    $   2,787/mes [OK    ]   p95=  1203ms [OK]

Solo cascade+cache mete la feature en su presupuesto de costo. El cascade
solo recorta, pero no basta: la cache —no repagar lo repetido— cierra la brecha.

Lee la tabla de arriba y luego la comparación contra el presupuesto, porque juntas cuentan la historia completa del paso 2.

Cada palanca recorta, y el recorte se compone. El baseline all_strong (todo al modelo caro) cuesta $9.55 por 1000 tickets. El cascade lo baja a $5.06 —casi la mitad—, enrutando el 70% fácil al modelo barato. Y cascade_cache lo baja a $4.65, porque además sirve 383 de los 1000 tickets desde la caché (calls baja de 1000 a 617: 383 tickets nunca llamaron al modelo). El ahorro total es 51.4% frente a mandar todo al caro. Fíjate en que las dos palancas atacan cosas distintas: el cascade abarata las llamadas que se hacen (de $5000 a $500 en las fáciles), la caché elimina llamadas enteras. Por eso se componen —la caché recorta lo que el cascade dejó—.

Pero el número que importa es el del presupuesto, y ahí está la lección honesta. Mira la sección "Contra el presupuesto". A escala de 20,000 tickets/día:

  • all_strong cuesta $5,733/mes → EXCEDE el margen de $3,000. Predecible: mandar todo al caro es caro.
  • cascade cuesta $3,038/mes → EXCEDE. Y este es el punto: el cascade recortó casi la mitad y aun así se queda por encima del presupuesto, apenas —por 38 dólares, pero por encima—. Una feature que cuesta $3,038 cuando el margen es $3,000 no llega a producción; "casi cabe" es no caber.
  • cascade_cache cuesta $2,787/mes → OK. Solo componiendo las dos palancas la feature entra en su presupuesto.

Ese es el argumento entero del paso 2: ninguna palanca sola es una bala de plata. El cascade es la palanca más famosa y la más grande, y sin embargo sola no basta para esta feature —recorta el 47% y se queda a un pelo por encima del margen—. Hace falta la caché para cerrar la brecha. Un arquitecto que aplica solo el cascade y declara "listo, ya optimicé el costo" mete a producción una feature que excede su presupuesto por poco; uno que compone cascade + caché la mete dentro. La diferencia entre las dos es exactamente esos 38 dólares que separan "EXCEDE" de "OK".

Y una nota sobre la latencia, honesta como en el módulo 2. El p95 de las tres estrategias es prácticamente idéntico (~1200 ms) y todas caben en el latency_budget de 4000 ms. El cascade y la caché bajaron el promedio (de 837 a 416 ms) pero no la latencia de cola —las queries difíciles siguen yendo al modelo lento en todas las estrategias—. Aquí eso no es un problema (1200 ms cabe de sobra en el presupuesto de 4 segundos del soporte), pero es el mismo matiz del módulo 2: el cascade arregla el costo y la latencia media, no la de cola. Si el presupuesto de latencia fuera estricto (como en la búsqueda), harían falta streaming u otras técnicas —pero esta feature tiene holgura, así que el cascade + caché resuelven su paso 2 completo—.

Profundización: componer palancas y el clasificador como pieza nueva

El presupuesto es una restricción de negocio, no un número técnico. ¿De dónde salen los $3,000/mes y los 4,000 ms? No de la ingeniería. El cost_budget viene del margen que el negocio puede gastar en soporte de IA; el latency_budget, de cuánto está dispuesto a esperar un cliente antes de frustrarse. Igual que el umbral del eval (lección 4) viene del riesgo, el presupuesto viene del negocio. La ingeniería no inventa el presupuesto; lo recibe y diseña para caber dentro. Por eso el veredicto "EXCEDE/OK" no es una opinión técnica —es la feature contra una línea que el negocio trazó—. Un presupuesto que la ingeniería inventa sin hablar con quien paga la factura es un cartel sin autoridad, como advertía el módulo 2.

El clasificador es una pieza nueva, determinista y barata, que gobierna a los caros. El cascade introdujo algo que las lecciones siguientes reusan: una pieza —el clasificador— que vive antes del LLM y decide a cuál llamar. Es determinista (una heurística o un modelo diminuto), barata (no cuesta una llamada al modelo grande), y su trabajo es solo enrutar, no responder. Es el primer ejemplo de un patrón que recorre todo el capstone: componentes deterministas y baratos que gobiernan a los probabilísticos y caros. El clasificador gobierna a qué modelo va cada ticket; los guardrails (lección 5) gobiernan qué propuestas pasan; la cáscara (lección 7) gobierna qué acciones se ejecutan. Todos son código determinista rodeando y controlando al núcleo probabilístico.

El cascade tiene un riesgo de calidad que el eval (lección 4) cubre. El clasificador es imperfecto (92% en el ejemplo), y a veces manda una query difícil al modelo barato, que puede responderla peor. El cascade, entonces, ahorra pero introduce un riesgo de calidad —el mismo que la lección 4 va a atrapar cuando la "regresión" que falla el eval gate resulte ser justamente un ahorro de costo mal calibrado (bajar demasiado al modelo barato)—. Aquí está la conexión entre las dos lecciones: el cascade te da el ahorro, el eval te confirma que el ahorro no vino a costa de la calidad. Por eso se calibra el clasificador para que en la duda escale (prefiera pagar de más por una fácil que responder mal una difícil), y por eso el paso 3 (presupuesto) y el paso 4 (eval) van juntos: optimizar el costo sin un eval que vigile la calidad es optimizar a ciegas.

Errores comunes

Aplicar una sola palanca y declarar el presupuesto resuelto. Qué pasa: el equipo mete el cascade, ve que el costo baja casi a la mitad, y concluye "ya optimizamos, cabe en presupuesto" sin comparar contra el margen real. En este ejemplo, el cascade solo deja la feature en $3,038/mes cuando el margen es $3,000 —excede por poco, pero excede—, y a fin de mes la factura llega por encima del presupuesto. Por qué pasa: un recorte grande (47%) se siente como suficiente, y es fácil no verificar contra el número exacto del negocio. Cómo detectarlo: aplicaste una técnica de optimización pero nunca comparaste el costo resultante contra el cost_budget de la hoja. Cómo corregirlo: mide contra el presupuesto, no contra el baseline. "Bajó 47%" no es el veredicto; "cabe en $3,000/mes" o "no cabe" lo es. Y si una palanca no basta, compón otra —el cascade + caché es lo que cierra la brecha—.

Confiar en un clasificador perfecto. Qué pasa: el diseño asume que el clasificador siempre acierta y no planea para los errores de enrutamiento. En producción, el clasificador manda algunas queries difíciles al modelo barato, que las responde peor, y la calidad se degrada sin que nadie lo note —hasta que el eval gate (lección 4) lo atrapa, o peor, hasta que un cliente se queja—. Por qué pasa: en el diagrama el clasificador se dibuja como una caja que "decide la dificultad", y es fácil olvidar que se equivoca. Cómo detectarlo: tu cascade no tiene un eval que verifique la calidad de las queries enrutadas al barato. Cómo corregirlo: calibra el clasificador para escalar en la duda (falso positivo barato, no falso negativo caro) y confía en el eval gate para confirmar que abaratar no rompió la calidad. El cascade sin eval es optimizar el costo sin red de seguridad.

Cachear sin pensar la frescura ni la personalización. Qué pasa: el equipo cachea agresivamente para maximizar el hit-rate, y sirve de caché una respuesta que ya no aplica —el estado del pedido cambió, la política de devoluciones se actualizó, o la respuesta era específica de otro cliente—. El ahorro es real pero la respuesta es incorrecta. Por qué pasa: se optimiza el hit-rate como si toda respuesta fuera cacheable, sin distinguir lo que es estable (una FAQ de horarios) de lo que es volátil o personal (el estado de tu pedido). Cómo detectarlo: tu caché no distingue respuestas estables de respuestas dependientes del estado o del usuario. Cómo corregirlo: cachea solo lo que es estable e impersonal (FAQs, respuestas de política), y para lo volátil, o no caches o usa un TTL corto. En el ejemplo, las preguntas repetidas cacheables son las de política general (horarios, cómo devolver), no "¿dónde está mi pedido A-1234?" —esa se calcula fresca cada vez—.

Ejercicios

Ejercicio 1 — ¿Cuánta caché haría falta para caber solo con caché? Supón que quitas el cascade (todo al modelo caro) pero subes el hit-rate de la caché. Con all_strong a $9.5544/1000 tickets y un margen de $2,787/mes como objetivo (el que logró cascade+cache) a 20,000 tickets/día, ¿qué fracción de tickets tendría que servir la caché para caber? Razona el cálculo y comenta si es realista.

Ver solución

A 20,000 tickets/día, el mes tiene 600,000 tickets (factor de escala 600 sobre los 1000 del experimento). Con all_strong a $9.5544/1000, el costo mensual sin caché es 9.5544 × 600 = $5,732.6/mes. Para bajar a $2,787/mes, necesitas eliminar la fracción de costo correspondiente:

  • fracción de costo que sobra = (5732.6 − 2787) / 5732.6 = 2945.6 / 5732.6 ≈ 0.514, o sea 51.4%.

Como cada ticket cacheado elimina su costo entero (no llama al modelo), servir el 51.4% de los tickets desde caché lograría el mismo costo que cascade+cache. Es decir: necesitarías un hit-rate del ~51%.

¿Es realista? Depende del workload, pero es alto —más alto que el 38.3% que la caché logró en el ejemplo (383/1000)—. Un hit-rate del 51% exigiría que más de la mitad de los tickets sean preguntas repetidas y cacheables, lo cual es optimista para soporte (muchos tickets son específicos de un pedido, no cacheables). La moraleja: se podría caber solo con caché si el hit-rate fuera altísimo, pero es más robusto componer —el cascade abarata lo que no se cachea, y la caché elimina lo repetido—, porque así ninguna palanca tiene que hacer todo el trabajo sola. Componer dos palancas moderadas (cascade 47% + caché 38%) es más alcanzable que exprimir una sola al 51%.

Ejercicio 2 — El presupuesto que no cabe ni con las dos palancas. Imagina que el negocio baja el cost_budget a $2,000/mes (en vez de $3,000). Con cascade+cache a $2,787/mes, la feature ya no cabe. Nombra tres decisiones de arquitectura (no de optimización de inferencia, que es AI Eng) que podrías tomar para meterla, y el trade-off de cada una.

Ver solución

Tres decisiones de arquitectura para meter la feature en $2,000/mes:

  1. Subir el hit-rate de la caché con caché semántica. En vez de cachear solo queries idénticas, cachear por intención (dos formas de preguntar "¿dónde está mi pedido?" comparten respuesta de plantilla). Sube el hit-rate y baja el costo. Trade-off: una caché semántica puede servir la respuesta equivocada si dos queries parecen similares pero no lo son —hay que calibrar el umbral de similitud, y eso rinde cuentas al eval—.
  2. Mover más tráfico al fallback determinista para las FAQ. Las preguntas más comunes (rastreo, política de devoluciones) podrían responderse siempre con plantillas deterministas (sin IA), reservando el modelo solo para lo que de verdad necesita razonamiento. Trade-off: las plantillas son más rígidas y menos naturales; si cubren mal un caso, la calidad baja (el eval gate lo vigila).
  3. Reservar el modelo caro para un umbral de dificultad más alto. Recalibrar el clasificador para que menos queries se consideren "difíciles", mandando más al barato. Baja el costo. Trade-off: es el peligroso —más falsos negativos (difíciles al barato) degradan la calidad—; solo es aceptable si el eval gate confirma que la calidad se sostiene. Es exactamente la tensión costo/calidad que la lección 4 gobierna.

Lo que no cuenta como decisión de arquitectura aquí: cuantizar el modelo, cambiar el hardware de inferencia, o afinar un modelo más pequeño y barato —todo eso es optimización de inferencia, que vive en AI Engineering/infra, del otro lado de la frontera—. El arquitecto compone caché, fallback determinista y calibración del cascade; el ingeniero de IA optimiza el modelo por dentro.

Ejercicio 3 — Por qué el p95 no cambió y por qué aquí no importa. En la tabla, el p95_ms de las tres estrategias es ~1200 ms —el cascade y la caché no lo bajaron—. Explica por qué el cascade no baja la latencia de cola, y por qué en esta feature (a diferencia de la búsqueda) no es un problema.

Ver solución

El cascade no baja la latencia de cola porque el p95 —la latencia del peor 5%— la dominan las queries difíciles, y esas siguen yendo al modelo caro y lento en todas las estrategias. El cascade abarata y acelera las fáciles (que van al modelo barato), pero las difíciles tardan lo que tardaban (300 ms base + 300 tokens × 3 ms/token = 1200 ms). Como el p95 lo fijan justamente las difíciles, no se mueve. La caché tampoco lo baja: sirve de un tirón las repetidas (bajando el promedio), pero las difíciles no repetidas siguen pagando su latencia completa. Es el matiz honesto del módulo 2: el cascade arregla el costo y la latencia media, no la de cola.

Por qué en esta feature no importa: el latency_budget del agente de soporte es 4000 ms, y el p95 es 1200 ms —cabe con muchísima holgura—. Un cliente que abre un ticket de soporte espera una respuesta en segundos, no en milisegundos; 1.2 segundos en el peor caso es perfectamente aceptable. En la búsqueda semántica, en cambio, el presupuesto de latencia es estricto (el usuario espera resultados casi instantáneos, cientos de milisegundos), y ahí un p95 de 1200 ms sí sería un problema —haría falta streaming u otra técnica para la cola—. La lección: si la técnica arregla el problema equivocado (el cascade no arregla la cola), no la culpes; verifica si el problema que no arregla te importa en esta feature. Aquí, con holgura de latencia, el cascade + caché resuelven el paso 2 completo. La misma técnica, evaluada contra el presupuesto de cada feature.

Resumen y siguiente paso

En esta lección llenaste los campos latency_budget y cost_budget de la hoja con las dos palancas del módulo 2: el model cascade (barato primero) y la caché (no repagar lo repetido), medidas sobre 1000 tickets del agente de soporte. Viste, con el call center y su guion de respuestas frecuentes, cómo el cascade abarata cada llamada y la caché elimina llamadas enteras, y cómo se componen. Y aprendiste la lección honesta del paso 2: ninguna palanca sola basta —el cascade recortó el 47% y se quedó a un pelo por encima del margen ($3,038 contra $3,000), y solo cascade + caché metió la feature en su presupuesto ($2,787/mes, OK)—. Mediste contra el presupuesto, no contra el baseline, porque "casi cabe" es no caber. Y viste que el clasificador del cascade es la primera pieza determinista que gobierna al núcleo probabilístico, un patrón que recorre todo el capstone.

Antes de avanzar deberías poder: medir el costo de una feature contra su presupuesto (no contra el baseline); explicar por qué el cascade y la caché atacan cosas distintas y se componen; argumentar por qué ninguna palanca sola es una bala de plata; y reconocer que el ahorro del cascade rinde cuentas al eval (abaratar sin verificar la calidad es optimizar a ciegas).

La lección 4 toma el campo eval_gate de la hoja y monta la compuerta de calidad que gobierna el deploy: el eval gate. Vas a ejecutar la compuerta sobre dos versiones del agente —la candidata a producción, que pasa, y una regresión que falla— y vas a ver que la regresión que se bloquea es justamente el ahorro de costo mal calibrado de esta lección (bajar demasiado al modelo barato). El presupuesto y el eval, atados: el cascade te dio el ahorro, y ahora el eval confirma que el ahorro no rompió la calidad.

Recursos

  • martinfowler.com — "Emerging Patterns in Building GenAI Applications", Bharani Subramaniam y Martin Fowler — el marco de tratar los building blocks de una app GenAI como decisiones de arquitectura; el respaldo conceptual del paso 2 de esta lección. (El routing entre modelos y la caché los mide el código de este paso; la doc de prompt-caching de Anthropic cubre la caché en detalle.) En inglés.
  • Chip Huyen — AI Engineering (O'Reilly) — el tratamiento sistemático del enrutamiento por dificultad, la caché y el trade-off costo/calidad que las dos palancas de esta lección explotan. En inglés.
  • Anthropic — Models overview (docs de Claude) — el panorama de familias de modelos por capacidad y precio, la escalera real (pequeño → mediano → grande) sobre la que se monta un cascade, sin fijar versión. En inglés.
  • architecture-for-ai-native-systems-guide, Módulo 2 (este ecosistema) — el tratamiento a fondo del presupuesto, el cascade, la caché y el streaming, incluido el matiz de por qué el p95 no baja con el cascade. Esta lección aplica al agente de soporte lo que el M2 desarrolló. En español.
← AnteriorUbica el componente y su contratoSiguiente →El eval gate