Pré-processamento de dados para ML: opções e recomendações

Este documento é o primeiro de uma série de duas partes que explora o tópico de engenharia de dados e engenharia de recursos para aprendizado de máquina (ML), com foco em tarefas de aprendizado supervisionado. Esta primeira parte discute as práticas recomendadas para pré-processamento de dados em um pipeline de ML no Google Cloud. O documento se concentra no uso do TensorFlow e da biblioteca de código aberto TensorFlow Transform ( tf.Transform ) para preparar dados, treinar o modelo e servir o modelo para previsão. Este documento destaca os desafios do pré-processamento de dados para ML e descreve as opções e cenários para realizar a transformação de dados no Google Cloud de maneira eficaz.

Este documento pressupõe que você esteja familiarizado com BigQuery , Dataflow , Vertex AI e a API TensorFlow Keras .

O segundo documento, Pré-processamento de dados para ML com Google Cloud , fornece um tutorial passo a passo sobre como implementar um pipeline tf.Transform .

Introdução

O ML ajuda você a encontrar automaticamente padrões complexos e potencialmente úteis nos dados. Esses padrões são condensados ​​em um modelo de ML que pode então ser usado em novos pontos de dados – um processo chamado de fazer previsões ou realizar inferências .

Construir um modelo de ML é um processo de várias etapas. Cada etapa apresenta seus próprios desafios técnicos e conceituais. Esta série de duas partes concentra-se em tarefas de aprendizagem supervisionada e no processo de seleção, transformação e aumento dos dados de origem para criar sinais preditivos poderosos para a variável de destino. Essas operações combinam conhecimento do domínio com técnicas de ciência de dados. As operações são a essência da engenharia de recursos .

O tamanho dos conjuntos de dados de treinamento para modelos de ML do mundo real pode facilmente ser igual ou superior a um terabyte (TB). Portanto, são necessárias estruturas de processamento de dados em grande escala para processar esses conjuntos de dados de forma eficiente e distribuída. Ao usar um modelo de ML para fazer previsões, você deve aplicar as mesmas transformações usadas para os dados de treinamento nos novos pontos de dados. Ao aplicar as mesmas transformações, você apresenta o conjunto de dados dinâmico ao modelo de ML da maneira que o modelo espera.

Este documento discute esses desafios para diferentes níveis de granularidade das operações de engenharia de recursos: agregações em nível de instância, passagem completa e janela de tempo. Este documento também descreve as opções e cenários para realizar a transformação de dados para ML no Google Cloud.

Este documento também fornece uma visão geral do TensorFlow Transform ( tf.Transform ), uma biblioteca do TensorFlow que permite definir a transformação de dados em nível de instância e de passagem completa por meio de pipelines de pré-processamento de dados. Esses pipelines são executados com Apache Beam e criam artefatos que permitem aplicar as mesmas transformações durante a previsão como quando o modelo é servido.

Pré-processamento de dados para ML

Esta seção apresenta operações de pré-processamento de dados e estágios de preparação de dados. Também discute os tipos de operações de pré-processamento e sua granularidade.

Engenharia de dados comparada à engenharia de recursos

O pré-processamento dos dados para ML envolve engenharia de dados e engenharia de recursos. Engenharia de dados é o processo de conversão de dados brutos em dados preparados . A engenharia de recursos então ajusta os dados preparados para criar os recursos esperados pelo modelo de ML. Esses termos têm os seguintes significados:

Dados brutos (ou apenas dados )

Os dados na sua forma original, sem qualquer preparação prévia para ML. Neste contexto, os dados podem estar na sua forma bruta (num data lake) ou numa forma transformada (num data warehouse). Os dados transformados que estão em um data warehouse podem ter sido convertidos de sua forma bruta original para serem usados ​​em análises. No entanto, neste contexto, dados brutos significam que os dados não foram preparados especificamente para a sua tarefa de ML. Os dados também são considerados dados brutos se forem enviados de sistemas de streaming que eventualmente chamam modelos de ML para previsões.

Dados preparados

