A/A test e validazione del sistema di misura

Questa lezione sta sul binario ml-tabellare: l’A/A test è un collaudo numerico, e la sua regola è semplice — due gruppi identici devono comportarsi come se fossero uno solo.

L’idea in una frase

Il test A/A confronta due gruppi identici per verificare che la piattaforma non segnali differenze quando non esiste alcun effetto reale.

La procedura in cinque passi

1. Duplica il gruppo di controllo in due rami identici con la stessa esperienza.
2. Fai girare il test per la durata standard con le metriche di produzione.
3. Conta quante metriche risultano significative e confronta la quota con la soglia attesa (α).
4. Se i falsi allarmi superano l’atteso, blocca i lanci e indaga randomizzazione, logging e pipeline.
5. Ripeti il collaudo a cadenza regolare e dopo ogni modifica all’infrastruttura.

Quando il sistema di misura mente

Prima di fidarti di un test A/B, devi sapere se la piattaforma misura bene quando non c’è alcuna differenza reale. Un test A/A assegna due gruppi identici alla stessa esperienza. Poi misura quante differenze spurie emergono per solo caso.

Un falso positivo qui significa un risultato significativo senza effetto reale. Se la quota supera la soglia attesa, ogni esperimento successivo eredita lo stesso rischio.

Tratta l’A/A come collaudo dell’infrastruttura, non come esercizio teorico. Verifica randomizzazione, logging, metriche e pipeline prima che un falso positivo diventi roadmap. Se due gruppi identici divergono, il problema è nel sistema di raccolta, non nei dati.

La sequenza di lavoro

Per evitare un rituale vuoto, collega ogni controllo a una decisione. La mappa parte dalla scelta da prendere e arriva all’azione operativa. Ogni passaggio chiarisce quale errore eviti e quale costo resta.

Parti dalla decisione: che cosa cambia se capiamo meglio l’affidabilità del sistema di misura? Poi individua il segnale osservabile, la baseline di confronto, i vincoli che possono falsare la lettura e l’azione che segue. La sequenza lega domanda, dato, baseline e decisione. Impedisce che un numero preciso ma scollegato dall’azione passi per evidenza.

Gli elementi da dichiarare

La validazione rende esplicita la relazione tra decisione, evidenza e rischio. Lo scopo non è complicare, ma mostrare le assunzioni. Così uno stakeholder discute il criterio decisionale invece di accettare il risultato per autorità.

Serve definire l’unità di analisi, la variabile osservata, la baseline, la soglia decisionale e il rischio residuo. Ogni elemento ha un controllo minimo: una definizione stabile e tracciabile, un criterio scritto prima della lettura, una verifica di sensibilità.

Un caso applicato

Un team usa l’A/A per decidere se fidarsi di pipeline, metrica o dashboard. La domanda utile non è la definizione corretta. La domanda utile è quale scelta diventa meno rischiosa con un’analisi fatta bene.

Pensa alle situazioni tipiche. Se il dato migliora ma la baseline è debole, il segnale potrebbe essere reale o dipendere dal campione: rafforza il confronto prima di scalare. Se la metrica cambia in un solo segmento, l’effetto medio nasconde eterogeneità: separa coorti o casi d’uso. Se il costo operativo aumenta, valuta il beneficio sul margine. Se il sistema produce numeri incoerenti, la fiducia nel dato è parte della decisione: correggi ownership e controlli.

L’errore tipico

L’errore più comune è usare l’A/A come etichetta invece che come criterio di scelta. Il team mostra un numero senza dire quale decisione cambia. Non dichiara quale baseline lo rende interpretabile né quale rischio resta aperto. Il dato sembra preciso ma non guida l’azione. Il collaudo diventa un timbro invece di una garanzia.

Verdetto: nessun test A/B è credibile sopra una piattaforma che non supera regolarmente il collaudo A/A.

Il caso Microsoft 2019

Nel 2019 il team di Analysis ed Experimentation di Microsoft pubblicò un’analisi dei propri A/A test su sistemi di produzione reale: circa un terzo mostrava un tasso di falsi positivi superiore al 5 per cento atteso. Non era un errore di calcolo ma un problema di infrastruttura: randomizzazione, pipeline di raccolta dati o metriche aggregate avevano un bias strutturale che faceva sembrare significative differenze inesistenti. La conseguenza è semplice nella formulazione e pesante nelle ricadute: se non validi il sistema di misura, non puoi fidarti di nessun esperimento costruito sopra di esso.

Domande per verificare la lezione

1. Perché due gruppi identici possono produrre un risultato significativo?
2. Quale quota di falsi positivi ti aspetti da un sistema sano?
3. Che cosa fai se i falsi allarmi superano stabilmente la soglia attesa?
4. Quando ripeti il collaudo A/A anche se nessuno si lamenta?