Saltar al contenido principal
Esencial•8–12 horas

Laboratorio de envolvente de release para serving de IA

Construye un contrato de release gobernado para un runtime de IA: fingerprint exacto de modelo/configuración, checks de readiness, reintentos acotados, canary, rollback y verificación del runtime en vez de asumir que un CI verde ya representa la verdad de producción.

serving de IAenvolventes de releaseverificación de runtimedespliegue canaryrollbackingeniería de fiabilidad

Escenario

Tarea

El equipo cambia el modelo, prompt, índice de retrieval o configuración de tools y obtiene CI verde. Producción aún puede ejecutar otra revisión del modelo, un prompt obsoleto, un índice incompleto o scopes antiguos de tools. Construye una envolvente de release que vincule el candidato verificado con el runtime real y demuestre que canary y producción ejecutan exactamente la configuración probada.

Ejecución paso a paso

1. Define una unidad de release más amplia que un commit de Git

Resultado: El equipo puede identificar sin ambigüedad la configuración de comportamiento realmente verificada.

Tareas

  • →Recopilar el fingerprint de código/modelo/prompt/retrieval/tools/policy/dependencias
  • →Registrar identificadores de versión inmutables o resolubles
  • →Asignar owner a cada componente mutable
  • →Prohibir aliases ambiguos en evidencia de producción sin resolver la versión exacta

Comprobaciones

  • ✓Una envolvente aprobada corresponde a una configuración reproducible
  • ✓Cambiar un alias de modelo o índice de retrieval cambia el fingerprint
  • ✓Los secrets no entran en el artefacto de evidencia

2. Construye el contrato de readiness y fallo

Resultado: El runtime no acepta tráfico si una dependencia crítica o el estado de policy no están listos.

Tareas

  • →Separar liveness y readiness
  • →Definir timeout, cancelación y reintentos acotados
  • →Añadir health de provider/retrieval/tools
  • →Definir modos degradados y condiciones de parada

Comprobaciones

  • ✓Un fallo de readiness no queda oculto por liveness exitoso
  • ✓El presupuesto de reintentos no crea un retry storm
  • ✓El modo degradado no amplía authority ni data scope

3. Ejecuta un rollout por etapas

Resultado: El candidato obtiene exposición limitada en producción antes de la promoción completa.

Tareas

  • →Ejecutar shadow o replay donde sea posible
  • →Asignar una cohorte canary
  • →Comparar señales de calidad, fiabilidad y coste con la baseline
  • →Registrar un veredicto explícito promote/hold/rollback

Comprobaciones

  • ✓Una regresión crítica de safety o authority bloquea la promoción sin importar el score agregado
  • ✓La ventana de observación del canary corresponde al risk class
  • ✓El objetivo de rollback se verifica antes del rollout

4. Demuestra la verdad del runtime

Resultado: El estado de producción se confirma con evidencia del runtime y no por haber terminado el pipeline.

Tareas

  • →Leer el fingerprint real del runtime
  • →Compararlo con la envolvente aprobada
  • →Simular un mismatch de modelo/prompt/índice obsoleto
  • →Guardar un artefacto de verificación del deployment

Comprobaciones

  • ✓Un mismatch termina en FAIL o UNKNOWN, nunca PASS
  • ✓CI PASS no sustituye la verificación del deployment
  • ✓El rollback también se confirma con el fingerprint real del runtime

Criterios de aceptación

  • La envolvente versiona código, modelo, prompt, retrieval, tools, policies, dependencias y dataset de evaluación
  • Readiness verifica dependencias críticas de IA y tiene reglas acotadas de timeout/reintento/cancelación
  • El canary tiene criterios explícitos de promote/hold/rollback y un objetivo known-good de rollback
  • La verificación de producción compara por máquina el fingerprint real con la envolvente aprobada
  • Una configuración de runtime obsoleta o divergente no puede recibir PASS