abmodelrouting

Implementa un sistema de routing A/B para evaluar nuevas versiones de modelos de machine learning en producción dentro del pipeline de verificación de identidad. Permite dirigir un porcentaje configurable del tráfico de verificación a un modelo candidato (ej: ArcFace v2) mientras el modelo de control (ej: ArcFace v1) sirve el resto, recopilando métricas comparativas de FAR, FRR y latencia para tomar decisiones de promoción basadas en datos.

When to use

Usa esta skill cuando necesites evaluar una nueva versión de modelo ML en producción dentro del modelserveragent. Aplica cuando se tenga un modelo candidato que haya pasado validación offline pero se requiera confirmar su rendimiento con tráfico real de verificación antes de hacer un rollout completo.

Instructions

1. Definir la configuración del experimento A/B:

``python @dataclass class ABExperiment: experimentid: str modelname: str # ej: "arcface" controlversion: str # ej: "1.0.0" candidateversion: str # ej: "2.0.0" trafficsplit: float # 0.0 a 1.0, porcentaje al candidato startdate: datetime minsamples: int # mínimo de verificaciones para significancia status: str # "running", "completed", "aborted" metricsconfig: dict # métricas a comparar: ["far", "frr", "latency_p95"] ``

1. Implementar el router que asigna cada solicitud de verificación al modelo control o candidato:

```python class ABRouter: def init(self, experiment: ABExperiment): self.experiment = experiment self.controlmodel = loadmodel(experiment.controlversion) self.candidatemodel = loadmodel(experiment.candidateversion)

def route(self, sessionid: str) -> tuple[str, Model]: # Hash determinista por sessionid para consistencia hashvalue = int(hashlib.sha256(sessionid.encode()).hexdigest(), 16) if (hashvalue % 100) / 100 < self.experiment.trafficsplit: return "candidate", self.candidatemodel return "control", self.controlmodel ```

1. Registrar los resultados de cada verificación asociados al grupo (control/candidato):

``python class ABMetricsCollector: def record(self, experimentid: str, group: str, sessionid: str, prediction: dict, groundtruth: dict = None): self.db.insert({ "experimentid": experimentid, "group": group, "sessionid": sessionid, "similarityscore": prediction["score"], "ismatch": prediction["ismatch"], "latencyms": prediction["latencyms"], "timestamp": datetime.utcnow() }) ``

1. Implementar el análisis estadístico para determinar si la diferencia entre modelos es significativa:

```python from scipy import stats

def analyzeexperiment(self, experimentid: str) -> dict: controlscores = self.getscores(experimentid, "control") candidatescores = self.getscores(experimentid, "candidate")

tstat, pvalue = stats.ttestind(controlscores, candidatescores) controlfar = self.calculatefar(experimentid, "control") candidatefar = self.calculatefar(experiment_id, "candidate")

return { "pvalue": pvalue, "controlfar": controlfar, "candidatefar": candidatefar, "issignificant": pvalue < 0.05, "recommendation": "promote" if candidatefar < controlfar and pvalue < 0.05 else "keepcontrol" } ```

1. Configurar guardrails automáticos que detengan el experimento si el modelo candidato degrada métricas críticas:

``python def checkguardrails(self, experimentid: str): candidatefar = self.calculatefar(experimentid, "candidate") if candidatefar > 0.001: # FAR > 0.1% -> abortar self.abortexperiment(experimentid) self.alert("AB experiment aborted: candidate FAR exceeded threshold") ``

1. Exponer un dashboard o endpoint con métricas en tiempo real del experimento: FAR, FRR, latencia p50/p95, volumen de muestras por grupo y significancia estadística actual.

1. Al completar el experimento, generar un informe automático y, si el candidato es superior, integrarse con la skill model_versioning para promover la nueva versión.

Notes

• El routing debe ser determinista por session_id para que todas las llamadas de una misma verificación (embedding, comparación) usen el mismo modelo, evitando inconsistencias en los resultados.
• Comenzar con un traffic split conservador (5-10% al candidato) e incrementar gradualmente solo si los guardrails no se activan; nunca iniciar un experimento con mas del 20% en el candidato sin validación previa.
• Los experimentos A/B en modelos de seguridad KYC requieren un volumen mínimo significativo (recomendado >1000 verificaciones por grupo) antes de tomar decisiones de promoción; resultados prematuros pueden ser engañosos.