RLScore: Regularized Least-Squares Learners

Tapio Pahikkala, Antti Airola; 17(221):1−5, 2016.

RLScore is a Python open source module for kernel based machine learning. The library provides implementations of several regularized least-squares (RLS) type of learners. RLS methods for regression and classification, ranking, greedy feature selection, multi-task and zero-shot learning, and unsupervised classification are included. Matrix algebra based computational short-cuts are used to ensure efficiency of both training and cross-validation. A simple API and extensive tutorials allow for easy use of RLScore.

RLScore: Regularized Least-Squares Learners

Learning Planar Ising Models

Jason K. Johnson, Diane Oyen, Michael Chertkov, Praneeth Netrapalli; 17(215):1−26, 2016.

Inference and learning of graphical models are both well-studied problems in statistics and machine learning that have found many applications in science and engineering. However, exact inference is intractable in general graphical models, which suggests the problem of seeking the best approximation to a collection of random variables within some tractable family of graphical models. In this paper, we focus on the class of planar Ising models, for which exact inference is tractable using techniques of statistical physics. Based on these techniques and recent methods for planarity testing and planar embedding, we propose a greedy algorithm for learning the best planar Ising model to approximate an arbitrary collection of binary random variables (possibly from sample data). Given the set of all pairwise correlations among variables, we select a planar graph and optimal planar Ising model defined on this graph to best approximate that set of correlations. We demonstrate our method in simulations and for two applications: modeling senate voting records and identifying geo-chemical depth trends from Mars rover data.

Learning Planar Ising Models

Sim, você deveria entender o backpropagation!

Por Andrej Karpathy

Backpropagation is a leaky abstraction; it is a credit assignment scheme with non-trivial consequences. If you try to ignore how it works under the hood because “TensorFlow automagically makes my networks learn”, you will not be ready to wrestle with the dangers it presents, and you will be much less effective at building and debugging neural networks.
The good news is that backpropagation is not that difficult to understand, if presented properly. I have relatively strong feelings on this topic because it seems to me that 95% of backpropagation materials out there present it all wrong, filling pages with mechanical math. Instead, I would recommend the CS231n lecture on backprop which emphasizes intuition (yay for shameless self-advertising). And if you can spare the time, as a bonus, work through the CS231n assignments, which get you to write backprop manually and help you solidify your understanding.

Sim, você deveria entender o backpropagation!

Automatic time-series phenotyping using massive feature extraction

por Ben D Fulcher, Nick S Jones

Across a far-reaching diversity of scientific and industrial applications, a general key problem involves relating the structure of time-series data to a meaningful outcome, such as detecting anomalous events from sensor recordings, or diagnosing patients from physiological time-series measurements like heart rate or brain activity. Currently, researchers must devote considerable effort manually devising, or searching for, properties of their time series that are suitable for the particular analysis problem at hand. Addressing this non-systematic and time-consuming procedure, here we introduce a new tool, hctsa, that selects interpretable and useful properties of time series automatically, by comparing implementations over 7700 time-series features drawn from diverse scientific literatures. Using two exemplar biological applications, we show how hctsa allows researchers to leverage decades of time-series research to quantify and understand informative structure in their time-series data.

Automatic time-series phenotyping using massive feature extraction

Simple Black-Box Adversarial Perturbations for Deep Networks

por Nina Narodytska, Shiva Prasad Kasiviswanathan

Deep neural networks are powerful and popular learning models that achieve state-of-the-art pattern recognition performance on many computer vision, speech, and language processing tasks. However, these networks have also been shown susceptible to carefully crafted adversarial perturbations which force misclassification of the inputs. Adversarial examples enable adversaries to subvert the expected system behavior leading to undesired consequences and could pose a security risk when these systems are deployed in the real world.
In this work, we focus on deep convolutional neural networks and demonstrate that adversaries can easily craft adversarial examples even without any internal knowledge of the target network. Our attacks treat the network as an oracle (black-box) and only assume that the output of the network can be observed on the probed inputs. Our first attack is based on a simple idea of adding perturbation to a randomly selected single pixel or a small set of them. We then improve the effectiveness of this attack by carefully constructing a small set of pixels to perturb by using the idea of greedy local-search. Our proposed attacks also naturally extend to a stronger notion of misclassification. Our extensive experimental results illustrate that even these elementary attacks can reveal a deep neural network’s vulnerabilities. The simplicity and effectiveness of our proposed schemes mean that they could serve as a litmus test for designing robust networks.

Simple Black-Box Adversarial Perturbations for Deep Networks

Previsões para Deep Learning para 2017

Por James Kobielus da IBM.

