Regole del machine learning:

Best practice per l'ingegneria del machine learning

Martin Zinkevich

Questo documento ha lo scopo di aiutare chi ha una conoscenza di base del machine learning a trarre vantaggio dalle best practice di Google nel machine learning. Rappresenta uno stile per il machine learning, simile alla Guida di stile per C++ di Google e ad altre guide popolari alla programmazione pratica. Se hai seguito un corso di machine learning o hai creato o lavorato su un modello di machine learning, allora disponi delle competenze necessarie per leggere questo documento.

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

Terminologia

Nella nostra discussione sul machine learning efficace, ritroveremo ripetutamente i seguenti termini:

  • Istanza: l'elemento del quale vuoi eseguire una previsione. Ad esempio, l'istanza potrebbe essere una pagina web che vuoi classificare come "about cats" o "not about cats".
  • Etichetta: una risposta a 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 "sui gatti".
  • Funzionalità: una proprietà di un'istanza utilizzata in un'attività di previsione. Ad esempio, una pagina web potrebbe avere una funzionalità "contiene la parola 'gatto'".
  • Colonna delle funzionalità: un insieme di funzionalità correlate, ad esempio l'insieme di tutti i possibili paesi in cui gli utenti potrebbero vivere. Un esempio può avere una o più caratteristiche presenti in una colonna delle caratteristiche. La "colonna Funzionalità" indica la terminologia specifica di Google. Una colonna delle funzionalità è denominata "spazio dei nomi" nel sistema VW (in Yahoo/Microsoft) o un campo.
  • Esempio: un'istanza (con le sue funzionalità) e un'etichetta.
  • Modello: una rappresentazione statistica di un'attività di previsione. Addestra un modello sugli esempi, quindi lo utilizzi per fare previsioni.
  • Metrica: un numero che ti interessa. L'ottimizzazione può essere o meno diretta.
  • 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, l'inserimento in file di dati di addestramento, l'addestramento di uno o più modelli e 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 realizzare prodotti di qualità:

il machine learning è come un grande ingegnere e non come un grande esperto di machine learning come te.

La maggior parte dei problemi che affronterai sono, in effetti, problemi di natura tecnica. Nonostante con tutte le risorse di un grande esperto di machine learning, la maggior parte dei vantaggi deriva da ottime funzionalità e non da algoritmi di machine learning di alto livello. L'approccio di base è quindi:

  1. Assicurati che la tua pipeline sia solida end-to-end.
  2. Inizia con un obiettivo ragionevole.
  3. Aggiungi funzionalità di buon senso in modo semplice.
  4. Assicurati che la tua pipeline sia solida.

Questo approccio funzionerà bene per un lungo periodo di tempo. Devi allontanarti da questo approccio solo quando non ci sono trucchi più semplici per andare avanti. L'aggiunta di complessità rallenta le release future.

Una volta terminati questi semplici trucchi, il machine learning all'avanguardia potrebbe effettivamente essere nel tuo futuro. Consulta la sezione relativa ai progetti di machine learning della Fase III.

Il documento è così organizzato:

  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 e l'aggiunta di nuove funzionalità alla pipeline, la valutazione dei modelli e il disallineamento addestramento/produzione.
  4. La parte finale riguarda cosa fare quando si raggiunge un altopiano.
  5. In seguito, sono disponibili un elenco di operazioni correlate e un'appendice con alcune informazioni sui sistemi comunemente utilizzati come esempi in questo documento.

Prima del machine learning

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

Il machine learning è fantastico, ma richiede dati. In teoria, puoi prendere i dati da un problema diverso e quindi modificare il modello per un nuovo prodotto, ma probabilmente le prestazioni saranno inferiori all'heuristics di base. Se ritieni che il machine learning ti darà un incremento del 100%, l'euristica ti consentirà di ottenere il 50% del percorso.

Ad esempio, se vuoi classificare le app in un marketplace di app, puoi utilizzare come euristica il tasso di installazione o il numero di installazioni. Se rilevi lo spam, filtra i publisher che lo hanno già inviato. Non aver paura di usare il montaggio umano. Se hai bisogno di classificare i contatti, posiziona il ranking più alto utilizzato più di recente (o persino in ordine alfabetico). Se il machine learning non è assolutamente necessario per il tuo prodotto, non utilizzarlo finché non disponi di dati.

Regola 2: Progetta e implementa innanzitutto le metriche.

Prima di formalizzare ciò che farà il tuo sistema di machine learning, effettua il monitoraggio quanto più possibile nel tuo sistema attuale. Esegui questa operazione per i seguenti motivi:

  1. È più facile ottenere l'autorizzazione dagli utenti del sistema in precedenza.
  2. Se pensi che un problema possa essere fonte di preoccupazione in futuro, è meglio ottenere dati storici ora.
  3. Se progetti il tuo sistema tenendo a mente la strumentazione delle metriche, il futuro migliorerà. Nello specifico, non andrai a cercare stringhe nei log per strumentare le metriche.
  4. Noterai cosa cambia e cosa rimane invariato. Ad esempio, supponiamo che tu voglia ottimizzare direttamente gli utenti attivi in un giorno. Tuttavia, durante le prime manipolazioni del sistema, potresti notare che le alterazioni drammatiche dell'esperienza utente non cambiano notevolmente questa metrica.

Il team di Google Plus misura l'espansione per lettura, le ricondivisioni per lettura, il numero di +1 per lettura, i commenti/la lettura, i commenti per utente, le ricondivisioni per utente e così via, che utilizzano per calcolare la bontà di un post al momento della pubblicazione. Inoltre, tieni presente che è importante un framework dell'esperimento, in cui puoi raggruppare gli utenti in bucket e aggregare le statistiche in base all'esperimento. Vedi la Regola n. 12.

Una maggiore liberalità nella raccolta delle metriche ti consente di avere una visione più ampia del tuo sistema. Hai notato un problema? Aggiungi una metrica per monitorarla. Sei entusiasmante di alcuni cambiamenti quantitativi nell'ultima release? Aggiungi una metrica per monitorarla.

Regola 3: scegli il machine learning invece di un'euristica complessa.

Una semplice euristica può far conoscere il tuo prodotto. Un'euristica complessa non è sostenibile. Una volta ottenuti i dati e un'idea di base degli i risultati che vuoi ottenere, passa al machine learning. Come per la maggior parte delle attività di progettazione del software, dovrai aggiornare costantemente il tuo approccio, che si tratti di un modello euristico o di machine learning, e scoprirai che il modello di machine learning è più facile da aggiornare e gestire (consulta la Regola n. 16).

ML - fase I: la tua prima pipeline

Concentrati sulla tua infrastruttura di sistema per la tua prima pipeline. Anche se è divertente pensare a tutto il machine learning fantasioso da implementare, sarà difficile capire cosa sta succedendo se non ti fidi prima della pipeline.

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

