Nós publicamos"TR-4910: Análise de sentimentos das comunicações com o cliente com a NetApp AI" , no qual um pipeline de IA de conversação de ponta a ponta foi construído usando o "Kit de ferramentas NetApp DataOps" , armazenamento AFF e sistema NVIDIA DGX. O pipeline executa processamento de sinal de áudio em lote, reconhecimento automático de fala (ASR), aprendizagem de transferência e análise de sentimentos, aproveitando o DataOps Toolkit, "NVIDIA Riva SDK" , e o "Estrutura do Tao" . Expandindo o caso de uso da análise de sentimentos para o setor de serviços financeiros, criamos um fluxo de trabalho SparkNLP, carregamos três modelos BERT para várias tarefas de PNL, como reconhecimento de entidade nomeada, e obtivemos sentimentos em nível de frase para as teleconferências de resultados trimestrais das 10 maiores empresas da NASDAQ.

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

A tabela a seguir lista a análise de sentimento em nível de frase e teleconferência de resultados para as 10 maiores empresas da NASDAQ de 2016 a 2020.

Em termos de porcentagem, a maioria das frases ditas pelos CEOs e CFOs são factuais e, portanto, carregam sentimentos neutros. Durante uma teleconferência de resultados, os analistas fazem perguntas que podem transmitir sentimentos positivos ou negativos. Vale a pena investigar mais quantitativamente como o sentimento negativo ou positivo afeta os preços das ações no mesmo dia ou no dia seguinte de negociação.

A tabela a seguir lista a análise de sentimento em nível de frase para as 10 maiores empresas do NASDAQ, expressa em porcentagem.

Em termos de tempo de execução do fluxo de trabalho, vimos uma melhoria significativa de 4,78x 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 modelos melhorou o processamento de dados e a velocidade de inferência do modelo distribuído do TensorFlow. A localização dos dados no NFS produziu um tempo de execução um pouco 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 fica mais óbvia.

O comando a seguir produziu informações de tempo de execução e um arquivo de log em nosso cluster Spark usando um único master nó com 160 executores, cada um com um núcleo. A memória do executor foi limitada a 5 GB para evitar erros de falta de memória. Veja a seção"Scripts Python para cada caso de uso principal" para mais detalhes sobre o processamento de dados, treinamento do modelo e cálculo de 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:

Foram necessários mais de 43 minutos para processar dados de entrada, treinar um modelo DNN, calcular a precisão e produzir pontos de verificação do TensorFlow e um arquivo CSV para resultados de previsão. Limitamos o número de períodos de treinamento a 10, que na prática geralmente é definido como 100 para garantir precisão satisfatória do modelo. O tempo de treinamento normalmente é escalonado 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 em yarn modo com dados em HDFS:

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

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

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

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

Houve uma aceleração adicional de 1,43x, conforme mostrado na figura a seguir. Portanto, com um armazenamento all-flash da NetApp conectado ao seu 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,55x em comparação à execução em um único nó.

Para sistemas de recomendação projetados para maximizar o CTR, você deve aprender interações de recursos sofisticados por trás dos comportamentos do usuário que podem ser calculados matematicamente da ordem mais baixa para a mais alta. Tanto as interações de recursos de baixa quanto de alta ordem devem ser igualmente importantes para um bom modelo de aprendizado profundo, sem distorção em relação a uma ou outra. Deep Factorization Machine (DeepFM), uma rede neural baseada em máquina de fatoração, combina máquinas de fatoração para recomendação e aprendizado profundo para aprendizado de recursos em uma nova arquitetura de rede neural.

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

Há duas entradas para este Modelo Amplo e Profundo, uma para o modelo amplo subjacente e outra para o profundo, sendo que esta última parte ainda requer engenharia de recursos especializada e, portanto, torna a técnica menos generalizável para outros domínios. Diferentemente do modelo amplo e profundo, o DeepFM pode ser treinado eficientemente com recursos brutos sem qualquer engenharia de recursos, porque sua parte ampla e parte profunda compartilham a mesma entrada e o mesmo vetor de incorporação.

