Why you need enforce reproducibility as habit

In the few months that I arrived in Movile, I saw some strange pattern about several “data analysis”. The pattern was: once the analysis is delivered by someone without any background of data science this kind of insight suddenly become a kind of dogma.

In other words, no one will check the information, and in most of the cases there is no code, no commit at github, no .sql file or .R/.py file with the scripts used.

The practical problem is: What if this information was deadly wrong? And worse: How to discover if this information was harmful to the business?

Seeing this, my first mission statement as Data Intelligence Tech Lead at that time was to enforce to every BI Developer, Revenue Assurance Data Analyst, and Data Scientist  that every code must be reproducible no matter what conditions. Every insight must be delivered with some code in github.

Someone could say: “Wow… We have a little dictator here!”

With this simple rule, we are having this not exhaustive list of positive effects:

  • We’re collecting until today a huge dividend about the reproductive science: Any opinion have a code behind, and this code can be tested for anyone with access in github. This avoids the “excel kid” to drive any decision making without one hand on their shoulder, BEFORE the decision making;
  • We unmasked several “BS artists” that exploit the lack of data literacy of our internal clients (e.g. analysts, managers, et cetera) showing unnecessary complexities or delusional estimates without any kind of method behind; and
  • We developed a culture to be very skeptic about our estimates, especially to what we do not know about the data (a.k.a. exogenous factors about the market, brazilian economy, and so on). In another words: We stop to guessing about what we don’t know at that time and MADE IT CLEAR for our internal clients.

To know a little bit more how we operate, this article was the key reference for us to built our culture of compliance and deployment.


No matter what time crunch you are facing, it’s not worth putting a flaky implementation of an analysis into production. As data scientists, we are working to create a culture of data-driven decision-making. If your application breaks without an explanation (likely because you are unable to reproduce the results), people will lose confidence in your application and stop making decisions based on the results of your application. Even if you eventually fix it, that confidence is very, very hard to win back.

Data science teams should require reproducibility in the same way they require unit testing, linting, code versioning, and review. Without consistently producing results as good or better than known results for known data, analyses should never be passed on to deployment. This performance can be measured via techniques similar to integration testing. Further, if possible, models can be run in parallel on current data running through your systems for a side-by-side comparison with current production models.

Don’t get me wrong: Without any kind of compliance about your analysis, your organization will be a house of BS artists and any benefit to extract insights of the data, will be contaminated with BS hidden bias and can lead to several disasters in decision making, as we already experienced.

Why you need enforce reproducibility as habit

Best price to bill approach

From whom are looking an initial approach to know the best time to bill your customers for some subscription services, this paper can be a good start.

In my current company, this is a very challenging problem.

Machine-Learning System For Recurring Subscription Billing

Jack Greenberg, Thomas Price

Abstract: A system and method for recurring billing of periodic subscriptions are disclosed. The system attempts to maximize a metric like long term customer retention while tailoring the subscription billing to the customer, using machine learning. The system is initially trained with a set of training data — a large corpus of records of subscription billings — including successes, billing failures, and customer cancellations. Any available metadata about the users or the type of subscription is also attached and may be used as features for the machine learning model. Such metadata may include, for example, customers’ age, gender, demographics, interests, and online behavioral profile/history, as well as metadata to identify the type of service being billed, such as music subscriptions, delivery subscriptions or other types of subscriptions, or the payment instrument. The system is used to predict the subscription model for a given user with relevant user-related constraints, while optimizing acceptability to that user.

Best price to bill approach

Construindo Jarvis. Por Mark Zuckerberg

Uma das melhores coisas que podem acontecer quando há uma expectativa muito grande em sua área de atuação em tecnologia é quando alguém muito conhecido tem uma mesma opinião de empirismo cético a cerca do estado da arte.

Mark Zuckerberg colocou uma meta em 2016 para construir o seu próprio Jarvis  (pra quem não sabe o Jarvis é o robô assistente que utiliza machine learning para auxiliar o Tony Stark em Iron Man) como uma forma de aprender sobre Inteligência Artificial e ver o estado da arte sobre o que estava sendo feito e usar isso em benefício próprio para realização de tarefas domésticas.

Arquitetura do Jarvis

O que pode ser dito no que diz respeito ao estado da arte em Machine Learning é que fora a parte de interconectividade com devices (que é um campo que pessoalmente eu não conhecia tantas limitações), não há nada de novo no front em termos algorítmicos em relação às restrições já conhecidas na academia.

Versão Beta do Jarvis.

O ponto extremamente positivo aqui, é que aos poucos todo o conhecimento da academia (que ainda está muito na frente da indústria) já está sendo transposto para a vida das pessoas, mesmo que ainda em termos de aplicações simples.