Il primo modello offre la maggiore spinta al prodotto, quindi non deve essere elaborato. Ma incontrerai molti più problemi di infrastruttura di quanto ti aspetti. Prima che qualcuno possa utilizzare il tuo nuovo sistema di machine learning, devi determinare:

  • Come visualizzare esempi per il tuo algoritmo di apprendimento.
  • Prima di tutto su cosa significa "buono" e "cattivo" per il tuo impianto.
  • Come integrare il modello nell'applicazione. Puoi applicare il modello in tempo reale o precalcolarlo su esempi offline e archiviare i risultati in una tabella. Ad esempio, potresti voler preclassificare le pagine web e archiviare i risultati in una tabella, ma potresti voler classificare i messaggi di chat in tempo reale.

La scelta di funzionalità semplici rende più facile garantire che:

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

Una volta che disponi di un sistema che svolge queste tre attività in modo affidabile, hai completato la maggior parte del lavoro. Il modello semplice fornisce metriche di base 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à dei guadagni del machine learning, per evitare di distrarsi.

Regola 5: testa l'infrastruttura in modo indipendente dal machine learning.

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

  1. Testa il recupero dei dati nell'algoritmo. Verifica che le colonne delle caratteristiche che devono essere completate siano completate. Laddove la privacy lo consenta, esamina manualmente l'input nell'algoritmo di addestramento. Se possibile, confronta le statistiche della pipeline con quelle relative agli stessi dati elaborati altrove.
  2. Testa l'uscita dei modelli dall'algoritmo di addestramento. Assicurati che il modello nel tuo ambiente di addestramento dia lo stesso punteggio del modello nell'ambiente di pubblicazione (consulta la Regola n. 37).

Il machine learning presenta caratteristiche imprevedibili, quindi assicurati di avere test del codice al fine di creare 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 complessi e di grandi dimensioni.

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

Spesso creiamo una pipeline copiando una pipeline esistente (ad es. la programmazione del culto del carico) e la vecchia pipeline elimina i dati necessari per la nuova pipeline. Ad esempio, la pipeline per i post precedenti di Google Plus Temi caldi (perché sta tentando di classificare nuovi post). Questa pipeline è stata copiata per essere utilizzata per Google Plus Stream, dove i post precedenti sono ancora significativi, ma la pipeline eliminava ancora i post precedenti. Un altro modello comune è registrare solo i dati visualizzati dall'utente. Pertanto, questi dati sono inutili se vogliamo creare un modello per cui un determinato post non è stato visto dall'utente, perché tutti gli esempi negativi sono stati eliminati. Si è verificato un problema simile in Google Play. Mentre lavoravamo sulla home page delle app di Google Play, è stata creata una nuova pipeline che conteneva anche esempi della pagina di destinazione per Play Giochi senza alcuna funzionalità per distinguere la provenienza di ciascun esempio.

Regola 7: trasforma l'euristica in caratteristiche o gestiscile esternamente.

Di solito i problemi che il machine learning cerca di risolvere non sono del tutto nuovi. Esiste già un sistema di ranking, classificazione o qualsiasi problema tu stia cercando di risolvere. Ciò significa che ci sono una serie di regole ed euristiche. Queste stesse euristiche possono aiutarti a migliorare l'esperienza utente quando le perfezionate con il machine learning. La tua euristica dovrebbe essere minata per qualsiasi informazione di cui disponi, per due motivi. Innanzitutto, la transizione a un sistema di machine learning sarà più fluida. In secondo luogo, di solito queste regole contengono molte intuizioni sul sistema che non si vuole buttare via. Esistono quattro modi per utilizzare un'euristica esistente:

  • Pre-elabora utilizzando l'euristica. Se la funzionalità è incredibilmente fantastica, allora questa è un'opzione. Ad esempio, se il mittente è già stato inserito in una lista bloccata in un filtro antispam, non provare a capire di nuovo cosa significa "non autorizzato". Blocca il messaggio. Questo è l'approccio più logico nelle attività di classificazione binaria.
  • Crea una funzionalità. Creare direttamente una caratteristica dall'euristica è un'ottima cosa. Ad esempio, se utilizzi un'euristica per calcolare un punteggio di pertinenza per un risultato di query, puoi includere il punteggio come valore di una caratteristica. In seguito, potresti utilizzare tecniche di machine learning per manipolare il valore (ad esempio convertendo il valore in un insieme finito di valori discreti o combinandolo con altre caratteristiche), ma inizia a utilizzare il valore non elaborato prodotto dall'euristica.
  • Estrazione degli 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, valuta la possibilità di separare questi elementi e inserire questi input nell'apprendimento separatamente. Alcune tecniche applicate agli insiemi si applicano qui (vedi Regola n. 40).
  • Modifica l'etichetta. Questa è un'opzione quando ritieni che l'euristica acquisisca informazioni attualmente non contenute nell'etichetta. Ad esempio, se vuoi 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. C'è molto margine di manovra. Consulta la sezione "Il tuo primo obiettivo".

Presta attenzione alla complessità aggiuntiva quando utilizzi l'euristica in un sistema ML. L'utilizzo di vecchie euristiche nel nuovo algoritmo di machine learning può contribuire a creare una transizione fluida, ma pensa se esiste un modo più semplice per ottenere lo stesso effetto.

Monitoraggio

In generale, adotta buone prassi per gli avvisi, ad esempio rendendo gli avvisi strategici e creando una pagina dashboard.

Regola 8: conosci i requisiti di aggiornamento del sistema.

In che misura le prestazioni si riducono se hai un modello di un giorno? Hai una settimana? Hai già un quarto? Queste informazioni possono aiutarti a comprendere le priorità del tuo monitoraggio. Se perdi una qualità significativa del prodotto se il modello non viene aggiornato per un giorno, ha senso che un ingegnere lo guardi continuamente. La maggior parte dei sistemi di pubblicazione di annunci ha nuovi annunci da gestire ogni giorno e deve essere aggiornata quotidianamente. Ad esempio, se il modello ML per Google Play Search non viene aggiornato, questo potrebbe avere un impatto negativo in meno di un mese. Il modello di alcuni modelli per Temi caldi di Google Plus non include identificatori dei post, pertanto è possibile esportarli raramente. Gli altri modelli con identificatori post vengono aggiornati con maggiore frequenza. Nota anche che l'aggiornamento può cambiare nel tempo, specialmente quando le colonne delle caratteristiche vengono aggiunte o rimosse dal modello.

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

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

Esegui i controlli di integrità subito prima di esportare il modello. In particolare, assicurati che le prestazioni del modello siano ragionevoli sui dati esclusi. Oppure, se hai ancora dubbi sui dati, non esportare un modello. Molti team il deployment continuo di 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, mentre i problemi su un modello rivolto agli utenti potrebbero richiedere una pagina. Quindi meglio attendere e assicurarsi prima di avere un impatto sugli utenti.

Regola 10: verifica la presenza di errori silenziosi.

