Regole del machine learning:

Best practice per l'ingegneria ML

Martin Zinkevich

Questo documento intende aiutare chi ha una conoscenza di base del machine learning a trarre vantaggio dalle best practice di Google in questo campo. Presenta uno stile per il machine learning, simile alle linee guida di stile di Google per C++ e ad altre guide popolari alla programmazione pratica. Se hai seguito un corso di machine learning o hai creato o lavorato a un modello di machine learning, hai le competenze necessarie per leggere questo documento.

Martin Zinkevich presenta 10 delle sue regole preferite del machine learning. Continua a leggere per scoprire tutte e 43 le regole.

Terminologia

I seguenti termini verranno ripetuti più volte nella nostra discussione sul machine learning efficace:

  • Istanza: l'elemento per cui vuoi fare una previsione. Ad esempio, l'istanza potrebbe essere una pagina web che vuoi classificare come "informazioni sui gatti" o "non informazioni sui gatti".
  • Etichetta: una risposta per un'attività di previsione, ovvero la risposta prodotta da un sistema di machine learning o la risposta corretta fornita nei dati di addestramento. Ad esempio, l'etichetta di una pagina web potrebbe essere "Informazioni sui gatti".
  • Elemento: una proprietà di un'istanza utilizzata in un'attività di previsione. Ad esempio, una pagina web potrebbe avere un elemento "contiene la parola "gatto"".
  • Colonna delle funzionalità: un insieme di funzionalità correlate, ad esempio l'insieme di tutti i possibili paesi in cui potrebbero risiedere gli utenti. Un esempio può avere una o più funzionalità presenti in una colonna di funzionalità. "Colonna di funzionalità" è una terminologia specifica di Google. Una colonna di elementi è indicata come "spazio dei nomi" nel sistema VW (Yahoo/Microsoft) o come campo.
  • Esempio: un'istanza (con le relative funzionalità) e un'etichetta.
  • Modello: una rappresentazione statistica di un'attività di previsione. Addestrai un modello su esempi, quindi lo utilizzi per fare previsioni.
  • Metrica: un numero che ti interessa. Potrebbe o meno essere ottimizzato direttamente.
  • Obiettivo: una metrica che l'algoritmo sta cercando di ottimizzare.
  • Pipeline: l'infrastruttura che circonda un algoritmo di machine learning. Include la raccolta dei dati dal front-end, il loro inserimento in file di dati di addestramento, l'addestramento di uno o più modelli ed eventualmente l'esportazione dei modelli in produzione.
  • Percentuale di clic: la percentuale di visitatori di una pagina web che fanno clic su un link in un annuncio.

Panoramica

Per creare prodotti di alta qualità:

Utilizza il machine learning come il grande ingegnere che sei, non come l'esperto di machine learning che non sei.

La maggior parte dei problemi che dovrai affrontare sono, infatti, problemi di ingegneria. Anche con tutte le risorse di un grande esperto di machine learning, la maggior parte dei vantaggi proviene da funzionalità eccellenti, non da algoritmi di machine learning eccellenti. L'approccio di base è quindi:

  1. Assicurati che la pipeline sia solida da un'estremità all'altra.
  2. Inizia con un obiettivo ragionevole.
  3. Aggiungi funzionalità di buon senso in modo semplice.
  4. Assicurati che la pipeline rimanga solida.

Questo approccio funzionerà bene per un periodo di tempo prolungato. Allontanati da questo approccio solo quando non ci sono più metodi semplici per andare oltre. L'aggiunta di complessità rallenta le release future.

Una volta esaurite le soluzioni semplici, il machine learning all'avanguardia potrebbe essere davvero il tuo futuro. Consulta la sezione relativa ai progetti di machine learning della Fase III.

Questo documento è organizzato come segue:

  1. La prima parte dovrebbe aiutarti a capire se è il momento giusto per creare un sistema di machine learning.
  2. La seconda parte riguarda il deployment della prima pipeline.
  3. La terza parte riguarda il lancio e l'iterazione con l'aggiunta di nuove funzionalità alla pipeline, come valutare i modelli e lo scostamento tra addestramento e pubblicazione.
  4. La parte finale riguarda cosa fare quando raggiungi un plateau.
  5. Successivamente, è presente un elenco di lavori correlati e un'appendice con alcune informazioni sui sistemi comunemente utilizzati come esempi in questo documento.

Prima del machine learning

Regola 1: non aver paura di lanciare un prodotto senza machine learning.

Il machine learning è fantastico, ma richiede dati. In teoria, puoi prendere i dati da un problema diverso e poi modificare il modello per un nuovo prodotto, ma questo probabilmente avrà un rendimento inferiore alle euristiche di base. Se ritieni che il machine learning ti offra un aumento del 100%, un'euristica ti consentirà di raggiungere il 50% del risultato.

Ad esempio, se stai classificando le app in un marketplace di app, puoi utilizzare il tasso di installazione o il numero di installazioni come approccio basato su regole empiriche. Se rilevi spam, escludi i publisher che hanno inviato spam in precedenza. Non aver paura di utilizzare anche l'editing da parte di persone. Se devi assegnare un ranking ai contatti, assegna il ranking più alto a quelli utilizzati più di recente (o anche in ordine alfabetico). Se il machine learning non è assolutamente obbligatorio per il tuo prodotto, non utilizzarlo finché non hai dati.

Regola 2: innanzitutto, progetta e implementa le metriche.

Prima di formalizzare le funzionalità del tuo sistema di machine learning, monitora il più possibile il tuo sistema attuale. Per i seguenti motivi:

  1. È più facile ottenere l'autorizzazione dagli utenti del sistema in un secondo momento.
  2. Se ritieni che in futuro possa verificarsi un problema, è meglio ottenere subito i dati storici.
  3. Se progetti il tuo sistema tenendo presente la misurazione delle metriche, in futuro avrai risultati migliori. In particolare, non vuoi trovarti a cercare stringhe nei log per eseguire l'instrumentazione delle tue metriche.
  4. Noterai cosa cambia e cosa rimane invariato. Ad esempio, supponiamo che tu voglia ottimizzare direttamente gli utenti attivi nell'ultimo giorno. Tuttavia, durante le prime manipolazioni del sistema, potresti notare che modifiche drastiche dell'esperienza utente non modificano in modo significativo questa metrica.

Il team di Google Plus misura le espansioni per lettura, le ricondivisioni per lettura, i Mi piace per lettura, i commenti/lettura, i commenti per utente, le ricondivisioni per utente e così via, che utilizza per calcolare l'efficacia di un post al momento della pubblicazione. Tieni inoltre presente che è importante avere un framework sperimentale in cui puoi raggruppare gli utenti in bucket e aggregare le statistiche per esperimento. Consulta Regola 12.

Se sei più permissivo nella raccolta delle metriche, puoi ottenere un quadro più ampio del tuo sistema. Hai notato un problema? Aggiungi una metrica per monitorarla. Ti entusiasmano alcune modifiche quantitative dell'ultima release? Aggiungi una metrica per monitorarla.

Regola 3: scegli il machine learning anziché un'euristica complessa.

Un'euristica semplice può farti iniziare a vendere il tuo prodotto. Un'euristica complessa è impossibile da gestire. Una volta raccolti i dati e acquisita un'idea di base di ciò che stai cercando di fare, passa al machine learning. Come nella maggior parte delle attività di ingegneria del software, ti consigliamo di aggiornare costantemente il tuo approccio, che si tratti di un'euristica o di un modello di machine learning, e scoprirai che il modello di machine learning è più facile da aggiornare e gestire (vedi Regola 16).

Fase I dell'apprendimento automatico: la tua prima pipeline

Per la tua prima pipeline, concentrati sull'infrastruttura di sistema. È divertente pensare a tutto il machine learning fantasioso che farai, ma sarà difficile capire cosa sta succedendo se prima non ti fidi della pipeline.

Regola 4: mantieni semplice il primo modello e scegli l'infrastruttura giusta.

