wespatrocinio

Você já parou para pensar se é um facilitador ou um solucionador de problemas?

2020-07-20T00:00:00+00:00

Highlights

Conheça um pouco sobre os perfis de facilitador e solucionador de problemas para saber com qual você se identifica mais;
Avaliar o seu perfil requer que você conheça a si mesmo e converse com outras pessoas;
Busque por situações onde você consegue explorar melhor seu potencial e se sentir mais satisfeito;

Visão geral

Recentemente eu fui exposto a um dilema profissional interessante: atuar liderando iniciativas que facilitariam a utilização de Machine Learning em toda a empresa, ou então assumir iniciativas associadas a um macro-problema e que envolveria o uso de Machine Learning como ferramenta para potencializar a solução do problema em si. Eu acabei optando pela segunda opção após entrar em um processo de reflexão sobre o meu perfil, o que me satisfaz mais e como consigo contribuir de maneira mais assertiva, e gostaria de compartilhar alguns detalhes desta minha reflexão neste artigo.

Facilitador VS Solucionador de problemas

Antes de expôr a reflexão em si, eu gostaria de pontuar aqui o que estou chamando de facilitador e solucionador de problemas:

O facilitador é a pessoa que “lubrifica” a utilização de determinada ferramenta ou tecnologia por outras pessoas da empresa, independente de sua área de atuação. No meu caso, eu teria o papel de criar ferramentas que facilitariam a criação e publicação de modelos org-wise, sendo o facilitador da aplicação de Machine Learning na empresa;
O solucionador de problemas é a pessoa que tem a missão de resolver uma família de problemas específicos, utilizando algumas tecnologias de domínio do time (por exemplo, desenvolvimento backend/frontend, machine learning, entre outros) e também colaborando com outras operações que podem estar associadas a este problema. No meu caso em específico, a família de problemas em si está associada com a Segurança e Qualidade de um marketplace.

O ponto principal da minha reflexão foi qual seria a minha abordagem, em ambos os casos, e como esta abordagem estaria associada às minhas crenças, preferências e aprendizados prévios. Isso é importante para prever fricções futuras e estimar, de maneira grosseira, se o meu trabalho teria bastante impacto para a empresa, uma vez que eu seria o responsável por “dar o tom” da execução das iniciativas.

O facilitador

Ao me colocar no papel de facilitador, eu me vi interagindo com inúmeros problemas diferentes de maneira superficial, tentando mapear as principais dores das diversas áreas e traduzindo-as em ações que permitiriam que determinadas iniciativas das áreas fossem executadas. Ao meu ver, este tipo de pensamento tem algumas premissas associadas:

Eu estaria assumindo que esta ferramenta será amplamente usada pela empresa, o que exige uma série de dependências de outros fatores como proficiência das pessoas em usar tal ferramenta. Por exemplo, se eu construo um reator nuclear em uma empresa metalúrgica esperando que todas as pessoas possam usá-la de maneira adequada e tirando o máximo de seu potencial, talvez eu devesse esperar uns 2-4 anos para que muitos conseguissem estudar o suficiente para ganhar o conhecimento necessário para tal;
Eu estaria abraçando a frase do Maslow que, traduzida pelo popular brasileiro, diz: “Quem vende martelo quer que o mundo acabe em prego”.

O solucionador de problemas

Do outro lado, me coloquei no papel do solucionador de problemas, onde teria contato com um número reduzido de problemas de maneira mais profunda, tendo como papel principal reduzir os impactos negativos causado pelos problemas e aproveitar oportunidade oriundas deles para aumentar os resultados da empresa, papel que traz consigo as seguintes premissas:

Eu teria que buscar a melhor solução para o problema (custo-benefício, escalabilidade, manutenção, etc.) independente da ferramenta para tal solução. Ou seja, posso me deparar diversas vezes com uma solução onde não precisarei utilizar Machine Learning/Data Science para aplicar a melhor solução ao problema;
Quando pensamos em dores causadas por problemas “gritantes”, soluções que tem perspectivas de resultados no curto-prazo ganham uma relevância muito grande durante priorizações, o que pode levar um time a trabalhar nos famosos “puxadinhos” de soluções e causar um problema grande de continuidade no longo prazo.

O que refleti bastante para analisar o dilema

Para comparar tais situações, procurar os pontos fracos e fortes e tomar minha decisão, eu analisei três pontos que considero fundamentais para a execução de um trabalho:

Meus valores e crenças sobre o que é um trabalho bem feito dentro da minha área de atuação;
Quais são os pontos fortes que possuo e como eles se projetam no desafio em vista;
O que me trará mais satisfação e perspectivas futuras;

Valores e crenças

Toda pessoa possui uma “caixa” de valores e crenças e foi preenchida ao longo do tempo e, espero eu, que vá sendo atualizada com novas experiências e fases da vida. Por mais que pareça óbvio, eu sugiro fortemente que você olhe para essa sua caixa constantemente e avalie se está contente com o que está dentro dela.

No caso desta reflexão, eu identifiquei quais seriam meus principais valores associados à iniciativas de resolver problemas usando tecnologia:

Para escolher uma boa ferramenta, você precisa enxergar claramente qual é o seu problema. A analogia que faço sempre sobre este assunto é: se você tentar fixar um quadro na parede tendo um martelo e um parafuso em mãos pode até funcionar, mas você poderia ter um processo muito menos doloroso e com melhores resultados se tivesse olhado um pouco melhor para o problema e suas condições de contorno antes de escolher a solução do seu problema. Olhando para ML/DS, é esperado que muitas pessoas queiram utilizar estas ferramentas para resolver problemas, dado o hype do momento. É importante lembrar também que ferramentas mais sofisticadas exigem bastante conhecimento para manuseio e, se aplicadas de maneira errada, podem gerar mais problemas do que soluções. Como analogia, se uma pessoa com pouco conhecimento de metalurgia tentar fazer uma solda elétrica, ela pode “matar” a peça e gerar efeitos colaterais grandes (problemas no olhos, queimaduras, etc.) se não souber aplicar os EPIs e técnicas adequada.
Não existe bala de prata. Seria muito cômodo ter uma mesma ferramenta que resolvesse todos os nossos problemas, porém é deveras utópico este pensamento. Cada problema específico tende a requerer ferramentas e soluções específicas e que terão seu tempo de vida. Afinal, assim como os problemas, soluções também são efêmeras e devem ser reavaliadas com certa frequência.
Seja simples, e não simplista. Antes se qualquer coisa, gostaria de pontuar o significado de simples que usarei neste contexto. Eu gosto da abordagem do Cortella sobre simplicidade: algo simples significa suficiência, enquanto algo simplista significa algo despreza elementos necessários na solução de um problema (sugiro leituras sobre a Navalha de Ockham). Sendo assim, precisamos resolver os problemas de maneira simples, de forma a reduzir esforços ao máximo porém sendo suficiente na solução do problem (o que exige que você conheça bem o problema - voltamos ao primeiro ponto). Uma solução simplista poderia aplicar algo cool porém que consome um tempo significativo e que não resolve todos os aspectos necessários do problema.

É importante ressaltar aqui que, ao longo das conversas para avaliar ambos meus papéis, eu avaliei o pensamento das pessoas que trabalhariam comigo (líderes, pares, etc.) sobre tais valores e avaliar se haveria sinergia ou fricção de valores.

Pontos fortes

Um aprendizado recente que me foi de grande valia, obtido na leitura do livro “O lado difícil das coisas difíceis” do Ben Horowitz, é que a avaliação de uma pessoa para determinada posição deve considerar os pontos fortes que são necessários para tal posição, e não os pontos fracos que não podem existir para tal. Eu aplico isso tanto para situações onde eu preciso contratar/alocar uma pessoa para determinada iniciativa quanto para auto-avaliações quando eu estou em fase de decidir se aceito um novo desafio profissional.

No meu caso, a minha auto-avaliação (que certamente tem diversos biases), me mostra que tenho os seguintes pontos fortes:

Alta adaptabilidade a novos contextos (problemas e desafios) e ambientes (pessoas e condições de contorno);
Curva de aprendizado bastante acentuada para compreender os pontos mais fundamentais de um contexto, não necessariamente para os tópicos mais profundos;
Habilidades para compreender o real problema existente, pois muitas vezes existe uma distância grande entre o problema sendo avaliado e o real problema existente;
Criatividade em encontrar soluções simples para os problemas que enfrento;
Boas habilidades de comunicação e manipulação (sim, no mundo corporativo há muita manipulação no sentido literal da palavra) para viabilizar a solução de um problema;

Satisfação e perspectivas futuras

Com base nos itens anteriores, eu passei a pensar onde estaria mais satisfeito. Entendo que, para mim, teria maior satisfação se tivesse a oportunidade de aplicar meus pontos fortes e conseguir várias realizações. E, me conhecendo, eu entendo que me sinto realizado quando vejo algo gerando valor até o final da cadeia de valor da qual faço parte, o que me leva à seguinte comparação:

Atuando como um facilitador, eu forneceria ferramentas para que outras pessoas resolvessem os problemas. Supondo que a ferramenta estivesse perfeita e que a solução criada sobre ela funcionasse muito bem, teria um cenário perfeito. Porém, se a ferramenta estiver perfeita mas a solução não estiver e/ou o problema não for mais atacado, eu sentiria certa frustração em não ter gerado o valor necessário;
Atuando como um solucionador de problemas, eu usaria ferramentas fornecidas por outras pessoas para construir a solução e teria como missão fazer o necessário para resolver tal problema, tendo uma dependência menos de pessoas, alinhamentos, etc. para fazer o valor chegar até o final da cadeia. Isso me deixaria mais satisfeito. Obviamente, teriam cenários de falhas e frustrações, mas que estariam sob uma zona de influência mais próxima a mim e onde eu teria maiores capacidades de reverter a situação.