Questo è un problema che si verifica più nei sistemi di machine learning che in altri tipi di sistemi. Supponiamo che una determinata tabella che viene unita non venga più aggiornata. Il sistema di machine learning si adeguerà e il comportamento continuerà a essere ragionevolmente buono, decrescendo gradualmente. A volte trovi tabelle non aggiornate da mesi e un semplice aggiornamento migliora il rendimento più di qualsiasi altro lancio del trimestre. La copertura di una funzionalità può cambiare a causa di modifiche di implementazione: ad esempio, una colonna delle funzionalità potrebbe essere compilata nel 90% degli esempi, scendendo improvvisamente al 60%. Una volta, Play aveva un tavolo inattivo per 6 mesi e l'aggiornamento della sola tabella ha portato a un aumento del 2% del tasso di installazione. Se monitori le statistiche dei dati, oltre a ispezionare manualmente i dati di tanto in tanto, puoi ridurre questi tipi di errori.

Regola 11. Assegna proprietari e documentazione alle colonne delle caratteristiche.

Se il sistema è di grandi dimensioni e sono presenti molte colonne delle caratteristiche, è necessario sapere chi ha creato o gestisce ciascuna colonna delle caratteristiche. Se noti che la persona che comprende una colonna delle funzionalità abbandona la pagina, assicurati che qualcuno disponga delle informazioni. Sebbene molte colonne delle caratteristiche abbiano nomi descrittivi, è consigliabile avere una descrizione più dettagliata della funzionalità, della sua provenienza e del modo in cui dovrebbe essere utile.

Il tuo primo obiettivo

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

Regola 12: non pensare troppo a quale obiettivo vuoi ottimizzare direttamente.

Vuoi generare entrate, soddisfare gli utenti e rendere il mondo un posto migliore. Esistono moltissime metriche che ti interessano e devi misurarle tutte (vedi Regola n. 2). Tuttavia, nella prima fase del processo di machine learning, noterai che sono tutte in aumento, anche quelle non ottimizzate direttamente. Ad esempio, supponiamo che ti interessino il numero di clic e il tempo trascorso sul sito. Se ottimizzi per il numero di clic, è probabile che il tempo speso aumenti.

Pertanto, mantieni la semplicità e non pensare troppo a bilanciare metriche diverse quando puoi comunque aumentare facilmente tutte le metriche. Non andare oltre questa regola: non confondere il tuo obiettivo con lo stato finale del sistema (vedi la Regola n. 39). Inoltre, se ti capita di aumentare la metrica direttamente ottimizzata, ma decidi di non lanciarla, potrebbe essere necessaria una revisione oggettiva.

Regola 13. Scegli una metrica semplice, osservabile e attribuibile per il tuo primo obiettivo.

Spesso non sai qual è il vero obiettivo. Pensi di saperlo, ma poi, quando osservi i dati e l'analisi affiancata del vecchio sistema e del nuovo sistema di ML, ti rendi conto di voler modificare l'obiettivo. Inoltre, i membri di diversi team spesso non sono d'accordo sul vero obiettivo. L'obiettivo ML dovrebbe essere facile da misurare e che sia un sostituto dell'obiettivo "vero". Infatti, spesso non esiste un obiettivo "vero" (vedi la Regola n. 39). Addestra quindi l'obiettivo ML semplice e valuta la possibilità di avere un "livello di criteri" in alto che ti permetta di aggiungere logica aggiuntiva (si spera che una logica molto semplice) per effettuare il ranking finale.

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

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

Inizialmente, evita di modellare gli effetti indiretti:

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

Gli effetti indiretti rappresentano 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 del prodotto?
  • L'utente è soddisfatto dell'esperienza?
  • Il prodotto migliora il benessere generale dell'utente?
  • Quale sarà l'impatto sulla salute generale dell'azienda?

Sono tutti importanti, ma anche estremamente difficili da misurare. Utilizza invece i proxy: se l'utente è soddisfatto, rimarrà sul sito più a lungo. Se l'utente è soddisfatto, lo visiterà di nuovo domani. Per quanto riguarda il benessere e la salute aziendale, è necessario il giudizio umano per collegare qualsiasi obiettivo di machine learning alla natura del prodotto che stai vendendo e al tuo business plan.

Regola 14. Partire da un modello interpretabile semplifica il debug.

Le regressioni lineare, logistica e di Poisson sono motivate direttamente da un modello probabilistico. Ogni previsione è interpretabile come una probabilità o come valore previsto. Questo semplifica il debug rispetto ai modelli che utilizzano obiettivi (perdita zero-one, perdite per cerniera e così via) che tentano di ottimizzare direttamente l'accuratezza della classificazione o le prestazioni del ranking. Ad esempio, se le probabilità nell'addestramento deviano dalle probabilità previste nell'analisi affiancata o ispezionata del sistema di produzione, questa deviazione potrebbe rivelare un problema.

Ad esempio, nella regressione lineare, logistica o di Poisson, ci sono sottoinsiemi di dati in cui l'aspettativa media prevista corrisponde all'etichetta media (un momento calibrato o appena calibrato). Questo è vero supponendo che tu non abbia regolarizzazione e che l'algoritmo abbia convernato ed è approssimativamente vero in generale. Se hai una caratteristica che è 1 o 0 per ogni esempio, viene calibrato l'insieme di 3 esempi in cui questa caratteristica è 1. Inoltre, se hai una funzionalità che è 1 per ogni esempio, l'insieme di tutti gli esempi viene calibrato.

Con i modelli semplici, è più facile gestire i cicli di feedback (vedi la Regola n. 36). Spesso per prendere una decisione utilizziamo queste previsioni probabilistiche: ad esempio, posizionaamo i post in ordine decrescente (ovvero la probabilità di clic/download e così via). Tuttavia, ricorda che, quando arriva il momento di scegliere il modello da utilizzare, la decisione è più importante della probabilità che i dati siano forniti al modello (vedi la regola n. 27).

Regola 15: separare i filtri antispam e il ranking della qualità in un livello normativo.

Il ranking di qualità è un'arte, ma filtrare lo spam è una guerra. Gli indicatori utilizzati per determinare i post di alta qualità saranno evidenti a coloro che utilizzano il sistema, che modificheranno i propri post per ottenere queste proprietà. Pertanto, il ranking di qualità dovrebbe concentrarsi sul ranking dei contenuti pubblicati in buona fede. Non bisogna trascurare il ranking dello spam per ottenere un ranking elevato. Allo stesso modo, i contenuti "per adulti" devono essere gestiti separatamente dal ranking di qualità. I filtri antispam sono diversi. Le caratteristiche che devi generare saranno in continua evoluzione. Spesso, ci saranno regole evidenti che inserisci nel sistema (se un post ha più di tre voti spam, non recuperarlo e così via). Ogni modello appreso dovrà essere aggiornato ogni giorno, se non più velocemente. La reputazione dell'autore dei contenuti sarà fondamentale.

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

ML - Fase II: progettazione delle funzionalità

Nella prima fase del ciclo di vita di un sistema di machine learning, le questioni più importanti sono inserire i dati di addestramento nel sistema di apprendimento, ottenere una strumentazione delle metriche di interesse e creare un'infrastruttura di gestione. Una volta realizzato un sistema end-to-end funzionante con strumentazione dei test delle unità e del sistema, inizia la Fase II.

