Regole del machine learning:

Best practice per l'ingegneria ML

Martin Zinkevich

Lo scopo di questo documento è aiutare chi ha una conoscenza di base della macchina possono sfruttare le best practice di Google nel campo del machine learning. it presenta uno stile per il machine learning, simile alla Guida di stile su Google C++ e altre guide popolari alla programmazione pratica. Se hai seguito un corso nel machine learning oppure ha creato o lavorato su un modello di machine learning, disporre delle informazioni di base necessarie per leggere questo documento.

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

Terminologia

I seguenti termini verranno riprese più volte nella nostra discussione sull'efficacia machine learning:

  • Istanza: l'elemento su cui vuoi creare una la previsione. Ad esempio, l'istanza potrebbe essere una pagina web che vuoi classificare come "riguardo ai gatti" o "non sui gatti".
  • Etichetta: una risposta per un'attività di previsione, la risposta prodotta da un di machine learning o la risposta corretta fornita nei dati di addestramento. Per ad esempio, l'etichetta per una pagina web potrebbe essere "informazioni sui gatti".
  • Funzionalità: una proprietà di un'istanza utilizzata in un'attività di previsione. Per Ad esempio, una pagina web potrebbe avere una caratteristica "contiene la parola 'gatto'".
  • Colonna delle caratteristiche: un insieme di funzionalità correlate, come l'insieme di tutte le funzionalità possibili i paesi in cui potrebbero risiedere gli utenti. Un esempio può avere una o più funzionalità presenti in una colonna delle caratteristiche. "Colonna delle caratteristiche" è la terminologia specifica di Google. Una colonna di caratteristiche è detta "spazio dei nomi" nel sistema VW (per Yahoo/Microsoft) o .
  • Esempio: un'istanza (con le sue funzionalità) e un'etichetta.
  • Modello: una rappresentazione statistica di un'attività di previsione. Un modello viene addestrato esempi usano il modello per fare previsioni.
  • Metrica: un numero che ti interessa. Può essere o meno essere ottimizzata 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, la loro inserimento nei dati di addestramento addestrare uno o più modelli ed esportare i modelli in produzione.
  • Percentuale di clic La percentuale di visitatori di una pagina web che fanno clic su un in un annuncio.

Panoramica

Per realizzare ottimi prodotti:

il machine learning è come il tuo grande ingegnere, non come il grande ma anche un esperto di machine learning.

La maggior parte dei problemi da affrontare sono, nei fatti, problemi di ingegneria. Uniforme con tutte le risorse di un bravo esperto di machine learning, la maggior parte dei provengono da funzionalità straordinarie, non da algoritmi di machine learning efficaci. Quindi, i concetti di base è il seguente:

  1. Assicurati che la pipeline sia solida end-to-end.
  2. Inizia con un obiettivo ragionevole.
  3. Aggiungi funzioni basate sul buon senso in modo semplice.
  4. Assicurati che la pipeline sia stabile.

Questo approccio funziona bene per per un lungo periodo di tempo. Deviazione da questo approccio solo quando non ce ne sono altri dei semplici trucchi per andare più lontano. L'aggiunta della complessità rallenta le release future.

Una volta che avrai esaurito i semplici trucchi, il machine learning all'avanguardia potrebbe essere nel tuo futuro. Consulta la sezione sulle Fase III progetti di machine learning.

Questo documento è disposto 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 la tua prima pipeline.
  3. La terza parte riguarda il lancio e eseguire l'iterazione aggiungendo nuove caratteristiche alla pipeline, come valutare i modelli e il disallineamento addestramento/produzione.
  4. La parte finale riguarda cosa fare quando si raggiunge un altopiano.
  5. In seguito, è presente un elenco di lavori correlati e una appendice con alcune sui sistemi comunemente usati come esempi in questo documento.

Prima del machine learning

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

Il machine learning è interessante, ma richiede dati. In teoria, si possono prendere dati da un problema diverso e poi modificare il modello per un nuovo prodotto, ma probabilmente registrerà un rendimento inferiore euristica. Se ritieni che il machine learning ti darà un incremento del 100%, mentre un'euristica ti darà il 50% della strada.

Ad esempio, se classifichi le app in un marketplace di app, puoi utilizzare la il tasso di installazione o il numero di installazioni come euristica. Se rilevi spam, escludere i publisher che hanno inviato spam in precedenza. Non aver paura di usare una persona o l'editing. Se hai bisogno di classificare i contatti, classifica quelli usati più di recente con il punteggio più alto (o persino in ordine alfabetico). Se il machine learning non è assolutamente obbligatorio per il prodotto, non utilizzarlo finché non avrai a disposizione i dati.

Regola 2: anzitutto, progetta e implementa le metriche.

Prima di formalizzare ciò che farà il tuo sistema di machine learning, monitora possibili nel sistema attuale. Esegui questa operazione per i seguenti motivi:

  1. Ora è più facile ottenere l'autorizzazione dagli utenti del sistema.
  2. Se pensi che qualcosa potrebbe costituire un problema in futuro, è meglio ottenere subito i dati storici.
  3. Se progetti il tuo sistema sulla base della strumentazione metrica, gli aspetti andranno meglio in futuro. Nello specifico, per evitare di sentirti a disagio, per le stringhe nei log per instrumentare le tue 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 Alterazioni significative dell'esperienza utente non cambiano in modo significativo in un file di dati.

Le misure del team di Google Plus si espandono per lettura, ricondivisioni per lettura, più uno per letture, commenti/letture, commenti per utente, ricondivisioni per utente e così via, che utilizzano nel calcolare la validità di un post al momento della pubblicazione. Inoltre, tieni presente che framework sperimentale, che ti consente di raggruppare gli utenti in bucket e aggregarli statistiche dall'esperimento, è importante. Consulta Regola n. 12.

Con un approccio più liberale nella raccolta delle metriche, puoi avere un quadro più ampio del tuo sistema. Noti un problema? Aggiungi una metrica per monitorarla. Entusiasta modifica quantitativa rispetto all'ultima pubblicazione? Aggiungi una metrica per monitorarla.

Regola 3: predilige il machine learning a un'euristica complessa.

Una semplice euristica può far uscire il tuo prodotto. Un'euristica complessa è e insostenibili. Una volta che hai i dati e un'idea di base di ciò che stai cercando passare al machine learning. Come nella maggior parte dell'ingegneria del software attività, è consigliabile aggiornare costantemente il tuo approccio, che si tratti di euristico o di apprendimento automatico, e scoprirai che di machine learning è più facile da aggiornare e mantenere (vedi Regola n. 16).

ML - Fase I: la tua prima pipeline

Concentrati sull'infrastruttura di sistema per la tua prima pipeline. Anche se è divertente al machine learning immaginativo che farai, sarà difficile capire cosa succede se non ti fidi una pipeline o un blocco note personalizzato.

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

Il primo modello fornisce la massima spinta al tuo prodotto, quindi non deve di fantasia. Ma incontrerai molti più problemi di infrastruttura in base alle previsioni. Prima che chiunque possa usare il tuo nuovo e fantastico sistema di machine learning, devi per determinare:

  • Come fornire esempi al tuo algoritmo di apprendimento.
  • Un primo taglio su cosa sia "buon" e "pessimo" per il tuo sistema.
  • Come integrare il modello nell'applicazione. Puoi applicare del modello in tempo reale precalcola il modello sugli esempi offline e archivia 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 live.