Além da satisfação em si, avaliei as perspectivas futuras. Supondo que tivesse tremendo sucesso em cumprir meu papel e estivesse pensando no próximo passo, me veria capaz de resolver problemas diferentes e/ou maiores, o que geralmente existe em toda empresa. Entretanto, não me enxergo operando ferramentas/plataformas que já funcionam muito bem e fazem parte do cotidiano das pessoas.

Conclusões

Juntando todos os pontos acima, junto com outros fatores não abordados aqui (questões pessoais, financeiras, conversas com pessoas, etc.), decidi seguir com o perfil de solucionador de problemas e aceitar o desafio associado a isso. Entendo que, por ocupar papéis de liderança, eu também tenho que facilitar o cotidiano do time e das outras pessoas envolvidas. Entretanto, a facilitação será um meio para resolver os problemas, e não o fim.

Conflito de cultura em uma linha de _report_

2020-06-26T00:00:00+00:00

Highlights

Não tenha medo do conflito, pois ele é quem mostrará as diferenças e o fará aprender a como resolvê-lo;
Seja ético e transparente a todo momento e com todas as pessoas. Todas;
Lembre-se que você faz parte de uma empresa que conta com diversas estruturas e mecanismos para lhe ajudar. Um “Exército de um homem só”, ou “Messias”, é uma ótima história para ser escrever em livros, não na vida real.

Visão geral

Na minha opinião, um dos principais movimentos do mundo corporativo das últimas décadas é a mudança de uma organização orientada pela hierarquia para uma orientação por uma cultura forte, criando laços mais horizontais entre as pessoas e iniciativas. Entretanto, um impacto imediato desta mudança é o conflito de culturas locais de uma estrutura dentro da organização com a cultura geral da empresa, e é sobre este ponto que eu gostaria de fazer algumas explorações.

Uma possibilidade real, e que eu, particularmente, já enfrentei em minha carreira, é um conflito cultural entre sua liderança imediata e a cultura mais ampla (da empresa ou do time em que trabalha). Neste caso, existem dois pontos importantes:

Neste caso em específico, a maior parte das pessoas está alinhada a uma mesma cultura;
Entretanto, as poucas pessoas que não estão alinhadas a esta cultura do time estão na liderança mais alta do time, causando um conflito hierárquico de cultura.

Em uma situação de conflito hierárquico de cultura, não há democracia. Não é uma questão apenas de adaptar uma pessoa a uma cultura, mas sim um conflito entre pessoas com responsabilidades e poderes diferentes (sim, por mais que existam organizações mais horizontais, líderes ainda tem poder de decisão sobre alocações, demissões, reconhecimentos, etc.), o que requer que mecanismos diferentes sejam utilizados na gestão deste conflito cultural. Em um caso mais “comum”, onde não há disparidade de poder, feedbacks, programas de mentoria e desenvolvimento funcionam em grande parte dos casos. Já com conflito de poder, o mais provável é que uma pessoa não se sinta confortável em dar um feedback direto para sua liderança sobre como seu comportamento está desalinhado com a cultura do time. E, nestes casos, é comum que os gestores mid-level (supervisores, coordenadores, gerentes) tenham que intermediar tal conflito. E é aí que começam a aparecer as armadilhas.

O gestor mid-level como um tradutor cultural

Um caminho comum é que o gestor, que está no fogo cruzado do conflito, tente “absorver” o conflito traduzindo os insumos (diretrizes, feedbacks, comentários, etc.) da liderança mais alta para o seu time, porém sem tentar resolver o conflito, apenas mitigando a fricção do conflito. Ao fazer isso, algumas armadilhas podem ser disparadas:

Falta de transparência

Tal absorção pode levar o gestor a não ser 100% transparente com ambas os lados, maquiando ou omitindo fatores que poderiam aumentar a fricção. Este tipo de ação automaticamente cria vulnerabilidades futuras, pois tais fatores podem aparecer futuramente junto com a omissão ou maquiagem, o que agravará ainda mais a situação.

Para evitar este tipo de situação, o gestor deve sempre buscar a transparência, mesmo que isso crie situações desconfortáveis. E é importante notar que tais situações desconfortáveis não são necessariamente ruins, pois são elas que tornarão evidente que há um conflito a ser tratado. Lembre-se de que ética, transparência e respeito são valores que devem ser aplicado a relações entre duas pessoas quaisquer, não importa o cargo que está escrito na assinatura de e-mail dela.

Resolver o problema sozinho

Uma outra ação que dispara outras armadilhas é a tentativa de resolver tal conflito sozinho, fazendo com o que o gestor tente “comprar a briga” com a liderança sem nenhum tipo de suporte. Isso jamais será um conflito justo por conta da disparidade de poderes. Isso não significa que o gestor não pode sentar com a liderança para expor sua visão sobre o conflito (até sugiro que faça isso o quanto antes). Entretanto, ele deve também buscar os demais mecanismos para mediar tal conflito.

É importante que o gestor enxergue, de maneira clara, que o alinhamento cultural é uma tarefa difícil que conta com o trabalho das áreas de Pessoas/RH e de todos os líderes, incluindo os seus líderes imediatos. Sendo assim, tal conflito deve ser levado para todas as partes necessárias para sua resolução, sempre de maneira transparente. Dessa forma, o gestor pode ter apoio de pares, RH, lideranças ainda mais altas, entre outros, para resolver tal conflito.

Ser apenas um repetidor

Há também o caso onde o gestor resolve se isentar do conflito e agir apenas como um repetidor, também conhecido como “lavar as mãos”. Com isso, os níveis de fricção seriam elevados e ele teria um grande trabalho de remediar os danos de tal fricção (queda de engajamento, demissões, etc.). Como exemplo mais tangível, eu acho extremamente desmotivante receber um feedback do meu gestor, que veio da liderança dele, no formato: “eu vou te dar um feedback que veio da minha liderança, mas isso não significa que eu concorde com ele”. Isso desmonta qualquer expectativa de que o feedback que você recebe foi algo discutido, amadurecido e que é algo que realmente é esperado de você. E a mesma coisa serve para o caminho contrário, quando o gestor, por exemplo, precisa passar um feedback para a liderança sobre o atraso em uma entrega importante, sem se comprometer com este atraso.

Se você é um gestor, automaticamente você é intermediador de uma comunicação onde você tem interferência direta nos fatores. Em outras palavras, toda mensagem que você precisa trafegar entre camadas diferentes de sua estrutura devem ter passado por um consenso/consentimento de todos os que serão representados por aquela mensagem. Por exemplo, se a liderança mais alta quer passar um feedback, via gestor, sobre o comportamento de uma pessoa do time técnico, é necessário que ocorra um consenso entre alta liderança e gestor sobre a mensagem, a qual deve ser repassada à pessoa do time técnico, sem mudanças. Com isso, o gestor também passa a ser dono daquele feedback e age como tal (o famoso skin in the game, tão falado no mundo corporativo atual).

Algumas conclusões

Não tenha medo do conflito, pois ele é quem mostrará as diferenças e o fará aprender a como resolvê-lo;
Seja ético e transparente a todo momento e com todas as pessoas. Todas;
Lembre-se que você faz parte de uma empresa que conta com diversas estruturas e mecanismos para lhe ajudar. Um “Exército de um homem só”, ou “Messias”, é uma ótima história para ser escrever em livros, não na vida real.

AutoML é útil, mas não vai fazer mágica em cima de seus problemas

2020-05-29T00:00:00+00:00

Highlights

As ferramentas de AutoML parecem ter grande potencial de contribuição no cotidiano de um time de Data Science/Machine Learning, porém nas etapas mais adiantadas do processo de desenvolvimento e realease de modelos;
Etapas de entendimento do problema e engenharia de features são pouco impactados por este tipo de ferramentas;
Analisando o auto-sklearn, o processo automatizado tem umas carga de aprendizado bastante grande e exige um certo processo exploratório inicial para redução do espaço de busca de algoritmos e parâmetros para facilitar uma segunda etapa de otimização de hiperparâmetros propriamente dito;
O código usado na exploração do auto-sklearn está disponível em um repositório público na minha conta do GitHub;

O artigo em si

Nos últimos meses tenho me dedicado à identificar e otimizar o cotidiano de times de Machine Learning & AI com processos, políticas e novas tecnologias. Um dos pontos que tenho avaliado em mais detalhes é a utilização de bibliotecas de automated machine learning (AutoML) para auxiliar o processo de encontrar o melhor modelo possível em desenvolvimento. Após algumas análises, decidi compartilhar algumas de minhas impressões neste artigo.

“I have a dream that one day my product is going to be supplied by self-assembled machine learning models.” (Algum C-level de alguma empresa anunciando que agora são AI-first e que serão referência em AI nos próximos 2 anos).

O que será considerado como um modelo neste artigo?

Na minha perspectiva (e acredito que não só minha), um modelo de Machine Learning é composto por três partes fundamentais. Já alerto que simplificarei bastante a descrição das partes para facilitar o entendimento de quem não tem muito vocabulário deste contexto.

