L'utilizzo del machine learning in Mail.ru

Sulla base delle mie presentazioni a Highload++ e DataFest Minsk 2019.

Per molti oggi la posta è una parte indispensabile della vita online. Grazie a essa, gestiamo corrispondenza aziendale, conserviamo varie informazioni importanti relative a finanze, prenotazioni di hotel, elaborazione di ordini e molto altro. A metà del 2018 abbiamo formulato una strategia di prodotto per lo sviluppo della posta. Come dovrebbe essere la posta moderna?

La posta deve essere intelligente, cioè deve aiutare gli utenti a orientarsi in un volume crescente di informazioni: filtrare, strutturare e fornire il tutto nel modo più comodo possibile. Deve essere utile, permettendo di risolvere varie attività direttamente nella casella di posta, ad esempio, pagando multe (una funzione che, con mio rammarico, utilizzo). E, naturalmente, la posta deve garantire la protezione delle informazioni, bloccando lo spam e proteggendo dagli attacchi, cioè deve essere sicura.

Queste direzioni definiscono una serie di compiti chiave, molti dei quali possono essere risolti in modo efficace con l'apprendimento automatico. Ecco alcuni esempi di funzionalità già operative, sviluppate nell'ambito della strategia — una per ogni direzione.

• Smart Reply. Nella posta esiste la funzione di risposta intelligente. Il neural network analizza il testo dell'email, ne comprende il significato e l'obiettivo, e alla fine propone tre risposte più appropriate: positiva, negativa e neutra. Questo aiuta a risparmiare notevolmente tempo nelle risposte alle email e a rispondere spesso in modo originale e divertente.
• Raggruppamento delle email, relative agli ordini nei negozi online. Spesso facciamo acquisti su internet e, di solito, i negozi possono inviare più email per ogni ordine. Ad esempio, da AliExpress, il servizio più grande, arrivano molte email riguardanti un solo ordine, e abbiamo calcolato che nel caso estremo il numero può arrivare fino a 29. Pertanto, grazie a un modello di Named Entity Recognition, estraiamo il numero dell'ordine e altre informazioni dal testo e raggruppiamo tutte le email in un'unica discussione. Mostriamo anche le informazioni principali sull'ordine in un apposito pannello, facilitando così la gestione di questo tipo di email.

  

• Antiphishing. Il phishing è un tipo di truffa particolarmente insidiosa, attraverso la quale i malintenzionati cercano di appropriarsi delle informazioni finanziarie (inclusi i dati delle carte di credito degli utenti) e delle credenziali. Queste email si mimetizzano dietro a comunicazioni legittime inviate da servizi, anche visivamente. Grazie al Computer Vision, riconosciamo i loghi e lo stile di design delle email delle grandi aziende (come Mail.ru, Sber, Alfa) e consideriamo questo insieme al testo e ad altri indicatori nei nostri classificatori di spam e phishing.

Apprendimento automatico

Un po' di informazione sull'apprendimento automatico nelle email in generale. La posta elettronica è un sistema ad alta richiesta: attraverso i nostri server passano in media circa 1,5 miliardi di email al giorno per 30 milioni di utenti DAU. Circa 30 sistemi di apprendimento automatico gestiscono tutte le funzioni e le caratteristiche necessarie.

Ogni email passa attraverso un vero e proprio processo di classificazione. All'inizio, filtriamo lo spam e lasciamo le email valide. Gli utenti spesso non si accorgono del funzionamento del sistema anti-spam, poiché il 95-99% dello spam non viene nemmeno inviato nella cartella corrispondente. Il riconoscimento dello spam è una parte molto importante e complessa del nostro sistema, poiché nel campo dell'anti-spam c'è una costante adattamento tra i sistemi di protezione e quelli di attacco, offrendo una sfida ingegneristica continua per il nostro team.

