Desenvolvimento

14 set, 2018

Dimensionamento do Assistente de Tíquetes de Suporte ao Cliente (COTA) da Uber com Deep Learning

Publicidade

No início deste ano, introduzimos o Assistente de Tíquetes de Obsessão do Cliente da Uber (COTA), uma ferramenta que aproveita as técnicas de aprendizado de máquina e processamento de linguagem natural (NLP) para recomendar respostas de tickets de suporte (Tipo de Contato e Resposta) a agentes de suporte ao cliente, com Tipo de Contato sendo a categoria de problema à qual o ticket está atribuído e Resposta sendo o modelo que os agentes usam para responder. Depois de integrá-lo à nossa Plataforma de Suporte ao Cliente, o COTA v1 reduziu os tempos de resolução de tickets no idioma inglês em mais de 10%, ao mesmo tempo em que oferece serviços com níveis semelhantes ou mais altos de satisfação do cliente.

Para a Uber, o COTA v1 foi apenas o começo. Em um esforço para melhorar o desempenho do COTA, realizamos experimentos off-line que mostraram que a aprendizagem profunda pode aumentar a precisão de previsão top-1 da solução em 16% (de 49% para 65%) para o modelo de Tipo de Contato e 8% (de 47% para 55 por cento) para o modelo Resposta (para mais detalhes, por favor consulte nosso artigo sobre KDD), um verdadeiro feito, dada a complexidade dessas tarefas.

Com esses resultados encorajadores, decidimos incorporar nossos modelos de aprendizagem profunda na plataforma interna de aprendizagem de máquina da Uber, Michelangelo. Conseguimos isso construindo um Pipeline de aprendizagem profunda baseado em Spark para produzir a segunda geração de COTA (COTA v2) usando a infraestrutura existente de Michelangelo.

Dado que o desempenho do modelo declina ao longo do tempo, também construímos um pipeline de gerenciamento de modelos para requalificar/reciclar e reformar automaticamente os modelos para mantê-los atualizados o tempo todo.

Após a integração com Michelangelo, nossos testes on-line validam que o sistema de aprendizagem profunda COTA v2 tem desempenho significativamente melhor que o sistema COTA v1 em termos de métricas-chave, incluindo desempenho do modelo, tempo de manipulação de tickets e satisfação do cliente.

Primeira geração do COTA: desafios e oportunidades

Enquanto o COTA v1 acelerou a resolução do ticket de suporte, havia duas áreas principais que identificamos para melhoria. Primeiro, o COTA v1 realizou amostragem negativa de uma maneira excessivamente complexa que dificultou o treinamento de nossos modelos. Combinado com dependências em tabelas de dados específicas, esse fator acabou por tornar a requalificação do COTA uma tarefa substancial. Embora não seja intransponível, esse nível de dificuldade para uma tarefa contínua/em curso poderia, com o tempo, desincentivar a manutenção regular.

Segundo, nossa implementação original não foi extensível o suficiente para ser usada por futuros modelos de PNL. Desde então, fizemos um esforço muito consciente para desenvolver um processo de implantação de aprendizagem profunda que abre as portas não apenas para nossos modelos, mas também para os de todas as outras equipes da Uber.

Por que a aprendizagem profunda?

O sucesso do COTA v1 nos motivou a investir ainda mais em nossa pilha de tecnologia e a explorar outras soluções de resolução de suporte. Atendendo a mais de 600 cidades em todo o mundo, oferecendo suporte a vários idiomas e facilitando mais de cinco canais de comunicação, o suporte ao cliente da Uber alcança clientes em todos os nossos negócios, incluindo ridesharing/compartilhamento de viagens, Uber Eats, bikesharing/compartilhamento de bicicletas e Uber Freight.

O escopo e a escala de nossos negócios agregaram enorme complexidade ao desafio que enfrentamos. Como resultado, o número de maneiras de categorizar e resolver tickets de suporte é da ordem de milhares. Além disso, o crescimento da Uber exige que façamos uma interação sem precedentes. Uma solução que funciona hoje pode não funcionar em alguns meses se não levarmos em conta o crescimento dos negócios.

A aprendizagem profunda revolucionou muitos domínios, como tradução automática, reconhecimento de fala, visão computacional e compreensão da linguagem natural, e alcançou desempenho igual ou superior aos especialistas humanos para determinadas tarefas. Por exemplo, os modelos de aprendizagem profunda já superaram os humanos em algumas tarefas de classificação e reconhecimento de imagens.

