Implementación de modelos ML

1) Función y objetivos

Implementación = entrega confiable del infierno en el producto y las operaciones, respetando los presupuestos RG/AML/Legal.
Objetivos: baja latencia, alta disponibilidad, reproducibilidad, seguridad y reversibilidad rápida (rollback).

2) Arquitecturas de serving

2. 1 Patrones

En línea (tiempo real): NAT/gRPC, p95 50-150 ms para personalización; ≤2 -5 s para alertas RG/AML.
Near-real-time: microbatches de 1-5 min (vitrinas OLAP).
Batch/offline: vitrinas nocturnas de oro, exportaciones WORM para el regulador.
In-process scoring: incrustar el modelo de luz en el servicio (baja latencia).
Serverless: funciones de inicio en frío para tareas raras.

2. 2 Topologías

El servicio de modelo único → fácil y rápido.
Ensemble/Graph (router → preprocess → model → postprocess) → paiplines complejos.
Sidecar Feature Fetcher → extrae fichas en línea de los cachés (Redis/Scylla).

3) Registro modelo y versiones

Registro: 'model _ id', 'version', 'stage = {Staging, Production, Archived}', artefactos (pesos, preprocesador, calibración), requisitos (CPU/GPU/memoria), tarjeta de modelo (datos, métricas, riesgos, fairness).
Artefactos inmutables: content-hash; Copias WORM de las versiones.
Política de retirada: sólo a través del registro y los manifiestos declarativos.

4) Envase y embalaje

dockerfile
FROM python:3. 11-slim
ENV PYTHONUNBUFFERED=1
WORKDIR /app
COPY requirements. txt.
RUN pip install -r requirements. txt --no-cache-dir
COPY artifacts/./artifacts/
COPY src/./src/
CMD ["python", "src/serve. py"]

python serve. py from fastapi import FastAPI import joblib, time app = FastAPI()
model = joblib. load("artifacts/model. joblib")
scaler = joblib. load("artifacts/scaler. joblib")

@app. post("/score")
def score(payload: dict):
t0 = time. time()
x = preprocess(payload, scaler)
y = float(model. predict_proba([x])[0,1])
return {"score": y, "latency_ms": int((time. time()-t0)1000), "model_version": "1. 8. 3"}

5) Kubernetes/Helm y Auto Scaling

yaml apiVersion: apps/v1 kind: Deployment metadata: {name: ml-score, labels: {app: ml-score}}
spec:
replicas: 3 selector: {matchLabels: {app: ml-score}}
template:
metadata: {labels: {app: ml-score}}
spec:
containers:
- name: api image: registry/ml-score:1. 8. 3@sha256:...
ports: [{containerPort: 8080}]
resources:
requests: {cpu: "500m", memory: "512Mi"}
limits:  {cpu: "2",  memory: "2Gi"}
envFrom: [{secretRef: {name: ml-secrets}}]
readinessProbe: {httpGet: {path: /healthz, port: 8080}, periodSeconds: 5}
livenessProbe: {httpGet: {path: /livez,  port: 8080}, periodSeconds: 10}

yaml apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: {name: ml-score-hpa}
spec:
scaleTargetRef: {apiVersion: apps/v1, kind: Deployment, name: ml-score}
minReplicas: 3 maxReplicas: 50 metrics:
- type: Pods pods:
metric: {name: requests_per_second}
target: {type: AverageValue, averageValue: "15"}
- type: Resource resource: {name: cpu, target: {type: Utilization, averageUtilization: 70}}

6) Estrategias de salida

Shadow (inicio oscuro): el nuevo modelo procesa las copias de las solicitudes, se ignoran las respuestas; comparación métrica/latencia/costo.
Canario: 1-10% de tráfico → 25% → 50% → 100% con SLO verdes; retroceso automático durante la degradación.
Azul-Verde: pilas paralelas; un sweet de enrutamiento instantáneo.
Flag de función de grado: enrutamiento por mercados/tenantes/dispositivos.
A/B/n: experimentos en línea con pruebas secuenciales.