Il primo modello offre il maggiore incremento al tuo prodotto, quindi non deve essere elaborato. Tuttavia, incontrerai molti più problemi di infrastruttura di quanto immaginassi. Prima che chiunque possa utilizzare il tuo nuovo sistema di machine learning, devi determinare:

  • Come ottenere esempi per l'algoritmo di apprendimento.
  • Una prima definizione di cosa si intende per "buono" e "cattivo" per il tuo sistema.
  • Come integrare il modello nell'applicazione. Puoi applicare il modello in tempo reale o precalcolare il modello su esempi offline e memorizzare i risultati in una tabella. Ad esempio, potresti voler preclassificare le pagine web e memorizzare i risultati in una tabella, ma potresti voler classificare i messaggi della chat in tempo reale.

Scegliere funzionalità semplici semplifica la verifica di quanto segue:

  • Le funzionalità raggiungono correttamente l'algoritmo di apprendimento.
  • Il modello apprende pesi ragionevoli.
  • Le funzionalità raggiungono correttamente il modello nel server.

Una volta creato un sistema che esegue queste tre operazioni in modo affidabile, hai svolto gran parte del lavoro. Il modello semplice fornisce metriche di riferimento e un comportamento di riferimento che puoi utilizzare per testare modelli più complessi. Alcuni team puntano a un primo lancio "neutro": un primo lancio che riduce esplicitamente la priorità ai vantaggi del machine learning, per evitare di essere distratti.

Regola 5: testa l'infrastruttura indipendentemente dal machine learning.

Assicurati che l'infrastruttura sia verificabile e che le parti di apprendimento del sistema siano incapsulate in modo da poter testare tutto ciò che lo circonda. In particolare:

  1. Testa l'inserimento dei dati nell'algoritmo. Verifica che le colonne delle funzionalità che devono essere compilate siano effettivamente compilate. Se la privacy lo consente, esamina manualmente gli input dell'algoritmo di addestramento. Se possibile, controlla le statistiche nella pipeline rispetto alle statistiche relative agli stessi dati elaborati altrove.
  2. Testa l'estrazione dei modelli dall'algoritmo di addestramento. Assicurati che il modello nell'ambiente di addestramento fornisca lo stesso punteggio del modello nell'ambiente di pubblicazione (vedi Regola 37).

Il machine learning presenta un elemento di imprevedibilità, quindi assicurati di eseguire test per il codice per la creazione di esempi durante l'addestramento e la pubblicazione e di poter caricare e utilizzare un modello fisso durante la pubblicazione. Inoltre, è importante comprendere i dati: consulta Consigli pratici per l'analisi di set di dati di grandi dimensioni e complessi.

Regola 6: fai attenzione ai dati persi durante la copia delle pipeline.

Spesso creiamo una pipeline copiando una pipeline esistente (ovvero programmazione cargo cult), e la vecchia pipeline elimina i dati di cui abbiamo bisogno per la nuova pipeline. Ad esempio, la pipeline di Google Plus Per te rimuove i post più vecchi (perché cerca di classificare i post più recenti). Questa pipeline è stata copiata per essere utilizzata per lo stream di Google Plus, dove i post più vecchi sono ancora significativi, ma la pipeline continuava a eliminare i post precedenti. Un altro schema comune è registrare solo i dati visualizzati dall'utente. Pertanto, questi dati sono inutili se vogliamo creare un modello del motivo per cui un determinato post non è stato visualizzato dall'utente, perché tutti gli esempi negativi sono stati eliminati. Si è verificato un problema simile in Play. Durante la lavorazione di Play Apps Home, è stata creata una nuova pipeline che conteneva anche esempi della pagina di destinazione di Play Giochi senza alcuna funzionalità per distinguere la provenienza di ciascun esempio.

Regola 7: trasforma le strategie di ricerca in funzionalità o gestiscile esternamente.

In genere, i problemi che il machine learning sta cercando di risolvere non sono completamente nuovi. Esiste già un sistema per il ranking, la classificazione o qualsiasi problema che stai cercando di risolvere. Ciò significa che esistono una serie di regole ed euristiche. Queste stesse strategie possono aiutarti se perfezionate con il machine learning. Le tue regole di euristica devono essere analizzate per ricavare tutte le informazioni di cui dispongono, per due motivi. Innanzitutto, la transizione a un sistema di machine learning sarà più agevole. In secondo luogo, in genere queste regole contengono molto dell'intuizione sul sistema che non vuoi buttare via. Esistono quattro modi per utilizzare un'euristica esistente:

  • Esegui la preelaborazione utilizzando l'euristica. Se la funzionalità è incredibilmente eccezionale, puoi optare per questa soluzione. Ad esempio, se in un filtro antispam il mittente è già nella lista nera, non provare a capire di nuovo cosa significa "lista nera". Bloccare il messaggio. Questo approccio ha più senso nelle attività di classificazione in due classi.
  • Crea una funzionalità. La creazione diretta di una funzionalità dall'euristica è ottima. Ad esempio, se utilizzi un'euristica per calcolare un punteggio di pertinenza per un risultato della query, puoi includere il punteggio come valore di un'evidenziazione. In un secondo momento, potresti utilizzare tecniche di machine learning per modificare il valore (ad esempio, convertirlo in uno di un insieme finito di valori discreti o combinarlo con altre funzionalità), ma inizia utilizzando il valore grezzo prodotto dall'euristica.
  • Analizza gli input non elaborati dell'euristica. Se esiste un'euristica per le app che combina il numero di installazioni, il numero di caratteri nel testo e il giorno della settimana, ti consigliamo di separare questi elementi e di inserirli separatamente nell'apprendimento. Qui si applicano alcune tecniche che si applicano agli insiemi (vedi Regola 40).
  • Modifica l'etichetta. Questa è un'opzione se ritieni che l'euristica acquisisca informazioni non attualmente contenute nell'etichetta. Ad esempio, se stai cercando di massimizzare il numero di download, ma vuoi anche contenuti di qualità, la soluzione potrebbe essere moltiplicare l'etichetta per il numero medio di stelle ricevute dall'app. Qui c'è molto margine di manovra. Consulta "Il tuo primo obiettivo".

Tieni presente la complessità aggiuntiva quando utilizzi le strategie di ricerca in un sistema di ML. L'utilizzo di vecchie strategie di euristica nel nuovo algoritmo di machine learning può contribuire a creare una transizione fluida, ma valuta se esiste un modo più semplice per ottenere lo stesso effetto.

Monitoraggio

In generale, adotta buone pratiche per gli avvisi, ad esempio rendendoli utili e disponendo di una pagina della dashboard.

Regola 8: conosci i requisiti di aggiornamento del tuo sistema.

Quanto peggiorano le prestazioni se hai un modello di un giorno fa? Da una settimana? Da un quarto d'ora? Queste informazioni possono aiutarti a comprendere le priorità del monitoraggio. Se perdi una qualità del prodotto significativa se il modello non viene aggiornato per un giorno, ha senso che un tecnico lo monitori continuamente. La maggior parte dei sistemi di pubblicazione degli annunci ha nuovi annunci da gestire ogni giorno e deve aggiornarsi quotidianamente. Ad esempio, se il modello di ML per la Ricerca Google Play non viene aggiornato, può avere un impatto negativo in meno di un mese. Alcuni modelli di Per te su Google Plus non hanno un identificatore dei post, pertanto possono essere esportati con poca frequenza. Altri modelli che dispongono di identificatori dei post vengono aggiornati molto più di frequente. Tieni inoltre presente che l'aggiornamento può cambiare nel tempo, soprattutto quando le colonne delle funzionalità vengono aggiunte o rimosse dal modello.

Regola 9: rileva i problemi prima di esportare i modelli.

Molti sistemi di machine learning hanno una fase in cui esporti il modello per la pubblicazione. Se si verifica un problema con un modello esportato, si tratta di un problema rivolto agli utenti.

Esegui controlli di congruenza subito prima di esportare il modello. In particolare, assicurati che le prestazioni del modello siano ragionevoli sui dati esclusi. In alternativa, se hai dei dubbi in merito ai dati, non esportare un modello. Molti team che eseguono il deployment continuo dei modelli controllano l'area sotto la curva ROC (o AUC) prima dell'esportazione. I problemi relativi ai modelli che non sono stati esportati richiedono un avviso via email, ma i problemi relativi a un modello rivolto agli utenti potrebbero richiedere una pagina. È meglio quindi attendere e accertarsi prima di influire sugli utenti.