Para a tarefa de usar fotografias de retina para detectar doenças oculares diabéticas, o Google mostrou que os algoritmos de aprendizagem profunda têm um desempenho semelhante ao dos oftalmologistas. O recente sucesso do AlphaGo demonstra que os algoritmos de aprendizagem profunda combinados com o aprendizado por reforço podem até mesmo vencer os melhores jogadores humanos de Go do mundo no que é considerado o jogo de tabuleiro mais complicado da humanidade.

Com base nesses exemplos e muitos outros, a aprendizagem profunda parecia uma escolha natural para o desenvolvimento do COTA v2. De fato, por meio de experimentos off-line, descobrimos que os modelos de aprendizagem profunda podem fornecer previsões de resolução de tickets muito mais precisas quando comparadas ao COTA v1.

Movendo-se para o COTA v2 com aprendizagem profunda

Para resumir brevemente, o COTA v1 foi desenvolvido com técnicas tradicionais de aprendizagem de máquina e PNL baseadas em modelagem de tópicos que incorporam uma mistura de recursos textuais, categóricos e numéricos, conforme mostrado na Figura 1 (a), abaixo:

Figura 1. (a) A arquitetura do modelo do COTA v1 utiliza modelagem de tópicos, técnicas tradicionais de engenharia de recursos e um algoritmo de classificação de pontos, enquanto (b) o COTA v2 suporta uma arquitetura de aprendizagem profunda com uma mistura de recursos de entrada.

Para extrair os recursos textuais, um Pipeline de NLP foi criado para processar as mensagens de entrada de tickets. A modelagem de tópicos foi usada para extrair a representação de recursos do recurso de texto. Engenharia de recursos adicionais foi usada para gerar similaridade de cosseno.

Depois que cada recurso foi desenvolvido, todos os recursos foram inseridos em um algoritmo de classificação binário em pontos para prever as respostas Tipo de Contato e Resposta.

A Figura 1 (b) mostra a arquitetura de aprendizagem profunda que usamos para o COTA v2.

O recurso de texto passa pelo pré-processamento típico da NLP, como limpeza de texto e tokenização (não mostrada), e cada palavra no ticket é codificada usando uma camada de incorporação (não mostrada) para converter a palavra em uma representação densa que continua nas camadas de convolução para codificar todo o corpo do texto.

Os recursos categóricos são codificados usando uma camada de incorporação para capturar a proximidade entre diferentes categorias. Os recursos numéricos são normalizados em lote para estabilizar o processo de treinamento.

Nossos experimentos off-line mostram que o sistema de aprendizagem profunda COTA v2 tem desempenho sistematicamente melhor (8-16% de melhoria) do que o COTA v1 tanto para as tarefas individuais de identificar Tipo de Contato ou Resposta independentemente quanto para a tarefa conjunta de prever Tipo de Contato e Resposta imediatamente.

Figura 2. Os gráficos t-SNE descrevem as incorporações aprendidas por modelos de aprendizagem profunda para a) palavras e b) tipos de contato.

A Figura 2, acima, mostra os gráficos de Incorporação de Vizinhos Estocásticos Distribuídos (t-SNE) das incorporações que aprendemos por meio de modelos de aprendizagem profunda. Por exemplo, na Figura 2 (a), visualizamos algumas palavras-chave específicas da Uber e observamos que “veículo” e “carro” estão muito próximos um do outro no gráfico t-SNE da incorporação. Palavras relacionadas ao pagamento, como “cobrança”, “crédito” e “tarifa”, também estão agrupadas na trama.

A Figura 2 (b) indica as incorporações aprendidas para os tipos de contato com cada ponto de dados correspondente a um tipo de contato exclusivo. Os tipos de contato são codificados por cores em três grupos principais: “passageiro”, “motorista” e “outro” (por exemplo, comedor, restaurante etc.). O gráfico t-SNE mostra clusters claros de tipos de contato relacionados ao passageiro e ao motorista.

Essas visualizações confirmam intuitivamente que o modelo está aprendendo representações razoáveis ​​e sugere que ele é capaz de capturar correlações e conexões semânticas entre palavras e relações entre tipos de contato.

