O aprendizado de máquina (ML) se tornou um dos recursos mais críticos para as empresas modernas crescerem e se manterem competitivas hoje. Desde a automação de processos internos até a otimização dos processos de design, criação e marketing por trás de praticamente todos os produtos consumidos, os modelos de ML permearam quase todos os aspectos de nosso trabalho e vida pessoal – e para as empresas, os riscos nunca foram tão altos. Deixar de adotar o ML como competência central resultará em grandes desvantagens competitivas que definirão os próximos líderes de mercado.
Por isso, os líderes de negócios e tecnologia precisam implementar modelos de ML em toda a organização, abrangendo um amplo espectro de casos de uso. No entanto, esse senso de urgência, combinado com o crescente escrutínio regulatório, cria novos e únicos desafios de governança que atualmente são difíceis de gerenciar. Por exemplo:Como meus modelos estão impactando os serviços prestados aos clientes finais? Ainda estou em conformidade com os regulamentos governamentais e internos? Como minhas regras de segurança serão traduzidas para modelos em produção?
Além das preocupações regulatórias ou legais, há vários motivos para ter processos e procedimentos de governança para Machine Learning. Os exemplos incluem maneiras de aumentar a produtividade (como reutilizar ativos como modelos e recursos), controlar e manter modelos em muitas linhas de negócios diferentes para garantir que os aplicativos essenciais aos negócios estejam fazendo o que deveriam fazer (ou encontrando aqueles que não estão) e ver um histórico de modelos e previsões, incluindo ativos obsoletos.
Ao enfrentar esses desafios, vale a pena definir quais modelos e recursos são conceitualmente (veja a Figura 1). Existem muitas definições diferentes, mas geralmente um modelo é qualquer pacote independente que usa recursos calculados a partir de dados de entrada e produz uma previsão (ou pontuação) e metadados. Este pacote pode assumir várias formas, mas sempre inclui uma representação matemática, código, lógica de negócios e dados de treinamento. As previsões do modelo são consumidas a jusante por sistemas ou usuários.
Muitas empresas operam a infraestrutura do modelo de ML em diferentes tamanhos e maturidades que exigem ferramentas para ajudá-las a controlar seus modelos. Em última análise, as necessidades de governança de ML podem ser destiladas nas seguintes áreas principais:visibilidade; e explicabilidade do modelo, interpretabilidade e reprodutibilidade.
figura 1
Visibilidade de modelos e recursos dentro de equipes e entre organizações
Um requisito básico para a governança de modelos é permitir que as equipes entendam como o aprendizado de máquina está sendo aplicado em suas organizações. Isso requer um catálogo canônico de modelos e recursos. Na ausência de tal catálogo, muitas organizações desconhecem seus modelos e recursos, onde são implantados, o que estão fazendo etc. Isso leva ao retrabalho, inconsistência do modelo, recursos de recálculo e outras ineficiências.
Explicabilidade, interpretabilidade e reprodutibilidade do modelo
Os modelos são frequentemente vistos como uma caixa preta:os dados entram, algo acontece e uma previsão sai. Essa falta de transparência é um desafio em vários níveis e geralmente é representada em termos vagamente relacionados, como:
- Explicabilidade :descrição da mecânica interna de um modelo de ML em termos humanos
- Interpretibilidade :a capacidade de a) entender a relação entre entradas, recursos e saídas do modelo eb) prever a resposta a mudanças nas entradas.
- Reprodutibilidade :a capacidade de reproduzir a saída de um modelo de maneira consistente para as mesmas entradas.
Todos eles exigem funcionalidade comum, incluindo um vínculo com os dados de origem, uma compreensão clara dos componentes internos dos modelos, como código e dados de treinamento, e outros métodos para sondar e analisar os próprios modelos.
Modele metadados com um exemplo
Para abordar os problemas de governança definidos acima, vamos começar pensando em um exemplo. Considere um site de entrega de comida. A empresa quer aproveitar o aprendizado de máquina para estimar o tempo de entrega.
O conjunto de dados de treinamento consiste nos logs de eventos de entregas anteriores, que contêm os tempos de entrega para cada entrega feita no passado. Esses dados são usados para treinar um modelo para estimar prazos de entrega futuros.
Um log de eventos pode ser algo assim:
Um pedido foi feito às 10h para que a comida fosse retirada do local1 e entregue no local2. O correio pegou no restaurante às 10h15 e entregou às 10h55, levando um total de 55 minutos desde o pedido até a entrega
Suponha que loc1 e loc2 sejam endereços de rua. Este é abreviado aqui para mantê-lo curto e fácil de ler.
Os logs de eventos são armazenados no HBase. A arquitetura de engenharia para o desenvolvimento do modelo é a seguinte:
- Os engenheiros de dados identificam a janela de tempo dos logs de eventos a serem usados para resolver o problema. Uma nova tabela estruturada do Hive é criada analisando os logs de eventos brutos com a janela de tempo identificada.
- Os engenheiros de recursos (essa pode ser uma função de cientistas de dados ou engenheiros de ML) identificam e desenvolvem novos recursos:
- Recurso de hora do rush:uma função para identificar se existem condições de hora do rush em um local e um horário.
- Recurso de "ocupação" do restaurante:uma função para identificar se um determinado restaurante está enfrentando altos tempos de espera com base em dados históricos. Esses dados históricos são coletados separadamente.
- Os recursos identificados acima são construídos como uma biblioteca python para reutilização.
- Esta biblioteca é usada para aplicar a função à tabela Hive estruturada para criar uma nova tabela que será o conjunto de dados de treinamento final. Uma linha na nova tabela tem esta aparência:
Suponha que loc1 e loc2 sejam endereços de rua. Este é abreviado aqui para mantê-lo curto e fácil de ler.
- Os cientistas de dados executam uma regressão linear no conjunto de dados de treinamento para prever o tempo de entrega. Nesse ponto, eles precisam usar a mesma biblioteca de recursos usada para extrair os recursos do conjunto de dados de treinamento.
- O modelo é implantado como um endpoint Function-as-a-Service (FaaS) usado pelo aplicativo da Web para prever o tempo de entrega.
Observe que o modelo precisa calcular os recursos para previsão em tempo real. Esses recursos são bibliotecas usadas internamente pelo modelo. Uma visualização das várias atividades executadas e artefatos gerados neste exemplo pode ter esta aparência:
As caixas azuis representam entidades ML (substantivos) como código, projeto, builds, deployments, etc. As caixas verdes representam processos (verbos) que atuam sobre entidades e produzem outras entidades.
A visualização e os relacionamentos que definem as transformações na estrutura dos dados são denominados coletivamente como linhagem . No mundo do banco de dados, adicionar uma nova coluna a uma tabela modificará sua linhagem. No mundo do aprendizado de máquina, retreinar um modelo consumindo recursos e conjuntos de dados modificará a linhagem. Para o site de entrega de alimentos, para responder à pergunta:“existe diferença entre a extração de recursos durante o treinamento e a pontuação”, precisamos das informações da linhagem. Este é apenas um exemplo da utilidade dos metadados de linhagem no mundo do aprendizado de máquina.
Apache Atlas como ferramenta de governança
É evidente que construir uma linhagem completa de ponta a ponta para fluxos de trabalho de ML — desde conjuntos de dados de treinamento até implantações de modelos — se torna um requisito fundamental para resolver os problemas de governança identificados. A integração de gerenciamento de dados e aprendizado de máquina deve permitir explicabilidade, interpretabilidade e reprodutibilidade.
A coleta, o armazenamento e a visualização de metadados de ML precisam de um sistema de software de back-end padrão. Uma definição de metadados aberta e extensível permitirá a padronização das operações de governança, independentemente de onde os modelos são desenvolvidos ou atendidos. O candidato óbvio para Cloudera (e nossos clientes) é o Apache Atlas.
O Apache Atlas já é um conjunto de ferramentas de governança amplamente utilizadas com tipos de metadados predefinidos para gerenciamento de dados. No contexto da governança de ML, é adequado para definir e capturar os metadados necessários para conceitos de aprendizado de máquina. Além disso, o Apache Atlas fornece recursos avançados, como classificações, integração com o Apache Ranger (para autorização e marcação), para citar alguns, e possui um sistema de complementos extensível que permite que a comunidade colabore e defina incrementalmente integrações com várias outras ferramentas no ML espaço. Fica como exercício para o leitor explorar a interface do usuário do Apache Atlas e ver como usar esses recursos.
Definição de metadados de ML no Apache Atlas
O Apache Atlas Type System atende a todas as nossas necessidades para definir objetos de metadados de ML. É de código aberto, extensível e possui recursos de governança pré-criados. Um Tipo no Atlas é uma definição de como um determinado tipo de objeto de metadados é armazenado e acessado. Também representa um ou mais atributos que definem as propriedades do objeto de metadados. Para governança de ML, o Atlas Type System pode ser usado para definir novos Tipos, capturando entidades e processos de ML como objetos de metadados do Atlas. Além da definição dos Tipos, o relacionamento entre as entidades e os processos também é necessário para visualizar o fluxo de linhagem de ponta a ponta.
Se relacionarmos isso com o exemplo de site de entrega de alimentos descrito anteriormente, o Atlas Type System fornece uma boa base para definir a linhagem de Machine Learning. Um sistema de linhagem de ML generalizado é visualizado da seguinte forma:
Como fica evidente no diagrama acima, a Definição de Metadados para aprendizado de máquina segue de perto o fluxo de trabalho de aprendizado de máquina real. Os conjuntos de dados de treinamento são o ponto de partida para um fluxo de linhagem de modelo. Esses conjuntos de dados podem ser tabelas de um data warehouse ou um arquivo csv integrado. Depois que um conjunto de dados é identificado, a linhagem segue para o treinamento, construção e implantação do modelo.
O desenvolvimento de recursos de ML é uma atividade paralela e especializada que pode ser denominada engenharia de recursos (diferente da engenharia de modelos). Hoje, em muitos casos, as duas atividades (engenharia de modelos e engenharia de recursos) são realizadas pela mesma pessoa ou equipe. Com a democratização e industrialização dos recursos, isso pode mudar no futuro, com equipes especializadas para desenvolvimento de modelos e desenvolvimento de recursos.
O sistema de tipos de ML agora pode ser definido através dos seguintes novos tipos:
"Criar projeto de aprendizado de máquina" e "Projeto de aprendizado de máquina"
Um único projeto de aprendizado de máquina representa um único caso de uso de negócios. O projeto de aprendizado de máquina representa o contêiner de arquivos e outros ativos incorporados. No mínimo, os metadados do projeto contêm:
- Lista de arquivos usados no modelo
- Versão histórica de todos os arquivos
- A implementação mais simples seria manter o projeto como um repositório git contando com o Git para manter o histórico de todos os arquivos.
"Conjunto de dados de treinamento"
Um subtipo de um DataSet no Atlas que representa um conjunto de dados de treinamento. A entidade Training Data Set é usada no processo de treinamento do modelo. Ele pode ser associado a um recurso se os dados gerados forem o resultado da aplicação de extração de recursos (ou transformação) a outro conjunto de dados.
"Treinar e construir"
Um processo que representa a ação de treinar e construir um modelo. Inclui a execução de experimentos, ajuste e finalização da escolha de um algoritmo de treinamento. O Processo de Treinar e Construir pode, opcionalmente, consumir a saída de uma Construção de Recurso; por exemplo, uma função de biblioteca que define a extração de recursos usada internamente pelo modelo.
“Construção do modelo”
O modelo é reforçado e versionado quando um cientista de dados termina de experimentar e treinar o modelo. Esse processamento resulta em um Model Build, que é um artefato imutável que forma o bloco de construção para a produção de modelos. Uma imagem do Docker é um exemplo de uma entidade Model Build.
"Implantar modelo" e "Implantar modelo"
Uma compilação de modelo passa por um processo de implantação, que cria uma implantação de modelo. A implantação do modelo representa uma instanciação ativa de um modelo. Um serviço REST baseado em Kubernetes (implantação no estilo FaaS) é um exemplo de uma entidade Model Deployment.
“Função de recurso”
Um recurso de aprendizado de máquina tem duas interpretações:1) Função de recurso e 2) Conjunto de dados transformado.
A entidade Feature Function é uma função personalizada (expressa em código) que define como extrair um recurso identificado de uma entrada. Isso representa o código para recursos, semelhante a como o ML Project representa o contêiner para o código ML.
A Função de Recurso é empacotada primeiro como uma biblioteca (com versão e reforçada). A biblioteca é então consumida e aplicada em um determinado DataSet para transformá-lo em um novo DataSet (com os recursos extraídos). O Conjunto de Dados Transformado é representado pela entidade Conjunto de Dados de Treinamento definida acima.
"Recurso de pacote" e "Criação de recurso"
O código na Função de Recurso é empacotado para compartilhamento (com outros modelos) ou para pontuação de tempo de execução. Esses pacotes são chamados de compilações de recursos. Por exemplo, um Feature Build pode conter uma biblioteca empacotada (em python) ou um arquivo jar (em Java). Esse pacote pode ser absorvido durante o processo de treinamento e construção do modelo para garantir que o mesmo recurso seja usado durante a extração e a previsão.
Experimente e envolva-se na definição do futuro da definição de metadados de ML
Começamos a trabalhar no ATLAS-3432, que é a primeira implementação do Machine Learning Type System aproveitando o Cloudera Data Science Workbench (CDSW) como cliente piloto. Agradecemos a Na Li da equipe de engenharia da Cloudera por liderar o trabalho de construção da integração do CDSW. O ATLAS-3432 permitirá que os metadados do modelo de uma instância CDSW sejam enviados para uma instância Apache Atlas para explorar a linhagem. Atualmente, o CDSW não suporta recursos (ou uma loja de recursos) e, portanto, a linhagem relacionada aos recursos não estará disponível.
Na Cloudera, não queremos simplesmente resolver esse problema para nossos clientes - acreditamos que as definições de metadados de ML devem ser universais, semelhantes a como tabelas, colunas etc. são muito padrão para estruturas de dados. Esperamos que as comunidades contribuam para definir esse padrão para ajudar as empresas a aproveitar ao máximo suas plataformas de ML.
Você tem um caso de uso de governança de aprendizado de máquina que não se encaixa no modelo de metadados? Participe da conversa postando suas sugestões para [email protected].