Nella seconda fase, i risultati sono molto positivi. Esistono numerose ovvie caratteristiche che possono essere inserite nel sistema. Pertanto, la seconda fase del machine learning prevede l'inserimento del maggior numero possibile di funzionalità e la loro combinazione in modi intuitivi. Durante questa fase, tutte le metriche dovrebbero comunque aumentare. Ci saranno molti lanci ed è un ottimo momento per coinvolgere molti ingegneri che possono unire tutti i dati necessari per creare un sistema di apprendimento davvero eccezionale.

Regola 16: pianifica il lancio e l'iterazione.

Non aspettarti che il modello su cui stai lavorando sia l'ultimo che lancerai o che non lancerai mai più. Valuta quindi se la complessità che aggiungi con questo lancio rallenterà i lanci futuri. Molti team hanno lanciato un modello ogni trimestre o più per anni. I motivi di base per lanciare nuovi modelli sono tre:

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

In ogni caso, dare a un modello un po' di amore può essere positivo: esaminare i dati che alimentano l'esempio può aiutare a trovare nuovi indicatori oltre a quelli vecchi e non funzionanti. Mentre crei il modello, pensa a quanto è facile aggiungere, rimuovere o ricombinare le caratteristiche. Pensa a quanto è facile creare una copia nuova della pipeline e verificarne la correttezza. Cerca di vedere se è possibile eseguire due o tre copie in parallelo. Infine, non preoccuparti se la funzionalità 16 di 35 farà parte di questa versione della pipeline. Lo riceverai il prossimo trimestre.

Regola 17. Iniziare con le caratteristiche osservate e registrate direttamente invece di quelle apprese.

Questo potrebbe essere un punto controverso, ma evita molte insidie. Innanzitutto, descriviamo che cos'è una caratteristica appresa. Una caratteristica appresa è una caratteristica generata da un sistema esterno (come un sistema di clustering non supervisionato) o dallo studente stesso (ad es. tramite un modello fattorizzato o il deep learning). Entrambi possono essere utili, ma possono presentare molti problemi, quindi non dovrebbero essere inclusi nel primo modello.

Se utilizzi un sistema esterno per creare una funzionalità, ricorda che il sistema esterno ha un proprio scopo. L'obiettivo del sistema esterno potrebbe essere solo debolmente correlato al tuo obiettivo attuale. Se acquisisci uno snapshot del sistema esterno, potrebbe 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 deep è che non sono convessi. Pertanto, non vi è alcuna garanzia che una soluzione ottimale possa essere approssimata o trovata e i minimi locali trovati su ogni iterazione possono essere diversi. Questa variante rende difficile valutare se l'impatto di una modifica al sistema è significativo o casuale. Creando un modello senza funzionalità avanzate, puoi ottenere prestazioni di riferimento eccellenti. Una volta raggiunta questa base di riferimento, puoi provare approcci più esoterici.

Regola 18: esplora con funzionalità dei contenuti che generalizzano i vari contesti.

Spesso un sistema di machine learning è una piccola parte di un quadro molto più ampio. Ad esempio, se immagini un post che potrebbe essere utilizzato in Temi caldi, molte persone aggiungono, ricondividino o commentano un post prima che venga mostrato in Temi caldi. Se fornisci queste statistiche allo studente, puoi promuovere nuovi post per i quali non dispone di dati nel contesto in cui sta ottimizzando. La sezione Guarda successivo di YouTube potrebbe utilizzare il numero di visualizzazioni o di co- visualizzazioni (il numero di volte in cui un video è stato guardato dopo che è stato guardato un altro) dalla ricerca di YouTube. Puoi anche usare valutazioni esplicite degli utenti. Infine, se utilizzi un'azione utente come etichetta, vedere l'azione sul documento in un contesto diverso può essere un'ottima funzionalità. Tutte queste funzionalità ti consentono di inserire nuovi contenuti nel contesto. Nota che non si tratta di personalizzazione: cercate innanzitutto di capire se a qualcuno piacciono i contenuti in questo contesto, poi cercate di capire a chi piacciono di più o di meno.

Regola 19: usa funzionalità molto specifiche quando puoi.

Con tantissimi dati, è più semplice apprendere milioni di semplici caratteristiche che alcune complesse. Gli identificatori dei documenti recuperati e le query canoniche non forniscono molta generalizzazione, ma allineano il tuo ranking con le tue etichette nelle query head. Pertanto, non temere i gruppi di funzionalità in cui ciascuna si applica a una porzione molto ridotta dei tuoi dati, ma la copertura complessiva è superiore al 90%. Puoi usare la regolarizzazione per eliminare le caratteristiche che si applicano a un numero troppo basso di esempi.

Regola 20: combina e modifica le funzionalità esistenti per crearne di nuove in modi comprensibili per le persone.

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

La discretizzazione consiste nell'utilizzare una caratteristica continua e nella creazione di molte caratteristiche discrete da questa. Considera una funzionalità continua, come l'età. Puoi creare una funzionalità che corrisponde a 1 se l'età ha meno di 18 anni, un'altra a 1 se l'età è compresa tra 18 e 35 anni e così via. Non pensare troppo ai limiti di questi istogrammi: i quantili di base ti daranno il massimo impatto.

Le croci combinano due o più colonne delle caratteristiche. Nella terminologia di TensorFlow, una colonna delle caratteristiche è un insieme di caratteristiche omogenee (ad es. {male, female}, {US, Canada, Mexico} e così via). Una croce è una nuova colonna di caratteristiche con caratteristiche, ad esempio {male, female} e {US,Canada, Mexico}. La nuova colonna conterrà l'elemento (maschile, Canada). Se utilizzi TensorFlow e chiedi a TensorFlow di creare questa croce per te, questa funzionalità (maschile, Canada) sarà presente negli esempi che rappresentano uomini canadesi. Tieni presente che sono necessarie enormi quantità di dati per apprendere i modelli con incroci di tre, quattro o più colonne di funzionalità di base.

Le croci che generano colonne di caratteristiche molto grandi potrebbero sovradimensionare. Ad esempio, immagina di eseguire una ricerca, di avere una colonna delle caratteristiche con parole nella query e una colonna delle caratteristiche con parole nel documento. Puoi combinarle con una croce, ma il risultato è molte caratteristiche (vedi la regola n. 21).

Quando lavori con il testo, hai due alternative. L'elemento più draconiano è un prodotto a punti. Un prodotto scalare nella sua forma più semplice conteggia semplicemente il numero di parole in comune tra la query e il documento. Questa caratteristica può quindi essere discretizzata. Un altro approccio è un'intersezione: quindi, avremo una caratteristica che è presente solo se la parola "pony" è presente sia nel documento che nella query e un'altra caratteristica che è presente solo se la parola "il" è presente sia nel documento che nella query.

Regola 21: il numero di ponderazioni delle caratteristiche che puoi apprendere in un modello lineare è approssimativamente proporzionale alla quantità di dati a tua disposizione.

