O aprendizado de máquina (ML) é amplamente utilizado em toda a plataforma Uber para suportar a tomada de decisão inteligente e a previsão de recursos como previsão de ETA e detecção de fraudes. Para melhores resultados, investimos muitos recursos no desenvolvimento de modelos preditivos precisos de ML.

Na verdade, é comum os praticantes/profissionais dedicarem 20 por cento de seus esforços na criação de modelos de trabalho iniciais e 80 por cento de seus esforços para melhorar o desempenho do modelo na chamada regra de divisão 20/80 do desenvolvimento do modelo ML.

Tradicionalmente, quando cientistas de dados desenvolvem modelos, eles avaliam cada candidato modelo usando escores resumidos como perda de log, área sob curva (AUC) e erro absoluto médio (MAE).

Embora essas métricas ofereçam insights sobre o desempenho de um modelo, elas não transmitem muitas informações sobre o motivo de um modelo não ter um bom desempenho e, a partir dele, como melhorar seu desempenho.

Como tal, os construtores de modelos tendem a confiar na tentativa e erro ao determinar como melhorar seus modelos.

Para tornar o processo de iteração do modelo mais informado e acionável, desenvolvemos o Manifold, ferramenta interna de visualização independente de modelo da Uber para diagnóstico de desempenho de ML e depuração de modelo.

Aproveitando as técnicas de análise visual, o Manifold permite que os praticantes de ML olhem além das métricas gerais de resumo para detectar qual subconjunto de dados um modelo está imprecisamente prevendo.

O Manifold também explica a possível causa do baixo desempenho do modelo ao exibir a diferença de distribuição de recursos entre subconjuntos de dados de melhor e de pior desempenho.

Além disso, ele pode exibir como vários modelos candidatos têm diferentes precisões de previsão para cada subconjunto de dados, fornecendo justificativa para tratamentos avançados, como o conjunto de modelos.

Neste artigo, discutimos o algoritmo e o design de visualização do Manifold, e também explicamos como a Uber aproveita a ferramenta para obter insights sobre seus modelos e melhorar o desempenho do modelo.

Motivação por trás do Manifold

Dada a sua complexidade, os modelos ML são intrinsecamente opacos. Como o ML se torna cada vez mais essencial para os negócios da Uber, precisamos equipar os usuários com ferramentas para tornar os modelos mais transparentes e fáceis de entender; somente então eles poderão usar previsões geradas pelo ML com confiança e segurança. A visualização ML, um domínio emergente, resolve esse problema.

Abordagens anteriores para a visualização do ML geralmente incluíam a visualização direta da estrutura interna ou dos parâmetros do modelo, um design restringido pelos algoritmos subjacentes e, portanto, não escalonável para lidar com casos de uso genéricos em toda a empresa.

Para enfrentar este desafio na Uber, construímos o Manifold para atender a maioria dos modelos de ML, começando com modelos de classificação e regressão. Também desenvolvemos o Manifold para oferecer transparência à caixa preta do desenvolvimento do modelo ML, apresentando diferenças de distribuição de recursos entre subconjuntos de dados.

Com o design da Manifold, transformamos o tradicional desafio de visualização do modelo ML em sua cabeça. Em vez de inspecionar os modelos, inspecionamos os pontos de dados individuais: (1) identificando os segmentos de dados que fazem um modelo funcionar bem ou mal e como esses dados afetam o desempenho entre os modelos e (2) avaliando as características dos recursos agregados desses segmentos de dados para identificar as razões de determinados comportamentos do modelo.

Essa abordagem facilita o agnosticismo/independência de modelo, uma característica particularmente útil quando se trata de identificar oportunidades para o conjunto de modelos.

Projeto de visualização e fluxo de trabalho

Além do protótipo de pesquisa construído em [4], nós nos concentramos em ressaltar sinais e padrões importantes em meio a conjuntos de dados de ML massivos e de alta dimensionalidade.

Nas seções a seguir, discutimos a interface do Manifold e o fluxo de trabalho do usuário, aprofundamos nossas considerações de design e explicamos os algoritmos que permitiam esse tipo de análise visual.

A interface do Manifold é composta por duas visualizações coordenadas:

• Visualização de comparação de desempenho, que consiste em um gráfico de várias vias com codificação de violino, compara o desempenho entre modelos e segmentos de dados.

• Visualização de atribuição de recurso, que consiste em dois conjuntos de histogramas de distribuição de recursos, compara os recursos de dois segmentos de dados selecionados.