La scelta di funzionalità semplici aiuta a garantire che:

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

Una volta che il sistema è in grado di eseguire queste tre operazioni in modo affidabile, la maggior parte del lavoro. Il tuo modello semplice fornisce metriche di base e una comportamento di base che puoi usare per testare modelli più complessi. Alcune squadre puntano per un modello "neutro" primo lancio: un primo lancio che riduce esplicitamente la priorità vantaggi del machine learning, per evitare di distrarre.

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

Assicuratevi che l'infrastruttura sia testabile e che le parti di apprendimento il sistema è incapsulato, così puoi testare tutto ciò che lo circonda. In particolare:

  1. Testa il recupero dei dati nell'algoritmo. Verifica che le colonne delle caratteristiche devono essere compilati. Dove la privacy lo consente, manualmente esaminare l'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 modello nell'ambiente di addestramento assegna lo stesso punteggio del modello nel tuo ambiente di pubblicazione (vedi Regola n. 37).

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

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

Spesso creiamo una pipeline copiando una pipeline esistente (ad es. programma cult del carico ) e la pipeline precedente elimina i dati necessari per la nuova. Ad esempio, la pipeline per Temi caldi di Google Plus elimina post meno recenti (perché sta tentando di classificare post nuovi). Questa pipeline è stata copiati per utilizzarli per lo stream Google Plus, dove i post precedenti sono ancora significative, ma la pipeline continuava ad abbandonare i vecchi post. Un altro Il pattern comune è registrare solo i dati visualizzati dall'utente. Pertanto, questi dati vengono è inutile creare un modello per spiegare perché un determinato post non è stato visto dall'utente, perché tutti gli esempi negativi sono stati eliminati. Si è verificato un problema simile in Gioca. Durante l'elaborazione della home page delle app di Google Play, è stata creata una nuova pipeline che conteneva esempi tratti dalla pagina di destinazione di Play Giochi senza alcuna funzionalità per capire da dove proviene ogni esempio.

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

Di solito i problemi che il machine learning cerca di risolvere non sono completamente nuovi. Esiste già un sistema per il ranking, la classificazione, per qualsiasi problema tu stia cercando di risolvere. Ciò significa che ci sono una serie di regole ed euristiche. La stessa euristica può darti un miglioramento se modifichi con il machine learning. L'euristica dovrebbe essere analizzata per qualsiasi le informazioni di cui dispone, per due motivi. Innanzitutto, la transizione a una macchina appreso sarà più fluido. In secondo luogo, di solito queste regole contengono l'intuizione sul sistema che non si vuole scartare. Esistono quattro per utilizzare un'euristica esistente:

  • Pre-elabora utilizzando l'euristica. Se la funzionalità è incredibilmente eccezionale, questa è un'opzione. Ad esempio, se, in un filtro antispam, il mittente è già stato inserito nella blacklist, non provare a riscoprire cosa rientra nella lista nera e i relativi vantaggi. Blocca il messaggio. Questo approccio è più logico nel caso di classificazione.
  • Crea un elemento. È fantastico creare direttamente una caratteristica dall'euristica. Ad esempio, se utilizzi un'euristica per calcolare il punteggio di pertinenza per una query è possibile includere il punteggio come valore di una caratteristica. Più tardi potresti voler utilizzare tecniche di machine learning per massaggiare il valore (ad esempio, la conversione del valore in uno di un insieme finito di componenti o la sua combinazione con altre caratteristiche), ma inizia con i dati non elaborati il valore prodotto dall'euristica.
  • Sfrutta gli input non elaborati dell'euristica. Se esiste un'euristica per le app, che combina il numero di installazioni, il numero di caratteri testo e il giorno della settimana, quindi considera la possibilità di separare queste parti, e inserendo questi input nell'apprendimento separatamente. Alcune tecniche quelli applicabili agli insiemi si applicano qui (vedi Regola n. 40).
  • Modifica l'etichetta. Questa è un'opzione quando ritieni che l'euristica acquisisce informazioni attualmente non 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. C'è molto margine. Consulta la sezione "Il tuo primo obiettivo".

Fai attenzione alla maggiore complessità quando utilizzi l'euristica in un ML di un sistema operativo completo. L'utilizzo della vecchia euristica nel nuovo algoritmo di machine learning può aiuta a creare una transizione fluida, ma pensa se esiste una un modo più semplice per ottenere lo stesso effetto.

Monitoraggio

In generale, adotta una buona gestione degli avvisi, rendendo ad esempio utilizzabili e di avere una pagina dashboard.

Regola 8: conoscere i requisiti di aggiornamento del sistema.

Di quanto si riducono le prestazioni se si dispone di un modello risalente a un giorno fa? Una settimana vecchio? Un quarto di età? Queste informazioni possono aiutarti a comprendere le priorità del monitoraggio. Se perdi una quantità considerevole di prodotti della qualità se il modello non viene aggiornato per un giorno, ha senso che un ingegnere la guardi di continuo. La maggior parte degli annunci dei sistemi di pubblicazione hanno nuove pubblicità da gestire ogni giorno e ogni giorno. Ad esempio, se il modello ML La Ricerca su Google Play non è aggiornata, può avere un impatto negativo in meno di un mese. Alcuni modelli per Temi caldi Il modello di Google Plus non contiene identificatori di post, quindi possono esportarli raramente. Gli altri modelli che hanno identificatori dei post sono aggiornati con maggiore frequenza. Nota anche che l'aggiornamento può cambiare nel tempo, in particolare quando le colonne di caratteristiche vengono aggiunte o rimosse dal modello.

Regola 9: rileva i problemi prima di esportare i modelli

Molti sistemi di machine learning dispongono di una fase in cui il modello viene esportato in fase di pubblicazione. Se si verifica un problema con un modello esportato, si tratta di un modello rivolto all'utente. problema.

Esegui i controlli di integrità immediatamente prima di esportare il modello. In particolare, assicurati che le prestazioni del modello siano ragionevoli con i dati esclusi. Oppure, se hai permanenti in merito ai dati, non esportare un modello. Molte squadre il deployment continuo dei modelli controlla l'area sotto Curva ROC (o AUC) prima dell'esportazione. I problemi relativi ai modelli che non sono stati esportati richiedono un avviso via email, ma per i problemi riscontrati in un modello rivolto agli utenti potrebbe essere necessaria una pagina. Molto meglio attendere e assicurarsi prima di influenzare gli utenti.

Regola 10: verifica gli errori silenziosi.

