Removido pelo BigQuery ML

Previsão de preferências de uísque no GCP

Phil Goerdt Blocked Unblock Seguir Seguindo 10 de janeiro

"Estou procurando por…

… Qualquer coisa que seja turfosa, esfumaçada como uma fogueira na praia, álcool médio a alto, frutas secas, frutas cítricas e um toque sutil de terra firme. ”

É fácil para mim entrar na minha loja de bebidas local e falar com notas de degustação (e brincar) com o cara ou a moça do uísque na equipe, e ele ou ela será capaz de saber o que eu estou procurando e fazer uma recomendação para mim. Mas um modelo de aprendizado de máquina pode fazer o mesmo em um conjunto mínimo de dados e com entradas limitadas? Essa é a questão em mãos.

(Para aqueles de vocês que estão participando agora, obrigado por virem nessa parte da história! Eu recomendo que você dê uma olhada nos outros blogs desta série, mas se você não o fizer, o resumo é que eu tenho um monte de uísque dados com minhas preferências de degustação. Vamos ver o que podemos aprender com isso.)

BigQuery ML em poucas palavras

Para este exercício, usarei o mecanismo BigQueryML do Google Cloud Platform. Se você não adivinhou, essa é uma ferramenta ML que permitirá criar modelos ML e executá-los no BigQuery.

O BQML é uma vantagem incrível para quem tem toneladas de dados no BigQuery (ou em qualquer outro lugar que possa transferir dados facilmente para o BQ), pois os dados podem permanecer inalterados e não exigem definição do quadro de dados. Além disso, podemos gerenciar e executar nossos modelos no BigQuery também; isso significa que não há mais máquinas computacionais virtuais específicas (ou, suponho, físicas) para provisionamento. E finalmente, podemos criar esses modelos usando comandos SQL especializados disponíveis no BQ. Isso não é como outros plugins SQL que exigem toneladas de funções definidas pelo usuário, classes e outras coisas divertidas que nos impedem de desenvolver conteúdo real; funciona de imediato. Quão legal é isso?!

E você escolheu isso porque …?

Por que devemos nos preocupar com esses recursos? Eu não deveria tentar usar “um verdadeiro framework ML” como o TensorFlow? Bem, sim … talvez. Eu poderia tentar fazer este exercício em uma "estrutura real" como o TensorFlow. Mas há algumas razões pelas quais eu não segui esse caminho.

Por um lado, eu não queria escrever outro blog “como fazer o seu primeiro com o TensorFlow”. Isso já foi blogado para a morte. Além disso, alguém como Sara Robinson fará um trabalho muito melhor na produção de conteúdo fresco e vanguardista do TensorFlow do que eu. BigQueryML aqui vamos nós!

Outra razão é que em blogs anteriores eu falei sobre o meu amor pela simplicidade ao projetar sistemas que funcionam juntos. Eu gosto que as coisas tenham o menor número possível de peças móveis, tenham o menor número de pontos de falha possível e sejam tão automatizadas quanto possível desde o início. O BigQueryML é simples, é barato para mim experimentar e se encaixa na minha definição de pilha de tecnologia atual. Usá-lo foi um acéfalo para mim.

Finalmente, minhas exigências não ditavam que eu precisava de qualquer coisa com alta potência. Meu conjunto de treinamento é um subconjunto de pouco mais de 100 linhas (todos os uísques que experimentei em 2018) e estou fazendo regressões bastante simples para previsão. E por causa dessas razões, acho que o risco de overtraining usando uma solução mais robusta e altamente projetada foi alto. (Comente e discuta abaixo, se você quiser. Se houver muita resposta a isso, talvez eu faça alguns modelos do TensorFlow e compare-os com o BQML em um post futuro.)

Independentemente das minhas razões para escolher o BigQueryML, vamos ao assunto de usá-lo.

Grandes consultas, maior ML?

Como eu disse acima, é muito fácil usar o BigQueryML, e isso se deve principalmente ao conjunto de recursos do produto. No entanto, só porque é fácil de usar, não significa que seja sem nuances. Vamos criar um modelo de exemplo baseado em meus dados, avaliá-lo e conversar um pouco sobre isso.

Vou ter o que ele está tendo

Em alguns blogs anteriores desta série, forneci uma rápida descrição do que eram os dados de classificação do uísque. Aqui está um lembrete rápido:

Mmm … dados tartare.