Em outras palavras, a automação de tarefas domésticas é hoje um problema muito mais de engenharia do que de tecnologia em si. E isso é ótimo.

Muito do que se discute em relação à Machine Learning tem muito de hype é verdade; mas se ao mesmo tempo isso amplifica mais ainda o discurso comercial atitudes como essa do Mark desmistifica o que é Machine Learning/Inteligência Artificial e contribuí para eliminar arrefecer o Inverno Nuclear em relação a Machine Learning e Inteligência Artificial causado pelo hype sobre esses dois campos de estudo.

Abaixo algumas partes do relato do Mark Zuckerberg:

Sobre a dificuldade de fazer a ligação do Jarvis com dispositivos não conectados à internet:

(…)Further, most appliances aren’t even connected to the internet yet. It’s possible to control some of these using internet-connected power switches that let you turn the power on and off remotely. But often that isn’t enough. For example, one thing I learned is it’s hard to find a toaster that will let you push the bread down while it’s powered off so you can automatically start toasting when the power goes on. I ended up finding an old toaster from the 1950s and rigging it up with a connected switch. Similarly, I found that connecting a food dispenser for Beast or a grey t-shirt cannon would require hardware modifications to work.
For assistants like Jarvis to be able to control everything in homes for more people, we need more devices to be connected and the industry needs to develop common APIs and standards for the devices to talk to each other.(…)

Sobre a dificuldade semântica que as máquinas tem para lidar com alguns tipos de ambiguidade na comunicação:

(…)Music is a more interesting and complex domain for natural language because there are too many artists, songs and albums for a keyword system to handle. The range of things you can ask it is also much greater. Lights can only be turned up or down, but when you say “play X”, even subtle variations can mean many different things. Consider these requests related to Adele: “play someone like you”, “play someone like adele”, and “play some adele”. Those sound similar, but each is a completely different category of request. The first plays a specific song, the second recommends an artist, and the third creates a playlist of Adele’s best songs. Through a system of positive and negative feedback, an AI can learn these differences.(…)

A respeito da oportunidade de negócios em recomendação:

(…)it also knows whether I’m talking to it or Priscilla is, so it can make recommendations based on what we each listen to. In general, I’ve found we use these more open-ended requests more frequently than more specific asks. No commercial products I know of do this today, and this seems like a big opportunity.(…)

Uma ótima ideia que pode ser adaptada por governos através de suas secretarias de segurança para mapeamento de desaparecidos e criminosos (será um novo Minority Report?)

(…) I built a simple server that continuously watches the cameras and runs a two step process: first, it runs face detection to see if any person has come into view, and second, if it finds a face, then it runs face recognition to identify who the person is. Once it identifies the person, it checks a list to confirm I’m expecting that person, and if I am then it will let them in and tell me they’re here. (…)

Como já discutimos na Movile, o chat é imortal!

(…)This preference for text communication over voice communication fits a pattern we’re seeing with Messenger and WhatsApp overall, where the volume of text messaging around the world is growing much faster than the volume of voice communication. This suggests that future AI products cannot be solely focused on voice and will need a private messaging interface as well.(…)

Construindo Jarvis. Por Mark Zuckerberg

Microserviços em Machine Learning – Parte 1: Uma (nano)introdução

Este post é uma pequena reflexão sobre uma das melhores palestras do evento The Developers Conference (TDC/2016) de São Paulo que foi a do Gilmar Souza sobre modelos de Machine Learning em produção e de algumas notas do livro do Sam Newman (Building Microservices) além de algumas referências auxiliares.

Um dos assuntos mais discutidos nas comunidades de Data Science/Machine Learning é a atual necessidade da transposição dos modelos stand-alone para ambientes de produção; o que é chamado hoje de Core Machine Learning.

Dessa forma vamos abstrair essa questão da transposição ou não e falaremos direto sobre modelos de arquitetura para Core Machine Learning.

Na palestra do Gilmar ele coloca uma série de potenciais implementações de modelos de ML em produção como (a) re-implementação do modelo via linguagem de programação nativa da plataforma; (b) exportação do modelo em PMML para o ambiente de produção e load em uma suíte de ML para devolver o resultado das predições; (c) Projeção; e finalmente (d) Microserviço que pode ser tanto via chamadas HTTP e/ou REST API dentro de serviços nativos e/ou plataformas de Machine Learning as a Service como Google Prediction, Azure Machine Learning ou Amazon Machine Learning.

A principal diferença de abordagem em termos de Core ML é que no item (a) o algoritmo de ML é totalmente embutido no sistema de produção e na abordagem (d) há uma estrutura auxiliar separada para realizar esse tipo de tarefa, que no caso é o Microserviço.