Successivamente, separiamo le email tra quelle inviate da persone e quelle generate da robot. Le email delle persone sono le più importanti, per cui forniamo funzionalità come Smart Reply. Le email dei robot si suddividono in due categorie: quelle transazionali, che sono email importanti da servizi, ad esempio conferme di acquisti o prenotazioni di hotel, e quelle informative, che comprendono pubblicità aziendale e sconti.

Riteniamo che le email transazionali abbiano la stessa importanza della corrispondenza personale. Devono essere facilmente accessibili, poiché spesso è necessario trovare rapidamente informazioni su un ordine o una prenotazione di volo, e si finisce per sprecare tempo a cercare tali email. Pertanto, per comodità, le suddividiamo automaticamente in sei categorie principali: viaggi, ordini, finanze, biglietti, registrazioni e, infine, multe.

Le email informative sono il gruppo più numeroso e, forse, meno importante, che non richiede una reazione immediata, dato che nulla di sostanziale cambierà nella vita dell'utente se non legge questo tipo di email. Nel nostro nuovo interfaccia, le raggruppiamo in due thread: social media e newsletter, pulendo visivamente la casella e lasciando in vista solo le email importanti.

Gestione

Un gran numero di sistemi presenta diverse difficoltà nell'uso. Infatti, i modelli nel tempo degradano, proprio come qualsiasi software: i segnali si rompono, le macchine si guastano, si accumula codice errato. Inoltre, i dati cambiano costantemente: nuovi dati vengono aggiunti, si trasforma il comportamento degli utenti ecc., pertanto un modello senza adeguato supporto nel tempo funzionerà sempre peggio.

Non si può dimenticare che più l'apprendimento automatico penetra nella vita degli utenti, maggiore è l'influenza che esercitano sull'ecosistema e, di conseguenza, maggiori sono le perdite finanziarie o i profitti che possono ottenere gli attori del mercato. Pertanto, in un numero crescente di settori, gli attori si adattano al lavoro degli algoritmi ML (classici esempi - pubblicità, ricerca e già menzionato antispam).

Inoltre, i compiti di apprendimento automatico hanno una caratteristica: qualsiasi, anche piccolo, cambiamento nel sistema può generare molto lavoro con il modello: gestione dei dati, riaddestramento, deployment, il che può richiedere settimane o mesi. Pertanto, quanto più velocemente cambia l'ambiente in cui operano i vostri modelli, tanto maggiori sforzi richiede il loro supporto. Un team può creare molti sistemi e rallegrarsi per questo, per poi spendere quasi tutte le risorse nel loro supporto, senza possibilità di fare qualcosa di nuovo. Una volta ci siamo trovati in una situazione simile nel team antispam. E abbiamo tratto la conclusione ovvia che il supporto deve essere automatizzato.

Automazione

Cosa si può automatizzare? In realtà quasi tutto. Ho individuato quattro direzioni che definiscono l'infrastruttura dell'apprendimento automatico:

• raccolta dati;
• riaddestramento;
• deployment;
• test e monitoraggio.

Se l'ambiente è instabile e cambia costantemente, allora l'intera infrastruttura attorno al modello diventa molto più importante del modello stesso. Può trattarsi di un vecchio buon classificatore lineare, ma se vengono fornite correttamente le caratteristiche e viene stabilito un buon feedback dagli utenti, funzionerà molto meglio rispetto ai modelli State-Of-The-Art con tutte le complicazioni.

Ciclo di feedback

Questo ciclo comprende la raccolta di dati, il riaddestramento e il deployment — in sostanza, l'intero ciclo di aggiornamento del modello. Perché è importante? Guarda il grafico delle registrazioni alla posta:

Uno sviluppatore di machine learning ha implementato un modello anti-bot che impedisce ai bot di registrarsi nella mail. Il grafico scende a un valore in cui rimangono solo utenti reali. Tutto eccellente! Ma passano quattro ore, i botmaster aggiornano i loro script e tutto torna come prima. In questa implementazione, lo sviluppatore ha impiegato un mese per aggiungere le caratteristiche e riaddestrare il modello, ma lo spammer è riuscito ad adattarsi in quattro ore.

