Che cos'è il test switchback per i modelli decisionali? | di Tiffany Bogich | Gennaio 2024 | Intelligenza-Artificiale

Test A/B per modelli decisionali

Il test di switchback per i modelli decisionali consente ai team di algoritmi di confrontare un modello candidato con un modello di base in un ambiente di produzione reale, in cui entrambi i modelli prendono decisioni nel mondo reale per l’operazione. Con questa forma di test, i team possono randomizzare quale modello viene applicato a unità di tempo e/o luogo per mitigare gli effetti di confusione (come festività, eventi importanti, ecc.) che possono influire sui risultati quando si esegue un test pre/post implementazione.

I test di switchback possono avere diversi nomi (ad esempio, esperimenti suddivisi nel tempo) e vengono spesso definiti test A/B. Sebbene questo sia un confronto utile per l’orientamento, è importante riconoscere che i test di ritorno e A/B sono simili ma non uguali. I modelli decisionali non possono essere testati A/B nello stesso modo in cui lo possono essere le pagine web a causa degli effetti di rete. I test di switchback consentono di tenere conto di questi effetti di rete, mentre i test A/B no.

Ad esempio, quando esegui il test A/B di una pagina web offrendo contenuti diversi agli utenti, l’esperienza che un utente ha con la Pagina A non influisce sull’esperienza che un altro utente ha con la Pagina B. Tuttavia, se hai provato a eseguire il test A/B incarichi agli autisti: semplicemente non puoi. Non è possibile assegnare lo stesso ordine a due conducenti diversi come test di confronto. Non esiste un modo per isolare il trattamento e il controllo all’interno di una singola unità di tempo o luogo utilizzando i tradizionali test A/B. È qui che entrano in gioco i test di ritorno.

Illustrazione del test a tornanti con i modelli A e B rappresentati da forme di coniglio. Immagine da N. Misek e T. Bogich, Cos’è il test switchback per i modelli decisionali? (2023), Nextmv. Ripubblicato con il permesso.

Esploriamo un po’ più a fondo questo tipo di test.

Immagina di lavorare in un’azienda agricola che consegna prodotti freschi (carote, cipolle, barbabietole, mele) e latticini (formaggio, gelato, latte) dalle fattorie locali alle case dei clienti. La vostra azienda ha recentemente investito nel potenziamento dell’intera flotta di veicoli per essere pronta per la catena del freddo. Poiché tutti i veicoli sono in grado di movimentare articoli sensibili alla temperatura, l’azienda è pronta a eliminare la logica aziendale rilevante per la precedente flotta ibrida.

Prima dell’aggiornamento della flotta, la condivisione della tua azienda agricola gestiva gli articoli sensibili alla temperatura in modalità LIFO (last-in-first-out). Ciò significava che se veniva ritirato un oggetto freddo come un gelato, un autista doveva lasciare immediatamente il gelato per evitare un triste pasticcio che si scioglieva. Questa logica LIFO ha aiutato l’integrità del prodotto e la soddisfazione del cliente, ma ha anche introdotto inefficienze con cambiamenti di percorso e backtracking.

Dopo l’ammodernamento della flotta, il team vuole eliminare questo vincolo poiché tutti i veicoli sono in grado di trasportare articoli freddi più a lungo con la refrigerazione. Test precedenti utilizzando input storici, come esperimenti in batch (test ad hoc utilizzati per confrontare uno o più modelli con input offline o storici (1)) e prove di accettazione (test con metriche pass/fail predefinite utilizzate per confrontare il modello attuale con un modello candidato rispetto a input offline o storici prima di “accettare” il nuovo modello (2)), hanno indicato che il tempo del veicolo su strada e le fermate non assegnate diminuiscono per il modello candidato rispetto al modello di produzione che ha il vincolo LIFO. Hai eseguito un prova dell’ombra (un test online in cui uno o più modelli candidati vengono eseguiti in parallelo al modello attuale in produzione ma “nell’ombra”, senza influenzare le decisioni (3)) per garantire la stabilità del modello nelle condizioni di produzione. Ora vuoi consentire al tuo modello candidato di prendere decisioni per i tuoi sistemi di produzione e confrontare i risultati con il tuo modello di produzione.

Per questo test, decidi di randomizzare in base al tempo (ogni 1 ora) in due città: Denver e New York City. Ecco un esempio delle unità sperimentali per una città e il trattamento che è stato loro applicato.

