Nothing found for Pass Guaranteed Accurate IBM - S2000-024 - IBM PowerVC v2.2 Administrator Specialty Latest Test Sample ⛹ Easily obtain free download of 《 S2000-024 》 by searching on ▷ www.pdfvce.com ◁ 🧢New S2000-024 Dumps Sheet

Sorry, but nothing matched your search terms. Please try again with some different keywords.

Capítulo 100 – Machine Learning – Guia Definitivo – Parte 10

Chegamos ao final do Deep Learning Book. Este é o centésimo e último capítulo deste livro online, em português, gratuito e agora com 100 capítulos!

Antes de mais nada nós da DSA gostaríamos de agradecer a você que acompanhou todo este trabalho realizado até aqui.

O Deep Learning Book nasceu do nosso inconformismo em ver pouco conhecimento sendo gerado em português sobre uma das tecnologias mais revolucionárias da história humana, a Inteligência Artificial. Este livro online, bem como os cursos gratuitos que oferecemos em nosso portal, fazem parte da nossa contribuição para ajudar a disseminar o conhecimento e a educação, tão importantes para a evolução do país.

Hoje o Deep Learning Book é uma referência em língua portuguesa, sendo usado aliás como referência em trabalhos de Mestrado e Doutorado, trabalhos de conclusão de curso de Graduação e Pós-Graduação e desde que foi lançado recebe um volume cada vez maior de acessos. Nosso objetivo vem sendo alcançado e estamos ajudando pessoas interessadas em aprender Inteligência Artificial.

Para concluir este trabalho, vamos fazer uma revisão do processo de aprendizado de máquina com as 10 últimas regras do Guia Definitivo de Machine Learning.

E ao final do capítulo teremos uma surpresa para você.

Boa leitura.

Inteligência Artificial já está presente em nossas vidas. Observe a sua volta. Aplicações de filtro de spam, sistemas de reconhecimento facial no celular, chatbots de atendimento ao cliente, sistemas de recomendação e muito, muito mais.

Pelo menos desde a década de 50 que cientistas ao redor do mundo estão tentando reproduzir nas máquinas o que considera-se como inteligência, reproduzindo especialmente o sistema de aprendizado do cérebro humano.

Mas foi a partir do surgimento do Big Data, e em especial do processamento paralelo em GPUs, pouco mais de uma década atrás, que a Inteligência Artificial cresceu de forma exponencial, permitindo a criação de aplicações maravilhosas em áreas como Visão Computacional e Processamento de Linguagem Natural, notadamente as tarefas mais complexas de reproduzir em computadores.

E uma sub-área da IA, Machine Learning, teve os avanços mais incríveis, quando uma arquitetura em especial, Deep Learning, conseguiu obter resultados do estado da arte.

Mas se você acompanhou este livro com atenção deve ter percebido que muito do que fazemos em IA se resume a Matemática com programação de computadores, através do treinamento com muitos, muitos dados. Aplicando as mais diversas técnicas matemáticas e estatísticas, preparamos os dados, treinamos algoritmos via programação e modelos são criados para os mais devidos fins, resolvendo problemas de negócio, ajudando tomadores de decisão ou alimentando aplicações. E muito ainda está por vir, à medida que as empresas percebem os benefícios de aplicações baseadas em IA.

Aqui estão as 10 regras finais do Guia Definitivo de Machine Learning.

Regra 41: Precisamos de Dados

Você pode pensar: “Espere, isso é óbvio”. Você ficaria surpreso com a quantidade de pessoas que não compreendem que IA, Machine Learning ou Deep Learning não existem sem dados. Precisamos de dados históricos para que, através de algoritmos, possamos detectar padrões e então o modelo realizar suas previsões ou tarefa final.

Para compreender bem isso, basta fazer uma analogia com o aprendizado de uma criança. Como uma criança aprende a falar? Ouvindo sua família falar o tempo todo (a voz representa os dados nesse caso). Como uma criança aprende a escrever? Quando alguém a ensina através de exercícios (que nesse caso representam os dados). Ou seja, uma criança aprende à medida que é exposta a dados, que são processados através dos sentidos e criam no cérebro a memória que será usada pela criança durante toda a sua vida.

Se a sua empresa ainda não está cuidando dos dados com o devido valor, ela já está bem atrasada. Os dados são agora um ativo corporativo mais importante do que nunca e que permite o uso e benefícios de Inteligência Artificial.

Isso explica por que a engenharia de dados também cresceu muito nos últimos anos, uma vez que precisamos de mecanismos, sistemas e ferramentas para coletar, armazenar e processar os dados.

Regra 42: Os Dados Raramente Estarão Prontos Para Uso

E por isso a etapa de limpeza e pré-processamentos dados ainda é parte crucial do trabalho. São várias técnicas que devem ser usadas de acordo com o conjunto de dados.

Raramente os dados estarão no formato ideal para o processo de análise ou construção dos modelos. A criação de pipelines de dados é o que permite passar os dados por uma “linha de produção”, para que os dados cheguem ao seu destino em condições de serem usados. Para compreender isso faça uma analogia: O petróleo bruto poderia ser usado como combustível em um automóvel? Não. Logo, o petróleo passa a ser valioso quando é processado e gera como produto final o combustível que, aí sim, ajudará a resolver diversos problemas (embora também crie outros). Com os dados a ideia é a mesma.

Regra 43: Não Há Arquitetura Ideal em Machine Learning

Machine Learning está distante da perfeição. Cada arquitetura tem pontos fortes e fracos e nosso trabalho não é buscar perfeição e sim encontrar a melhor solução possível, uma aproximação, que será suficiente para resolver determinado problema de negócio.

Não desperdice seu tempo buscando o modelo perfeito. Mantenha o foco na solução do problema e tente encontrar o modelo que oferece a melhor aproximação com o menor esforço.

Regra 44: Machine Learning Não é Aplicação Pronta

Um equívoco muito comum cometido por iniciantes é achar que Machine Learning é uma aplicação pronta, linda e maravilhosa, que pode ser usada imediatamente. Não. Machine Learning cria um modelo e ainda precisamos dar um passo adiante e decidir como usar esse modelo.

O modelo pode ser usado via linha de comando em nossas máquinas, pode ser integrado em uma aplicação web, uma aplicação para smartphone, podemos criar uma API usando um serviço em nuvem. As opções são inúmeras, mas Machine Learning concentra o conhecimento para criação do modelo e não criação da uma aplicação completa.

Regra 45: Use Transfer Learning Sempre Que Possível

Quando seu conjunto de dados consiste em dados não estruturados, como imagens, texto ou áudio, é recomendável pegar carona em modelos pré-treinados existentes.

Para ajustar um classificador de imagens, você pode precisar de apenas 10 exemplos por classe, por exemplo. Frameworks como TensorFlow e PyTorch oferecem uma variedade de modelos pré-treinados. Você não precisa reinventar a roda ou gastar horas ou mesmo dias para treinar um modelo a partir do zero. Aprenda a trabalhar com Transfer Learning e mantenha o foco no seu objetivo. Seu objetivo não é criar modelos e sim resolver problemas de negócio. Aprenda a usar Transfer Learning.

Regra 46: Generalização Através de Regularização

Ao criar um modelo de Machine Learning queremos que ele seja generalizável, ou seja, depois de aprender com dados de treino o modelo deve ser capaz de fazer previsões ou extrair padrões em novos conjuntos de dados. Generalização significa que o modelo não deve aprender os detalhes dos dados de treino, mas sim a relação matemática geral nos dados.