Per non far sì che sia così doloroso e non dover rifare tutto successivamente, bisogna pensare fin dall'inizio a come apparirà il ciclo di feedback e cosa faremo se l'ambiente cambia. Iniziamo dalla raccolta dei dati: questo è il carburante per i nostri algoritmi.

Raccolta dati

È chiaro che per le reti neurali moderne, più dati ci sono, meglio è, e questi, fondamentalmente, vengono generati dagli utenti del prodotto. Gli utenti possono aiutarci etichettando i dati, ma non dobbiamo abusarne, poiché a un certo punto gli utenti si stancheranno di riaddestrare i vostri modelli e passeranno a un altro prodotto.

Uno degli errori più comuni (qui faccio riferimento a Andrew Ng) è una forte focalizzazione sulle metriche su un dataset di test piuttosto che sul feedback degli utenti, che in realtà è il principale parametro della qualità del lavoro, poiché stiamo creando un prodotto per l'utente. Se il lavoro del modello non è chiaro o non piace all'utente, allora è tutto vano.

Pertanto, l'utente deve sempre avere la possibilità di esprimere la propria opinione; bisogna fornirgli uno strumento per il feedback. Se riteniamo che nella casella sia arrivata una mail riguardante le finanze, dobbiamo marcarla come "finanze" e disegnare un pulsante che l'utente può premere per dire che non si tratta di finanze.

Qualità del feedback

Parliamo della qualità del feedback degli utenti. Innanzitutto, tu e l'utente potete attribuire significati diversi alla stessa parola. Per esempio, tu e i product manager ritenete che "finanze" si riferisca alle lettere provenienti dalla banca, mentre l'utente pensa che una lettera della nonna riguardante la pensione rientri anch'essa nel tema delle finanze. In secondo luogo, ci sono utenti che premono pulsanti senza alcuna logica. In terzo luogo, l'utente potrebbe avere idee completamente sbagliate sulle proprie conclusioni. Un esempio lampante dalla nostra esperienza è l'implementazione di un classificatore di spam nigeriano, un tipo di spam piuttosto divertente, in cui all'utente viene offerto di ritirare diversi milioni di dollari da un lontano parente trovato all'improvviso in Africa. Dopo aver implementato questo classificatore, abbiamo verificato i click su "Non spam" su queste lettere, e si è rivelato che l'80% di esse era un delizioso spam nigeriano, il che dimostra che gli utenti possono essere estremamente creduloni.

E non dimentichiamo che i pulsanti possono essere cliccati non solo da persone, ma anche da vari bot che si spacciano per browser. Quindi, il feedback grezzo non è adatto per l'apprendimento. Cosa si può fare con queste informazioni?

Adottiamo due approcci:

• Feedback dal ML correlato. Ad esempio, abbiamo un sistema anti-bot online che, come ho già detto, prende decisioni rapide basate su un numero limitato di segnali. E c'è un secondo sistema, più lento, che opera post-factum. Esso dispone di più dati sull'utente, sul suo comportamento, ecc. Di conseguenza, viene presa la decisione più ponderata, e quindi ha una maggiore precisione e completezza. Possiamo indirizzare la differenza di funzionalità tra questi sistemi nel primo come dati per l'apprendimento. In questo modo, il sistema più semplice cercherà sempre di avvicinarsi alle prestazioni di quello più complesso.
• Classificazione dei click. È possibile semplicemente classificare ogni clic dell'utente, valutarne la validità e la possibilità di utilizzo. Lo facciamo nell'anti-spam della posta, utilizzando segnali dell'utente, la sua cronologia, i segnali del mittente, il testo stesso e il risultato del lavoro dei classificatori. In definitiva otteniamo un sistema automatico che valida il feedback dell'utente. E poiché deve essere ri-addestrato in modo sostanzialmente meno frequente, il suo lavoro potrebbe diventare la base per tutti gli altri sistemi. La priorità principale in questo modello è la precisione, perché addestrare il modello su dati imprecisi può avere conseguenze.