Mas a primeira pergunta que fica é: O que são os microserviços?

De acordo com o Sam Newton os microserviços é uma abordagem para sistemas distribuídos que promove o uso de serviços mais granulares com os seus próprios ciclos de vida.

Da perspectiva do Sam, esses microserviços são modelados ao redor de domínios de negócios para evitar os problemas das tradicionais arquiteturas monolíticas, isto é, arquiteturas que consideram um sistema único com todos os seus módulos em uma única aplicação.

Então, sabe aquele mel gostoso que você consome? Ele é totalmente feito em uma estrutura de microserviços. Foto: My honey supers by Mandie

Buscando uma outra definição, agora do lendário Martin Fowler e do James Lewis, traduzido do blog do Pedro Mendes temos uma ideia de como é o design dessa arquitetura:

[…] (O) microsserviço é uma abordagem [1] para desenvolver uma única aplicação como uma suíte de serviços, cada um rodando em seu próprio processo e se comunicando através de mecanismos leves, geralmente através de uma API HTTP. Estes serviços são construídos através de pequenas responsabilidades e publicados em produção de maneira independente através de processos de deploys automatizados. Existe um gerenciamento centralizado mínimo destes serviços, que podem serem escritos em diferentes linguagens e usarem diferentes tecnologias para armazenamento de dados.[…]

Vamos ver na prática como seria essa diferença em termos de arquitetura de uma estrutura monolítica seja para outra de microserviços na figura abaixo:

Referência: http://www.martinfowler.com/articles/microservices.html

Como podemos ver, cada elemento/funcionalidade da plataforma/sistema na estrutura monolítica é inserida dentro da aplicação como um todo; já nos microserviços esse funcionalidades são replicadas e isoladas ao longo dos servidores e usadas conforme a necessidade.

Em linhas gerais o que é definido nessa arquitetura é que esses sistemas distribuídos atuam de forma autônoma dentro de um determinado espectro de pequenas atividades específicas através de um serviço.

Extendendo um pouco mais esse conceito, vamos usar alguns dos pontos principais das definições do Sam Newton das características dos microserviços que são:

(a) são sistemas pequenos e focados em fazer bem uma única coisa, isto é, há uma coesão dentro do domínio do negócio no qual o serviço está atrelado; e

(b) baixo acoplamento, o que na prática significa que a manutenção nessa abordagem não afeta o sistema como um todo e sim somente um pequena parte;

Quando falamos de sistemas monolíticos distribuídos logo vem a mente o clássico livro do Michael Feathers chamado Working Effectively with Legacy Code (tradução livre: Trabalhando com código legado) que é uma bíblia para quem trabalha com código/arquiteturas não tão bem desenhadas que constantemente tem problemas de bugs, interdependências desnecessárias, complexidades escondidas o que deixa qualquer atividade de incorporação de novas features ou refactoring um verdadeiro pesadelo que se torna realidade.

E se pensarmos que na grande parte das vezes não estamos nem construindo software novo, mas sim colocando 90% do nosso esforço para manutenção de código antigo não soa tão mal assim pensarmos que faz sentido a adoção deste tipo de arquitetura de microserviços.

Uma das principais características no que se refere aos microserviços é que o isolamento do deployment (e por consequência a autonomia que o sistema tem por conta desse isolamento) é que se ao mesmo tempo o sistema/plataforma legada não é afetado por modificações, com os microserviços a manutenção tende a ganhar uma escala muito maior em termos de volume e administração (óbvio que se tratando de tecnologias de Continuous Integration há tecnologias como Chef e o Jenkins que fazem muito bem esse papel, mas prática é uma questão muito mais complexa de sincronização, orquestração e janelas de deployment; ou seja: não existe resposta fácil aqui).

Nem tudo são rosas quando falamos de microserviços. Se considerarmos alguns pontos do próprio Martin Fowler podemos ver que os microserviços ainda tem alguns calcanhares de Aquiles que são:

(a) aumento da complexidade de mecanismos de tolerância à falha (no caso o Netflix tem até uma aplicação para forçar isso de maneira arbitrária para aumentar a resiliência de suas plataformas);

(b) com maior volume de pequenos serviços distribuídos a parte de disponibilidade passa a ser muito mais crítica e difícil de lidar, o que coloca uma pressão altíssima nas questões de monitoramento e alarmística (o que no caso será um aumento violento da quantidade de alertas sobre jobs, fluxos de sincronização e orquestração em casos que se fosse em um sistema monolítico um time de Dev Ops poderia trabalhar com muito mais foco e minimizar o RTO e o RPO).

Na prática, assim como o número de serviços aumenta, os pontos de falha aumentam multiplicam-se na mesma velocidade;