Esistono affascinanti risultati della teoria dell'apprendimento statistico che riguardano il livello di complessità appropriato di un modello, ma questa regola è fondamentalmente tutto ciò che devi sapere. Ho avuto conversazioni in cui le persone erano dubbie sul fatto che da mille esempi si possa imparare qualcosa, o che avresti avuto bisogno di più di un milione di esempi, perché sono bloccati in un certo metodo di apprendimento. Il segreto è adattare l'apprendimento alle dimensioni dei dati:

  1. Se stai lavorando su un sistema di ranking dei risultati di ricerca e sono presenti 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 ingegnerizzate. 1000 esempi, una dozzina di funzionalità.
  2. Se hai un milione di esempi, incrocia le colonne delle funzionalità di documento e query, utilizzando la regolarizzazione ed eventualmente la selezione delle funzionalità. Questo ti offrirà milioni di funzionalità, ma con la regolarizzazione ne avrai meno. Dieci milioni di esempi, forse centomila caratteristiche.
  3. Se hai miliardi o centinaia di miliardi di esempi, puoi attraversare le colonne delle caratteristiche con 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 un'ottima guida per un punto di partenza.

Alla fine, usa la Regola n. 28 per decidere quali funzionalità usare.

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

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

Tieni presente la copertura quando valuti quali funzionalità aggiungere o mantenere. Quanti esempi sono coperti dalla funzionalità? Ad esempio, se disponi di alcune funzionalità di personalizzazione, ma solo l'8% degli utenti dispone di funzionalità di personalizzazione, questa soluzione non sarà molto efficace.

Allo stesso tempo, alcune funzionalità possono avere un pugno maggiore rispetto al proprio peso. Ad esempio, se hai una funzionalità che copre solo l'1% dei dati, ma il 90% degli esempi che hanno la funzionalità sono positivi, allora sarà un'ottima funzionalità da aggiungere.

Analisi umana del sistema

Prima di passare alla terza fase del machine learning, è importante concentrarsi su qualcosa che non viene insegnato in nessuna classe di machine learning: come esaminare un modello esistente e migliorarlo. Questa è più un'arte che una scienza, eppure ci sono diversi contromodelli che aiuta a evitare.

Regola 23: non sei un tipico utente finale.

Questo è forse il modo più semplice per un team di impantanarsi. Nonostante i numerosi vantaggi offerti dalla pesca (con l'utilizzo di un prototipo all'interno del team) e dalla versione sperimentale (utilizzando un prototipo all'interno dell'azienda), i dipendenti devono verificare se le prestazioni sono corrette. Sebbene una modifica palesemente errata non debba essere applicata, qualsiasi cosa che sembri ragionevolmente vicina alla produzione dovrebbe essere ulteriormente testata, pagando persone non addetti ai lavori per rispondere alle domande su una piattaforma di crowdsourcing, oppure attraverso un esperimento in tempo reale su utenti reali.

I motivi sono due. Il primo è che ti trovi troppo vicino al codice. Magari stai cercando un aspetto particolare dei post o se sei semplicemente coinvolto emotivamente (ad esempio, bias di conferma). Il secondo è che il tuo tempo è troppo prezioso. Considera il costo di nove ingegneri riuniti in una riunione di un'ora e pensa a quante etichette umane a contratto che acquistano su una piattaforma di crowdsourcing.

Se vuoi davvero ricevere feedback degli utenti, utilizza le metodologie dell'esperienza utente. Creare utenti tipo (una descrizione è presente in Sketching User Experiences di Bill Buxton) all'inizio di un processo ed eseguire i test di usabilità (una descrizione è presente in Don’t Make Me Think) di Steve Krug in seguito. Gli utenti tipo implicano la creazione di un utente ipotetico. Ad esempio, se il tuo team è formato solo da uomini, potrebbe essere utile progettare un utente tipo di utente di sesso femminile di 35 anni (completa di funzionalità utente) e osservare i risultati che genera invece di quelli per gli uomini tra i 25 e i 40 anni. Anche convincere le persone reali ad assistere alle loro reazioni sul tuo sito (a livello locale o remoto) nei test di usabilità può farti avere una nuova prospettiva.

Regola 24. Misura il delta tra i modelli.

Una delle misurazioni più semplici e a volte più utili che puoi effettuare prima che qualsiasi utente abbia esaminato il nuovo modello è calcolare in che misura i nuovi risultati sono diversi dalla produzione. Ad esempio, in caso di problemi di ranking, esegui entrambi i modelli su un campione di query effettuate nell'intero sistema e osserva la dimensione della differenza simmetrica dei risultati (ponderata in base alla posizione del ranking). Se la differenza è molto bassa, senza eseguire un esperimento puoi capire che i cambiamenti sono ridotti. Se la differenza è molto elevata, accertati che la modifica sia buona. Analizzare le query in cui la differenza simmetrica è elevata può aiutarti a capire qualitativamente come è stato il cambiamento. Tuttavia, assicurati che il sistema sia stabile. Assicurati che un modello rispetto a se stesso presenti una differenza simmetrica bassa (preferibilmente zero).

Regola 25: quando si scelgono i modelli, le prestazioni utilitarrie hanno la meglio sulla capacità predittiva.

Il modello potrebbe cercare di prevedere la percentuale di clic. Tuttavia, alla fine la domanda chiave è come si utilizza la previsione. Se lo 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 applichi una data limite ai contenuti bloccati, la precisione di ciò che è consentito è più importante. Nella maggior parte dei casi, le due cose dovrebbero essere in accordo: quando non sono d'accordo, il guadagno è probabilmente minimo. Pertanto, se viene apportata una modifica che migliora la perdita di log ma riduce le prestazioni del sistema, cerca un'altra funzionalità. Quando questa situazione inizia più spesso, è il momento di rivedere l'obiettivo del modello.

Regola 26: cerca schemi negli errori misurati e crea nuove caratteristiche.

Supponiamo di vedere un esempio di addestramento in cui il modello è "sbagliato". In un'attività 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 il ranking di un valore positivo è inferiore a quello negativo. Il punto più importante è che questo è un esempio che il sistema di machine learning sa che si è verificato un errore e vorrebbe correggere l'errore se venisse data l'opportunità. Se assegni al modello una caratteristica che consente di correggere l'errore, il modello proverà a utilizzarlo.

Se invece provi a creare una funzionalità basata su esempi che il sistema non considera come errori, la funzionalità verrà ignorata. Ad esempio, supponiamo che nella ricerca di app di Google Play una persona cerchi "giochi senza costi". Supponiamo che uno dei primi risultati sia un'app di gag meno pertinente, quindi crei una funzionalità per le "app gag". Tuttavia, se stai massimizzando il numero di installazioni e gli utenti installano un'app di gag quando cercano giochi senza costi, la funzionalità "app gag" non avrà l'effetto che vuoi.