Mentre puliamo i dati e ri-addestriamo i nostri sistemi ML, non dobbiamo dimenticare gli utenti, poiché per noi migliaia, milioni di errori sul grafico sono statistiche, mentre per l'utente ogni bug è una tragedia. Oltre al fatto che l'utente deve in qualche modo convivere con il tuo errore nel prodotto, lui dopo il feedback si aspetta l'esclusione di situazioni simili in futuro. Pertanto, è sempre bene dare agli utenti non solo la possibilità di votare, ma anche di correggere il comportamento dei sistemi ML, creando, ad esempio, euristiche personali per ogni clic di feedback; nel caso della posta, potrebbe essere la possibilità di filtrare tali email per mittente e oggetto per questo utente.

Inoltre, è necessario basarsi su rapporti o segnalazioni al supporto, in modo semi-automatico o manuale, per adattare il modello, affinché anche gli altri utenti non subiscano problemi simili.

Euristiche per l'addestramento

Con queste euristiche e adattamenti ci sono due problemi. Il primo è che il numero crescente di adattamenti è difficile da mantenere, per non parlare della loro qualità e funzionalità a lungo termine. Il secondo problema è che l'errore potrebbe non essere frequente e alcuni clic per il ri-addestramento del modello potrebbero non essere sufficienti. Sembrerebbe che questi due effetti non correlati possano essere notevolmente ridotti applicando il seguente approccio.

1. Creiamo un adattamento temporaneo.
2. Invitiamo i dati ad esso nel modello, che viene regolarmente ri-addestrato anche sui dati ottenuti. Qui, ovviamente, è importante che l'euristica abbia un'alta precisione, per non compromettere la qualità dei dati nel set di addestramento.
3. Poi mettiamo in atto il monitoraggio per l'attivazione del bypass e, se dopo un certo periodo il bypass non si attiva più e viene completamente sostituito dal modello, possiamo rimuoverlo senza problemi. Ora è improbabile che questo problema si ripresenti.

Quindi l'esercito di bypass è molto utile. L'importante è che il loro utilizzo sia temporaneo e non permanente.

Riaddestramento

Il riaddestramento è il processo di aggiunta di nuovi dati, ottenuti in seguito al feedback degli utenti o di altri sistemi, e di formazione del modello esistente su di essi. Con il riaddestramento possono sorgere diversi problemi:

1. Il modello potrebbe semplicemente non supportare il riaddestramento e dover essere addestrato solo da zero.
2. Nella natura non è scritto da nessuna parte che il riaddestramento migliori necessariamente la qualità del lavoro in produzione. Spesso succede il contrario, ovvero è possibile solo un peggioramento.
3. Le modifiche possono essere imprevedibili. Questo è un aspetto piuttosto delicato che abbiamo identificato. Anche se il nuovo modello in un test A/B mostra risultati simili rispetto a quello attuale, ciò non significa affatto che funzionerà in modo identico. Il loro funzionamento può differire di un qualche percento che può portare a nuovi errori o ripristinare vecchi errori già corretti. Con gli errori attuali sia noi che gli utenti siamo già abituati a convivere e quando emerge un gran numero di nuovi errori, l'utente potrebbe non capire cosa sta succedendo, dal momento che si aspetta un comportamento prevedibile.

Quindi, la cosa più importante nel riaddestramento è garantire il miglioramento del modello, o almeno non peggiorarlo.

La prima cosa che ci viene in mente quando parliamo di riaddestramento è l'approccio dell'Active Learning. Cosa significa questo? Ad esempio, un classificatore determina se una email è di natura finanziaria e intorno al suo confine di decisione aggiungiamo un campione di esempi etichettati. Questo funziona bene, ad esempio, nella pubblicità, dove ci sono molte informazioni di feedback e si può addestrare il modello in modalità online. Se invece il feedback è scarso, otteniamo un campione pesantemente sbilanciato rispetto alla distribuzione dei dati in produzione, sulla quale non possiamo valutare il comportamento del modello durante l'esercizio.