Dataset, que contém os dados com todas as features e registros que serão utilizados para o treinamento e validação do modelo, independente do fato de ser supervisionado ou não;
Algoritmo/Ensemble, que é a ferramenta que será usada para encontrar determinados padrões nos dados do dataset e ser capaz de utilizar tais padrões para processar novos registros que sejam requisitados para o modelo e realizar uma predição (classificação, regressão, pattern recognition, etc.).
Hiper-parâmetros: os parâmetros a serem usados pelo algoritmo e que serão otimizados (também chamado de tunning) de forma a obter maior capacidade de predição de um algoritmo sobre um determinado conjunto de dados. Alguns pontos importantes são:
- Existem parâmetros tanto do algoritmo quanto do dataset (por exemplo, balanço entre classes positivas e negativas em um caso de aprendizado supervisionado) e de algoritmo (por exemplo, a profundidade máxima de uma árvore de decisão);
- Um mesmo algoritmo aplicado a dois datasets diferentes pode (e provavelmente irá) requerer diferentes valores de parâmetros para alcançar a performance ótima;

Diagrama simplificado sobre as etapas da criação de um modelo de ML

Qual a minha compreensão sobre AutoML neste momento?

Ao explorar algumas bibliotecas de AutoML como o auto-sklearn, H2O, Google Cloud AutoML e outras, identifiquei, de maneira geral, o seguinte comportamento em todas elas:

oferecem funcionalidades de Engenharia de Features que aplicam novas representações de um mesmo dado (por exemplo, fazer One Hot Encoding de uma feature categórica) mas não abordam muito bem a relevância delas;
oferecem um grande portfolio de algoritmos que serão utilizados na busca pelo melhor modelo;
permitem customizações de métricas e de algoritmos para permitir que os usuários utilizem a ferramenta de AutoML como uma plataforma de otimização que pode ser encaixada nas particularidades de uma empresa;

Dessa forma, as ferramentas que explorei não agregam muito valor à etapa de engenharia de features, com foco explícito no tunning de algoritmos e hiper-parâmetros. Ao meu ver, isso limita bastante a magnitude do impacto que este tipo de ferramenta tem na automação do processo de criação de um modelo. Eis alguns pontos que sustentam esta minha opinião:

Por mais que muitos acreditem que um modelo de ML é um data monster que vai processar milhares de features com dados de usuários dos últimos 10 anos e se tornar um oráculo das predições, não é o que acontece de fato. A etapa de tratamento de dados, construção de features e identificação das mais relevantes compõe os maiores desafios na construção de modelos;
Alguns algoritmos possuem premissas as quais os dados precisam respeitar para que sejam aplicados adequadamente (por exemplo, o LDA assume que os dados tenham distribuição normal e que ambas as classes possuam uma mesma matriz de covariância). A automação apenas do processo de tunning pode contribuir com a negligência deste tipo de validação;

Um breve exemplo: algoritmos vanilla VS `auto-sklearn`

Para exemplificar de maneira mais tangível o valor percebido durante a minha exploração das bibliotecas, eu mostrarei um exemplo simples que construi para explorar como o auto-sklearn funciona e o quanto ele contribuiria para um modelo construído sobre dados que já conheço. Portanto, eu tomei como base um modelo que fiz alguns anos atrás, para fins didáticos, para prever o gênero de uma música a partir de sua letra. Sendo assim, usei os mesmos dados e gerei as mesmas features (tf-idf dos 200 tokens mais relevantes) para treinar um modelo. Neste artigo eu não entrarei em detalhes sobre a geração destas features.

Vanilla Decision Tree

Para ter um baseline simples, vou criar um modelo usando Árvore de Decisão (Decision Tree) com os parâmetros padrão do scikit-learn.

from sklearn.tree import DecisionTreeClassifier

model = DecisionTreeClassifier()
model.fit(train_features, train_target)
predicted_target = model.predict(test_features)
print("Accuracy score: ", sklearn.metrics.accuracy_score(test_target, predicted_target))

O resultado impresso por este trecho de código é:

Accuracy score: 0.6412903225806451

Sendo assim, um modelo criado sobre este conjunto de features usando uma árvore de decisão “padrão” gerou um modelo com 64,1% de acurácia.

Vanilla Random Forests

Da mesma forma que usei uma árvore de decisão sem otimização de hiper-parâmetros como baseline, farei o mesmo com Random Forests.

from sklearn.ensemble import RandomForestClassifier

model = RandomForestClassifier()
model.fit(train_features, train_target)
predicted_target = model.predict(test_features)
print("Accuracy score: ", sklearn.metrics.accuracy_score(test_target, predicted_target))

O resultado impresso por este trecho de código é:

Accuracy score: 0.7896774193548387

A acurácia obtida por este modelo foi de 79,0%, consideravelmente maior que o modelo vanilla de Árvore de Decisão.

`auto-sklearn`

O auto-sklearn é uma biblioteca construída em cima do scikit-learn e que ganhou relevância ao ser apresentado no NIPS e também ao vencer um desafio de AutoML. Pela simplicidade do propósito desta exploração, o escolhi para fazer alguns testes.

Algumas premissas importantes para interpretar melhor o que vem a seguir:

Eu executei os pipelines em meu computador pessoal e para fins de exploração. Sendo assim, não fiz longas e extensivas explorações dos recursos da biblioteca;
De propósito, eu explorei a biblioteca de maneira mais naive e tentando simular como pessoas sem tanta experiência neste tipo de modelagem fariam a exploração;

Show me the code.

import autosklearn.classification
import yaml

with open('config.yml') as f:
    settings = yaml.load(f, Loader=yaml.FullLoader)

automl = autosklearn.classification.AutoSklearnClassifier(**settings)
automl.fit(train_features, train_target)
predicted_target = automl.predict(test_features)
print(automl.show_models())
print(automl.sprint_statistics())
print("Accuracy score", sklearn.metrics.accuracy_score(test_target, predicted_target))

Para executar os pipelines, eu montei as configurações em arquivos yaml com os parâmetros a serem usados pelo pipeline do automl.

`config.yml` sem ensemble

Na primeira tentativa, vou tentar encontrar um modelo simples com apenas um conjunto de algoritmo + hiperparâmetros. Para isso, usei as configurações abaixo.

n_jobs: 2
per_run_time_limit: 120 # 2 minutes
time_left_for_this_task: 1800 # 30 minutes 
include_preprocessors: ['no_preprocessing']
ensemble_size: 1 # to get only a model, not an ensemble

[(1.000000, SimpleClassificationPipeline({'balancing:strategy': 'none', 'classifier:__choice__': 'bernoulli_nb', 'data_preprocessing:categorical_transformer:categorical_encoding:__choice__': 'no_encoding', 'data_preprocessing:categorical_transformer:category_coalescence:__choice__': 'no_coalescense', 'data_preprocessing:numerical_transformer:imputation:strategy': 'mean', 'data_preprocessing:numerical_transformer:rescaling:__choice__': 'normalize', 'feature_preprocessor:__choice__': 'no_preprocessing', 'classifier:bernoulli_nb:alpha': 10.12857981579372, 'classifier:bernoulli_nb:fit_prior': 'False'},
dataset_properties={
  'task': 2,
  'sparse': False,
  'multilabel': False,
  'multiclass': True,
  'target_type': 'classification',
  'signed': False})),
]

O melhor modelo encontrado nesta execução foi o bernoulli_nb (Naive Bayes classifier for multivariate Bernoulli). Até aí, nenhum problema.

As características da execução do pipeline foram:

Metric: accuracy
Best validation score: 0.786458
Number of target algorithm runs: 1903
Number of successful target algorithm runs: 1880
Number of crashed target algorithm runs: 9
Number of target algorithms that exceeded the time limit: 5
Number of target algorithms that exceeded the memory limit: 9

Vamos às métricas:

Accuracy score: 0.7638709677419355

Ou seja, o modelo encontrado automaticamente pelo auto-sklearn foi melhor que o vanilla Decision Tree porém pior que o vanilla Random Forest.

`config.yml` com ensemble

Para explorar melhor as funcionalidades da biblioteca, criei um novo pipeline onde busco como resultado final um ensemble com 3 modelos para maximizar a acurácia da classificação. Abaixo seguem as configurações deste novo pipeline:

n_jobs: 2
per_run_time_limit: 120 # 2 minutes
time_left_for_this_task: 1800 # 30 minutes 
include_preprocessors: ['no_preprocessing']
ensemble_size: 3 # to get only a model, not an ensemble

As características desse ensemble foram:

[(0.333333, SimpleClassificationPipeline({'balancing:strategy': 'weighting', 'classifier:__choice__': 'sgd', 'data_preprocessing:categorical_transformer:categorical_encoding:__choice__': 'no_encoding', 'data_preprocessing:categorical_transformer:category_coalescence:__choice__': 'minority_coalescer', 'data_preprocessing:numerical_transformer:imputation:strategy': 'mean', 'data_preprocessing:numerical_transformer:rescaling:__choice__': 'quantile_transformer', 'feature_preprocessor:__choice__': 'no_preprocessing', 'classifier:sgd:alpha': 1.1309190654192295e-07, 'classifier:sgd:average': 'True', 'classifier:sgd:fit_intercept': 'True', 'classifier:sgd:learning_rate': 'optimal', 'classifier:sgd:loss': 'perceptron', 'classifier:sgd:penalty': 'elasticnet', 'classifier:sgd:tol': 0.0003060155962964433, 'data_preprocessing:categorical_transformer:category_coalescence:minority_coalescer:minimum_fraction': 0.006195858518768137, 'data_preprocessing:numerical_transformer:rescaling:quantile_transformer:n_quantiles': 1929, 'data_preprocessing:numerical_transformer:rescaling:quantile_transformer:output_distribution': 'uniform', 'classifier:sgd:l1_ratio': 0.0018872923177367703},
dataset_properties={
  'task': 2,
  'sparse': False,
  'multilabel': False,
  'multiclass': True,
  'target_type': 'classification',
  'signed': False})),
(0.333333, SimpleClassificationPipeline({'balancing:strategy': 'weighting', 'classifier:__choice__': 'extra_trees', 'data_preprocessing:categorical_transformer:categorical_encoding:__choice__': 'no_encoding', 'data_preprocessing:categorical_transformer:category_coalescence:__choice__': 'no_coalescense', 'data_preprocessing:numerical_transformer:imputation:strategy': 'mean', 'data_preprocessing:numerical_transformer:rescaling:__choice__': 'quantile_transformer', 'feature_preprocessor:__choice__': 'no_preprocessing', 'classifier:extra_trees:bootstrap': 'False', 'classifier:extra_trees:criterion': 'entropy', 'classifier:extra_trees:max_depth': 'None', 'classifier:extra_trees:max_features': 0.23993615625255216, 'classifier:extra_trees:max_leaf_nodes': 'None', 'classifier:extra_trees:min_impurity_decrease': 0.0, 'classifier:extra_trees:min_samples_leaf': 1, 'classifier:extra_trees:min_samples_split': 10, 'classifier:extra_trees:min_weight_fraction_leaf': 0.0, 'data_preprocessing:numerical_transformer:rescaling:quantile_transformer:n_quantiles': 1169, 'data_preprocessing:numerical_transformer:rescaling:quantile_transformer:output_distribution': 'uniform'},
dataset_properties={
  'task': 2,
  'sparse': False,
  'multilabel': False,
  'multiclass': True,
  'target_type': 'classification',
  'signed': False})),
(0.333333, SimpleClassificationPipeline({'balancing:strategy': 'weighting', 'classifier:__choice__': 'qda', 'data_preprocessing:categorical_transformer:categorical_encoding:__choice__': 'one_hot_encoding', 'data_preprocessing:categorical_transformer:category_coalescence:__choice__': 'no_coalescense', 'data_preprocessing:numerical_transformer:imputation:strategy': 'most_frequent', 'data_preprocessing:numerical_transformer:rescaling:__choice__': 'standardize', 'feature_preprocessor:__choice__': 'no_preprocessing', 'classifier:qda:reg_param': 0.40061768323123503},
dataset_properties={
  'task': 2,
  'sparse': False,
  'multilabel': False,
  'multiclass': True,
  'target_type': 'classification',
  'signed': False})),
]

Resumindo, o ensemble é composto por um modelo SGD - Stochastic Gradient Descendent, um Extra Trees e um QDA - Quadratic Discriminant Analysis, cada um com o respectivo conjunto de hiperparâmetros listados no snippet acima.

As características da execução do pipeline foram:

Metric: accuracy
Best validation score: 0.786458
Number of target algorithm runs: 1949
Number of successful target algorithm runs: 1908
Number of crashed target algorithm runs: 10
Number of target algorithms that exceeded the time limit: 6
Number of target algorithms that exceeded the memory limit: 25

Vamos à acurácia:

Accuracy score: 0.7316129032258064

Ou seja, o ensemble obteve uma acurácia de 73,2% que, quando comparada aos casos anteriores, nos dá o seguinte ranking:

Vanilla Random Forest
AutoML sem ensemble
AutoML com ensemble
Vanilla Decision Tree

`config.yml` otimizando apenas o Random Forest

Como terceira tentativa, decidi explorar um pipeline para otimização apenas do Random Forest usando as configurações abaixo:

n_jobs: 2
per_run_time_limit: 60 # 1 minute
time_left_for_this_task: 1200 # 20 minutes 
include_preprocessors: ['no_preprocessing']
include_estimators: ['random_forest'] # include only Random Forest
ensemble_size: 3 # to get only a model, not an ensemble

O melhor modelo encontrado pelo pipeline foi:

[(1.000000, SimpleClassificationPipeline({'balancing:strategy': 'weighting', 'classifier:__choice__': 'random_forest', 'data_preprocessing:categorical_transformer:categorical_encoding:__choice__': 'no_encoding', 'data_preprocessing:categorical_transformer:category_coalescence:__choice__': 'minority_coalescer', 'data_preprocessing:numerical_transformer:imputation:strategy': 'mean', 'data_preprocessing:numerical_transformer:rescaling:__choice__': 'normalize', 'feature_preprocessor:__choice__': 'no_preprocessing', 'classifier:random_forest:bootstrap': 'False', 'classifier:random_forest:criterion': 'gini', 'classifier:random_forest:max_depth': 'None', 'classifier:random_forest:max_features': 0.14928991954179588, 'classifier:random_forest:max_leaf_nodes': 'None', 'classifier:random_forest:min_impurity_decrease': 0.0, 'classifier:random_forest:min_samples_leaf': 2, 'classifier:random_forest:min_samples_split': 8, 'classifier:random_forest:min_weight_fraction_leaf': 0.0, 'data_preprocessing:categorical_transformer:category_coalescence:minority_coalescer:minimum_fraction': 0.010000000000000004},
dataset_properties={
  'task': 2,
  'sparse': False,
  'multilabel': False,
  'multiclass': True,
  'target_type': 'classification',
  'signed': False})),
]

Ao olhar os parâmetros usados neste modelo, é possível observar que foram poucas as customizações de parâmetros realizadas, o que resulta em um modelo razoavelmente próximo ao vanilla Random Forest.

As características da execução do pipeline foram:

Metric: accuracy
Best validation score: 0.786458
Number of target algorithm runs: 1260
Number of successful target algorithm runs: 1253
Number of crashed target algorithm runs: 0
Number of target algorithms that exceeded the time limit: 7
Number of target algorithms that exceeded the memory limit: 0

Os números acima mostram que o pipeline executou mais de 1200 configurações diferentes de modelo, com alguns poucos casos que excederam o limite de tempo de 1 minuto por modelo.

Vamos às métricas:

Accuracy score: 0.8025806451612904

Ou seja, este pipeline resultou em um modelo que alcançou uma acurácia de 80,3%, o maior alcançado até o momento. Entretanto, o ganho não foi muito substancial (1,6%) e o resultado final foi um modelo muito parecido com o vanilla.

Algumas conclusões e próximos passos

Das opções testadas, o melhor modelo obtido foi a partir de um pipeline do auto-sklearn otimizando apenas Random Forests. Entretanto, o resultado de acurácia é muito semelhante ao vanilla Random Forest;
Há uma curva de aprendizado considerável para extrair o melhor da biblioteca;
É possível que eu tenha dedicado pouco tempo de computação para este tipo de otimização pelo auto-sklearn. Se for o caso, acredito que este tipo de “necessidade” poderia ficar mais explícito nas documentações para que os usuários tivessem uma expectativa mais realista sobre o que precisariam para extrair valor da biblioteca;

Do fundamento à aplicação: Árvores Métricas

2020-02-16T00:00:00+00:00

Este será o primeiro artigo de uma série chamada “Do fundamento à aplicação”, que abordará, através de exemplos e pequenas aplicações, a importância de conhecer bem os fundamentos das metodologias e ferramentas que utilizamos em nosso dia-a-dia para que possamos fazer boas escolhas na hora de criar e implementar soluções, sejam elas técnicas ou gerenciais. Além da conexão entre fundamentos e aplicações, haverá uma tentativa de traduzir alguns conceitos para uma linguagem menos formal e técnica.

O tema estreante será uma estrutura de dados bastante interessante e de muita utilidade: as Árvores Métricas (fundamento) cuja aplicação é um bom e velho conhecido de todos nós — corretor ortográfico.

Alguns fundamentos importantes

O principal propósito deste tipo de conteúdo e mostrar, além de trechos de código mostrando como construir uma aplicação, o que está “embaixo do capô” deste código, permitindo um entendimento mais completo da solução, além de maiores capacidades de extensão de partes específicas para resolver problemas que são próximos a este.

Nesta seção, serão abordados, de maneira resumida e com referências para que vocês possam se aprofundar nos temas, alguns fundamentos que serão a base para a construção da aplicação em questão — um corretor ortográfico. Os temas serão:

Conjuntos e domínios de dados;
Espaços métricos e Árvores;
Distância de edição;
Árvores de BK;

Conjuntos e Espaços Métricos

Suponha um conjunto de dados com 1000 pontos 2D (x, y), amostra a qual será chamada A, cujos valores de x e y variem entre 0 e 1([0,1]²), intervalo o qual pode ser chamado de domínio (D).

import random
import pandas as pd
import numpy as np

def generate_random_df_2d(x_size: int, y_size: int) -> pd.DataFrame:
    """ Generate a dataframe with dimensions 'x_size' and 'y_size' filled with
        random float numbers between 0 and 1
    """
    return pd.DataFrame(np.random.random_sample(size=(x_size, y_size)))

Toda vez que um conjunto de objetos, seja o objeto numérico (como o os números inteiros ou reais) ou de outro tipo (palavras, imagens, etc.) ter uma métrica bem definida que pode ser associada, então este conjunto pode ser classificado como um espaço métrico.

Mas o que significa exatamente a tal métrica?

De uma perspectiva mais próximo da matemática, uma métrica existe quando os pontos de um conjunto satisfazem as seguintes condições:

A distância de um ponto para ele mesmo é zero (0);
A distância entre dois pontos distintos (A e B) quaisquer é sempre positiva;
A distância entre os pontos A e B é a mesma entre os pontos B e A;
A distância entre dois pontos A e B, medida diretamente, é sempre menor ou igual à distância medida entre A e B passando por um ponto C (o que está associado ao Teorema da Desigualdade Triangular, que será usado mais a frente);