Em suma, a aprendizagem profunda pode melhorar a precisão de previsão top-1 da solução em 16% (de 49% para 65%) para o modelo de Tipo de Contato e 8% (de 47% para 55%) para o modelo de Resposta comparado ao COTA v1 , o que pode melhorar diretamente a experiência de suporte ao cliente.

Desafios e soluções para implantar o COTA v2

Dado o forte desempenho dos modelos de aprendizagem profunda em nossa análise off-line, decidimos integrar o sistema COTA v2 à produção. No entanto, dada a complexidade de integrar tanto as transformações de PNL quanto o treinamento de aprendizagem profunda, além de usar uma grande quantidade de dados de treinamento, a implantação de nossos modelos de aprendizagem profunda do COTA v2 veio com sua parcela justa de desafios.

Idealmente, queríamos aproveitar o Spark para as transformações de PNL de maneira distribuída. Os cálculos do Spark são tipicamente feitos usando clusters de CPU. Por outro lado, o treinamento de aprendizagem profunda é executado com mais eficiência em uma infraestrutura baseada em GPU. Para abordar essa dualidade, precisávamos descobrir uma maneira de usar tanto as transformações do Spark quanto o treinamento da GPU, bem como criar um Pipeline unificado para treinar e atender ao modelo de aprendizagem profunda.

Outro desafio com o qual lidamos foi determinar como manter o frescor do modelo, dada a natureza dinâmica dos negócios da Uber. Em vista disso, um pipeline era necessário para requalificar e reimplementar modelos com frequência.

Para resolver o primeiro desafio, construímos um Pipeline Spark de aprendizagem profunda (DLSP) para aproveitar Spark para as transformações de NLP e as GPUs para treinamento de aprendizagem profunda. Para o segundo desafio, integramos uma ferramenta interna de agendamento de trabalho e construímos um Pipeline modelo de gerenciamento de ciclo de vida (MLMP) sobre o DLSP, o que nos permite programar e executar cada trabalho na frequência necessária. Esses dois pipelines nos permitiram não apenas treinar e implantar modelos de aprendizagem profunda no sistema de produção da Uber, mas também requalificar e atualizar os modelos para mantê-los no desempenho máximo.

Nas próximas duas seções, discutiremos os dois pipelines em maior detalhe.

Spark Pipeline de Aprendizagem Profunda do COTA v2

Ao projetar nosso DLSP, desejamos atribuir tarefas a CPUs e GPUs com base em qual hardware seria mais eficiente. A definição do pipeline em dois estágios, um para o pré-processamento do Spark e um para a aprendizagem profunda, parecia ser a melhor maneira de alocar a carga de trabalho. Ao estender o conceito de um Spark Pipeline, podemos servir modelos para previsão de lotes e serviços de previsão em tempo real usando nossa infraestrutura existente.

Treinamento

O treinamento do modelo é dividido em duas etapas, conforme mostrado na Figura 3 (a), abaixo:

  • Transformações de pré-processamento usando o Spark: Aproveitamos nossos grandes clusters Spark para executar o pré-processamento de dados e ajustar as transformações necessárias para o treinamento e a veiculação. Todas as transformações executadas nos dados durante o pré-processamento são salvas como transformadores do tipo Spark, que são usados ​​para criar um Pipeline do Spark para veiculação. O pré-processamento distribuído no cluster do Spark é muito mais rápido do que os dados de pré-processamento em uma máquina de GPU de node único. Calculamos as transformações ajustadas (transformações que exigem dados persistentes, por exemplo, StringIndexer) e transformações não ajustadas (por exemplo, limpeza de tags HTML de strings etc.) no cluster do Spark.
  • Treinamento de aprendizagem profunda usando o TensorFlow: Quando o pré-processamento da etapa (1) for concluído, aproveitamos os dados pré-processados ​​para treinar o modelo de aprendizagem profunda usando o TensorFlow. O modelo treinado deste estágio é então mesclado com o Spark Pipeline gerado na etapa (1). Isso produz o Spark Pipeline final, englobando os transformadores de pré-processamento e o modelo TensorFlow, que pode ser usado para executar previsões. Somos capazes de combinar o Spark Pipeline com o modelo TensorFlow implementando um tipo especial de transformador chamado TFTransformer, que traz o modelo TensorFlow para o Spark. É importante observar que, como todos os Transformadores do Spark são respaldados por implementações Java, o TFTransformer segue esse padrão.
Figura 3. Construímos uma arquitetura de Spark Pipeline de aprendizagem profunda para a) modelos de treinamento e b) atendendo a solicitações.