yaml routes:
- match: {tenant: "EEA"} # feature-flags/rules to: {model: "1. 8. 3", weight: 20}
- match: {tenant: "EEA"}
to: {model: "1. 7. 9", weight: 80}

7) Fichi online/offline: equivalencia

Una única biblioteca de transformación y Feature Store (online + offline).
Prueba de equivalencia: MAE/MAPE entre las fichas online y la referencia offline en la muestra de referencia.
Caché fich: Redis/Scylla, TTL para características de ventana; taimouts y fallbacks.

8) Observabilidad, SLO y alerting

8. 1 puntos de referencia SLI/SLO

Latencia: p95 ≤ 150 ms (personalización), p99 ≤ 300 ms; alertas RG/AML ≤ 5 con fin a fin.
Disponibilidad: ≥ 99. 9%.
Error de inferencia: ≤ 0. 5% 5xx; coverage ≥ 99%.
Deriva: PSI fich/skora <umbral, ECE (calibración) es estable.
Бизнес: uplift Net Revenue, fraud saved, time-to-intervene.

8. 2 Métricas (Prometheus)

yaml
- http_request_duration_seconds{quantile="0. 95"}
- http_requests_total{code=~"5.."}
- model_inference_latency_ms_bucket
- feature_fetch_latency_ms_bucket
- model_score_distribution_bucket
- psi_feature_{name}
- expected_cost_live

yaml
- alert: HighP95Latency expr: histogram_quantile(0. 95, sum(rate(model_inference_latency_ms_bucket[5m])) by (le)) > 0. 15 for: 10m
- alert: DriftDetected expr: psi_feature_amount_base > 0. 25 for: 15m

Трейсинг: OpenTelemetry — span’ы `feature_fetch`, `score`, `postprocess`, `guardrail`.

9) RG/AML guardrails y política de seguridad

Pre-/Post-filter: máscaras de actividades prohibidas (frecuencias de espectáculos, cooldown, prohibición de offers agresivos).
Policy Shielding: score por encima del umbral RG → intervención/pausa suave.
Auditoría: lógica de 'policy _ id', 'propensity', 'mask', 'decision', 'reason'.
PII y residencia: tokens en lugar de ID, claves de cifrado individuales y clúster en EEA/UK/BR; Prohibición de la join's cruzada-regional sin fundamento.
Secretos: KMS/CMK, Administrador Secreto; ningún PII en los logs/tries.

10) Calibración, umbrales y políticas de soluciones

Calibración (Platt/Isotonic) como artefacto.
Umbral por costo especulado; configurable en el registro/bandera de ficha.
Safety caps: bordes de acción superior/inferior, override manual para el cumplimiento.

11) Retrocesos, degradación y DR

One-click rollback: cambia la ruta a la anterior 'model _ version'.
Runbook: scripts «latentnost↑», «errores 5xx↑», «deriva/calibración rota», «proveedor de alimentos externo no disponible».
Aislamiento de fallos: circuito breaker, retry/backoff, caché de la última solución válida.
DR: backups de artefactos/registros, replicación a una región «cálida», enseñanzas.

python try:
features = fetch_features(timeout=30)
except TimeoutError:
features = last_known_good(user_id) # fallback

12) Costo-ingeniería y rendimiento

Perfilando la ruta: fichas (30-60%), modelo (20-40%), red/IO (10-30%).
Reducción de costes: almacenamiento en caché de fiches calientes, cuotas de réplicas, modelos lightweight, INT8/FP16 (si procede), lazy-postprocess.
HPA en RPS/CPU/latencia, restricción state-size en stream-fich.
Chargeback: cost/request, cost/feature; presupuestos de mercado/equipo.

13) Lanzamientos seguros y cumplimiento