(…)The first hugely successful consumer application of deep learning will come to market: I predict that deep learning’s first avid embrace by the general public will come in 2017. And I predict that it will be to process the glut of photos that people are capturing with their smartphones and sharing on social media. In this regard, the golden deep-learning opportunities will be in apps that facilitate image search, auto-tagging, auto-correction, embellishment, photorealistic rendering, resolution enhancement, style transformation, and fanciful figure inception. (…)

(…)A dominant open-source deep-learning tool and library will take the developer community by storm: As 2016 draws to a close, we’re seeing more solution providers open-source their deep learning tools, libraries, and other intellectual property. This past year, Google open-sourced its DeepMind and TensorFlow code, Apple published its deep-learning research, and the OpenAI non-profit group has started to build its deep-learning benchmarking technology. Already, developers have a choice of open-source tools for development of deep-learning applications in Spark, Scala, Python, and Java, with support for other languages sure to follow. In addition to DeepMind and TensorFlow, open tools for deep-learning development currently include DeepLearning4J, Keras, Caffe, Theano, Torch, OpenBLAS and Mxnet.(…)

(…)A new generation of low-cost commercial off-the-shelf deep-learning chipsets will come to market: Deep learning relies on the application of multilevel neural-network algorithms to high-dimensional data objects. As such, it requires the execution of fast-matrix manipulations in highly parallel architectures in order to identify complex, elusive patterns—such as objects, faces, voices, threats, etc. For high-dimensional deep learning to become more practical and pervasive, the underlying pattern-crunching hardware needs to become faster, cheaper, more scalable, and more versatile. Also, the hardware needs to become capable of processing data sets that will continue to grow in dimensionality as new sources are added, merged with other data, and analyzed by deep learning algorithms of greater sophistication. (…)

(…)The algorithmic repertoire of deep learning will grow more diverse and sophisticated: Deep learning remains a fairly arcane, specialized, and daunting technology to most data professionals. The growing adoption of deep learning in 2017 will compel data scientists and other developers to grow their expertise in such cutting-edge techniques as recurrent neural networks, deep convolutional networks, deep belief networks, restricted Boltzmann machines, and stacked auto-encoders. (…)

Previsões para Deep Learning para 2017

Como um agricultor do Japão está usando Deep Learning para seleção de pepinos

Direto do blog da Google

[…]Here’s a systems diagram of the cucumber sorter that Makoto built. The system uses Raspberry Pi 3 as the main controller to take images of the cucumbers with a camera, and in a first phase, runs a small-scale neural network on TensorFlow to detect whether or not the image is of a cucumber. It then forwards the image to a larger TensorFlow neural network running on a Linux server to perform a more detailed classification.


Makoto used the sample TensorFlow code Deep MNIST for Experts with minor modifications to the convolution, pooling and last layers, changing the network design to adapt to the pixel format of cucumber images and the number of cucumber classes.[…]

[…]One of the current challenges with deep learning is that you need to have a large number of training datasets. To train the model, Makoto spent about three months taking 7,000 pictures of cucumbers sorted by his mother, but it’s probably not enough.

“When I did a validation with the test images, the recognition accuracy exceeded 95%. But if you apply the system with real use cases, the accuracy drops down to about 70%. I suspect the neural network model has the issue of “overfitting” (the phenomenon in neural network where the model is trained to fit only to the small training dataset) because of the insufficient number of training images.”

The second challenge of deep learning is that it consumes a lot of computing power. The current sorter uses a typical Windows desktop PC to train the neural network model. Although it converts the cucumber image into 80 x 80 pixel low-resolution images, it still takes two to three days to complete training the model with 7,000 images.[…]

Como um agricultor do Japão está usando Deep Learning para seleção de pepinos

Desenvolvimento e validação de um algoritmo de Deep Learning para detecção da retinopatia diabética em fotografias de fundo retinal

Em 2008 quando eu iniciei grande parte dos meus estudos e interesse em Data Mining (que é uma disciplina irmã do que chamamos hoje de Data Science) desde aquela época tinha uma convicção muito forte de que os dados seriam o motor do que estamos vivendo hoje que é a quarta revolução industrial; revolução esta que tem os dados como principal combustível seja nas mas diversas áreas do conhecimento humano.

Dito isso, a Google juntamente com pesquisadores dos times da University of Texas, 3EyePACS LLC, University of California, Aravind Medical Research Foundation, Shri Bhagwan Mahavir Vitreoretinal Services, Verily Life Sciences e da Harvard Medical School conseguiram um avanço da aplicação de Deep Learning que confirma essa tese acima.

A retinopatia diabética é uma doença causada pela evolução de um quadro de diabetes em que os vasos sanguíneos do fundo da retina sofrem algum tipo de dilatação ou rompimento e que e não tratada pode causar cegueira. É uma doença que tem mais de 150 mil casos no brasil e não tem cura. Contudo, se o diagnóstico for realizado de forma antecipada o tratamento pode ajudar na minimização da cegueira.

