Este documento apresenta conceitos fundamentais de machine learning e MLOps, incluindo: (1) introdução à machine learning e seus algoritmos, (2) conceitos de MLOps e ciclo de vida MLOps, (3) boas práticas de codificação em Python para ML, e (4) arquitetura recomendada para ML na Databricks.
1. Introdução à Engenharia de
Machine Learning e MLOps
Databricks
Douglas Mendes – Engenheiro de Machine Learning
2. Sobre mim
• Douglas Mendes
• Engenheiro de Machine Learning
• linkedin.com/in/douglasmendes/
• https://github.com/DOUGLASMENDES
3. Agenda
• Conceitos
• Introdução à Machine Learning
• MLOps e Ciclo MLOps
• Devops vs MLOps
• CI/CD
• Boas Práticas de codificação python
• Model Serving
• Otimização de Modelos de Machine Learning
• Feature Store
• Governança em Ciência de Dados
• Repositório de Modelos - MLFlow
• Data Drift e Model Drift
• Experimentos e AutoML
• Arquitetura Databricks Recomendada
• Ferramentas
• Databricks Partner Connect
34. Algumas Distribuições
• Distribuição Normal
• conhecida como curva de sino porque parece um sino!
• a curva de densidade é simétrica
• é definida por sua média e desvio padrão
• é centrada em torno de sua média, com desvio padrão indicando sua
propagação
• no ponto x, a altura é
representada da seguinte forma:
35. Algumas Distribuições
• Distribuição Normal Padrão
• A curva de distribuição Normal Padrão tem:
• Média = 0
• Desvio padrão = 1
• Podemos converter dados normalmente
distribuídos para que sigam uma normal
padrão subtraindo a média e dividindo pelo
desvio padrão
36. Algumas Distribuições
• Distribuição Normal Padrão
• Para dados normalmente distribuídos:
• 68,3% das observações estão dentro de 1
desvio padrão da média (-1,1)
• 95% das observações estão dentro de 2
desvios padrão da média (-2,2)
• 99,7% das observações estão dentro de 3
desvios padrão da média, intervalo (-3,3)
37. Algumas Distribuições
• Distribuição de Poisson
• é a distribuição de probabilidade discreta do
número de eventos que ocorrem em um
determinado período de tempo.
• é extremamente útil para fins de
planejamento, pois permite que gerentes
analisem o comportamento do cliente
enquanto visitam um restaurante ou loja,
por exemplo.
38. Algumas Distribuições
• Distribuição de Poisson
• Exemplo:
• um gerente de restaurante deseja saber quantos
clientes visitam a loja. Ele sabe que a média de
visitantes é de 5, mas o número real pode mudar
drasticamente.
• Uma distribuição de Poisson permite ao
gerente analisar a probabilidade de vários
eventos.
• Probabilidade de 0 clientes virem ao restaurante.
• Probabilidade de 7 ou mais clientes no
restaurante.
39. Algumas Distribuições
• Distribuição de Poisson
• Quando aplicar a distribuição de Poisson?
• Os eventos são independentes, se um evento
ocorrer, não afeta a probabilidade de outro
evento acontecendo também.
• A taxa de ocorrência do evento é constante
• A probabilidade de ocorrência de um evento é
proporcional ao período de tempo.
40. Algumas Distribuições
• Distribuição de Poisson
• EXEMPLO:
• Você é gerente de uma concessionária de carros e a média de carros vendidos é de 2
carros por dia. Qual é a probabilidade de que exatamente 5 carros sejam vendidos
amanhã?
• Solução
• Como temos 2 carros vendidos por dia, μ = 2.
• Como queremos saber a probabilidade de 5 carros serem vendidos amanhã, x = 5.
• Sabemos que e = 2,71828 (constante).
• Logo, a probabilidade de vender 5 carros amanhã é 0,036
41. Algumas Distribuições
• Distribuição Binomial
• mede a probabilidade de sucesso ou de
falha quando o experimento é repetido
várias vezes
• Ex: os resultados de fazer o exame de
Certificação Machine Learning são:
Passar ou Falhar
• Existem apenas dois resultados possíveis
com probabilidades fixas somando a um
42. Algumas Distribuições
• Distribuição Binomial
• Ex: um cara ou coroa tem apenas dois
resultados possíveis:
• cara ou coroa onde a probabilidade de
cada evento é exatamente = 0,5.
• Para N tentativas e probabilidade = π, a
distribuição binomial é calculado da
seguinte forma:
• onde P(x) é a probabilidade de x sucessos
em N tentativas, N é o número de
tentativas e π é a probabilidade de
sucesso.
43. Algumas Distribuições
• Distribuição de Bernoulli
• é um caso especial da distribuição binomial para n = 1.
• Simplificando, é uma distribuição binomial com uma única
tentativa (uma moeda ao ar)
• é uma distribuição de probabilidade discreta com apenas
dois resultados (“Sucesso” ou um “Fracasso”)
• Por exemplo, ao jogar uma moeda:
• Probabilidade de cara (sucesso) = 0,5
• Probabilidade de cauda (falha) = 1 – P = 0,5
• A probabilidade de uma falha é rotulada no eixo x como 0 e o
sucesso é rotulado como 1
• Conforme mostrado na figura, a probabilidade de sucesso (1)
é de 0,7 e a probabilidade de falha (0) é 0,3
44. Séries Temporais
• Tendências
• Em qualquer série temporal, existem 4 componentes importantes:
• 1. Nível: valor médio da série
• 2. Tendência: se a série está aumentando ou diminuindo em valor
• 3. Sazonalidade: repetição do ciclo de curto prazo na série
• 4. Ruído: variação aleatória não sistemática componente
45. Séries Temporais
• Modelos Aditivos vs Multiplicativos
• Existem dois tipos de modelos de séries temporais:
• aditivo e multiplicativo.
• Em modelos aditivos, a sazonalidade, tendência e componentes de erro são
adicionados.
• Em modelos multiplicativos, estes componentes são multiplicados.
49. Redes Neurais
• Função de Ativação Sigmóide:
• Recebe um número e o ajusta entre 0 e 1
• Converte números negativos grandes para 0 e números positivos grandes
para 1
• Geralmente utilizado na camada de saída
51. Redes Neurais
• Função de Ativação RELU (unidades lineares retificadas):
• Se entrada x <0, a saída é 0 e se x> 0 a saída é x
• Relu não satura, portanto, evita o problema do gradiente de fuga
• Utiliza limiar (threshold) simples para que seja computacionalmente eficiente
• geralmente usado em camadas ocultas
53. Redes Neurais
• Função de Ativação Tangente Hiperbólica:
• “Tanh” é semelhante ao sigmóide, o número converte entre -1 e 1
• Ao contrário do sigmóide, as saídas do Tanh são centradas em zero (intervalo:
-1 e 1)
• Na prática, Tanh é preferível ao sigmóide
55. Redes Neurais
• Rede Perceptron de Multicamadas (Multilayer Perceptron Network):
• A rede é representada por uma matriz (array) de pesos, entradas e saídas.
• Número total de parâmetros ajustáveis = 8:
• pesos = 6
• vieses = 2
58. Redes Neurais
• Rede Perceptron de Multicamadas (Multilayer Perceptron Network):
• Vamos conectar vários desses neurônios de maneira multicamada
• Quanto mais camadas ocultas, mais "profunda“ (deep) a rede ficará
60. Redes Neurais – Treinando uma rede
• Aprendizado supervisionado
• se houver um grande conjunto de dados de teste com rótulos conhecidos
(outputs)
• O algoritmo de aprendizado avalia a produção (ou seja: faz previsões),
compara a produção com o rótulo/anotação (label) e ajuste a rede. Depois,
repete
61. Redes Neurais – Treinando uma rede
• Aprendizado não supervisionado
• Usado com dados "não anotados" (não categorizados)
• (ex: cluster de K-Means)
• Como o algoritmo de aprendizado funciona com dados não anotados, não há
como avaliar a precisão da estrutura
• sugerido pelo algoritmo
62. Treinando o modelo
• Aprendizado por reforço
• O algoritmo de aprendizado toma ações que maximizam alguma noção de
recompensa cumulativa
• Com o tempo, a rede aprende a preferir o tipo certo de ação e evitar o errado
66. Redes Neurais
• Função Custo
• medida que quantifica o quão boa é a performance do modelo em relação
aos dados de treinamento
• equação que compara as previsões do modelo com os valores reais dos dados
de treinamento e retorna um valor numérico que indica o quão bem o
modelo está ajustando-se aos dados.
• O objetivo de ML é minimizar a função custo, para que o modelo possa fazer
previsões mais precisas
69. Redes Neurais
• Gradiente Descendente
• algoritmo de otimização que é usado para minimizar a função custo
• A ideia é iterativamente atualizar os parâmetros do modelo, como os pesos
das conexões entre os neurônios em uma rede neural, de maneira que a
função custo seja minimizada.
• O algoritmo calcula a derivada parcial da função custo em relação a cada
parâmetro do modelo e usa essa informação para ajustar os parâmetros na
direção que leva a uma redução da função custo
72. Redes Neurais
• Backpropagation
• método usado para treinar RNAs calculando o gradiente necessário para
atualizar os pesos da rede.
• É comumente usado pelo algoritmo de otimização de gradiente descendente
para ajustar o peso dos neurônios calculando o gradiente da função de perda.
73. Redes Neurais
• Backpropagation
• Fase 1: propagação
• Propagação pela rede para gerar o(s) valor(es) de saída
• Cálculo do custo (termo de erro)
• Propagação de ativações de saída através da rede usando o alvo do padrão de
treinamento para gerar os deltas (diferença entre os valores de saída desejados e reais)
74. Redes Neurais
• Backpropagation
• Fase 2: atualização de peso
• Calcular o gradiente de peso.
• Uma proporção (porcentagem) do gradiente do peso é subtraída do peso.
• Essa proporção influencia a velocidade e a qualidade do aprendizado e é chamada de
taxa de aprendizado. Quanto maior a razão, mais rápido o trem de neurônios, mas
quanto menor a razão, mais preciso é o treinamento.
75. Redes Neurais Profundas
(Deep Neural Networks) – Deep Learning
• Evolução das redes neurais
• compostas por camadas de
neurônios interconectados que
realizam operações matemáticas
em seus inputs e geram outputs
• termo "profundo" se refere ao fato
de que essas redes podem ter
muitas camadas, geralmente
dezenas ou centenas, o que
permite que elas aprendam
características mais complexas e
sutis dos dados
77. Redes Neurais Profundas
(Deep Neural Networks) – Deep Learning
• DeepFace - Taigman, Yang, Ranzato &Wolf, 2014
DeepFace: Closing the Gap to Human-Level Performance in Face Verification
https://research.fb.com/publications/deepface-closing-the-gap-to-human-level-performance-inface-verification/
79. Redes Neurais Profundas
(Deep Neural Networks) – Deep Learning
• podem ser treinadas por meio de técnicas de backpropagation
• ajustam os pesos das conexões entre os neurônios durante o processo de
aprendizado
• permitindo que a rede melhore sua capacidade de fazer previsões precisas
• principal característica: sua capacidade de aprender representações
hierárquicas e abstratas de dados
• podem ser usadas em tarefas complexas
• reconhecimento de fala
• visão computacional
• processamento de linguagem natural (NLP)
• outras áreas em que o modelo precisa aprender a partir de grandes quantidades de
dados
82. Redes Neurais Profundas
(Deep Neural Networks) – Deep Learning
• Muitas vezes é preciso melhorar a arquitetura da rede para obter
melhores previsões no modelo
84. Redes Neurais Profundas
(Deep Neural Networks) – Deep Learning
• Muitas vezes é preciso melhorar a arquitetura da rede para obter
melhores resultados
86. Processo para criação de modelos de
Machine Learning
• 1 – Identificar:
• tipo do problema
• qual o melhor algoritmo
• se usará Deep Learning ou não
• 2 – Separar os dados relevantes e prepara-los (dataprep)
• anotar os dados, caso não estejam anotados
• 3 – Treinar o algoritmo usando grande quantidade de dados anotados
(labeled)
• 4 – Testar a performance do modelo com dados não anotados
• 5 – Refazer até que a performance seja aceitável (Iterativo)
88. Hiperparâmetros
• Definição:
• parâmetros que não são aprendidos pelo algoritmo de treinamento
• são definidos pelo usuário antes do treinamento
• controlam o comportamento do algoritmo de ML
• afetam a precisão e a eficiência do modelo resultante
• Exemplos:
• número de camadas e neurônios em uma rede neural
• taxa de aprendizado do algoritmo de otimização
• número de árvores em uma floresta aleatória (random forest)
• valor de regularização para evitar overfitting
89. Hiperparâmetros
• Escolha adequada dos hiperparâmetros pode ser crucial para obter
um modelo com boa performance
• Muitas vezes é um processo iterativo que envolve testar diferentes
combinações de valores para os hiperparâmetros e avaliar o
desempenho do modelo resultante
91. Parâmetros e Hiperparâmetros
• Parâmetros:
• valores obtidos pelo processo de
treinamento, como:
• pesos da rede
• vieses (bias)
92. Papel do Engenheiro de Machine Learning
• Colocar em produção os modelos
de ciência de dados
• Conhecer o processo de criação de
modelos em Ciência de Dados
• Otimizar modelos
• Processos DevOps/MLOps
• Pipelines de dados para ML
• Integração dos dados para ML
• Conhecimento das ferramentas
usadas
• Cloud
• Backend
• Data Science
93. Métricas para Avaliação de Modelos
• Diferentes tipos de métricas
• Depende:
• tipo de problema
• algoritmo(s) aplicados
• dos dados
• do objetivos do modelo
94. Métricas para Avaliação de Modelos
• Acurácia (Accuracy)
• proporção de predições corretas em relação ao número total de predições
• Precisão (Precision)
• proporção de verdadeiros positivos (TP) em relação ao número total de
predições positivas (TP + FP)
• é importante quando é mais importante evitar falsos positivos (FP), ou seja,
quando é crucial que o modelo não faça uma previsão positiva quando na
verdade é negativa
95. Métricas para Avaliação de Modelos
• Recall (Sensibilidade ou Revocação)
• proporção de verdadeiros positivos (TP) em relação ao número total de
positivos (TP + FN)
• é importante quando é mais importante evitar falsos negativos (FN), ou seja,
quando é crucial que o modelo não perca uma previsão positiva quando na
verdade é positiva
• F1-score
• É a média harmônica da precisão e do recall, e é uma métrica que leva em
conta tanto os falsos positivos quanto os falsos negativos
97. Métricas para Avaliação de Modelos
• Log-loss
• usada em problemas de classificação que envolvem probabilidades
• mede a diferença entre as probabilidades previstas pelo modelo e as
probabilidades reais
• é uma métrica que penaliza mais fortemente as previsões erradas com uma
alta confiança
• Mean Squared Error (MSE)
• usada em problemas de regressão, que mede a diferença quadrática média
entre as previsões do modelo e os valores reais
98. Métricas para Avaliação de Modelos
• Root Mean Squared Error (RMSE)
• representa o desvio padrão dos resíduos (ou seja: diferenças entre previsões
do modelo e os valores verdadeiros/dados de treinamento).
• pode ser facilmente interpretado em comparação com o MSE porque as
unidades do RMSE correspondem às unidades da saída.
• fornece uma estimativa de quão grandes os resíduos estão sendo dispersos.
• é calculado da seguinte forma:
99. Métricas para Avaliação de Modelos
• KS (Kolmogorov-Smirnov)
• avalia a qualidade de um modelo de classificação binária
• mede a diferença entre duas distribuições cumulativas: uma distribuição de
exemplos positivos (classe positiva) e uma distribuição de exemplos negativos
(classe negativa)
• Para calcular o KS:
• 1. ordenar as previsões do modelo para cada exemplo do conjunto de dados em ordem
decrescente de probabilidade de pertencer à classe positiva
• 2. é calculada a distribuição cumulativa para a classe positiva e para a classe negativa. A
métrica KS é a maior diferença entre essas duas distribuições cumulativas.
100. Métricas para Avaliação de Modelos
• KS (Kolmogorov-Smirnov)
• o KS mede a capacidade do modelo de separar as classes positiva e negativa,
ou seja, o quão bem o modelo é capaz de atribuir probabilidades maiores
para os exemplos da classe positiva do que para os exemplos da classe
negativa.
• Quanto maior o valor do KS, melhor é o desempenho do modelo
• comumente utilizada em aplicações financeiras, como análise de risco de
crédito, para avaliar a capacidade do modelo de distinguir entre bons e maus
pagadores
• também pode ser usado para comparar o desempenho de diferentes modelos
de classificação binária.
102. Métricas para Avaliação de Modelos
• Curva ROC
• usada para avaliar a capacidade do
modelo de distinguir entre classes
positivas e negativas
• gera um gráfico que plota a taxa de
verdadeiros positivos (TPR) em função
da taxa de falsos positivos (FPR) para
diferentes valores de threshold
(limiar)
• a AUC-ROC é a área sob essa curva, e
quanto mais próxima de 1, melhor é o
desempenho do modelo
104. Métricas para Avaliação de Modelos
• Matriz de Confusão
• tabela que resume o desempenho de
um modelo para um problema de
classificação
• mostra a contagem de previsões
corretas e incorretas para cada classe do
problema
• A partir dela, várias métricas podem ser
calculadas para avaliar o desempenho
do modelo, como acurácia, precisão,
recall, F1-score e AUC-ROC
105. Métricas para Avaliação de Modelos
• Matriz de Confusão
• 4 elementos principais:
• Verdadeiros Positivos (TP): quando o
modelo prevê corretamente que uma
instância pertence à classe positiva
• Falsos Positivos (FP): quando o modelo
prevê incorretamente que uma instância
pertence à classe positiva
• Verdadeiros Negativos (TN): quando o
modelo prevê corretamente que uma
instância não pertence à classe positiva
• Falsos Negativos (FN): quando o modelo
prevê incorretamente que uma instância
não pertence à classe positiva
106. Métricas para Avaliação de Modelos
• Matriz de Confusão
• ferramenta importante para entender
como o modelo está se comportando
para cada classe e se há algum
desequilíbrio entre as classes (por
exemplo, quando uma classe tem muito
menos exemplos que as outras).
• A interpretação da matriz de confusão
pode ajudar a ajustar os
hiperparâmetros do modelo ou o
próprio conjunto de dados para
melhorar o desempenho do modelo
108. Underfitting e Overfitting
• Underfitting
• quando o modelo é muito simples
para capturar as relações
complexas presentes nos dados de
treinamento
• pode levar a um desempenho ruim
tanto nos dados de treinamento
quanto nos dados de teste. O
modelo não consegue aprender
padrões nos dados e, portanto, não
consegue fazer previsões precisas
109. Underfitting e Overfitting
• Overfitting
• ocorre quando o modelo se ajusta muito bem aos dados de treinamento, mas
não generaliza bem para novos dados
• pode levar a um desempenho excelente nos dados de treinamento, mas um
desempenho ruim nos dados de teste.
• O modelo memoriza os dados de treinamento em vez de aprender padrões e tendências
nos dados, o que resulta em uma capacidade limitada de generalização
112. Underfitting e Overfitting
• Ambos underfitting e overfitting podem ser evitados por:
• técnicas de regularização, como a regularização L1 e L2
• ajuste adequado dos hiperparâmetros do modelo, como:
• taxa de aprendizado
• número de épocas de treinamento
• o uso de mais dados de treinamento (adicionar mais dados)
• recursos computacionais mais poderosos
• escolha de um modelo mais adequado
113. Underfitting e Overfitting
• Overfitting pode ser evitado por:
• realizar Parada Antecipada (Early Stopping)
• Pare de treinar quando perceber que a perda de validação (validation loss) aumenta
enquanto a perda de treinamento (training loss) diminui
• Isso é usado quando a precisão sobre o conjunto de dados de treinamento é aumentada,
mas a precisão sobre a validação conjunto de dados começa a diminuir.
• A parada antecipada permite que a rede seja capaz de generalizar. O que significa que
terá um ótimo desempenho durante o treinamento e conjunto de dados de teste.
114. Underfitting e Overfitting
• Overfitting pode ser evitado por:
• realizar Parada Antecipada (Early Stopping)
• A parada antecipada pode ser usada quando a
precisão sobre o conjunto de dados de
treinamento é aumentado, mas o precisão
sobre a validação (avaliação) conjunto de
dados começa a diminuir
115. Underfitting e Overfitting
• Overfitting pode ser evitado por:
• executar escolha de features
• A eliminação de features inúteis pode melhorar a capacidade de generalização do
modelo
• Use boosting e bagging (Ensemble Learning)
• Ao combinar a votação de muitos modelos diferentes por meio de bagging e boosting,
isso melhorará a generalização do modelo
• Adicione mais ruído
• Adicionar ruído pode permitir que o modelo se torne mais geral
116. Underfitting e Overfitting
• Overfitting pode ser evitado por:
• Use a técnica do abondono (dropout)
• No treinamento de Rede Neural Artificial, a queda de alguns neurônios usando a técnica
Dropout melhora a capacidade de generalização das redes
• Este tipo de regularização força o aprendizado a se espalhar entre os neurônios
artificiais, evitando ainda mais o overfitting
• Melhore a precisão adicionando um dropout.
• Abandono refere-se ao abandono de unidades em uma rede neural.
• Os neurônios desenvolvem co-dependência entre si durante o treinamento
• Dropout é uma técnica de regularização para reduzir o overfitting em redes neurais.
• Possibilita que o treinamento ocorra em diversas arquiteturas da rede neural
118. Underfitting e Overfitting
• Overfitting pode ser evitado por:
• Remova camadas da rede neural
• Outra técnica é reduzir a complexidade
da RNA removendo camadas, em vez de
adicioná-las.
• também pode ajudar a evitar que um
modelo excessivamente complexo seja
criado
119. Underfitting e Overfitting
• Regularização L1 (Regularização de Laplace)
• adiciona um termo à função de custo do modelo que penaliza o valor
absoluto dos parâmetros do modelo
• Esse termo tem a forma de λ * ||w||
• λ é uma constante de regularização
• ||w|| é a norma L1 dos parâmetros do modelo
• A norma L1 é a soma dos valores absolutos dos parâmetros do modelo
• A regularização L1 tende a gerar modelos esparsos, onde muitos parâmetros
têm um valor próximo a zero, o que pode ajudar a evitar overfitting
120. Underfitting e Overfitting
• Regularização L2 (Regularização de Ridge)
• adiciona um termo à função de custo do modelo que penaliza o quadrado dos
parâmetros do modelo
• Esse termo tem a forma de λ/2 * ||w||^2,
• λ é uma constante de regularização
• ||w||^2 é a norma L2 dos parâmetros do modelo
• A norma L2 é a raiz quadrada da soma dos quadrados dos parâmetros do modelo.
• A regularização L2 tende a gerar modelos onde todos os parâmetros têm
valores pequenos, mas diferentes de zero
• Isso pode ajudar a evitar overfitting e melhorar a capacidade de generalização do
modelo.
121. Underfitting e Overfitting
• Regularização L1 e L2
• L1 tende a gerar soluções mais esparsas do que um regularizador quadrático
122. Underfitting e Overfitting
• Regularização L1 e L2
• A regularização L1 penaliza o valor absoluto dos parâmetros, enquanto a
regularização L2 penaliza o quadrado dos parâmetros
• A escolha entre L1 e L2 depende da:
• natureza da tarefa
• conjunto de dados
•
• Escolha pode ser determinada por meio de experimentação técnica comum
de regularização para evitar overfitting
123. Otimização de modelos de Machine Learning
• Parâmetros a considerar:
• Função de custo:
• a função de custo é usada para avaliar o quão bem o modelo está se ajustando aos dados
de treinamento. É importante escolher uma função de custo adequada para a tarefa em
questão
• Algoritmo de otimização:
• há vários algoritmos de otimização disponíveis para ajustar os parâmetros do modelo.
Alguns exemplos incluem o gradiente descendente, o algoritmo de Adam e o algoritmo
de RMSprop
124. Otimização de modelos de Machine Learning
• Parâmetros a considerar:
• Taxa de aprendizagem:
• a taxa de aprendizagem controla o tamanho do passo que o algoritmo de otimização dá
em cada atualização de parâmetro.
• Uma taxa de aprendizagem muito alta pode fazer com que o algoritmo salte em torno do
mínimo global da função de custo, enquanto uma taxa de aprendizagem muito baixa
pode fazer com que o algoritmo leve muito tempo para convergir
125. Otimização de modelos de Machine Learning
• Parâmetros a considerar:
• Regularização:
• a regularização é usada para evitar overfitting, que ocorre quando o modelo se ajusta
muito bem aos dados de treinamento, mas não generaliza bem para novos dados.
• Existem várias técnicas de regularização disponíveis, como a regularização L1 e L2
126. Otimização de modelos de Machine Learning
• Parâmetros a considerar:
• Arquitetura do modelo:
• a arquitetura do modelo, como o número de camadas em uma rede neural ou o número
de árvores em uma floresta aleatória, pode afetar significativamente o desempenho do
modelo
• Hiperparâmetros específicos do modelo:
• dependendo do modelo específico que está sendo otimizado, há outros hiperparâmetros
que devem ser ajustados.
• Por exemplo, em uma rede neural, é importante considerar o número de neurônios em
cada camada, o tipo de função de ativação usada e o tipo de inicialização de pesos
127. Viés e Variância
• Viés:
• tendência do modelo de aprender relações simplificadas entre as variáveis do
problema, geralmente ignorando informações relevantes nos dados de
treinamento
• um modelo com alto viés pode ser muito simples para a tarefa em questão e
não ser capaz de capturar relações complexas nos dados
• isso pode levar a um desempenho ruim tanto nos dados de treinamento quanto nos
dados de teste
128. Viés e Variância
• Variância:
• sensibilidade do modelo a pequenas flutuações nos dados de treinamento
• um modelo com alta variância pode se ajustar muito bem aos dados de
treinamento, mas não generaliza bem para novos dados
• isso pode levar a um desempenho excelente nos dados de treinamento, mas um
desempenho ruim nos dados de teste
129. Viés e Variância
• Trade-off Viés-Variância:
• um modelo com alto viés e baixa variância tende a ser muito simples e pode
ter um desempenho ruim tanto nos dados de treinamento quanto nos dados
de teste
• um modelo com baixo viés e alta variância pode ser muito complexo e ter um
desempenho excelente nos dados de treinamento, mas um desempenho ruim
nos dados de teste. O objetivo é encontrar um equilíbrio entre viés e variância
que resulte no melhor desempenho geral do modelo
132. O que é Devops?
• Cultura de colaboração
• Coleção de boas práticas
• Integra melhor os times de desenvolvimento de software (Devs) e
operações de infraestrutura (Ops)
• Busca:
• Construir
• Testar
• Entregar software
• De forma mais rápida e eficiente
133. O que é Devops?
• Incentiva:
• automação de processos
• comunicação contínua entre as equipes
• adoção de práticas ágeis de desenvolvimento de software, como integração
contínua, entrega contínua e implantação contínua (CI/CD)
• essas práticas ajudam:
• reduzir os ciclos de desenvolvimento
• aumentar a frequência de releases de software
134. O que é Devops?
• Os profissionais de DevOps:
• geralmente têm habilidades técnicas em áreas como:
• Programação
• Automação
• Gerenciamento de configuração e infraestrutura de cloud
• trabalham para eliminar barreiras entre as equipes devs e operações
• Promovem uma cultura de colaboração e compartilhamento de responsabilidades
• Benefícios:
• maior agilidade
• redução de custos
• aumento da qualidade do software
• melhoria na experiência do usuário
137. Devops vs MLOps
• O DevOps é considerado o precursor ou “pai” do MLOps
• Ambos:
• visam dar maior eficiência e agilidade para:
• Criação / Desenvolvimento
• Implantação (Deploy)
• Testes / Controle de Qualidade
• Dimensionamento
• Gerenciamento e Monitoramento
138. Devops vs MLOps
• Desenvolvimento
• DevOps:
• desenvolvimento refere-se à criação de código para novos aplicativos ou recursos
• depois de escrito, o código é implantado e validado em uma série de testes
• MLOps:
• o desenvolvimento refere-se ao código que constrói e treina um modelo de ML
• Para implantação e validação, o MLOps se preocupa com o desempenho do modelo de ML
em vários conjuntos de dados de teste
• DevOps e MLOps:
• os ciclos de desenvolvimento são repetidos até que a qualidade ou desempenho desejado
seja finalmente alcançado
139. Devops vs MLOps
• Controle de versão
• DevOps:
• rastrear as alterações no código e nos artefatos
• detectar e corrigir erros/bugs com mais rapidez
• trabalhar simultaneamente no mesmo projeto
• facilitar a localização e a comunicação de alterações no código
• Devs e Ops trabalham juntos com mais rapidez para liberar rapidamente novos recursos ou
aplicativos
• MLOps:
• gira em torno do rastreamento das alterações feitas durante a construção e o treinamento de
um modelo de ML
• rastreiam e medem as variáveis de cada execução experimental, incluindo dados, código de
construção de modelo e o artefatos do modelo
• mede análises sobre o desempenho do modelo, para ajustes e testes futuros
140. Devops vs MLOps
• Monitoramento
• DevOps:
• o monitoramento é exaustivo e abrange a supervisão de todo o ciclo de vida de
desenvolvimento de software
• inclui planejamento, desenvolvimento, integração, teste, implantação e operações
• MLOps:
• se concentra no monitoramento do modelo de ML, incluindo possíveis problemas
• procura eliminar desvios de dados, features menos importantes e defeitos de precisão
do modelo
• Data drift
• Model drift
141. Devops vs MLOps
• Funções e responsabilidades
• DevOps e MLOps:
• maior comunicação e melhor fluxo de trabalho, mas atingem esse objetivo de duas
maneiras únicas
• DevOps:
• envolve devs e operações de TI para acelerar o ciclo de vida do desenvolvimento e
oferecer entrega contínua de software da mais alta qualidade
• inclui garantia de qualidade e, recentemente, a segurança está se tornando uma função
mais focada no DevOps, com o DevSecOps
• trabalha para reduzir as barreiras entre Desenvolvimento e Operações para permitir uma
comunicação mais eficaz e permitir entregas mais rápidas, mantendo a alta qualidade.
142. Devops vs MLOps
• Funções e responsabilidades
• MLOps:
• as funções e responsabilidades da equipe incluem a equipe de ML, ou os cientistas de dados,
que, ao lado da equipe de operações, se concentra nas operações e na produção
• As operações de ML e Dev são diferentes
• Ambos se esforçam para implantar software em um fluxo de trabalho repetível e tolerante a falhas
• com MLOps o software inclui um componente de ML
• DevOps e MLOps se complementam e diferem de várias maneiras
• mas MLOps pode ser melhor considerado uma implementação específica de DevOps que se
concentra em aplicativos de ML
• Ao aplicar os princípios do DevOps aos sistemas de ML, o MLOps ajuda a manter uma
integração perfeita entre o desenvolvimento e a implantação de modelos de ML,
possibilitando projetos de dados em larga escala
143. MLOps – Níveis de Maturidade
• Nível 0 – processo manual
144. MLOps – Níveis de Maturidade
• Nível 1 –
automaçã
o do
pipeline de
ML
145. MLOps – Níveis de Maturidade
• Nível 2 –
automação do
pipeline de
CI/CD
146. MLOps = ML + DEV + OPS
Experiment
Data retrieval
Business
understanding
Initial modeling
Develop Operate
Continuous Delivery
Data Feedback Loop
System + Model Monitoring
+ Testing
Continuous Integration
Continuous Deployment
147. MLOps
It brings together people, processes, and platform to automate ML-infused
software delivery & provide continuous value to end users.
• Blend together the work of individual
engineers in a repository.
• Each time you commit, your work is
automatically built and tested, and bugs are
detected faster.
• Code, data, models and retraining pipelines
are shared to accelerate innovation.
People Process Platform
• Provide templates to bootstrap your
infrastructure and model development
environment, expressed as code.
• Automate the entire process from code
commit to production.
• Data engineering is all about 24x7 reliability,
but data science is about inner loop agility.
• Safely deliver features to your customers as
soon as they're ready.
• Monitor your pipelines, infrastructure and
products in production and know when they
aren’t behaving as expected.
148. Traditional vs ML infused systems
ML introduces two new assets into the software development lifecycle:
data and models
149. MLOps Workflow
ML Engineer
using Azure DevOps
Build app
Collaborate Test app Release app Monitor app
Model reproducibility Model retraining
Model deployment
Model validation
Data scientist using
Azure Machine Learning
150. MLOps Benefits
• Accelerate code integration and
solution deployment
• Pipelines are reproducible and
verifiable
• You can tag and audit all artifacts
Increased Velocity and Security for ML
• SWE Best Practices for Quality Control
• Offline comparison of model quality
• Minimize bias and provide
descriptiveness
• Controlled rollout capabilities
• Live comparison of predicted and
expected performance
• Results feedback to monitor drift
and improve model
Automation &
Observability
Validation Reproducibility &
Auditability
151. MLOps Workflow
Code, dataset, and
environment versioning
Model reproducibility Model retraining
Model deployment
Model validation
Build app
Collaborate Test app Release app Monitor app
ML Engineer
using Azure DevOps
Data scientist using
Azure Machine Learning
152. MLOps Workflow
Model reproducibility Model retraining
Model deployment
Model validation
Automated ML
ML Pipelines
Hyperparameter tuning
Train model
Build app
Collaborate Test app Release app Monitor app
ML Engineer
using Azure DevOps
Data scientist using
Azure Machine Learning
153. MLOps Workflow
Model validation
& certification
Model reproducibility Model retraining
Model deployment
Model validation
Train model Validate
model
Build app
Collaborate Test app Release app Monitor app
ML Engineer
using Azure DevOps
Data scientist using
Azure Machine Learning
154. MLOps Workflow
Model packaging
Simple deployment
Model reproducibility Model retraining
Model deployment
Model validation
Train model Validate
model
Deploy
model
Build app
Collaborate Test app Release app Monitor app
ML Engineer
using Azure DevOps
Data scientist using
Azure Machine Learning
155. MLOps Workflow
Model
management
& monitoring
Model performance
analysis
Model reproducibility Model retraining
Model deployment
Model validation
Train model Validate
model
Deploy
model
Monitor
model
Retrain model
Build app
Collaborate Test app Release app Monitor app
ML Engineer
using Azure DevOps
Data scientist using
Azure Machine Learning
160. ML Eng
Cloud Services
IDE
Data Scientist
[ { "cat": 0.99218,
"feline": 0.81242 }]
IDE
Apps
Edge Devices
Model Store
Consume Model
DevOps
Pipeline
Customize Model
Deploy Model
Predict
Validate
&
Flight
Model
+
App
Update
Application
Publish Model
Collect
Feedback
Deploy
Application
Model
Telemetry
Retrain Model
ML + App Dev Process
Model Versioning & Storage
161. Model Versioning & Storage
Provide a consistent way to discover, store, track
& share models
Provide a consistent model metadata format
Track where a model came from
• which data,
• which experiment / previous model(s),
• where’s the code / notebook)
• Was it converted / quantized?
Track where model is running & model health
Control who has access to what models
• Private / compliant data
162. ML Eng
Cloud Services
IDE
Data Scientist
[ { "cat": 0.99218,
"feline": 0.81242 }]
IDE
Apps
Edge Devices
Model Store
Consume Model
DevOps
Pipeline
Customize Model
Deploy Model
Predict
Validate
&
Flight
Model
+
App
Update
Application
Publish Model
Collect
Feedback
Deploy
Application
Model
Telemetry
Retrain Model
ML + App Dev Process Model Validation
163. Model Validation
Profile and validate
• Data (changes to shape / profile)
• Model in isolation (offline A/B)
• Model + app (functional testing)
Control model rollout on validation
• Only deploy after initial validation passes
• Ramp up traffic to new model using A/B
experimentations
Assess performance
• Functional behavior
• Performance characteristics
164. ML Eng
Cloud Services
IDE
Data Scientist
[ { "cat": 0.99218,
"feline": 0.81242 }]
IDE
Apps
Edge Devices
Model Store
Consume Model
DevOps
Pipeline
Customize Model
Deploy Model
Predict
Validate
&
Flight
Model
+
App
Update
Application
Publish Model
Collect
Feedback
Deploy
Application
Model
Telemetry
Retrain Model
ML + App Dev Process
Inference Deployment
165. Model Deployment
Provide safe & efficient process to deploy models
• Focus on ML, not DevOps
• Get telemetry for service health and model behavior
Simplify process to interact with the model
• code-generation
• API specifications / interfaces
Support a variety of inferencing targets
• Cloud Services
• Mobile / Embedded Applications
• Edge Devices
• Quantize / optimize models for target platform
Control the rollout of your models (with A/B)
• Compliant + Safe
167. ML Eng
Cloud Services
IDE
Data Scientist
[ { "cat": 0.99218,
"feline": 0.81242 }]
IDE
Apps
Edge Devices
Model Store
Consume Model
DevOps
Pipeline
Customize Model
Deploy Model
Predict
Validate
&
Flight
Model
+
App
Update
Application
Publish Model
Collect
Feedback
Deploy
Application
Model
Telemetry
Retrain Model
ML + App Dev Process
Re-training Deployment
168. Azure DevOps + Azure ML
Trigger release pipelines
on model registration
Use Azure DevOps +
Azure ML CLI to manage
E2E release flow
Leverage Azure DevOps
approvals for controlling
application rollout
Announcing: The AML
Extension for MLOps
169. First Class Model Training Tasks
CI pipeline captures:
1. Create sandbox
2. Run unit tests and code quality checks
3. Attach to compute
4. Run training pipeline
5. Evaluate model
6. Register model
170. Automated Deployment
CD pipeline captures:
1. Package model into container
image
2. Validate and profile model
3. Deploy model to DevTest (ACI)
4. If all is well, proceed to rollout
to AKS
Everything is done via the CLI
171. Integração Contínua
(Continuous Integration – CI)
• processo que envolve a integração contínua de conteúdo, como
imagens, arquivos e outros recursos necessários para construir, testar
e implantar um aplicativo ou serviço de software
• visa garantir que todos os artefatos necessários estejam disponíveis
em todas as etapas do ciclo de vida de desenvolvimento, desde o
desenvolvimento até a produção
172. Integração Contínua
(Continuous Integration – CI)
• pode ser realizada de várias formas, incluindo:
• integração de repositórios de código
• integração de dependências de pacotes
• integração de ferramentas de automação de construção e implantação
• permite que as mudanças no código e nos artefatos sejam integradas
de forma automática e contínua em um pipeline de entrega
173. Integração Contínua
(Continuous Integration – CI)
• ajuda a garantir que as diferentes equipes que trabalham em um
projeto possam colaborar e compartilhar o conteúdo necessário de
forma eficiente, mesmo quando estão geograficamente distantes ou
trabalhando em diferentes fusos horários
• permite uma maior velocidade e eficiência no desenvolvimento e
implantação de aplicativos e serviços de software
174. Integração Contínua
(Continuous Integration – CI)
• é um componente essencial da cultura DevOps
• prática fundamental para garantir a entrega contínua e a implantação
confiável de software
• garantindo que todos os conteúdos necessários estejam disponíveis
em todas as etapas do ciclo de vidaajuda a garantir a qualidade do
software e a acelerar a entrega de valor aos usuários finais
176. Entrega Contínua
(Continuous Delivery – CD)
• Prática de desenvolvimento de software que faz parte da cultura
DevOps
• Objetivo: entregar software de forma rápida e confiável, permitindo
que as empresas possam atender às demandas de seus clientes de
forma mais eficiente
177. Entrega Contínua
(Continuous Delivery – CD)
• Processo automatizado de desenvolvimento e entrega de software
• envolve desde a construção do código-fonte até a implantação e teste do
software em ambientes de produção.
• é executado de forma contínua, sem interrupções, permitindo que novas
funcionalidades e correções de bugs possam ser entregues rapidamente aos
usuários finais
• Necessário que as equipes de desenvolvimento e operações
trabalhem em conjunto
• utilizem ferramentas e técnicas que permitam a automação de processos e a
integração contínua de código
178. Entrega Contínua
(Continuous Delivery – CD)
• também envolve a realização de testes automatizados em todos os estágios do
processo de desenvolvimento e entrega
• garante a qualidade e a estabilidade do software
• fundamental para empresas que desejam manter-se competitivas no mercado
atual
• velocidade de desenvolvimento e entrega de software é cada vez mais importante
• Reduz bugs
• Melhora a colaboração e comunicação entre Devs e Ops
181. Repositórios Git
• Git é um sistema de controle de versão de código-fonte
• amplamente utilizado no desenvolvimento de software moderno
• Repositório Git:
• local onde o código-fonte de um projeto é armazenado, versionado e
compartilhado entre os membros da equipe de desenvolvimento
• composto por uma coleção de arquivos e diretórios, incluindo o código-fonte
do projeto, arquivos de configuração, documentação e outros artefatos
relacionados
• cada mudança feita no código-fonte é registrada como um "commit" e pode
ser rastreada e revertida facilmente
183. Repositórios Git
• Branches
• podem ser usados para desenvolver novas funcionalidades ou corrigir bugs
sem afetar o código-base principal
• Divisão:
• Produção/Master
• Homolog
• Desenvolvimento
• Features
• Fixes
185. Repositórios Git
• frequentemente hospedados em plataformas de hospedagem de
código-fonte na nuvem
• essas plataformas fornecem recursos para gerenciar e colaborar em
projetos de software, como:
• controle de acesso
• rastreamento de problemas (bugs e fixes)
• gerenciamento de tarefas
• integração contínua
• Permitem que devs trabalhem de forma mais ágil e colaborativa,
compartilhando e versionando o código-fonte de forma segura e
confiável
187. Boas práticas de codificação Python
• Python PEP8 - https://peps.python.org/pep-0008/
• Tamanho da linha
• Tabs ou espaços
• Nomenclatura de objetos e variáveis
• Aspas
• Comentários
• Argumentos
• Exceções
• Etc.
• Benefícios:
• Padronização no Time
• Melhor entendimento
• Melhor manutenção
• Código otimizado
188. Boas práticas de codificação Python
• Aplicação de Libs python (CI pipeline)
• flake8 – aderência ao PEP8
• black – formatação do código
• isort – otimização de imports
• bandit – verificação de brechas de segurança
• safety – verificação de vulnerabilidades de segurança das dependências
189. Boas práticas de codificação Python
• Aplicação de Libs python (CI pipeline)
• flake8 – aderência ao PEP8
190. Boas práticas de codificação Python
• Aplicação de Libs python (CI pipeline)
• bandit – verificação de brechas de segurança
191. Boas práticas de codificação Python
• Garantindo a Qualidade do Produto (QA – Quality Assurance)
• Testes Unitários
• pytest
192. Boas práticas de codificação Python
• Garantindo a Qualidade do Produto (QA – Quality Assurance)
• Testes Integrados/de Integração
• Sistemas externos
• Bases de dados
• Fluxo completo
193. Boas práticas para Data Science
• Peer Review e Peer Programming
• Fluxo de aprovação por Pull Request (PR’s)
194. Boas práticas para Data Science
• Peer Review e Peer Programming
• Fluxo de aprovação por Pull Request (PR’s)
195. Boas práticas para Data Science
• Peer Review e Peer Programming
• Fluxo de aprovação por Pull Request (PR’s)
201. Feature Engineering (Engenharia de Recursos)
• Os algoritmos de ML exigem dados de treinamento para
treinar
• Recursos (Features) são matéria-prima dos modelos de ML
• A engenharia de recursos é:
• uma tarefa crítica que os cientistas de dados precisam realizar
antes de treinar os modelos AI/ML
• uma arte de introduzir novos recursos que não existiam antes
• Como cientista de dados, você pode precisar:
• Destacar informações importantes nos dados
• Remover/isolar informações desnecessárias (ex.: outliers).
• Adicionar sua própria experiência e conhecimento de domínio
para alterar os dados
202. Feature Engineering (Engenharia de Recursos)
• Os cientistas de dados gastam 80% de
seu tempo realizando engenharia de
recursos
• Os 20% restantes são a parte fácil que inclui
treinar o modelo realizando otimização de
hiperparâmetros
• Executar a engenharia de recursos
adequada é crucial para melhorar o
desempenho do modelo de AI/ML
203. Feature Engineering (Engenharia de Recursos)
• Como cientista de dados, você precisa responder às seguintes perguntas:
• Quais são os recursos do modelo de ML que possuo?
• Quais recursos devo selecionar?
• Posso adicionar meu conhecimento de domínio para usar menos recursos?
• Posso criar novos recursos a partir dos dados que tenho em mãos?
• O que devo colocar nos locais de dados ausentes?
• É importante escolher os recursos mais relevantes para o problema.
• Adicionar novos recursos desnecessários aumentará os requisitos
computacionais necessários para treinar o modelo (maldição da
dimensionalidade)
• Existem inúmeras técnicas que podem ser usadas para reduzir o número de
recursos (comprimir/codificar os dados), como Análise de Componentes
Principais (PCA)
204. Feature Engineering - Exemplo
• Vamos dar uma olhada nesses dados e ver o que há de errado com eles!
206. Feature Selection
• Livre-se de dados inúteis!
• é o processo de selecionar recursos relevantes apenas do conjunto de dados disponível.
• aprimora o desempenho do modelo removendo o "ruído" e, portanto, permitindo o modelo para
se concentrar apenas em recursos importantes
• Dados inúteis são dados de tipo discreto que não têm nenhuma relação com a saída
• Normalmente descartamos os recursos inúteis do conjunto de dados antes de treinar o modelo
• Exemplos incluem:
• IDs de clientes aleatórios em uma loja ou banco
207. Feature Selection
• PCA – Principal Component Analysis
• algoritmo não supervisionado
• executa reduções de dimensionalidade enquanto
tenta manter as informações originais inalteradas
• funciona tentando encontrar um novo conjunto de
recursos chamados “componentes”
• Os componentes são compostos dos recursos de entrada
fornecidos não correlacionados
• O primeiro componente é responsável pela maior
variabilidade de dados seguido por segundo
componente e assim por diante
208. Feature Engineering - Técnicas
• Scaling: Dimensionamento
• O dimensionamento de recursos (normalização) é necessário antes do
treinamento de redes neurais artificiais para garantir que os recursos estejam
na mesma escala.
• Exemplo:
• taxa de juros e taxas de emprego estão em uma escala diferente
• Isso resultará em um recurso dominando o outro recurso.
209. Feature Engineering - Técnicas
• Scaling: Dimensionamento
• O Scikit Learn oferece várias ferramentas para executar o escalonamento de
recursos.
210. Feature Engineering - Técnicas
• Scaling: Normalização
• executada para fazer com que os valores dos recursos variem de 0 a 1.
211. Feature Engineering - Técnicas
• Scaling: Padronização
• é conduzida para transformar os dados para que tenham uma média de zero
e desvio padrão de 1
• também é conhecida como normalização de pontuação Z
• é preferível à normalização quando há muitos outliers
• pode-se reverter para o intervalo de dados original aplicando padronização
inversa.
215. Feature Engineering - Técnicas
• Imputation
• Impossível reparar ou há esperança??
• Como cientista de dados, você encontrará dados com valores ausentes “NaN”.
• Dados ausentes podem surgir de um sensor ou de um servidor que pode ter quebrado, por
exemplo
• Para alimentar com esses dados um modelo de ML, você precisará:
• Substituir os valores NaN ausentes por algo que possa ser valor médio, mediano ou máximo!
• Remover a linha inteira (não recomendado, pois a linha pode conter informações valiosas).
• Você pode obter a média substituindo os valores NaN pela média do recurso, por exemplo.
216. Feature Engineering - Técnicas
• Imputation
• Impossível reparar ou há esperança??
• Exemplo: dataset do Titanic
217. Feature Engineering - Técnicas
• Imputation – Dropping (Removendo)
• Pode ser necessário remover a coluna "Cabin"
• Parece que há uma tonelada de dados ausentes além da possibilidade de
reparo
218. Feature Engineering - Técnicas
• Imputation – Substituindo valores ausentes pela média
• Para a coluna “Age”, pode ser necessário obter a média e substituir os valores
ausentes pela média da coluna “Age”
• Outra forma de melhorar é substituir os valores em falta pela “idade” média
em função do “sexo” do passageiro
219. Feature Engineering - Técnicas
• Imputation – Substituindo valores
ausentes pela média
• Substituir os valores ausentes pela média é
simples e eficaz, mas carece de precisão.
• Na presença de outliers, usar a mediana pode
levar a melhores resultados
• E os dados categóricos?
• Você pode substituir o valor ausente pelo valor
que ocorreu com mais frequência.
• Se os valores seguirem uma distribuição
uniforme, use “outro” em seu lugar.
220. Feature Engineering - Técnicas
• Imputation – Usando ML para substituir valores ausentes!
• Outra maneira de lidar com valores ausentes é usar ML
• Essas técnicas levarão a maior precisão, mas são muito mais complexas do
que uma simples “substituição pela média”
• Pode funcionar bem com dados numéricos e categóricos
• Técnicas de Deep Learning, KNN ou Regressão podem ser usadas
• Mas também: coletar mais dados!
221. Feature Engineering - Técnicas
• Imputation – Usando ML para substituir valores ausentes!
• DeepAR – algoritmo disponível no AWS Sagemaker
• algoritmo de previsão de séries temporais
• Em séries temporais, a falta de dados pode ter um grande impacto na
precisão da previsão.
• A imputação de valores ausentes com zeros direcionará o algoritmo para zero,
o que não é desejável.
222. Feature Engineering - Técnicas
• Imputation – Usando ML para substituir valores ausentes!
• DeepAR:
• pode trabalhar com dados ausentes (diretamente no modelo) para que não seja
necessário nenhuma extração manual de recursos
• depende da RNN - Rede Neural Recorrente (deep learning) para realizar a imputação,
resultando em resultados muito precisos.
223. Feature Store
• Feature Store é uma plataforma
de gerenciamento de features
de dados
• permite que as equipes de
ciência de dados e engenheiros
de ML gerenciem e
compartilhem features entre as
equipes de maneira eficiente
224. Databricks Feature Store
• Benefícios:
• Gerenciamento centralizado, plataforma única:
• local centralizado para armazenar e gerenciar recursos de dados, incluindo features, datasets e modelos
• facilita a colaboração e o compartilhamento entre as equipes
• features já estão em um alto nível de refinamento
• centralizar as features que são usadas frequentemente evita redundância de cálculos
• Por consequência, reduz custos na utilização da infra
• Garante consistência nos dados
• Integração com o ecossistema do Databricks
• se integra perfeitamente com outras ferramentas do ecossistema do Databricks, como Delta Lake e
Mlflow
• Versionamento e rastreamento de recursos
• permite que os usuários versionem e rastreiem recursos de dados
• ajuda a garantir a consistência e reprodutibilidade dos resultados de ML
225. Databricks Feature Store
• Benefícios:
• Escalabilidade e desempenho
• é projetada para escalabilidade e desempenho, permitindo que os usuários gerenciem
grandes volumes de dados e recursos de forma eficiente
• Segurança e Permissionamento
• é altamente segura, com recursos de controle de acesso baseados em função e
autenticação segura para proteger os dados dos usuários
• Automação e orquestração
• fornece recursos avançados de automação e orquestração para ajudar os usuários a
automatizar e gerenciar pipelines de dados de ponta a ponta
226. Databricks Feature Store
• Benefícios:
• Descoberta/Navegação
• Reaproveitamento de dataprep/feature engineering entre modelos
• Em média 70% do tempo dos cientistas de dados é gasto com preparação e limpeza dos
dados
• Viagem no tempo, ou “time travel” - quando há necessidade de voltar
algumas features para uma data/hora específica
• Versionamento de features - manter versões diferentes de uma feature ajuda
a fazer diferentes experimentos e cenários de modelagem
• Linhagem
228. Databricks Feature Store
• Recomenda-se que as features sejam criadas em um banco de dados
de Feature Store produtivo, que pode ser acessado por todos os
notebooks e scripts de treinamento
• Isso permite:
• features de dados sejam gerenciadas de forma centralizada
• features sejam usadas em diferentes modelos
• Recomenda-se o uso de padrões de nomenclatura consistentes e uma
documentação clara e concisa para as features da Feature Store
• facilita a colaboração entre os membros da equipe.
229. Databricks Feature Store
• Recomendações:
• Atualizar regularmente as features: atualizar com frequência para refletir as
mudanças na base de dados subjacentes e manter os modelos de ML precisos
• Definir o tipo de dados mais apropriado para as features
• permite bom desempenho nas consultas, na utlização de storage e uso futuro das
features
• Garantir a segurança e conformidade:
• implementar medidas de segurança e conformidade (LGPD)
• criptografia de dados e controle de acesso, para proteger os dados de características
confidenciais, de preferência antes de colocar os dados na Feature Store
• Adicionar tags relevantes às tabelas de features: isso permite melhor gestão e
localização dos dados
230. Databricks Feature Store
• Recomendações:
• Monitorar o uso de features na UI (Lineage - producers e features) para
identificar quais são mais valiosas (jobs, notebooks, models que usam estas
features)
• priorizar o desenvolvimento e a atualização de features futuras
232. Feature Store
• Recomendações:
• Aproveitar os recursos de integração com outras ferramentas (Databricks
Partner Connect) quando não existe tal recurso no Databricks -> para isto,
usar a delta table
• Camada semântica
• Data Quality
• Dashboards
• Etc.
233. Governança em Ciência de Dados
• conjunto de práticas, políticas e processos
que visam garantir a qualidade,
segurança, privacidade e conformidade
dos dados usados em projetos de ciência
de dados
• são implementadas por meio de uma
estrutura organizacional que estabelece
responsabilidades e papéis claros para os
diferentes envolvidos no processo de ciência
de dados.
234. Governança em Ciência de Dados
• é importante porque os projetos de ciência de dados envolvem dados
de diferentes fontes e tipos, que podem ser sensíveis e confidenciais
• a ciência de dados envolve a criação de modelos e algoritmos que
afetam diretamente as decisões de negócios e podem ter um impacto
significativo nos resultados da organização
235. Governança em Ciência de Dados
• práticas comuns de governança incluem:
• Estabelecer políticas claras para o uso e armazenamento de dados
• Designar responsabilidades e papéis claros para os envolvidos no processo de
ciência de dados
• Estabelecer padrões de qualidade para os dados e algoritmos usados em
projetos de ciência de dados
236. Governança em Ciência de Dados
• práticas comuns de governança incluem:
• Garantir a privacidade e segurança dos dados por meio de medidas de
segurança e criptografia
• Monitorar e auditar o processo de ciência de dados para garantir a
conformidade com as políticas estabelecidas
237. Governança em Ciência de Dados
• é uma prática em evolução, à medida que novas tecnologias e
tendências emergem no campo
• A implementação efetiva da governança em ciência de dados pode:
• ajudar as organizações a tomar decisões melhores e mais informadas com
base em dados confiáveis e seguros
239. Datamesh
• abordagem arquitetural para gerenciamento de dados que busca
descentralizar a gestão dos dados
• cada equipe ou departamento mantém controle sobre seus próprios dados e
pode compartilhá-los com outras equipes, criando uma rede de dados
interconectados
• O objetivo é criar um ambiente mais ágil e flexível para o
gerenciamento de dados, em que cada equipe pode trabalhar de
forma autônoma, mas ainda assim, colaborar com outras equipes e
compartilhar informações quando necessário
242. Democratização dos Dados
• iniciativa que visa tornar os dados disponíveis para um público mais amplo
dentro da organização
• Além de simplesmente tornar os dados acessíveis, a democratização dos
dados visa transformar todos os funcionários em cientistas de dados,
promovendo a “alfabetização de dados” e a narrativa (storytelling)
• Envolve:
• a implementação de ferramentas e processos que tornam os dados mais acessíveis e
compreensíveis para usuários não técnicos, permitindo que eles usem os dados para:
• tomar decisões melhores
• tomar decisões mais informadas
243. Democratização dos Dados
• 6 pilares:
Consolidate date into one easy to access location.
Allows business users to build and manipulate their
own reports with little to no training
Systems thar aggregate, process and store data
used for reporting, analysis and decision making
The process of protecting data from unauthorized
access and data corruption throughout its lifecycle
The use of data visualization and storytelling to
make data-driven insights understandable and
actionable
The ability to decipher, obtain meaning from and
use data as information
A collection of standardized policies and processes
that control the management, usage and
accessibility of data within an organization
244. Democratização dos Dados
• pode envolver:
• fornecimento de dashboards e relatórios intuitivos
• realização de treinamentos e workshops para funcionários de diversos setores
da empresa
• criação de uma cultura organizacional que valoriza e utiliza dados para
orientar as decisões.
245. Unity Catalog
• Ferramenta que permite gerenciar e compartilhar metadados de
dados e modelos
• garante a conformidade e a governança dos dados
• Recomenda-se que os cientistas de dados usem tags e anotações para
categorizar os dados e os modelos
• garante que as informações importantes, como o esquema dos dados e as
dependências do modelo, estejam claramente documentadas
250. MLFlow
• Ferramenta importante para gerenciar o ciclo de vida dos modelos
• garante a reprodutibilidade
• garante a transparência dos experimentos de dados
• recomendável que cada notebook de modelo seja criado em uma
repositório git separado, com o código-fonte do modelo e os logs de
experimentos organizados de forma clara e consistente
• recomenda-se que os cientistas de dados usem tags e anotações para
registrar informações importantes sobre cada experimento, como os
hiperparâmetros usados, as métricas de desempenho e outras
informações relevantes.
251. MLFlow
• Benefícios:
• Rastreamento de Experimentos
• Usar o MLflow e a sua UI para rastrear e comparar diferentes experimentos e
configurações de modelos. Isso permite uma análise posterior dos resultados e uma
seleção mais informada do melhor modelo
• Versionamento de modelos
• Armazenar e versionar os modelos treinados usando o MLflow, pois permite uma fácil
recuperação de modelos antigos caso seja necessário
• Gerenciamento de dependências
• gerenciar as dependências do projeto de ML, incluindo bibliotecas, versões de pacotes e
ambientes de execução
252. MLFlow
• Benefícios:
• Integração nativa com o Databricks
• nativo na plataforma Databricks, o que permite integração fácil e fluida com outros
componentes do ecossistema de ML da Databricks. Sendo assim, não é necessário
utilizar ferramentas externas de registro de modelos
• Usar os MLFlow webhooks (ainda em Public Preview)
• Os Webhooks do MLFlow permitem “ouvir” eventos do Registro de Modelo para que as
integrações possam disparar ações automaticamente
• Pode-se usar webhooks para automatizar e integrar o pipeline de ML com ferramentas e
fluxos de trabalho de CI/CD existentes
255. Experimentos e AutoML
• AutoML:
• uma abordagem low-code que acelera projetos de ciência de dados
avançando rapidamente através das iterações usuais
• executa um conjunto de ensaios e os registra criando, ajustando e avaliando
vários modelos
• gerar rapidamente modelos de linha de base e blocos de anotações
• Modelos self-service! (quase...)
• Gera automaticamente:
• análise exploratória dos dados do modelo
• Indica significância de features (que possuem maior impacto no modelo)
• Acelera o processo de ciência de dados
• Abordagem “data processing first”
257. Experimentos e AutoML
• AutoML:
• Why do we still manually implement our ML models? | element61
258. Experimentos e AutoML
• Experimentos - recomendações:
• Organização: manter registros detalhados sobre os experimentos, incluindo
input/hiperparâmetros, output e configurações
• facilita a reprodução de experimentos e a comparação de resultados
• Baseline: estabelecer uma linha de base para os experimentos, usando
métricas relevantes para o problema que você está tentando resolver
• permite avaliar se os resultados dos experimentos estão realmente melhorando a
solução
• Controle de variáveis
• garantir que os experimentos sejam controlados, ajustando apenas uma variável por vez
para evitar efeitos colaterais
259. Experimentos e AutoML
• Experimentos - recomendações:
• Validação cruzada
• usar técnicas de validação cruzada, como k-fold cross validation, para obter resultados
mais confiáveis
• Automatização
• automatizar o processo de experimentação, desde a preparação dos dados até a
execução e análise dos resultados
• poupa tempo e garante a consistência dos resultados
• Documentação
• documentar cuidadosamente os experimentos e resultados, incluindo gráficos, tabelas e
conclusões
• permite a revisão e compartilhamento dos resultados entre os membros da equipe
260. Ferramentas adicionais
• Azure Devops
• Automatização de pipelines
• Testes
• Execução de testes unitários e testes de integração automaticamente
• Dashboard com acompanhamento da qualidade dos códigos
• Deploy em Homologação e Produção
• Fluxo de aprovação por liderança
• Code-review
• Pull-requests com fluxo de aprovação por pares
• Git – repositórios com branches (ramificações), PR’s, comparar versões etc.
• Alertas por e-mail, Teams, Slack etc.
• Possibilidade de acompanhar as sprints, ter wiki, fazer rastreamento
• Kambam, Agile
• Pode ter integrações com Jira também (necessita customização)
261.
262. Ferramentas adicionais
• VS Code (sugestão)
• IDE bem difundida
• Desenvolvimento de funções utilitárias
• Também é possível integrar com ambiente Spark do Databricks (exige libs adicionais)
• Depuração integrada, Refactoring, Testes unitários, Code complete, Sugestões
• Melhor integração/interface para trabalhar com repositórios Git do que Databricks
• Diversas extensões (add-ons) para maior qualidade de código e produtividade
• Impulsionadores (boosters) para codificação:
• Co-pilot
• ChatGPT (quase substituindo Stack Overflow e demais queries no Google)
• Databricks a partir de 14/fev/2023:
• VS Code extension for Databricks
• Databricks ❤️ IDEs - The Databricks Blog
265. Ferramentas adicionais
• Azure – Serviços Cognitivos e OpenAI
• Integração com serviços Azure
• General availability of Azure OpenAI Service expands access to large, advanced AI models with added enterprise benefits | Azure Blog
and Updates | Microsoft Azure
270. Data Drift e Model Drift
• Modelos irão perder performance com o tempo!
• O desafio é detectar quando isso acontecer!
271. Data Drift e Model Drift
• Tipos de Drift (movimento, deriva)
272. Data Drift e Model Drift
• Drifts podem ocorrer em:
• Features
• Labels
• Previsões
Fontes:
https://dataz4s.com/statistics/chi-square-test/
https://towardsdatascience.com/machine-learning-in-production-why-you-should-care-about-data-and-concept-drift-
d96d0bc907fb
273. Data Drift e Model Drift
• Drift de Conceito
Fonte: Krawczyk and Cano 2018. Online Ensemble Learning for Drifting and Noisy Data Streams
274. Data Drift e Model Drift
• Tipo de Drift e Ações a tomar
275. Data Drift
• ocorre quando a distribuição dos dados usados em um modelo de ML
muda com o tempo, tornando o modelo impreciso ou menos eficaz
• pode acontecer por várias razões, incluindo:
• mudanças nos comportamentos ou preferências dos usuários
• alterações na forma como os dados são coletados ou processados
• mudanças nas condições ambientais que afetam a coleta dos dados
• entre diversas outras causas
276. Data Drift
• Métodos para identificar:
• Análise de estatísticas descritivas:
• comparação de estatísticas descritivas dos dados coletados em diferentes momentos
• média, variância, desvio padrão, percentis, entre outras
• podem ser usadas para identificar mudanças significativas na distribuição dos dados
• Testes estatísticos:
• teste de hipóteses
• teste de Kolmogorov-Smirnov
• usados para avaliar a diferença entre duas distribuições de dados
277. Data Drift
• Métodos para identificar:
• Monitoramento em tempo real dos dados
• pode ser usado para detectar mudanças na distribuição dos dados à medida que
ocorrem.
• pode ser feito por meio de dashboards e alertas que avisam quando há uma mudança
significativa nos dados
• Independentemente da metodologia usada, é importante verificar o data drift
regularmente para:
• garantir que o modelo de ML continue sendo preciso e eficaz ao longo do tempo.
• A falta de verificação do data drift pode levar a resultados imprecisos, perda de
confiança do usuário e até mesmo danos à reputação da empresa
278. Data Drift
• O que monitorar?
• Estatísticas resumidas básicas de features e target
• Distribuições de features e target
• Métricas de performance do modelo
• Métricas de negócios (sobre os dados reais)
284. Data Drift
• Features Categóricas
• Teste qui-quadrado
• técnica estatística usada para avaliar a associação entre duas variáveis categóricas.
• é utilizado para determinar se existe uma diferença significativa entre as frequências
observadas e as frequências esperadas em um conjunto de dados
• é baseado na comparação de duas hipóteses:
• a hipótese nula (H0) -> não há associação entre as duas variáveis categóricas
• hipótese alternativa (Ha) -> há uma associação significativa entre elas
285. Data Drift
• Features Categóricas
• Teste qui-quadrado
• envolve a comparação das frequências observadas com as frequências esperadas.
• As frequências esperadas são calculadas com base nas frequências marginais e na suposição
de que não há associação entre as duas variáveis.
• Se as frequências observadas diferirem significativamente das frequências esperadas, então
rejeitamos a hipótese nula e concluímos que há uma associação significativa entre as duas variáveis
• é comumente usado em pesquisa de mercado, estudos epidemiológicos e em outras áreas
que envolvem dados categóricos
• pode ser realizado manualmente ou com o uso de software estatístico.
289. Model Drift
• ocorre quando um modelo se torna menos preciso ou eficaz ao longo
do tempo, devido a mudanças nas condições ou no ambiente em que
está sendo usado
• podem incluir, por exemplo:
• alterações nos dados de entrada
• mudanças na distribuição dos dados
• mudanças nas regras de negócio ou mesmo erros na implementação do modelo
290. Model Drift
• Métodos para identificar:
• Verificação da acurácia
• comparação dos resultados previstos pelo modelo com os resultados reais
• se a precisão do modelo começar a diminuir, isso pode ser um sinal de model drift
291. Model Drift
• Métodos para identificar:
• Monitoramento do desempenho ao longo do tempo
• pode ser feito por meio de gráficos que mostram a precisão do modelo em diferentes
momentos
• Modelos de regressão: MSE, gráficos de distribuição de erros, etc.
• Modelos de classificação: ROC, matriz de confusão, pontuação F1, etc.
• Desempenho em fatias de dados
• Análise dos resíduos
• identifica padrões e tendências que podem indicar model drift
• pode ser feito por meio de gráficos que mostram os resíduos do modelo em diferentes
momentos
292. Model Drift
• Métodos para identificar:
• Comparação com modelos de referência
• pode ajudar a identificar se o modelo está se comportando de maneira diferente do
esperado
• pode ser feito por meio de testes estatísticos que comparam a precisão do modelo com
a precisão dos modelos de referência
• Relação entre o destino e os recursos
• Target Numérico: Coeficiente de Pearson
• Target Categórico: Tabelas de contingência
• Tempo que modelo está tomando para treinar
294. Model Drift
• Pacotes para monitoramento open-source emergentes:
• Data Drift Detector
• Alibi Detect
• scikit-multiflow
295. Arquitetura Databricks Recomendada
• Databricks recomenda implantação de códigos e não modelos
• durante o processo de desenvolvimento de ML, é recomendado promover o
código, em vez de modelos, de um ambiente para outro
• garantia de que todo o código no processo de desenvolvimento de ML passe
pelos mesmos processos de revisão de código e teste de integração
• modelos são criados por código, mas os artefatos de modelo resultantes e o
código que os criou podem operar de forma assíncrona
• Ou seja, novas versões de modelo e mudanças de código podem não acontecer ao
mesmo tempo
296. Arquitetura Databricks Recomendada
• Implantação de códigos e não modelos
• Considere os cenários:
• 1º Cenário: para detectar transações fraudulentas, é desenvolvido um pipeline de ML
que retreina um modelo semanalmente. O código pode não mudar com muita
frequência, mas o modelo pode ser treinado novamente toda semana para incorporar
novos dados
• 2º Cenário: ao criar uma rede neural grande e profunda para classificar documentos.
Nesse caso, o treinamento do modelo é computacionalmente caro e demorado, e é
provável que o novo treinamento do modelo aconteça com pouca frequência. No
entanto, o código implantado, atende e monitora esse modelo pode ser atualizado sem
retreinar o modelo
299. Arquitetura Databricks Recomendada
• É importante considerar a divisão do workspace em três áreas
distintas:
• Desenvolvimento
• Homologação
• Produção
• Abordagens:
• Opção A – fazer a divisão de ambientes por workspace (um workspace para
cada ambiente)
• Opção B – usar um workspace para os três ambientes, mas criando uma pasta
no dbfs para homologação e outra para produção com acessos restritos
(menor custo, menor necessidade de administração)
300.
301. Ambiente de Desenvolvimento
• Onde os cientistas de dados trabalham para desenvolver e testar suas
soluções
• Recomenda-se que os cientistas de dados criem seus próprios
notebooks e arquivos, utilizando-se do controle de código fontes pelo
Azure Devops
• organizados em pastas lógicas que sejam de fácil acesso para toda a equipe
(usar o template ML cookiecutter)
• área de desenvolvimento isolada do resto do ambiente Databricks para evitar
interferências entre as diferentes etapas do processo.
302.
303. Ambiente de Homologação/Staging
• Onde as soluções desenvolvidas pelos cientistas de dados são
testadas e validadas antes de serem enviadas para produção
• Recomenda-se que os modelos sejam treinados em um ambiente de
homologação que seja o mais semelhante possível ao ambiente de
produção
• Garante que os modelos funcionem corretamente e possam ser implantados
com confiança
304.
305. Ambiente de Produção
• Onde os modelos são implantados e executados em produção
• Ambiente crítico!
• Importante garantir a alta disponibilidade e escalabilidade dos
modelos para garantir que as soluções de dados sejam entregues de
forma confiável e consistente
• Recomenda-se o uso de serviços gerenciados:
• Azure Databricks - oferece recursos de dimensionamento automático,
gerenciamento de cluster, monitoramento e outros recursos que facilitam a
operação de soluções em produção