O conjunto de dados no formato pronto para sua tarefa de ML: as fontes de dados foram analisadas, unidas e colocadas em um formato tabular. Os dados preparados são agregados e resumidos com a granularidade correta – por exemplo, cada linha no conjunto de dados representa um cliente único e cada coluna representa informações resumidas do cliente, como o total gasto nas últimas seis semanas. Em uma tabela de dados preparada, colunas irrelevantes foram eliminadas e registros inválidos foram filtrados. Para tarefas de aprendizagem supervisionada, o recurso alvo está presente.

Recursos projetados

O conjunto de dados com os recursos ajustados esperados pelo modelo, ou seja, recursos criados pela execução de determinadas operações específicas de ML nas colunas do conjunto de dados preparado e pela criação de novos recursos para seu modelo durante o treinamento e a previsão, conforme descrito posteriormente. em Operações de pré-processamento . Exemplos dessas operações incluem dimensionamento de colunas numéricas para um valor entre 0 e 1, valores de recorte e recursos categóricos de codificação one-hot .

O diagrama a seguir, figura 1, mostra as etapas envolvidas na preparação de dados pré-processados:

Na prática, os dados da mesma fonte estão frequentemente em diferentes estágios de preparação. Por exemplo, um campo de uma tabela no seu data warehouse pode ser usado diretamente como um recurso de engenharia. Ao mesmo tempo, outro campo na mesma tabela pode precisar passar por transformações antes de se tornar um recurso de engenharia. Da mesma forma, as operações de engenharia de dados e engenharia de recursos podem ser combinadas na mesma etapa de pré-processamento de dados.

Operações de pré-processamento

O pré-processamento de dados inclui várias operações. Cada operação é projetada para ajudar o ML a construir modelos preditivos melhores. Os detalhes destas operações de pré-processamento estão fora do escopo deste documento, mas algumas operações são brevemente descritas nesta seção.

Para dados estruturados, as operações de pré-processamento de dados incluem o seguinte:

• Limpeza de dados: remoção ou correção de registros que possuem valores corrompidos ou inválidos de dados brutos e remoção de registros que estão faltando um grande número de colunas.
• Seleção e particionamento de instâncias: seleção de pontos de dados do conjunto de dados de entrada para criar conjuntos de treinamento, avaliação (validação) e teste . Este processo inclui técnicas para amostragem aleatória repetível, sobreamostragem de classes minoritárias e particionamento estratificado.
• Ajuste de recursos: melhorar a qualidade de um recurso para ML, que inclui dimensionamento e normalização de valores numéricos, imputação de valores ausentes, recorte de valores discrepantes e ajuste de valores com distribuições distorcidas.
• Transformação de recursos: conversão de um recurso numérico em um recurso categórico (por meio de bucketização ) e conversão de recursos categóricos em uma representação numérica (por meio de codificação one-hot, aprendizado com contagens , incorporação de recursos esparsos, etc.). Alguns modelos funcionam apenas com recursos numéricos ou categóricos, enquanto outros podem lidar com recursos de tipos mistos. Mesmo quando os modelos lidam com ambos os tipos, eles podem se beneficiar de diferentes representações (numéricas e categóricas) do mesmo recurso.
• Extração de recursos: reduzindo o número de recursos criando representações de dados mais poderosas e de menor dimensão usando técnicas como PCA , extração de incorporação e hashing .
• Seleção de recursos: selecionar um subconjunto de recursos de entrada para treinar o modelo e ignorar os irrelevantes ou redundantes, usando métodos de filtro ou wrapper . A seleção de recursos também pode envolver a simples eliminação de recursos se os recursos estiverem faltando um grande número de valores.
• Construção de recursos: criação de novos recursos usando técnicas típicas, como expansão polinomial (usando funções matemáticas univariadas) ou cruzamento de recursos (para capturar interações de recursos). Os recursos também podem ser construídos usando a lógica de negócios do domínio do caso de uso de ML.

Quando você trabalha com dados não estruturados (por exemplo, imagens, áudio ou documentos de texto), o aprendizado profundo substitui a engenharia de recursos baseada em conhecimento de domínio, integrando-os à arquitetura do modelo. Uma camada convolucional é um pré-processador automático de recursos. Construir a arquitetura do modelo correto requer algum conhecimento empírico dos dados. Além disso, é necessária alguma quantidade de pré-processamento, como o seguinte:

• Para documentos de texto: lematização e lematização , cálculo TF-IDF e extração de n-gramas , pesquisa de incorporação.
• Para imagens: recorte, redimensionamento, corte, desfoque gaussiano e filtros canário.
• Para todos os tipos de dados (incluindo texto e imagens): transferência de aprendizagem , que trata todas as últimas camadas do modelo totalmente treinado como uma etapa de engenharia de recursos.

Granularidade de pré-processamento

Esta seção discute a granularidade dos tipos de transformações de dados. Ele mostra por que essa perspectiva é crítica ao preparar novos pontos de dados para previsões usando transformações aplicadas em dados de treinamento.

As operações de pré-processamento e transformação podem ser categorizadas da seguinte forma, com base na granularidade da operação:

• Transformações em nível de instância durante treinamento e previsão . Estas são transformações simples, onde apenas valores da mesma instância são necessários para a transformação. Por exemplo, as transformações em nível de instância podem incluir o recorte do valor de um recurso para algum limite, a expansão polinomial de outro recurso, a multiplicação de dois recursos ou a comparação de dois recursos para criar um sinalizador booleano.

  Essas transformações devem ser aplicadas de forma idêntica durante o treinamento e a previsão, porque o modelo será treinado nos recursos transformados, não nos valores brutos de entrada. Se os dados não forem transformados de forma idêntica, o modelo se comportará mal porque serão apresentados dados que possuem uma distribuição de valores com os quais não foi treinado. Para obter mais informações, consulte a discussão sobre distorção de serviço de treinamento na seção Desafios de pré-processamento .

• Transformações de passagem completa durante o treinamento, mas transformações em nível de instância durante a previsão . Neste cenário, as transformações têm estado, porque utilizam algumas estatísticas pré-computadas para realizar a transformação. Durante o treinamento, você analisa todo o corpo de dados de treinamento para calcular quantidades como mínimo, máximo, média e variância para transformar dados de treinamento, dados de avaliação e novos dados no momento da previsão.

  Por exemplo, para normalizar um recurso numérico para treinamento, você calcula sua média (μ) e seu desvio padrão (σ) em todos os dados de treinamento. Este cálculo é chamado de operação de passagem completa (ou análise ). Quando você fornece o modelo para previsão, o valor de um novo ponto de dados é normalizado para evitar distorções no fornecimento de treinamento. Portanto, os valores μ e σ calculados durante o treinamento são usados ​​para ajustar o valor do recurso, que é a seguinte operação simples em nível de instância :

  $$ value_{scaled} = (value_{raw} - \mu) \div \sigma $$

  As transformações de passagem completa incluem o seguinte:

  • Recursos numéricos de escalonamento MinMax usando mínimo e máximo calculados a partir do conjunto de dados de treinamento.
  • Recursos numéricos de escalonamento padrão (normalização de pontuação z) usando μ e σ calculados no conjunto de dados de treinamento.
  • Bucketização de recursos numéricos usando quantis.
  • Imputação de valores faltantes usando a mediana (características numéricas) ou a moda (características categóricas).
  • Converter strings (valores nominais) em inteiros (índices) extraindo todos os valores distintos (vocabulário) de um recurso categórico de entrada.
  • Contagem da ocorrência de um termo (valor do recurso) em todos os documentos (instâncias) para cálculo do TF-IDF.
  • Calculando o PCA dos recursos de entrada para projetar os dados em um espaço dimensional inferior (com recursos linearmente dependentes).

  Você deve usar apenas os dados de treinamento para calcular estatísticas como μ, σ, min e max . Se você adicionar os dados de teste e avaliação para essas operações, estará vazando informações dos dados de avaliação e teste para treinar o modelo. Isso afeta a confiabilidade dos resultados do teste e da avaliação. Para garantir que você aplique uma transformação consistente a todos os conjuntos de dados, use as mesmas estatísticas calculadas a partir dos dados de treinamento para transformar os dados de teste e avaliação.