Regola 10: fai attenzione agli errori silenziosi.

Questo problema si verifica più spesso per i sistemi di machine learning rispetto ad altri tipi di sistemi. Supponiamo che una determinata tabella connessa non sia più aggiornata. Il sistema di machine learning si adeguerà e il comportamento continuerà a essere ragionevolmente buono, diminuendo gradualmente. A volte potresti trovare tabelle non aggiornate da mesi e un semplice aggiornamento migliora il rendimento più di qualsiasi altro lancio nel trimestre. La copertura di un elemento può cambiare a causa di modifiche all'implementazione: ad esempio, una colonna di elementi potrebbe essere compilata nel 90% degli esempi e scendere improvvisamente al 60% degli esempi. Play once aveva una tabella non aggiornata da 6 mesi e il solo aggiornamento della tabella ha generato un aumento del 2% del tasso di installazione. Se monitori le statistiche dei dati e, a volte, li ispezioni manualmente, puoi ridurre questi tipi di errori.

Regola 11: assegna proprietari e documentazione alle colonne delle funzionalità.

Se il sistema è di grandi dimensioni e sono presenti molte colonne di funzionalità, devi sapere chi ha creato o gestisce ogni colonna di funzionalità. Se la persona che conosce una colonna di funzionalità se ne va, assicurati che le informazioni siano disponibili per qualcun altro. Sebbene molte colonne delle funzionalità abbiano nomi descrittivi, è bene avere una descrizione più dettagliata di che cosa sia la funzionalità, da dove proviene e in che modo dovrebbe essere utile.

Il tuo primo obiettivo

Hai molte metriche o misurazioni del sistema che ti interessano, ma spesso l'algoritmo di machine learning richiede un singolo scopo, un numero che l'algoritmo sta "cercando" di ottimizzare. Qui distinguo tra obiettivi e metriche: una metrica è un numero qualsiasi riportato dal sistema, che può essere importante o meno. Vedi anche Regola 2.

Regola 12: non pensare troppo a quale obiettivo scegliere per l'ottimizzazione diretta.

Vuoi guadagnare, rendere felici i tuoi utenti e migliorare il mondo. Esistono moltissime metriche che ti interessano e che dovresti misurare tutte (vedi Regola 2). Tuttavia, all'inizio del processo di machine learning, noterai che tutti aumentano, anche quelli che non ottimizzi direttamente. Ad esempio, supponiamo che ti interessi il numero di clic e il tempo trascorso sul sito. Se esegui l'ottimizzazione in base al numero di clic, è probabile che il tempo di visualizzazione aumenti.

Quindi, mantieni la semplicità e non preoccuparti troppo di bilanciare le diverse metriche se puoi comunque aumentare facilmente tutte le metriche. Tuttavia, non esagerare con questa regola: non confondere il tuo obiettivo con il funzionamento ottimale del sistema (vedi Regola 39). Inoltre, se noti un aumento della metrica ottimizzata direttamente, ma decidi di non lanciarla, potrebbe essere necessaria una revisione dell'obiettivo.

Regola 13: scegli una metrica semplice, osservabile e attribuibile per il tuo primo scopo.

Spesso non sai qual è il vero scopo. Lo pensi, ma poi, mentre osservi i dati e l'analisi affiancata del vecchio sistema e del nuovo sistema di ML, ti rendi conto che vuoi modificare lo scopo. Inoltre, spesso i diversi membri del team non riescono a mettersi d'accordo sul vero obiettivo. L'obiettivo di ML deve essere qualcosa di facile da misurare e che rappresenti un sostituto dell'obiettivo "reale". In effetti, spesso non esiste un obiettivo "reale" (consulta la Regola 39). Pertanto, esegui l'addestramento con l'obiettivo di ML semplice e valuta la possibilità di aggiungere un "livello di norme" aggiuntivo che ti consenta di aggiungere una logica aggiuntiva (si spera molto semplice) per eseguire la classificazione finale.

Il comportamento utente più facile da modellare è quello osservato direttamente e attribuibile a un'azione del sistema:

  • È stato fatto clic su questo link classificato?
  • Questo oggetto classificato è stato scaricato?
  • L'oggetto classificato è stato inoltrato/ha ricevuto una risposta/è stato inviato per email?
  • Questo oggetto classificato è stato valutato?
  • L'oggetto mostrato è stato contrassegnato come spam/pornografia/offensivo?

Per prima cosa, evita di modellare gli effetti indiretti:

  • L'utente ha effettuato una visita il giorno successivo?
  • Per quanto tempo l'utente ha visitato il sito?
  • Quanti erano gli utenti attivi giornalieri?

Gli effetti indiretti sono ottime metriche e possono essere utilizzati durante i test A/B e le decisioni di lancio.

Infine, non cercare di far capire al machine learning:

  • L'utente è soddisfatto dell'utilizzo del prodotto?
  • L'utente è soddisfatto dell'esperienza?
  • Il prodotto migliora il benessere generale dell'utente?
  • Quali saranno le conseguenze sulla salute complessiva dell'azienda?

Sono tutti importanti, ma anche incredibilmente difficili da misurare. Utilizza invece i proxy: se l'utente è soddisfatto, rimarrà sul sito più a lungo. Se l'utente è soddisfatto, tornerà a visitare il sito domani. Per quanto riguarda il benessere e la salute dell'azienda, è necessario il giudizio umano per collegare qualsiasi obiettivo di machine learning alla natura del prodotto che vendi e al tuo piano aziendale.

Regola 14: iniziare con un modello interpretabile semplifica il debug.

La regressione lineare, la regressione logistica e la regressione di Poisson sono direttamente motivate da un modello probabilistico. Ogni previsione è interpretabile come probabilità o valore previsto. Ciò li rende più facili da eseguire il debug rispetto ai modelli che utilizzano obiettivi (perdita zero-uno, varie perdite a cerniera e così via) che tentano di ottimizzare direttamente l'accuratezza della classificazione o il rendimento del ranking. Ad esempio, se le probabilità durante l'addestramento si discostano da quelle previste nei confronti diretti o dall'ispezione del sistema di produzione, questa deviazione potrebbe indicare un problema.

Ad esempio, nella regressione lineare, logistica o di Poisson, esistono sottoinsiemi di dati in cui l'aspettativa media prevista è uguale all'etichetta media (1- momento calibrato o semplicemente calibrato). Questo è vero se non hai alcuna regolarizzazione e se l'algoritmo è convergente ed è approssimativamente vero in generale. Se hai un attributo che assume il valore 1 o 0 per ogni esempio, l'insieme di 3 esempi in cui l'attributo è 1 è calibrato. Inoltre, se hai una funzionalità pari a 1 per ogni esempio, l'insieme di tutti gli esempi è calibrato.

Con modelli semplici è più facile gestire i loop di feedback (consulta la Regola 36). Spesso utilizziamo queste previsioni probabilistiche per prendere una decisione: ad esempio, per classificare i post in base al valore previsto decrescente (ovvero la probabilità di clic/download e così via). Tuttavia, ricorda che quando arriva il momento di scegliere quale modello utilizzare, la decisione è più importante della probabilità dei dati in base al modello (vedi Regola 27).

Regola 15: separa il filtro dello spam e il ranking della qualità in un livello delle norme.

Il ranking della qualità è un'arte, ma il filtro antispam è una guerra. Gli indicatori che utilizzi per determinare i post di alta qualità diventeranno evidenti per chi utilizza il tuo sistema, che modificherà i propri post in modo che abbiano queste proprietà. Pertanto, il ranking della qualità dovrebbe concentrarsi sui contenuti pubblicati in buona fede. Non dovresti ignorare l'algoritmo di apprendimento del ranking della qualità per il ranking elevato del spam. Analogamente, i contenuti "piccanti" devono essere gestiti separatamente dal ranking della qualità. Il filtro antispam è un'altra storia. Devi aspettarti che le funzionalità da generare siano in continua evoluzione. Spesso, vengono inserite nel sistema regole evidenti (se un post ha più di tre voti come spam, non recuperarlo e così via). Qualsiasi modello appreso dovrà essere aggiornato quotidianamente, se non più velocemente. La reputazione del creator dei contenuti svolgerà un ruolo fondamentale.