In realtà, il nostro obiettivo è preservare i vecchi modelli, quelli già noti, e acquisirne di nuovi. Qui la continuità è importante. Il modello che abbiamo faticato a sviluppare sta già funzionando, quindi possiamo basarci sulle sue prestazioni.

Nella posta vengono utilizzati diversi modelli: alberi, lineari, reti neurali. Per ognuno di essi creiamo il nostro algoritmo di riaddestramento. Durante il processo di riaddestramento, otteniamo non solo nuovi dati, ma anche spesso nuove caratteristiche, che terremo in considerazione in tutti gli algoritmi sottostanti.

Modelli lineari

Supponiamo di avere una regressione logistica. Componiamo la funzione di perdita del modello dai seguenti componenti:

• LogLoss sui nuovi dati;
• regolarizziamo i pesi delle nuove caratteristiche (non tocchiamo le vecchie);
• impariamo anche dai dati vecchi per preservare i vecchi modelli;
• e, forse, cosa più importante: applichiamo la Regolarizzazione Armonica, che garantisce che i pesi non cambino drasticamente rispetto al vecchio modello secondo la norma.

Poiché ogni componente di Loss ha dei coefficienti, possiamo trovare valori ottimali per il nostro problema attraverso la cross-validation o in base ai requisiti di prodotto.

Alberi

Passiamo agli alberi decisionali. Abbiamo sviluppato il seguente algoritmo di riaddestramento per gli alberi:

1. In produzione stiamo utilizzando una foresta di 100-300 alberi, addestrata su un vecchio dataset.
2. Alla fine rimuoviamo M = 5 alberi e aggiungiamo 2M = 10 nuovi, addestrati su tutto il dataset, ma con un alto peso sui nuovi dati, il che garantisce naturalmente una modifica incrementale del modello.

È ovvio che nel tempo il numero di alberi aumenta notevolmente e devono essere ridotti periodicamente per rispettare i tempi. A tal fine utilizziamo il sempre presente Knowledge Distillation (KD). Un breve riassunto del suo funzionamento.

1. Abbiamo l'attuale modello "complesso". Lo eseguiamo sul dataset di addestramento e otteniamo la distribuzione delle probabilità delle classi in output.
2. Successivamente, addestriamo un modello studente (in questo caso un modello con un numero minore di alberi) a ripetere i risultati del modello, utilizzando la distribuzione delle classi come variabile target.
3. È importante notare che non utilizziamo in alcun modo la formattazione del dataset, e quindi possiamo utilizzare dati arbitrari. Naturalmente, usiamo un campione di dati dal flusso di produzione come set di apprendimento per il modello studente. In questo modo, il set di addestramento ci consente di garantire la precisione del modello, mentre il campione del flusso assicura prestazioni simili nella distribuzione di produzione, compensando il bias del set di apprendimento.