Uma maneira de ajudar seu modelo a generalizar além do conjunto de treinamento é colocar penalidades no tamanho dos pesos w do seu modelo. Isso se chama regularização. Duas penalidades populares são a norma de Manhattan (ou norma L₁) e a norma euclidiana “padrão” (ou norma L₂).

Ao regularizar, verifique se todos os recursos são dimensionados para ordenar a unidade (sem dimensão) por padronização. Isso garante que a penalidade afete todos os pesos igualmente. As estimativas de Ball Park podem ser obtidas estudando dois casos de regressão linear que podem ser resolvidos de forma fechada, a saber, Regressão Lasso (isto é, L₁ regularização λ₁|w|₁ de pesos w) e Regressão de Ridge (L₂ regularização λ₂|w|²₂ de pesos W). Quando os recursos são centrados e não correlacionados, suas soluções podem ser expressas em termos da solução não penalizada.

A Regularização LASSO corta (ou trunca) todos os coeficientes não penalizados abaixo de λ₁. Um ponto de partida razoável pode, portanto, ser λ₁ = 0,1.

A Regularização Ridge, por outro lado, apenas diminui o tamanho para zero. Para escolher λ₂, você pode querer levar em consideração até que ponto seu sistema está sobreajustado (overfitting).

Uma nota de advertência: O Scikit-Learn usa convenções ligeiramente diferentes para os objetivos em Ridge e Lasso.

Regra 47: Qual o Volume de Dados Ideal Para Treinar Modelos de Machine Learning?

Não existe regra mágica, mas a figura abaixo apresenta um ponto de partida:

Número de amostras (m), recursos (n) e parâmetros de modelo (d) formam a santíssima trindade do aprendizado de máquina. A maioria das regras de ouro pode ser amplamente trazida de volta a esta tríade.

Regra 48: Quantas Amostras Para Treinar Modelos de Machine Learning?

O desempenho normalmente escala como log m, onde m é o número de amostras e geralmente é limitado pelo ruído nos rótulos. Portanto, quando os dados de treinamento são rotulados por humanos, esse limite geralmente corresponde ao desempenho de nível humano. Logo, pode ser útil focar na qualidade dos dados, em vez da quantidade, conforme sugerido pelo movimento de IA centrada em dados.

Em geral, mais amostras são necessárias para problemas de regressão do que para problemas de classificação.

Regra 49: Quantos Parâmetros?

Lembre-se de sua aula de álgebra linear lá no ensino médio, que para resolver um sistema linear com d graus de liberdade, você precisa de d restrições. Para regressão linear, cada amostra é uma restrição.

Portanto, para fixar os parâmetros d, você precisa de pelo menos tantas amostras — caso contrário, seu sistema é considerado subdeterminado. De forma mais geral, ao interpretar os parâmetros de um modelo como graus de liberdade, uma heurística comum é um sistema dez vezes sobredeterminado:

d ≤ m/10

embora limites mais conservadores para redes neurais, como d ≤ m/50, também sejam sugeridos. Por sua vez, ter determinado o número de parâmetros, d, pode ajudá-lo a decidir se o número de recursos, n, precisa ser reduzido.

No entanto, é necessário cautela porque para muitos modelos, por exemplo, modelos probabilísticos, o número de restrições pode ser O(n) e independente do tamanho da amostra m.

Regra 50: Não Termina Aqui. Isso Foi Só o Começo

Existem 3 fases do aprendizado:

Fase 1 – Você não sabe o que não sabe.
Fase 2 – Você sabe o que não sabe.
Fase 3 – Você sabe o que sabe.

Ao finalizar a leitura deste livro esperamos que você tenha passado da Fase 1 para a Fase 2, quando o assunto é aprendizado de máquina.

Há muito ainda para aprender sobre Inteligência Artificial e este livro foi apenas o começo!

Sucesso na sua jornada!

E agora sua surpresa.

Para ajudar na sua capacitação estamos lançando a mais nova Formação DSA:

Formação Engenheiro de Inteligência Artificial

Um programa que traz para você as mais modernas técnicas de IA através de uma série de laboratórios práticos e projetos realmente incríveis em diferentes áreas de negócio.

Veja abaixo a sequência e descrição dos 6 cursos da Formação Engenheiro de IA:

1- Deep Learning Para Aplicações de IA com PyTorch e Lightning

Este é o ponto de partida da Formação. Aqui você aprenderá como construir modelos de Deep Learning, as principais arquiteturas, como pré-processar os dados, como otimizar os modelos e como realizar o deploy. Os frameworks PyTorch e Pytorch Lightning serão usados em Linguagem Python.

Este é um curso completo de Deep Learning, hoje a principal técnica de Inteligência Artificial, com o framework de maior sucesso da atualidade, o PyTorch. E vamos trazer também para você o Lightning, biblioteca que simplifica a forma como criamos modelos com o PyTorch aumentando a produtividade na construção dos modelos e a performance das aplicações de Inteligência Artificial.

Depois de mais de 5 anos capacitando milhares de alunos em Deep Learning através de diversos outros treinamentos, neste novo curso oferecido pela DSA você vai desenvolver suas habilidades em IA com o estado da arte em Deep Learning através de Estudos de Caso, Labs, Mini-Projetos e Projetos.

2- Análise de Imagens com Inteligência Artificial

Aqui é onde a diversão começa. Você vai trabalhar com uma das principais áreas da Inteligência Artificial, a Visão Computacional. Através de labs e projetos de diferentes áreas, você aprenderá como construir modelos de IA capazes de detectar, classificar e segmentar imagens dos mais variados tipos.

Este curso traz para você modernas técnicas de Visão Computacional para análise de todo tipo de imagem, como imagens médicas, imagens de satélite, imagens de plantações agrícolas, imagens de objetos, imagens de pessoas para reconhecimento facial e você ainda vai aprender como criar seu próprio dataset de imagens customizado e como detectar Deep Fakes.

Visão Computacional é atualmente uma das principais áreas da Inteligência Artificial. Um conjunto de técnicas para carregar, manipular, tratar, processar, detectar, prever, segmentar e analisar imagens. E neste curso, de alto nível, vamos trazer as principais técnicas e ferramentas para você, incluindo Vision Transformers.

O curso é inteiramente orientado a projetos. Isso significa que a cada capítulo você vai trabalhar em um problema do mundo real com dados reais (disponíveis publicamente) e então vai desenvolver suas habilidades através de aulas teóricas que exploram os principais conceitos e aulas práticas que implementam a solução. E em um dos capítulos vamos ensinar como você cria seu próprio dataset de imagens customizado.

3- Processamento de Linguagem Natural com Transformers

O terceiro curso da Formação é sobre a área mais complexa da Inteligência Artificial. Pelo menos até o surgimento dos modelos Transformers, que estão revolucionando a forma como ensinamos o computador a fazer traduções de texto, reconhecer a voz humana ou classificar textos e mensagens por tópicos

Você deseja aplicar o Processamento de Linguagem Natural (PLN), com as mais modernas técnicas de IA, para resolver diferentes problemas nas áreas de Direito, Atendimento ao Cliente, Reconhecimento de Voz, Análise de Sentimento, Classificação de Texto e Detecção de Fake News? Então este curso é para você.

Este não é apenas um curso de PLN. Este curso traz para você o estado da arte em Inteligência Artificial com Transformers e aplicações práticas em diversas áreas com projetos completos, incluindo a Dorothy, o Bot Transformer que você irá construir para automatizar o atendimento ao cliente. Imperdível.

4- Análise e Previsão de Séries Temporais com Inteligência Artificial