O Manifold ajuda os usuários a descobrir áreas para melhoria de modelos por meio de três etapas:

Comparar: primeiro, dado um conjunto de dados com a saída de um ou mais modelos ML, o Manifold compara e destaca as diferenças de desempenho entre modelos ou subconjuntos de dados (Figura 3a.)

Fatiar: essa etapa permite que os usuários selecionem subconjuntos de dados de interesse com base no desempenho do modelo para inspeção adicional (Figura 3b.)

Atribuir: Manifold, em seguida, destaca as diferenças de distribuição de recursos entre os subconjuntos de dados selecionados, ajudando os usuários a encontrar as razões por trás dos resultados de desempenho (Figura 3c.)

Nosso objetivo com o Manifold é comparar o desempenho de diferentes modelos em vários pontos de dados (em outras palavras, valores de recursos). Como uma alternativa de design, uma implementação direta dessa visualização é mostrada na Figura 4, abaixo:

Na Figura 4, cada ponto no gráfico representa o desempenho do modelo x no ponto de dados y. Enquanto o conceito funciona em teoria, na prática existem três desafios principais com esta abordagem:

• Há muitos pontos na nuvem de pontos para identificar claramente os padrões; alguma abstração ou redução dos pontos é necessária para revelar padrões.
• É difícil identificar quais recursos são mais valiosos para o eixo y usar, a fim de identificar padrões relevantes na nuvem de pontos.
• Torna-se mais difícil comparar modelos diferentes à medida que o número de modelos aumenta.

Para abordar preventivamente esses problemas, implementamos a seguinte agregação/simplificação: em vez de representar cada ponto de dados separadamente, agrupamo-los em subconjuntos.

Em vez de usar o eixo y para codificar o valor de um recurso específico, transformamos o mesmo em um eixo categórico representando diferentes subconjuntos de dados.

Essa abordagem evoluiu para o nosso gráfico de desempenho final, levando a esses dois benefícios significativos:

• Os pontos de dados que são essencialmente semelhantes não serão duplicados no gráfico. Apenas as diferenças mais importantes e de alto nível são destacadas.
• Como o número de formas no gráfico é reduzido, modelos diferentes podem ser plotados no mesmo gráfico para fazer comparações melhores.

A chave para revelar padrões na visualização de Comparação de Desempenho da ferramenta era dividir o conjunto de dados de teste em subconjuntos. No Manifold, os subconjuntos são gerados automaticamente usando um algoritmo de clustering com base em uma ou mais colunas de desempenho.

Dessa forma, os dados com desempenho semelhante em relação a cada modelo são agrupados (porque o algoritmo garante o desempenho do Modelo X para diferentes pontos de dados no Subconjunto Y serem consistentes entre si). As figuras 5 e 6, abaixo, ilustram esse processo:

Arquitetura Manifold

Como a geração de visualizações do Manifold envolve alguns cálculos numéricos intensos (clustering, divergência de KL), o desempenho de computação abaixo da média diminui a renderização da interface do usuário e afeta a experiência geral do usuário.

Com isso em mente, começamos a implementar todos os cálculos pesados ​​em Python, utilizando seu processamento de DataFrame otimizado e bibliotecas ML (como Pandas e Scikit-Learn).

No entanto, ter que confiar em um backend Python tornou o Manifold menos ágil e mais difícil de se compor, o que se tornou uma desvantagem quando se tratou de integrar o Manifold ao maior ecossistema ML da Uber, por exemplo, nossa plataforma ML, Michelangelo.

Portanto, além da computação em Python, adicionamos um segundo caminho de fluxo de trabalho do usuário com aceleração de GPU totalmente escrita em JavaScript, uma linguagem muito mais ágil.

A Figura 7, abaixo, descreve como os dois fluxos de trabalho se integram ao Manifold:

Os usuários podem utilizar o Manifold de duas maneiras: por meio de um pacote Python ou de um pacote npm (por meio de uma página da Web). Como a reutilização e a modularidade do código são cruciais para a coexistência de dois fluxos de trabalho, as bases de código Python e JavaScript são organizadas em três módulos funcionais diferentes:

• Transformador de dados: recurso que adapta formatos de dados de outros serviços internos (por exemplo, Michelangelo) ao formato interno de representação de dados do Manifold.
• Mecanismo de computação: recurso responsável pela execução de clusters e outras computações com uso intensivo de dados
• Componentes de front-end: interface do usuário do sistema de análise visual do Manifold (seu pacote Python usa uma versão incorporada de componentes front-end de JavaScript)

