M2 · Enterprise Integration & Production — Resumen de estudio

Curso 2 de 5 · 20 pantallas, 5 secciones, 6 checkpoints

Es lo que separa un prototipo de un sistema en producción: evals → cost/reliability → sizing/feasibility → integración → A/B y observabilidad.

1. Evals como criterio de aceptación (se escriben ANTES del código)

Por qué antes:

  1. Obligan a definir el éxito en términos medibles.
  2. Exponen supuestos de diseño cuando todavía es barato cambiarlos.
  3. Dan un gate para cada cambio (modelo, prompt, retrieval).

"Si no puedes escribir un eval para un comportamiento, no tienes forma de medir si está presente."

Workflow del eval (cada etapa produce un artefacto):

  1. Define the task: especificación + prompt + criterios de aprobación.
  2. Golden dataset: entradas representativas, edge cases y contraejemplos, con salidas esperadas.
  3. Automated checks: pasa/falla por ítem.
  4. Score with a judge: puntaje + razonamiento para lo interpretativo.
  5. Interpret & act: desglose por categoría. Subir la media degradando edge cases no es mejorar.

Tipos de eval:

TipoPara quéCostoLímite
Code-basedLo inequívoco: schema, regex, JSON, longitud, comparación con dato autoritativoCasi ceroNo evalúa tono, razonamiento ni utilidad
Model-based (LLM judge)Lo interpretativo: calidad, seguimiento de instrucciones, razonamiento, seguridad1 llamada por ítemInconsistente en casos límite; pide razonamiento junto al puntaje
Human reviewAlto riesgo, capacidades nuevas, calibrar juecesEl más altoLento y no escala (usar muestreo)

Grading ladder: code primero → LLM judge (rúbrica detallada, veredictos restringidos, calibrado contra etiquetas humanas, un modelo distinto al evaluado para evitar el sesgo de autopreferencia) → humano como último recurso.

De requisito a criterio de éxito:

  1. Comportamiento específico: "extraer nombre, número de claim, fecha y monto".
  2. Umbral que sale del requisito de negocio, no de lo que logró el prototipo (p. ej. 100% en campos estructurados, <2% de hallucination, 99.5% dentro del schema).
  3. Failure modes como categorías del dataset.
  4. Entradas adversariales (campos faltantes, manuscritos, formatos raros).

⚠️ Watch out: se probó con 10 contratos "conocidos", se cambió el prompt sin actualizar el dataset y fallaron los contratos con obligaciones no estándar. Fueron dos errores: dataset no representativo y no actualizado. Los spot-checks manuales no reemplazan un eval.

Checkpoint (code vs model): code = 1 JSON schema, 3 longitud <500 tokens, 5 claim number vs fuente, 7 secciones presentes · model = 2 razonamiento, 4 queja emocional, 6 resumen captura lo importante, 8 tono de marca.

2. De POC a producción: costo, latencia, confiabilidad y failure modes

Las 4 dimensiones son invisibles en una demo. Además, mide en el POC la métrica de negocio: un costo dentro del presupuesto sin mejora medible sigue siendo un fracaso.

Controles de confiabilidad (cada uno en su capa):

ControlQué haceDónde va
Retries con exponential backoff429, timeouts, 5xx (529 = overloaded)Junto a la llamada a la API
Fallback chainsOtro tier o respuesta cacheada en vez de mostrar un error (pruébalo en los evals)Capa de orquestación
Circuit breakerCorta cuando el error rate supera un umbral; falla rápidoLímite del servicio

Failure modes por arquitectura:

Model version pinning aplica a todas: fija versiones, monitorea la página de deprecations y ten un runbook de actualización.

⚠️ Watch out: se usó el costo del POC como el costo de producción. (1) Volumen equivocado. (2) La cola de documentos largos se llevaba el 80% del gasto. (3) Un error 529 en el pico tumbó todo porque no había fallback. El POC prueba capacidad, no costo ni confiabilidad.

Calculadora (checkpoint): 50k req/mes, system prompt de 5k tokens, techo de $800 y p95 ≤3 s → la palanca es B: prompt caching (el prompt estable es el principal costo de input).

3. Sizing y feasibility