No quarto curso da Formação você vai aplicar Inteligência Artificial em problemas de negócio que requerem análise ao longo do tempo. Os principais métodos clássicos para análise de séries temporais, também serão abordados no começo do curso.

A análise de séries temporais é provavelmente uma das mais importantes habilidades dentro do universo da Ciência de Dados. Afinal, o fator tempo é determinante em quase tudo que ocorre no mundo dos negócios.

E com os avanços das técnicas de Inteligência Artificial conseguimos construir modelos cada vez mais precisos, capazes de entregar respostas aos tomadores de decisão que podem fazer toda a diferença nas estratégias corporativas.

Este é um curso de alto nível que vai trazer para você modernas técnicas de IA aplicadas a análise e previsão de séries temporais e comparar essas técnicas com os métodos clássicos (que também são abordados no curso).

5- Cyber Security Data Science

No curso número 5 você vai aplicar técnicas de Data Science e Inteligência Artificial para resolver problemas na área de segurança cibernética. Um curso incrível não apenas para quem deseja aplicar análise de dados na área de segurança, mas também em problemas comuns na área de tecnologia, como configuração de rede, configuração de sistema operacional e segurança de acesso.

Além de conhecer as principais ameaças e riscos cibernéticos, você vai aprender quais são as estratégias ideais de segurança, como trabalhar com dados reais e como usar Ciência de Dados e IA para detectar anomalias, tentativas de invasão, ataques a bancos de dados e dispositivos IoT, e muito mais.

6- Infraestrutura Como Código com Terraform, AWS, Azure e Databricks

O sexto e último curso é a cereja do bolo. Você vai desenvolver as habilidades necessárias para criar a infraestrutura necessária para treinar seus modelos, fazer o deploy e publicar aplicações usando IaC (Infraestrutura Como Código) através do Terraform, ferramenta open-source que simplifica de forma considerável a maneira como criamos, usamos e então desfazemos a infraestrutura necessária para o trabalho com Data Science, Machine Learning e IA.

IaC (Infraestrutura Como Código) nasceu no universo DevOps, mas rapidamente chegou à área de dados para ajudar no trabalho de Engenheiros de Dados, Engenheiros de Machine Learning, Arquitetos de Dados, Cientistas de Dados e Engenheiros de IA.

Além do Terraform você vai trabalhar com AWS, Azure e Databricks através de diversos Labs e Projetos. O conhecimento que você irá adquirir neste curso vai colocá-lo muito a frente de outros profissionais do mercado, aumentando de forma considerável sua empregabilidade na área de dados, independente da sua função.

Não é incrível?

Mas espere, tem mais.

Assim como as demais Formações DSA você ainda recebe os Módulos Extras de Capacitação Profissional com os seguintes cursos de bônus:

Introdução à Lógica de Programação
Sistema Operacional Linux, Docker e Kubernetes
Governança de Dados
Empreendedorismo em Data Science, IA e Blockchain
Web Scraping e Análise de Dados
Soft Skills – Desenvolvendo Suas Habilidades Comportamentais
E-Gov Analytics
Machine Learning com JavaScript e Go
Data Science e Machine Learning com Linguagem Julia

A Formação está disponível em nosso portal. Confira:

Formação Engenheiro de IA

Obrigado

Equipe DSA

Capítulo 99 – Machine Learning – Guia Definitivo – Parte 9

Nos 10 capítulos finais (de 91 a 100) deste livro online vamos trazer um grande resumo sobre Machine Learning. O objetivo é fornecer uma visão clara do que é e como Machine Learning está sendo usado no dia a dia, um pouco de matemática, as principais regras e princípios. Queremos ainda que esses capítulos finais possam servir de material de referência para os alunos que estão buscando as certificações oferecidas pela DSA no Bootcamp de Certificação.

Serão 10 partes no total com um guia completo sobre Machine Learning. Aproveite a leitura para compreender de forma definitiva o que é uma das tecnologias mais incríveis do nosso tempo.

Neste capítulo vamos continuar abordando algumas regras que iniciamos no capítulo anterior e que raramente você verá sendo explicadas nos cursos em geral por aí, pelo simples fato que muitos que ensinam Machine Learning nunca colocaram um modelo em produção. Vamos agora responder à seguinte pergunta: Quais são as estratégias ideais para o deploy de modelos de Machine Learning?

Boa leitura!

Regra 36: Deploy do Modelo Como Web Service

A maneira mais simples de implantar um modelo de aprendizado de máquina é criar um web service para entregar as previsões do modelo. Um web service é um sistema de software que suporta interação máquina a máquina interoperável em uma rede.

Para criar um web service de aprendizado de máquina, você precisa de pelo menos três etapas:

– O primeiro passo é criar um modelo de aprendizado de máquina, treiná-lo e validar seu desempenho, normalmente tarefa de um Cientista de Dados.

– Na segunda etapa, precisamos persistir o modelo, ou seja, gravar o modelo em um arquivo no disco. O ambiente em que implantamos o web service geralmente é diferente de onde treinamos o modelo. Assim, essa separação ajuda as empresas a otimizar seus orçamentos e esforços. Aplicamos a serialização para persistir o modelo em disco e isso pode ser feito através de diferentes bibliotecas em Linguagens Python, R, Scala, C++ ou Java.

– Finalmente, na terceira etapa, podemos servir o modelo usando um framework web ou serviço na nuvem. O modelo é hospedado em um ambiente diferente, geralmente em um servidor na nuvem. A partir do framework web implementamos o web service que será responsável por receber os novos dados, passá-los ao pipeline de processamento e ao modelo, receber a resposta com a previsão e entregar de volta ao chamador.

Implementar um web service é normalmente tarefa de um Engenheiro de Machine Learning e temos diversas ferramentas para esse propósito.

Regra 37: Deploy do Modelo Para Previsões em Batch

Podemos fazer o deploy de modo que os modelos de Machine Learning forneçam previsões em tempo real (usando web service, por exemplo). Nesse caso chamamos de modelos online. Mas em diversas situações é preferível ter as previsões em batch (lote) e nesse caso chamamos de modelos offline.

Os modelos offline podem ser otimizados para lidar com um alto volume de instâncias e executar modelos mais complexos. Uma outra vantagem desse tipo de deploy é que normalmente podemos usar um único tipo de hardware sem preocupação com escalabilidade.

A previsão em lote pode ser tão simples quanto chamar a função de previsão com um conjunto de dados de variáveis de entrada. Isso pode ser feito via linha de comando, no Jupyter Notebook, no RStudio ou com script automatizado.

Às vezes, você terá que agendar o treinamento ou a previsão no método de processamento em lote. Existem várias maneiras de fazer isso. Uma alternativa é usar o Airflow ou o Prefect para automatizar a tarefa.

No entanto, a construção do modelo pode exigir vários estágios na estrutura de processamento em lote. Você precisa decidir quais recursos são necessários e como deve construir o modelo para cada estágio. O ideal é treinar o modelo em um sistema de computação de alto desempenho com uma estrutura de processamento em lote apropriada.

Normalmente, você particiona os dados de treinamento em segmentos que são processados sequencialmente, um após o outro. Você pode fazer isso dividindo o conjunto de dados usando um esquema de amostragem (por exemplo, amostragem balanceada, amostragem estratificada) ou por meio de algum algoritmo (por exemplo, map-reduce).

As partições podem ser distribuídas para várias máquinas, mas todas devem carregar o mesmo conjunto de recursos. O dimensionamento de recursos é recomendado. Se você usou pré-treinamento não supervisionado (por exemplo, codificadores automáticos) para Transfer Learning, deverá desfazer cada partição.