Do ponto de vista mais intuitivo, uma métrica remete à distância entre dois pontos (ou objetos), como duas pessoas em uma praça (cuja distância pode ser medida em linha reta) ou duas localizações em uma cidade (cuja distância pode ser medida em linha reta ou através do trajeto a ser percorrido nas ruas). Entretanto, tal conceito também pode ser aplicado a tipos de objetos não muito comuns, como música (que tem métricas bem definidas) ou palavras, que possuem distância de edição entre si (que abordaremos em mais detalhes mais à frente).

Figura ilustrando o Teorema da Desigualdade Triangular

Distância de edição

A distância de edição entre duas strings é a contagem de operações que precisam ser realizadas para uma string transforme-se (ou torne-se igual) à outra, sendo que as operações possíveis são:

Inserção de novo caractere;
Remoção de caractere;
Substituição de caractere;

Sendo assim, dado um conjunto de palavras ou sentenças (também chamado de corpus), é possível encontrar a distância de edição entre uma referência (que pode ser uma palavra qualquer de seu corpus). Abaixo segue um trecho simples de código para calcular a distância entre duas palavras:

# Install it by "pip install python-Levenshtein"
from Levenshtein import distance

def calculate_distance(str_1, str_2):
  """ Given two string, applies the Levenshtein's method to calculate the
      editon distance
  """
  return distance(str_1, str_2)

In [1]: calculate_distance(“motocicleta”, “bicicleta”) 
Out[1]: 4

Árvores de Burkhard-Keller (BK)

As árvores BK são um tipo de árvore métrica dedicadas a espaços métricos discretos, ou seja, cujas distâncias entre os objetos do espaço são sempre números inteiros.

Como exemplo, vamos pensar no espaço métrico que representa pontos em um mapa. Lembrando que todo espaço métrico possui uma métrica específica que o define, precisamos escolher muito bem qual a métrica a ser usada neste exemplo para que ele seja elegível à aplicação de uma árvore BK. Se escolhermos a distância Euclideana (linha reta entre dois pontos), teremos uma métrica cujos valores podem variar de maneira contínua, em outras palavras, números reais. Entretanto, se escolhermos como métrica o número de quarteirões a serem percorridos por inteiro, tal métrica terá apenas valores inteiros e teremos um espaço métrico discreto.

Voltando à nossa aplicação de interesse, a distância de edição de Levenshtein é uma métrica discreta, pois o número de operações a serem realizadas para transforma uma palavra em outra é sempre um número inteiro. Com isso, o espaço métrico que representa um conjunto de palavras cuja distância entre si é calculada pela distância de Levenshtein é um espaço discreto e, portanto, pode ser representado por uma árvore BK.

Para a construção da árvore propriamente dita, basta escolhermos um termo arbitrário (que chamarei de termo de referência) do corpus e calcular a distância de todos os outros termos com relação à referência, e organizar as tuplas (palavra, distância) como uma árvore indexada a partir da distância à referência.

Ilustração de uma árvore BK a partir de algumas palavras em inglês

Abaixo segue um trecho de código mostrando como criar e usar uma árvore BK a partir de: uma lista de palavras (strings) e uma métrica de distância de edição escolhida (Levenshtein).

# pip install pybktree && pip install python-Levenshtein
from pybktree import BKTree
from Levenshtein import distance as levenshtein_distance

WORDS_LIST = ['car', 'house', 'jar', 'mouse', 'engineer', 'pioneer', 'Jamaica']
tree = BKTree(levenshtein_distance, WORDS_LIST)

Se pedirmos a impressão ordenada da árvore, lembrando que o termo de referência dela é arbitrário, teremos uma lista de palavras ordenadas pelas distância de edição à primeira palavra da lista:

In [1]: print(sorted(tree))
Out[1]: [‘Jamaica’, ‘car’, ‘engineer’, ‘house’, ‘jar’, ‘mouse’, ‘pioneer’]

E se quisermos procurar quais palavras da árvore estão a uma distância de edição menor ou igual a 2 da palavra mouse, teremos como resultado uma lista de tuplas (distância, palavra) ordenadas pela distância:

print(tree.find('mouse'), 2)
[(0, ‘mouse’), (1, ‘house’)]

Como isso se tornaria em um corretor ortográfico?

Dado que agora temos uma árvore onde podemos procurar quaisquer palavras que sejam semelhantes a uma determinada referência, podemos então construir uma árvore com todas as palavras de uma determinada língua (o PT-BR, por exemplo, possui cerca de 381 mil verbetes) e, para cada palavra digitada, checar se existe uma palavra com distância zero (0) para ela e, caso não tenha, sugerir as palavras com menor distância de edição para tal. Simples, não é?

Exemplificando, se eu estivesse escrevendo um texto em inglês e digitasse a palavra gouse. Usando meu exemplo acima, eu poderia procurar as palavras com distância de edição até 3 e obteria o seguinte resultado:

In [1]: tree.find(‘gouse’, 3) 
Out[1]: [(1, ‘house’), (1, ‘mouse’)]

Como não foi encontrada nenhuma palavra com distância zero, eu assumiria que essa palavra está errada e sugeriria as palavras house e mouse como as prováveis palavras que deveriam ocupar este espaço.

Obviamente esta é uma visão bastante simplificada de como resolver o problema, afinal existem diversos desafios periféricos à identificação de palavras não existentes:

Engenharia: percorrer árvores com centenas de milhares de nós em near-real-time. O algoritmo do “caixeiro viajante” é uma boa solução para varrer este tipo de estrutura;
Semântica: se existem duas palavras com mesma distância, qual a que mais se encaixa no contexto? E se for um erro de digitação, qual das duas palavras estaria mais próxima no quesito “proximidade de teclas”?
Multi-idiomas: só neste texto eu misturei uns 3 idiomas.

Entretanto, entender como o núcleo da solução funciona lhe permite entender melhor os desafios e como conectar esta solução com todas as funcionalidades e objetivos que você deseja alcançar ao desenvolver tal aplicação.

Referências

https://en.wikipedia.org/wiki/Metric_space
https://pt.wikipedia.org/wiki/Desigualdade_triangular
https://www2.unifap.br/matematica/files/2017/01/Francinor-m%c3%a9trico-completos-e-teorema-de-Banach-steinhuas.pdf
http://www.ppgia.pucpr.br/~alceu/mestrado/edit_distance.pdf
https://en.wikipedia.org/wiki/BK-tree
https://pt.wikipedia.org/wiki/Problema_do_caixeiro-viajante

Aumente a visibilidade de AI adotando seu vocabulário no cotidiano

2020-01-29T00:00:00+00:00

De maneira aproximada, estamos completando uma década desde que a tsunami tecnológica associada a Data Science, Machine Learning, Inteligência Artificial e afins atingiu o mundo corporativo. Abriram as portas dos laboratórios e vimos uma séries de pessoas, recursos e conceitos, que ficavam “confinados” no mundo acadêmico e/ou P&D, adentrarem o cerne das pequenas, médias e grandes empresas de maneira transformadora. E, por mais que a aceitação e entendimento destas áreas tenham evoluídos, ainda há bastante espaço para a otimização da exploração destas metodologias e tecnologias.

Não é de hoje que a humanidade coloca sua esperança de sobrevivência sobre redes neurais.

No momento em que escrevo este texto, estou há 7 anos desenvolvendo e/ou aplicando Data Science, Machine Learning, AI e afins (que vou abreviar adiante como DS/ML/AI) no mundo corporativo, somados a outros anos de bagagem acadêmica e P&D. E, neste período, identifiquei dois grandes blocos desafiadores neste mercado: I) os desafios técnicos (contratações, plataformas, modelos, etc.) e II) a integração de áreas de DS/ML/AI à estratégia & tática da empresa. Neste artigo eu vou explorar um ponto fundamental no item II citado a pouco.

Reflexão sobre linguagem, instrumentação e interpretação de conceitos

Se você, que está lendo, já foi exposto a um ambiente onde todas as demais pessoas são proficientes em determinados que você não conhece, deve ter pensado (ou até falado) algumas vezes: “estas pessoas estão falando “grego” e eu não estou entendendo nada”. Este tipo de situação já foi bastante comum em iniciativas de DS/ML/AI há alguns anos, pois os profissionais da área estavam ventilando conceitos e fundamentos que não eram de conhecimento comum (geralmente técnicos), enquanto estas mesmas pessoas não eram familiares ao mundo corporativo e seu modo de funcionar.

Wat?

Atualmente, os profissionais da área já estão mais “educados” pelo mundo corporativo porém o “tecniquês” ainda é usando por muitos DS/ML/AI por alguns motivos:

Ego inflado (simples assim);
Mecanismo de defesa, pois se as pessoas ao redor não entendem exatamente o que o DS/ML/AI está propondo, tem menor poder de questionamento sobre o tema;
Falta de empatia com as pessoas ao redor;

Entretanto, o uso demasiado de termos muito específicos dos conceitos e fundamentos associados a DS/ML/AI, sem a devida evangelização, causa um problema de comunicação entre os times pois não há uma linguagem comum entre tais e, pasmem, o uso de linguagens diferentes entre dois grupos podem gerar um impacto profundo no cotidiano da convivência dentro das empresas: uma má exploração deste tipo de recurso.

Linguagem como instrumento

Para explicar o impacto do uso de diferentes linguagens, eu vou abordar de maneira resumida (até porque não tenho muitas condições de ir além disso) alguns conceitos de linguística e cognição, além de dados de um experimento muito interessante para validar algumas teorias associadas.

