Princípios básicos da previsão

Você pode hospedar modelos treinados de aprendizado de máquina na nuvem e usar o serviço de previsão do Cloud ML para inferir valores alvo a dados novos. Nesta página, são abordadas a hospedagem e a previsão de modelo, além de considerações que você deve ter em mente para seus projetos.

Como funciona

O serviço de previsão do Cloud ML Engine gerencia recursos de computação na nuvem para executar seus modelos. Você pode solicitar previsões dos modelos e receber valores alvo previstos para eles. Veja abaixo o processo de configuração para fazer previsões na nuvem:

  1. Exporte o modelo usando SavedModel como parte do aplicativo de treinamento.

  2. Crie um recurso de modelo no Cloud ML Engine e, em seguida, crie uma versão de modelo a partir do modelo salvo.

  3. Formate os dados de entrada para a previsão e solicite a on-line ou em lote.

  4. Quando você usa a previsão on-line, o serviço executa o modelo salvo e retorna as previsões solicitadas como mensagem de resposta para a chamada.

    • A versão de modelo é implantada na região que você especificou quando criou o modelo.
    • Uma versão de modelo que você usa regularmente costuma ficar pronta para ser executada, mas isso não é garantido.

    Quando você usa a previsão em lote, o processo é um pouco mais complicado:

    1. O serviço de previsão aloca recursos para executar o job. Isso inclui um ou mais nodes de previsão.

    2. Este serviço restaura o gráfico TensorFlow em cada node alocado.

    3. Depois, ele distribui os dados de entrada pelos nodes alocados.

    4. Cada node executa o gráfico e salva as previsões em um local do Google Cloud Storage especificado por você.

    5. Após todos os dados de entrada serem processados, o serviço encerra o job e libera os recursos alocados para ele.

Implantação do modelo

O Cloud ML Engine pode hospedar os modelos para que você possa receber previsões deles na nuvem. O processo de hospedagem de um modelo salvo é chamado de implantação. O serviço de previsão gerencia a infraestrutura necessária para executar o modelo em escala e disponibiliza-o para solicitações de previsão on-line e em lote. Esta seção descreve a implantação do modelo.

Sobre modelos e versões

O Cloud ML Engine organiza os modelos treinados usando recursos denominados modelos e versões. Um modelo é uma solução de aprendizado de máquina. Por exemplo, você pode criar um modelo denominado census para conter todo o trabalho em um modelo de aprendizado de máquina do censo dos EUA. A entidade que você cria, denominada census, é um contêiner de implementações reais do modelo de aprendizado de máquina, isto é, versões.

O desenvolvimento de um modelo de aprendizado de máquina é um processo iterativo. Por esse motivo, o paradigma de recurso do Cloud ML Engine é configurado com a suposição de que você fará várias versões de cada modelo de aprendizado de máquina. Essa terminologia pode ser confusa porque um recurso de modelo do Cloud ML Engine, por si só, não é propriamente um modelo de aprendizado de máquina. No Cloud ML Engine, um modelo é um contêiner das versões do modelo de aprendizado da máquina.

O que há em uma versão?

O "modelo" que você implanta no Cloud ML Engine como uma versão de modelo é um SavedModel do TensorFlow. Você exporta um SavedModel no treinador. Não importa se o treinamento do modelo foi na nuvem usando o Cloud ML Engine ou em qualquer outro lugar, contanto que você tenha um SavedModel com a assinatura de veiculação definida como serving_default.

Variações entre versões

As versões que você cria para qualquer recurso de modelo são arbitrárias. Você pode usar o mesmo recurso de modelo, mesmo que altere completamente o modelo de aprendizado de máquina entre as versões. Um modelo é uma ferramenta organizacional que você pode usar do jeito que fizer sentido para a situação.

É comum, especialmente depois que você tiver uma versão em produção, usá-lo para manter as entradas e saídas iguais entre as versões do modelo. Isso permite alternar as versões sem precisar alterar outra estrutura de aplicativo que você tenha construído em torno do modelo. Também facilita o teste de novas versões com dados existentes.

Versão padrão