Após a execução de todos os estágios, você pode fazer previsões em novos dados com o modelo resultante iterando sequencialmente nas partições.

Regra 38: Deploy do Modelo em Dispositivos de Borda (Edge) Como Modelos Incorporados

A computação em dispositivos de borda (Edge Computing), como dispositivos móveis e IoT, tornou-se muito popular nos últimos anos. Os benefícios de implantar um modelo de aprendizado de máquina em dispositivos de borda incluem, mas não estão limitados a:

Latência reduzida, pois o dispositivo provavelmente estará mais próximo do usuário do que um servidor distante.

Reduz o consumo de largura de banda de dados à medida que enviamos os resultados processados de volta para a nuvem, em vez de dados brutos que geralmente são maiores e, eventualmente, consomem mais largura de banda.

Mas dispositivos de borda, como dispositivos móveis e IoT, têm poder de computação e capacidade de armazenamento limitados devido à natureza de seu hardware. Não podemos simplesmente implantar modelos de aprendizado de máquina diretamente nesses dispositivos da mesma forma que faríamos em um servidor, especialmente se nosso modelo for grande ou exigir computação extensiva para executar inferência neles.

Em vez disso, devemos simplificar o modelo usando técnicas como quantização e agregação, mantendo a precisão. Esses modelos simplificados podem ser implantados com eficiência em dispositivos de borda com computação, memória e armazenamento limitados.

Podemos usar a biblioteca TensorFlow Lite para simplificar nosso modelo TensorFlow. O TensorFlow Lite é uma biblioteca de software de código aberto para dispositivos móveis e incorporados que tenta fazer o que o nome diz: executar modelos do TensorFlow em plataformas móveis e incorporadas.

Regra 39: Monitoramento do Modelo em Produção

O estágio de monitoramento do ciclo de vida da Ciência de Dados começa após a implantação bem-sucedida de um modelo.

O monitoramento garante que o modelo esteja funcionando corretamente e que suas previsões sejam eficazes. Claro, não é apenas o modelo que precisa ser monitorado, principalmente durante as primeiras execuções. A equipe de implantação precisa garantir que o software e os recursos de suporte estejam funcionando conforme necessário e que os usuários finais tenham sido suficientemente treinados. Aqui normalmente temos Engenheiros DataOps e Engenheiros de Dados atuando.

Vários problemas podem surgir após a implantação: os recursos podem não ser adequados, o feed de dados pode não estar conectado corretamente ou os usuários podem não estar usando os aplicativos de forma adequada.

Depois que sua equipe determinar que o modelo e seus recursos de suporte estão funcionando corretamente, o monitoramento ainda precisa continuar, mas a maior parte disso pode ser automatizada até que surja um problema.

A melhor maneira de monitorar um modelo é avaliar rotineiramente seu desempenho em seu ambiente implantado. Este deve ser um processo automatizado, usando ferramentas que rastrearão as métricas para alertá-lo automaticamente caso haja alterações em sua precisão, precisão ou pontuação F.

Cada modelo implantado tem o potencial de se degradar ao longo do tempo devido a problemas como:

– Variação nos dados. Muitas vezes, os dados fornecidos ao modelo na implantação não são limpos da mesma maneira que os dados de treinamento e teste, resultando em alterações na implantação do modelo.

– Alterações na integridade dos dados. Ao longo de semanas, meses ou anos, as alterações nos dados que estão sendo alimentados no modelo podem afetar negativamente o desempenho do modelo, como alterações nos formatos, campos renomeados ou novas categorias.

– Desvio de dados. Mudanças na demografia ou mudanças no mercado podem causar desvios ao longo do tempo, tornando os dados de treinamento menos relevantes para a situação atual e os resultados do modelo, portanto, menos precisos. Por isso o modelo deve ser re-treinado periodicamente.

– Mudança de conceito. Mudanças nas expectativas dos usuários finais sobre o que constitui uma previsão correta podem mudar ao longo do tempo, tornando as previsões do modelo menos relevantes.

Usando uma plataforma de Ciência de Dados corporativa, você pode monitorar automaticamente cada um desses problemas, usando uma variedade de ferramentas de monitoramento, e fazer com que a equipe de Ciência de Dados seja alertada assim que a variação for detectada no modelo.

Regra 40: Planejar e Projetar Protocolos Robustos de Monitoramento, Auditoria e Reciclagem

Antes de implantar e usar um modelo preditivo, você precisa entender se ele está realmente entregando o tipo de resultado que você estava procurando. Você deve verificar se esses resultados são precisos e também se os dados que você está carregando no modelo manterão esses modelos consistentes e relevantes ao longo do tempo. Além disso, dados muito antigos usados no treinamento podem criar desvios no modelo, levando a resultados imprecisos.

Isso implica que você deve criar processos de treinamento e pipelines que atraiam novos dados, monitorem suas fontes de dados internas e informem quais recursos ainda estão fornecendo informações importantes.

Você nunca deve ficar complacente em relação a isso, ou os modelos podem estar influenciando as decisões de negócio em direções inúteis. É essencial manter os processos em posição para monitorar os resultados, garantindo que você não esteja apenas configurando cada vez mais tipos de dados errados em seu modelo preditivo.

Você também deve realizar testes AB para descobrir o desempenho desses modelos em diferentes versões.

O próximo capítulo é o de número 100, o último deste livro. E você não pode deixar de conferir o que preparamos!

Referências:

Machine Learning com Python e R

Machine Learning com Python e C++

Deploy de Modelos de Machine Learning

Capítulo 98 – Machine Learning – Guia Definitivo – Parte 8

Serão 10 partes no total com um guia completo sobre Machine Learning. Aproveite a leitura para compreender de forma definitiva o que é uma das tecnologias mais incríveis do nosso tempo.

Neste capítulo vamos abordar algumas regras que raramente você verá sendo explicadas nos cursos em geral por aí, pelo simples fato que muitos que ensinam Machine Learning nunca colocaram um modelo em produção: Como analisar um modelo existente e melhorá-lo? Isso é mais uma arte do que uma ciência e existem vários padrões e técnicas que ajudam com essa tarefa.

Boa leitura!

O Que é o Deploy de Modelos de Machine Learning?

Antes de trazer as regras para você, vamos compreender claramente o que é colocar um modelo em produção, o que tem vários sinônimos: servir o modelo, implantar o modelo, fazer o deploy do modelo.

Os modelos de Machine Learning (ML) quase sempre são desenvolvidos em uma configuração offline, mas devem ser implantados em um ambiente de produção para fazer previsões ou detectar padrões com novos dados e, então, agregar valor.

O objetivo de construir um aplicativo de aprendizado de máquina é resolver um problema e um modelo de ML só pode fazer isso quando está sendo usado ativamente em produção.

Como tal, a implantação do modelo de ML é tão importante quanto o desenvolvimento do modelo de ML. Cientistas de Dados desenvolvem os modelos e Engenheiros de Machine Learning fazem o deploy.

A implantação é o processo pelo qual um modelo de ML é movido de um ambiente offline e integrado a um ambiente de produção, como um aplicativo ativo. É uma etapa crítica que deve ser concluída para que um modelo atenda ao propósito pretendido e resolva os desafios para os quais foi projetado.

O processo exato de implantação do modelo de ML será diferente dependendo do ambiente do sistema, do tipo de modelo e dos processos de DataOps e MLOps implementados em cada empresa.

Agora vamos às regras com dicas valiosas.

Regra 23: Você Não Deve Fazer os Testes Finais no Modelo