Servindo

A Figura 3 (b) mostra como servimos o modelo treinado usando um Spark Pipeline de aprendizagem profunda para os serviços de predição em lote e de previsão em tempo real. O Spark Pipeline construído a partir do treinamento contém transformações de pré-processamento e transformações do TensorFlow.

Estendemos a Michelangelo para apoiar o fornecimento de Spark Sparkelines genéricos e utilizamos a infraestrutura existente de implantação e fornecimento para atender ao modelo de aprendizagem profunda.

O pipeline usado para veiculação é executado em uma Java Virtual Machine (JVM). O desempenho que vemos durante o fornecimento tem uma latência de p95 < 10ms, o que demonstra a vantagem da baixa latência ao usar uma infraestrutura de fornecimento de JVM existente para modelos de aprendizagem profunda. Ao estender o Spark Pipelines para encapsular os modelos de aprendizagem profunda, aproveitamos o melhor dos mundos controlados por CPU e GPU:

  • 1) Cálculo distribuído de transformações do Spark e baixa latência fornecendo pipelines de Spark usando CPUs
  • 2) Aceleração de treinamento em modelo de aprendizagem profunda usando GPUs

Pipeline de gerenciamento do ciclo de vida do modelo: mantendo os modelos atualizados

Para evitar que o desempenho do modelo COTA v2 se decresça ao longo do tempo, criamos um pipeline de gerenciamento do ciclo de vida do modelo (MLMP) em cima de nosso DLSP. Em especial, aproveitamos a ferramenta interna de agendamento de trabalho da Uber para construir um Pipeline de ponta a ponta para requalificar e reimplantar nossos modelos em uma frequência fixa.

Figura 4. Nosso pipeline de gerenciamento do ciclo de vida do modeloconsiste em seis trabalhos, incluindo Data ETL, Transformações do Spark e Fusão de Modelos.

A Figura 4, acima, descreve o fluxo desse pipeline. Consistindo em seis trabalhos no total, ele usa as APIs existentes de Michelangelo para requalificar o modelo. Esses trabalhos formam um gráfico acíclico direcionado (DAG) com dependência indicada pelas setas:

  • ETL de dados: Envolve a gravação de uma tarefa de extração de dados, transformação básica e carregamento (ETL) para preparar dados. Normalmente, ele extrai dados de várias fontes de dados diferentes, convertendo-os no formato correto e colocando-os em um banco de dados Hive.
  • Transformação Spark: Essa etapa transforma dados brutos (textuais, categóricos, numéricos etc.) em formato Tensor, de modo que eles possam ser consumidos por um gráfico do TensorFlow para treinamento de modelo. A transformação subjacente utiliza o Spark Engine via Michelangelo em uma forma de computação distribuída. Os transformadores são salvos em um armazenamento de modelo.
  • Transferência de dados: Os clusters de computadores com CPUs realizam as transformações Spark. O treinamento de aprendizagem profunda requer GPUs para acelerar o progresso. Portanto, transferimos os dados de saída da Etapa 2 para os clusters da GPU.
  • Treinamento de Aprendizagem Profunda: Uma vez que os dados são transferidos para os clusters da GPU. Um trabalho é acionado para abrir uma sessão de GPU com um contêiner do Docker personalizado e iniciar o processo de treinamento de aprendizagem profunda. Depois que o treinamento é concluído, um arquivo de modelo do TensorFlow é salvo no armazenamento de modelo.
  • Fusão de modelos: Os transformadores Spark da Etapa 2 e o modelo TensorFlow da Etapa 4 são mesclados para formar o modelo final.
  • Implementação do Modelo: O modelo final é implementado e um model_id é gerado como uma referência ao modelo recém-implementado. Os microsserviços externos podem atingir o endpoint usando a framework de fornecimento do Thrift, fazendo referência ao model_id.

Teste online: COTA v1 versus COTA v2

Para validar o desempenho dos modelos de aprendizagem profunda do COTA v2 que observamos offline, realizamos um teste on-line antes de implantar o sistema.

Estratégia de teste

Para evitar viés de amostragem pré-existente, realizamos um teste A/A antes de ativar o teste A/B, conforme mostrado na Figura 5, abaixo:

Figura 5. Estratégia de teste geral para comparar os sistemas COTA v1 e COTA v2.

