Sfide tra industria e Kaggle. Raccogliere più osservazioni e avere accesso a più variabili è più importante della modellazione fantasia?

Spero che il titolo sia autoesplicativo. In Kaggle, la maggior parte dei vincitori usa lo stacking con a volte centinaia di modelli base, per spremere un po 'di% in più di MSE, precisione ... In generale, nella tua esperienza, quanto è importante la modellazione fantasia come lo stacking rispetto alla semplice raccolta di più dati e più funzionalità per i dati?

A titolo di background, da 12 anni eseguo previsioni negozio serie temporali SKU per vendite al dettaglio. Decine di migliaia di serie storiche in centinaia o migliaia di negozi. Mi piace dire che abbiamo fatto Big Data da prima che il termine diventasse popolare.$\times$

Ho costantemente scoperto che la cosa più importante è capire i tuoi dati . Se non capisci i principali piloti come la Pasqua o le promozioni, sei condannato. Abbastanza spesso, questo si riduce a comprendere il business specifico abbastanza bene da porre le domande corrette e dire sconosciuti noti da sconosciuti sconosciuti .

Una volta compresi i dati, è necessario lavorare per ottenere dati puliti . Ho supervisionato un certo numero di junior e stagisti, e l'unica cosa che non avevano mai sperimentato in tutte le loro lezioni di statistica e di data science era quanta merda ci può essere nei dati che hai. Quindi è necessario tornare alla fonte e provare a ottenerlo per produrre dati validi, oppure provare a ripulirlo, o anche semplicemente buttare via alcune cose. La modifica di un sistema in esecuzione per produrre dati migliori può essere sorprendentemente difficile.

Dopo aver compreso i dati e in realtà i dati in qualche modo puliti, puoi iniziare a giocherellare con essi. Sfortunatamente, a questo punto, mi sono trovato spesso a corto di tempo e risorse.

Personalmente sono un grande fan della combinazione di modelli ("accatastamento"), almeno in un senso astratto , meno di una ingegnosa caratteristica ingegneristica, che spesso attraversa la linea in un territorio in eccesso - e anche se il tuo modello più elaborato funziona leggermente meglio in media, spesso si scopre che le previsioni davvero pessime peggiorano con un modello più complesso. Questo è un rompicapo nel mio settore di attività. Una singola previsione davvero negativa può distruggere completamente completamente la fiducia nell'intero sistema, quindi la solidità è estremamente alta nella mia lista di priorità. Il tuo chilometraggio può variare.

Nella mia esperienza, sì, la combinazione di modelli può migliorare la precisione. Tuttavia, i primi due passi si ottengono davvero grandi vantaggi: comprendere i dati e pulirli (o ottenere dati puliti in primo luogo).

Non posso parlare per l'intero settore, ovviamente, ma lavoro nel settore e ho gareggiato su Kaggle, quindi condividerò il mio POV.

Innanzitutto, hai ragione a sospettare che Kaggle non corrisponda esattamente a ciò che la gente sta facendo nel settore. È un gioco, soggetto a giocabilità, con molte restrizioni folli. Ad esempio, nel concorso Santander attualmente in corso :

1. I nomi delle caratteristiche sono stati sottoposti a hashing artificiale per nascondere il loro significato
2. Il set "training" era artificialmente limitato per contenere meno righe delle colonne in modo specifico, in modo che la selezione delle caratteristiche, la robustezza e la tecnica di regolarizzazione sarebbero indispensabili per il successo.
3. Il cosiddetto set di "test" ha una diversa distribuzione marcatamente rispetto al training set e le due sono chiaramente non campioni casuali della stessa popolazione.

Se qualcuno mi fornisse un set di dati come questo al lavoro, mi offrirei immediatamente di lavorare con loro sull'ingegnerizzazione delle funzionalità in modo da poter ottenere funzionalità più utili. Suggerirei di usare la conoscenza del dominio per decidere su probabili termini di interazione, soglie, strategie di codifica delle variabili categoriche, ecc. Affrontare il problema in questo modo sarebbe chiaramente più produttivo del tentativo di estrarre significato da un file di scarico prodotto da un ingegnere di database senza formazione in ML.