Você (Cientista de Dados, Engenheiro de Machine Learning ou Engenheiro de IA) não é um usuário final do modelo. Você não deve ser o responsável pelos testes finais quando o modelo estiver próximo de ser colocado em produção.

Em última instância um modelo de Machine Learning é uma peça de software e uma regra básica da Engenharia de Software é que os testes devem ser feitos por quem não desenvolveu a solução. Ensinamos isso no primeiro curso da Formação Engenheiro de Machine Learning.

Os testes finais de um modelo de Machine Learning devem ser feitos por usuários, preferencialmente usuários que irão usar o sistema ou que serão responsáveis pelo suporte ao usuário final.

Regra 24: Obtenha Feedback Contínuo

Uma vez que o modelo seja colocado em produção e testado pelos usuários, isso não significa que o trabalho acabou. Muito pelo contrário. O modelo deve ser constantemente monitorado e novas rodadas de validação e testes com os usuários finais devem ser realizadas. Quanto mais feedback você obter sobre o uso do modelo, mais fácil identificar e corrigir problemas.

Para obter feedback contínuo, considere perguntas como essas:

Como podemos obter o feedback dos modelos de produção?
Como podemos garantir uma entrega constante?
Como podemos testar novas iterações do modelo?
Como podemos iterar nosso modelo sem interromper sua operação?

Crie uma base de conhecimento com o feedback contínuo do modelo em produção e o uso de Machine Learning se torna algo de valor cada vez maior para a empresa.

Regra 25: Calcule o Delta Entre os Modelos

Se você já tiver um modelo de Machine Learning em produção e está preparando uma nova versão do modelo, esse é um bom momento para calcular a diferença de performance entre ambos. Por isso a regra 24 anterior é tão importante. Com a ajuda da validação feita por um usuário final, você pode calcular e medir a diferença de performance entre o modelo atual em produção e o novo modelo com as melhorias.

Além de criar documentação, permite demonstrar a evolução do trabalho e como a empresa está conseguindo construir modelos cada vez melhores. E o contrário também é verdadeiro. Uma mudança que poderia melhorar a performance pode, na verdade, piorá-la e esse é o momento de detectar isso.

Calculando o delta da diferença de performance, podemos facilmente responder perguntas do tipo: Qual o percentual de melhoria de performance do modelo em produção depois das alterações realizadas? Qual foi o custo dessa melhoria? Quanto tempo foi necessário?

Regra 26: Ao Atualizar Modelos, a Solução do Problema é Mais Importante do Que o Poder Preditivo

Seu modelo pode tentar prever a taxa de cliques, por exemplo. No entanto, no final, a questão-chave é o que você faz com essa previsão. Se você estiver usando o modelo para classificar documentos, a qualidade da classificação final importa mais do que o poder de previsão.

Machine Learning não é um fim. É um meio para resolver problemas. Logo, a performance geral do sistema é mais importante do que o poder preditivo do modelo.

Imagine um modelo usado para previsão se uma mensagem é spam ou não. O modelo não precisa ser 100% eficaz. Se conseguir prever que um documento é spam com 55% de probabilidade isso já é suficiente e a performance final do sistema (ter cada mensagem classificada como spam ou não) será ótima.

É comum tentar levar o modelo ao limite da perfeição (como se isso fosse realmente possível), quando na verdade o poder de previsão é menos importante do que o resultado em si.

Regra 27: Procure Padrões nos Erros do Modelo em Produção e Crie Novos Recursos

Suponha que você veja um exemplo de que o modelo em produção errou na previsão. Em uma tarefa de classificação, esse erro pode ser um falso positivo ou um falso negativo. Em uma tarefa de classificação, o erro pode ser um par em que um positivo foi classificado abaixo de um negativo.

O ponto mais importante é que este é um exemplo de que o sistema de aprendizado de máquina sabe o que deu errado e gostaria de corrigir se tivesse a oportunidade. Se você fornecer ao modelo um recurso que permita corrigir o erro, o modelo tentará usá-lo.

Logo, se o modelo em produção foi treinado com 10 recursos (10 variáveis), pode ser que a inclusão de mais um recurso aumente de forma significativa a performance do modelo. Por isso é tão importante monitorar o modelo em produção, pois o padrão que havia nos dados usados no treinamento pode mudar ao longo do tempo e novos recursos podem ser necessários.

Regra 28: Tente Quantificar o Comportamento Indesejável Observado

É natural que um modelo tenha perda de performance ao longo do tempo. Os eventos que geraram os dados mudam, os padrões de comportamento mudam, os dados mudam.

Em determinado momento, um modelo em produção pode começar a apresentar comportamento indesejado, indicando que sua performance está deteriorando. Mas qual o limite aceitável e como quantificar isso?

O ideal nesse caso é criar uma métrica para quantificar o comportamento indesejado. Por exemplo, se é aceitável um modelo classificar mensagens como spam com 55% de probabilidade, se esse valor for reduzido para 52% é hora de tomar alguma ação. Ou seja, não temos que esperar o modelo começar a errar para então otimizá-lo.

A regra geral é “medir primeiro, otimizar depois”. Não caia na tentação de querer otimizar algo que você não mediu antes.

Regra 29: Esteja Ciente de Que Comportamento Idêntico de Curto Prazo Não Implica Comportamento Idêntico de Longo Prazo

A mudança é a regra.

Uma boa estratégia depois que os dados estiverem em produção é continuar coletando novos dados e retreinar o modelo periodicamente. Algumas empresas retreinam seus modelos todos os dias, algumas uma vez por semana e isso vai depender do volume de dados disponível.

Mas o fato é que mudanças de comportamento são esperadas e o modelo não pode ficar muito tempo sem atualização. É possível criar um repositório de versionamento de modelos para garantir que tenhamos sempre a versão mais atual disponível em produção. E mesmo se o modelo parece apresentar boa performance por vários dias seguidos, isso não é garantia que irá permanecer assim por muito tempo.

Regra 30: Reutilize o Código Entre o Pipeline de Treinamento e o Pipeline de Deploy Sempre que Possível

O processamento em lote é diferente do processamento online. No processamento online, você deve lidar com cada solicitação à medida que ela chega (por exemplo, você deve fazer uma pesquisa separada para cada consulta), enquanto no processamento em lote, você pode combinar tarefas (por exemplo, fazer uma junção).

Quando o modelo está em produção, você está fazendo o processamento online, enquanto o treinamento do modelo é uma tarefa de processamento em lote. No entanto, há algumas coisas que você pode fazer para reutilizar o código.

Por exemplo, você pode criar um objeto que seja específico do seu sistema onde o resultado de quaisquer consultas ou junções pode ser armazenado de uma maneira muito legível e os erros podem ser testados facilmente. Então, depois de reunir todas as informações, com o modelo em produção ou em treinamento, você executa um método comum para fazer a ponte entre o objeto legível por humanos específico do seu sistema e qualquer formato que o sistema de aprendizado de máquina espera.

Isso elimina uma fonte de distorção entre o modelo em produção e o treinamento. Tente não usar duas linguagens de programação diferentes entre treinar e servir. Essa decisão tornará quase impossível compartilhar código.

Regra 31: Se Você Produzir um Modelo com Base nos Dados até 5 de Janeiro, Teste o Modelo nos Dados de 6 de Janeiro em Diante

Em geral, meça o desempenho de um modelo nos dados coletados após os dados nos quais você treinou o modelo, pois isso reflete melhor o que seu sistema fará em produção.

Se você produzir um modelo com base nos dados até 5 de janeiro, teste o modelo nos dados a partir de 6 de janeiro, por exemplo. Você esperará que o desempenho não seja tão bom nos novos dados, mas não deve ser radicalmente pior.