• Agregações históricas durante treinamento e previsão . Isso envolve a criação de agregações, derivações e sinalizadores de negócios como sinais de entrada para a tarefa de previsão – por exemplo, criação de métricas de atualidade, frequência e monetárias (RFM) para que os clientes construam modelos de propensão. Esses tipos de recursos podem ser pré-computados e armazenados em um armazenamento de recursos para serem usados ​​durante o treinamento do modelo, pontuação em lote e serviço de previsão on-line. Você também pode realizar engenharia de recursos adicionais (por exemplo, transformação e ajuste) nessas agregações antes do treinamento e da previsão.

• Agregações históricas durante o treinamento, mas agregações em tempo real durante a previsão . Essa abordagem envolve a criação de um recurso resumindo valores em tempo real ao longo do tempo. Nesta abordagem, as instâncias a serem agregadas são definidas através de cláusulas de janela temporal. Por exemplo, você pode usar essa abordagem se quiser treinar um modelo que estime o tempo de viagem de táxi com base nas métricas de tráfego da rota nos últimos 5 minutos, nos últimos 10 minutos, nos últimos 30 minutos e em outras ocasiões. intervalos. Você também pode usar essa abordagem para prever a falha de uma peça do motor com base na média móvel dos valores de temperatura e vibração calculados nos últimos 3 minutos. Embora essas agregações possam ser preparadas off-line para treinamento, elas são computadas em tempo real a partir de um fluxo de dados durante o serviço.

  Mais precisamente, quando você prepara dados de treinamento, se o valor agregado não estiver nos dados brutos, o valor será criado durante a fase de engenharia de dados. Os dados brutos geralmente são armazenados em um banco de dados com formato (entity, timestamp, value) . Nos exemplos anteriores, entity é o identificador do segmento de rota para as rotas de táxi e o identificador da peça do motor para a falha do motor. Você pode usar operações de janelamento para calcular (entity, time_index, aggregated_value_over_time_window) e usar os recursos de agregação como entrada para o treinamento do seu modelo.

  Quando o modelo para previsão em tempo real (online) é servido, o modelo espera recursos derivados dos valores agregados como entrada. Portanto, você pode usar uma tecnologia de processamento de fluxo como o Apache Beam para calcular as agregações dos pontos de dados em tempo real transmitidos para o seu sistema. A tecnologia de processamento de fluxo agrega dados em tempo real com base em janelas de tempo à medida que novos pontos de dados chegam. Você também pode realizar engenharia de recursos adicionais (por exemplo, transformação e ajuste) nessas agregações antes do treinamento e da previsão.

Pipeline de ML no Google Cloud

Esta seção discute os principais componentes de um pipeline típico de ponta a ponta para treinar e fornecer modelos do TensorFlow ML no Google Cloud usando serviços gerenciados. Ele também discute onde você pode implementar diferentes categorias de operações de pré-processamento de dados e desafios comuns que você pode enfrentar ao implementar tais transformações. A seção Como funciona o tf.Transform mostra como a biblioteca TensorFlow Transform ajuda a enfrentar esses desafios.

Arquitetura de alto nível

O diagrama a seguir, figura 2, mostra uma arquitetura de alto nível de um pipeline de ML típico para treinar e servir modelos do TensorFlow. Os rótulos A, B e C no diagrama referem-se aos diferentes locais do pipeline onde o pré-processamento de dados pode ocorrer. Detalhes sobre essas etapas são fornecidos na seção a seguir.

O pipeline consiste nas seguintes etapas:

1. Depois que os dados brutos são importados, os dados tabulares são armazenados no BigQuery, e outros dados, como imagens, áudio e vídeo, são armazenados no Cloud Storage. A segunda parte desta série usa dados tabulares armazenados no BigQuery como exemplo.
2. A engenharia de dados (preparação) e a engenharia de recursos são executadas em escala usando o Dataflow. Essa execução produz conjuntos de treinamento, avaliação e teste prontos para ML que são armazenados no Cloud Storage. Idealmente, esses conjuntos de dados são armazenados como arquivos TFRecord , que é o formato otimizado para cálculos do TensorFlow.
3. Um pacote de treinamento de modelo do TensorFlow é enviado ao Vertex AI Training, que usa os dados pré-processados ​​das etapas anteriores para treinar o modelo. A saída desta etapa é um SavedModel treinado do TensorFlow que é exportado para o Cloud Storage.
4. O modelo treinado do TensorFlow é implantado no Vertex AI Prediction como um serviço que tem uma API REST para que possa ser usado para previsões on-line. O mesmo modelo também pode ser usado para trabalhos de previsão em lote.
5. Depois que o modelo for implantado como uma API REST, os aplicativos cliente e os sistemas internos poderão invocar a API enviando solicitações com alguns pontos de dados e recebendo respostas do modelo com previsões.
6. Para orquestrar e automatizar esse pipeline, você pode usar o Vertex AI Pipelines como um agendador para invocar as etapas de preparação de dados, treinamento de modelo e implantação de modelo.