Acima estão as pontuações cruas e não ponderadas de dois uísques, juntamente com alguns atributos dimensionais. Pense que é o suficiente para prever contra? Eu acho que o veredicto ainda está errado. Eu acho que, se pensarmos sobre isso, como a maioria dos bebedores de uísque normalmente começa a conversar sobre o que eles bebem, geralmente é dito um tipo de uísque, como “eu sou um bourbon guy” ou “eu só bebo single malts”. " Às vezes a maturidade entra em jogo e, muitas vezes, o preço dita o que compramos ou podemos pagar. Estes geralmente são bons indicadores por si mesmos. Mas o modelo será capaz de aprender além disso? Temos o suficiente para detectar nuances?

Eu acho que nós vamos ter que ver o que o modelo pensa.

Modelando como um profissional

Agora que estamos todos atualizados no conjunto de dados de treinamento, vamos dar uma olhada em como modelar realmente as coisas no BigQueryML.

Se você estiver familiarizado com SQL, você pode ter imaginado que a criação de um modelo é semelhante a qualquer instrução DDL . Usando a instrução create model , podemos criar alguns modelos que são executados e treinados diretamente no BigQuery. A documentação do GCP faz um excelente trabalho ao analisar todos os parâmetros disponíveis, portanto, verifique se você deseja ler coisas que não estou usando neste exemplo.

 --Oi! Eu sou um modelo (muito) simples para prever uma pontuação total! 
 crie ou substitua o modelo `sample_schema.predict_total_test` 
opções
(model_type = 'linear_reg', / * este é o tipo de modelo * /
l1_reg = 0, / * quanto de regularização L1 devemos usar? * /
max_iterations = 5, / * quantas vezes devemos treinar? * /
input_label_cols = ['label'], / * esta é a coluna para prever * /
data_split_method = 'seq', / * como queremos dividir os dados? * /
data_split_eval_fraction = 0.3, / * quanto devemos dividir? * /
data_split_col = 'date_sampled' / * qual coluna devemos dividir? * /
) Como
 / * esta é uma consulta para coletar dados para usar no modelo. 
Todas essas colunas devem estar presentes mais tarde quando executarmos o modelo. * /
 selecione 
f.rating_name como full_name
, f.distilaria como destilaria
, f.date_sampled como date_sampled
f.total_score como rótulo
de
`sample_schema.w_ratings_f` f
onde 1 = 1
;

Parece bastante simples, mas deixe-me quebrar o que está acontecendo lá.

Primeiro, temos a instrução de create or replace model seguida pelo nome do modelo. Em seguida, vem a cláusula options , que nos permite parametrizar nosso novo modelo. Como eu disse antes, há muitas alavancas divertidas para puxar e puxar para dentro, e você pode ler mais sobre isso na documentação. Este exemplo tem apenas algumas opções para aguçar seu apetite. Vamos dar uma olhada no que eles são.

  • model_type : Este é o tipo de modelo que estou criando. Eu estou usando o modelo de regressão linear recomendado, que é usado para previsões e previsões.
  • l1_reg : Controla a ponderação de entradas no modelo , o que é importante para reduzir o ruído em recursos e remover recursos irrelevantes em conjuntos de dados esparsos e altamente dimensionais. Uma vez que este modelo é tão simples, ter um 0 aqui está bem. Embora, se editarmos o modelo para ter uma maior dimensionalidade, podemos querer ajustar esse parâmetro. (Quando isso se tornaria relevante? Vamos fingir que adiciono notas de prova ao conjunto de dados, e que apenas alguns dos conjuntos de amostras têm essas notas. Porque essas notas seriam escassas (não se aplica a todas as linhas) e porque tem notas diferentes para cada um (um conjunto variado de texto), nós queremos forçar os pesos desse recurso para 0 para ignorá-lo para uma entrada específica se não houver notas.)
  • max_iterations : Este é quantos passos o modelo levará para treinar. Estou paranóico com o overtraining, já que esse é um conjunto de dados tão pequeno, e é por isso que diminuí o máximo para 5 do padrão de 20.
  • input_label_cols : identifica as colunas que serão previstas. Simplificando, recursos são entradas e rótulos são saídas. Aqui estou tentando prever a pontuação total.
  • data_split_method : Como devemos dividir os dados para treinamento? As opções são random e seq .
  • data_split_eval_fraction : Controla a quantidade de dados que é dividida para treinamento. O padrão é .2 , mas como esse conjunto de dados é muito pequeno, prefiro um pouco mais. Daí a escolha para .3 .
  • data_split_col : identifica a coluna na qual dividir os dados. Não está incluído no conjunto de recursos.