A un certo livello, l'output di questi due sistemi dovrà essere integrato. Tieni conto che il filtraggio dello spam nei risultati di ricerca dovrebbe essere probabilmente più aggressivo rispetto al filtraggio dello spam nei messaggi email. Inoltre, è prassi standard rimuovere lo spam dai dati di addestramento per il classificatore della qualità.

Fase II dell'apprendimento automatico: feature engineering

Nella prima fase del ciclo di vita di un sistema di machine learning, i problemi importanti sono inserire i dati di addestramento nel sistema di apprendimento, eseguire l'instrumentazione di eventuali metriche di interesse e creare un'infrastruttura di pubblicazione. Dopo aver avuto un sistema end-to-end funzionante con test di unità e di sistema, inizia la fase II.

Nella seconda fase, ci sono molte opportunità a portata di mano. Esistono diverse funzionalità evidenti che potrebbero essere incorporate nel sistema. Pertanto, la seconda fase del machine learning prevede di estrarre il maggior numero possibile di funzionalità e combinarle in modo intuitivo. Durante questa fase, tutte le metriche dovrebbero essere ancora in aumento. Ci saranno molti lanci ed è un'ottima occasione per coinvolgere molti ingegneri che possono unire tutti i dati di cui hai bisogno per creare un sistema di apprendimento davvero straordinario.

Regola 16: pianifica il lancio e l'iterazione.

Non aspettarti che il modello su cui stai lavorando ora sia l'ultimo che lancerai o che smetta di lanciare modelli. Pertanto, valuta se la complessità che stai aggiungendo con questo lancio rallenterà i lanci futuri. Molti team hanno lanciato un modello ogni trimestre o più per anni. Esistono tre motivi di base per lanciare nuovi modelli:

  • Stai creando nuove funzionalità.
  • Stai ottimizzando la regolarizzazione e combinando le vecchie funzionalità in nuovi modi.
  • Stai ottimizzando l'obiettivo.

In ogni caso, dedicare un po' di tempo a un modello può essere utile: esaminare i dati inseriti nell'esempio può aiutare a trovare nuovi indicatori, nonché indicatori vecchi e inutilizzati. Pertanto, durante la creazione del modello, pensa a quanto sia facile aggiungere o rimuovere o ricombinare le funzionalità. Pensa a quanto sia facile creare una nuova copia della pipeline e verificarne la correttezza. Valuta se è possibile eseguire due o tre copie in parallelo. Infine, non preoccuparti se la funzionalità 16 di 35 viene inserita in questa versione della pipeline. Lo riceverai nel prossimo trimestre.

Regola 17: inizia con le funzionalità osservate e registrate direttamente anziché con quelle apprese.

Questo potrebbe essere un punto controverso, ma evita molti tranelli. Innanzitutto, descriviamo che cos'è un attributo appreso. Un attributo appreso è un attributo generato da un sistema esterno (ad esempio un sistema di clustering non supervisionato) o dall'apprendente stesso (ad es. tramite un modello fattorizzato o il deep learning). Entrambi possono essere utili, ma possono presentare molti problemi, quindi non devono essere inclusi nel primo modello.

Se utilizzi un sistema esterno per creare una funzionalità, ricorda che questo sistema ha un proprio scopo. Lo scopo del sistema esterno potrebbe essere correlato solo debolmente al tuo scopo attuale. Se acquisisci uno snapshot del sistema esterno, questo può diventare obsoleto. Se aggiorni le funzionalità dal sistema esterno, i significati potrebbero cambiare. Se utilizzi un sistema esterno per fornire una funzionalità, tieni presente che questo approccio richiede molta attenzione.

Il problema principale dei modelli fattorizzati e dei modelli di deep learning è che non sono convessi. Pertanto, non è garantito che sia possibile approssimare o trovare una soluzione ottimale e i minimi locali trovati in ogni iterazione possono essere diversi. Questa variazione rende difficile stabilire se l'impatto di una modifica al sistema è significativo o casuale. Creando un modello senza funzionalità di apprendimento approfondito, puoi ottenere un rendimento di base eccellente. Una volta raggiunto questo valore di riferimento, puoi provare approcci più esoterici.

Regola 18: esplora con funzionalità dei contenuti che si generalizzano in più contesti.

Spesso un sistema di machine learning è una piccola parte di un quadro molto più grande. Ad esempio, se immagini un post che potrebbe essere utilizzato nella sezione Tendenze, molte persone lo metteranno Mi piace, lo ricondivideranno o lo commenteranno prima che venga mostrato nella sezione Tendenze. Se fornisci queste statistiche all'apprendente, può promuovere nuovi post per i quali non ha dati nel contesto in cui sta ottimizzando. La sezione YouTube potrebbe utilizzare il numero di visualizzazioni o le visualizzazioni condivise (il numero di volte in cui un video è stato guardato dopo un altro) della ricerca di YouTube. Puoi anche utilizzare le valutazioni esplicite degli utenti. Infine, se utilizzi un'azione utente come etichetta, vedere questa azione nel documento in un contesto diverso può essere una funzionalità molto utile. Tutte queste funzionalità ti consentono di inserire nuovi contenuti nel contesto. Tieni presente che non si tratta di personalizzazione: scopri prima se a qualcuno piacciono i contenuti in questo contesto, poi scopri a chi piacciono di più o di meno.

Regola 19: se possibile, utilizza funzionalità molto specifiche.

Con una quantità enorme di dati, è più semplice apprendere milioni di funzionalità semplici rispetto a poche funzionalità complesse. Gli identificatori dei documenti recuperati e le query canoniche non forniscono molta generalizzazione, ma allineano il ranking alle tue etichette nelle query principali. Pertanto, non temere i gruppi di funzionalità in cui ogni funzionalità si applica a una frazione molto piccola dei dati, ma la copertura complessiva è superiore al 90%. Puoi utilizzare la regolarizzazione per eliminare le caratteristiche che si applicano a un numero troppo ridotto di esempi.

Regola 20: combina e modifica le funzionalità esistenti per creare nuove funzionalità in modo comprensibile per le persone.

Esistono diversi modi per combinare e modificare le funzionalità. I sistemi di machine learning come TensorFlow ti consentono di pre-elaborare i dati tramite trasformazioni. I due approcci più standard sono "discretizzazioni" e "incroci".

La discretizzazione consiste nel prendere una caratteristica continua e creare da essa molte caratteristiche discrete. Prendiamo in considerazione un attributo continuo come l'età. Puoi creare una funzionalità che assume il valore 1 se l'età è inferiore a 18 anni, un'altra che assume il valore 1 se l'età è compresa tra 18 e 35 anni e così via. Non soffermarti troppo sui limiti di queste tabelle di distribuzione: i quantili di base ti daranno la maggior parte dell'impatto.

Le intersezioni combinano due o più colonne di funzionalità. Una colonna di caratteristiche, nella terminologia di TensorFlow, è un insieme di caratteristiche omogenee (ad es. {male, female}, {US, Canada, Mexico} e così via). Un incrocio è una nuova colonna di funzionalità con funzionalità in, ad esempio {male, female} × {US,Canada, Mexico}. Questa nuova colonna conterrà la funzionalità (maschio, Canada). Se utilizzi TensorFlow e lo inviti a creare questa croce per te, questa funzionalità (maschio, Canada) sarà presente negli esempi che rappresentano i canadesi di sesso maschile. Tieni presente che sono necessarie enormi quantità di dati per addestrare modelli con incroci di tre, quattro o più colonne di funzionalità di base.

Gli incroci che producono colonne di funzionalità molto grandi potrebbero essere soggetti a overfitting. Ad esempio, immagina di eseguire una ricerca e di avere una colonna di funzionalità con le parole nella query e una colonna di funzionalità con le parole nel documento. Puoi combinarli con una croce, ma avrai un sacco di funzionalità (vedi Regola 21).

Quando si lavora con il testo, sono disponibili due alternative. La più draconiana è un prodotto vettoriale. Un prodotto scalare nella sua forma più semplice conteggia semplicemente il numero di parole in comune tra la query e il documento. Questa funzionalità può quindi essere discretizzata. Un altro approccio è un'intersezione: avremo quindi un elemento presente se e solo se la parola "pony" è presente sia nel documento sia nella query e un altro elemento presente se e solo se la parola "il" è presente sia nel documento sia nella query.

