How to A/B Test Machine Learning Models: A Practical Guide

Your data science team trained a new model, shows AUC lift on test, but business won't deploy without proof on real data. A/B testing ML models is the only way to reliably measure business impact. A metric on a test dataset shows accuracy but doesn't answer the key question: will it bring more money

AI Development Areas

Frequently Asked Questions

Latest works

  • image_web-applications_feedme_466_0.webp
    Development of a web application for FEEDME
    1285
  • image_ecommerce_furnoro_435_0.webp
    Development of an online store for the company FURNORO
    1241
  • image_logo-advance_0.webp
    B2B Advance company logo design
    696
  • image_crm_enviok_479_0.webp
    Development of a web application for Enviok
    983
  • image_logo-aider_0.webp
    AIDER company logo development
    919
  • image_crm_chasseurs_493_0.webp
    CRM development for Chasseurs
    1033

Your data science team trained a new model, shows AUC lift on test, but business won't deploy without proof on real data. A/B testing ML models is the only way to reliably measure business impact. A metric on a test dataset shows accuracy but doesn't answer the key question: will it bring more money or better UX? A properly configured A/B test provides a statistically sound answer with risk control. Our certified MLOps engineers with proven experience have delivered over 100 experiments across 30+ projects — from banking to e-commerce. Inference cost savings from correct model selection can reach 30% of the budget, translating to an average of $15,000 per month for typical enterprise deployments. Seldon Core sets up 3x faster than custom routing on Nginx. For instance, in a recent project for a retail client, we measured a 12% increase in average order value with a p-value of 0.003. With A/B testing ML models, you can confidently assess business impact. Contact us for an audit of your infrastructure.

Why ML A/B is harder than classic?

In classic A/B, users are randomly assigned to groups once. In ML A/B, additional complexities arise:

  • Novelty effect: users react to novelty, not model quality.
  • Long-term effects: recommendation systems influence behavior not visible in short tests.
  • Carryover effect: previous prediction result affects current behavior.
  • Network effects: in collaborative systems, one user's behavior influences others.

These effects require careful experimental design. For example, to combat novelty, use ramp-up with gradual traffic increase from 5% to 50%.

A/B Architecture for ML

Traffic Split Levels

Method Description When to use
User-level split Same user always gets one model version Personalization, recommendations
Request-level split Each request randomly directed to a version Stateless services (search, pricing)
Cohort-based split Split by user segments Balance demographic characteristics

Traffic routing:

import hashlib def get_model_version(user_id: str, experiment_id: str) -> str: # Deterministic hashing for stable assignment hash_key = f"{experiment_id}:{user_id}" hash_value = int(hashlib.md5(hash_key.encode()).hexdigest(), 16) bucket = hash_value % 100 # 0-99 if bucket < 50: # 50% traffic return "model_v2" else: return "model_v1_control" 

Tools

Nginx / Envoy — infrastructure-level routing by headers or weights.

Seldon Core / KServe — Kubernetes-native inference with built-in A/B. Seldon Core is a Kubernetes-native inference platform for ML models, ideal for Kubernetes inference workloads:

apiVersion: machinelearning.seldon.io/v1 kind: SeldonDeployment spec: predictors: - name: control traffic: 70 graph: name: model-v1 - name: treatment traffic: 30 graph: name: model-v2 

Feature flags (LaunchDarkly, Unleash) — flexible experiment management without redeployment.

Tools Comparison

Tool Traffic management Statistics Notes
Seldon Core Built-in A/B, canary Yes (prometheus) Kubernetes-native, supports any ML framework
KServe InferenceGraph with % traffic Not built-in Simple configuration, Knative integration
LaunchDarkly Feature flags No Flexible management, ML-infrastructure independent

How to choose traffic split method?

Choice depends on service nature and goals. User-level split is good for personalization but may distort long-term effects. Request-level split is simpler but only for stateless loads. Cohort-based split gives control over biases but requires prior segmentation. We help select the optimal scheme for your architecture.

Statistical Methodology

Metrics for ML A/B:

  • Primary metric: business metric (conversion, ARPU, retention)
  • Guardrail metrics: latency, error rate — must not degrade
  • Secondary metrics: proxy indicators (CTR, engagement)

Sample size and test power:

To detect an effect of 2% at a baseline conversion of 5%, significance level α=0.05 and power 80%, approximately 15,000 users per group are needed. Conduct power analysis to ensure adequate sample size. Use a power calculator (scipy.stats.norm or online tools) before launching. Our experiments typically involve sample sizes from 10,000 to 1 million users per group. For more details, see Wikipedia: Statistical hypothesis testing.

Stopping the test:

  • Do not stop early due to preliminary results (peeking problem)
  • Minimum duration: 1-2 weeks to account for daily and weekly patterns
  • Use sequential testing (e-values) if you need to make decisions earlier

Analysis of Results

from scipy import stats control_conversions = [0, 1, 0, 1, ...] # 0/1 per user treatment_conversions = [0, 1, 1, 0, ...] # t-test for continuous metrics t_stat, p_value = stats.ttest_ind(control_conversions, treatment_conversions) # Chi-squared for binary metrics from scipy.stats import chi2_contingency contingency = [[control_success, control_fail], [treatment_success, treatment_fail]] chi2, p_value, dof, expected = chi2_contingency(contingency) print(f"Relative lift: {(treatment_rate - control_rate) / control_rate:.2%}") print(f"P-value: {p_value:.4f}") print(f"Statistically significant: {p_value < 0.05}") 

What's included in the work

  • Audit of current infrastructure and metrics
  • Design of traffic split scheme (user-level, request-level, cohort)
  • Routing setup via Nginx/Envoy or Seldon Core
  • Integration of feature flags for experiment management
  • Calculation of required sample size and test duration
  • Power analysis to validate sample sizes
  • Monitoring of guardrail metrics (latency, error rate)
  • Documentation of results and knowledge transfer to the team

Process

  1. Analytics — study your infrastructure, goals, and available data.
  2. Design — select split type, metrics, and tools.
  3. Implementation — set up routing, integrate feature flags, connect monitoring.
  4. Test — launch a pilot experiment on 10% traffic, verify correctness.
  5. Deploy — full-scale test with automatic stop rules.

Timelines and Cost

Setup timelines for A/B testing — from 2 to 4 weeks depending on infrastructure complexity. Cost is calculated individually after the audit. Our proven methodology guarantees reliable results. Get a consultation — contact us to assess your project. A properly configured A/B test enables you to make model deployment decisions based on data with a measurable level of confidence, not intuition.

Typical primary metrics include: conversion rate (CVR), average revenue per user (ARPU), retention rate at D1/D7/D30, click-through rate (CTR). Guardrail metrics often include p99 latency, error rate, and cost per inference.