Você também pode usar o Vertex AI Feature Store para armazenar recursos de entrada para fazer previsões. Por exemplo, você pode criar periodicamente recursos de engenharia a partir dos dados brutos mais recentes e armazená-los no Vertex AI Feature Store. Os aplicativos cliente buscam os recursos de entrada necessários no Vertex AI Feature Store e os enviam ao modelo para receber previsões.

Onde fazer o pré-processamento

Na figura 2, os rótulos A, B e C mostram que as operações de pré-processamento de dados podem ocorrer no BigQuery, Dataflow ou TensorFlow. As seções a seguir descrevem como cada uma dessas opções funciona.

Opção A: BigQuery

Normalmente, a lógica é implementada no BigQuery para as seguintes operações:

• Amostragem: seleção aleatória de um subconjunto dos dados.
• Filtragem: remoção de instâncias irrelevantes ou inválidas.
• Particionamento: divisão dos dados para produzir conjuntos de treinamento, avaliação e teste.

Os scripts SQL do BigQuery podem ser usados ​​como uma consulta de origem para o pipeline de pré-processamento do Dataflow, que é a etapa de processamento de dados na figura 2. Por exemplo, se um sistema for usado no Canadá e o data warehouse tiver transações de todo o mundo, filtrando para obter dados de treinamento somente no Canadá é melhor feito no BigQuery. A engenharia de recursos no BigQuery é simples e escalonável e oferece suporte à implementação de transformações de recursos de agregações históricas e em nível de instância.

No entanto, recomendamos que você use o BigQuery para engenharia de recursos somente se usar seu modelo para previsão em lote (pontuação) ou se os recursos forem pré-calculados no BigQuery, mas armazenados no Vertex AI Feature Store para serem usados ​​durante a previsão on-line. Se você planeja implantar o modelo para previsões on-line e não tiver o recurso projetado em um repositório de recursos on-line, será necessário replicar as operações de pré-processamento SQL para transformar os pontos de dados brutos gerados por outros sistemas. Em outras palavras, você precisa implementar a lógica duas vezes: uma vez no SQL para pré-processar os dados de treinamento no BigQuery e uma segunda vez na lógica do aplicativo que consome o modelo para pré-processar pontos de dados on-line para previsão.

Por exemplo, se seu aplicativo cliente for escrito em Java, você precisará reimplementar a lógica em Java. Isso pode introduzir erros devido a discrepâncias de implementação, conforme descrito na seção de distorção de serviço de treinamento em Desafios de pré-processamento, mais adiante neste documento. Também é uma sobrecarga extra manter duas implementações diferentes. Sempre que você alterar a lógica no SQL para pré-processar os dados de treinamento, será necessário alterar a implementação Java de acordo para pré-processar os dados no momento da veiculação.

Se você estiver usando seu modelo apenas para previsão em lote (por exemplo, usando a previsão em lote do Vertex AI) e se os dados para pontuação forem provenientes do BigQuery, você poderá implementar essas operações de pré-processamento como parte do script SQL do BigQuery. Nesse caso, você pode usar o mesmo script SQL de pré-processamento para preparar dados de treinamento e de pontuação.

As transformações com estado de passagem completa não são adequadas para implementação no BigQuery. Se você usar o BigQuery para transformações de passagem completa, precisará de tabelas auxiliares para armazenar quantidades necessárias para transformações com estado, como médias e variações para dimensionar recursos numéricos. Além disso, a implementação de transformações de passagem completa usando SQL no BigQuery cria maior complexidade nos scripts SQL e cria uma dependência complexa entre o treinamento e os scripts SQL de pontuação.

Opção B: fluxo de dados