Todo modelo que tenha pelo menos uma versão tem uma versão padrão, que é definida quando a primeira versão é criada. Se você solicitar previsões especificando apenas um nome de modelo, o Cloud ML Engine usará a versão padrão desse modelo.

A única vez em que o serviço define automaticamente a versão padrão é quando você cria a primeira. Para definir qualquer versão subsequente como padrão, basta chamar projects.models.versions.setDefault. Esse comando também é exibido como gcloud ml-engine versions set-default e como uma opção na lista de versões na página "Detalhes do modelo" no Console do Google Cloud Platform. Clique no modelo que você quer na lista na Página de modelos. Isso permite que você, por exemplo, use uma versão padrão estável para veicular previsões em produção enquanto testa versões mais recentes sem criar um recurso de modelo dedicado para teste.

Como nomear modelos e versões

Os nomes de modelo e versão precisam:

  • conter apenas letras maiúsculas e minúsculas, números e sublinhados;
  • começar com uma letra;
  • conter no máximo 128 caracteres;
  • ser exclusivos dentro de um determinado projeto (para modelos) ou modelo (para versões).

Não há regras para nomes além desses requisitos técnicos, mas há algumas práticas recomendadas:

  • Nomes de modelo devem ser descritivos e distintivos. Talvez seja necessário retirá-los de listas com muitos nomes em registros ou relatórios.
  • Escolha nomes de versão curtos e simples. É mais fácil identificar "v1" em uma lista de recursos do que "2017_01_29T13_54_58", por exemplo.

Limites de modelo e versão

A política de cotas do Cloud ML Engine define um limite de 100 modelos por projeto e limita a 200 o número total de versões (combinadas entre todos os modelos).

Parâmetros de implantação de modelo

O Cloud ML Engine precisa de algumas informações para criar a versão do modelo. Há também algumas opções que você pode configurar. Esta seção descreve os parâmetros dos dois tipos. Esses parâmetros são definidos no objeto Version ou adicionados por conveniência no comando gcloud ml-engine versions create.

Nome da versão
Um nome para a nova versão que é exclusivo entre os nomes de outras versões do modelo.
Descrição
Você pode incluir uma descrição para a versão. No momento, a descrição só é fornecida quando você recebe as informações da versão com a API, nem a ferramenta de linha de comando gcloud nem o Console do Google Cloud Platform exibem a descrição.
URI de implantação
É preciso fornecer o URI do local do Cloud Storage onde o SavedModel está armazenado. O Cloud ML Engine extrai o modelo desse local e o implanta. Esse parâmetro é denominado --origin no comando gcloud ml-engine versions create.
Versão de tempo de execução
O Cloud ML Engine usa a versão de tempo de execução estável mais recente para implantar a versão do modelo, a menos que você especifique uma outra compatível. A versão de tempo de execução determina principalmente a versão do TensorFlow que o serviço de previsão usa para executar o modelo. Ao executar um job de previsão em lote, você tem a opção de modificar a versão de tempo de execução atribuída. A previsão on-line sempre usa a versão de tempo de execução definida quando a versão do modelo é implantada.
Escalonamento manual

Você pode especificar o número de nodes de treinamento que continuam em execução para a versão do modelo. Consulte a seção sobre escalonamento para mais informações.

Intervalo de preparação

Se você estiver usando a ferramenta de linha de comando gcloud para implantar o modelo, poderá usar um SavedModel no computador local. A ferramenta o organiza no local do Cloud Storage que você especificou antes de implantá-lo no Cloud ML Engine.

Alterações de gráfico para previsão

Você pode ter incluído operações do TensorFlow no gráfico de computação que foram úteis principalmente no contexto de treinamento. Depois de treinar o modelo, você pode remover essas operações do gráfico antes de exportar a versão final.

Boa parte da orientação dada na página de desenvolvimento de aplicativo de treinamento visa a experiência de previsão. Em alguns casos, essas são as alterações que você faz no modelo quando a maior parte do treinamento está concluída e você está pronto para começar a implantar versões.

Como receber previsões

Você pode enviar novos dados às versões de modelo implantadas para receber previsões. As seções a seguir descrevem importantes considerações sobre previsão.

Previsão on-line versus previsão em lote