A linguagem é um instrumento para que tenhamos a difusão de conhecimento para um determinado grupo/comunidade. Quando um conceito novo surge na sociedade, ele ganha potência de difusão quando são estabelecidos termos específicos e únicos para descreve-lo. Entretanto, quando não existem tais termos para os grupos, há uma grande dificuldade na identificação e entendimento daquele conceito.

“You’re talking a lot, but you’re not saying anything”.

No século XIX, William Gladstone, um intelectual e político britânico, identificou que nas obras de Homero e de outros autores da Grécia antiga não havia a menção à cor azul. Tal descoberta inspirou outros pesquisadores, que identificaram um comportamento semelhante em outras culturas, até que o psicólogo Jules Davidoff fez experimentos em uma tribo na Namíbia (país africano), cuja linguagem não possui uma palavra para a cor azul, mas possui vários termos para diferentes tons de verde. Ele mostrava 11 quadrados verdes e 1 azul para as pessoas e questionava qual era o quadrado diferente, porém eles não foram capazes de identificar. Ao trocar o quadrado azul por um tipo diferente de verde, as pessoas identificaram instantaneamente.

Palavras que descrevem as diferentes cores no dialeto Himba, na Namíbia. Note que o termo ‘buru’ descreve um tom verde e um azul..

Projeção para o mundo corporativo

Projetando a linguagem como instrumento de difusão e interpretação para o mundo corporativo e as interações com DS/ML/AI, a utilização de termos específicos da área e que não fazem parte do vocabulário dos demais grupos fazem com que ocorra má interpretação ou até certa “invisibilidade” sobre a contribuição que estes novos conceitos pode dar às iniciativas entre equipes diferentes (o que em tempos de metodologias Lean e Agile é praticamente mandatório), aumentando a fricção nas interações e diminuindo o potencial da exmploração de DS/ML/AI pelas empresas.

O que devemos fazer ao saber disso?

Sabendo disso, tenho algumas dicas para mitigar este tipo de problema na empresa/instituição com a qual você colabora (e elas funcionam para todas as posições e/ou senioridade):

Tenha mais empatia pelo público-alvo do seu discurso e tente, quando possível, traduzir os termos específicos de DS/ML/AI para descrições mais comuns a outros contextos;
Evangelize a terminologia de DS/ML/AI para a empresa e sugira conteúdo introdutório para as pessoas que terão interação direta com tais times (ninguém precisa ser necessariamente phD em Ciência da Computação ou Estatística para conseguir entender e tirar proveito dos conceitos). Cursos como o AI for Everyone, do Andrew Ng, são ideias para este propósito;
Não caia na famosa “Lei da ferramenta” de Maslow (abaixo) e ache que DS/ML/AI é a bala de prata para resolver todos os problemas. Lembre-se que nas demais equipes existem pessoas tão inteligentes quanto a sua equipe, porém que dominam técnicas diferentes e que podem ter “poderes” que você ainda não conhece e/ou sabe explorar;

“Eu suponho que é tentador, se a única ferramenta que você tem é um martelo, para tratar tudo como se fosse um prego”. (Abraham Maslow)

Referências

https://www.youtube.com/watch?v=kdHmy0_Rkcw

Não incentive o _Night Hero_ em seu time

2020-01-27T00:00:00+00:00

Macacos me mordam! As APIs estão indisponíveis novamente, Batman!

Em tempos de trabalho remoto, ambientes digitais acessíveis de qualquer lugar e comunicação & trabalho assíncronos, eu vejo o surgimento de um novo tipo de profissional, principalmente em times de tecnologia, no qual vejo muitos riscos: o Night Hero (o qual chamarei carinhosamente de NH neste texto). O profissional que estou chamando de NH é a pessoa que está sempre disponível, não importa o dia e horário que a demanda apareça. É 24/7 em alerta, trabalhando aos domingos a noite para garantir que a segunda estará operante, que está sempre alerta para os incidentes e desastres, etc.

Uma breve análise sobre esforço VS eficácia

Em times de tecnologia, é comum que estas figuras tornem-se mais evidentes em áreas de Desenvolvimento, Infraestrutura/DevOps e Suporte. Em todo tipo de acidente/incidente, o NH está lá presente trabalhando na sustentação, mandando e-mails, interagindo com pessoas em outros fusos horários, etc., enquanto deveria estar dormindo, junto com a família, praticando atividades físicas, entre outros. Tanto faz se o problema foi causado por algo feito pelo próprio NH ou por alguém que não tem nenhuma relação direta com ele. E é nesta hora que entra uma análise bastante pertinente a este tipo de situação: esforço VS eficácia.

O que eu espero de uma pessoa, no aspecto profissional, é que ela trabalhe com a máxima eficácia possível sobre o pacote de trabalho acordado por ambas as partes (sejam horas semanais, prazos de entrega, metas, etc.). Entretanto, se a quantidade de esforço para cumprir determinado acordo é muito maior do que o esperado, duas suspeitas óbvias surgem instantâneamente: o tamanho do pacote de trabalho foi subestimado e/ou a eficácia da pessoa a executar o trabalho foi superstimada.

O reconhecimento fomenta o comportamento, seja ele saudável ou nocivo

Voltando para o Night Hero, na maior parte dos casos que presenciei e convivi, a causa principal foi a combinação (explosiva) entre uma alta carga de trabalho com uma pessoa com maiores níveis de ansiedade. E ao identificar este cenário, eu, como gestor, entendo que o ideial seria executar ações que i) reduza a carga de trabalho e/ou ii) ajuste os níveis de ansiedade da pessoa. Porém, o que vejo com certa frequência é uma terceira ação: o reconhecimento ($, faz-me-rir, tutu, etc.) dessa pessoa.

Ao reconhecer uma pessoa por um comportamento específico (de maneira implícita ou explícita), você está fomentando a continuade ou até aumentando a intensidade do mesmo.

Ao meu ver, o reconhecimento deste tipo de comportamento é um fomento para que ele torne-se latente, ao invés de um mecanismo de desenvolvimento do profissional. Idealmente, o desenvolvimento deveria ser guiado pela gestão de iniciativas que ajudem a mitigar as causas que levaram a este esforço excessivo por parte do NH, aumentando a eficácia do profissional e da equipe.

Isso não impede que o gestor seja grato ao esforço extra feito pela pessoa, ou o reconhecimento por ela alcançar as metas que, de alguma maneira, exigiram aquele esforço.Entretanto, o reconhecimento ao puro e simples esforço é algo que pode ser bastante nocivo por alguns motivos:

Ao saber que sempre existe alguém disponível para atuar em problemas, pessoas do time podem perder compromisso com práticas preventivas e aumentar a ocorrência de incidentes, sobrecarregando ainda mais o NH;
Toda pessoa sobrecarregada pode ser induzida a tomar más decisões e/ou cometer erros técnicos, o que, geralmente, aumenta a quantidade de re-trabalho e a ocorrência de incidentes. Ou seja, aumenta a sobrecarga no NH e do restante do time;
Altos níveis de ansiedade e estresse podem causar danos à saúde das pessoas envolvidas, os quais podem graves(quem nunca ouviu a história da pessoa que infartou no escritório depois de um período de alta carga de trabalho?);
As metas associadas à ações preventivas e/ou avaliação da contratação de mais pessoas para o time podem ser despriorizadas, pois o time possui uma “segurança” na sustentação do time feita pelo Night Hero;

O que eu penso que devo fazer neste tipo de situação?

Dado este cenário, as minhas dicas, como gestor, de como agir ao identifica um Night Hero são:

No curto prazo, puxe o time para a realização de post-mortem dos incidentes de forma a envolver e conscientizar todas as pessoas das causas, dos impactos do incidente (dando ênfase à dedicação extra do NH) e das ações para mitigar os riscos identificado. Sugiro também conversar 1:1 com o NH para deixar claro que não é interessante ter aquele tipo de atuação como rotina e induzi-lo a compensar as horas a mais já nos dias seguintes;
No médio prazo, priorize ações preventivas baseadas nos riscos identificados e divida a responsabilidade de execução de tais ações com todo o time. É importante que o máximo de pessoas possível compartilhe os riscos do contexto em que trabalham, assim os esforços e ansiedades também são compartilhados;
No longo prazo, planeje recursos e investimento para deixar o cotidiano/operacional de sua equipe mais robusto e com menos riscos, de forma a ter um dia-a-dia mais saudável em sua equipe e operação;

Espero que esta reflexão lhes seja útil.

Um abraço!

Data Science é metodologia, e não tecnologia

2017-07-25T00:00:00+00:00

Assim como P&D (Pesquisa e Desenvolvimento), Data Science sofre com o desbalanço entre as ponderações dos termos. Em P&D, o Desenvolvimento tem um peso muito mais forte que Pesquisa. Em Data Science, o Data ganhou muito mais peso e dominou as falácias de corredores e Meetups. Porém não se engane: we’re talking about Science, bitch!

O estereótipo das pessoas sobre os Cientistas.

A Ciência de Dados é constituída de princípios fundamentais que norteiam a extração de conhecimento a partir de dados (assim como Ciências Naturais — como Física e Química) extraem conhecimento de fenômenos naturais. Sendo assim, data mining, machine learning e estatística são ferramentas usadas para a extração de conhecimento de um domínio de dados. De maneira mais franca, o que eu quero dizer é que existe Data Science sem Machine Learning e vice-versa, ou seja, um Cientista de Dados não é necessariamente um Engenheiro de Machine Learning e vice-versa.