Regola 21: il numero di pesi delle caratteristiche che puoi apprendere in un modello lineare è approssimativamente proporzionale alla quantità di dati di cui disponi.

Esistono risultati affascinanti della teoria dell'apprendimento statistico relativi al livello di complessità appropriato per un modello, ma questa regola è praticamente tutto ciò che devi sapere. Ho avuto conversazioni con persone che dubitavano che si potesse imparare qualcosa da mille esempi o che potessero servire più di un milione di esempi, perché si bloccano in un determinato metodo di apprendimento. L'importante è scalare l'apprendimento in base alle dimensioni dei dati:

  1. Se stai lavorando a un sistema di ranking dei risultati di ricerca e ci sono milioni di parole diverse nei documenti e nella query e hai 1000 esempi etichettati, devi utilizzare un prodotto scalare tra le funzionalità dei documenti e delle query, TF-IDF e una mezza dozzina di altre funzionalità altamente progettate dall'uomo. 1000 esempi, una dozzina di funzionalità.
  2. Se hai un milione di esempi, interseca le colonne delle funzionalità del documento e della query, utilizzando la regolarizzazione e, eventualmente, la selezione delle funzionalità. In questo modo avrai a disposizione milioni di funzionalità, ma con la regolarizzazione ne avrai meno. Dieci milioni di esempi, forse centomila funzionalità.
  3. Se hai miliardi o centinaia di miliardi di esempi, puoi incrociare le colonne delle funzionalità con i token di documenti e query, utilizzando la selezione delle funzionalità e la regolarizzazione. Avrai un miliardo di esempi e 10 milioni di funzionalità. La teoria dell'apprendimento statistico raramente fornisce limiti stretti, ma offre ottime indicazioni per un punto di partenza.

Alla fine, utilizza la Regola 28 per decidere quali funzionalità utilizzare.

Regola 22: ripulisci le funzionalità che non utilizzi più.

Le funzionalità inutilizzate creano un debito tecnico. Se scopri di non utilizzare una funzionalità e che la combinazione con altre funzionalità non funziona, rimuovila dalla tua infrastruttura. Vuoi mantenere l'infrastruttura pulita in modo da poter provare le funzionalità più promettenti il più rapidamente possibile. Se necessario, qualcuno può sempre aggiungere di nuovo la funzionalità.

Tieni presente la copertura quando decidi quali funzionalità aggiungere o mantenere. Quanti esempi sono coperti dalla funzionalità? Ad esempio, se hai alcune funzionalità di personalizzazione, ma solo l'8% dei tuoi utenti le utilizza, non saranno molto efficaci.

Allo stesso tempo, alcune funzionalità potrebbero avere un rendimento superiore alle aspettative. Ad esempio, se hai una funzionalità che copre solo l'1% dei dati, ma il 90% degli esempi che la contengono sono positivi, si tratta di una funzionalità molto utile da aggiungere.

Analisi del sistema da parte di persone

Prima di passare alla terza fase del machine learning, è importante concentrarsi su un aspetto che non viene insegnato in nessun corso di machine learning: come esaminare un modello esistente e migliorarlo. Si tratta più di un'arte che di una scienza, ma esistono diversi antipattern che aiutano a evitare.

Regola 23: non sei un utente finale tipico.