La combinazione di queste due metodologie (l'aggiunta di alberi e la riduzione periodica della loro quantità tramite Knowledge Distillation) garantisce l'introduzione di nuovi schemi e una piena continuità.

Con la KD eseguiamo anche la differenziazione delle operazioni con le caratteristiche del modello, ad esempio, la rimozione di caratteristiche e la gestione delle assenze. Nel nostro caso, abbiamo una serie di importanti caratteristiche statistiche (sui mittenti, sugli hash testuali, sugli URL, ecc.) che sono memorizzate in un database soggetto a fallimento. Pertanto, il modello non è pronto a tale eventualità, poiché non ci sono situazioni di fallimento nel set di addestramento. In questi casi, combiniamo le tecniche di KD e di augmentazione: durante l'addestramento, per una parte dei dati, rimuoviamo o azzeriamo le caratteristiche necessarie, mentre le etichette (le uscite del modello attuale) rimangono quelle originali, e il modello studente impara a ripetere questa distribuzione.

Abbiamo notato che più grave è la manipolazione dei modelli, maggiore è la percentuale di campione di flusso richiesta.

Per la rimozione di caratteristiche, l'operazione più semplice, è necessario solo un piccolo flusso, poiché cambiano solo alcune caratteristiche, e il modello attuale è stato addestrato sullo stesso set — la differenza è minima. Per semplificare il modello (riducendo il numero di alberi in diversi modi), è già necessario avere un rapporto di 50 su 50. E per le assenze di importanti caratteristiche statistiche che influenzano seriamente le prestazioni del modello, serve un flusso ancora maggiore per livellare il funzionamento del nuovo modello resistente alle assenze su tutti i tipi di messaggi.

FastText

Passiamo a FastText. Ricordo che la rappresentazione (Embedding) di una parola consiste nella somma dell'embedding della parola stessa e di tutti i suoi N-gram di lettere, in genere trigrammi. Poiché possono esserci molti trigrammi, si utilizza il Bucket Hashing, ovvero la trasformazione dell'intero spazio in una certa mappa hash fissa. Di conseguenza, la matrice dei pesi ha dimensioni pari al numero di parole più i bucket.

Durante il fine-tuning emergono nuove caratteristiche: parole e trigrammi. Nel fine-tuning standard di Facebook non accade nulla di significativo. Vengono solamente aggiornati i pesi esistenti con la cross-entropy sui nuovi dati. In questo modo, le nuove caratteristiche non vengono utilizzate; chiaramente, questo approccio presenta tutti i difetti sopra descritti, legati all'imprevedibilità del modello in produzione. Pertanto, abbiamo apportato alcune modifiche a FastText. Aggiungiamo tutti i nuovi pesi (parole e trigrammi), addestriamo di nuovo l'intera matrice con la cross-entropy e aggiungiamo una regolarizzazione armonica, analogamente al modello lineare, che garantisce un'alterazione non sostanziale dei pesi esistenti.

CNN

Con le reti convoluzionali la situazione è un po' più complessa. Se in una CNN vengono aggiornati gli strati finali, ovviamente, è possibile applicare la regolarizzazione armonica e garantire la continuità. Ma nel caso in cui sia necessario eseguire il fine-tuning dell'intera rete, tale regolarizzazione non può essere applicata a tutti gli strati. Tuttavia, esiste un'opzione per l'addestramento di embedding complementari attraverso il Triplet Loss (articolo originale).

Triplet Loss

Prendiamo come esempio il compito dell'antifishing, esaminiamo in linea generale il Triplet Loss. Prendiamo il nostro logo, così come esempi positivi e negativi di loghi di altre aziende. Minimizzando la distanza tra i primi e massimizzando la distanza tra i secondi, facciamo questo con un piccolo margine, per garantire una maggiore compattezza delle classi.

Se addestriamo nuovamente la rete, lo spazio metrico cambia completamente e diventa assolutamente incompatibile con quello precedente. Questo è un serio problema nei compiti che utilizzano vettori. Per aggirare questo problema, durante l'addestramento incorporeremo vecchi embedding.

Abbiamo aggiunto nuovi dati al set di addestramento e stiamo addestrando da zero la seconda versione del modello. Nella seconda fase, perfezioniamo la nostra rete (Finetuning): prima viene addestrato l'ultimo strato, poi viene sbloccata l'intera rete. Durante la composizione dei triplet, solo una parte degli embedding viene calcolata utilizzando il modello addestrato, mentre gli altri vengono calcolati utilizzando il vecchio modello. In questo modo, nel processo di affinamento, garantiamo la compatibilità degli spazi metrici v1 e v2. È una sorta di variante della regolarizzazione armonica.

Architettura complessiva

Se consideriamo l'intero sistema prendendo come esempio l'antispam, i modelli non sono isolati, ma sono incorporati l'uno nell'altro. Prendiamo immagini, testo e altre caratteristiche, e tramite CNN e Fast Text otteniamo embedding. Successivamente, sui embedding vengono applicati classificatori, che forniscono score per diverse classi (tipi di email, spam, presenza del logo). Gli score e le caratteristiche vengono quindi inviati in una foresta di alberi per prendere la decisione finale. Classificatori separati in questo schema consentono una migliore interpretazione dei risultati del sistema e un affinamento più mirato dei componenti in caso di problemi, piuttosto che presentare tutti i dati grezzi agli alberi decisionali.

Di conseguenza, garantiamo continuità a ogni livello. A livello inferiore, in CNN e Fast Text, utilizziamo la regolarizzazione armonica; per i classificatori a livello medio, utilizziamo anch'essa la regolarizzazione armonica e la calibrazione dello score per la compatibilità della distribuzione di probabilità. E il boosting degli alberi viene addestrato in modo incrementale o tramite Knowledge Distillation.

In generale, il supporto di un sistema di machine learning così incorporato rappresenta di solito una sfida, poiché qualsiasi componente a livello inferiore porta all'aggiornamento dell'intero sistema sovrastante. Tuttavia, poiché nel nostro setup ogni componente cambia leggermente ed è compatibile con il precedente, l'intero sistema può essere aggiornato a blocchi senza la necessità di riaddestrare l'intera struttura, il che consente di mantenerlo senza un notevole sovraccarico.

Deploy

Abbiamo trattato la raccolta dei dati e l'affinamento di diversi tipi di modelli, quindi passiamo alla loro distribuzione nell'ambiente di produzione.

A/B testing

Come ho detto in precedenza, durante il processo di raccolta dati, di solito otteniamo un campione distorto, il che rende impossibile valutare il performance model in produzione. Pertanto, durante il deployment, è fondamentale confrontare il modello con la versione precedente per capire come stanno realmente le cose, ovvero effettuare test A/B. In effetti, il processo di rilascio e l'analisi dei grafici è piuttosto routinario e si presta bene all'automazione. Rilasciamo i nostri modelli gradualmente sul 5%, 30%, 50% e 100% degli utenti, raccogliendo nel contempo tutte le metriche disponibili sulle risposte del modello e sul feedback degli utenti. In caso di picchi significativi, ripristiniamo automaticamente il modello, mentre per gli altri casi, dopo aver raccolto un numero sufficiente di clic da parte degli utenti, decidiamo di aumentare la percentuale. Alla fine, portiamo il nuovo modello al 50% degli utenti in modo completamente automatico, e una persona approva il rilascio a tutto il pubblico, anche se questo passaggio può essere automatizzato.

Tuttavia, il processo di test A/B offre ampie possibilità di ottimizzazione. Il fatto è che qualsiasi test A/B è piuttosto lungo (nel nostro caso dura da 6 a 24 ore a seconda della quantità di feedback), il che lo rende piuttosto costoso e con risorse limitate. Inoltre, è necessario un flusso di utenti sufficientemente alto per il test, per accelerare il tempo totale del test A/B (raccogliere un campione statisticamente significativo per la valutazione delle metriche su una piccola percentuale può richiedere molto tempo), il che rende il numero di slot A/B estremamente limitato. È evidente che dobbiamo testare solo i modelli più promettenti, di cui ne otteniamo numerosi durante il processo di affinamento.

Per affrontare questo problema, abbiamo addestrato un classificatore separato che prevede il successo del test A/B. Per questo utilizziamo come caratteristiche le statistiche di decisione, Precision, Recall e altre metriche sui dati di addestramento, su un set di convalida e su un campione proveniente dal flusso. Confrontiamo anche il modello con quello attuale in produzione, con le euristiche e consideriamo la complessità (Complexity) del modello. Utilizzando tutte queste caratteristiche, il classificatore addestrato sulla storia dei test valuta i modelli candidati, nel nostro caso si tratta di foreste di alberi, e prende decisione su quale di essi far passare al test A/B.

Al momento dell'implementazione, questo approccio ha consentito di aumentare notevolmente il numero di A/B test di successo.

Test e monitoraggio

Stranamente, il testing e il monitoraggio non danneggiano la nostra salute, anzi, migliorano e alleviano lo stress. Il testing consente di prevenire i guasti, mentre il monitoraggio aiuta a rilevarli in tempo per ridurre l'impatto sugli utenti.

È importante comprendere che prima o poi il vostro sistema presenterà sempre errori: questo è legato al ciclo di sviluppo di qualsiasi software. All'inizio dello sviluppo, ci sono sempre molti bug fino a quando tutto non si stabilizza e non si conclude la fase principale delle innovazioni. Ma col tempo, l'entropia prende piede e riappaiono gli errori, a causa della degradazione dei componenti circostanti e della modifica dei dati, come ho accennato all'inizio.

Qui vorrei sottolineare che ogni sistema di machine learning deve essere considerato in termini di vantaggio durante tutto il ciclo di vita. Di seguito, il grafico mostra un esempio di un sistema di rilevamento di un raro tipo di spam (nel grafico, la linea si trova intorno allo zero). Una volta, a causa di una caratteristica erroneamente memorizzata nella cache, è impazzito. Purtroppo, non c'era monitoraggio per attivazioni anomale, quindi il sistema ha iniziato a salvare le email nella cartella "spam" al confine della decisione in gran numero. Nonostante la correzione delle conseguenze, il sistema aveva già commesso così tanti errori che non si ripagherebbe nemmeno in cinque anni. Questo rappresenta un completo fallimento dal punto di vista del ciclo di vita del modello.

Pertanto, una cosa così semplice come il monitoraggio può diventare fondamentale nella vita del modello. Oltre alle metriche standard e ovvie, consideriamo la distribuzione delle risposte e i punteggi del modello, nonché la distribuzione dei valori delle caratteristiche chiave. Utilizzando la divergenza di KL, possiamo confrontare la distribuzione attuale con quella storica o i valori nel test A/B con il resto del flusso, il che ci consente di rilevare anomalia nel modello e ripristinare le modifiche in tempo.

Nella maggior parte dei casi, lanciamo le nostre prime versioni dei sistemi utilizzando semplici euristiche o modelli, che in futuro utilizzeremo come monitoraggio. Ad esempio, monitoriamo un modello NER rispetto a espressioni regolari per negozi online specifici e se la copertura del classificatore diminuisce in confronto a queste, cerchiamo di comprendere le ragioni. Un altro utilizzo utile delle euristiche!

Conclusioni

Ripercorriamo ancora una volta i punti chiave dell'articolo.

• Fibdэк. Pensiamo sempre all'utente: come vivrà con i nostri errori, come potrà segnalarli. Non dimentichiamo che gli utenti non sono una fonte di feedback puro per l'apprendimento dei modelli, e questo deve essere ripulito con l'ausilio di sistemi ML complementari. Se non è possibile raccogliere segnali dagli utenti, cerchiamo fonti alternative di feedback, ad esempio, sistemi correlati.
• Riaddestramento. Qui l'elemento principale è la continuità, quindi ci basiamo sul modello attuale in produzione. Alleniamo nuovi modelli in modo che non si discostino molto da quello precedente grazie alla regolarizzazione armonica e ad altri trucchi simili.
• Deploy. L'autodeploy delle metriche riduce drasticamente il tempo di implementazione dei modelli. Il monitoraggio delle statistiche e della distribuzione delle decisioni, il numero di errori da parte degli utenti è essenziale per il vostro sonno tranquillo e per weekend produttivi.

Beh, spero che quanto letto vi aiuti a migliorare più rapidamente i vostri sistemi ML, a accelerare il loro lancio sul mercato e a renderli più affidabili, riducendo lo stress legato al lavoro.

Fonte: habr.com