Publicamos "TR-4910: Análise de sentimento a partir de comunicações com clientes com o NetApp AI", no qual um pipeline de AI conversacional completo foi criado usando o "Toolkit DataOps do NetApp", o storage da AFF e o sistema NVIDIA DGX. O pipeline executa o processamento de sinal de áudio em lote, o reconhecimento automático de fala (ASR), o aprendizado de transferência e a análise de sentimento usando o DataOps Toolkit e "O NVIDIA é um SDK" o "Tao framework". Expandindo o caso de uso de análise de sentimento para o setor de serviços financeiros, construímos um fluxo de trabalho SparkNLP, carregamos três modelos BERT para várias tarefas de PNL, como reconhecimento de entidades nomeadas, e obtivemos sentimento em nível de sentença para as chamadas de ganhos trimestrais das 10 principais empresas da NASDAQ.

O script a seguir sentiment_analysis_spark. py usa o modelo FinBERT para processar transcrições no HDFS e produzir contagens de sentimentos positivos, neutros e negativos, como mostrado na tabela a seguir:

A tabela a seguir lista a análise de sentimento em nível de frase para as 10 principais empresas da NASDAQ de 2016 a 2020.

Em termos de porcentagens, a maioria das frases faladas pelos CEOs e CFOs são factuais e, portanto, carregam sentimentos neutros. Durante uma chamada de resultados, os analistas fazem perguntas que possam transmitir sentimento positivo ou negativo. Vale a pena investigar quantitativamente como o sentimento negativo ou positivo afeta os preços das ações no mesmo ou no dia seguinte da negociação.

A tabela a seguir lista a análise de sentimento em nível de sentença para as 10 principais empresas da NASDAQ, expressa em porcentagem.

Em termos de tempo de execução do fluxo de trabalho, vimos uma melhoria significativa de 4,78x do local modo para um ambiente distribuído no HDFS e uma melhoria adicional de 0,14% ao aproveitar o NFS.

Como mostra a figura a seguir, o paralelismo de dados e modelo melhorou a velocidade de inferência do modelo Data Processing e Distributed TensorFlow. O local dos dados no NFS rendeu um tempo de execução ligeiramente melhor, porque o gargalo do fluxo de trabalho é o download de modelos pré-treinados. Se aumentarmos o tamanho do conjunto de dados de transcrições, a vantagem do NFS é mais óbvia.

O comando a seguir produziu informações de tempo de execução e um arquivo de log em nosso cluster do Spark usando um único master nó com 160 executores cada um com um núcleo. A memória do executor estava limitada a 5GB MB para evitar erros de memória. Consulte a seção ""Scripts Python para cada caso de uso principal"" para obter mais detalhes sobre o Data Processing, o treinamento do modelo e o cálculo da precisão do modelo em keras_spark_horovod_rossmann_estimator.py.

O tempo de execução resultante com dez épocas de treinamento foi o seguinte:

Demorou mais de 43 minutos para processar dados de entrada, treinar um modelo DNN, calcular a precisão e produzir checkpoints TensorFlow e um arquivo CSV para resultados de previsão. Limitamos o número de épocas de treinamento a 10, que na prática é muitas vezes definido para 100 para garantir uma precisão satisfatória do modelo. O tempo de treinamento normalmente escala linearmente com o número de épocas.

Em seguida, usamos os quatro nós de trabalho disponíveis no cluster e executamos o mesmo script no yarn modo com dados no HDFS:

O tempo de execução resultante foi melhorado da seguinte forma:

Com o modelo de Horovod e paralelismo de dados no Spark, vimos uma aceleração de tempo de execução 5,29x do yarn modo versus local com dez épocas de treinamento. Isso é mostrado na figura a seguir com as legendas HDFS e Local. O treinamento subjacente do modelo DNN TensorFlow pode ser acelerado ainda mais com GPUs, se disponível. Planejamos realizar esse teste e publicar resultados em um relatório técnico futuro.

Nosso próximo teste comparou os tempos de execução com dados de entrada residentes em NFS versus HDFS. O volume de NFS no AFF A800 foi montado /sparkdemo/horovod nos cinco nós (um mestre, quatro trabalhadores) em nosso cluster do Spark. Executamos um comando semelhante ao dos testes anteriores, com o --data- dir parâmetro apontando agora para a montagem NFS:

O tempo de execução resultante com NFS foi o seguinte:

Houve mais 1,43x speedup, como mostrado na figura a seguir. Portanto, com um storage all-flash NetApp conetado ao cluster, os clientes aproveitam os benefícios da rápida transferência e distribuição de dados para fluxos de trabalho do Horovod Spark, alcançando uma aceleração de 7,55xx em comparação com a execução em um único nó.

Para sistemas de recomendação projetados para maximizar a CTR, você deve aprender interações sofisticadas de recursos por trás dos comportamentos do usuário que podem ser calculadas matematicamente de ordem baixa a ordem alta. As interações de recursos de baixa ordem e alta ordem devem ser igualmente importantes para um bom modelo de aprendizagem profunda sem se aproximar de um ou outro. Deep Factorization Machine (DeepFM), uma rede neural baseada em máquina de fatoração, combina máquinas de fatoração para recomendação e deep learning para aprendizado de recursos em uma nova arquitetura de rede neural.