Una volta individuati gli esempi in cui il modello ha sbagliato, cerca tendenze che non rientrano nel tuo set di caratteristiche attuale. Ad esempio, se il sistema sta retrocedendo post più lunghi, aggiungi la lunghezza dei post. Non essere troppo specifico sulle caratteristiche che aggiungi. Se vuoi aggiungere la lunghezza del post, non provare a indovinare il significato della lunghezza, ma aggiungi una decina di caratteristiche e consenti al modello di capire cosa farne (consulta la Regola n. 21). Questo è il modo più semplice per ottenere ciò che vuoi.

Regola 27: prova a quantificare i comportamenti indesiderati osservati.

Alcuni membri del tuo team inizieranno a sentirsi frustrati dalle proprietà del sistema che non gradiscono e che non sono rilevate dalla funzione di perdita esistente. A questo punto, dovrebbero fare tutto il possibile per trasformare le loro lamentele in numeri solidi. Ad esempio, se pensa che nella Ricerca di Play vengano mostrate troppe "app gag", i valutatori potrebbero farli identificare da persone fisiche. In questo caso, puoi utilizzare dati etichettati da persone fisiche poiché una frazione relativamente piccola delle query rappresenta una grande frazione del traffico. Se i problemi sono misurabili, puoi iniziare a utilizzarli come funzionalità, obiettivi o metriche. La regola generale è "misura prima, ottimizza seconda".

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 analizza ogni doc_id edexact_query e calcola la probabilità di clic per ogni documento per ogni query. Ti rendi conto che il suo comportamento è quasi identico a quello del tuo sistema attuale sia nei test affiancati che nei test A/B; pertanto, data la sua semplicità, viene lanciato. Tuttavia, noti che non vengono mostrate nuove app. Perché? Beh, dal momento che il tuo sistema mostra solo un documento basato sulla propria cronologia con quella query, non c'è modo di sapere che dovrebbe essere mostrato un nuovo documento.

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

Disallineamento addestramento/produzione

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

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

In Google abbiamo osservato sistemi di machine learning di produzione con disallineamento addestramento/produzione che influisce negativamente sulle prestazioni. La soluzione migliore è monitorarla esplicitamente in modo che le modifiche al sistema e ai dati non introducano disallineamenti inosservati.

Regola 29: il modo migliore per assicurarsi che l'addestramento sia costante e coerente consiste nel salvare l'insieme di caratteristiche utilizzate al momento della pubblicazione e poi associarle a un log per utilizzarle al momento dell'addestramento.

Anche se non puoi eseguire questa operazione per ogni esempio, fallo per una piccola frazione, in modo da poter verificare la coerenza tra la pubblicazione e l'addestramento (consulta la Regola n. 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 logging al momento della pubblicazione, con significativi miglioramenti di qualità e una riduzione della complessità del codice. Inoltre, molti team stanno cambiando l'infrastruttura mentre parliamo.

Regola 30: non eliminare i dati campionati in base alla ponderazione arbitraria.

Quando si dispone di un numero eccessivo di dati, si potrebbe avere la tentazione di prendere i file 1-12 e ignorare i file 13-99. Questo è un errore. Sebbene i dati che non sono mai stati mostrati all'utente possano essere eliminati, la ponderazione dell'importanza è la migliore per gli altri. La ponderazione dell'importanza significa che, se decidi di campionare l'esempio X con una probabilità del 30%, assegna una ponderazione di 10/3. Con la ponderazione dell'importanza, tutte le proprietà di calibrazione discusse nella Regola n. 14 rimangono valide.

Regola 31: tieni presente che se unisci i dati di una tabella al momento dell'addestramento e della pubblicazione, i dati della tabella potrebbero cambiare.

Supponi di unire gli ID documento a una tabella contenente le funzionalità per quei documenti (come il numero di commenti o clic). Tra il tempo di addestramento e quello di pubblicazione, le caratteristiche nella tabella potrebbero essere modificate. La previsione del modello per lo stesso documento potrebbe quindi differire tra addestramento e pubblicazione. Il modo più semplice per evitare questo tipo di problema è registrare le caratteristiche al momento della pubblicazione (consulta la Regola n. 32). Se la tabella cambia solo lentamente, puoi anche creare snapshot della tabella ogni ora o ogni giorno per ottenere dati abbastanza simili. Tieni presente che questo non risolve ancora completamente il problema.

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

L'elaborazione batch è diversa dall'elaborazione online. Nell'elaborazione online, devi gestire ogni richiesta man mano che arriva (ad esempio, devi eseguire una ricerca separata per ogni query), mentre nell'elaborazione batch puoi combinare le attività (ad es. creare un join). Al momento della pubblicazione, l'elaborazione è online, mentre l'addestramento è un'attività di elaborazione batch. Tuttavia, ci sono alcune cose che si può fare per riutilizzare il codice. Ad esempio, puoi creare un oggetto specifico per il tuo sistema, in cui il risultato di qualsiasi query o join può essere archiviato in modo molto leggibile e in cui gli errori possono essere testati facilmente. Dopo aver raccolto tutte le informazioni, durante la pubblicazione o l'addestramento, esegui un metodo comune per collegare gli oggetti leggibili specifici del tuo sistema e qualsiasi formato previsto dal sistema di machine learning. In questo modo si elimina una fonte di disallineamento addestramento/produzione. Come corollario, cerca di non utilizzare due linguaggi di programmazione diversi tra addestramento e pubblicazione. Questa decisione ti renderà quasi impossibile condividere il codice.

Regola 33: se crei un modello basato sui dati fino al 5 gennaio, testa il modello con i dati a partire dal 6 gennaio.

In generale, misura le prestazioni di un modello sui dati raccolti dopo i dati su cui hai addestrato il modello, poiché riflettono meglio le attività del sistema in produzione. Se generi un modello basato sui dati fino al 5 gennaio, testa il modello sui dati a partire dal 6 gennaio. Ti aspetti che il rendimento non sia altrettanto buono con i nuovi dati, ma non radicalmente peggiore. Poiché potrebbero verificarsi 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 negativo, deve essere ragionevolmente simile.

Regola 34: nella classificazione binaria per i filtri (come il rilevamento di spam o la determinazione di email interessanti), fare piccoli sacrifici a breve termine in termini di prestazioni per dati molto puliti.

In un'attività di filtro, gli esempi contrassegnati come negativi non vengono mostrati all'utente. Supponi di avere un filtro che blocca il 75% degli esempi negativi durante la pubblicazione. Potresti avere la tentazione di ricavare dati di addestramento aggiuntivi dalle istanze mostrate agli utenti. Ad esempio, se un utente contrassegna un'email come spam che è stata lasciata passare dal filtro, potresti voler imparare da questo.

Ma questo approccio introduce il bias del campionamento. Puoi raccogliere dati più puliti se, durante la pubblicazione, etichetti l'1% di tutto il traffico come "in sospeso" e invii all'utente tutti gli esempi bloccati. Ora il filtro blocca almeno il 74% degli esempi negativi. Questi esempi presentati possono diventare i tuoi dati di addestramento.

Tieni presente che se il filtro blocca almeno il 95% degli esempi negativi, questo approccio diventa meno attuabile. Tuttavia, se vuoi misurare il rendimento della pubblicazione, puoi creare un campione ancora più piccolo (ad esempio, 0,1% o 0,001%). Diecimila esempi sono sufficienti per stimare il rendimento in modo abbastanza preciso.