Ao contrário da contraparte do Python, lidar com computação com uso intensivo de dados é um desafio para o nosso mecanismo de computação JavaScript. Para que os usuários vejam padrões significativos, são necessários cerca de 10.000 registros de dados (“linhas”).

O clustering e o cálculo da divergência de KL, entre outras ações, precisariam acontecer no front-end, o que poderia representar um gargalo na velocidade e prejudicar seriamente a experiência do usuário. Na verdade, com base em nossos experimentos, a computação/cálculo implementada em JavaScript simples pode levar mais de dez segundos no navegador toda vez que um usuário atualiza o número de clusters na visualização de comparação de desempenho.

Em vez disso, utilizamos o TensorFlow.js como uma biblioteca de utilitários de álgebra linear para implementar nossos cálculos de clustering de k-means e divergência de KL.

Como esse tipo de computação pode ser vetorizado e, portanto, acelerado usando o WebGL por meio do TensorFlow.js, a mesma tarefa de atualizar o número de clusters pode ser concluída em segundos – mais de 100x do desempenho original.

Sendo dividido em componentes e contido em um pacote npm, o Manifold oferece a flexibilidade de ser usado como um serviço autônomo, bem como integrado a outros sistemas ML de toda a empresa, como o Michelangelo.

Como a maioria das caixas de ferramentas de visualização para ML exigem processos de computação extra além do que está incluído no back-end de treinamento do modelo, integrá-los aos sistemas ML corporativos pode ser incômodo ou insatisfatório.

O Manifold propõe uma solução para essa situação, manipulando a computação necessária no sistema de análise visual separadamente das necessárias para os modelos de treinamento e, portanto, permitindo uma iteração mais rápida e uma interface de dados mais limpa.

Usando o Manifold na Uber

Equipes focadas em ML em toda a Uber alavancam o Manifold para tudo, desde a previsão de ETA até o melhor entendimento dos modelos de segurança do motorista. Abaixo, percorremos dois dos nossos casos de uso mais comuns: identificação de recursos úteis de modelos ML e eliminação de falsos negativos nos resultados do modelo. Nesses casos, o Manifold permite que os cientistas de dados descubram insights que os guiam através do processo de iteração do modelo.

Identificando recursos úteis

A equipe da Uber Eats usou o Manifold para avaliar os efeitos de um novo modelo que prevê o tempo de entrega do pedido. Durante a iteração do modelo, eles integraram um conjunto extra de recursos que eles achavam que tinham o potencial de melhorar o desempenho do modelo existente.

No entanto, depois de incorporar esses recursos, o desempenho geral do modelo foi pouco alterado. Por que os novos recursos não estavam ajudando? Eles deveriam desistir da ideia de usar esses recursos ou havia algo mais para culpar por esse desempenho abaixo da média?

Para responder a essas perguntas, eles usaram os modelos descritos na Figura 8, abaixo – um modelo original (verde) e um modelo treinado com recursos extras (laranja) – como entradas para o Manifold. Todos os outros aspectos desses dois modelos eram idênticos.

A Figura 8, acima, descreve essa análise como representada pelas visualizações de dados do Manifold. Conforme descrito, o conjunto de dados de teste foi segmentado automaticamente em quatro clusters com base na semelhança de desempenho entre os pontos de dados.

Para os Clusters 0, 1 e 2, o modelo com recursos adicionais não forneceu melhoria de desempenho. No entanto, o desempenho do novo modelo (aquele com recursos extras) foi um pouco melhor no Cluster 3, conforme indicado por uma perda de log deslocada para a esquerda.

Já que o segmento de dados no Cluster 3 foi mal previsto pelo modelo original, (conforme indicado pelo seu maior valor de perda de log do que os de outros clusters), acreditamos que os recursos foram valiosos para seu modelo, pois eles pareciam lidar com alguns dos casos individuais mais difíceis, como aqueles representados no Cluster 3.

Eliminando falsos negativos

Em um exemplo diferente, a equipe de Segurança da Uber usou o Manifold para melhorar o desempenho de um modelo de classificação binária que identifica viagens que podem incorrer em incidentes de segurança.

Especificamente, eles queriam eliminar o número de falsos negativos que foram gerados por seu modelo (instâncias que devem ser previstas como tendo um rótulo Positivo, mas o modelo não conseguiu capturar) e, para isso, precisavam determinar o motivo pelo qual seu modelo preveria uma instância Positiva como Negativa nessas situações.