Questo è un problema che si verifica più per i sistemi di machine learning che per altri sistemi diversi. Supponiamo che una determinata tabella di cui viene eseguito il join non sia più a lungo. Il sistema di machine learning si adeguerà e il comportamento continuerà a essere ragionevolmente buono e decadrà gradualmente. A volte trovi tabelle obsolete di mesi e un semplice aggiornamento migliora il rendimento più di ogni altro lancio in quel trimestre. La copertura di un La funzionalità può cambiare a causa di modifiche di implementazione, ad esempio una colonna di caratteristiche potrebbe essere compilato nel 90% degli esempi per poi scendere improvvisamente al 60% esempi. Una volta, Google Play aveva un tavolo inattivo per 6 mesi che si aggiornava la tabella da sola ha dato un incremento del 2% al tasso di installazione. Se monitori le statistiche e di ispezionarli manualmente, occasionalmente, puoi ridurre questo tipo di errori.

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

Se il sistema è di grandi dimensioni e ci sono molte colonne di caratteristiche, sai chi ha creato o mantiene ogni colonna delle caratteristiche. Se scopri che la persona comprende l'abbandono della colonna di caratteristiche, assicurati che qualcuno abbia informazioni. Anche se molte colonne di caratteristiche hanno nomi descrittivi, è utile per avere una descrizione più dettagliata della funzionalità, e come dovrebbe essere utile.

Il tuo primo obiettivo

Disponi di molte metriche o misurazioni del sistema che ti interessano, ma l'algoritmo di machine learning spesso richiede un solo obiettivo, numero che l'algoritmo sta "provando" per l'ottimizzazione. Faccio una distinzione tra obiettivi e metriche: una metrica è qualsiasi numero che il tuo sistema report, che possono essere o meno importanti. Vedi anche Regola n. 2.

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

Vuoi generare entrate, soddisfare gli utenti e migliorare il mondo posto. Ci sono moltissime metriche che ti interessano e che devi misurare tutti (vedi la Regola n. 2). Tuttavia, all'inizio del processo di machine learning, noterai che cresceranno, anche a quelli che non ottimizzi direttamente. Ad esempio, supponiamo che ti interessi numero di clic e tempo trascorso sul sito. Se ottimizzi per il numero di clic, probabilmente noterai un aumento del tempo speso.

Pertanto, punta sulla semplicità e non pensare troppo a trovare il giusto equilibrio tra metriche diverse quando puoi comunque aumentare facilmente tutte le metriche. Non usare anche questa regola non confondere l'obiettivo con lo stato finale delle di sistema (vedi Regola n. 39). E, se ti capita di dover aumentare metrica ottimizzata, ma decidendo di non lanciare, alcune revisioni obiettive potrebbero richiesta.

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

Spesso non si sa quale sia il vero obiettivo. Pensi di sì, ma poi osserverai i dati e l'analisi affiancata del vecchio sistema e del nuovo ML di sistema, ti rendi conto di voler modificare l'obiettivo. Inoltre, team diversi spesso non sono d'accordo sul vero obiettivo. L'obiettivo ML dovrebbe essere qualcosa che sia facile da misurare e che sia sostituto del "vero" obiettivo. Infatti, spesso non esiste un "vero" (vedi Regola n. 39). Quindi... addestrarlo sull'obiettivo ML semplice e considera l'idea di definire un "livello di policy" in alto che consente di aggiungere ulteriore logica (si spera che una logica molto semplice) la classifica finale.

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

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

Inizialmente, evita di modellare 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 durante il lancio prendono le loro decisioni.

Infine, non farti aiutare dal machine learning a capire:

  • L'utente è soddisfatto dell'utilizzo del prodotto?
  • L'utente è soddisfatto dell'esperienza?
  • Il prodotto migliora il benessere generale dell'utente?
  • Come influirà sulla salute generale dell'azienda?

Sono tutti aspetti importanti, ma anche estremamente difficili da misurare. Utilizza invece proxy: se l'utente è soddisfatto, rimarrà sul sito più a lungo. Se l'utente è soddisfatto, lo visiterà di nuovo domani. In termini di benessere e la salute dell'azienda, ci vuole il giudizio umano per mettere in relazione machine learning alla natura del prodotto che vendi e il tuo business plan.

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

La regressione lineare, logistica e di Poisson sono direttamente motivati da un modello probabilistico. Ogni previsione è interpretabile come un con la probabilità più alta o con un valore previsto. In questo modo è più facile eseguire il debug rispetto ai modelli che usano obiettivi (perdita zero-one, varie perdite a livello di cerniera e così via) che tentano per ottimizzare direttamente l'accuratezza della classificazione o le prestazioni del ranking. Per Ad esempio, se le probabilità nell'addestramento si discostano da quelle previste affiancate o ispezionate il sistema di produzione, questa deviazione potrebbe a individuare un problema.

Ad esempio, nella regressione lineare, logistica o di Poisson, ci sono sottoinsiemi di i dati in cui l'aspettativa media prevista corrisponde all'etichetta media (1- momento calibrato o appena calibrato). Ciò è vero supponendo che tu non abbia della regolarizzazione e che l'algoritmo è convergente. vero in generale. Se la caratteristica è 1 o 0 per ogni esempio, allora l'insieme di 3 esempi in cui la caratteristica è 1 viene calibrata. Inoltre, se hanno una caratteristica pari a 1 per ogni esempio, l'insieme di tutti gli esempi viene calibrata.

Con modelli semplici, è più facile gestire i cicli di feedback (vedi Regola n. 36). Spesso, per prendere una decisione, utilizziamo queste previsioni probabilistiche: ad es. classifica post con un valore previsto decrescente (ad es. probabilità di clic/download e così via). Tuttavia, ricorda che quando devi scegliere il modello da utilizzare, decisione è più importante della probabilità che i dati siano stati dati dal modello (vedi Regola n. 27).

Regola 15: separa i filtri antispam e il ranking della qualità in un livello delle norme.

Il ranking della qualità è un'arte, ma i filtri antispam sono una guerra. Gli indicatori che che utilizzi per determinare post di alta qualità saranno ovvi per coloro che utilizzano il tuo sistema e modificheranno i post per ottenere queste proprietà. Pertanto, il ranking della qualità dovrebbe concentrarsi sul ranking dei contenuti pubblicati con la fede. Non ignorare lo studente che valuta la qualità del ranking per valutare lo spam molto. Analogamente, "per adulti" i contenuti devono essere gestiti separatamente dalla qualità il ranking. Il filtro antispam è tutta un'altra cosa. Devi aspettarti che che devi generare sono in continua evoluzione. Spesso, regole ovvie che inserisci nel sistema (se un post ha più di tre voti spam, non recuperarli e così via). Qualsiasi modello appreso avrà vengono aggiornate quotidianamente, se non più rapidamente. La reputazione dell'autore del avranno un ruolo importante.

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

ML - Fase II: feature engineering

Nella prima fase del ciclo di vita di un sistema di machine learning, questioni importanti consistono nel inserire i dati di addestramento nel sistema di apprendimento, metriche di interesse strumentate e creano un'infrastruttura di gestione. Dopo hai un sistema end-to-end funzionante con test delle unità e del sistema instrumentati, Inizia la fase II.

Nella seconda fase, ci sono molti frutti disponibili. Esistono diverse di caratteristiche ovvie che potrebbero essere inserite nel sistema. Pertanto, il secondo fase del machine learning prevede l'inserimento del maggior numero possibile di caratteristiche e combinandole in modo intuitivo. Durante questa fase, tutte le metriche devono è ancora in crescita. Ci saranno molti lanci ed è un ottimo momento per coinvolgere molti ingegneri che possono unire tutti i dati di cui hai bisogno per creare un sistema di apprendimento davvero incredibile.