Como pode haver efeitos diários, você pode não prever a taxa média de cliques ou a taxa de conversão, mas a área sob a curva, que representa a probabilidade de dar ao exemplo positivo uma pontuação mais alta do que a um exemplo negativo, deve ser razoavelmente próxima.

Regra 32: Na classificação binária para filtragem (como detecção de spam ou determinação de e-mails interessantes), faça pequenos sacrifícios de curto prazo no desempenho para obter dados limpos

Em uma tarefa de filtragem, os exemplos marcados como negativos não são mostrados ao usuário final da aplicação que contém o modelo de Machine Learning.

Suponha que você tenha um filtro que bloqueie 75% dos exemplos negativos em produção. Você pode ficar tentado a extrair dados de treinamento adicionais das instâncias mostradas aos usuários. Por exemplo, se um usuário marca um e-mail como spam que seu filtro deixou passar, você pode querer aprender com isso.

Mas essa abordagem introduz viés de amostragem. Você pode coletar dados mais limpos se, com o modelo em produção, rotular 1% de todo o tráfego como “retido” e enviar todos os exemplos retidos ao usuário. Agora seu filtro está bloqueando pelo menos 74% dos exemplos negativos. Esses exemplos retidos podem se tornar seus dados de treinamento.

Observe que se o seu filtro estiver bloqueando 95% dos exemplos negativos ou mais, essa abordagem se tornará menos viável. Mesmo assim, se você deseja medir o desempenho em produção, pode fazer uma amostra ainda menor (digamos 0,1% ou 0,001%). Dez mil exemplos são suficientes para estimar o desempenho com bastante precisão.

Regra 33: Evite Loops de Feedback com Características Posicionais

A posição do conteúdo afeta drasticamente a probabilidade de o usuário interagir com ele. Se você colocar um botão na primeira posição no topo de uma página, ele será clicado com mais frequência do que um botão no final da página. A posição fará com que um botão seja muito mais clicado do que o outro e isso pode dar a impressão que o primeiro botão é melhor. Não. Ele apenas está posicionado de forma que o cérebro humano o percebe primeiro.

Uma maneira de lidar com isso é adicionar características posicionais, ou seja, características sobre a posição do conteúdo na página. Você treina seu modelo com recursos posicionais e ele aprende a ponderar, por exemplo, o recurso “1stposition” fortemente. Seu modelo, portanto, dá menos peso a outros fatores para exemplos com “1stposition=true”.

Então, ao servir o modelo, você não dá a nenhuma instância o recurso posicional, ou dá a todos o mesmo recurso padrão, porque você está pontuando os candidatos antes de decidir a ordem na qual exibi-los.

Observe que é importante manter quaisquer recursos posicionais um pouco separados do restante do modelo devido a assimetria entre treinamento e teste. Ter o modelo como a soma de uma função dos traços posicionais e uma função do resto dos traços é o ideal. Por exemplo, não cruze os recursos posicionais com nenhum recurso de documento.

Regra 34: Medir a Distorção Entre Treinamento/Produção

Existem várias coisas que podem causar distorção no sentido mais geral. Além disso, você pode dividi-lo em várias partes:

A diferença entre o desempenho nos dados de treinamento e os dados de validação. Em geral, isso sempre existirá, e nem sempre é ruim.

A diferença entre o desempenho nos dados de validação e os dados do “dia seguinte”. Novamente, isso sempre existirá. Você deve ajustar sua regularização para maximizar o desempenho no dia seguinte. No entanto, grandes quedas no desempenho entre os dados de hoje e do dia seguinte podem indicar que alguns recursos são sensíveis ao tempo e possivelmente degradam o desempenho do modelo.

A diferença entre o desempenho nos dados do “dia seguinte” e os dados ao vivo. Se você aplicar um modelo a um exemplo nos dados de treinamento e o mesmo exemplo em produção, ele deverá fornecer exatamente o mesmo resultado. Assim, uma discrepância aqui provavelmente indica um erro na construção do modelo.

Regra 35: Prepara-se Para o Deploy Através de Containers

Hoje a tecnologia de containers (máquinas virtuais super leves) é quase um padrão em Machine Learning e Engenharia de Dados (e por isso o tema é abordado em detalhes nos cursos em nosso portal).

Ao fazer o deploy de um modelo você não estará enviando o modelo em si, mas um container com o modelo, suas dependências, arquivos de configuração, parâmetros e muito mais. Isso simplifica o deploy, mas requer cuidados adicionais, especialmente com o versionamento. Certifique-se que você domina a tecnologia de containers e conhece muito bem o Docker.

Continuaremos no próximo capítulo.

Referências:

Curso Gratuito de Sistema Operacional Linux, Docker e Kubernetes

Machine Learning com Python e R

Machine Learning com Python e C++

Rules of Machine Learning

Deploy de Modelos de Machine Learning

Capítulo 97 – Machine Learning – Guia Definitivo – Parte 7

Nos 10 capítulos finais deste livro online vamos trazer um grande resumo sobre Machine Learning. O objetivo é fornecer uma visão clara do que é e como Machine Learning está sendo usado no dia a dia, um pouco de matemática, as principais regras e princípios. Queremos ainda que esses capítulos finais possam servir de material de referência para os alunos que estão buscando as certificações oferecidas pela DSA no Bootcamp de Certificação.

Serão 10 partes no total com um guia completo sobre Machine Learning. Aproveite a leitura para compreender de forma definitiva o que é uma das tecnologias mais incríveis do nosso tempo.

Neste capítulo vamos seguir explicando para você dezenas de regras e princípios sobre Machine Learning para resolver problemas de negócio, agora com ênfase na Engenharia de Atributos (Feature Engineering).

Boa leitura!

Engenharia de Atributos

A Engenharia de Atributos (também chamada de Engenharia de Recursos) é uma das partes mais importantes e ao mesmo tempo mais complexas em Machine Learning.

Quando estamos diante de um problema e recebemos os dados, não sabemos previamente se cada variável (cada atributo ou recurso) é realmente útil ou não. Também não sabemos se a combinação de variáveis pode ser mais interessante do que o uso de variáveis individuais. Ou ainda, não sabemos se outros atributos serão necessários. E como resolvemos isso?

Através da experimentação, trabalho fundamental do Cientista de Dados. Ou seja, diversos experimentos devem ser feitos com diferentes atributos a fim de chegar no conjunto ideal para resolver determinado problema. E diversas técnicas podem ser usadas na Engenharia de Atributos, técnicas que são ensinadas nos cursos da DSA.

Mas depois que o modelo está criado e em produção, será que podemos melhorar sua performance incluindo mais atributos ou modificando atributos já usados pelo modelo? Afinal, o padrão previamente detectado nos dados pode mudar ao longo do tempo e a performance do modelo será reduzida de forma gradual. Logo, mesmo depois que o modelo estiver em produção o trabalho de Engenharia de Atributos continua, mas nesse caso passa a ser responsabilidade do Engenheiro de Machine Learning.

Vamos continuar listando as regras e princípios em Machine Learning e agora compreender algumas técnicas fundamentais ao trabalhar com Engenharia de Atributos. Algumas das técnicas listadas aqui são de nível avançado e requerem boa experiência em Machine Learning e no processo de Ciência de Dados.

Regra 16: O Processo é Iterativo

Não espere que o modelo em que você está trabalhando agora seja a última e perfeita versão. De fato, o modelo nunca será perfeito e raramente será a última versão. O processo é iterativo e contínuo.