Indo mais além na instrução SQL, você notará que há uma instrução select que serve os dados para o modelo. Isso é bastante autoexplicativo, e essa simplicidade de não precisar definir quadros de dados, recursos e todas as outras coisas divertidas que acompanham os modelos ML torna o BigQueryML muito atraente para alguém na minha situação.

Uma vez que o modelo é definido, posso executar a declaração acima e o que acontece a seguir é bem legal. O BigQuery ingere a lógica do modelo, consulta os dados e provisiona e protege automaticamente os recursos do GCE (Google Compute Engine) para executar o modelo. Sério, quão legal é isso? O Eagle Eyed (com permissões de administrador de cobrança) pode perceber que há alguns itens de linha adicionais para o GCE, e isso é porque você será cobrado por executar essas instruções de ML. No entanto, você não é responsável por girar esses recursos para cima ou para baixo ao executá-los.

Agora que executei o modelo, devo avaliá-lo. A razão para isso é entender melhor a precisão do modelo. Embora possamos saber definitivamente se o modelo é preciso (porque, você sabe, matemática), em alguns casos, construir e ajustar modelos é um pouco mais de arte do que de ciência. Vamos percorrer alguns exemplos de por que esse é o caso.

Hora da prova

Posso verificar alguns indicadores importantes da precisão de meus modelos executando o seguinte comando no BigQuery:

 selecione * 
from ml.evaluate (model `sample_schema.predict_total_test`);

Isto lhe dará uma saída parecida com esta:

Uh … obrigado?

A variedade de estatísticas acima ajuda a quantificar a quantidade de erro que está no modelo; isto é, quanto o modelo está "desligado" da pontuação correta. Se estamos tentando prever a pontuação correta a cada vez (e estamos), estaríamos tentando ter um erro o mais próximo de zero possível.

Quem se lembra de "linha de melhor ajuste" da classe de estatísticas?

Vamos dar uma olhada rápida nesta figura do curso de acidente de ML do Google. Essa figura mostra como o modelo está tentando se encaixar no conjunto de dados e, claramente, o da direita está fazendo um trabalho melhor. Ao olhar para os erros estatísticos do modelo, parece que podemos fazer melhor… certo?

Em teoria, sim, eu definitivamente poderia. O que fiz a seguir foi executar o mesmo modelo várias vezes com conjuntos de recursos diferentes para determinar o que causou impacto nas taxas de erro do modelo. Você pode ver abaixo que adicionar e remover recursos adicionais alterou bastante as taxas de erros e nenhuma das taxas de erro foi tão baixa quanto o modelo base.

Uau. Essas estatísticas.

Isso significa que devemos reverter para a base? Na minha opinião, não, e aqui está o porquê. O conjunto de dados é muito pequeno. Se olharmos para o modelo base, há duas características: o nome completo do uísque e a destilaria. Se eu fosse usá-los apenas para prever se eu gostava ou não de um uísque, provavelmente teria resultados ruins com o tempo. A razão pela qual as taxas de erro estão aumentando quando adiciono mais recursos é que não há dados suficientes ou recursos suficientes para determinar um padrão.

Isso significa que, mesmo quando podemos ver, do ponto de vista matemático, que um modelo é “o mais correto”, isso não significa que ele será escalável ou capaz de aprender com novos dados a que está exposto. E qual é o objetivo disso?

De volta à prancheta?

Eu fiz vários outros modelos desde o primeiro modelo e experimentei eles para produzir resultados muito melhores. Parte deste processo foi obter mais dados, especificamente introduzindo notas de prova no modelo. Além disso, o ajuste dos parâmetros dos modelos também ajudou. Então, como foi o “trabalho em andamento” final?

Não é ruim … certo?

Eu acho que os resultados acima estão corretos. Obviamente ainda preciso fazer alguns ajustes nos modelos, e também acho que um pequeno conjunto de dados é parte do problema. (Se você quiser conferir todas as recomendações, sinta-se à vontade para ir até Damn Dram .)

Mas não vamos esquecer a estrela do programa aqui, que é o BigQueryML. Foi incrivelmente fácil criar, gerenciar e testar esses modelos no BigQueryML e se integrou perfeitamente ao que eu já estava criando. E não consigo ver nada de errado com isso.