O Cloud ML Engine oferece duas maneiras de receber previsões de modelos treinados: previsão on-line (às vezes chamada de previsão HTTP) e previsão em lote. Nos dois casos, você passa dados de entrada a um modelo de aprendizado de máquina hospedado em nuvem e recebe inferências para cada instância de dados. As diferenças são mostradas na tabela a seguir:

Previsão on-line Previsão em lote
Otimizada para minimizar a latência das previsões de veiculação. Otimizada para processar um alto volume de instâncias em um job e executar modelos mais complexos.
Pode processar uma ou mais instâncias por solicitação. Pode processar uma ou mais instâncias por solicitação.
Previsões retornadas na mensagem de resposta. Previsões gravadas em arquivos de saída em um local do Cloud Storage especificado por você.
Dados de entrada passados diretamente como string JSON. Dados de entrada passados indiretamente como um ou mais URIs de arquivos em locais do Cloud Storage.
Retorna o mais rápido possível. Solicitação assíncrona.
Qualquer pessoa com acesso Leitor ao projeto pode solicitar. É necessário ser um Editor para executar.
Executa a versão de tempo de execução e na região selecionada quando você implanta o modelo. Pode ser executada em qualquer região disponível usando qualquer versão de tempo de execução disponível. Porém, você deve executar com os padrões para as versões de modelo implantadas.
Executa modelos implantados no Cloud ML Engine. Executa modelos implantados no Cloud ML Engine ou modelos armazenados em locais acessíveis do Google Cloud Storage.

As necessidades do aplicativo determinam o tipo de previsão que melhor se encaixa. Em geral, usa-se a previsão on-line ao fazer solicitações em resposta à entrada do aplicativo ou em outras situações em que a inferência em tempo hábil é necessária. A previsão em lote é ideal para processar dados acumulados quando você não precisa de resultados imediatos. Por exemplo, um job periódico que recebe previsões para todos os dados coletados desde o último. Leve em conta na sua decisão as possíveis diferenças nos custos de previsão.

Latência de previsão em lote

Se você usa um modelo simples e um pequeno conjunto de instâncias de entrada, verá que há uma diferença considerável entre a previsão on-line e a previsão em lote com relação ao tempo que cada uma leva para finalizar a mesma solicitação. Um job em lote pode levar vários minutos para concluir as previsões que são retornadas quase que instantaneamente por uma solicitação on-line. Trata-se de um efeito colateral da infraestrutura diferente usada pelos dois métodos. O Cloud ML Engine aloca e inicializa recursos para um job de previsão em lote quando você envia a solicitação. A previsão on-line geralmente está pronta para processar no momento da solicitação.

Como entender nodes de previsão e alocação de recursos

O Cloud ML Engine mede o volume de processamento que você consome para previsão em horas de node. Esta seção descreve esses nodes e como eles são alocados para os diferentes tipos de previsão.

É mais fácil pensar em um node como uma máquina virtual (VM), mesmo que ele seja implementado com um mecanismo diferente de uma VM tradicional. Cada node é provisionado com uma volume definido de energia e memória de processamento. Ele também tem uma imagem de sistema operacional e uma configuração de software definida que são necessárias para executar o modelo visando receber previsões.

Tanto a on-line como a em lote executam o node com processamento distribuído, de modo que uma determinada solicitação ou job possa usar vários nodes simultaneamente. Você é cobrado pelo uso total do node por minuto, usando-se uma taxa por hora. Por exemplo, executar dois nodes por dez minutos custa o mesmo que executar um node por vinte minutos. A previsão on-line e em lote aloca os nodes de modos diferentes, o que pode afetar substancialmente o será cobrado de você.

Alocação de node para previsão em lote

O serviço de previsão em lote escalona o número de nodes que usa para minimizar o tempo decorrido na execução do job. Para isso, o serviço:

  • aloca alguns nodes para processar o job quando você o inicia;

  • escalona o número de nodes durante o job na tentativa de otimizar a eficiência. Como cada node demora para começar, o serviço tenta alocar apenas os nodes suficientes para que o tempo de inicialização seja contido pela redução do tempo decorrido;

  • encerra os nodes assim que o job é concluído.