Entretanto, como este é um termo do mundo dos negócios, a Ciência de Dados trouxe também a responsabilidade de automatizar e sistematizar tal extração de conhecimento para tomadas de decisão, de forma a substituir o modelo tradicional de um time de analistas olhando para dados e opiniões para extrair algum conhecimento. Atualmente existem dois cenários macro de aplicações de tomadas de decisão orientada por dados, usando os princípios de Data Science: (1) as descobertas realizadas a partir de dados e (2) decisões repetitivas e em grande escala. O caso (1) está mais próximo do que hoje é chamado de Advanced Analytics, onde a empresa adquiri novas informações apenas “olhando” para os dados. Grandes exemplos deste formato estão no Walmart, como o caso do furacão Frances e as associações de compra entre fraldas e cervejas e a mudança da disposição dos produtos em suas lojas físicas. Já o caso (2) pode ser representando pelos sistemas de recomendação, onde a própria aplicação decide automaticamente quais produtos deve exibir para o usuário.

Este ponto de vista metodológico de Data Science ajuda na sua desambiguação de Big Data e Data Engineering. Estes últimos são áreas complementares que viabilizam o uso de dados para aprendizado e decisões, porém não fazem parte necessariamente do processo de aprendizado e decisões. Ocasionalmente, tecnologias e técnicas de Big Data e Data Engineering são utilizadas na implementação de exploração e mineração de dados. Eu vejo um jeito simples de separar os conceitos: as respostas da pergunta “o que eu preciso fazer para ser capaz de acessar e processar todos os meus dados?” são iniciativas de Big Data e Data Engineering. Já as respostas de “o que eu consigo aprender ou fazer melhor a partir dos meus dados?” se enquadram no contexto de Data Science.

Esta mescla técnica entre engenharia e ciência existe em todos os contextos. Um cientista da computação precisa saber programar, um físico precisa saber construir experimentos, assim como um químico precisa saber como operar instrumentos e equipamentos de um laboratório. Dessa forma, um cientista de dados precisa saber técnicas de manuseio de dados para realizar o seu trabalho, seja construindo aplicações para cenários particulares ou utilizados ferramentas já prontas. Além disso, lembrando da responsabilidade “brinde” de sistematizar e automatizar suas tarefas, conhecimento de arquitetura de sistemas e produtos são muito úteis e bem-vindas (embora não seja requisitada por e para todos).

Já uma mescla que continua carente em dias atuais é a de gestores que compreendem de maneira clara o que é Data Science e como ela deve ser executada. Empresas cujos gestores não compreendem este assunto perdem tempo e dinheiro por decisões erradas, seja por recrutar as pessoas com perfil inadequado ou então por decisões erradas com base em projetos mal estruturados. Uma empresa que deseja ter sucesso aplicando esta metodologia deve tratar Data Science como um ativo estratégico, investindo de ponta a ponta (desde coleta de dados, passando por engenheiros e cientistas até chegar na camada de gestão). No final das contas, a implantação desta metodologia terá forte impacto nos processos e na cultura da empresa, que junto às pessoas formam a espinha dorsal de uma organização.

Este artigo foi inspirado em alguns insights obtidos com a leitura do livro Data Science for business (Foster Provost & Tom Fawcett).

_Statistical Learning Theory_ — você deveria usar mais do que imagina

2017-07-25T00:00:00+00:00

Tem aumentado a frequência em que eu escuto profissionais e simpatizantes de Data Science minimizando (ou até desprezando) a importância de conhecimento em Estatística para a criações de soluções baseadas em Inteligência Artificial e/ou Machine Learning. Isso sempre me remete a mesma preocupação com relação a uma etapa importante da modelagem e que está cada vez mais sendo negligenciada: a validação de algumas premissas necessárias para que ocorra aprendizado supervisionado em um domínio de dados.

Por conta disso, eu gostaria de trazer à tona alguns conceitos básicos de Statistical Learning Theory que abordam algumas premissas que um bom conjunto de dados pode ter para que uma seja possível a construção preditiva baseada em dados, ou seja, para garantir que um algoritmo será capaz de aprender corretamente.

http://letterstoayounglibrarian.blogspot.com/2016/04/on-bias.html

Usando uma linguagem mais cotidiana, estamos falando do famoso BIAS, que ocorre quando uma de suas variáveis contém a distribuição de probabilidade de seu alvo. Por exemplo, se você está tentando prever se uma pessoa é completamente careca ou não, ter uma variável que contém o número de fios de cabelo que cada indivíduo tem incluirá a distribuição de carecas no treinamento, dado que o fator que determina a classe do indivíduo é ele ter fios de cabelo ou não. Portanto, seu algoritmo lhe fornecerá um diagnóstico, e não uma previsão.

Para mitigar tal tipo de problema, uma análise de covariância ou de dependência linear entre suas variáveis e seu alvo podem lhe ajudar a identificar a ocorrência de BIAS.

A distribuição de probabilidade de seu alvo deve ser estática

https://www.slashgear.com/one-percent-of-tv-static-originates-from-the-big-bang-24492754/

Em outras palavras, quero dizer que seus dados não podem ter dependência temporal dentro das condições de contorno de seu problema. Caso não seja, seu algoritmo aprenderá a construir uma função de predição que não será mais a mesma após determinado intervalo de tempo, e haverá degradação de seu poder de predição.

Para casos de variação temporal dentro de suas condições de contorno, abordagens como Séries Temporais são mais adequadas.

As amostras usadas para aprendizado devem representar todo o seu espaço amostral

https://www.theodysseyonline.com/5-reasons-why-representation-matters

Ao escolher um conjunto de elementos para construir uma amostra de seu domínio de dados, você deve garantir que todo o seu espaço está representado por tais amostras, ou seja, de que existem amostras de todas as regiões de seu espaço e que a proporcionalidade dos grupos contidos neles também é mantida.

Imagine que você está na fila de um banco com outras 100 pessoas (que baita fila) e queira criar um grupo de indivíduos que represente todas as pessoas que ali estão. No final de sua amostragem, temos 10 indivíduos: 2 crianças de até 10 anos, 5 mulheres entre 25 e 35 anos, 3 homens entre 18 e 25 anos. Esta amostra lhe diria que:

20% das pessoas na fila são crianças;
Não existem idosos na fila do banco;
Há quase o dobro de mulheres na fila se comparadas aos homens;

Entretanto, se você olhar o espaço como um todo pode perceber que o espaço completo não está sendo bem representado, pois existiam idosos na fila, e as 2 crianças na amostra na verdade eram as duas únicas crianças em toda a fila. Este tipo de situação pode acontecer por três motivos principais:

Uma amostragem feita de maneira não aleatória;
Uma amostragem aleatória, porém com uma quantidade pequena o suficiente para não considerar alguns grupos minoritários contidos no espaço;
Diferença entre as condições de contorno (ou segmentação) que definem o espaço completo e o amostral;

Para evitar tal tipo de situação, analisar a variância de sua amostra e compara-la com a mesma métrica do espaço completo pode lhe ajudar a evitar tal tipo de situação.

As amostras devem ser independentes entre si

https://brilliant.org/practice/conditional-probability-in-quant-finance/

Ao desenhar sua amostragem, os indivíduos de seu espaço amostral não podem ter dependência entre si, ou seja, a probabilidade de um evento acontecer para uma indivíduo não pode ser condicional a outro indivíduo ou então exigir que seu espaço amostral contenha determinados indivíduos.

Um bom exemplo é a boa e velha predição de churn. Suponha que você trabalha com um produto cujo modelo de negócio é uma assinatura mensal que permite uma estrutura de titular e dependentes do plano. Ao tentar modelar sua predição tendo como alvo o churn de um usuário, automaticamente você terá dependência condicional em seu espaço, já que a assinatura, alterações contratuais e cancelamentos ocorrerão sobre todos os usuários que estão contidos em uma conta.

Em termos mais técnicos, tal condicionamento é ruim para o aprendizado pois a sua distribuição de probabilidade do alvo dependerá de escolhas específicas de sua amostragem. Para evitar tal tipo de situação, você deve identificar muito bem qual é a melhor representação para o indivíduo de seu espaço (que no exemplo acima seria uma conta, e não um usuário).

Seu alvo pode ter ruído

The Germs: ruído de qualidade - http://www.latimes.com/entertainment/arts/miranda/la-et-cam-slash-magazine-book-exhibition-20160719-snap-story.html

Por último, mas não menos importante, vem o fato de que seu alvo, representado pela classe/valor alvo de cada indivíduo em seu espaço amostral, pode ter ruído, ou seja, erros de classificação no ground truth, desde que sejam minoritários.

Este item é importante pois é muito comum que alguns profissionais, durante a validação da qualidade dos dados e variáveis, encontre certo ruído e sintam-se tentados a remover os indivíduos ruidoso de seu espaço amostral. Ao fazer isso, você estará alterando as características de seu espaço e impactando as capacidades de seu modelo. Muito provavelmente você terá que processar novas entradas que possuem este perfil problemático (por exemplo, erros em sistemas de cadastro feitos manualmente) sem ter permitido que seu modelo tivesse amostras desse perfil em seu conjunto de dados de treinamento. Lembrando que a premissa é que tal ruído seja minoritário e será tratado como tal pela predição.

Repare que todos os pontos abordados acima estão diretamente relacionados a conceitos estatísticos (e a maior parte deles não muito avançados). Sendo assim, se você não enxerga a importância de tais conceitos em seu dia-a-dia, pode ser que algumas etapas importantes de seu trabalho estejam sendo negligenciadas.

Precisamos falar mais sobre metas em Data Science

2017-07-10T00:00:00+00:00