Conforme mostrado na Figura 2, você pode implementar operações de pré-processamento computacionalmente caras no Apache Beam e executá-las em escala usando o Dataflow. O Dataflow é um serviço de escalonamento automático totalmente gerenciado para processamento de dados em lote e stream. Ao usar o Dataflow, você também pode usar bibliotecas externas especializadas para processamento de dados, diferentemente do BigQuery.

O Dataflow pode realizar transformações em nível de instância e transformações de recursos de agregação histórica e em tempo real. Em particular, se seus modelos de ML esperam um recurso de entrada como total_number_of_clicks_last_90sec , as funções de janelamento do Apache Beam podem calcular esses recursos com base na agregação de valores de janelas de tempo de dados de eventos em tempo real (streaming) (por exemplo, eventos de clique). Na discussão anterior sobre granularidade de transformações , isso foi referido como "agregações históricas durante o treinamento, mas agregações em tempo real durante a previsão".

O diagrama a seguir, figura 3, mostra a função do Dataflow no processamento de dados de stream para previsões quase em tempo real.

Conforme mostrado na figura 3, durante o processamento, eventos chamados pontos de dados são ingeridos no Pub/Sub . O Dataflow consome esses pontos de dados, calcula recursos com base em agregações ao longo do tempo e, em seguida, chama a API do modelo de ML implantado para fazer previsões. As previsões são então enviadas para uma fila de saída do Pub/Sub. No Pub/Sub, as previsões podem ser consumidas por sistemas downstream, como monitoramento ou controle, ou podem ser enviadas de volta (por exemplo, como notificações) ao cliente solicitante original. As previsões também podem ser armazenadas em um armazenamento de dados de baixa latência, como o Cloud Bigtable, para busca em tempo real. O Cloud Bigtable também pode ser usado para acumular e armazenar essas agregações em tempo real para que possam ser consultadas quando necessário para previsão.

A mesma implementação do Apache Beam pode ser usada para processar em lote dados de treinamento provenientes de um armazenamento de dados off-line, como o BigQuery, e processar dados em tempo real para fornecer previsões on-line.

Em outras arquiteturas típicas, como a mostrada na figura 2, o aplicativo cliente chama diretamente a API do modelo implantado para previsões on-line. Nesse caso, se as operações de pré-processamento forem implementadas no Dataflow para preparar os dados de treinamento, as operações não serão aplicadas aos dados de previsão que vão diretamente para o modelo. Portanto, transformações como essas devem ser integradas ao modelo durante a veiculação de previsões online.

O Dataflow pode ser usado para realizar a transformação de passagem completa, calculando as estatísticas necessárias em escala. No entanto, essas estatísticas precisam ser armazenadas em algum lugar para serem usadas durante a previsão para transformar os pontos de dados de previsão. Usando a biblioteca TensorFlow Transform ( tf.Transform ), você pode incorporar diretamente essas estatísticas no modelo em vez de armazená-las em outro lugar. Essa abordagem é explicada posteriormente em Como funciona o tf.Transform .

Opção C: TensorFlow

Conforme mostrado na Figura 2, você pode implementar operações de pré-processamento e transformação de dados no próprio modelo do TensorFlow. Conforme mostrado na figura, o pré-processamento implementado para treinar o modelo do TensorFlow torna-se parte integrante do modelo quando o modelo é exportado e implantado para previsões. As transformações no modelo do TensorFlow podem ser realizadas de uma das seguintes maneiras:

• Implementar toda a lógica de transformação em nível de instância na função input_fn e na função serving_fn . A função input_fn prepara um conjunto de dados usando a API tf.data.Dataset para treinar um modelo. A função serving_fn recebe e prepara os dados para previsões.
• Colocar o código de transformação diretamente em seu modelo do TensorFlow usando camadas de pré-processamento Keras ou criando camadas personalizadas .

O código lógico de transformação na função serving_fn define a interface de serviço do seu SavedModel para previsão online. Se você implementar as mesmas transformações que foram usadas para preparar dados de treinamento no código lógico de transformação da função serving_fn , isso garantirá que as mesmas transformações sejam aplicadas a novos pontos de dados de previsão quando eles forem servidos.