Você pode simular o escalonamento de um job de previsão em lote especificando o número máximo de nodes que serão usados. Normalmente, você quer quantos nodes forem necessários para o serviço, mas o uso está sujeito à política de cotas do Cloud ML Engine. Talvez seja necessário limitar o número de nodes alocados a um job específico, especialmente se você compartilhar o projeto com outras pessoas e potencialmente executar jobs (de treinamento e previsão) simultaneamente.

Alocação de nodes para previsão on-line

O serviço de previsão on-line escalona o número de nodes usados para maximizar a quantidade de solicitações processadas sem apresentar excesso de latência. Para isso, o serviço:

  • aloca alguns nodes na primeira vez que você solicita previsões após uma longa pausa nas solicitações;

  • escalona o número de nodes em resposta ao tráfego de solicitação, adicionando nodes quando o tráfego aumenta e removendo-os quando há menos solicitações;

  • mantém pelo menos um node pronto durante vários minutos para processar solicitações, mesmo quando não há nenhuma para processar. O estado pronto garante que o serviço possa atender cada previsão prontamente.

  • escalona até zero quando a versão de modelo fica vários minutos sem uma solicitação de previsão.

Depois que o serviço é escalonado para zero, pode demorar alguns segundos ou minutos até que os nodes sejam inicializados para atender uma solicitação. O tempo de inicialização depende do tamanho da versão do modelo, de modo que o tempo limite do lado do cliente pode resultar no descarte da primeira solicitação de um modelo grande.

Para garantir o atendimento rápido em todos os momentos, especifique um número mínimo de nodes que o serviço deve manter prontos, definindo a opção minNodes na versão do modelo. Essa configuração pode aumentar o custo porque os nodes são pagos mesmo quando nenhuma previsão é atendida.

Limitações do escalonamento automático

O escalonamento automático do Cloud ML Engine para previsão on-line pode ajudá-lo a veicular taxas variáveis de solicitações de previsão, ao mesmo tempo que minimiza os custos. No entanto, ele não é ideal para todas as situações. O serviço pode não ser capaz de colocar os nodes on-line rápido o suficiente para acompanhar os grandes picos de tráfego de solicitação. Se o tráfego regularmente tem picos altos, e a latência baixa confiável é importante para o aplicativo, talvez convenha fazer o escalonamento manual.

Como usar o escalonamento manual

Você pode simular o escalonamento de previsão on-line para uma versão de modelo especificando um número de nodes para continuar em execução, independentemente do tráfego. Definir o número de nodes manualmente na verdade impede que o serviço escalone, o que significa que o número de nodes que você especifica estará sempre pronto, e você será cobrado continuamente por eles. Isso não é recomendável, a menos que o número de solicitações que o modelo recebe flutue mais rapidamente do que o escalonamento automático pode acompanhar. O número de nodes a serem usados é definido por manualScaling no objeto Version que você passa para projects.models.versions.create.

Dados de entrada de previsão

Os dados que você usa para receber previsões são dados novos que assumem a mesma forma que os dados usados no treinamento. Tanto a previsão on-line como a em lote usam os mesmos dados (recursos do modelo), mas elas exigem formatos diferentes, dependendo do tipo de previsão e da interface que você usa. Esses formatos estão resumidos na tabela a seguir e descritos em mais detalhes nas seções abaixo:

Tipo e interface de previsão Formato de entrada compatível
Lote com chamada de API Arquivo de texto com strings de instância JSON ou arquivo TFRecords (pode ser compactado)
Lote com ferramenta gcloud Arquivo de texto com strings de instância JSON ou arquivo TFRecords (pode ser compactado)
On-line com chamada de API Mensagem de solicitação JSON
On-line com ferramenta gcloud Arquivo de texto com strings de instância JSON ou arquivo CSV

Strings JSON de instâncias

O formato básico das previsões on-line e em lote é uma lista de tensores de dados de instância. Pode ser uma lista simples de valores ou membros de um objeto JSON, dependendo de como você configurou as entradas no aplicativo de treinamento:

Este exemplo mostra um tensor de entrada e uma chave de instância:

{"values": [1, 2, 3, 4], "key": 1}

A composição da string JSON pode ser complexa, contanto que siga estas regras:

  • O nível superior dos dados da instância precisa ser um objeto JSON, um dicionário de pares chave/valor.

  • Os valores individuais em um objeto de instância podem ser strings, números ou listas. Não é possível incorporar objetos JSON.

  • As listas precisam conter apenas itens do mesmo tipo (incluindo outras listas). Não é possível misturar strings e valores numéricos.

A seguinte string (formatada para legibilidade) mostra um objeto contendo um marcador e uma imagem, em que a imagem é uma matriz tridimensional de inteiros de 8 bits:

{
  "tag": "beach",
  "image": [
    [
      [138, 30, 66],
      [130, 20, 56],
      ...
    ],
    [
      [126, 38, 61],
      [122, 24, 57],
      ...
    ],
        ...
  ]
}

Se o modelo só recebe uma entrada, não é necessário incorporá-lo em um objeto JSON. Por exemplo, se você enviar um único tensor (vetor, neste caso) com quatro valores, não é necessário formatá-lo assim:

{"values": [1, 2, 3, 4]}

Você pode apenas formatar cada instância como uma lista:

[1, 2, 3, 4]
Dados binários na entrada de previsão

Os dados binários não podem ser formatados como as strings codificadas em UTF-8 compatíveis com o JSON. Se houver dados binários nas entradas, é preciso usar a codificação base64 para representá-los. A seguinte formatação especial é necessária:

  • A string codificada precisa ser formatada como um objeto JSON com uma chave única denominada b64. O seguinte exemplo Python codifica um buffer de dados JPEG em bruto usando a biblioteca base64 para fazer uma instância:

    {"image_bytes":{"b64": base64.b64encode(jpeg_data)}}
    
  • No código do modelo TensorFlow, é preciso criar aliases para seus tensores de entrada e saída para que eles terminem com "_bytes".

Dados de entrada de previsão on-line

Você passa instâncias de entrada para a previsão on-line como o corpo da mensagem para a solicitação de previsão. Para formatar o corpo de solicitação e resposta, consulte os detalhes da solicitação de previsão.

Em resumo: faça de cada instância um item em uma lista e nomeie o membro da lista como instances. Com isso, o exemplo acima de JSON de instância de dados simples fica assim:

{"instances": [{"values": [1, 2, 3, 4], "key": 1}]}

Quando você usa gcloud ml-engine projects predict para solicitar previsões on-line, você passa um arquivo com o mesmo formato usado para previsão em lote.

Dados de entrada de previsão em lote

Você fornece dados de entrada para previsão em lote em um ou mais arquivos de texto contendo linhas de dados de instância JSON, conforme descrito acima. Um arquivo de entrada não contém cabeçalhos de coluna ou outra formatação além da sintaxe JSON simples.

{"image": [0.0, 0.0, ... ], "key": 0}
{"image": [0.0, 0.0, ... ], "key": 1}
{"image": [0.0, 0.0, ... ], "key": 2}

Chaves de instância

O Cloud ML Engine executa os jobs de previsão em lote usando processamento distribuído. Isso significa que os dados são distribuídos por um cluster arbitrário de máquinas virtuais e processados em ordem imprevisível. Para poder corresponder às previsões retornadas com as instâncias de entrada, é necessário ter chaves de instância definidas. Uma chave de instância é um valor que cada instância tem e é exclusivo entre as instâncias em um conjunto de dados. A chave mais simples é um número de índice.

Você deve passar as chaves por meio do gráfico inalterado no aplicativo de treinamento. Se os dados ainda não têm chaves de instância, você pode adicioná-las como parte do pré-processamento de dados.

Versões de tempo de execução

À medida que novas versões do Cloud ML Engine são lançadas, os modelos desenvolvidos em versões anteriores podem ficar obsoletos. Isto é particularmente pertinente se você chegar a uma versão modelo efetiva que permanece inalterada por um longo período. Analise a política de versão do Cloud ML Engine e certifique-se de compreender a versão de tempo de execução do Cloud ML Engine que você usa para treinar as versões de modelo.