Eu classifico 2017 como o ano da popularização de iniciativas de Data Science no mercado brasileiro, seja pelo surgimento ou melhoria de ferramentas que catalizam as iniciativas (como os serviços e bibliotecas de AWS, Google, Microsoft, IBM, etc.), pelo aumento do número de profissionais engajados e qualificados na área ou pelo aprendizado que a camada de gestão de negócios teve nos últimos anos neste contexto. O fato é que vemos empresas de diversos tamanhos e segmentos “espremendo” dados para extrair valor de diversas formas.

Moisés e seu cajado de METAS dividindo um mar de falácias sobre Data Science.

Os últimos anos de evolução deste mercado também ajudaram a definir melhor os papéis e fundamentos envolvidos. Data Science tornou-se um conceito definitivamente genérico e suas aplicações (AI e Advanced Analytics, por exemplo) e principais ferramentas (Machine Learning, Deep Learning, Engenharia de Dados, etc.) tomaram corpo dentro das empresas e cursos/conteúdo de capacitação. Hoje vemos cursos, vagas e cargos muito mais definidos e o mito dos Cientistas de Dados unicórnios (ou “carregadores de piano”, na minha visão) sendo desconstruído. Além disso, surgiram equipes e empresas com foco em desenvolver tecnologia específica para determinados domínios de dados, enquanto outras se especializaram na integração de stacks de negócios já existentes com tais tecnologias específicas.

Neste mercado “atualizado”, eu vejo um divisor de águas que separa as iniciativas que tem um retorno positivo de seus investimentos das que falham neste sentido: a maturidade em determinar qual o objetivo específico da iniciativa, para os íntimos: metas bem definidas! Como há um amplo universo de possibilidades de exploração e geração de valor, direções bem definidas ajudam a convergir esforços e mentalidade para um objetivo comum e bem estabelecido. Uma iniciativa deve ser construída a partir de um propósito, e não a partir das atividades.

Vou me explicar melhor. Imagine que um Data team — com seus cientistas, engenheiros, estrategistas, etc. — seja uma equipe de arqueologia. De maneira muito macro, as atividades principais de um time de arqueologia são escavar o solo, procurar “objetos” e fragmentos, identifica-los, categoriza-los e reconstituir um objetos. Se um time de arqueologia é montado sem nenhum objetivo bem estabelecido, eles terão que estar preparados para:

Ter técnicas e ferramentas para escavar qualquer tipo de solo (arenoso, rochoso, argiloso, etc.);
Procurar por todo e qualquer objeto e fragmento, de fósseis a garrafas de vidro;
Identificar, categorizar e reconstruir fragmentos de qualquer coisa, exigindo que sejam conhecidas estruturas desde animais em extinção, vasos Astecas e simples rochas;

Dessa forma, será extremamente difícil encontrar profissionais que tenham tamanha amplitude de conhecimento, investir em anos de capacitação que deem tamanho conhecimento para a equipe e adquirir um grande número de ferramentas que viabilize tudo isso. Além disso, há o risco de cada profissional “andar” em uma direção diferente, fazendo com que a equipe e, consequentemente, a iniciativa não cheguem a lugar algum.

Exatamente a mesma situação dos arqueólogos acontece com uma iniciativa data-driven. Se um objetivo não é estabelecido, fica extremamente difícil encontrar profissionais capacitados, manter um time engajado ter um projeto de sucesso e obter retorno de seus investimentos. Devemos também sempre ter em mente que o termo Data Science contempla a abordagem científica de um problema, e a aplicação das metodologias científicas é que levarão a respostas com menor de teor de bias e maior grau de determinismo possível.

Resumindo a ópera em uma sugestão: defina muito bem o propósito e os objetivos detalhados de sua iniciativa de Data Science antes de dar os primeiros passos concretos (contratação de time, alocação de budget, etc.). Isso vai lhe economizar tempo e dinheiro e aumentar a chance de sucesso de sua iniciativa.

Por que precisamos de planejamento?

2015-10-13T00:00:00+00:00

Quem tem vivência no mundo corporativo já passou por vários eventos (reuniões, treinamentos, feiras, fóruns, etc) relacionados a planejamento. Planejamentos podem ser massantes, incompletos, inúteis, entre outros atributos negativos, porém há um consenso de que é necessário. E por que?

Existem dois pontos de vista sobre a importância de um planejamento (de preferência bem feito): o corporativo e o individual. O corporativo é extensamente discutido pelas diversas metodologias e consultorias que exercitam tal processo junto às empresas. Eu gostaria de discorrer um pouco sobre o impacto de um planejamento no cotidiano de um indivíduo.

Ao contrário do que muitos pensam, um plano de ação não serve para que você avalie se está fazendo a coisa certa, ou quão distante está de alcançar uma meta / objetivo. O papel principal do planejamento é dar segurança a uma pessoa, seja no momento de executar uma tarefa ou de tomar uma decisão. Mas a palavra importante é segurança!

Imagine o cenário onde você fará uma longa viagem de férias, de carro, com sua família, incluindo crianças. Se você é uma pessoa precavida, você pensará na rota a ser realizada, rotas alternativas, pontos de paradas, Waze para lhe alertar sobre o trânsito e perspectiva de chegada, água, comida, revisão do carro, se o destino está dentro do alcance do seu seguro, etc. Ou seja, você tem em mãos um panorama da situação, sabe onde quer chegar e tem um plano detalhado de como deve executar sua viagem, plano de contingência e suporte disponível. Resumindo, você tem um bom plano de viagem.

Se sua viagem seguir exatamente como o planejado, você não verá muito valor no planejamento proriamente dito. Como tudo correu bem, o seu plano foi apenas um script para ser executado e sua viagem ficou mais mecânica pois não foi necessário tomar decisões ou fazer atividades extras durante o percurso. Apenas seguir o script. Entretanto, se algo der errado, como uma criança com muita vontade de ir ao banheiro, pane no carro, etc, o seu planejamento de viagem bem feito lhe dará alternativas para solucionar o problema de maneira rápida / previsível, reduzindo o estresse, preocupações e efeitos colaterais.

Analisando de maneira mais analítica, o planejamento lhe deu segurança para que você pudesse executar as atividades necessárias com maior foco e de maneira mais automática, sem precisar pensar quais são os próximos passos ou se aquilo realmente deveria ser feito. Isso aumenta a qualidade do resultado das atividades e reduz o tempo de execução das mesmas, aumentando a produtividade. Além disso, nos casos de exceção / falha, um plano de contingência e canais de suporte disponíveis lhe dão ferramentas para contornar a situação de maneira mais ágil, reduzir os riscos de falha do objetivo da empreitada e propagar os efeitos colaterais de maneira mais ordenada a todos os envolvidos no resultado desejado, fornecendo perspectivas e prazos de maneira mais assertiva.

Sendo assim, alguns pontos que você deve observar ao participar ou receber um planejamento:

Você tem visibiliadade de tudo o que deve fazer para alcançar o objetivo?
Tem visibilidade de quais são os pontos críticos com maior risco?
Você tem plano de contingência ou caminhos alternativos para escolher em alguns pontos chaves que podem apresentar problema?

Caso tenha respondido não para algum dos pontos acima, lhe recomendo revisar o seu plano e esclarecê-lo, para que o planejamento torne-se efetivo e lhe dê a segurança necessária para que você execute-o com sucesso e alcance seu objetivo.

wespatrocinio

Você já parou para pensar se é um facilitador ou um solucionador de problemas?

Highlights

Visão geral

Facilitador VS Solucionador de problemas

O facilitador

O solucionador de problemas

O que refleti bastante para analisar o dilema

Valores e crenças

Pontos fortes

Satisfação e perspectivas futuras

Conclusões

Conflito de cultura em uma linha de _report_

Highlights

Visão geral

O gestor mid-level como um tradutor cultural

Falta de transparência

Resolver o problema sozinho

Ser apenas um repetidor

Algumas conclusões

AutoML é útil, mas não vai fazer mágica em cima de seus problemas

Highlights

O artigo em si

O que será considerado como um modelo neste artigo?

Qual a minha compreensão sobre AutoML neste momento?

Um breve exemplo: algoritmos vanilla VS auto-sklearn

Vanilla Decision Tree

Vanilla Random Forests

auto-sklearn

config.yml sem ensemble

config.yml com ensemble

config.yml otimizando apenas o Random Forest

Algumas conclusões e próximos passos

Do fundamento à aplicação: Árvores Métricas

Alguns fundamentos importantes

Conjuntos e Espaços Métricos

Mas o que significa exatamente a tal métrica?

Distância de edição

Árvores de Burkhard-Keller (BK)

Como isso se tornaria em um corretor ortográfico?

Referências

Aumente a visibilidade de AI adotando seu vocabulário no cotidiano

Reflexão sobre linguagem, instrumentação e interpretação de conceitos

Linguagem como instrumento

Projeção para o mundo corporativo

O que devemos fazer ao saber disso?

Referências

Não incentive o _Night Hero_ em seu time

Uma breve análise sobre esforço VS eficácia

O reconhecimento fomenta o comportamento, seja ele saudável ou nocivo

O que eu penso que devo fazer neste tipo de situação?

Data Science é metodologia, e não tecnologia

_Statistical Learning Theory_ — você deveria usar mais do que imagina

A distribuição de probabilidade de seu alvo deve ser estática

As amostras usadas para aprendizado devem representar todo o seu espaço amostral

As amostras devem ser independentes entre si

Seu alvo pode ter ruído

Precisamos falar mais sobre metas em Data Science

Por que precisamos de planejamento?

Um breve exemplo: algoritmos vanilla VS `auto-sklearn`

`auto-sklearn`

`config.yml` sem ensemble

`config.yml` com ensemble

`config.yml` otimizando apenas o Random Forest