Muitas equipes lançam um modelo para um determinado problema por trimestre ou por semestre (lembrando que cada problema de negócio vai requerer um modelo diferente). Existem três razões básicas para lançar novos modelos:

Você deseja usar novos recursos (atributos) testados recentemente.
Você está ajustando a regularização e combinando recursos antigos de novas maneiras.
Você está ajustando o objetivo.

Assim como qualquer sistema de software, um modelo de Machine Learning tem o seu ciclo de vida e requer manutenção constante. Monitorando as métricas conseguimos detectar eventuais quedas de performance e tomar ações para que o modelo siga atendendo o propósito para o qual ele foi criado. A Engenharia de Atributos será, portanto, um processo constante.

Regra 17: Comece com Recursos Observados Diretamente em Oposição aos Recursos Aprendidos

Este pode ser um ponto controverso, mas evita muitas armadilhas. Em primeiro lugar, vamos descrever o que é um recurso aprendido.

Um recurso aprendido é um recurso gerado por um sistema externo (como um sistema de clustering não supervisionado) ou pelo próprio modelo (por exemplo, por meio de um modelo fatorado ou aprendizado profundo). Ambos podem ser úteis, mas podem ter muitos problemas, portanto, não devem estar na primeira versão do modelo.

Se você usar um sistema externo para criar um recurso, lembre-se de que o sistema externo tem seu próprio objetivo. O objetivo do sistema externo pode ser apenas fracamente correlacionado com seu objetivo atual. Se você capturar um instantâneo do sistema externo, ele poderá ficar desatualizado. Se você atualizar os recursos do sistema externo, os significados podem mudar. Se você usar um sistema externo para fornecer um recurso, saiba que essa abordagem requer muito cuidado.

Quem disse que seria fácil?

O principal problema com modelos fatorados e modelos profundos é que eles não são convexos. Assim, não há garantia de que uma solução ótima possa ser aproximada ou encontrada e os mínimos locais encontrados em cada iteração podem ser diferentes.

Essa variação torna difícil julgar se o impacto de uma mudança em seu sistema é significativo ou aleatório. Ao criar um modelo sem recursos profundos, você pode obter um excelente desempenho de linha de base (benchmark). Depois que essa linha de base for alcançada, você pode tentar abordagens mais esotéricas.

Regra 18: Combine Recursos Usando Discretização

Há várias maneiras de combinar e modificar recursos. Sistemas de aprendizado de máquina, como o TensorFlow, permitem que você pré-processe seus dados por meio de transformações. As duas abordagens mais comuns são “discretizações” e “cruzamentos”.

A discretização consiste em pegar um recurso contínuo e criar muitos recursos discretos a partir dele. Considere um recurso contínuo, como a idade. Você pode criar um recurso (um novo atributo) que terá o valor 1 quando a idade for menor que 18, outro recurso que o valor será 1 quando a idade estiver entre 18 e 35, etc. Podemos usar os quartis para fazer essa divisão.

Dependendo do problema, o recurso original contínuo pode apresentar melhor performance. Mas em um outro tipo de problema, o mesmo recurso de forma discretizada pode ser uma melhor opção. A discretização oferece ainda uma vantagem: pode ser mais fácil de compreender para os seres humanos e assim facilitar a interpretação dos resultados de um modelo.

No fim, precisamos experimentar. Isso faz parte do nosso trabalho em Ciência de Dados.

Regra 19: Combine Recursos Usando Cruzamento

Cruzamentos combinam duas ou mais colunas de recursos. Uma coluna de recursos, na terminologia do TensorFlow, é um conjunto de recursos homogêneos (por exemplo, {masculino, feminino}, {EUA, Canadá, México} etc.).

Um cruzamento é uma nova coluna de recurso com recursos em, por exemplo, {masculino, feminino} × {EUA, Canadá, México}. Esta nova coluna de recurso conterá o recurso (masculino, Canadá). Se você estiver usando o TensorFlow e disser ao TensorFlow para criar esse cruzamento para você, esse recurso (masculino, Canadá) estará presente em exemplos que representam homens canadenses. Observe que são necessárias grandes quantidades de dados para aprender modelos com cruzamentos de três, quatro ou mais colunas de recursos básicos. Isso é muito útil para regras de associação e sistemas de recomendação.

Cruzamentos que produzem colunas de recursos muito grandes podem se ajustar demais. Por exemplo, imagine que você está fazendo algum tipo de pesquisa e tem uma coluna de recurso com palavras na consulta e uma coluna de recurso com palavras no documento. Você pode combiná-los com um cruzamento, mas acabará com muitos recursos.

Ao trabalhar com texto, existem duas alternativas. O mais draconiano é um produto escalar. Um produto escalar em sua forma mais simples conta o número de palavras em comum entre a consulta e o documento. Este recurso pode então ser discretizado. Outra abordagem é uma interseção: assim, teremos um recurso que está presente se e somente se a palavra “pônei” estiver no documento e na consulta, e outro recurso que está presente se e somente se a palavra “o” estiver no documento e na consulta, por exemplo.

Regra 20: Use Recursos Muito Específicos Quando Puder

Com toneladas de dados é mais simples aprender milhões de recursos simples do que alguns recursos complexos.

Portanto, não tenha medo de grupos de recursos em que cada recurso se aplica a uma fração muito pequena de seus dados, mas a cobertura geral está acima de 90%. Você pode usar a regularização para eliminar os recursos que se aplicam a poucos exemplos.

Regra 21: Pesos dos Recursos

O número de pesos de recursos que você pode aprender em um modelo linear é aproximadamente proporcional à quantidade de dados que você possui.

Existem resultados fascinantes da teoria da aprendizagem estatística sobre o nível apropriado de complexidade para um modelo, mas essa regra é basicamente tudo o que você precisa saber. Muitos profissionais duvidam que algo possa ser aprendido com mil exemplos, ou que você precisaria de mais de um milhão de exemplos, porque eles ficam presos a um certo método de aprendizado. A chave é dimensionar seu aprendizado para o tamanho de seus dados. Por exemplo:

Se você estiver trabalhando em um sistema de classificação de pesquisa e houver milhões de palavras diferentes nos documentos e na consulta e tiver 1.000 exemplos rotulados, você deve usar um produto escalar entre os recursos de documento e consulta, TF-IDF e uma dúzia de outros recursos altamente projetados por humanos. Ou seja, 1000 exemplos, uma dúzia de recursos.

Se você tiver um milhão de exemplos, cruze as colunas de recurso de consulta e documento, usando regularização e possivelmente seleção de recurso. Isso lhe dará milhões de recursos, mas com a regularização você terá menos. Ou seja, 10 milhões de exemplos, talvez 100 mil recursos.

Se você tiver bilhões ou centenas de bilhões de exemplos, poderá cruzar as colunas de recursos com tokens de documento e consulta, usando seleção e regularização de recursos. Você terá um bilhão de exemplos e 10 milhões de recursos.

A teoria da aprendizagem estatística raramente fornece limites, mas dá uma ótima orientação para um ponto de partida.

Regra 22: Limpe os Recursos Que Você Não Está Mais Usando

Recursos não utilizados criam dívida técnica.

Se você achar que não está usando um recurso e que combiná-lo com outros recursos não está funcionando, remova-o de sua infraestrutura e do seu modelo (o modelo obviamente terá que ser retreinado sem aquele recurso).

Você deve manter sua infraestrutura limpa para que os recursos mais promissores possam ser testados o mais rápido possível. Se necessário, alguém sempre pode adicionar de volta seu recurso. Por isso as Features Stores (Lojas de Recursos) estão cada vez mais populares. São repositórios que armazenam os recursos já tratados e processados e que podem ser usados a qualquer momento. Leia mais sobre isso aqui.