Regola 16: pianifica il lancio e l'iterazione.

Non aspettarti che il modello su cui stai lavorando ora sarà l'ultimo lancerai o addirittura interrompererai mai il lancio dei modelli. Pertanto, valuta se la complessità aggiunta con questo lancio rallenterà lanci futuri. Molti team hanno lanciato un modello ogni trimestre o più per anni. Ci sono tre motivi di base per lanciare nuovi modelli:

  • Stai progettando 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 l'inserimento nell'esempio può aiutare a trovare nuovi indicatori, oltre che vecchi, quelli. Quindi, mentre crei il tuo modello, pensa a quanto è facile aggiungere o rimuovere o ricombinare le caratteristiche. Pensa a quanto è facile creare una nuova copia della pipeline e verificarne la correttezza. Cerca di capire se è possibile avere due o tre copie eseguite in parallelo. Infine, non devi preoccuparti se la funzionalità 16 di 35 rientra in questa versione della pipeline. Dovrai ottenerlo il trimestre prossimo.

Regola 17: inizia con le caratteristiche osservate e segnalate direttamente anziché con quelle apprese.

Questo punto potrebbe essere controverso, ma evita molte insidie. Prima tra descriveremo cos'è una caratteristica appresa. Una caratteristica appresa è una caratteristica generate da un sistema esterno (come un clustering non supervisionato) sistematico) o dallo stesso studente (ad es. tramite un modello fattorizzato o deep learning). Entrambe queste opzioni possono essere utili, ma possono presentare molti problemi, per cui dovrebbero non essere nel primo modello.

Se utilizzi un sistema esterno per creare una caratteristica, ricorda che l'interfaccia sistema ha un proprio scopo. L'obiettivo del sistema esterno può essere solo debole correlati al tuo obiettivo attuale. Se acquisisci un'istantanea del server esterno sistema, può diventare obsoleto. Se aggiorni le funzionalità esterno, i significati potrebbero cambiare. Se utilizzi un sistema esterno una caratteristica, tieni presente che questo approccio richiede una grande attenzione.

Il problema principale dei modelli fattorizzati e di quelli profondi è che non convesso. Pertanto, non vi è alcuna garanzia che una soluzione ottimale possa essere approssimati o trovati e i minimi locali trovati su ogni iterazione possono essere diverso. Questa variante rende difficile valutare se l'impatto di un che una modifica al sistema sia significativa o casuale. Creando un modello senza avanzate, puoi ottenere un eccellente rendimento di base. Dopo questa data base, puoi provare approcci più esoterici.

Regola 18: esplorare con funzionalità di contenuti che generalizzano in vari contesti.

Spesso un sistema di machine learning è solo una piccola parte di un quadro molto più ampio. Per Ad esempio, se immagini un post che potrebbe essere utilizzato in Temi caldi, molte persone farà +1, ricondividerà o commenterà un post prima che venga mostrato nei contenuti Temperatura alta. Se fornisci queste statistiche allo studente, puoi promuovere nuovi post per il quale non dispone di dati nel contesto per cui esegue l'ottimizzazione. La funzionalità Cosa guardare di YouTube potrebbe utilizzare il numero di visualizzazioni o co- visualizzazioni (numero di volte in cui un video è stato guardato dopo un altro guardati) dalla ricerca di YouTube. Puoi anche usare contenuti espliciti valutazioni degli utenti. Infine, se utilizzi un'azione utente come etichetta, vedere che l'azione sul documento in un contesto diverso può essere un ottimo modo funzionalità. Tutte queste funzionalità ti consentono di inserire nuovi contenuti nel contesto. Tieni presente che non si tratta di personalizzazione: scopri se a qualcuno piace contenuti in questo contesto, poi devi capire a chi piacciono di più o meno.

Regola 19: utilizza caratteristiche molto specifiche quando possibile.

Con tantissimi dati, è più facile apprendere milioni di semplici caratteristiche rispetto a un poche caratteristiche complesse. Identificatori dei documenti recuperati e query canoniche non forniscono molta generalizzazione, ma allineano il ranking con le tue etichette nelle query head. Perciò, non aver paura dei gruppi caratteristiche in cui ogni caratteristica si applica a una frazione molto ridotta dei tuoi dati, della copertura complessiva sia superiore al 90%. Puoi utilizzare la regolarizzazione per eliminare caratteristiche applicabili a un numero troppo basso di esempi.

Regola 20: Combina e modifica le caratteristiche esistenti per crearne di nuove in modi comprensibili per l'uomo.

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

La discretizzazione consiste nell'adottare una caratteristica continua e nel creare molte caratteristiche discrete. Prendi in considerazione una funzionalità continua, come l'età. Puoi creare una caratteristica che è 1 quando l'età è inferiore a 18 anni, un'altra caratteristica che è 1 se l’età è compresa tra 18 e 35 anni e così via. Non pensarci troppo sui limiti questi istogrammi: i quantili di base ti daranno la maggior parte dell'impatto.

Gli incroci combinano due o più colonne di caratteristiche. Una colonna di caratteristiche, nel terminologia è un insieme di caratteristiche omogenee, (ad es. {maschio, femmina}, {US, Canada, Messico} e così via). Una croce è una nuova colonna di caratteristiche con caratteristiche in, ad esempio {maschio, femmina} × {US,Canada, Mexico}. Questa nuova colonna di caratteristiche conterrà l'elemento (maschio, Canada). Se utilizzi TensorFlow e dire a TensorFlow di creare questo incrocio per te. Questa caratteristica (maschile, Canada) esempi che rappresentano gli uomini canadesi. Tieni presente che ci vuole moltissimo quantità di dati per apprendere modelli con incroci di tre, quattro o più basi colonne delle caratteristiche.

Gli incroci che producono colonne di caratteristiche molto grandi possono avere un overfitting. Ad esempio, immagina di eseguire una ricerca e di avere una colonna di caratteristiche con parole nella query e c'è una colonna di caratteristiche con parole documento. È possibile combinare questi elementi con un incrocio, ma al fine di ottenere molte (consulta la Regola n. 21).

Esistono due alternative per lavorare con il testo. Il più draconiano è prodotto. Un prodotto scalare nella sua forma più semplice conta semplicemente il numero di parole in comune tra query e documento. Questa caratteristica può quindi essere discretizzati. Un altro approccio è un incrocio: quindi, avremo una caratteristica che è presente solo se la parola "pony" sia nel documento che query e un'altra caratteristica presente solo se la parola "il" è in sia il documento che la query.

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