Regola 35: fai attenzione al disallineamento intrinseco nei problemi di ranking.

Se cambi l'algoritmo di ranking in modo radicalmente diverso da mostrare risultati diversi, hai modificato i dati che l'algoritmo vedrà in futuro. Questo tipo di inclinazione si presenterà e dovrai progettare il tuo modello intorno a questo. Esistono diversi approcci diversi. Questi approcci sono tutti modi per favorire i dati che il tuo modello ha già visto.

  1. Imposta una maggiore regolarizzazione per le caratteristiche che coprono più query rispetto a quelle attive per una sola query. In questo modo, il modello predilige le caratteristiche specifiche di una o alcune query rispetto a quelle che generalizzano per tutte le query. Questo approccio può aiutare a evitare che risultati molto popolari vengano infiltrati in query non pertinenti. Tieni presente che questo è opposto al consiglio più convenzionale di applicare una maggiore regolarizzazione alle colonne delle caratteristiche con valori più univoci.
  2. Consenti solo ponderazioni positive delle funzionalità. Pertanto, una caratteristica valida sarà migliore di una "sconosciuta".
  3. Non dispongono di funzionalità di solo documento. Questa è una versione estrema della n. 1. Ad esempio, anche se una determinata app diventa un download frequente a prescindere dalla query, non è consigliabile mostrarla ovunque. Non avere funzioni solo per documenti rende semplice. Il motivo per cui non vuoi mostrare un'app specifica molto popolare in tutto il mondo ha a che fare con l'importanza di rendere raggiungibili tutte le app desiderate. Ad esempio, se qualcuno cerca "app per il birdwatching", potrebbe scaricare "uccelli arrabbiati", ma di certo non era il suo intento. Mostrare un'app di questo tipo potrebbe migliorare il tasso di download, ma lasciare insoddisfatti le esigenze dell'utente.

Regola 36. Evita cicli di feedback con caratteristiche di posizionamento.

La posizione dei contenuti influisce notevolmente sulla probabilità che l'utente interagisca con essi. Se metti un'app nella prima posizione, gli utenti faranno clic più spesso e sarai convinto che abbia maggiori probabilità di essere selezionata. Un modo per risolvere questo problema è aggiungere caratteristiche di posizionamento, ovvero caratteristiche relative alla posizione dei contenuti nella pagina. Il modello viene addestrato con le caratteristiche di posizionamento, che impara a ponderare, ad esempio, la caratteristica "1stposition". Il modello dà quindi meno peso ad altri fattori per gli esempi con "1stposition=true". Quindi, al momento della pubblicazione, non concedi a nessuna istanza la funzionalità di posizionamento o le attribuisci la stessa funzionalità predefinita, perché attribuisci un punteggio ai candidati prima di aver deciso l'ordine in cui visualizzarli.

Tieni presente che è importante mantenere le caratteristiche di posizionamento un po' separate dal resto del modello a causa di questa asimmetria tra addestramento e test. L'ideale è far sì che il modello sia la somma di una funzione delle caratteristiche di posizionamento e di una delle altre caratteristiche. Ad esempio, non incrociare le caratteristiche di posizionamento con quelle del documento.

Regola 37: misurazione del disallineamento addestramento/al servizio.

Ci sono diversi fattori che possono causare un'inclinazione nel senso più generale. Inoltre, puoi dividerlo in più parti:

  • La differenza tra le prestazioni dei dati di addestramento e i dati di holdout. In generale, esisterà sempre e non è sempre un male.
  • La differenza tra il rendimento dei dati di holdout e quelli del giorno successivo. Anche in questo caso, esisteranno sempre. Dovresti regolare la regolarizzazione per massimizzare il rendimento del giorno successivo. Tuttavia, cali significativi nelle prestazioni tra i dati di holdout e quelli del giorno successivo possono indicare che alcune funzionalità sono sensibili al tempo e potrebbero peggiorare le prestazioni del modello.
  • La differenza tra il rendimento dei dati del giorno successivo e dei dati in tempo reale. Se applichi un modello a un esempio nei dati di addestramento e allo stesso esempio alla pubblicazione, dovresti ottenere esattamente lo stesso risultato (consulta la Regola n. 5). Pertanto, una discrepanza in questo caso probabilmente indica un errore di progettazione.

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

Ci saranno alcuni indizi che indicano che la seconda fase sta per finire. Innanzitutto, le tue entrate mensili inizieranno a diminuire. Inizierai ad avere compromessi tra le metriche: noterai un aumento e altre un calo in alcuni esperimenti. È qui che diventa interessante. Poiché i guadagni sono più difficili da ottenere, il machine learning deve diventare più sofisticato. Un avvertimento: questa sezione ha più regole del cielo blu rispetto alle sezioni precedenti. Abbiamo visto molti team attraversare i momenti felici del machine learning di Fase I e Fase II. Una volta raggiunta la Fase III, i team devono trovare la propria strada.

Regola 38: non perdere tempo con nuove funzioni se il problema è associato a obiettivi disallineati.

Man mano che le misurazioni si fermano, il team inizierà a esaminare problemi che non rientrano nell'ambito degli obiettivi del tuo attuale sistema di machine learning. Come indicato in precedenza, se gli obiettivi di prodotto non sono coperti dall'obiettivo algoritmico esistente, devi modificare l'obiettivo o gli obiettivi di prodotto. Ad esempio, puoi ottimizzare clic, +1 o download, ma prendere decisioni di lancio basate in parte su revisori umani.

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

Alice ha un'idea su come ridurre la perdita logistica dovuta alla previsione delle installazioni. Aggiunge una funzione. La perdita logistica cala. Quando conduce un esperimento in tempo reale, nota un aumento del tasso di installazione. Tuttavia, quando va a una riunione di verifica del lancio, qualcuno fa notare che il numero di utenti attivi giornalieri diminuisce 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 mediante il machine learning.

La verità è che nel mondo reale non ci sono sotterranei e draghi: non esistono "hit point" che identificano lo stato del prodotto. Il team deve utilizzare le statistiche che raccoglie per cercare di prevedere in modo efficace la qualità del sistema in futuro. Deve interessarsi al coinvolgimento, agli utenti attivi in 1 giorno (DAU), ai 30 utenti attivi giornalieri, alle entrate e al ritorno sull'investimento dell'inserzionista. Queste metriche misurabili nei test A/B di per sé sono solo un indicatore di obiettivi più a lungo termine: soddisfare gli utenti, aumentare gli utenti, soddisfare partner e profitto, che anche a quel punto potresti considerare come indicatori di un prodotto utile e di alta qualità e di un'azienda fiorente tra cinque anni.

Le uniche decisioni facili da prendere si verificano quando tutte le metriche migliorano (o almeno non peggiorano). Se il team può scegliere tra un sofisticato algoritmo di machine learning e una semplice euristica, se la semplice euristica fa un lavoro migliore con tutte queste metriche, dovrebbe scegliere l'euristica. Inoltre, non esiste un ranking esplicito di tutti i possibili valori delle metriche. Nello specifico, considera i seguenti due scenari:

Esperimento Utenti attivi giornalieri Entrate/giorno
R 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. Questo sembra in conflitto con il comportamento razionale; tuttavia, le previsioni di modifica delle metriche potrebbero o meno avere una panoramica, pertanto entrambe le operazioni comportano un grosso rischio. Ogni metrica copre alcuni rischi che interessano il team.

Inoltre, nessuna metrica copre la preoccupazione principale del team, "dove sarà il mio prodotto tra cinque anni"?

Gli individui, invece, tendono a favorire un obiettivo che possono ottimizzare direttamente. La maggior parte degli strumenti di machine learning favorisce un ambiente di questo tipo. Un ingegnere che prova a introdurre nuove funzionalità può ottenere un flusso costante di lanci in un ambiente del genere. Esiste un tipo di machine learning, apprendimento a più obiettivi, che inizia ad affrontare questo problema. Ad esempio, si può formulare un problema di soddisfazione dei vincoli con limiti inferiori su ciascuna metrica e ottimizzare alcune combinazioni lineari di metriche. Tuttavia, anche in questo caso, non tutte le metriche possono essere facilmente incluse come obiettivi di machine learning: se si fa clic su un documento o se viene installata un'app, significa che sono stati mostrati i contenuti. Ma è molto più difficile capire perché un utente visita il tuo sito. Il modo in cui prevedere il successo futuro di un sito nel suo complesso è completo con l'IA: è difficile quanto una visione artificiale o l'elaborazione del linguaggio naturale.

Regola 40: crea un mix semplice.

I modelli unificati che assumono caratteristiche non elaborate e classificano direttamente i contenuti sono i modelli più semplici da sottoporre a debug e 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 accetta solo l'input di altri modelli o un modello di base con molte funzionalità, ma non entrambi. Se i modelli si aggiungono ad altri che vengono addestrati separatamente, la loro combinazione può causare comportamenti dannosi.

Utilizza un modello semplice per l'assemblaggio che prende solo l'output dei modelli "base" come input. Vuoi anche applicare le proprietà su questi modelli di insieme. Ad esempio, un aumento del punteggio prodotto da un modello base non deve diminuire il punteggio dell'insieme. 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 di insieme. Inoltre, fai in modo che un aumento della probabilità prevista di un classificatore sottostante non diminuisca la probabilità prevista dell'insieme.

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

Hai aggiunto alcune informazioni demografiche sull'utente. Hai aggiunto alcune informazioni sulle parole nel documento. Hai esaminato l'esplorazione dei modelli e perfezionato la regolarizzazione. Non hai assistito a un lancio con un miglioramento di più dell'1% delle tue metriche chiave negli ultimi 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 l'utente ha eseguito l'accesso nell'ultimo giorno, nell'ultima settimana o nell'ultimo anno oppure dati di una proprietà diversa. Utilizza entità wikidata o elementi interni alla tua azienda (ad esempio il Knowledge Graph di Google). Usare il deep learning. Inizia ad adeguare le tue aspettative sul ritorno previsto sull'investimento ed espandi i tuoi sforzi di conseguenza. Come in qualsiasi progetto di ingegneria, devi valutare il vantaggio derivante dall'aggiunta di nuove funzionalità a fronte dei costi derivanti da una maggiore complessità.

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

La diversità in un insieme di contenuti può avere molti significati e la diversità della fonte dei contenuti è una delle più comuni. La personalizzazione implica che ciascun utente riceva i propri risultati. La pertinenza implica che i risultati per una determinata query sono più appropriati per quella query rispetto a qualsiasi altra. Tutte e tre queste proprietà sono quindi definite come diverse dall'ordinaria.

Il problema è che la normalità tende a essere difficile da battere.

Tieni presente che se il tuo sistema misura clic, tempo trascorso, visualizzazioni, +1, ricondivisioni e così via, stai misurando la popolarità dei contenuti. A volte i team provano ad apprendere un modello personale con diversità. Per personalizzare, aggiungono funzionalità che permetterebbero al sistema di personalizzare (alcune funzioni che rappresentano l'interesse dell'utente) o diversificare (caratteristiche che indicano se il documento presenta funzionalità in comune con altri documenti restituiti, ad esempio autore o contenuti) e scoprono che queste caratteristiche hanno un peso inferiore (o talvolta un segno diverso) rispetto alle aspettative.

Questo non significa che la diversità, la personalizzazione o la pertinenza non siano importanti. Come indicato nella regola precedente, puoi eseguire la post-elaborazione per aumentare diversità o pertinenza. Se noti che gli obiettivi a più lungo termine aumentano, dichiara che la diversità/pertinenza, oltre alla popolarità, è preziosa. Puoi quindi continuare a utilizzare la post-elaborazione o modificare direttamente l'obiettivo in base alla diversità o alla pertinenza.

Regola 43: i tuoi amici tendono a essere uguali per prodotti diversi. I tuoi interessi tendono a non esserlo.

I team di Google hanno preso molta influenza dall'utilizzo di un modello che prevede la vicinanza di una connessione in un prodotto e dal fatto che funzioni bene su un altro. I tuoi amici sono ciò che sono. D'altra parte, ho visto diversi team lottare con le funzionalità di personalizzazione tra i diversi prodotti. Sì, sembra che dovrebbe funzionare. Per il momento, non sembra così. A volte, è stato possibile utilizzare i dati non elaborati di una proprietà per prevedere il comportamento in un'altra. Inoltre, tieni presente che può essere utile sapere che un utente ha una cronologia su un'altra proprietà. Ad esempio, la presenza di attività utente su due prodotti può essere indicativa di per sé.

Esistono anche molti documenti sul machine learning, sia in Google che esternamente.

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, Grazie anche a Kristen Lefevre, Suddha Basu e Chris Berg che ci hanno aiutato con una versione precedente. Eventuali errori, omissioni o opinioni impopolari sono miei.

Appendice

Il presente documento contiene una serie di riferimenti ai prodotti Google. Per ulteriori informazioni, di seguito forniamo una breve descrizione degli esempi più comuni.

Panoramica su YouTube

YouTube è un servizio di video in streaming. I team della home page di YouTube e della sezione Guarda successivo di YouTube usano i modelli ML per classificare i video consigliati. La sezione Guarda successivo consiglia video da guardare dopo quello attualmente in riproduzione, mentre la home page consiglia video agli utenti che navigano nella home page.

Panoramica di Google Play

Google Play dispone di molti modelli che risolvono una serie di problemi. Le app Ricerca Google Play, Consigli personalizzati nella home page di Google Play e "Gli utenti hanno installato anche" utilizzano tutte il machine learning.

Panoramica di Google Plus

Google Plus utilizzava il machine learning in svariate situazioni: ranking dei post nello "stream" di post visualizzati dall'utente, ranking dei post "Temi caldi" (post più popolari del momento), ranking delle 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.