E a aplicação de Deep Learning por esses pesquisadores ocorreu para auxiliar os médicos no diagnóstico desta doença.


Colocando de forma bem resumida: esse time utilizou Deep Learning para detecção da retinopatia diabética usando uma base de fotografias de fundo retinal de treinamento e obteve 90.3% e 87.0% de sensibilidade (i.e. a capacidade do algoritmo saber corretamente quem está com a doença ou não dos casos em que a doença é presente) e 98.1% e 98.5% de especificidade (i.e. o grau de precisão do algoritmo para identificar corretamente as pessoas que não tem a doença em casos em que de fato a doença não está presente) na detecção da retinopatia diabética.

Essa alta taxa de especificidade de 98.1% (i.e. capacidade de saber corretamente quem não tem a doença dentro do grupo que realmente não tem, ou seja, saber identificar corretamente a classe negativa) direciona de forma muito assertiva os tratamentos no sentido em que há uma certeza maior nos resultados da classe negativa (e essa forma os esforços não seriam direcionados de fato para quem não tem a doença).

Uma ideia de estratégia de saúde preventiva ou mesmo de diagnósticos pontuais é que após o exame de imagem a fotografia de fundo de retina passaria pelo algoritmo de Deep Learning já treinado, e caso o resultado do teste fosse positivo , o médico já iniciaria o tratamento e ao mesmo tempo a rede hospitalar e de medicamentos seria notificada de mais um caso, e haveria automaticamente o provisionamento de medicação e alocação de recursos médicos para o acompanhamento/tratamento.

Isso sem dúvidas muda todo o eixo de como vemos a medicina hoje, dado que isso daria um ganho ainda maior de eficiência para a medicina preventiva e evitaria a ineficiente (e bem mais cara) medicina curativa.

Abaixo os principais resultados do estudo.

Development and Validation of a Deep Learning Algorithm for Detection of Diabetic Retinopathy in Retinal Fundus Photographs

Varun Gulshan, PhD1; Lily Peng, MD, PhD1; Marc Coram, PhD1; et al Martin C. Stumpe, PhD1; Derek Wu, BS1; Arunachalam Narayanaswamy, PhD1; Subhashini Venugopalan, MS1,2; Kasumi Widner, MS1; Tom Madams, MEng1; Jorge Cuadros, OD, PhD3,4; Ramasamy Kim, OD, DNB5; Rajiv Raman, MS, DNB6; Philip C. Nelson, BS1; Jessica L. Mega, MD, MPH7,8; Dale R. Webster, PhD1

Key Points
Question How does the performance of an automated deep learning algorithm compare with manual grading by ophthalmologists for identifying diabetic retinopathy in retinal fundus photographs?

Finding In 2 validation sets of 9963 images and 1748 images, at the operating point selected for high specificity, the algorithm had 90.3% and 87.0% sensitivity and 98.1% and 98.5% specificity for detecting referable diabetic retinopathy, defined as moderate or worse diabetic retinopathy or referable macular edema by the majority decision of a panel of at least 7 US board-certified ophthalmologists. At the operating point selected for high sensitivity, the algorithm had 97.5% and 96.1% sensitivity and 93.4% and 93.9% specificity in the 2 validation sets.

Meaning Deep learning algorithms had high sensitivity and specificity for detecting diabetic retinopathy and macular edema in retinal fundus photographs.

Importance Deep learning is a family of computational methods that allow an algorithm to program itself by learning from a large set of examples that demonstrate the desired behavior, removing the need to specify rules explicitly. Application of these methods to medical imaging requires further assessment and validation.

Objective To apply deep learning to create an algorithm for automated detection of diabetic retinopathy and diabetic macular edema in retinal fundus photographs.

Design and Setting A specific type of neural network optimized for image classification called a deep convolutional neural network was trained using a retrospective development data set of 128 175 retinal images, which were graded 3 to 7 times for diabetic retinopathy, diabetic macular edema, and image gradability by a panel of 54 US licensed ophthalmologists and ophthalmology senior residents between May and December 2015. The resultant algorithm was validated in January and February 2016 using 2 separate data sets, both graded by at least 7 US board-certified ophthalmologists with high intragrader consistency.

Exposure Deep learning–trained algorithm.

Main Outcomes and Measures The sensitivity and specificity of the algorithm for detecting referable diabetic retinopathy (RDR), defined as moderate and worse diabetic retinopathy, referable diabetic macular edema, or both, were generated based on the reference standard of the majority decision of the ophthalmologist panel. The algorithm was evaluated at 2 operating points selected from the development set, one selected for high specificity and another for high sensitivity.

