Semplificazione dello sviluppo di Machine Learning con un Feature Store
Di Giovanni Tommaso
In UFC , i combattenti si preparano per il loro tempo nell'Ottagono con intensi regimi di allenamento. I combattenti e le loro squadre trascorreranno mesi analizzando lo stile del loro avversario per eventuali punti deboli sfruttabili, perfezionando il loro corpo e la loro tecnica per offrire la migliore partita possibile.
I data scientist dell'organizzazione madre di UFC, Endeavor , affrontano le previsioni di apprendimento automatico con non meno determinazione. Mentre i combattenti si lanciano davanti alla telecamera, anche i dati relativi ai fan che guardano il combattimento vengono analizzati in modo critico: la competizione per attirare e trattenere gli spettatori è feroce. I clienti hanno bisogno di un'esperienza coinvolgente che li mantenga agganciati e Endeavor è diventato un leader in ascesa nello sfruttare l'apprendimento automatico e le competenze digitali per affrontare la sfida. Di seguito approfondiamo il lavoro di Endeavor nel massimizzare le informazioni sugli spettatori con la loro implementazione di un negozio di funzionalità per semplificare lo sviluppo del machine learning in UFC.
Molti data scientist che leggono questo articolo sanno che la maggior parte del lavoro svolto nella creazione di modelli di machine learning deriva dalla creazione di funzionalità. Caratteristiche (ad esempio, predittori o attributi) come caratteristiche aggregate (ad esempio, giorni dall'ultimo acquisto o paese di residenza del cliente) sono una parte necessaria dei modelli predittivi di machine learning. Affinché un modello esegua previsioni accurate, ha bisogno di caratteristiche di alta qualità che possano spiegare una variazione sufficiente nell'output (in altre parole, determinare a quale categoria appartiene la tua previsione). Tuttavia, con il ridimensionamento delle operazioni di machine learning, potrebbe essere difficile o ripetitivo mantenere un ecosistema ML. Inoltre, il tuo team può rischiare l'incoerenza della definizione nella tua base di codice ripetendo gli stessi sforzi più e più volte. Endeavor ha risolto questo problema attraverso un Feature Storeche standardizza e centralizza le funzionalità per garantire coerenza, rilevabilità e riusabilità.
Lo sviluppo delle funzionalità può richiedere molto tempo, a seconda della complessità dei calcoli. Puoi passare settimane ad aggregare i dati grezzi disponibili in un formato digeribile che abbia senso per il tuo modello. Alcune funzionalità possono essere comuni a diversi casi d'uso, ad esempio la vendita di biglietti a vita o i dispositivi di streaming più utilizzati, che possono essere predittive sia per i modelli di comportamento transazionale che per quelli di navigazione. Se più data scientist lavorano su modelli che utilizzano la stessa fonte, possono emergere problemi come l'incoerenza della definizione quando le stesse funzionalità vengono create più volte per diverse funzioni obiettivo (ad esempio, la domanda predittiva a cui si desidera rispondere). Gli sforzi di ingegneria dei dati possono essere semplificati, utilizzando un hub comune di funzionalità che possono essere utilizzate su più client e più modelli.
Entra nel negozio di funzionalità.
Un archivio di funzionalità è un repository di codice comune in cui più contributori possono definire le funzionalità per lo sviluppo del modello.
In un feature store, puoi avere uno schema composto da diverse tabelle di funzionalità, ognuna delle quali fornisce uno sguardo all'identificatore comune su cui stai tentando di prevedere. Possiamo esaminare un esempio utilizzando il lavoro svolto con Endeavour Streaming.Endeavor Streaming porta tecnologie all'avanguardia e competenze sui media digitali nel mondo dello streaming e offre una serie di capacità analitiche per i giganti dello streaming sportivo. Con ogni cliente (definito come l'azienda con cui Endeavor collabora per lo streaming dei propri contenuti), Endeavor Streaming raccoglie in modo efficace i dati sul loro comportamento di streaming e transazionale, che possono quindi migliorare l'esperienza del cliente. I data scientist del nostro team utilizzano quindi questi flussi di dati grezzi per fornire previsioni di machine learning per i clienti. Se stavi eseguendo il machine learning per un'origine dati sui dati di streaming video, potresti avere la seguente ripartizione, ad esempio:
Potenziali funzioni obiettivo:
- Churn : qual è la probabilità che un cliente annulli l'abbonamento?
- Riacquisto Pay-Per-View -Quali sono le possibilità che un cliente che ha acquistato una licenza Pay-Per-View ne acquisti di nuovo una?
- Re-coinvolgimento del cliente: qual è la probabilità che un cliente possa trasmettere in streaming un contenuto specifico?
Tabella 1: Esempio di flusso di dati grezzi di spettatori per UFC
Endeavor sfrutta i database Snowflake per archiviare i nostri dati e massimizziamo l'efficienza utilizzando i modelli DBT per archiviare query di aggregazioni di dati pertinenti. Utilizzando DBT, potremmo creare set di dati di test e inferenza a livello di cliente (identificati da customer_EXID per rispondere alle funzioni obiettivo disponibili.
Alcune caratteristiche che potrebbero essere derivate da questi set di dati:
- Dispositivi utilizzati dal cliente
- Minuti guardati dal cliente
- Paese di visualizzazione per cliente
- Contenuto visualizzato dal cliente
- Primo contenuto della scheda principale visualizzato
Questo "funziona". La fase di manipolazione dei dati dei dati di visualizzazione per due client può produrre due frame di dati (test e inferenza) per ciascuna funzione obiettivo (3). Questo ci porta a dodici modelli distinti, tutti attingendo da fonti simili e producendo risultati simili. Si noti che non tutte le funzionalità vengono utilizzate in ogni modello, quindi questo è specificamente considerato nella creazione di ogni singolo modello tramite DBT. Questo, tuttavia, è inefficiente per alcuni motivi:
- Drift della definizione delle funzionalità: poiché le stesse funzionalità vengono ricreate per ciascuno di questi modelli, non esistono meccanismi in atto affinché la definizione di tale funzionalità rimanga coerente tra i modelli
- Ripetizione: man mano che vengono introdotti nuovi clienti, il processo di ricreazione di questi modelli esatti per quei clienti deve essere ripetuto.
- Mantenimento del modello: man mano che i dati cambiano o la nuova profondità sulla variabile target viene esposta nel tempo, la modifica più piccola deve essere implementata manualmente in tutti i modelli uno per uno.
Ora siamo in grado di mediare le preoccupazioni di cui sopra centralizzando lo sviluppo delle funzionalità in un'unica posizione. Tutte le funzionalità, indipendentemente dal caso d'uso, risiedono nel feature store. Un modello può semplicemente "controllare" qualsiasi funzionalità che gli piace dal negozio, semplicemente unendosi all'identificatore a livello di riga (cliente). La bellezza di questo design non si ferma qui; qualsiasi client aggiunto d'ora in poi seguirà semplicemente la logica dei suoi predecessori utilizzati per creare le funzionalità. Poiché la struttura dei dati di visualizzazione non elaborati che entrano nel database è identica, se abbiamo un nuovo "Cliente 3" a bordo, possiamo semplicemente applicare la stessa logica dei clienti esistenti e generare queste stesse funzionalità per il Cliente 3 con uno sforzo relativamente basso. Questo ci consente anche di creare rapidamente modelli (test e inferenza) per questi nuovi clienti.
Questo è utile per una serie di motivi:
- Il lavoro di sviluppo delle funzionalità è facilmente accessibile ad altri data scientist
- Il calcolo delle funzionalità è ora automatizzato per tutti i casi d'uso
- I set di dati di addestramento e inferenza sono coerenti nelle funzionalità
- La replica dei modelli in diversi casi d'uso è rapidamente scalabile
Mentre i dati elaborati dai client univoci serviti da Endeavor Streaming esistono nello stesso archivio di funzionalità, i dati vengono federati nello sviluppo del modello semplicemente filtrando l'archivio di funzionalità in base al client. Nell'esempio UFC, i modelli di machine learning possono essere sviluppati solo dopo la generazione di set di addestramento specifici per UFC , garantendo così l'assenza di perdite di dati tra client. La sicurezza dei dati è integrata nel design e si rivela un altro vantaggio del negozio di funzionalità qui a Endeavor Digital.
Vogliamo inserire tutte le tabelle in un'aggregazione comune a livello di riga e, nel caso d'uso per il lavoro con Endeavor Streaming, ci preoccupiamo di ridurre le cose al livello del cliente, indicato da CUSTOMER_EXID. Le aggregazioni dell'ora di inizio/ora di fine delle visualizzazioni possono essere molto utili e degne di una tabella delle funzionalità nel nostro negozio.
WITH minutes AS (
SELECT
customer_exid,
DATEDIFF(
'minute', session_start, session_end
) AS session_length,
DATE(session_start) AS session_date
FROM
viewership
)
SELECT
customer_exid,
AVG(session_length) AS avg_session_length,
COUNT(DISTINCT session_date) AS distinct_days_active
FROM
minutes
GROUP BY
customer_exid
E viceversa, possiamo fare lo stesso per la nostra conoscenza di quali dispositivi usano per lo streaming.
SELECT
customer_exid,
MODE(device) AS most_used_device
FROM
viewership
GROUP BY
customer_exid
Poiché i flussi di dati di Endeavour Streaming sono coerenti nella loro struttura, possiamo fare affidamento su queste tabelle delle funzionalità per calcolare automaticamente queste funzionalità una volta create.
Con Churn, potremmo avere un elenco di un sottoinsieme di clienti storici (rappresentati come CUSTOMER_EXID) nonché un identificatore che indica se hanno abbandonato o annullato l'abbonamento o meno (sono attualmente attivi).
Tabella 4: tabella clienti dello stato di abbandono (churn_status)
Il nostro obiettivo con questa funzione obiettivo è trovare predittori di qualità in grado di classificare al meglio lo stato di un cliente come attivo o scaduto. Sebbene questa parte della magia avvenga nell'effettivo apprendimento automatico, dobbiamo creare un set di dati. Ma il bello del feature store è che in realtà possiamo creare molto rapidamente un set di dati da addestrare in base alle tabelle che abbiamo già. Non abbiamo bisogno di fare una query complicata per creare questa tabella, piuttosto dobbiamo solo unire tutte le funzionalità che vogliamo insieme.
SELECT
A.customer_exid,
A.status,
COALESCE(B.avg_session_length, 0) AS avg_session_length COALESCE(B.distinct_days_active, 0) AS distinct_days_active,
COALESCE(C.most_used_device, 'Invalid') AS most_used_device
FROM
churn_status A
LEFT JOIN feature_minutes B ON A.customer_exid = B.customer_exid
LEFT JOIN feature_devices C ON A.customer_exid = C.customer_exid
Come puoi vedere, ora disponiamo di un set di dati statussu cui possiamo fare previsioni, utilizzando tutte le mie funzionalità come predittori a CUSTOMER_EXID livello. Potresti anche notare qualcosa di critico qui: non tutti i clienti appariranno in ciascuna delle tue tabelle delle caratteristiche. Un cliente che ha un account ma non ha mai visualizzato alcun contenuto non apparirà mai nella viewershiptabella o nelle tabelle delle caratteristiche che ne derivano. Di conseguenza, vuoi assicurarti di aggiungere COALESCE()la maggior parte se non tutti i tuoi join per tenere conto di questi valori altrimenti nulli.
Se un altro data scientist vuole prevedere la probabilità che un cliente che ha acquistato una licenza Pay-Per-View ne acquisti una di nuovo, può verificare le funzionalità che sono già state create nel caso d'uso di abbandono per la loro funzione obiettivo. Ciò riduce significativamente i tempi di sviluppo del modello e garantisce che le definizioni delle funzionalità siano comuni a tutti i modelli. Inoltre, quando arriva il momento di produrre i tuoi modelli, puoi estrarre nuovamente dal feature store quando crei i tuoi set di inferenza. Utilizzando un feature store, ottimizzi lo sviluppo della formazione ML e crei un solido ecosistema per consentire al tuo team di data science di muoversi in modo efficace ed efficiente.
Vuoi parlare di più sui dati con l'autore? Contatta John Thomas direttamente su LinkedIn !

![Che cos'è un elenco collegato, comunque? [Parte 1]](https://post.nghiatu.com/assets/images/m/max/724/1*Xokk6XOjWyIGCBujkJsCzQ.jpeg)



