No entanto, como o modelo do TensorFlow processa cada ponto de dados de forma independente ou em um lote pequeno, não é possível calcular agregações de todos os pontos de dados. Como resultado, as transformações de passagem completa não podem ser implementadas no seu modelo do TensorFlow.

Desafios de pré-processamento

A seguir estão os principais desafios da implementação do pré-processamento de dados:

• Desvio de serviço de treinamento . A distorção entre treinamento e serviço refere-se a uma diferença entre eficácia (desempenho preditivo) durante o treinamento e durante o serviço. Essa distorção pode ser causada por uma discrepância entre como você lida com os dados no treinamento e nos pipelines de serviço. Por exemplo, se o seu modelo for treinado em um recurso transformado logaritmicamente, mas for apresentado com o recurso bruto durante a veiculação, a saída da previsão poderá não ser precisa.

  Se as transformações se tornarem parte do próprio modelo, poderá ser simples lidar com as transformações no nível da instância, conforme descrito anteriormente na Opção C: TensorFlow . Nesse caso, a interface de serviço do modelo (a função serving_fn ) espera dados brutos, enquanto o modelo transforma internamente esses dados antes de calcular a saída. As transformações são as mesmas que foram aplicadas nos pontos de dados brutos de treinamento e previsão.

• Transformações de passagem completa . Não é possível implementar transformações de passagem completa, como transformações de dimensionamento e normalização, no modelo do TensorFlow. Nas transformações de passagem completa, algumas estatísticas (por exemplo, valores max e min para dimensionar recursos numéricos) devem ser calculadas previamente nos dados de treinamento, conforme descrito na Opção B: Fluxo de dados . Os valores então devem ser armazenados em algum lugar para serem usados ​​durante o serviço do modelo para previsão para transformar os novos pontos de dados brutos como transformações em nível de instância, o que evita distorções no serviço de treinamento. Você pode usar a biblioteca TensorFlow Transform ( tf.Transform ) para incorporar diretamente as estatísticas em seu modelo do TensorFlow. Essa abordagem é explicada posteriormente em Como funciona o tf.Transform .

• Preparar os dados antecipadamente para melhorar a eficiência do treinamento . A implementação de transformações no nível da instância como parte do modelo pode degradar a eficiência do processo de treinamento. Essa degradação ocorre porque as mesmas transformações são aplicadas repetidamente aos mesmos dados de treinamento em cada época. Imagine que você tem dados de treinamento brutos com 1.000 recursos e aplica uma combinação de transformações em nível de instância para gerar 10.000 recursos. Se você implementar essas transformações como parte de seu modelo e, em seguida, alimentar o modelo com os dados brutos de treinamento, essas 10.000 operações serão aplicadas N vezes em cada instância, onde N é o número de épocas. Além disso, se você estiver usando aceleradores (GPUs ou TPUs), eles ficarão ociosos enquanto a CPU executa essas transformações, o que não é um uso eficiente de seus aceleradores caros.

  Idealmente, os dados de treinamento são transformados antes do treinamento, usando a técnica descrita na Opção B: Dataflow , onde as 10.000 operações de transformação são aplicadas apenas uma vez em cada instância de treinamento. Os dados de treinamento transformados são então apresentados ao modelo. Nenhuma outra transformação é aplicada e os aceleradores ficam ocupados o tempo todo. Além disso, usar o Dataflow ajuda a pré-processar grandes quantidades de dados em escala, usando um serviço totalmente gerenciado.

  Preparar os dados de treinamento antecipadamente pode melhorar a eficiência do treinamento. No entanto, implementar a lógica de transformação fora do modelo (as abordagens descritas na Opção A: BigQuery ou Opção B: Dataflow ) não resolve o problema da distorção do fornecimento de treinamento. A menos que você armazene o recurso projetado no armazenamento de recursos para ser usado tanto para treinamento quanto para previsão, a lógica de transformação deverá ser implementada em algum lugar para ser aplicada em novos pontos de dados que chegam para previsão, porque a interface do modelo espera dados transformados. A biblioteca TensorFlow Transform ( tf.Transform ) pode ajudá-lo a resolver esse problema, conforme descrito na seção a seguir.

Como funciona o tf.Transform

