MCP HubMCP Hub
Volver a habilidades

run-ab-test-models

pjt222
Actualizado Yesterday
1 vistas
17
2
17
Ver en GitHub
Pruebasaitestingdesigndata

Acerca de

Esta habilidad permite realizar pruebas A/B para modelos de ML en producción mediante la división de tráfico y análisis estadístico. Facilita implementaciones canario y medición de rendimiento para tomar decisiones de despliegue basadas en datos. Úsela para validar nuevas versiones de modelos, comparar algoritmos o cumplir con requisitos de implementación gradual.

Instalación rápida

Claude Code

Recomendado
Principal
npx skills add pjt222/agent-almanac -a claude-code
Comando PluginAlternativo
/plugin add https://github.com/pjt222/agent-almanac
Git CloneAlternativo
git clone https://github.com/pjt222/agent-almanac.git ~/.claude/skills/run-ab-test-models

Copia y pega este comando en Claude Code para instalar esta habilidad

Documentación

Run A/B Test for Models

See Extended Examples for complete configuration files and templates.

Execute controlled experiments comparing model versions using traffic splitting and statistical analysis.

Cuándo Usar

  • Deploying new model version and want to validate improvement before full rollout
  • Comparing multiple candidate models trained with different algorithms or features
  • Testing impact of hyperparameter changes on business metrics
  • Need to measure model performance in production without risking full traffic
  • Regulatory requirements for gradual rollout (e.g., medical ML systems)
  • Evaluating cost-performance tradeoffs between model sizes

Entradas

  • Requerido: Champion model (current production version)
  • Requerido: Challenger model(s) (new version to test)
  • Requerido: Traffic allocation percentage (e.g., 5% to challenger)
  • Requerido: Success metrics (business and ML metrics)
  • Requerido: Minimum sample size or test duration
  • Opcional: Guardrail metrics (latency, error rate thresholds)
  • Opcional: User segments for stratified testing

Procedimiento

Paso 1: Design Experiment

Define test parameters, success criteria, and statistical requirements.

# ab_test/experiment_config.py
from dataclasses import dataclass
from typing import List, Dict
import numpy as np
from scipy.stats import norm


@dataclass
# ... (see EXAMPLES.md for complete implementation)

Esperado: Experiment configuration with statistically sound sample size calculation, typically 5-10k samples per variant for 5-10% MDE.

En caso de fallo: If required sample size too large, increase traffic allocation, extend test duration, or accept larger MDE; verify baseline metric estimate is accurate; consider sequential testing for continuous monitoring.

Paso 2: Implement Traffic Splitting

Set up routing logic to randomly assign requests to models.

# ab_test/traffic_router.py
import hashlib
import random
from typing import Dict, Optional
from dataclasses import dataclass
import logging

logger = logging.getLogger(__name__)
# ... (see EXAMPLES.md for complete implementation)

Esperado: Consistent user-to-variant assignment, accurate traffic split matching configured percentages, all assignments logged for analysis.

En caso de fallo: Verify hash function produces uniform distribution (test with 10k user IDs), check that user_id is stable across requests (not session_id), ensure logs capture all prediction events, validate traffic split in first 1000 requests.

Paso 3: Implement Shadow Deployment (Optional)

Run challenger model in parallel without affecting users (shadow mode).

# ab_test/shadow_deployment.py
import asyncio
from typing import Dict, Any
import logging
from concurrent.futures import ThreadPoolExecutor
import time

logger = logging.getLogger(__name__)
# ... (see EXAMPLES.md for complete implementation)

Esperado: Champion predictions served with normal latency, challenger predictions logged asynchronously without blocking, prediction differences captured for analysis.

En caso de fallo: Set challenger timeout < champion SLA to avoid blocking, handle challenger errors gracefully without affecting champion, monitor memory usage (two models loaded), consider sampling (log only 10% of shadow predictions).

Paso 4: Collect and Analyze Metrics

Gather experiment data and perform statistical tests.

# ab_test/analysis.py
import pandas as pd
import numpy as np
from scipy import stats
from typing import Dict, Tuple
import logging

logger = logging.getLogger(__name__)
# ... (see EXAMPLES.md for complete implementation)

Esperado: Statistical test results with p-values, confidence intervals, and clear decision (rollout/keep/inconclusive), typically after 7-14 days or reaching sample size.

En caso de fallo: Verify ground truth labels are available (may need delayed analysis), check for sample ratio mismatch (SRM) indicating assignment bugs, ensure sufficient sample size reached, look for novelty/primacy effects in early data, consider sequential testing if fixed-horizon test is too slow.

Paso 5: Monitor Guardrail Metrics

Continuously check that challenger doesn't violate safety thresholds.