Embora as máquinas de fatoração convencionais modem a harmonização apresentem interações como um produto interno de vetores latentes entre as caraterísticas e possam, teoricamente, capturar informações de alta ordem, na prática, os profissionais de aprendizado de máquina geralmente usam interações de recurso de segunda ordem devido à alta complexidade de computação e armazenamento. Variantes de redes neurais profundas como as do Google "Modelos amplos profundos", por outro lado, aprendem interações sofisticadas de recursos em uma estrutura de rede híbrida, combinando um modelo linear amplo e um modelo profundo.

Existem duas entradas para este modelo amplo e profundo, uma para o modelo amplo subjacente e outra para o profundo, a última parte da qual ainda requer engenharia de recursos especializados e, assim, torna a técnica menos generalizável para outros domínios. Ao contrário do modelo Wide & Deep, DeepFM pode ser treinado eficientemente com recursos brutos sem qualquer engenharia de recursos, porque sua parte larga e parte profunda compartilham a mesma entrada e o vetor de incorporação.

Primeiro, processamos o arquivo Criteo ( train.txt`11GB) em um arquivo CSV chamado `ctr_train.csv armazenado em uma montagem NFS /sparkdemo/tr-4570-data usando run_classification_criteo_spark.py a partir da seção ""Scripts Python para cada caso de uso principal."" dentro deste script, a função process_input_file executa vários métodos de string para remover guias e inserir ‘,’ como delimitador e ‘\n’ como nova linha. Observe que você só precisa processar o original train.txt uma vez, para que o bloco de código seja mostrado como comentários.

Para os seguintes testes de diferentes modelos DL, usamos ctr_train.csv como o arquivo de entrada. Em testes subsequentes, o arquivo CSV de entrada foi lido em um Spark DataFrame com esquema contendo um campo ‘label’ de , recursos inteiros densos ['I1', 'I2', 'I3', …, 'I13'] e recursos esparsos ['C1', 'C2', 'C3', …, 'C26'] . O comando a seguir spark-submit leva em um CSV de entrada, treina modelos DeepFM com 20% de divisão para validação cruzada e escolhe o melhor modelo após dez épocas de treinamento para calcular a precisão de previsão no conjunto de testes:

Observe que, uma vez que o arquivo de dados ctr_train.csv é superior a 11GB, você deve definir um valor suficiente spark.driver.maxResultSize maior do que o tamanho do conjunto de dados para evitar erros.

Na configuração acima SparkSession.builder, também habilitamos "Apache Arrow"o , que converte um Spark DataFrame em um PANDAS DataFrame com o df.toPandas() método.

Após a divisão aleatória, existem mais de 36M linhas no conjunto de dados de treinamento e 9M amostras no conjunto de testes:

Como esse relatório técnico é focado em testes de CPU sem usar GPUs, é imperativo que você construa o TensorFlow com flags de compilador apropriados. Esta etapa evita invocar qualquer biblioteca acelerada por GPU e aproveita ao máximo as instruções do TensorFlow (AVX) e do AVX2. Esses recursos são projetados para computações algébricas lineares, como adição vetorizada, multiplicações de matriz dentro de um treinamento DNN de avanço ou retropropagação. A instrução Fused Multiply Add (FMA) disponível com AVX2 usando Registros de ponto flutuante de 256 bits (FP) é ideal para código inteiro e tipos de dados, resultando em até 2x speedup. Para códigos FP e tipos de dados, o AVX2 alcança um aumento de 8% em relação ao AVX.

Para criar o TensorFlow a partir da fonte, o NetApp recomenda o uso "Bazel"do . Para o nosso ambiente, executamos os seguintes comandos no prompt shell para instalar dnf dnf-plugins , , e Bazel.

Você deve habilitar o GCC 5 ou mais recente para usar os recursos C-17 durante o processo de compilação, que é fornecido pelo RHEL com a Biblioteca de Coleções de Software (SCL). Os seguintes comandos instalam devtoolset e GCC 11.2.1 em nosso cluster RHEL 7,9:

Observe que os dois últimos comandos habilitam devtoolset-11, que usa /opt/rh/devtoolset-11/root/usr/bin/gcc (GCC 11,2.1). Além disso, certifique-se de que sua git versão é maior que 1.8.3 (isso vem com RHEL 7,9). Consulte esta "artigo" secção para atualizar git para 2.24.1.

Nós assumimos que você já clonou o mais recente repositório mestre TensorFlow. Em seguida, crie um workspace diretório com um WORKSPACE arquivo para construir o TensorFlow a partir da fonte com AVX, AVX2 e FMA. Execute o configure arquivo e especifique a localização binária correta do Python. "CUDA" Está desativado para nossos testes porque não usamos uma GPU. Um .bazelrc arquivo é gerado de acordo com suas configurações. Além disso, editamos o arquivo e definimos build --define=no_hdfs_support=false para ativar o suporte HDFS. Consulte .bazelrc na secção ""Scripts Python para cada caso de uso principal"," para obter uma lista completa de definições e sinalizadores.

Depois de criar o TensorFlow com os sinalizadores corretos, execute o seguinte script para processar o conjunto de dados do Criteo Display ads, treine um modelo DeepFM e calcule a Área sob a curva caraterística de operação do recetor (ROC AUC) a partir de pontuações de previsão.

Após dez épocas de treinamento, obtivemos a pontuação AUC no conjunto de dados de teste:

De forma semelhante aos casos de uso anteriores, comparamos o tempo de execução do fluxo de trabalho do Spark com dados residentes em diferentes locais. A figura a seguir mostra uma comparação da previsão de CTR de aprendizado profundo para um runtime de fluxos de trabalho do Spark.