Inoltre, se impari, diciamo, che una particolare colonna numerica non è affatto numerica ma piuttosto un codice postale, beh, puoi andare e ottenere dati da fonti di dati di terze parti come il censimento degli Stati Uniti per aumentare i tuoi dati. O se hai una data, forse includerai il prezzo di chiusura di S&P 500 per quel giorno. Tali strategie di aumento esterno richiedono una conoscenza dettagliata del set di dati specifico e una conoscenza di dominio significativa, ma di solito hanno i profitti molto più ampi rispetto ai puri miglioramenti algoritmici.

Quindi, la prima grande differenza tra l'industria e Kaggle è che nell'industria, le caratteristiche (nel senso dei dati di input) sono negoziabili.

Una seconda classe di differenze è la prestazione. Spesso i modelli verranno distribuiti alla produzione in due modi: 1) le previsioni del modello verranno pre-calcolate per ogni riga in una tabella di database molto grande, oppure 2) un'applicazione o un sito Web passerà al modello una singola riga di dati e è necessaria una previsione restituita in tempo reale. Entrambi i casi d'uso richiedono buone prestazioni. Per questi motivi, spesso non vedi modelli che possono essere lenti a prevedere o utilizzare un'enorme quantità di memoria come K-Clos-Neighbours o Extra Random Forests. Una regressione logistica o una rete neurale, al contrario, può segnare un lotto di record con alcune moltiplicazioni di matrice e la moltiplicazione di matrice può essere altamente ottimizzata con le librerie giuste.Anche se potrei ottenere +0.001 AUC forse se impilassi su un altro modello non parametrico, non lo farei perché il rendimento della previsione e la latenza calerebbero troppo.

C'è anche una dimensione di affidabilità in questo - impilare quattro diverse librerie di terze parti all'avanguardia, ad esempio LightGBM , xgboost , catboost e Tensorflow (su GPU , ovviamente) potrebbe darti quella riduzione .01 di MSE che vince le competizioni di Kaggle, ma sono quattro diverse librerie da installare, distribuire e eseguire il debug se qualcosa va storto. È fantastico se riesci a far funzionare tutte quelle cose sul tuo laptop, ma farlo funzionare all'interno di un contenitore Docker in esecuzione su AWS è una storia completamente diversa. La maggior parte delle aziende non vuole far fronte a un piccolo team di sviluppatori solo per affrontare questo tipo di problemi di implementazione.

Detto questo, impilare in sé non è necessariamente un grosso problema. In effetti, impilare un paio di modelli diversi che si comportano tutti ugualmente bene ma che hanno limiti di decisione molto diversi è un ottimo modo per ottenere un piccolo aumento nell'AUC e un grande aumento nella robustezza. Basta non buttare così tanti lavelli da cucina nel tuo insieme eterogeneo che inizi ad avere problemi di distribuzione.

Dalla mia esperienza, più dati e più funzionalità sono più importanti del modello più elegante, accatastato, ottimizzato, che si possa trovare.

Guarda le competizioni pubblicitarie online che si sono svolte. I modelli vincenti sono stati così complessi che alla fine hanno impiegato un'intera settimana per allenarsi (su un set di dati molto piccolo, rispetto allo standard del settore). Inoltre, la previsione in un modello sovrapposto è più lunga rispetto a un modello lineare semplice. Sullo stesso argomento, ricorda che Netflix non ha mai usato il suo algoritmo 1M $ a causa dei costi di ingegneria .

Direi che le competizioni online di scienza dei dati sono un buon modo per un'azienda di sapere "qual è la massima precisione (o qualsiasi metrica delle prestazioni) che può essere raggiunta" usando i dati che raccolgono (ad un certo punto nel tempo). Si noti che questo in realtà è un problema difficile che viene risolto! Ma, nel settore, le conoscenze sul campo, i vincoli hardware e di business di solito scoraggiano l'uso della "modellazione di fantasia".

Lo stacking aumenta significativamente la complessità e riduce l'interpretazione. I guadagni sono generalmente relativamente piccoli per giustificarlo. Quindi, sebbene l'insemblaggio sia probabilmente ampiamente utilizzato (ad es. XGBoost), penso che lo stacking sia relativamente raro nell'industria.