Ci sono affascinanti risultati della teoria dell'apprendimento statistico relativi di complessità adeguato a un modello, ma questa regola è fondamentalmente che ti serve sapere. Ho avuto delle conversazioni in cui le persone dubitavano si può imparare tutto da mille esempi o che si potrebbe mai richiedono più di un milione di esempi, perché rimangono bloccati in un certo metodo di apprendimento. Il segreto è adattare l'apprendimento alla dimensione dei dati:

  1. Se lavori su un sistema di ranking di ricerca e ci sono milioni di parole diverse nei documenti e nella query e c'è 1000 esempi etichettati, devi utilizzare un prodotto scalare tra i documenti e le caratteristiche delle query, TF-IDF, e una mezza dozzina di altre persone le funzionalità di machine learning. 1000 esempi, una dozzina di caratteristiche.
  2. Se hai un milione di esempi, incrocia il documento e la query colonne di caratteristiche, utilizzando la regolarizzazione ed eventualmente la selezione delle caratteristiche. Questo ti darà milioni di funzionalità, ma con la regolarizzazione ne avranno di meno. Dieci milioni di esempi, forse centomila caratteristiche.
  3. Se si hanno miliardi o centinaia di miliardi di esempi, è possibile le colonne delle caratteristiche con token di query e documenti, utilizzando la selezione delle caratteristiche e regolarizzazione. Avrai un miliardo di esempi e 10 milioni le funzionalità di machine learning. La teoria dell'apprendimento statistico raramente dà limiti stretti, ma un'ottima guida per iniziare.

Alla fine, usa 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 ti accorgi che non stai utilizzando un caratteristica e la loro combinazione con altre funzioni non funziona, quindi dalla tua infrastruttura. Vuoi mantenere l'infrastruttura pulita in modo che che le caratteristiche più promettenti possano essere provate il più rapidamente possibile. Se necessario, qualcuno può sempre aggiungere nuovamente la tua caratteristica.

Tieni presente la copertura quando scegli quali funzionalità aggiungere o conservare. Quanti sono trattati dalla funzionalità? Ad esempio, se hai alcuni funzionalità di personalizzazione, ma solo l'8% dei tuoi utenti ha la possibilità non sarà molto efficace.

Allo stesso tempo, alcune caratteristiche possono avere un impatto superiore al loro peso. Ad esempio, se hai una caratteristica che copre solo l'1% dei dati, ma il 90% degli esempi che hanno questa caratteristica sono positive, allora sarà un'ottima caratteristica da aggiungere.

Analisi umana del sistema

Prima di passare alla terza fase del machine learning, è importante concentrarsi su qualcosa che non viene insegnato in nessun corso di machine learning, esaminare un modello esistente e migliorarlo. È più un'arte che ci sono però diversi anti-pattern che aiuta a evitare.

Regola 23: non sei un utente finale tipico.

Questo è forse il modo più semplice per un team di bloccarsi. Anche se esistono una grande varietà di vantaggi per l'alimentazione (usando un prototipo all'interno del team) e (usando un prototipo all'interno dell'azienda), i dipendenti dovrebbero osservare se il rendimento è corretto. Anche se un cambiamento che è ovviamente negativo non deve essere utilizzato, tutto ciò che sembri ragionevolmente vicino a un ambiente di produzione dovrebbe ulteriormente testando, pagando i non addetti ai lavori per rispondere a domande una piattaforma di crowdsourcing o un esperimento in diretta su utenti reali.

Questo può accadere per due motivi. La prima è che siete troppo vicini al le API nel tuo codice. Magari stai cercando un aspetto particolare dei post oppure troppo emotivamente coinvolto (ad esempio, bias di conferma). Il secondo è che il tuo tempo è troppo prezioso. Consideriamo il costo di nove ingegneri seduti in uno di ore di riunione e pensa a quante etichette umane a contratto effettuano un acquisto di crowdsourcing.

Se vuoi davvero ricevere feedback dagli utenti, utilizza l'esperienza utente metodologie. Creare utenti tipo (una descrizione è riportata nella descrizione schizzi delle esperienze utente) nelle fasi iniziali di un processo ed eseguire test di usabilità (una nella descrizione di Steve Krug Non farmi pensare) in un secondo momento. Utenti tipo implica la creazione di un utente ipotetico. Ad esempio, se il tuo team è composto solo da uomini, potrebbe essere utile progettare un utente utente femminile di 35 anni (completa di caratteristiche) ed esaminare i risultati che genera anziché i 10 risultati Uomini di età compresa tra i 25 e i 40 anni. Invitare persone reali a guardare la loro reazione tuo sito (locale o remoto) nei test di usabilità può anche offrirti punto di vista.

Regola 24: misura il delta tra i modelli.

Una delle misurazioni più semplici e a volte più utili che si possono effettuare prima che qualsiasi utente ha esaminato il tuo nuovo modello è calcolare quanto nuovi risultati provengono dalla produzione. Ad esempio, se hai un problema di ranking, eseguire entrambi i modelli su un campione di query in tutto il sistema e osservare la dimensione della differenza simmetrica dei risultati (ponderata in base al ranking media). Se la differenza è molto piccola, puoi capirla senza eseguire un esperimento che ci saranno pochi cambiamenti. Se la differenza è molto grande, devi assicurarti che la modifica sia corretta. Uno sguardo oltre in cui la differenza simmetrica è elevata può aiutarti a capire qualitativamente è stata la modifica. Assicurati, tuttavia, che il sistema sia stabile. Assicuratevi che il modello confrontato con se stesso abbia un valore basso (idealmente zero) differenza simmetrica.

Regola 25: nella scelta dei modelli, le prestazioni utilitarie sono più efficaci del potere predittivo.

Il modello potrebbe provare a prevedere la percentuale di clic. Tuttavia, alla fine, la chiave domanda è come si fa con la previsione. Se la utilizzi per classificare documenti, la qualità del ranking finale conta di più che la previsione stessa. Se prevedi la probabilità che un documento sia spam avere un limite relativo a ciò che è bloccato, la precisione di ciò che è consentito attraverso le pratiche. Nella maggior parte dei casi, questi due aspetti dovrebbero trovarsi accordo: quando non sono d'accordo, il guadagno è scarso. Pertanto, se c'è una modifica che migliora la perdita di log, ma ne peggiora le prestazioni nel sistema, necessiti di un'altra caratteristica. Quando questo accade più spesso, è il momento di rivedere l'obiettivo del modello.

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

Supponi di vedere un esempio di addestramento in cui il modello ha "sbagliato". In un 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 positivo è stato classificato più basso che negativo. La cosa più importante è che questo è un esempio in cui sistema di machine learning sa che ha sbagliato e vorrebbe correggerlo se dato l'opportunità. Se assegni al modello una caratteristica che gli consente di correggere l'errore, il modello proverà a utilizzarlo.

D'altra parte, se provi a creare una caratteristica basata su esempi non considerano errori, la caratteristica verrà ignorata. Ad esempio, supponiamo che nella ricerca di app di Google Play qualcuno cerchi "giochi senza costi". Supponiamo che uno dei primi risultati è un'app gag meno pertinente. Crei quindi una caratteristica "app gag". Se invece massimizzi il numero di installazioni e di utenti installare un'app gag quando cercano giochi senza costi, le "app gag" funzionalità non avranno l'effetto desiderato.