Versões de tempo de execução e previsões

Você pode especificar uma versão de tempo de execução do Cloud ML Engine compatível quando cria uma versão de modelo. Isso estabelece a configuração padrão da versão de modelo. Se você não especifica uma explicitamente, o Cloud ML Engine cria a versão usando a versão de tempo de execução padrão atual (geralmente a versão estável mais recente).

Você pode especificar uma versão de tempo de execução para usar ao iniciar um job de previsão em lote. Isso serve para acomodar o recebimento de previsões usando um modelo que não é implantado no Cloud ML Engine. Não é recomendado usar uma versão de tempo de execução diferente do padrão para um modelo implantado. Fazer isso pode causar erros inesperados.

Por não ser possível solicitar previsões on-line a partir de modelos de fora do Cloud ML Engine, não há opção para modificar a versão de tempo de execução padrão na solicitação.

A versão de tempo de execução padrão definida para uma versão de modelo não pode ser alterada. Para especificar uma versão de tempo de execução diferente para uma versão de modelo, implante uma versão nova com os mesmos artefatos de treinamento que usou inicialmente.

Regiões e previsões

O Google Cloud Platform usa regiões subdivididas em zonas para definir a localização geográfica dos recursos físicos de computação. Ao implantar um modelo para a previsão usando o Cloud ML Engine, você especifica a região padrão onde quer que a predição seja executada.

Ao iniciar um job de previsão em lote, você pode especificar uma região para executar o job modificando a região padrão. As previsões on-line são sempre veiculadas a partir da região padrão definida para o modelo.

Para ver as regiões disponíveis para os serviços do Cloud ML Engine, incluindo o treinamento do modelo e a previsão em lote/on-line, leia o guia sobre regiões.

Geração de registros de previsão

A previsão em lote gera registros de job que você pode ver no Stackdriver Logging. Você também poderá receber registros de solicitações de previsão on-line se configurar o modelo para gerá-los quando forem criados. É preciso especificar essa opção ao criar o recurso de modelo no Cloud ML Engine: ou todas as versões de um modelo geram registros de previsões on-line ou nenhuma delas gera.

É possível configurar a geração de registros de previsão on-line para um modelo. Basta definir onlinePredictionLogging como true (True no Python) no recurso Modelo que você usa ao criar o modelo com projects.models.create. Se você usar a ferramenta de linha de comando gcloud para criá-lo, inclua a sinalização --enable-logging ao executar gcloud ml-engine models create.

Como receber previsões de modelos não implantados

Você pode solicitar uma previsão em lote usando um modelo que não foi implantado no serviço Cloud ML Engine. Em vez de especificar um nome de modelo ou versão, você pode usar o URI de um local do Google Cloud Storage onde está armazenado o modelo a ser executado.

Como um modelo não implantado não tem uma versão de tempo de execução padrão estabelecida, você precisa defini-la explicitamente na solicitação de job. Se você não fizer isso, o Cloud ML Engine usará a versão de tempo de execução estável mais recente.

De qualquer outro modo, um job de previsão em lote usando um modelo não implantado se comporta como qualquer outro job em lote.

Teste de modelo

Você pode usar o serviço de previsão do Cloud ML Engine para hospedar os modelos que estão em produção. Também é possível usá-lo para testar os modelos. Tradicionalmente, o teste do modelo é a etapa antes da preparação para implantar uma solução de aprendizado de máquina. O objetivo é testar o modelo em um ambiente que seja próximo ao modo como será usado em situações do mundo real.

Lembre-se de que várias versões de um modelo podem ser implantadas simultaneamente no serviço. Isso significa que, se necessário, você poderá testar várias revisões do modelo de uma só vez. Isso também facilita a implantação de uma versão de produção do modelo, ao mesmo tempo em que a próxima revisão é testada. Tal como acontece com grande parte do desenvolvimento de aplicativos de aprendizado de máquina, a disponibilidade de dados recentes muitas vezes é um fator de limitação. Você deve desenvolver estratégias para dividir os dados que tem e coletar novos dados para usar em teste.

Próximas etapas

Enviar comentários sobre…

Cloud Machine Learning Engine (Cloud ML Engine)