(c) aumento da latência entre aplicações. Na prática funciona assim: uma coisa é um contexto de 200ms de tempo de resposta em uma arquitetura com um baixo grau de requisições com apenas um módulo de microserviço; outra completamente diferente é ter esses mesmos 200ms através de uma pilha de 6 aplicações interdependentes com mais de 120 milhões de requisições por dia;

(d) heterogeneidade do stack de tecnologia. Em alguns casos os sistemas monolíticos tem (ou ao menos deveriam ter) uma espécie de lingua franca para a construção da plataforma/sistema. Já com os microserviços, como vimos anteriormente eles tem um isolamento que restringe (minimiza) o impacto em plataformas adjacentes; mas que no entanto podem não obedecer algum tipo de padrão de tecnologia. Na prática, você pode ter um stack com um serviço escrito em Java, outro em Elixir, outro em Clojure, alguns até mesmo em Erlang.

Na prática isso é extremamente difícil de trabalhar, o que demanda um tempo maior de desenvolvedores full stack dado que essa abordagem pode em algum grau aumentar o número de redundâncias desnecessárias, limitar a produtividade e de quebra promover ainda mais a epidemia de desenvolvedores Resumé Driven que escolhem a melhor tecnologia para os seus respectivos CVs mas que deixam (muitas) pequenas bombas relógio nas aplicações/sistemas/plataformas mundo a fora.

Agora que temos a definição bem generalista do que é um microserviço, em um próximo post vamos explorar essa ideia para aplicações de Machine Learning dentro desse mesmo universo.

Palestra do Gilmar Souza no TDC 2016 Trilha Machine Learning

Uma ótima referência sobre ML em produção

Machine learning at NRK: From prototype to production: Øyvind Holmstad, Thomas Oldervoll from JavaZone on Vimeo.

Microserviços em Machine Learning – Parte 1: Uma (nano)introdução

Strata Singapore 2016 – Machine learning in practice with Spark MLlib: An intelligent data analyzer


No próximo dia 8 o meu amigo Eiti Kimura e eu faremos uma apresentação no Strata Hadoop World em Singapura para falarmos de uma solução que fizemos na Movile de monitoramento usando Machine Learning.

Já tivemos a oportunidade de falar um pouco (de maneira bem breve é verdade) no TDC 2016 aqui em São Paulo, mas agora iremos falar em um evento que pode ser considerado o mais importante de Big Data, Analytics e Machine Learning do mundo.


Falaremos um pouco do nosso case que basicamente é um problema de previsão de série temporal, em que tínhamos MUITOS alarmes que não funcionavam da maneira adequada e mais: como a nossa plataforma de tarifação funciona 24 x 7, a cada minuto que ela fica parada estamos perdendo muito dinheiro.

E a nossa solução que foi batizada de Watcher-AI usa basicamente o Spark MLLib e é acoplada na nossa plataforma de billing; e em qualquer sinal de instabilidade faz notificação para todo o time para solucionar o problema o mais rápido possível.

Ao longo dos dias vamos falar um pouco da conferência, sobre as novidades em relação à Machine Learning, Big Data, e algumas reflexões sobre Data Science e Machine Learning.

Não percam os próximos dias.





Strata Singapore 2016 – Machine learning in practice with Spark MLlib: An intelligent data analyzer

Movendo modelos de Machine Learning para produção

Isso ainda vai virar um post extenso aqui no blog, mas vamos com esse belo post do Ram Balakrishnan.

After building, training and deploying your models to production, the task is still not complete unless you have monitoring systems in place. A crucial component to ensuring the success of your models is being able to measure and quantify their performance. A number of questions are worth answering in this area.

Movendo modelos de Machine Learning para produção

What is hardcore data science—in practice?

Via Ideas O’Reilly

Um bom artigo que fala a respeito da inserção de modelos de Data Science em produção, ou o que é mais conhecido como Core Machine Learning.

So far, we have focused on how systems typically look in production. There are variations in how far you want to go to make the production system really robust and efficient. Sometimes, it may suffice to directly deploy a model in Python, but the separation between the exploratory part and production part is usually there.

One of the big challenges you will face is how to organize the collaboration between data scientists and developers. “Data scientist” is still a somewhat new role, but the work they have to do differs enough from those of typical developers that you should expect some misunderstandings and difficulties in communication.

The work of data scientists is usually highly exploratory. Data science projects often start with a vague goal and some ideas of what kind of data is available and methods that could be used, but very often, you have to try out ideas and get insights into your data. Data scientists write a lot of code, but much of this code is there to test out ideas and is expected to not be part of the final solution.


What is hardcore data science—in practice?