Una volta ottenuti esempi di errori del modello, cerca le tendenze che al di fuori dell'insieme di caratteristiche corrente. Ad esempio, se il sistema sembra essere far retrocedere post più lunghi e aggiungere la lunghezza del post. Non essere troppo specifico riguardo al le caratteristiche che aggiungi. Per aggiungere una lunghezza di post, non provare a indovinare quale significa che è sufficiente aggiungere una decina di caratteristiche e il modello "Let" stabilisce cosa fare con loro (vedi Regola n. 21 . È 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 essere frustrati dalle proprietà dei o sistemi non graditi, che non vengono acquisiti dalla funzione loss esistente. Alle ore a questo punto, dovrebbero fare tutto il possibile per trasformare le loro lamentele in numeri. Ad esempio, se pensa che un numero eccessivo di "app gag" vengono mostrati nella ricerca di Google Play, potrebbero far identificare le app gag a revisori umani. (puoi utilizzare in modo pratico dati etichettati dal team umano, in quanto una quantità relativamente piccola frazione delle query rappresenta un'ampia frazione del traffico.) Se le tue problemi sono misurabili, puoi iniziare a utilizzarli come caratteristiche, o metriche. La regola generale è "misurare prima, ottimizzare per seconda".

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

Immagina di avere un nuovo sistema che controlla ogni ID doc e query_esatta, e poi calcola la probabilità di clic per ogni documento e ogni query. Scoprirai che il suo comportamento è quasi identico a quello del tuo sistema attuale in affiancati e test A/B, quindi, data la sua semplicità, lanciala. Tuttavia, noti che non vengono mostrate nuove app. Perché? Beh, dato che mostra un documento solo in base alla sua cronologia con quella query, per sapere che un nuovo documento deve essere mostrato.

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

Disallineamento tra addestramento e distribuzione

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

  • Discrepanza tra il modo in cui gestisci i dati nelle pipeline di addestramento e gestione.
  • 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 in Google attraverso un disallineamento della pubblicazione che influisce negativamente sulle prestazioni. La soluzione migliore è monitorarlo esplicitamente in modo che le modifiche al sistema e ai dati non creino disallineamenti inosservato.

Regola 29: il modo migliore per assicurarsi di eseguire l'addestramento in modo simile al servizio è salvare l'insieme di caratteristiche utilizzate al momento della pubblicazione e poi indirizzare queste caratteristiche a un log per utilizzarle durante l'addestramento.

Anche se non è possibile farlo per ogni esempio, usa solo una piccola parte, come di verificare la coerenza tra pubblicazione e addestramento (vedi Regola n. 37). Team che hanno attivato questa azione le misurazioni di Google a volte sono rimasti sorpresi dai risultati. Home page di YouTube è passata alle funzionalità di logging al momento della gestione con una qualità significativa miglioramenti e una riduzione della complessità del codice e molti team stanno passando la loro infrastruttura.

Regola 30: dati campionati ponderati in base all'importanza, non ignorarli arbitrariamente.

Quando i dati sono troppi, c'è la tentazione di prendere i file 1-12 e ignora i file 13-99. Si tratta di un errore. Anche se i dati che erano non può essere mai mostrata all'utente, la ponderazione dell'importanza è la migliore e riposare. Per ponderazione di importanza si intende campionare l'esempio X con una probabilità del 30%, quindi assegnargli 10/3. Con della ponderazione dell'importanza, tutte le proprietà di calibrazione discusse in Regola n. 14 rimangono in attesa.