Para atingir esse objetivo, eles filtraram todas as instâncias de um conjunto de dados de teste rotulado como Negativo e compararam as diferenças entre os casos rotulados como Positivo. Eles definiram a métrica do eixo x do gráfico de Comparação de Desempenho como “escore de previsão real” (1), aumentaram o número de clusters (2) e compararam os subconjuntos cujos valores estão abaixo e acima do limite de decisão (3), conforme representado na Figura 9, abaixo:

Como resultado, notamos que havia vários recursos (A, B, C, D, E) mostrando diferenças de distribuição notáveis ​​entre o grupo verdadeiro positivo (cinza) e o grupo falso negativo (rosa), mostrado na Figura 10, abaixo.

Em outras palavras, se um ponto de dados tiver valores baixos nos recursos A, B, C ou D e seu rótulo verdadeiro for Positivo, o modelo tenderá a não prever o valor E corretamente.

Para aprofundar ainda mais na causa raiz desses falsos negativos, comparamos diretamente as distribuições de recursos do grupo Positivo e do grupo Negativo, conforme ilustrado na Figura 11, abaixo:

Observamos que a maioria das instâncias Negativas verdadeiras também tendem a ter valores baixos nos recursos A, B, C ou D. Portanto, se uma instância tiver valores baixos nesses recursos, o modelo tende a prevê-los como negativos (o que às vezes é errado!).

Depois de conduzir essa análise com o Manifold, eles perceberam que o modelo estava superindexando esses recursos. Para melhorar o desempenho, eles poderiam encontrar mais recursos que poderiam ajudar a distinguir os negativos falsos dos negativos verdadeiros ou treinar um modelo separado para a partição de dados em que esses recursos estivessem abaixo de um determinado limite.

Próximos passos

Desde o lançamento do Manifold em agosto de 2018, a ferramenta se tornou parte integrante do processo de desenvolvimento do modelo ML da Uber. Os três principais benefícios do Manifold incluem: agnosticismo/independência de modelo, analítica visual para avaliação de desempenho de modelo que analise além das estatísticas de resumo de desempenho de modelo para imprecisões e a capacidade de para separar computações de sistema de análise visual e de modelo padrão para facilitar o desenvolvimento de modelo mais rápido e flexível.

Atualmente, o Manifold é uma ferramenta da web autônoma e um pacote Python. Para aumentar a funcionalidade do Manifold, planejamos integrar a caixa de ferramentas do Manifold à miríade de inúmeras plataformas de ciência de dados, estabelecendo ainda mais a ferramenta como parte essencial de nosso fluxo de trabalho de ciência de dados mais amplo.

Ao fazer isso, poderemos realmente aumentar o potencial do agnosticismo de dados do Manifold contra vários cenários de uso da ciência de dados em toda a empresa. A partir daí, pretendemos fazer melhorias no design com base nesses aplicativos, permitindo um suporte mais robusto desses casos de uso.

Se lidar com problemas de engenharia em grande escala com aprendizagem de máquina e visualização de dados lhe interessa, considere se candidatar a um papel em nossa equipe!

Referências

• M. Kahng, PY Andrews, A. Kalro e DH Chau, “ActiVis: Exploração Visual de Modelos de Rede Neural Profunda em Escala da Indústria”, em IEEE Transactions on Visualization and Computer Graphics , vol.24, não. 1, pp. 88-97, janeiro de 2018.
• Y. Ming, S. Cao, R. Zhang, Z. Li, Y. Chen, Y. Song e H. Qu. Compreender memórias ocultas de redes neurais recorrentes. arXiv preprint arXiv: 1710.10777 , 2017.
• L. Padua, H. Schulze, K. Matkovic e C. Delrieux. Exploração interativa do espaço de parâmetros na mineração de dados: Compreender a qualidade preditiva de grandes coleções de árvores de decisão. Computadores e Gráficos, 41: 99–113, 2014.
• J. Zhang, Y. Wang, P. Molino, L. Li e DS Ebert, “Manifold: Uma Estrutura Modelo Agnóstica para Interpretação e Diagnóstico de Modelos de Aprendizado de Máquina”, em IEEE Transactions on Visualization and Computer Graphics , vol. 25, não. 1, pp. 364-373, janeiro de 2019.

***

Este artigo é do Uber Engineering. Ele foi escrito por Lezhi Li e Yang Wang. A tradução foi feita pela Redação iMasters com autorização. Você pode conferir o original em: https://eng.uber.com/manifold/