Riepilogo del piano di esempio per un test di commutazione attivo Successivomv. Immagine da Nextmv.io Console cloud (2024). Ripubblicato con il permesso.

Dopo 4 settimane di test, scopri che il tuo modello candidato supera il modello di produzione avendo costantemente meno tempo su strada, meno fermate non assegnate e conducenti più felici perché non zigzagavano per la città per soddisfare il vincolo LIFO. Con questi risultati, collaborerai con il team per implementare completamente il nuovo modello (senza il vincolo LIFO) in entrambe le regioni.

I test di switchback creano comprensione e fiducia negli impatti comportamentali dei cambiamenti del modello quando sono in gioco effetti di rete. Poiché utilizzano i dati online e le condizioni di produzione in modo statisticamente valido, i test di ritorno forniscono informazioni su come il processo decisionale di un nuovo modello influisce sul mondo reale in modo misurato anziché semplicemente “spedirlo” all’ingrosso per produrlo e sperare per il meglio. Il test switchback è la forma di test più efficace per comprendere come si comporterà un modello candidato nel mondo reale.

Questo tipo di comprensione è qualcosa che non puoi ottenere dai test ombra. Ad esempio, se esegui un modello candidato che modifica una funzione obiettivo in modalità ombra, tutti i tuoi KPI potrebbero sembrare buoni. Ma se esegui lo stesso modello come test di ritorno, potresti vedere che i corrieri rifiutano gli ordini a un tasso più elevato rispetto al modello di base. Ci sono solo comportamenti e risultati che non è sempre possibile prevedere senza eseguire un modello candidato in produzione in un modo che consenta di osservare il modello mentre prende decisioni operative.

Inoltre, i test di switchback sono particolarmente rilevanti per i problemi di domanda e offerta nello spazio di instradamento, come la consegna e la spedizione dell’ultimo miglio. Come descritto in precedenza, le tecniche di test A/B standard semplicemente non sono appropriate in queste condizioni a causa degli effetti di rete che non possono tenere conto.

C’è una citazione da Principi di ingegneria del caos“Chaos preferisce fortemente sperimentare direttamente sul traffico di produzione” (4). I test di ritorno (e i test ombra) sono fatti per affrontare questo tipo di caos. Come accennato nella sezione precedente: arriva un punto in cui è il momento di vedere come un modello candidato prende decisioni che incidono sulle operazioni del mondo reale. Questo è il momento in cui hai bisogno di un test di ritorno.

Detto questo, non ha senso che il primo ciclo di test su un modello candidato sia un test di tipo switchback. Ti consigliamo di eseguire una serie di test storici come test batch, di scenario e di accettazione, quindi passare ai test shadow sui dati di produzione. I test di ritorno rappresentano spesso l’ultimo passaggio prima di impegnarsi a implementare completamente un modello candidato al posto di un modello di produzione esistente.

Illustrazione del flusso di lavoro di test che include test di passaggio prima della distribuzione di un nuovo modello. Immagine di Haley Eshagh.

Per eseguire i test di ritorno, i team spesso creano da zero l’infrastruttura, il quadro di randomizzazione e gli strumenti di analisi. Sebbene i vantaggi dei test switchback siano notevoli, il costo per implementarli e mantenerli può essere elevato e spesso richiede un coinvolgimento dedicato nella scienza dei dati e nell’ingegneria dei dati. Di conseguenza, questo tipo di test non è così comune nello spazio della scienza delle decisioni.

Una volta che l’infrastruttura è a posto e i test di ritorno sono attivi, diventa un esercizio di discussione dei dati per intrecciare le informazioni per capire quale trattamento è stato applicato e in quale momento e riconciliare tutti questi dati per fare un’analisi più formale dei risultati.

Alcuni buoni punti di riferimento in cui immergersi includono i post del blog l’argomento di DoorDash come questo (ne scrivono parecchio) (5), oltre a questo Verso il post di Data Science da un ingegnere di soluzioni Databricks (6), che fa riferimento a un utile documento di ricerca da MIT e Harvard (7) vale la pena leggerlo.

Il test di switchback per i modelli decisionali è simile al test A/B, ma consente ai team di tenere conto degli effetti di rete. Il test switchback è una parte fondamentale del flusso di lavoro DecisionOps perché esegue un modello candidato utilizzando dati di produzione con effetti reali. Stiamo continuando a costruire il esperienza di test presso Nextmv – e vorremmo il tuo input.