Regola 31: tieni presente che se unisci i dati da 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à di questi documenti (come di commenti o clic). Tra il tempo di addestramento e quello di distribuzione, le caratteristiche la tabella potrebbe essere modificata. La previsione del modello per lo stesso documento e poi differiscono tra addestramento e pubblicazione. Il modo più semplice per evitare questo tipo del problema è la registrazione delle caratteristiche al momento della pubblicazione (vedi Regola 32 . Se la tabella è cambiare solo lentamente, puoi anche creare uno snapshot della tabella ogni ora o ogni giorno abbastanza vicini. Tieni presente che il problema non è ancora stato risolto completamente problema.

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

L'elaborazione in modalità batch è diversa dall'elaborazione online. Nell'elaborazione online, devi gestire ogni richiesta man mano che arriva (ad esempio, devi eseguire una ricerca per ogni query), mentre nell'elaborazione batch puoi combinare le attività (ad es. un join). Al momento della pubblicazione, esegui l'elaborazione online, mentre è un'attività di elaborazione batch. Ci sono, però, alcuni aspetti per riutilizzare il codice. Ad esempio, puoi creare un oggetto specifiche del tuo sistema, dove il risultato di query o join può essere memorizzati in modo leggibile e gli errori possono essere testati facilmente. Poi, una volta raccolte tutte le informazioni, durante il servizio o l'addestramento, eseguire un metodo comune per creare un collegamento tra l'oggetto leggibile da una persona specifiche per il tuo sistema e a qualsiasi formato sia il sistema di machine learning si aspetta. In questo modo si elimina la fonte di disallineamenti tra addestramento e distribuzione. Come come corollario, cerca di non usare due linguaggi di programmazione diversi tra una formazione e l'altra e pubblicazione. Questa decisione ti renderà quasi impossibile le API nel tuo codice.

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

In generale, misurare le prestazioni di un modello sui dati raccolti dopo i dati su cui hai addestrato il modello, poiché riflette meglio ciò che farà il tuo sistema e produzione. Se produci un modello basato sui dati fino al 5 gennaio, il modello sui dati a partire dal 6 gennaio. Ci aspettiamo che il rendimento non sarà altrettanto buono con i nuovi dati, ma non dovrebbe essere radicalmente peggiore. Dal momento che potrebbero verificarsi effetti giornalieri, potresti non prevedere il clic medio tasso di conversione o tasso di conversione, ma l'area sotto la curva, che rappresenta la probabilità di attribuire all'esempio positivo un punteggio superiore a quello negativo dovrebbe essere ragionevolmente simile.

Regola 34: nella classificazione binaria per l'applicazione di filtri (ad esempio il rilevamento di spam o la determinazione di email interessanti), fai piccoli sacrifici a breve termine in termini di prestazioni per ottenere dati estremamente puliti.

In un'attività di filtro, gli esempi contrassegnati come negativi non vengono mostrati a per l'utente. Supponi di avere un filtro che blocca il 75% degli esempi negativi durante la pubblicazione. Potresti avere la tentazione di ricavare altri dati di addestramento di istanze VM mostrate agli utenti. Ad esempio, se un utente contrassegna un'email come spam che il filtro lascia passare, potresti trarre insegnamenti da questo.

Tuttavia, questo approccio introduce dei bias di campionamento. Puoi raccogliere dati più puliti Durante la pubblicazione, invece, etichetti l'1% di tutto il traffico come "messi da parte" e invii tutti ha offerto esempi all'utente. Ora il filtro blocca almeno il 74% esempi negativi. Questi esempi esclusi possono diventare i tuoi dati di addestramento.

Tieni presente che se il filtro blocca il 95% degli esempi negativi o più, dell'IA diventa meno attuabile. In ogni caso, se vuoi misurare la pubblicazione delle prestazioni, è possibile ottenere un campione ancora più piccolo (ad esempio, 0,1% o 0,001%). Dieci mille esempi sono sufficienti per stimare il rendimento con precisione.

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

Quando cambi l'algoritmo di ranking in modo abbastanza radicale da far sì che risultati diversi appaiono, hai modificato i dati a cui l'algoritmo in futuro. Vedrai questo tipo di disallineamento e dovresti progettare il tuo modello precedente. Esistono diversi approcci. Questi approcci sono tutti i modi per favorire i dati che il modello ha già visto.

  1. Hanno una maggiore regolarizzazione delle caratteristiche che coprono più query rispetto a le caratteristiche che sono attive per una sola query. In questo modo, il modello favorirà specifiche per una o più query rispetto a caratteristiche che generalizza a tutte le query. Questo approccio consente di evitare derivanti dalla fuga di informazioni da query irrilevanti. Tieni presente che si trova all'opposto consigli più convenzionali di una maggiore regolarizzazione delle colonne delle caratteristiche con più valori univoci.
  2. Consenti solo alle caratteristiche di avere ponderazioni positive. Pertanto, qualsiasi caratteristica valida verrà meglio di una caratteristica "sconosciuta".
  3. Non hanno funzionalità solo per i documenti. Questa è una versione estrema del n. 1. Per esempio, anche se una determinata app è un download di successo indipendentemente dal una query, non è consigliabile mostrarla ovunque. Non dispone di funzionalità Solo documento semplifica tutto. Il motivo per cui non vuoi mostrare uno specifico un'app famosa in tutto il mondo ha a che fare con l'importanza rendendo raggiungibili tutte le app desiderate. Ad esempio, se qualcuno cerca "app per il birdwatching", potrebbero scaricare "uccelli arrabbiati", ma sicuramente non era il loro intento. Mostrare un'app di questo tipo potrebbe migliorare la percentuale di download, ma non soddisfano le sue esigenze.

Regola 36: evita i cicli di feedback con le caratteristiche posizionali.

La posizione dei contenuti influisce notevolmente sulla probabilità che l'utente interagisca con essa. Se posizioni un'app nella prima posizione, riceverà più spesso clic su di essa, e avrai la convinzione che ha maggiori probabilità di ricevere clic. Un modo per affrontare questo serve per aggiungere caratteristiche posizionali, cioè caratteristiche relative alla posizione contenuti della pagina. Il modello viene addestrato con le caratteristiche posizionali Impara a ponderare, ad esempio, la caratteristica "1stposition" molto. Il tuo modello pertanto dà meno peso ad altri fattori per gli esempi con "1stposition=true". Quindi, al momento della pubblicazione non fornisci a nessuna istanza la caratteristica posizionale, oppure assegni tutte le stesse funzionalità predefinite, perché il punteggio dei candidati è precedente hanno deciso l'ordine in cui mostrarli.

Tieni presente che è importante mantenere le caratteristiche posizionali in qualche modo separate il resto del modello a causa di questa asimmetria tra addestramento e test. Il modello è la somma di una funzione delle caratteristiche posizionali delle altre caratteristiche è ideale. Ad esempio, non attraversare caratteristiche posizionali con qualsiasi caratteristica del documento.

Regola 37: Misurare il disallineamento tra addestramento e servizio.

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

  • La differenza tra le prestazioni sui dati di addestramento e l'isolamento e i dati di Google Cloud. In generale, esiste sempre e non è sempre un male.
  • Differenza tra il rendimento dei dati di holdout e del "giorno successivo" e i dati di Google Cloud. Anche in questo caso, esiste sempre. Dovresti ottimizzare la regolarizzazione per massimizzare il rendimento il giorno successivo. Tuttavia, i notevoli cali del rendimento tra l'isolamento e i dati del giorno successivo possono indicare che alcune caratteristiche sono e le prestazioni del modello potrebbero peggiorare.
  • Differenza tra il rendimento del "giorno successivo" e i carichi di lavoro e i dati di Google Cloud. Se applichi un modello a un esempio nei dati di addestramento e esempio alla pubblicazione, dovrebbe restituire esattamente lo stesso risultato (vedi Regola n. 5 . Pertanto, una discrepanza in questo caso indica probabilmente un errore ingegneristico.

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

Ci saranno alcuni segnali che indicano che la seconda fase sta per finire. Prima di tutto, i guadagni mensili inizieranno a diminuire. Inizierai ad avere dei compromessi tra le metriche: alcune aumenteranno, mentre altre caleranno in qualche modo. esperimenti. Ed è qui che diventa interessante. Poiché è più difficile ottenere guadagni ottenere, il machine learning deve diventare più sofisticato. Attenzione: questo ha più regole per il cielo blu rispetto alle sezioni precedenti. Abbiamo visto molte squadre ripercorriamo i momenti felici della Fase I e della Fase II del machine learning. Una volta fase III, i team devono trovare la propria strada.

Regola 38: non sprecare tempo su nuove caratteristiche se il problema è diventato un obiettivo incongruente.

Man mano che le misurazioni si fermano, il team inizierà a esaminare i problemi al di fuori dell'ambito degli obiettivi del tuo attuale sistema di machine learning. Come dichiarati in precedenza, se gli obiettivi del prodotto non sono coperti dalla configurazione algoritmica esistente devi modificare lo scopo o gli obiettivi del prodotto. Per Ad esempio, puoi ottimizzare clic, +1 o download, ma lanciare decisioni basate in parte su revisori umani.

Regola 39: le decisioni di lancio sono un proxy per obiettivi di prodotto a lungo termine.

Alice ha un'idea su come ridurre la perdita logistica derivante dalla previsione delle installazioni. Lei aggiunge una caratteristica. La perdita logistica cala. Quando fa un esperimento dal vivo, aumenta il tasso di installazione. Tuttavia, quando accede a una revisione del lancio, durante una riunione, qualcuno sottolinea 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 ottimizzate direttamente con il machine learning.

La verità è che il mondo reale non sono sotterranei e draghi: non esistono "colpi punti" identificare lo stato di salute del tuo prodotto. Il team deve utilizzare dati che raccoglie per cercare di prevedere in modo efficace la qualità del sistema in futuro. Occorre preoccuparsi del coinvolgimento, 1 giorno di utenti attivi (DAU), 30 DAU, entrate e ritorno sull'investimento dell'inserzionista. Queste metriche misurabili nei test A/B di per sé sono solo un sostituto per più a lungo termine obiettivi: soddisfare gli utenti, aumentare gli utenti, soddisfare i partner e profitto, anche in questo caso si potrebbero prendere in considerazione dei proxy per avere un'alta qualità prodotto e un'azienda di successo tra cinque anni.

Le uniche decisioni di lancio facili sono quando tutte le metriche migliorano (o almeno lo fanno non peggiori). Se il team può scegliere tra una macchina sofisticata di machine learning, e una semplice euristica, se la semplice euristica un lavoro migliore in tutte queste metriche, dovrebbe scegliere l'euristica. Inoltre, non rappresenta un ranking esplicito di tutti i possibili valori delle metriche. In particolare, considera due scenari possibili:

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 al sistema B. Se se il sistema attuale è B, è improbabile che il team passi ad A. Questo sembrano in conflitto con un comportamento razionale; tuttavia, le previsioni di cambiamenti le metriche possono o meno avere successo. Di conseguenza, il rischio entrambe le modifiche. Ogni metrica copre alcuni rischi che interessano il team.

Inoltre, nessuna metrica copre la preoccupazione principale del team, ovvero "dove si trova il mio prodotto tra cinque anni"?

I singoli, invece, tendono a preferire un obiettivo che possono ottimizzare direttamente. La maggior parte degli strumenti di machine learning favorisce questo ambiente. Un che lancia nuove funzionalità può ottenere un flusso costante di lanci in completamente gestito di Google Cloud. C'è un tipo di machine learning, apprendimento multi-obiettivo, che inizia a risolvere il problema. Ad esempio, si può formulare un problema di soddisfazione relativo a un vincolo di soddisfazione con limiti inferiori su ogni metrica ottimizza alcune combinazioni lineari di metriche. Tuttavia, anche in questo caso, non tutte le metriche possono essere facilmente inquadrate come obiettivi di machine learning: se un documento viene o se un'app è installata, è perché i contenuti sono stati mostrati. Ma è molto più difficile capire perché un utente visita il tuo sito. Come prevedere il valore il successo futuro di un sito nel suo complesso è Completo con IA: difficile come il computer visione artificiale o elaborazione del linguaggio naturale.

Regola 40: scegli un outfit semplice.

I modelli unificati che prendono le caratteristiche non elaborate e classificano direttamente i contenuti sono modelli più semplici da sottoporre a debug e comprendere. Tuttavia, un insieme di modelli (una "modello" che combina i punteggi di altri modelli) può funzionare meglio. Per mantenere per semplicità, ogni modello dovrebbe essere un insieme che utilizza solo l'input altri modelli o un modello di base con molte caratteristiche, ma non entrambe. Se disponi modelli addestrati separatamente, oltre a quelli addestrati separatamente, per poi combinarli può causare comportamenti dannosi.

Usa un modello semplice per l'assemblaggio che prende solo l'output della "base" come input. Vuoi anche applicare le proprietà su questi modelli di insieme. Ad esempio, un aumento del punteggio prodotto da un modello di base non dovrebbe diminuisci il punteggio dell'ensemble. Inoltre, è meglio se i modelli in arrivo interpretabile semanticamente (ad esempio, calibrato) in modo che le modifiche del i modelli sottostanti non confondono il modello ensemble. Inoltre, imponi che dell'aumento della probabilità prevista di un classificatore sottostante non diminuire la probabilità prevista dell'insieme.

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

Hai aggiunto alcuni dati demografici sull'utente. Hai aggiunto alcuni informazioni sulle parole contenute nel documento. Hai esaminato il modello dell'esplorazione e ottimizzato la regolarizzazione. Non hai visto un lancio con altri di un miglioramento dell'1% nelle metriche chiave in pochi trimestri. Ti chiedi cosa fare adesso?

È ora di iniziare a costruire l'infrastruttura per modelli radicalmente diversi quali la cronologia dei documenti a cui l'utente ha eseguito l'accesso nella l'ultimo giorno, l'ultima settimana o l'anno precedente o i dati di un'altra proprietà. Utilizza le funzionalità di wikidata persone giuridiche o qualcosa di interno all'azienda (come il Knowledge Graph). Usa deep machine learning. Inizia ad adeguare le tue aspettative relative al ritorno prevedi un investimento ed espandi i tuoi sforzi di conseguenza. Come in qualsiasi di progettazione, devi valutare il vantaggio di aggiungere nuove caratteristiche a fronte del costo di una maggiore complessità.

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

La diversità in un insieme di contenuti può avere molti significati, con la diversità del l'origine dei contenuti è una delle più comuni. La personalizzazione implica all'utente ricevono i propri risultati. La pertinenza implica che i risultati per una sono più appropriate per quella query rispetto a qualsiasi altra. Quindi tutti e tre queste proprietà sono definite diverse dall'ordinaria.

Il problema è che le cose ordinarie sono difficili da battere.

Tieni presente che se il tuo sistema misura clic, tempo trascorso, visualizzazioni, +1, ricondivisioni e così via, misuri la popolarità dei contenuti. Team a volte provano a imparare un modello personale basato sulla diversità. Per personalizzare, aggiungono funzionalità che consentirebbero al sistema di personalizzare (alcune caratteristiche rappresentano interesse dell'utente) o diversificare (funzionalità che indicano se il documento presenta caratteristiche in comune con altri documenti restituiti, come autore o contenuti), e scoprire che tali caratteristiche hanno un peso minore (o a volte un segno diverso). del previsto.

Ciò non significa che la diversità, la personalizzazione o la pertinenza non siano preziose. Come evidenziato nella regola precedente, è possibile eseguire la post-elaborazione per diversità o pertinenza. Se noti un aumento degli obiettivi a lungo termine, puoi dichiarano che la diversità/pertinenza è preziosa, al di là della popolarità. Puoi quindi continuare a utilizzare la post-elaborazione o modificare direttamente scopo basato sulla diversità o sulla pertinenza.

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

I team di Google hanno ottenuto molta spinta dall'adozione di un modello che prevede vicinanza di una connessione in un prodotto e farla funzionare bene in un altro. I tuoi amici sono chi sono. D'altra parte, ho guardato diverse squadre hanno difficoltà a gestire le funzionalità di personalizzazione nei diversi prodotti. Sì, sembra dovrebbe funzionare. Per ora, non sembra che sia così. Ciò che a volte è ha funzionato nell'utilizzare i dati non elaborati di una proprietà per prevedere il comportamento su un'altra. Inoltre, ricorda che anche sapere che un utente ha una cronologia su un'altra proprietà può guida. Ad esempio, la presenza di attività utente su due prodotti potrebbe essere indicativo di per sé.

Esistono molti documenti sul machine learning in Google e 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, Konstantinos Katsiapis, Glen Anderson, Dan Duckworth, Shishir Birmiwal, Gal Elidan, Su Lin Wu, Jaihui Liu, Fernando Pereira e Hrishikesh Aradhye per molte correzioni. suggerimenti ed esempi utili per questo documento. Inoltre, grazie a Kristen Lefevre, Suddha Basu e Chris Berg che hanno dato il loro contributo per una versione precedente. Qualsiasi errori, omissioni o opinioni impopolari sono le mie.

Appendice

Il documento contiene una serie di riferimenti ai prodotti Google. A fornire maggiore contesto; fornirò una breve descrizione degli esempi più comuni di seguito.

Panoramica su YouTube

YouTube è un servizio di video in streaming. Sia la sezione Che cosa guardare dopo di YouTube sia la home page di YouTube I team addetti alle pagine usano modelli di ML per classificare i suggerimenti video. Cosa guardare in seguito video da guardare dopo quello attualmente in riproduzione, mentre la home page consiglia video agli utenti che visitano la home page.

Panoramica di Google Play

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

Panoramica di Google Plus

Google Plus ha utilizzato il machine learning in diverse situazioni: classificare i post in lo "stream" di post visti dall'utente, classificati come "Temi caldi" post (post molto popolari adesso), classifica 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.