A biblioteca tf.Transform é útil para transformações que exigem uma passagem completa. A saída da biblioteca tf.Transform é exportada como um gráfico do TensorFlow que representa a lógica de transformação no nível da instância e as estatísticas calculadas a partir de transformações de passagem completa, para serem usadas para treinamento e veiculação. Usar o mesmo gráfico para treinamento e saque pode evitar distorções, porque as mesmas transformações são aplicadas em ambos os estágios. Além disso, a biblioteca tf.Transform pode ser executada em escala em um pipeline de processamento em lote no Dataflow para preparar os dados de treinamento antecipadamente e melhorar a eficiência do treinamento.

O diagrama a seguir, figura 4, mostra como a biblioteca tf.Transform pré-processa e transforma dados para treinamento e previsão. O processo é descrito nas seções a seguir.

Transforme dados de treinamento e avaliação

Você pré-processa os dados brutos de treinamento usando a transformação implementada nas APIs tf.Transform Apache Beam e executa-os em escala no Dataflow. O pré-processamento ocorre nas seguintes fases:

• Fase de análise: durante a fase de análise, as estatísticas necessárias (como médias, variações e quantis) para transformações com estado são calculadas nos dados de treinamento com operações de passagem completa. Esta fase produz um conjunto de artefatos de transformação, incluindo o gráfico transform_fn . O gráfico transform_fn é um gráfico do TensorFlow que possui a lógica de transformação como operações em nível de instância. Inclui as estatísticas calculadas na fase de análise como constantes.
• Fase de transformação: Durante a fase de transformação, o gráfico transform_fn é aplicado aos dados brutos de treinamento, onde as estatísticas computadas são usadas para processar os registros de dados (por exemplo, para dimensionar colunas numéricas) em nível de instância.

Uma abordagem em duas fases como essa aborda o desafio de pré-processamento de realizar transformações de passagem completa.

Quando os dados de avaliação são pré-processados, apenas as operações em nível de instância são aplicadas, usando a lógica no gráfico transform_fn e as estatísticas calculadas a partir da fase de análise nos dados de treinamento. Em outras palavras, você não analisa os dados de avaliação de maneira completa para calcular novas estatísticas, como μ e σ, para normalizar recursos numéricos nos dados de avaliação. Em vez disso, você usa as estatísticas computadas dos dados de treinamento para transformar os dados de avaliação em nível de instância.

Os dados de treinamento e avaliação transformados são preparados em escala usando o Dataflow, antes de serem usados ​​para treinar o modelo. This batch data-preparation process addresses the preprocessing challenge of preparing the data up front to improve training efficiency. As shown in figure 4, the model internal interface expects transformed features.

Attach transformations to the exported model

As noted, the transform_fn graph that's produced by the tf.Transform pipeline is stored as an exported TensorFlow graph. The exported graph consists of the transformation logic as instance-level operations, and all of the statistics computed in the full-pass transformations as graph constants. When the trained model is exported for serving, the transform_fn graph is attached to the SavedModel as part of its serving_fn function.

While it's serving the model for prediction, the model serving interface expects data points in the raw format (that is, before any transformations). However, the model internal interface expects the data in the transformed format.

The transform_fn graph, which is now part of the model, applies all the preprocessing logic on the incoming data point. It uses the stored constants (like μ and σ to normalize the numeric features) in the instance-level operation during prediction. Therefore, the transform_fn graph converts the raw data point into the transformed format. The transformed format is what is expected by the model internal interface in order to produce prediction, as shown in figure 4.

This mechanism resolves the preprocessing challenge of the training-serving skew, because the same logic (implementation) that is used to transform the training and evaluation data is applied to transform the new data points during prediction serving.

Preprocessing options summary

The following table summarizes the data preprocessing options that this document discussed. In the table, "N/A" stands for "not applicable."

^* With TensorFlow, transformations like crossing, embedding, and one-hot encoding should be performed declaratively as feature_columns columns.

What's next

• To implement a tf.Transform pipeline and run it using Dataflow, read part two of this series, Data preprocessing for ML using TensorFlow Transform .
• Take the Coursera specialization on ML with TensorFlow on Google Cloud .
• Learn about best practices for ML engineering in Rules of ML .
• For more reference architectures, diagrams, and best practices, explore the TFX Cloud Solutions .