Criterios de preparación prod: SLO verde en shadow, no hay deriva/fugas, la tarjeta del modelo está llena, las diapositivas fairness son normales.
Regulador: archivo WORM de lanzamiento (pesos, calibración, umbrales, métricas, registros de pruebas), informes de exportación inmutables.
DSAR/RTBF: procedimientos para eliminar rastros de usuarios específicos de cachés/registros/fich.

14) QA antes de rodar

Pruebas de integración: contrato de API, circuitos fich, casos «vacíos/extremos».
Carga: p99, colas de distribución, tráfico burst.
Prueba de equivalencia online/offline.
Pruebas de chaos: apagado de caché/base de fichas, temporizadores de servicios externos.

15) Ejemplos de configuraciones

yaml
- match: [headers: {x-exp: "canary"}]
route:
- destination: {host: ml-score-v1-8-3, weight: 20}
- destination: {host: ml-score-v1-7-9, weight: 80}

python
@app. get("/healthz")
def health():
return {"ok": True, "model_version": "1. 8. 3", "registry_sig_ok": verify_signature()}

16) Procesos y RACI

R (Responsable): MLOps (serving/orquestación/observabilidad), Data Eng (fichas/caches/contratos), Data Science (tarjetas de modelo/calibración/umbrales).
A (Accountable): Head of Data / CDO.

C (Consultado): Cumplimiento/DPO (PII/RG/AML/DSAR), Seguridad (KMS/Secretos/Auditoría), SRE (SLO/Incidentes), Finanzas (ROI/Presupuestos)

I (Informed): Producto/Marketing/Operaciones/Soporte.

17) Hoja de ruta para la aplicación

1. Registro modelo y artefactos inmutables; Servicio FastAPI/gRPC + K8s/Helm.

2. Lanzamiento de sombras con monitoreo p95/5xx/deriva, prueba de equivalencia fich.

3. Canario 10% → 50% → 100% con autoscripción y alertas.

4. Tarjeta de modelo, calibración, umbral de factura y Guardrails v1.

• Ficha caché, circuitos breakers, ejercicios de runbooks/DR.
• Auto skaling en RPS/latency, costa dashboard y chargeback.
• Control de diapositivas fairness, archivo WORM de versiones.

• Gráfico de serving (candidatos → re-rank), lógica slate de propensity.
• Multi-región, residencia (EEA/UK/BR) con claves separadas.
• Auto-enrollado/enrollado a la deriva, informes de calidad/calibración de autogen.

18) Lista de comprobación de disponibilidad

• La tarjeta modelo está llena; datos/fichas/calibración/umbrales versionados.
• Los contratos fich y la prueba de equivalencia online/offline son verdes.
• SLO: p95, 5xx, coverage - verde en shadow y 10% canario ≥ 24 h.
• Se incluyen alertas y dashboards (latencia/errores/deriva/proyección-costo).
• Guardrails RG/AML y las auditorías de soluciones están activas; PII/residencia respetada.
• Se ha probado un solo clic en el rollback y el runbook de incidentes.
• El costo se ajusta al presupuesto; HPA y caché están configurados.

19) Anti-patrones y riesgos

Manuales sin registro y artefactos inmutables.
Los fiches online/offline no coordinados → discrepancias en la venta.
Sin shadow/canary → regresiones ocultas.
El umbral no es por costo especulado, no hay calibración.
lookups externos sincronizados sin temporizadores/caché.
No hay DR/rollback, no hay archivo WORM de lanzamiento.

20) Resultado

La producción de ML no es un «desafío de modelo», sino una plataforma de ingeniería: registro y versiones, descargas seguras (shadow/canary/blue-green), disciplina de fich y calibración, observabilidad y SLO, guardrails para RG/AML y un claro plan de retroceso. Al seguir este playbook, obtendrá un inference rápido, confiable y complaciente que aporta valor comercial de forma constante a un coste controlado.