Primeiro processamos o Criteo train.txt (11 GB) em um arquivo CSV chamado ctr_train.csv armazenado em uma montagem NFS /sparkdemo/tr-4570-data usando run_classification_criteo_spark.py 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 tabulações 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 testes seguintes de diferentes modelos DL, usamos ctr_train.csv como arquivo de entrada. Em execuções de testes subsequentes, o arquivo CSV de entrada foi lido em um Spark DataFrame com esquema contendo um campo de 'label' , recursos densos inteiros ['I1', 'I2', 'I3', …, 'I13'] , e recursos esparsos ['C1', 'C2', 'C3', …, 'C26'] . A seguir spark-submit O comando recebe um CSV de entrada, treina modelos DeepFM com divisão de 20% para validação cruzada e escolhe o melhor modelo após dez períodos de treinamento para calcular a precisão da previsão no conjunto de teste:

Observe que, como o arquivo de dados ctr_train.csv for maior que 11 GB, você deve definir um espaço suficiente spark.driver.maxResultSize maior que o tamanho do conjunto de dados para evitar erros.

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

Após a divisão aleatória, há mais de 36 milhões de linhas no conjunto de dados de treinamento e 9 milhões de amostras no conjunto de teste:

Como este relatório técnico se concentra em testes de CPU sem usar GPUs, é fundamental que você crie o TensorFlow com sinalizadores de compilador apropriados. Esta etapa evita invocar quaisquer bibliotecas aceleradas por GPU e aproveita ao máximo as instruções Advanced Vector Extensions (AVX) e AVX2 do TensorFlow. Esses recursos são projetados para cálculos algébricos lineares, como adição vetorizada, multiplicação de matrizes dentro de um treinamento DNN de propagação direta ou retropropagação. A instrução Fused Multiply Add (FMA) disponível com AVX2 usando registradores de ponto flutuante (FP) de 256 bits é ideal para códigos inteiros e tipos de dados, resultando em um aumento de velocidade de até 2x. Para códigos FP e tipos de dados, o AVX2 atinge 8% de aceleração em relação ao AVX.

Para construir o TensorFlow a partir do código-fonte, a NetApp recomenda usar "Bazel" . Para nosso ambiente, executamos os seguintes comandos no prompt do shell para instalar dnf , dnf-plugins , e Bazel.

Você deve habilitar o GCC 5 ou mais recente para usar os recursos do C++17 durante o processo de compilação, que é fornecido pelo RHEL com a Software Collections Library (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 seu git a versão é maior que 1.8.3 (vem com o RHEL 7.9). Consulte isto "artigo" para atualização git para 2.24.1.

Presumimos que você já clonou o repositório mestre mais recente do TensorFlow. Em seguida, crie um workspace diretório com um WORKSPACE arquivo para compilar o TensorFlow a partir do código-fonte com AVX, AVX2 e FMA. Execute o configure arquivo e especifique o local binário correto do Python. "CUDA" está desabilitado para nossos testes porque não usamos uma GPU. UM .bazelrc o arquivo é gerado de acordo com suas configurações. Além disso, editamos o arquivo e configuramos build --define=no_hdfs_support=false para habilitar o suporte HDFS. Consulte .bazelrc na seção"Scripts Python para cada caso de uso principal," para uma lista completa de configurações e sinalizadores.

Depois de criar o TensorFlow com os sinalizadores corretos, execute o script a seguir para processar o conjunto de dados Criteo Display Ads, treinar um modelo DeepFM e calcular a Área sob a Curva Característica Operacional do Receptor (ROC AUC) a partir das pontuações de previsão.

Após dez períodos de treinamento, obtivemos a pontuação AUC no conjunto de dados de teste:

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