Lembre-se da cobertura ao considerar quais recursos adicionar ou manter. Quantos exemplos são cobertos pelo recurso? Por exemplo, se você tiver alguns recursos de personalização, mas apenas 8% de seus usuários tiverem recursos de personalização, isso não será muito eficaz.

Se, por outro lado, você tem um recurso que cobre apenas 1% dos dados, mas 90% dos exemplos que têm o recurso são positivos, então será um ótimo recurso para adicionar.

Machine Learning não é mais um hype. É uma tecnologia usada pelas empresas no dia a dia e a gestão desse processo se torna cada vez mais importante.

Continuaremos no próximo capítulo.

Referências:

Formação Linguagem Python Para Data Science

Formação Machine Learning

Rules of Machine Learning

Capítulo 96 – Machine Learning – Guia Definitivo – Parte 6

Serão 10 partes no total com um guia completo sobre Machine Learning. Aproveite a leitura para compreender de forma definitiva o que é uma das tecnologias mais incríveis do nosso tempo.

E neste capítulo vamos seguir explicando para você dezenas de regras e princípios da aplicação de Machine Learning para resolver problemas de negócio!

Boa leitura!

Regras e Princípios

O terceiro grupo de regras e princípios é sobre definição de métricas e objetivos dos modelos de aprendizado de máquina. O segundo grupo foi descrito no capítulo anterior.

Regra 12: Métricas Técnicas x Métricas de Negócio

As métricas técnicas são aquelas triviais em Machine Learning: acurácia, precisão, recall para modelos de classificação e erro quadrático médio e coeficiente de determinação para podemos de regressão, por exemplo.

As métricas de negócio dizem respeito ao objetivo do modelo de Machine Learning. Se o modelo prevê a taxa e cliques em um anúncio de um portal, qual foi a taxa efetiva de cliques no anúncio? Ou ainda, se o modelo prevê a taxa de turnover de funcionários de uma empresa, qual foi a taxa efetiva de turnover?

Ajustar todas as essas métricas é bem complicado, mas no final das contas é esse nosso trabalho. Primeiro medimos as métricas técnicas usando os dados de teste antes do modelo seguir para produção e, então, medimos as métricas de negócio depois que o modelo está em produção, calculando as previsões do modelo e comparando com o resultado efetivo.

Uma boa acurácia nos dados de teste não significa necessariamente que o modelo terá uma boa performance mais tarde ao prever o clique em um anúncio, por exemplo. Por quê? Porque o padrão nos dados pode mudar. Usamos dados históricos para treinar a avaliar o modelo, logo, a acurácia é medida com dados históricos. Já a métrica de negócio será medida com novos dados e o padrão pode ter mudado por conta de um feriado, mudança na preferência do usuário ou velocidade do web site. Se a métrica de negócio estiver ruim, devemos voltar e re-treinar o modelo com novos dados históricos. De fato, muitas empresas re-treinam seus modelos todos os dias, o que normalmente é trabalho de um Engenheiro de Machine Learning.

Regra 13: Defina qual objetivo você deseja otimizar

Existem dúzias de métricas com as quais você se importa e você deve medir todas elas. No entanto, no início do processo de aprendizado de máquina, você notará que todas elas estão subindo, mesmo aquelas que você não otimiza diretamente. Por exemplo, suponha que você se preocupe com o número de cliques e o tempo gasto no web site. Se você otimizar seu modelo para prever com mais precisão o número de cliques, provavelmente verá melhoria na métrica que prevê o tempo gasto no web site. Isso é comum no começo do ciclo de vida de modelos de Machine Learning.

Portanto, mantenha as coisas simples e não pense muito em equilibrar métricas diferentes quando você ainda pode aumentar facilmente todas as métricas. No entanto, não leve essa regra longe demais: não confunda seu objetivo com a saúde final do sistema. Queremos um modelo equilibrado sendo executado em produção.

Regra 14: Escolha uma métrica simples, observável e atribuível para seu primeiro objetivo

Muitas vezes você não sabe qual é o verdadeiro objetivo. Você pensa que sabe, mas ao observar os dados e analisar os resultados do modelo de Machine Learning, percebe que deseja ajustar o objetivo.

Além disso, diferentes membros da equipe de Data Science muitas vezes não conseguem concordar com o verdadeiro objetivo. O objetivo de um modelo de Machine Learning deve ser algo que seja fácil de medir e seja um proxy para o objetivo “verdadeiro”. Portanto, treine o modelo com um objetivo simples e considere ter uma “camada de política” no topo que permita adicionar lógica complementar (esperamos uma lógica muito simples) para fazer a classificação final. Ou seja, sobre a previsão feita pelo modelo adicionamos uma lógica definida por seres humanos (ensinamos isso em diversos cursos na Data Science Academy). Lembre-se: Machine Learning é um meio e não um fim.

A coisa mais fácil de modelar é um comportamento do usuário que é observado diretamente e atribuível a uma ação do sistema:

Este link classificado foi clicado?
Este objeto foi classificado?
Este objeto classificado foi baixado?
Este objeto classificado foi encaminhado/respondido/enviado por e-mail?
Este objeto mostrado foi marcado como spam/ofensivo?

Evite modelar efeitos indiretos no início:

O usuário visitou o web site no dia seguinte?
Quanto tempo o usuário visitou o site?
Quais eram os usuários ativos diários?

Os efeitos indiretos são ótimas métricas e podem ser usados durante o Teste A/B e durante as decisões de lançamento. Os alunos estudam Testes A/B no curso de Business Analytics.

Por fim, não tente fazer o aprendizado de máquina descobrir:

O usuário está satisfeito com o produto?
O usuário está satisfeito com a experiência?
O produto está melhorando o bem-estar geral do usuário?
Como isso afetará a saúde geral da empresa?

Tudo isso é importante, mas também incrivelmente difícil de medir. Em vez disso, use proxies: se o usuário estiver satisfeito, ele permanecerá no site por mais tempo. Se o usuário estiver satisfeito, ele visitará novamente o web site amanhã. No que diz respeito ao bem-estar e à saúde da empresa, o julgamento humano é necessário para conectar qualquer objetivo de Machine Learning à natureza do produto que sua empresa está vendendo e ao plano de negócios.

Regra 15: Começar com um modelo interpretável facilita a depuração

Regressão linear e regressão logística são diretamente motivadas por um modelo probabilístico. Cada previsão é interpretável como uma probabilidade ou um valor esperado. Isso os torna mais fáceis de depurar do que modelos que usam objetivos que tentam otimizar diretamente a precisão da classificação ou o desempenho da classificação. Por exemplo, se as probabilidades no treinamento se desviarem das probabilidades previstas lado a lado ou pela inspeção do sistema de produção, esse desvio pode revelar um problema.

Com modelos simples, é mais fácil lidar com loops de feedback. Muitas vezes, usamos essas previsões probabilísticas para tomar uma decisão. Por exemplo, classificar as postagens em valor esperado decrescente (ou seja, probabilidade de clique/download/etc.). No entanto, lembre-se quando chegar a hora de escolher qual modelo usar, a decisão final importa mais do que a probabilidade dos dados fornecidos ao modelo.

Comece com modelos mais simples e interpretáveis para conquistar a confiança das áreas de negócio e gestores. Com o suporte deles será mais fácil avançar para o uso de modelos mais complexos.

Continuaremos no próximo capítulo.

Referências:

Formação Linguagem Python Para Data Science

Formação Machine Learning

Rules of Machine Learning