Results The EyePACS-1 data set consisted of 9963 images from 4997 patients (mean age, 54.4 years; 62.2% women; prevalence of RDR, 683/8878 fully gradable images [7.8%]); the Messidor-2 data set had 1748 images from 874 patients (mean age, 57.6 years; 42.6% women; prevalence of RDR, 254/1745 fully gradable images [14.6%]). For detecting RDR, the algorithm had an area under the receiver operating curve of 0.991 (95% CI, 0.988-0.993) for EyePACS-1 and 0.990 (95% CI, 0.986-0.995) for Messidor-2. Using the first operating cut point with high specificity, for EyePACS-1, the sensitivity was 90.3% (95% CI, 87.5%-92.7%) and the specificity was 98.1% (95% CI, 97.8%-98.5%). For Messidor-2, the sensitivity was 87.0% (95% CI, 81.1%-91.0%) and the specificity was 98.5% (95% CI, 97.7%-99.1%). Using a second operating point with high sensitivity in the development set, for EyePACS-1 the sensitivity was 97.5% and specificity was 93.4% and for Messidor-2 the sensitivity was 96.1% and specificity was 93.9%.

Conclusions and Relevance In this evaluation of retinal fundus photographs from adults with diabetes, an algorithm based on deep machine learning had high sensitivity and specificity for detecting referable diabetic retinopathy. Further research is necessary to determine the feasibility of applying this algorithm in the clinical setting and to determine whether use of the algorithm could lead to improved care and outcomes compared with current ophthalmologic assessment.

Desenvolvimento e validação de um algoritmo de Deep Learning para detecção da retinopatia diabética em fotografias de fundo retinal

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

Porque intervalos de confiança em previsões de séries temporais não são boas quanto desejamos?

Direto do Peter Stats Stuff

Para quem trabalha com modelos tipicamente de previsão usando ARIMA e Auto-ARIMA um aspecto bem difícil de se estimar é a a incerteza dos termos auto-regressivos (isso é, os seus intervalos de erros).

Na prática, no momento em que temos os termos dos coeficientes auto regressores absorvendo parte da incerteza seja por conta de meta-parametrização (ou a falta dela) ou mesmo devido à natureza dos dados, os modelos de previsão de séries temporais não conseguem captar esse tipo de incerteza, e nesse caso acontecem os problemas dos intervalos de confiança não representarem exatamente um range aceitável/factível.

The problem is that for all but the most trivial time series forecasting method there is no simple way of estimating the uncertainty that comes from having estimated the parameters from the data, and much less so the values of meta-parameters like the amount of differencing needed, how many autoregressive terms, how many moving average terms, etc (those example meta-parameters come from the Box-Jenkins ARIMA approach, but other forecasting methods have their own meta-parameters to estimate too).

Porque intervalos de confiança em previsões de séries temporais não são boas quanto desejamos?

Porque os métodos de árvores de decisão não são os mais ideais para problemas de extrapolação?

Neste artigo do Peter Stats ele demonstra que métodos baseados em árvores como Random Forests e Árvores de Decisão não tem um bom desempenho quando trabalham com dados muito fora do range do seu conjunto de treinamento, ou em termos estatísticos não realizam uma boa extrapolação.

Isso acontece na prática devido a alguns fatores mais relacionados à natureza dos algoritmos de árvores de decisão do que uma limitação em si como:

(a) os particionamentos recursivos das árvores de decisão por si só no momento em que encontram os dados de treinamento já estabelecem implicitamente algumas fronteiras em relação aos seus critérios de divisão dos dados;

(b) os critérios de divisão de dados (split criteria) mais comuns (information gain, entropia, CHAID, et cetera) levam em consideração os valores dos atributos de forma completa, antes do particionamento, o que já contribuí para esses limites não considerarem dados fora de um range específico; e

(c)  algumas ferramentas como o Spark MLIIb tem alguns parâmetros como Max Depth (máximo de profundidade) que controla a especificidade da árvore e de seus nós folha, e Max Bins (número máximo de agrupamento de dados dos valores de cada coluna) que determina por parametrização um range fixo (e com isso, mais fronteiras estabelecidas).

Dessa forma, para esse tipo de problema de séries temporais, o uso de algoritmos como o XGBoost ou até mesmo de Árvores de Decisão tem um bom desempenho quando aplicados em problemas em que a série temporal tem um comportamento bem previsível dentro de um range estabelecido (ou interpolação clássica) (não mais de 1 ou 2 desvios padrão) ou mesmo para problemas de previsão de limiares como usamos na Movile e que pode ser visto aqui.

Porque os métodos de árvores de decisão não são os mais ideais para problemas de extrapolaçã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