Abbiamo pubblicato "TR-4910: Analisi del sentimento da Customer Communications con NetApp ai", In cui è stata costruita una pipeline di ai conversazionale end-to-end utilizzando "NetApp DataOps Toolkit", Storage AFF e sistema NVIDIA DGX. La pipeline esegue l'elaborazione del segnale audio batch, il riconoscimento vocale automatico (ASR), l'apprendimento del trasferimento e l'analisi del sentimento utilizzando il DataOps Toolkit, "SDK NVIDIA Riva"e il "Framework di Tao". Espandendo il caso d'uso dell'analisi del sentimento nel settore dei servizi finanziari, abbiamo creato un workflow SparkNLP, caricato tre modelli BERT per varie attività NLP, come il riconoscimento delle entità nominate, e ottenuto un sentimento a livello di frase per le chiamate trimestrali sui guadagni delle prime 10 aziende NASDAQ.

Il seguente script sentiment_analysis_spark. py Utilizza il modello FinBERT per elaborare le trascrizioni in HDFS e produrre conteggi di sentimenti positivi, neutri e negativi, come mostrato nella seguente tabella:

La seguente tabella elenca l'analisi del sentimento a livello di frase e di chiamata degli utili per le prime 10 aziende NASDAQ dal 2016 al 2020.

In termini di percentuali, la maggior parte delle frasi pronunciate dagli amministratori delegati e dai CFO è fattuale e quindi ha un sentimento neutrale. Durante una chiamata sui guadagni, gli analisti pongono domande che potrebbero trasmettere un sentimento positivo o negativo. Vale la pena di analizzare in maniera quantitativa il modo in cui il sentimento negativo o positivo influisce sui prezzi delle azioni nello stesso giorno o nel giorno successivo di negoziazione.

La seguente tabella elenca l'analisi del sentimento a livello di frase per le prime 10 aziende NASDAQ, espressa in percentuale.

In termini di runtime del workflow, abbiamo riscontrato un significativo miglioramento di 4,78 volte local A un ambiente distribuito in HDFS e un ulteriore miglioramento del 0.14% grazie all'utilizzo di NFS.

Come mostrato nella figura seguente, il parallelismo dei dati e dei modelli ha migliorato l'elaborazione dei dati e la velocità di deduzione del modello TensorFlow distribuito. La posizione dei dati in NFS ha prodotto un runtime leggermente migliore perché il collo di bottiglia del workflow è il download di modelli preformati. Se aumentiamo le dimensioni del set di dati delle trascrizioni, il vantaggio di NFS è più evidente.

Il seguente comando ha prodotto informazioni di runtime e un file di log nel cluster Spark utilizzando un singolo master nodo con 160 esecutori ciascuno con un core. La memoria dell'esecutore era limitata a 5 GB per evitare errori di memoria esaurita. Vedere la sezione ""Script Python per ogni caso di utilizzo principale"" per ulteriori dettagli sull'elaborazione dei dati, sul training del modello e sul calcolo della precisione del modello in keras_spark_horovod_rossmann_estimator.py.

Il runtime risultante con dieci epoche di training è stato il seguente:

Ci sono voluti più di 43 minuti per elaborare i dati di input, formare un modello DNN, calcolare la precisione e produrre checkpoint TensorFlow e un file CSV per i risultati delle previsioni. Abbiamo limitato il numero di epoche di training a 10, che in pratica è spesso impostato a 100 per garantire una precisione del modello soddisfacente. Il tempo di training in genere è in grado di scalare in modo lineare con il numero di epoche.

Successivamente, abbiamo utilizzato i quattro nodi di lavoro disponibili nel cluster ed eseguito lo stesso script in yarn Modalità con dati in HDFS:

Il runtime risultante è stato migliorato come segue:

Con il modello di Horovod e il parallelismo dei dati in Spark, abbiamo visto una velocità di runtime di 5,29x yarn contro local con dieci epoche di training. Questo è mostrato nella figura seguente con le legende HDFS e. Local. Il training sul modello DNN TensorFlow sottostante può essere ulteriormente accelerato con le GPU, se disponibili. Prevediamo di condurre questo test e di pubblicare i risultati in un report tecnico futuro.

Il nostro test successivo ha confrontato i runtime con i dati di input che risiedono in NFS rispetto a HDFS. Il volume NFS su AFF A800 è stato montato /sparkdemo/horovod Tra i cinque nodi (un master, quattro dipendenti) nel cluster Spark. Abbiamo eseguito un comando simile a quello dei test precedenti, con --data- dir Parametro ora che punta al montaggio NFS:

Il runtime risultante con NFS è stato il seguente:

Si è verificato un ulteriore velocismo di 1,43 volte, come mostrato nella figura seguente. Pertanto, con uno storage all-flash NetApp collegato al cluster, i clienti possono usufruire dei vantaggi di un rapido trasferimento e distribuzione dei dati per i flussi di lavoro di Horovod Spark, ottenendo una velocità di 7,55 volte superiore rispetto all'esecuzione su un singolo nodo.

Per i sistemi di raccomandazione progettati per massimizzare il CTR, è necessario imparare sofisticate interazioni di funzionalità dietro i comportamenti degli utenti che possono essere calcolati matematicamente da basso ordine a alto ordine. Le interazioni di funzionalità di basso e alto ordine devono essere ugualmente importanti per un buon modello di deep learning senza polarizzare l'uno o l'altro. DeepFM (Deep Factorization Machine), una rete neurale basata su macchine per la fattorizzazione, combina macchine per la fattorizzazione per consigli e un apprendimento approfondito per l'apprendimento delle funzionalità in una nuova architettura di rete neurale.

Anche se le macchine convenzionali di fattorizzazione modellano le interazioni a coppie come prodotto interno di vettori latenti tra le funzionalità e possono teoricamente acquisire informazioni di ordine elevato, in pratica, i professionisti dell'apprendimento automatico di solito utilizzano solo le interazioni di funzionalità di secondo ordine a causa dell'elevata complessità di calcolo e storage. Varianti di rete neurali profonde come quelle di Google " modelli profondi" d'altro canto, impara sofisticate interazioni di funzionalità in una struttura di rete ibrida combinando un modello ampio lineare e un modello profondo.

Ci sono due input per questo modello ampio e profondo, uno per il modello ampio sottostante e l'altro per il deep, l'ultima parte del quale richiede ancora un esperto di ingegneria delle funzionalità e quindi rende la tecnica meno generalizzabile per altri domini. A differenza di Wide & Deep Model, DeepFM può essere addestrato in modo efficiente con funzionalità raw senza alcuna progettazione delle funzioni, perché la sua parte ampia e profonda condividono lo stesso input e lo stesso vettore di inclusione.

Abbiamo elaborato per la prima volta il Criteo train.txt (11 GB) in un file CSV denominato ctr_train.csv Memorizzato in un montaggio NFS /sparkdemo/tr-4570-data utilizzo di run_classification_criteo_spark.py dalla sezione ""Script Python per ogni caso di utilizzo principale"." All'interno di questo script, la funzione process_input_file esegue diversi metodi di stringa per rimuovere le schede e inserire ‘,’ come delimitatore e. ‘\n’ come novità. Tenere presente che è necessario elaborare solo l'originale train.txt una volta, in modo che il blocco di codice sia visualizzato come commenti.

Per i seguenti test di diversi modelli DL, abbiamo utilizzato ctr_train.csv come file di input. Nelle successive esecuzioni dei test, il file CSV di input è stato letto in un Spark DataFrame con schema contenente un campo di ‘label’, caratteristiche ad alta densità di numeri interi ['I1', 'I2', 'I3', …, 'I13']`e funzioni sparse `['C1', 'C2', 'C3', …, 'C26']. Quanto segue spark-submit Command acquisisce un input CSV, allena i modelli DeepFM con una suddivisione del 20% per la convalida incrociata e sceglie il modello migliore dopo dieci epoche di training per calcolare l'accuratezza della previsione sul set di test:

Tenere presente che dal file di dati ctr_train.csv È superiore a 11 GB, è necessario impostare un valore sufficiente spark.driver.maxResultSize maggiore della dimensione del set di dati per evitare errori.

In quanto sopra SparkSession.builder anche la configurazione è stata abilitata "Freccia Apache", Che converte un DataFrame Spark in un DataFrame Pandas con df.toPandas() metodo.

Dopo la suddivisione casuale, nel set di dati di training sono presenti più di 36 M di righe e 9 M di esempi nel set di test:

Poiché questo report tecnico è incentrato sul test della CPU senza utilizzare alcuna GPU, è fondamentale creare TensorFlow con i flag appropriati del compilatore. Questo passaggio evita di invocare librerie con accelerazione GPU e sfrutta al meglio le istruzioni AVX (Advanced Vector Extensions) e AVX2 di TensorFlow. Queste funzionalità sono progettate per calcoli algebrici lineari come addizione vettorizzata, moltiplicazioni di matrice all'interno di un training feed-forward o DNN back-propagation. L'istruzione FMA (Fused Multiply Add) disponibile con AVX2 che utilizza registri a virgola mobile (FP) a 256 bit è ideale per i tipi di dati e codice intero, con una velocità fino a 2 volte superiore. Per il codice FP e i tipi di dati, AVX2 raggiunge una velocità dell'8% su AVX.

Per creare TensorFlow dall'origine, NetApp consiglia di utilizzare "Bazel". Per il nostro ambiente, abbiamo eseguito i seguenti comandi nel prompt della shell per l'installazione dnf, `dnf-plugins`E Bazel.

È necessario abilitare GCC 5 o versioni successive per utilizzare le funzionalità C++17 durante il processo di creazione, fornito da RHEL con Software Collections Library (SCL). I seguenti comandi vengono installati devtoolset E GCC 11.2.1 sul nostro cluster RHEL 7.9:

Si noti che gli ultimi due comandi sono disponibili devtoolset-11, che utilizza /opt/rh/devtoolset-11/root/usr/bin/gcc (GCC 11.2.1). Inoltre, assicurarsi di git La versione è superiore alla 1.8.3 (fornita con RHEL 7.9). Fare riferimento a questo "articolo" per l'aggiornamento git a 2.24.1.

Supponiamo che tu abbia già clonato l'ultimo repo master TensorFlow. Quindi, creare un workspace directory con un WORKSPACE File per la creazione di TensorFlow dall'origine con AVX, AVX2 e FMA. Eseguire configure E specificare la posizione binaria di Python corretta. "CUDA" È disattivato per i test perché non abbiamo utilizzato una GPU. R .bazelrc il file viene generato in base alle impostazioni. Inoltre, abbiamo modificato il file e il set build --define=no_hdfs_support=false Per attivare il supporto HDFS. Fare riferimento a. .bazelrc nella sezione ""Script Python per ogni caso di utilizzo principale"," per un elenco completo di impostazioni e flag.

Dopo aver creato TensorFlow con i flag corretti, eseguire il seguente script per elaborare il set di dati Criteo Display Ads, formare un modello DeepFM e calcolare l'area sotto la curva caratteristica operativa ricevitore (ROC AUC) in base ai punteggi di previsione.

Dopo dieci epoche di training, abbiamo ottenuto il punteggio AUC nel set di dati di test:

In modo simile ai casi di utilizzo precedenti, abbiamo confrontato il runtime del workflow Spark con i dati che risiedono in posizioni diverse. La figura seguente mostra un confronto della previsione CTR di apprendimento approfondito per un runtime di workflow Spark.