A arquitetura limpa (Clean Architecture) é uma abordagem que visa a separação de preocupações em sistemas de software, permitindo maior flexibilidade, testabilidade e manutenção. A arquitetura é composta por camadas, incluindo a camada de apresentação, camada de domínio e camada de dados. A regra de dependência exige que as dependências do código-fonte só possam apontar para dentro, o que significa que nada em um círculo interno pode saber nada sobre algo em um círculo externo.
Neste artigo, apresentamos uma proposta de estruturação do Clean Architecture visando a melhorar as interações entre Cientistas de Dados e Software Engineer. A proposta feita no presente texto está baseada na identificação dos principais pontos de interação entre esses profissionais.
Clean Architecture, divisão por camadas e equipes multidisciplinares
Equipes multidisciplinares e arquitetura de camadas são conceitos que se complementam bem. A criação de equipes multidisciplinares é essencial para o sucesso do desenvolvimento de software, pois permite que diferentes especialistas trabalhem juntos em um projeto. Por outro lado, a arquitetura de camadas é uma abordagem para dividir um sistema em diferentes camadas lógicas, cada uma com uma responsabilidade específica. A combinação desses dois conceitos pode ajudar a criar um software de alta qualidade.
Ao usar uma abordagem de camadas, é possível definir claramente as responsabilidades de cada equipe e garantir que haja uma separação clara de preocupações. Por exemplo, uma equipe de cientistas de dados pode trabalhar em camadas de dados e processamento, enquanto uma equipe de desenvolvedores de software pode trabalhar em camadas de apresentação e infraestrutura. Isso permite que cada equipe se concentre em sua área de especialização e trabalhe de forma mais eficaz.
Benefícios da arquitetura de camadas no desenvolvimento de software
Criar camadas para separar o trabalho do cientista de dados e desenvolvedor de software pode trazer vários benefícios importantes. Aqui estão alguns deles:
Clareza de responsabilidades: ao definir as camadas de software, fica claro qual equipe é responsável por cada camada. Isso ajuda a evitar conflitos e mal-entendidos sobre quem é responsável pelo quê.
Maior produtividade: ao separar as camadas, cada equipe pode se concentrar em sua área de especialização e trabalhar de forma mais produtiva. Isso pode levar a uma entrega mais rápida e eficiente do software.
Maior qualidade do software: separar as camadas também permite que cada equipe se concentre em seu trabalho específico. Isso pode levar a um software de melhor qualidade, pois cada equipe pode dedicar mais tempo e recursos às suas tarefas.
Melhor colaboração: ao separar o trabalho em camadas, as equipes podem colaborar de forma mais eficaz. Cada equipe pode se concentrar em sua área de especialização e trabalhar em estreita colaboração com a outra equipe. Isso pode levar a uma melhor comunicação e um melhor entendimento dos requisitos do projeto.
Facilidade de manutenção: separar as camadas também torna mais fácil manter o software a longo prazo. Cada equipe pode se concentrar em manter sua camada específica e garantir que ela esteja funcionando corretamente. Isso pode levar a uma manutenção mais fácil e eficiente do software.
Clean Architecture (Arquitetura Limpa)
Nos últimos anos, vimos toda uma gama de ideias sobre a arquitetura de sistemas, as quais incluem:
Hexagonal Architecture
Onion Architecture
Screaming Architecture
DCI
BCE
Embora todas essas arquiteturas variem um pouco em seus detalhes, elas são muito semelhantes. Todas elas têm o mesmo objetivo, que é a separação de preocupações. Todas elas conseguem essa separação dividindo o software em camadas. Cada um tem pelo menos uma camada para regras de negócios e outra para interfaces. Baseado nessas informações e com o objetivo de integrar os pontos fundamentais dessas arquiteturas, Robert C. Martin (Uncle Bob) propõe a arquitetura representada na seguinte figura 1.
Fig. 1: The Clean Architecture layers (as camadas da arquitetura limpa)
A Camada de Apresentação contém UI (Atividades e Fragmentos), que são coordenados por Apresentadores/ViewModels que executam um ou vários casos de uso. A Camada de Apresentação depende da Camada de Domínio.
A Camada de Domínio é a parte mais interna da “cebola” (sem dependências com outras camadas) e contém entidades, casos de uso e interfaces de repositório. Os casos de uso combinam dados de 1 ou várias interfaces de repositório.
A Camada de Dados contém implementações de repositório e 1 ou várias fontes de dados. Os repositórios são responsáveis por coordenar os dados das diferentes fontes de dados. A Camada de Dados depende da Camada de Domínio.
Os círculos concêntricos representam diferentes áreas de software. Em geral, quanto mais você avança, mais alto o software se torna.
A regra primordial que faz essa arquitetura funcionar é a regra de dependência. Essa regra diz que as dependências do código-fonte só podem apontar para dentro. Nada em um círculo interno pode saber absolutamente nada sobre algo em um círculo externo. Em particular, o nome de algo declarado em um círculo externo não deve ser mencionado pelo código no círculo interno. Isso inclui, funções, classes, variáveis ou qualquer outra entidade de software nomeada.
Da mesma forma, os formatos de dados usados em um círculo externo não devem ser usados por um círculo interno, especialmente se esses formatos forem gerados por uma estrutura em um círculo externo. Não queremos que nada em um círculo externo afete os círculos internos.
Clean Architecture é sobre acoplamento. Não há prescrição para as camadas que você define ou como você define o acoplamento. Você não precisa definir camadas por projetos. É sobre a direção das dependências entre os tipos. O acoplamento aferente e eferente é o que define a estabilidade de cada camada. Motivo pelo qual pessoas envolvidas em projetos onde a Clean Architecture é aplicada devem ter uma boa ideia dos princípios que se aplicam nessa arquitetura.
A importância da ciência de dados
A principal responsabilidade de cientistas de dados é trabalhar com dados para obter insights, realizar análises e criar modelos. No entanto, a qualidade do código é importante para garantir que os projetos sejam escaláveis, fáceis de manter e reutilizáveis, e que possam ser desenvolvidos com eficiência e eficácia.
Existem muitas habilidades necessárias para realizar o trabalho desses especialistas. Na Figura 2 apresenta-se um conjunto de habilidades e processos que devem ser seguidos para o trabalho com dados. Esses processos exigem um conjunto de conhecimentos muito profundos em estatísticas, matemática, tratamento de dados, visualização de dados para comunicar os resultados da análise de dados de maneira clara e eficaz, dentre outras habilidades.
Como a Ciência de Dados é um campo em constante evolução, é importante que os profissionais que desempenham esse trabalho estejam continuamente aprendendo e se atualizando em novas técnicas e tecnologias. Isso pode incluir a participação em cursos e treinamentos, a leitura de artigos e livros sobre Ciência de Dados e a participação em comunidades da área.
A qualidade e incerteza dos dados podem ter um impacto significativo no tempo que os cientistas de dados devem investir em cada fase do processo de análise de dados. A coleta e limpeza de dados podem ser particularmente demoradas, já que os dados podem estar em formatos diferentes e podem conter erros, valores ausentes ou dados duplicados. A análise de dados também pode ser afetada pela qualidade dos dados, pois dados de baixa qualidade podem levar a insights imprecisos ou equivocados.
Como resultado, cientistas de dados podem precisar revisitar essas fases do processo várias vezes para garantir que os dados estejam limpos e prontos para a análise. Isso pode ser especialmente desafiador em projetos de grande escala, onde há uma grande quantidade de dados para serem analisados.
No entanto, é importante lembrar que o investimento de tempo nas fases iniciais do processo de análise de dados pode economizar tempo e esforço no longo prazo, garantindo que os dados sejam limpos e precisos antes da análise. Além disso, a iteração contínua pode levar a melhorias significativas na análise de dados e na qualidade dos resultados.
Embora a programação seja uma habilidade importante para um cientista de dados, não é necessário que sejam especialistas em programação. Muitas vezes, cientistas de dados trabalham em colaboração com engenheiros de software ou desenvolvedores para garantir que o código seja escrito de maneira eficiente e eficaz. Isso pode envolver a revisão do código de outros desenvolvedores e garantir que ele siga as melhores práticas de programação e padrões de código.
Além disso, muitas organizações têm equipes dedicadas de engenharia de software que garantem a qualidade do código e a conformidade com as melhores práticas de programação. Nesses casos, os cientistas de dados podem se concentrar em suas principais responsabilidades de análise de dados e modelagem, enquanto os engenheiros de software se concentram na qualidade do código.
Fig. 2: A ciência de dados e processos que a compõem
Uma boa arquitetura de software irá promover a interdependência entre cientistas de dados e engenheiros de software. Motivo pelo qual a seguir abordaremos uma proposta de uso do Clean Architecture desde a óptica de equipes multidisciplinares de cientistas de dados e engenheiros de software.
Clean Architecture na Ciência de Dados
Ao aplicar a Clean Architecture na Ciência de Dados, é importante identificar as diferentes camadas do sistema e suas responsabilidades, incluindo a camada de dados, a camada de infraestrutura, a camada de negócios e a camada de apresentação. Cada camada deve ser projetada para ser independente das outras camadas, permitindo que o sistema seja facilmente adaptável a mudanças nos requisitos de negócios ou tecnologias.
Contextos que envolvem processamento de dados tem como foco principal a lógica de negócios (business logic) encarregada dos processos de transformação ou cálculo dos dados, além do encaminhamento destes para pessoas ou software (workflow).
As regras de negócios são expressões formais da política de negócios. Qualquer coisa que seja um processo ou procedimento é uma lógica de negócios e qualquer coisa que não seja um processo nem um procedimento é uma regra de negócios. Daí que processos tais como ETL, análise e inferência de dados sejam pertinentes à lógica de negócios e fazem parte dos casos de uso na camada de domínio.
Uma possível subdivisão a realizar a fim de independizar o trabalho de cientistas de dados e engenheiros de software seria na camada de domínio, com um modelo segundo os seguintes tipos de Casos de Uso:
Processamento dos dados provenientes das fontes de dados: a camada contempla a orquestração do fluxo de dados visando a persistência, consistência e validação dos dados.
Desenvolvimento e manutenção de modelos: processo de usar o conhecimento do domínio para selecionar e transformar as variáveis mais relevantes dos dados brutos ao criar um modelo preditivo usando aprendizado de máquina ou modelagem estatística.
Processos que envolvem diretamente o usuário final
Por outro lado, a camada de dados passará a estar conformada pelos Repository, e tarefas (tasks) que conformam o fluxo de dados.
Note-se que essa separação implica que ferramentas ETL ou ELT sejam conformadas por duas camadas. Uma delas relativa à lógica de negócios contemplando a modelação do workflow de dados e a outra com a lógica de acesso e compartilhamento de dados, sendo que na segunda camada existe espaço para aplicação de princípios de software.
No nível de armazenamento da camada de dados é possível fazer uma subdivisão dos dados segundo esquemas ou bancos de dados diferentes, refletindo a separação em camadas segundo Caso de Uso. No entanto, é importante ter em mente que a criação de esquemas ou bancos de dados separados pode aumentar a complexidade da aplicação e exigir mais recursos de gerenciamento de dados. Portanto, é importante manter bem definido e documentado o objetivo de cada uma das camadas que são criadas.
Conclusão – Clean Architecture aplicada na Ciência de Dados
Na ciência de dados, a arquitetura limpa pode ser aplicada para criar uma arquitetura de aplicação orientada a aplicações de ciência de dados. A camada de domínio pode ser subdividida em casos de uso, incluindo processamento de dados, desenvolvimento e manutenção de modelos e processos que envolvem diretamente o usuário final. A camada de dados pode ser conformada por Repository e tarefas (tasks) que conformam o fluxo de dados. É possível fazer uma subdivisão dos dados de acordo com esquemas ou bancos de dados diferentes, refletindo a separação em camadas de caso de uso.
Desenvolvedor Python na Aquarela Advanced Analytics. Mestrado em Informatica pela PUC-Rio (CAPES 7). Graduação em Ciência da Computação pela Universidade da Havana. Na minha carreira tenho participado de vários projetos envolvendo desenvolvimento de software, processamento de dados e Ciência de dados.
A implementação de inteligência artificial (IA) tem ganhado muita visibilidade nos últimos tempos, incluindo no desenvolvimento de produtos, onde sua utilização tem se tornado cada vez mais comum em empresas de diferentes setores.
No entanto, a implementação bem-sucedida de IA requer uma colaboração efetiva entre Product Managers e Cientistas de Dados. Neste artigo, exploraremos a importância dessa colaboração para alcançar resultados eficazes e eficientes na criação de soluções de produtos com IA.
Definição do papel de Product Managers e Cientistas de Dados na implementação de IA
O papel dos product managers é definido pela responsabilidade na liderança da gestão de produtos, desde a concepção, passando pelo controle do desenvolvimento, até a comercialização do produto e o acompanhamento da saúde do software. Nessa posição, é fundamental entender as necessidades dos clientes e do mercado, definir as especificações do produto e garantir que o produto final atenda às expectativas dos clientes.
Por outro lado, os cientistas de dados têm a expertise em análise de dados, modelagem e técnicas de IA. Possuem também a responsabilidade de coletar e analisar dados para ajudar a tomar decisões informadas sobre o desenvolvimento do produto, trazendo assim uma cultura de tomada de decisão voltada aos dados (data-driven).
Compreensão das necessidades do cliente, definição de métricas e objetivos de desenvolvimento
No começo de cada desenvolvimento, é importante a clareza e compreensão das necessidades do cliente, dessa forma há grandes chances de que o desenvolvimento de produtos seja bem-sucedido.
Com o trabalho conjunto entre product managers e cientistas de dados desde a etapa de Discovery, é possível identificar as principais métricas e objetivos de sucesso para o produto, o que pode ajudar a orientar a análise dos dados e a tomada de decisões. É importante que ambos os profissionais trabalhem em conjunto para garantir que as necessidades do cliente sejam atendidas de maneira efetiva.
Há uma metodologia chamadaData-Driven, que utiliza dados para orientar as decisões. Ela pode ser uma abordagem eficaz para ajudar product managers e cientistas de dados a identificar as necessidades do cliente e definir as métricas e objetivos de sucesso.
O Data-Driven envolve coletar, analisar e interpretar dados para entender melhor as necessidades do cliente. Os cientistas de dados utilizam diferentes técnicas, como mineração de dados e aprendizado de máquina, para identificar padrões nos dados e entender as preferências e comportamentos dos clientes. Os product managers, por sua vez, podem usar essas informações para definir métricas e objetivos de sucesso para o produto.
Análise de dados e desenvolvimento de modelos de IA pelos cientistas de dados
Além de possibilitar ao produto uma orientação por dados (data-driven), os cientistas de dados também são responsáveis pela análise de dados e pelo desenvolvimento de modelos de inteligência artificial.
A análise de dados é um processo importante para desenvolver modelos de IA precisos e relevantes. Para isso, os cientistas de dados usam algoritmos e modelos para treinar os dados e ajustar os parâmetros para garantir que o modelo seja eficaz e preciso.
Uma vez que o modelo seja treinado e ajustado, ele pode ser usado para fazer previsões, identificação de padrões e tomada de decisões informadas. Logo, é possível para os cientistas de dados trabalharem em colaboração com os product managers para garantir que os modelos de IA desenvolvidos atendam às necessidades do produto e dos clientes.
Depois que um modelo de IA é desenvolvido e implementado, é importante monitorar seu desempenho e avaliar continuamente sua eficácia. Se ocorrerem mudanças nas condições de mercado ou nas preferências dos clientes, os product managers e cientistas de dados devem estar prontos para ajustar o modelo de IA de acordo. A avaliação contínua envolve a análise e interpretação dos resultados do modelo de IA para analisar se ele está atingindo os objetivos do produto e do cliente.
Assim, product managers e cientistas de dados devem trabalhar em conjunto para garantir que o modelo de IA seja monitorado e avaliado continuamente. Os product managers podem fornecer informações sobre as mudanças no mercado e as necessidades do cliente, enquanto os cientistas de dados podem contribuir com informações sobre a eficácia do modelo de IA e ajustá-lo de acordo. Com uma abordagem de monitoramento e avaliação contínua, product managers e cientistas de dados podem garantir que a implementação de IA atenda, de forma relevante, o produto ao longo do tempo.
Conclusão – Colaboração entre Cientistas de Dados e Product Managers na criação de produtos
A colaboração entre product managers e cientistas de dados é fundamental para a implementação bem-sucedida de IA no desenvolvimento e gestão de produtos. Ao trabalharem juntos, eles podem criar um ambiente data-driven, colocando os dados no centro da tomada de decisões, e apoiar nos desafios associados à implementação de IA. Além de que a colaboração contínua também é necessária para o monitoramento e avaliação do desempenho dos modelos de IA criados.
A implementação bem-sucedida de IA na gestão de produtos pode trazer inúmeros benefícios, como melhorias na eficiência operacional, aumento da satisfação do cliente e vantagem competitiva. No entanto, a colaboração entre product managers e cientistas de dados é crucial para garantir que esses benefícios sejam alcançados de forma eficaz e sustentável.
Profissional da área de produtos com background técnico e experiência em softwares da área siderúrgica, energia e serviços de crédito. Tenho como especialidade o desenvolvimento de Discovery, criação e acompanhamento de Roadmap, assim como o Product Backlog e a Priorização do Backlog. Além disso, criação de indicadores do sistema (DAU, MAU, acesso, etc.), assim como a criação de user stories, análise de requisitos, facilitação de reuniões e contato direto com stakeholders, time de desenvolvimento e UX.
A área de análise de dados (o que é data analytics?) é ampla o suficiente para se encontrar uma posição de trabalho que seja capaz de gerar satisfação tanto para quem contrata e é contratado. Porém existem algumas características pessoais que valem uma atenção especial. Quais são?
Neste artigo, apresento algumas dicas para profissionais e estudantes ou para quem está buscando ter uma visão do encaixe do seu perfil dentro da área de análise de dados. Não encaixar em um perfil não significa necessariamente um problema, e sim uma oportunidade para continuar buscando aquele local ou tipo de trabalho que te realiza profissionalmente.
Como chegamos até aqui?
Nos últimos 10 ou 15 anos houve uma grande transformação nas empresas na direção à indústria 4.0 (o que é a indústria 4.0). Foi nesse período que muitas organizações se informatizaram e entraram na internet. É este cenário de transformação digital que está gerando cada vez mais dados para análise, descobertas de padrões e automatização de rotinas.
Então, o(a) profissional encarregado(a) de planejar e executar essas atividades pode ser chamado de analista de dados, cientista de dados e até engenheiro ou arquiteto de dados, dependendo do cenário de negócio.
Existem muitas definições para cada um desses conceitos. Contudo, há algumas características gerais que valem uma atenção especial para quem está decidindo investir na carreira nessa área.
Aprendizado 80 Execução 20 na análise de dados
A área de dados é uma área voltada para processos contínuos de solução de problemas (problem solving). Como no Princípio de Pareto, a proporção de tempo dedicado ao estudo e treinamento pode ser muito superior à execução propriamente dita. É uma quebra de paradigma importante sobre como a gente deve olhar para esse tipo de trabalho. Por isso, se você gosta de iniciar atividades que tenham um fim previamente conhecido e com tudo planejado ao invés das incertezas, a área de análise de dados pode não ser a melhor escolha.
Criatividade Gerenciada (gestão do conhecimento)
Análise de dados é um trabalho fundamentalmente criativo, porém ao mesmo tempo demanda autodisciplina.
Os trabalhos de análise de dados são 99% digitais, salvo casos raros de visita a instalações e reuniões presenciais. Portanto, quanto mais bem documentados forem suas atividades criativas para solução de um problema analítico, mais valiosa é sua contribuição. A palavra “ciência” do termo “ciência de dados” faz referência aos processos científicos para se chegar ao resultado.
Por outro lado, se você cria muita coisa mas não tem uma gestão eficiente e clara destas criações ou o hábito de documentar os caminhos realizados, fazer apresentações, relatórios e se expressar de uma forma baseada em fatos, provavelmente a análise de analytics pode não ser a melhor aposta.
Curiosidade, Autodidatismo e Motivação
No mundo ideal, o trabalho demandaria um curso específico para cada desafio, mas os desafios analíticos raramente são iguais na vida real, o que torna impossível a publicação de cursos adequados para cada problema em tempo hábil.
Para tratar de problemas analíticos, é necessário ser uma pessoa autodidata, curiosa por tecnologia e pelos comportamentos das coisas que estão sob análise, pois sem esse desejo pelo desconhecido, não faz sentido a investigação dos dados.
Durante as fases de análise e dependendo da maturidade de analítica dos clientes ou do projeto, é absolutamente fundamental ter uma atitude positiva frente aos erros e falhas que normalmente acontecem. Essa postura contribui muito com o time para se chegar às melhores alternativas para cada problema.
Trabalhar em times ágeis
É preciso gostar de trabalhar com diversas disciplinas e pessoas com diversas ideias, jeitos e até hábitos. A multidisciplinaridade que ocorre em projetos de dados é uma situação onde cada um pode agregar seus conhecimentos e habilidades ao todo. Por isso, busca-se um constante vórtex de conhecimento, onde tudo aquilo que é diferente trabalha junto, rumo a um objetivo único.
Então, se o seu perfil é mais voltado para trabalhos individuais e/ou que não demandam grande quantidade de comunicação e empatia, provavelmente analytics não é uma área recomendada.
Inglês como língua franca
Por último, mas não menos importante, está o conhecimento em inglês em todos os seus níveis. Mesmo que você não tenha planos de sair do país, a área de computação, sistemas de informação e Analytics são todas baseadas nesse idioma. Frequentemente, as primeiras publicações relevantes sobre cada tema são em inglês, além de grande parte das documentações. Por isso, estar apto a absorver conhecimentos novos é bastante importante.
Se você não estiver disposto a enfrentar o ciclo de aprendizado rigoroso do idioma, esse será um ponto fraco na sua carreira profissional e isso estará sempre em evidência. Uma vez resolvido a questão do inglês, ele se tornará seu maior amigo e abrirá muitas portas a médio e longo prazo.
Tenho o perfil para trabalhar com Análise de dados? – Conclusões
Bom, pessoal, com base em minha experiência de mais de 10 anos na ciência de dados, busquei trazer alguns pontos que considero importantes para quem está descobrindo área e tem interesse em encontrar seu lugar no mercado de trabalho.
A área de dados mescla os verbos estudar e trabalhar, atividades que até então, nas outras fases da industrialização, eram facilmente separáveis. É de fato um mundo novo, com novas formas de trabalhar e que exige uma atenção especial ao perfil mais adequado para essa tarefa. Essa não é nem de perto uma atividade fácil tanto para quem contrata como para quem é contratado, por isso ficam aí algumas reflexões e o desejo de que tenham sucesso em suas escolhas, ou melhor “your choices”. Então, “Good Luck, folks”.
Fundador e Diretor Comercial da Aquarela, Mestre em Business Information Technology com especialização em logística – Universiteit Twente – Holanda. Escritor e palestrante na área de Ciência e Governança de Dados para indústria e serviços 4.0.
Os outliers são dados que se diferenciam drasticamente de todos os outros. Em outras palavras, um outlier é um valor que foge da normalidade e que pode (e provavelmente irá) causar anomalias nos resultados obtidos por meio de algoritmos e sistemas de análise.
Entender os outliers é fundamental em uma análise de dados por pelo menos dois aspectos:
os outliers podem viesar negativamente todo o resultado de uma análise;
o comportamento dos outliers pode ser justamente o que está sendo procurado.
Os outliers presentes em datasets (o que são datasets) possuem diversos outros nomes, como:
A seguir, elencamos algumas situações comuns em que os outliers surgem na análise de dados e apontamos sugestões de como lidar com eles em cada caso.
Como identificar quais são os dados outliers?
Existem diversas formas de encontrar outliers, aqui citamos algumas delas.
Encontrar os outliers utilizando tabelas
A forma mais simples de encontrar dados outliers é olhar diretamente para a tabela ou planilha de dados – o dataset como chamam os cientistas de dados.
O caso da tabela a seguir exemplifica claramente um erro de digitação, ou seja, de input dos dados. Logo, o campo da idade do indivíduo “Antônio Silveira” certamente não representa a idade de 470 anos.
Olhando para a tabela é possível identificar o outlier, mas fica difícil afirmar qual seria a idade correta. Existem várias possibilidades que podem se referir a idade certa, como: 47, 70 ou ainda 40 anos.
Em uma pequena amostra, a tarefa de encontrar outliers com o uso de tabelas pode ser fácil. Porém, quando a quantidade de observações (linhas) passa para a casa dos milhares ou milhões fica impossível de encontrar quais são os dados que destoam do geral.
Portanto, a tarefa de identificar anomalias pode se tornar difícil, principalmente quando mais variáveis (mais as colunas) são envolvidas. Para isso existem outros métodos.
Encontrar os outliers utilizando gráficos
Uma das melhores formas de identificar dados outliers é utilizando gráficos. Pois, ao plotar um gráfico o analista consegue claramente perceber que existe algo diferente.
Veja a seguir alguns cases que exemplificam a visualização de outliers com gráficos.
Case: outliers no sistema de saúde brasileiro
Em um estudo já publicado em nosso blog analisamos os fatores que levam as pessoas a não comparecem em consultas agendadas no sistema público de saúde da cidade de Vitória/ES.
No dataset, diversos padrões foram encontrados, como por exemplo: crianças praticamente não faltam às consultas; e mulheres comparecem muito mais às consultas do que os homens.
Porém, um caso curioso foi o de uma senhora “outlier”, que com 79 anos agendou uma consulta com 365 dias de antecedência e de fato compareceu à consulta.
Este é um caso, por exemplo, de um dado outlier que merece ser estudado, pois o comportamento dessa senhora pode trazer informações relevantes de medidas que podem ser adotadas para aumentar a taxa de assiduidade nos agendamentos.
Veja o caso no gráfico a seguir.
Agendamentos médicos na cidade de Vitória-ES
Case: outliers no mercado financeiro brasileiro
No dia 17 de maio de 2017 as ações da Petrobrás caíram 15,8% e o índice da bolsa (IBOVESPA) teve uma queda de 8,8% em um único dia. Neste caso, a maioria das ações da bolsa brasileira viram seu preço despencar neste dia.
Essa forte variação negativa teve como principal motivação a delação de Joesley Batista, um dos eventos políticos mais impactantes que aconteceram no primeiro semestre de 2017.
Esse caso representa um outlier para o analista que, por exemplo, deseja saber qual foi a média de retornos diários das ações da Petrobrás nos últimos 180 dias. Certamente o dia da delação de Joesley afetou fortemente a média para baixo.
Ao analisar o gráfico a seguir, mesmo diante de diversas observações, fica fácil identificar o ponto que destoa dos demais.
O dado do exemplo acima pode ser chamado de outlier, mas se levado ao pé da letra, não pode necessariamente ser considerado um “ponto fora da curva”. Portanto, a “curva” no gráfico acima, apesar de contra-intuitivo, é representada pela linha reta que corta os pontos.
Ainda pelo gráfico acima é possível perceber que apesar de diferente dos demais, o dado não está exatamente fora da curva. Neste sentido, um modelo preditivo poderia facilmente inferir, com alta precisão, que uma queda de cerca de 9% no índice da Bolsa representaria uma queda de cerca de 15% no preço das ações da Petrobrás.
Em outro caso, ainda com dados do mercado financeiro de ações brasileiro, a ação da empresa Magazine Luiza teve valorização de 30,8% em um dia em que o índice da Bolsa subiu apenas 0,7%.
Em suma, esse dado, além de ser um ponto atípico, distante dos demais, representa também um ponto fora da curva. Veja o gráfico:
Este é um caso de outlier que pode prejudicar não apenas cálculos de estatística descritiva, como média e mediana, por exemplo, mas afeta também a calibração de modelos preditivos.
Encontrar os outliers utilizando métodos estatísticos
Uma maneira mais complexa, porém bastante precisa, de encontrar outliers em uma análise de dados é encontrar a distribuição estatística que mais se aproxima à distribuição dos dados e utilizar métodos estatísticos para detectar os pontos discrepantes.
O exemplo a seguir representa o histograma da conhecida métrica dos motoristas “quilômetros por litro”.
O dataset utilizado para este exemplo é um conjunto de dados público bastante explorado em testes estatísticos por cientistas de dados e estudantes.
O dataset é composto por dados extraídos da “Motor Trend US magazine” de 1974 e compreende diversos aspectos acerca da performance de 32 modelos de automóveis da época. Mais detalhes neste link.
O histograma é uma das principais e mais simples ferramentas gráficas para o analista de dados utilizar na compreensão do comportamento dos dados que está analisando.
No histograma abaixo a linha azul representa como seria a distribuição normal (gaussiana) baseada na média, desvio-padrão e tamanho da amostra, e está contraposta com o histograma em barras.
As linhas verticais vermelhas representam as unidades de desvio-padrão. Percebe-se que os carros com performance “outlier” para a época conseguiam fazer uma média maior que 14 quilômetros por litro, o que corresponde à mais de 2 desvios padrões em relação à média.
Pela distribuição normal, os dados que estão a menos de duas vezes do desvio-padrão correspondem a 95% de todos os dados; os outliers representam, nesta análise 5%.
Outliers em processo de agrupamentos (clustering)
Neste vídeo em inglês (com legendas) apresentamos a identificação de outliers de modo visual a lúdica com bandeira a partir do processo de agrupamentos (clustering). Mais informações sobre clustering neste artigo específico sobre o tema.
Conclusões: o que fazer com os outliers?
Vimos ao longo deste artigo que é imprescindível dar atenção aos outliers, pois eles podem viesar toda a análise de dados. Porém, além de identificar, o que é preciso fazer para tratar os pontos fora da curva?
Existem diversas saídas, algumas delas são:
excluir as observações discrepantes da amostra de dados: quando o dado discrepante é fruto de um erro de input dos dados, então ele precisa ser removido da amostra;
realizar uma análise separada apenas com os outliers: esta abordagem é útil quando se quer investigar casos extremos, como alunos que só tiram notas boas, empresas que apresentam lucro mesmo em tempos de crise, casos de fraudes, entre outros.
utilizar métodos de clusterização para encontrar uma aproximação que corrige e dá um novo valor aos dados outliers: em casos de erros no input dos dados, ao invés de excluir e perder uma linha inteira de registros devido a uma única observação outlier, uma solução é utilizar algoritmos de clusterização que encontram o comportamento das observações mais próximas ao dado outlier e fazem inferência de qual seria o melhor valor aproximado.
Por fim, a principal conclusão sobre os outliers pode ser resumida da seguinte forma:
um dado outlier pode ser o que mais atrapalha sua análise, mas também pode ser exatamente aquilo que você está procurando.
Ainda, estratégias de tratamento de outliers podem ter um impacto direto em negócios reduzindo custos de manutenção de equipamentos industriais com análises preditivas e prescritivas – Ler mais (Vortx Manutenção 4.0).
Fundador e Diretor Comercial da Aquarela, Mestre em Business Information Technology com especialização em logística – Universiteit Twente – Holanda. Escritor e palestrante na área de Ciência e Governança de Dados para indústria e serviços 4.0.
Doutor e Mestre em Finanças pela Universidade Federal de Santa Catarina – Brasil. Pesquisador em finanças / economia comportamental e mercado de capitais. Atualmente Data Scientist aplicando estratégias de aprendizado de máquina em problemas de negócios de grandes organizações no Brasil e no exterior.