Questo è forse il modo più semplice per un team di rimanere bloccato. Sebbene il fishfooding (utilizzo di un prototipo all'interno del team) e il dogfooding (utilizzo di un prototipo all'interno dell'azienda) offrano molti vantaggi, i dipendenti devono verificare se il rendimento è corretto. Anche se una modifica palesemente negativa non deve essere utilizzata, tutto ciò che sembra ragionevolmente vicino alla produzione deve essere ulteriormente testato, pagando persone non esperte per rispondere a domande su una piattaforma di crowdsourcing o tramite un esperimento dal vivo su utenti reali.

I motivi sono due. La prima è che sei troppo vicino al codice. Potresti cercare un aspetto specifico dei post o essere semplicemente troppo coinvolto emotivamente (ad es. pregiudizio di conferma). La seconda è che il tuo tempo è troppo prezioso. Valuta il costo di nove ingegneri che partecipano a una riunione di un'ora e pensa a quante etichette umane acquistate su una piattaforma di crowdsourcing.

Se vuoi davvero ricevere feedback dagli utenti, utilizza metodologie per l'esperienza utente. Creare profili utente (una descrizione è disponibile nel libro di Bill Buxton Sketching User Experiences) all'inizio di un processo ed eseguire test di usabilità (una descrizione è disponibile nel libro di Steve Krug Don't Make Me Think) in un secondo momento. I profili dell'utente prevedono la creazione di un utente ipotetico. Ad esempio, se il tuo team è composto interamente da uomini, potrebbe essere utile creare un'utente persona di 35 anni di sesso femminile (completa di funzionalità utente) e esaminare i risultati generati anziché 10 risultati per uomini di età compresa tra 25 e 40 anni. Anche coinvolgere persone reali per osservare la loro reazione al tuo sito (localmente o da remoto) durante i test di usabilità può darti una nuova prospettiva.

Regola 24: misura il delta tra i modelli.

Una delle misurazioni più semplici e talvolta più utili che puoi eseguire prima che gli utenti esaminino il nuovo modello è calcolare la differenza tra i nuovi risultati e quelli di produzione. Ad esempio, se hai un problema di ranking, esegui entrambi i modelli su un campione di query nell'intero sistema e controlla la dimensione della differenza simmetrica dei risultati (ponderata in base alla posizione del ranking). Se la differenza è molto piccola, puoi capire senza eseguire un esperimento che ci saranno poche variazioni. Se la differenza è molto elevata, devi assicurarti che la modifica sia corretta. Esaminare le query in cui la differenza simmetrica è elevata può aiutarti a comprendere qualitativamente la natura della variazione. Assicurati però che il sistema sia stabile. Assicurati che un modello, se confrontato con se stesso, abbia una differenza simmetrica bassa (idealmente zero).

Regola 25: quando scegli i modelli, le prestazioni utilitaristiche prevalgono sulla capacità predittiva.

Il modello potrebbe provare a prevedere la percentuale di clic. Tuttavia, alla fine, la domanda chiave è cosa farai con questa previsione. Se la utilizzi per classificare i documenti, la qualità del ranking finale è più importante della previsione stessa. Se prevedi la probabilità che un documento sia spam e poi hai un limite per ciò che viene bloccato, la precisione di ciò che viene consentito è più importante. Nella maggior parte dei casi, queste due cose dovrebbero essere in accordo: quando non lo sono, probabilmente il guadagno sarà ridotto. Pertanto, se viene apportata una modifica che migliora la perdita di log, ma peggiora le prestazioni del sistema, cerca un'altra funzionalità. Quando questo accade più spesso, è il momento di rivedere lo scopo del modello.

Regola 26: cerca pattern negli errori misurati e crea nuove funzionalità.

Supponiamo che tu veda un esempio di addestramento che il modello ha "sbagliato". In un compito di classificazione, questo errore potrebbe essere un falso positivo o un falso negativo. In un'attività di ranking, l'errore potrebbe essere una coppia in cui un elemento positivo ha un ranking inferiore rispetto a un elemento negativo. Il punto più importante è che questo è un esempio che il sistema di machine learning sa di aver sbagliato e vorrebbe correggere se gli viene data l'opportunità. Se fornisci al modello una funzionalità che gli consente di correggere l'errore, lo proverà a utilizzare.

D'altra parte, se provi a creare una funzionalità basata su esempi che il sistema non considera errori, la funzionalità verrà ignorata. Ad esempio, supponiamo che nella Ricerca app di Google Play un utente cerchi "giochi senza costi". Supponiamo che uno dei risultati principali sia un'app di scherzo meno pertinente. Pertanto, crei una funzionalità per le "app di scherzo". Tuttavia, se stai massimizzando il numero di installazioni e le persone installano un'app scherzo quando cercano giochi senza costi, la funzionalità "App scherzo" non avrà l'effetto desiderato.

Una volta individuati gli esempi errati del modello, cerca le tendenze al di fuori dell'attuale insieme di funzionalità. Ad esempio, se il sistema sembra sminuire i post più lunghi, aggiungi la lunghezza del post. Non essere troppo specifico sulle funzionalità che aggiungi. Se vuoi aggiungere la lunghezza del post, non cercare di indovinare cosa significa "lungo", ma aggiungi una dozzina di funzionalità e lascia che sia il modello a capire cosa farne (consulta la Regola 21). È il modo più semplice per ottenere ciò che vuoi.

Regola 27: prova a quantificare il comportamento indesiderato osservato.

Alcuni membri del team inizieranno a essere frustrati dalle proprietà del sistema che non amano e che non vengono acquisite dalla funzione di perdita esistente. A questo punto, deve fare di tutto per trasformare le lamentele in dati concreti. Ad esempio, se ritengono che nella Ricerca Google Play vengano mostrate troppe "app di scherzo", possono chiedere a valutatori umani di identificare queste app. In questo caso puoi utilizzare i dati etichettati da persone perché una parte relativamente piccola delle query rappresenta una grande parte del traffico. Se i problemi sono misurabili, puoi iniziare a utilizzarli come funzionalità, obiettivi o metriche. La regola generale è "prima misura, poi ottimizza".

Regola 28: tieni presente che un comportamento identico a breve termine non implica un comportamento identico a lungo termine.

Immagina di avere un nuovo sistema che esamini ogni doc_id ed exact_query e poi calcoli la probabilità di clic per ogni documento per ogni query. Scopri che il suo comportamento è quasi identico a quello del tuo sistema attuale sia nei test side-by-side sia nei test A/B, quindi, data la sua semplicità, lo lanci. Tuttavia, noti che non vengono mostrate nuove app. Perché? Dato che il sistema mostra un documento solo in base alla propria cronologia con quella query, non c'è modo di sapere che deve essere mostrato un nuovo documento.

L'unico modo per capire come un sistema di questo tipo funzionerebbe a lungo termine è farlo addestrare solo sui dati acquisiti quando il modello era attivo. È molto difficile.

Disallineamento addestramento/pubblicazione

Il disallineamento addestramento/produzione è una differenza tra le prestazioni durante l'addestramento e quelle durante la distribuzione. Questo scostamento può essere causato da:

  • Una discrepanza tra il modo in cui gestisci i dati nelle pipeline di addestramento e di pubblicazione.
  • Una variazione nei dati tra il momento dell'addestramento e quello della pubblicazione.
  • Un ciclo di feedback tra il modello e l'algoritmo.

Abbiamo osservato sistemi di machine learning di produzione di Google con uno scostamento tra addestramento e pubblicazione che influisce negativamente sulle prestazioni. La soluzione migliore è monitorarlo esplicitamente in modo che le modifiche al sistema e ai dati non introducano scostamenti inosservati.

Regola 29: il modo migliore per assicurarti di eseguire l'addestramento come la pubblicazione è salvare l'insieme di funzionalità utilizzate al momento della pubblicazione e poi inoltrarle a un log per utilizzarle al momento dell'addestramento.

Anche se non puoi farlo per ogni esempio, esegui questa operazione per una piccola parte, in modo da verificare la coerenza tra pubblicazione e addestramento (vedi Regola 37). I team che hanno effettuato questa misurazione in Google a volte sono rimasti sorpresi dai risultati. La home page di YouTube è passata alle funzionalità di registrazione al momento della pubblicazione con miglioramenti significativi della qualità e una riduzione della complessità del codice. Al momento, molti team stanno cambiando la propria infrastruttura.

Regola 30: non eliminare arbitrariamente i dati campionati con ponderazione in base all'importanza.

Quando hai troppi dati, è facile prendere i file 1-12 e ignorarne 13-99. Si tratta di un errore. Sebbene i dati che non sono mai stati mostrati all'utente possano essere eliminati, la ponderazione dell'importanza è la soluzione migliore per gli altri. La ponderazione dell'importanza significa che se decidi di eseguire il sampling dell'esempio X con una probabilità del 30%, devi assegnare un peso di 10/3. Con la ponderazione dell'importanza, tutte le proprietà di calibrazione discusse nella Regola 14 rimangono valide.

Regola 31: tieni presente che se unisci i dati di una tabella durante l'addestramento e la pubblicazione, i dati nella tabella potrebbero cambiare.

Supponiamo di unire gli ID documento a una tabella contenente le funzionalità per questi documenti (ad esempio il numero di commenti o clic). Tra l'addestramento e il momento di pubblicazione, le funzionalità nella tabella possono essere modificate. La previsione del modello per lo stesso documento può quindi essere diversa tra l'addestramento e la pubblicazione. Il modo più semplice per evitare questo tipo di problema è registrare le funzionalità al momento della pubblicazione (vedi Regola 32). Se la tabella varia lentamente, puoi anche acquisire uno snapshot della tabella ogni ora o ogni giorno per ottenere dati ragionevolmente vicini. Tieni presente che questo non risolve completamente il problema.

Regola 32: riutilizza il codice tra la pipeline di addestramento e la pipeline di pubblicazione, se possibile.

L'elaborazione batch è diversa dall'elaborazione online. Nell'elaborazione online, devi gestire ogni richiesta man mano che arriva (ad es. devi eseguire una ricerca distinta per ogni query), mentre nell'elaborazione collettiva puoi combinare le attività (ad es. eseguire un join). Al momento della pubblicazione, esegui l'elaborazione online, mentre la formazione è un'attività di elaborazione batch. Tuttavia, esistono alcuni accorgimenti che puoi mettere in pratica per riutilizzare il codice. Ad esempio, puoi creare un oggetto specifico per il tuo sistema in cui il risultato di eventuali query o join può essere memorizzato in un formato molto leggibile e gli errori possono essere testati facilmente. Poi, dopo aver raccolto tutte le informazioni, durante l'erogazione o l'addestramento, esegui un metodo comune per creare un collegamento tra l'oggetto leggibile da persone specifico del tuo sistema e qualsiasi formato previsto dal sistema di machine learning. In questo modo viene eliminata una fonte di disallineamento addestramento/produzione. Di conseguenza, prova a non utilizzare due linguaggi di programmazione diversi tra l'addestramento e la pubblicazione. Questa decisione renderà quasi impossibile la condivisione del codice.

Regola 33: se produci un modello basato sui dati fino al 5 gennaio, testa il modello sui dati dal 6 gennaio in poi.

In generale, misura le prestazioni di un modello sui dati raccolti dopo quelli su cui hai addestrato il modello, in quanto ciò riflette meglio ciò che il sistema farà in produzione. Se produci un modello basato sui dati fino al 5 gennaio, testa il modello sui dati del 6 gennaio. È normale che il rendimento non sia altrettanto buono con i nuovi dati, ma non dovrebbe essere radicalmente peggiore. Poiché potrebbero esserci effetti giornalieri, potresti non prevedere la percentuale di clic o il tasso di conversione medio, ma l'area sotto la curva, che rappresenta la probabilità di assegnare all'esempio positivo un punteggio superiore a quello di un esempio negativo, dovrebbe essere ragionevolmente vicina.

Regola 34: nella classificazione binaria per il filtraggio (ad esempio il rilevamento dello spam o la determinazione delle email interessanti), accetta piccoli sacrifici a breve termine delle prestazioni per dati molto puliti.

In un'attività di filtro, gli esempi contrassegnati come negativi non vengono mostrati all'utente. Supponiamo di avere un filtro che blocca il 75% degli esempi negativi durante la pubblicazione. Potresti essere tentato di estrarre ulteriori dati di addestramento dalle istanze mostrate agli utenti. Ad esempio, se un utente contrassegna come spam un'email che il tuo filtro ha consentito di passare, potresti trarre insegnamento da questa situazione.

Tuttavia, questo approccio introduce un bias di campionamento. Puoi raccogliere dati più chiari se, durante la pubblicazione, etichetti l'1% di tutto il traffico come "escludendo" e invii all'utente tutti gli esempi esclusi. Ora il filtro blocca almeno il 74% degli esempi negativi. Questi esempi esclusi possono diventare i tuoi dati di addestramento.

Tieni presente che se il filtro blocca il 95% o più degli esempi negativi, questo approccio diventa meno fattibile. Tuttavia, se vuoi misurare il rendimento della pubblicazione, puoi creare un campione ancora più piccolo (ad esempio lo 0,1% o lo 0,001%). Diecimila esempi sono sufficienti per stimare il rendimento con una buona precisione.

Regola 35: fai attenzione alla distorsione intrinseca dei problemi di ranking.

Quando cambi l'algoritmo di ranking in modo così radicale da mostrare risultati diversi, hai effettivamente modificato i dati che l'algoritmo vedrà in futuro. Questo tipo di scostamento verrà visualizzato e dovresti progettare il tuo modello in base a questo. Esistono diversi approcci. Questi approcci sono tutti modi per favorire i dati che il modello ha già visto.

  1. Hanno una regolarizzazione più elevata per gli elementi che coprono più query rispetto a quelle attivate solo per una query. In questo modo, il modello favorirà le funzionalità specifiche per una o più query rispetto a quelle che si applicano a tutte le query. Questo approccio può contribuire a evitare che risultati molto popolari vengano inclusi in query irrilevanti. Tieni presente che questo è opposto al consiglio più tradizionale di avere una maggiore regolarizzazione delle colonne delle funzionalità con più valori univoci.
  2. Consenti solo ai fattori di avere pesi positivi. Pertanto, qualsiasi caratteristica valida sarà migliore di una caratteristica "sconosciuta".
  3. Non hanno funzionalità solo per i documenti. Questa è una versione estrema del punto 1. Ad esempio, anche se una determinata app è un download popolare indipendentemente dalla query, non vuoi mostrarla ovunque. Non avere funzionalità solo per i documenti semplifica tutto. Il motivo per cui non vuoi mostrare un'app popolare specifica ovunque riguarda l'importanza di rendere raggiungibili tutte le app desiderate. Ad esempio, se un utente cerca "app per il bird watching", potrebbe scaricare "Angry Birds", ma di certo non era questa la sua intenzione. La visualizzazione di un'app di questo tipo potrebbe migliorare il tasso di download, ma lasciare insoddisfatte le esigenze dell'utente.

Regola 36: evita i loop di feedback con le funzionalità di posizionamento.

La posizione dei contenuti influisce notevolmente sulla probabilità che l'utente interagisca con essi. Se metti un'app nella prima posizione, riceverà più clic e avrai la certezza che sia più probabile che venga scelta. Un modo per risolvere questo problema è aggiungere elementi posizionali, ovvero elementi relativi alla posizione dei contenuti nella pagina. Addestrai il modello con caratteristiche di posizione e questo impara a dare un'alta ponderazione, ad esempio, alla caratteristica "1a posizione". Il modello dà quindi meno peso ad altri fattori per gli esempi con "1st­position=true". Poi, al momento della pubblicazione, non assegni a nessuna istanza la funzionalità di posizionamento o assegni a tutte la stessa funzionalità predefinita, perché assegni un punteggio ai candidati prima di decidere l'ordine in cui mostrarli.

Tieni presente che è importante mantenere le eventuali funzionalità di posizione un po' separate dal resto del modello a causa di questa asimmetria tra addestramento e test. È ideale che il modello sia la somma di una funzione delle funzionalità di posizione e di una funzione del resto delle funzionalità. Ad esempio, non incrociare le caratteristiche di posizione con alcuna caratteristica del documento.

Regola 37: misura il disallineamento addestramento/erogazione.

Esistono diversi fattori che possono causare uno sbilanciamento nel senso più generale. Inoltre, puoi suddividerlo in più parti:

  • La differenza tra il rendimento sui dati di addestramento e su quelli di esclusione. In generale, questo problema esisterà sempre e non è sempre negativo.
  • La differenza tra il rendimento sui dati di esclusione e i dati "del giorno successivo". Anche in questo caso, la funzionalità rimarrà sempre disponibile. Devi ottimizzare la regolarizzazione per massimizzare il rendimento del giorno successivo. Tuttavia, cali significativi del rendimento tra i dati di controllo e quelli del giorno successivo possono indicare che alcune funzionalità sono sensibili al tempo e potrebbero peggiorare il rendimento del modello.
  • La differenza tra il rendimento dei dati "del giorno successivo" e i dati in tempo reale. Se applichi un modello a un esempio nei dati di addestramento e allo stesso esempio al momento del servizio, dovresti ottenere esattamente lo stesso risultato (vedi Regola 5 ). Pertanto, una discrepanza in questo caso indica probabilmente un errore di progettazione.

Fase III del ML: crescita rallentata, perfezionamento dell'ottimizzazione e modelli complessi

Esistono alcuni indicatori che indicano che la seconda fase sta per terminare. Innanzitutto, i tuoi utili mensili inizieranno a diminuire. Inizierai a dover fare dei compromessi tra le metriche: alcune aumenteranno, altre diminuiranno in alcuni esperimenti. È qui che diventa interessante. Poiché i miglioramenti sono più difficili da ottenere, il machine learning deve diventare più sofisticato. Un avvertimento: questa sezione contiene più regole blue-sky rispetto alle sezioni precedenti. Abbiamo visto molti team che hanno vissuto i bei tempi del machine learning di fase I e fase II. Una volta raggiunta la fase III, i team devono trovare il proprio percorso.

Regola 38: non perdere tempo con le nuove funzionalità se il problema sono gli obiettivi non in linea.

Quando le misurazioni raggiungono un plateau, il tuo team inizierà a esaminare i problemi che non rientrano nell'ambito degli obiettivi del tuo attuale sistema di machine learning. Come accennato in precedenza, se gli obiettivi di prodotto non sono coperti dallo scopo algoritmico esistente, devi modificare lo scopo o gli obiettivi di prodotto. Ad esempio, puoi ottimizzare i clic, i Mi piace o i download, ma prendere decisioni di lancio in parte in base a valutatori umani.

Regola 39: le decisioni di lancio sono un sostituto degli obiettivi di prodotto a lungo termine.

Alice ha un'idea per ridurre la perdita logistica della previsione delle installazioni. Aggiunge una funzionalità. La perdita logistica diminuisce. Quando esegue un esperimento dal vivo, nota un aumento del tasso di installazione. Tuttavia, quando partecipa a una riunione di revisione del lancio, qualcuno fa notare che il numero di utenti attivi giornalieri è diminuito del 5%. Il team decide di non lanciare il modello. Alice è delusa, ma ora si rende conto che le decisioni di lancio dipendono da più criteri, solo alcuni dei quali possono essere ottimizzati direttamente utilizzando l'IA.

La verità è che il mondo reale non è Dungeons & Dragons: non esistono "punti di riferimento" che identificano lo stato di salute del tuo prodotto. Il team deve utilizzare le statistiche raccolte per cercare di prevedere in modo efficace l'efficacia del sistema in futuro. Devono preoccuparsi del coinvolgimento, degli utenti attivi giornalieri (DAU), degli utenti attivi in 30 giorni, delle entrate e del ritorno sull'investimento dell'inserzionista. Queste metriche misurabili nei test A/B sono solo un sostituto di obiettivi più a lungo termine: soddisfare gli utenti, aumentare il numero di utenti, soddisfare i partner e generare profitti, che anche in questo caso potresti considerare come sostituti di un prodotto utile e di alta qualità e di un'azienda prospera tra cinque anni.

Le uniche decisioni di lancio facili sono quando tutte le metriche migliorano (o almeno non peggiorano). Se il team ha la possibilità di scegliere tra un algoritmo di machine learning sofisticato e un'euristica semplice, deve scegliere quest'ultima se funziona meglio per tutte queste metriche. Inoltre, non esiste un ranking esplicito di tutti i possibili valori delle metriche. In particolare, considera i seguenti due scenari:

Esperimento Utenti attivi giornalieri Entrate/giorno
A 1 milione 4 milioni di dollari
B 2 milioni 2 milioni di dollari

Se il sistema attuale è A, è improbabile che il team passi a B. Se il sistema attuale è B, è improbabile che il team passi ad A. Ciò sembra in conflitto con un comportamento razionale; tuttavia, le previsioni di variazione delle metriche possono o meno essere confermate e, di conseguenza, ciascuna modifica comporta un rischio elevato. Ogni metrica copre un rischio che preoccupa il team.

Inoltre, nessuna metrica copre la principale preoccupazione del team: "Quali traguardi vorrei raggiungere con il mio prodotto tra cinque anni?"

Le persone fisiche, invece, tendono a preferire un obiettivo che possono ottimizzare direttamente. La maggior parte degli strumenti di machine learning favorisce questo tipo di ambiente. Un ingegnere che sviluppa nuove funzionalità può ottenere un flusso costante di lanci in un simile ambiente. Esiste un tipo di machine learning, l'apprendimento multi-obiettivo, che inizia a risolvere questo problema. Ad esempio, è possibile formulare un problema di soddisfazione delle restrizioni che ha limiti inferiori per ogni metrica e ottimizza una combinazione lineare di metriche. Tuttavia, anche in questo caso, non tutte le metriche possono essere facilmente definite come obiettivi di machine learning: se un documento viene visualizzato o un'app viene installata, è perché i contenuti sono stati mostrati. Tuttavia, è molto più difficile capire perché un utente visita il tuo sito. Predire il futuro successo di un sito nel suo complesso è un compito completo di IA: difficile quanto la visione artificiale o l'elaborazione del linguaggio naturale.

Regola 40: mantieni gli abbinamenti semplici.

I modelli unificati che acquisiscono funzionalità non elaborate e classificano direttamente i contenuti sono i modelli più facili da eseguire il debug e da comprendere. Tuttavia, un insieme di modelli (un "modello" che combina i punteggi di altri modelli) può funzionare meglio. Per semplificare, ogni modello deve essere un insieme che prende solo l'input di altri modelli o un modello di base che prende molte funzionalità, ma non entrambi. Se hai modelli su altri modelli addestrati separatamente, la loro combinazione può comportare comportamenti indesiderati.

Utilizza un modello semplice per l'assemblaggio che prende come input solo l'output dei modelli "di base". Inoltre, vuoi applicare le proprietà a questi modelli di ensemble. Ad esempio, un aumento del punteggio prodotto da un modello di base non deve diminuire il punteggio dell'ensemble. Inoltre, è preferibile che i modelli in entrata siano interpretabili semanticamente (ad esempio calibrati) in modo che le modifiche dei modelli sottostanti non confondano il modello dell'ensemble. Inoltre, assicurati che un aumento della probabilità prevista di un classificatore sottostante non diminuisca la probabilità prevista dell'ensemble.

Regola 41: quando il rendimento si stabilizza, cerca fonti di informazioni qualitativamente nuove da aggiungere anziché perfezionare gli indicatori esistenti.

Hai aggiunto alcune informazioni demografiche sull'utente. Hai aggiunto alcune informazioni sulle parole nel documento. Hai eseguito l'esplorazione del modello e hai ottimizzato la regolarizzazione. Non hai registrato un lancio con un miglioramento superiore all'1% delle metriche chiave in alcuni trimestri. Ti chiedi cosa fare adesso?

È il momento di iniziare a creare l'infrastruttura per funzionalità radicalmente diverse, come la cronologia dei documenti a cui questo utente ha eseguito l'accesso nell'ultimo giorno, settimana o anno o i dati di un'altra proprietà. Utilizza entità wikidata o elementi interni alla tua azienda (ad esempio il Knowledge Graph di Google). Utilizza il deep learning. Inizia ad adeguare le tue aspettative sul ritorno sull'investimento e intensifica le tue attività di conseguenza. Come in qualsiasi progetto di ingegneria, devi valutare il vantaggio dell'aggiunta di nuove funzionalità rispetto al costo dell'aumento della complessità.

Regola 42: non aspettarti che diversità, personalizzazione o pertinenza siano correlate alla popolarità quanto pensi.

La diversità in un insieme di contenuti può significare molte cose, tra cui la diversità della fonte dei contenuti, una delle più comuni. La personalizzazione implica che ogni utente riceva i propri risultati. La pertinenza implica che i risultati per una determinata query siano più appropriati per quella query rispetto a qualsiasi altra. Pertanto, tutte e tre queste proprietà sono definite come diverse dall'ordinario.

Il problema è che l'ordinario tende a essere difficile da battere.

Tieni presente che se il tuo sistema misura clic, tempo di visualizzazione, visualizzazioni, +1, condivide nuovamente e così via, stai misurando la popolarità dei contenuti. A volte i team cercano di apprendere un modello personale con diversità. Per personalizzare, aggiungono elementi che consentano al sistema di personalizzare (alcune caratteristiche che rappresentano l'interesse dell'utente) o diversificare (elementi che indicano se questo documento ha elementi in comune con altri documenti restituiti, come autore o contenuti) e scoprono che questi elementi hanno un peso inferiore (o a volte un segno diverso) rispetto a quanto previsto.

Ciò non significa che la diversità, la personalizzazione o la pertinenza non siano importanti. Come indicato nella regola precedente, puoi eseguire il post-trattamento per aumentare la diversità o la pertinenza. Se noti un aumento degli obiettivi a lungo termine, puoi dichiarare che la diversità/rilevanza è importante, oltre alla popolarità. Puoi quindi continuare a utilizzare l'elaborazione post-trattamento o modificare direttamente lo scopo in base alla diversità o alla pertinenza.

Regola 43: i tuoi amici tendono ad essere gli stessi su diversi prodotti. I tuoi interessi tendono a non esserlo.

I team di Google hanno ottenuto ottimi risultati utilizzando un modello che prevede la vicinanza di una connessione in un prodotto e facendolo funzionare bene in un altro. I tuoi amici sono ciò che sono. D'altra parte, ho visto diversi team faticare con le funzionalità di personalizzazione nei vari prodotti. Sì, sembra che dovrebbe funzionare. Per ora, non sembra. A volte è stato utile utilizzare i dati non elaborati di una proprietà per prevedere il comportamento in un'altra. Inoltre, tieni presente che anche sapere che un utente ha una cronologia su un'altra proprietà può essere utile. Ad esempio, la presenza di attività utente su due prodotti può essere indicativa di per sé.

Esistono molti documenti sul machine learning, sia all'interno di Google che all'esterno.

Ringraziamenti

Grazie a David Westbrook, Peter Brandt, Samuel Ieong, Chenyu Zhao, Li Wei, Michalis Potamias, Evan Rosen, Barry Rosenberg, Christine Robson, James Pine, Tal Shaked, Tushar Chandra, Mustafa Ispir, Jeremiah Harmsen, Konstantinos Katsiapis, Glen Anderson, Dan Duckworth, Shishir Birmiwal, Gal Elidan, Su Lin Wu, Jaihui Liu, Fernando Pereira e Hrishikesh Aradhye per le numerose correzioni, suggerimenti ed esempi utili per questo documento. Grazie anche a Kristen Lefevre, Suddha Basu e Chris Berg che hanno contribuito a una versione precedente. Eventuali errori, omissioni o (orrore!) opinioni impopolari sono di mia responsabilità.

Appendice

Questo documento contiene diversi riferimenti ai prodotti Google. Per fornire maggiori informazioni, di seguito è riportata una breve descrizione degli esempi più comuni.

Panoramica su YouTube

YouTube è un servizio di streaming video. I team di Che cosa guardare dopo e della home page di YouTube utilizzano modelli di ML per classificare i consigli video. La sezione Cosa guardare consiglia i video da guardare dopo quello in riproduzione, mentre la home page consiglia i video agli utenti che la stanno visitando.

Panoramica di Google Play

Google Play ha molti modelli che risolvono una serie di problemi. La Ricerca Google Play, i consigli personalizzati della home page di Google Play e le app "Installate anche dagli utenti" utilizzano tutti il machine learning.

Panoramica di Google Plus

Google Plus utilizzava il machine learning in una serie di situazioni: per classificare i post nel "stream" di post visualizzati dall'utente, per classificare i post "Più popolari" (post molto apprezzati in quel momento), per classificare le persone che conosci e così via. Google Plus ha chiuso tutti gli account personali nel 2019 ed è stato sostituito da Google Currents per gli account aziendali il 6 luglio 2020.