# ab_test/guardrails.py
import pandas as pd
import logging
from typing import Dict, List

logger = logging.getLogger(__name__)


# ... (see EXAMPLES.md for complete implementation)

Esperado: Guardrail violations detected within 5-15 minutes, automated experiment stop if critical thresholds breached (latency, errors), alerts sent to team.

En caso de fallo: Verify guardrail thresholds are realistic (not too tight), ensure monitoring loop is running continuously, check that stop_experiment() function actually updates routing, test alert delivery channels.

Paso 6: Make Rollout Decision

Based on experiment results, decide whether to rollout challenger.

# ab_test/rollout_decision.py
import logging
from typing import Dict
from dataclasses import dataclass

logger = logging.getLogger(__name__)


# ... (see EXAMPLES.md for complete implementation)

Esperado: Clear decision (full/gradual rollout, keep champion, or extend test) with justification and action items.

En caso de fallo: If decision unclear, perform subgroup analysis (by user segment, time of day, device type), check for interaction effects, review business context (e.g., is 2% lift worth engineering cost?), consult with stakeholders.

Validación

  • Traffic split matches configured percentages (within 1%)
  • Same user always assigned to same variant (consistency check)
  • Sample size calculation produces reasonable numbers (5-50k per variant)
  • Statistical tests produce p-values consistent with manual calculation
  • Guardrail violations trigger alerts within 5 minutes
  • Shadow deployment shows <5% prediction divergence between models
  • Experiment reports include confidence intervals
  • Rollout decision documented with justification

Errores Comunes

  • Sample ratio mismatch (SRM): If observed traffic split differs from configured (e.g., 95/5 becomes 92/8), indicates assignment bug; check hash function uniformity
  • Peeking: Checking results before reaching sample size inflates Type I error; use sequential testing or wait for pre-determined end date
  • Novelty effect: Users respond differently to new model initially; run for 2+ weeks to see steady-state behavior
  • Carryover effects: Previous variant exposure affects current behavior; use new users or sufficient washout period
  • Multiple testing: Testing many metrics increases false positive risk; correct with Bonferroni or focus on single primary metric
  • Insufficient power: Small traffic allocation may require months to detect realistic effects; balance statistical power with risk tolerance
  • Ignoring segments: Aggregate lift may hide negative impact on important user segments; perform subgroup analysis
  • Attribution errors: Ensure outcome metrics correctly attributed to model predictions (not other system changes)

Habilidades Relacionadas

  • deploy-ml-model-serving - Model deployment infrastructure and versioning
  • monitor-model-drift - Ongoing performance monitoring post-rollout

Repositorio GitHub

pjt222/agent-almanac
Ruta: i18n/es/skills/run-ab-test-models
0
agentsagentskillsai-assisted-developmentclaude-codeskillsteams

Habilidades relacionadas

evaluating-llms-harness

Pruebas

Esta Skill de Claude ejecuta el benchmark lm-evaluation-harness para evaluar modelos de lenguaje en más de 60 tareas académicas estandarizadas como MMLU y GSM8K. Está diseñada para que los desarrolladores comparen la calidad de los modelos, realicen seguimiento del progreso del entrenamiento o reporten resultados académicos. La herramienta admite varios backends, incluidos modelos de HuggingFace y vLLM.

Ver habilidad

cloudflare-cron-triggers

Pruebas

Esta habilidad proporciona conocimiento integral para implementar Cron Triggers de Cloudflare y programar Workers mediante expresiones cron. Cubre la configuración de tareas periódicas, trabajos de mantenimiento y flujos de trabajo automatizados, manejando problemas comunes como expresiones cron inválidas y inconvenientes de zonas horarias. Los desarrolladores pueden utilizarla para configurar manejadores programados, probar activadores cron e integrar con Workflows y Green Compute.

Ver habilidad

webapp-testing

Pruebas

Esta habilidad de Claude proporciona un kit de herramientas basado en Playwright para probar aplicaciones web locales mediante scripts de Python. Permite verificación de frontend, depuración de interfaz de usuario, captura de pantallas y visualización de registros, mientras gestiona los ciclos de vida del servidor. Úsela para tareas de automatización de navegadores, pero ejecute los scripts directamente en lugar de leer su código fuente para evitar contaminación del contexto.

Ver habilidad

finishing-a-development-branch

Pruebas

Esta habilidad ayuda a los desarrolladores a completar el trabajo terminado verificando que las pruebas pasen y luego presentando opciones estructuradas de integración. Guía el flujo de trabajo para fusionar, crear PRs o limpiar ramas después de que se completa la implementación. Úsala cuando tu código esté listo y probado para finalizar sistemáticamente el proceso de desarrollo.

Ver habilidad