Nella mia esperienza, la raccolta di dati e funzionalità utili è molto più importante.

I clienti con cui abbiamo lavorato di solito hanno molti dati, e non tutti in formato che può essere facilmente esportato o con cui lavorare facilmente. Il primo lotto di dati non è generalmente molto utile; è nostro compito collaborare con il cliente per capire quali dati avremmo bisogno per rendere il modello più utile. Questo è un processo molto iterativo.

C'è molta sperimentazione in corso e abbiamo bisogno di modelli che siano:

1. Veloce da allenare
2. Veloce da prevedere (spesso è anche un requisito aziendale)
3. Facile da interpretare

Il punto 3) è particolarmente importante, perché i modelli facili da interpretare sono più facili da comunicare al cliente ed è più facile da rilevare se abbiamo fatto qualcosa di sbagliato.

Ecco qualcosa che non emerge molto su Kaggle: il

• più variabili che hai nel tuo modello e
• più complessa è la relazione tra tali variabili e l'output,

il rischio maggiore che si troveranno ad affrontare nel corso della vita di quel modello. Il tempo è in genere congelato nelle competizioni Kaggle, oppure c'è una breve finestra futura in cui entrano in gioco i valori dei set di test. Nell'industria, quel modello potrebbe funzionare per anni. E tutto ciò che potrebbe essere è che una variabile vada in tilt affinché l'intero modello vada all'inferno, anche se è stato costruito in modo impeccabile. Capisco, nessuno vuole assistere a un concorso in cui i concorrenti bilanciano attentamente la complessità del modello con il rischio, ma là fuori in un lavoro, la tua attività e la qualità della vita ne risentiranno se qualcosa va storto con un modello di cui sei responsabile. Anche le persone estremamente intelligenti non sono immuni. Prendi, ad esempio, l' errore di previsione di Google Trend influenzali . Il mondo è cambiato e non l'hanno visto arrivare.

Alla domanda di OP, " In generale, nella tua esperienza, quanto è importante la modellazione di fantasia come lo stacking vs semplicemente la raccolta di più dati e più funzionalità per i dati? " Beh, sono ufficialmente vecchio, ma la mia risposta è che a meno che tu non abbia un infrastruttura di modellazione davvero solida, è meglio avere modelli semplici, con un insieme minimo di variabili, in cui la relazione input-to-output è relativamente semplice. Se una variabile migliora a malapena la metrica di perdita, lasciala fuori. Ricorda che è un lavoro. Porta i tuoi calci fuori dal lavoro nei concorsi di Kaggle dove c'è l'incentivo "vai alla grande o vai a casa".

Un'eccezione sarebbe se la situazione aziendale richiedesse un certo livello di prestazioni del modello, ad esempio se la tua azienda avesse bisogno di eguagliare o battere le prestazioni di un concorrente per ottenere qualche vantaggio (probabilmente nel marketing). Ma quando esiste una relazione lineare tra prestazioni del modello e guadagno aziendale, gli aumenti della complessità non giustificano in genere il guadagno finanziario (vedere " Netflix non ha mai usato il suo algoritmo da $ 1 milione a causa dei costi di ingegneria " - si scusa con @ RUser4512 per aver citato lo stesso articolo). In una competizione Kaggle, tuttavia, quel guadagno aggiuntivo può farti spostare centinaia di gradi mentre passi soluzioni vicine.

Una breve risposta che è una citazione che mi piace dal libro Deep Thinking di Gary Kasparov

Un processo intelligente batte una conoscenza superiore e una tecnologia superiore

Lavoro principalmente con i dati finanziari delle serie temporali e il processo dalla raccolta dei dati, alla loro pulizia, elaborazione, e quindi lavorando con i proprietari dei problemi per capire cosa vogliono veramente fare, per poi costruire funzionalità e modelli per cercare di affrontare il problema e infine esaminare retrospettivamente il processo per migliorare per la prossima volta.

L'intero processo è maggiore della somma delle sue parti. Tendo a ottenere prestazioni di accettazione "accettabili" con una regressione lineare / logistica e parlando con esperti di dominio per generare funzionalità, molto meglio il tempo speso che passare troppo tempo ad adattare il mio modello ai dati che ho.