Sizing (4 pasos, antes del código):

  1. Volumen: pídeselo al dueño del negocio, no lo saques de un dataset de muestra.
  2. Token budget: modela la distribución, no el promedio. El caching requiere marcadores cache_control; escribir en caché cuesta más que el input normal y el TTL por defecto es de 5 min.
  3. Costo mensual: input × tarifa de input + output × tarifa de output (son distintas), usando la tarifa de lectura de caché para lo cacheado. Considera la Batch API (~50% de descuento y hasta 100k requests por batch, verificar) si el SLA permite procesamiento asíncrono. En entornos regulados, verifica que el BAA lo cubra.
  4. Análisis de sensibilidad: ¿qué pasa si se duplica el volumen o la cola crece?

Scoping (4 pasos): requisito → lista de capacidades → esquema de arquitectura (Claude / sistemas / humano) → boundary conditions → alcance en el SOW.

Feasibility con las 4 propiedades:

3 veredictos:

ROI / business value:

⚠️ Watch out: se confirmó feasibility antes de preguntar volumen, tamaño y latencia (800 contratos/día, hasta 300 páginas, <30 s). Que entren en el context window depende del tier (1M vs 200k). A 800/día (1 cada 108 s) el volumen presiona el costo, no la latencia.

Checkpoint: Esc. 1 = B (feasible as scoped) · Esc. 2 = C (feasible with constraints: precisión de extracción en una escritura transaccional, code eval + gate humano) · Esc. 3 = A (not feasible as described: brecha de live state; validar que el round-trip del feed quepa en 2 s).

4. Patrones de integración empresarial

Orden: compliance → entry point/route → patrón de integración → identity → authorization → data handling → observability.

Entry points (vista de integración):

Matriz restricción → integración:

Las 5 capas y qué se rompe:

⚠️ Watch out: resumen de intake clínico con nombre, fecha de nacimiento, SSN e Insurance ID en el user message → miles de SSN en texto plano en los logs. Filtro correcto: la necesidad, no la conveniencia. Solución: redacción del lado del servidor + retrieval solo de los campos necesarios.

Checkpoint (diagrama SaaS): problemas = Claude Code como backend, API key compartida, "soy premium" como control de capacidades, número de cuenta y email en los logs, escritura al CRM sin log · correctos = auth del lado del servidor, aislamiento por tenant en storage.

5. A/B testing y observabilidad

Experimento:

Leer resultados: significancia ≠ relevancia. ¿El efecto justifica el costo operativo? ¿Se degradó alguna métrica secundaria? Ojo con las interacciones con tipos de input (picos estacionales).

Shadow testing: la nueva versión recibe copia del tráfico real, sus salidas se registran sin servirse y se califican offline. Úsalo cuando un solo error es demasiado riesgoso o hay poco tráfico (en industrias reguladas suele ser la única opción). Lo que se pierde es la señal de comportamiento del usuario.

Observabilidad (4 capas):

  1. Tracing por request (modelo, versión, tokens, latencia, stop reason, tool calls).
  2. Métricas agregadas con desglose por request: un agregado sano puede esconder una cola cara o errónea.
  3. Anomalías (p. ej. costo >150% del promedio de 7 días, p95 por encima del SLA, comparación periódica de distribuciones para drift).
  4. Atribución del cambio: model drift vs data drift vs model update.

Failure taxonomy:

Discernment (competencia 4D): clasifica cada salida como aceptable, necesita revisión o necesita override, y alimenta los evals con eso.

Capa de traducción a negocio: task success → first-contact resolution, latencia → handle time. Se construye en el diseño, no después del primer business review.

⚠️ Watch out: 50 vs 50 sesiones (68% vs 62%) → a las dos semanas, 61%. Muestra pequeña, distribución sin controlar, métrica elegida a posteriori. Era confirmación, no evidencia.

Checkpoint (plano efecto × confianza):

Ejercicios resueltos (clave)

Eval framework de la aseguradora:

Production readiness (consultora, 800 req/día, $3k, p95 <8 s):

Para recordar

  1. Evals antes del código y siempre actualizados; son el gate de todo cambio.
  2. Modela costo y p95 a volumen real; retries, fallbacks y circuit breakers desde el diseño.
  3. Las 4 propiedades → veredicto en 3 formas + boundary condition documentada.
  4. Identidad del lado del servidor, datos mínimos en contexto, observabilidad desde el diseño.
  5. Métrica primaria y tamaño de muestra antes; desglose por request; traducción a métricas de negocio.