Durante os testes A/A e A/B, os tickets de suporte são distribuídos aleatoriamente em grupos controle e de tratamento com base em uma divisão 50/50. Na fase de teste A/A, os grupos controle e de tratamento estão recebendo previsões dos mesmos modelos do COTA v1. Enquanto na fase de teste A/B, o grupo de tratamento é fornecido pelos modelos de aprendizagem profunda COTA v2.

Resultados

Fizemos o teste A/A durante uma semana e o teste A/B durante cerca de um mês. A Figura 6, abaixo, descreve duas métricas principais que acompanhamos: precisão do modelo (usamos o modelo de Tipo de Contato como exemplo aqui) e o tempo médio de atendimento por ticket. Como mostrado na Figura 6(a), não há diferença no desempenho do modelo durante a fase de teste A/A, enquanto há um grande salto depois que ativamos o teste A/B. Estes resultados confirmam que o sistema de aprendizagem profunda do COTA v2 fornece soluções mais precisas para os agentes em comparação com o COTA v1.

O tempo médio de atendimento por ticket é muito menor para o grupo de tratamento em toda a fase de teste A/B, conforme mostrado na Figura 6(b). Uma observação adicional da Figura 6(a) é que o desempenho do modelo decai ao longo do tempo, destacando a necessidade do Pipeline de gestão do modelo MLMP mostrado na Figura 5. (Observação: para garantir a consistência, não requalificamos os modelos durante o curso do experimento).

Nossos testes on-line provaram novamente que, havendo dados de treinamento suficientes, nossos modelos de aprendizagem profunda COTA v2 podem superar significativamente os modelos clássicos de aprendizagem de máquina COTA v1.

Figura 6. Principais métricas do teste on-line: a) precisão do modelo e b) tempo médio de manipulação durante os testes A/A e A/B diariamente.

Uma análise estatística mostra que durante o teste A/A não houve diferença estatisticamente significativa entre os tempos médios de manipulação dos grupos controle e de tratamento, enquanto houve diferença estatisticamente significativa durante o teste A/B. Esta é uma redução relativa de 6,6%, acelerando os tempos de resolução de tickets e melhorando a precisão de nossas recomendações de resolução de tickets. Além disso, também medimos as pontuações de satisfação do cliente e encontramos uma pequena melhora como resultado do uso do COTA v2.

Além de melhorar a experiência de suporte ao cliente, o COTA v2 também economizará milhões de dólares a cada ano para a empresa, simplificando o processo de suporte de resolução do ticket.

Próximos passos

Dado o forte desempenho de nossos modelos de aprendizagem profunda no COTA v2, planejamos usar previsões de tipo de problema no futuro para determinar a qual agente de suporte ao cliente rotear um determinado ticket, uma vez que esses agentes geralmente possuem conhecimento em um conjunto específico de tipos de problemas. Essas atualizações aumentarão nossa probabilidade de identificar o agente certo para resolver um ticket durante o primeiro roteamento, melhorando a eficiência de todo o sistema de suporte a tickets.

Também estamos analisando recursos que nos permitirão responder mais rapidamente a tickets que meramente solicitam informações, por exemplo, tickets que colocam perguntas como “como atualizo minha foto do perfil da Uber?” Para esses tickets, a solução é simplesmente compartilhar informações estáticas (instruções neste caso).

Isso pode ser apenas um pequeno subconjunto de alguns por cento de todos os tickets de suporte ao cliente, mas pode ser tratado automaticamente pelo COTA v2 sem a supervisão de um agente. A simplificação dessas respostas estáticas ajudará os clientes a economizar tempo e capacitar os agentes a se concentrarem em tickets mais desafiadores, proporcionando melhor atendimento ao cliente.

Se você estiver interessado em enfrentar os desafios de aprendizagem de máquina que geram impacto nos negócios em escala, considere a possibilidade de se candidatar a um cargo em nossas equipes de Engenharia de Obsessão do Cliente com base em São Francisco, Palo Alto ou Bangalore ou Aprendizagem de Máquina Aplicada, Michelangelo. Também estamos contratando gerentes de produto baseados em São Francisco, bem como analistas e cientistas de dados para nossa equipe de Obsessão do Cliente.

Assine nossa newsletter para acompanhar as mais recentes inovações da Engenharia da Uber.

***

Este artigo é do Uber Engineering. A tradução foi feita pela Redação iMasters com autorização. Você pode conferir o original em: https://eng.uber.com/cota-v2/