Machine Learning e o modelo de queijo suíço: falhas ativas e condições latentes

TL;DR: Problemas sempre vão existir. Uma postura reflexiva, sistemática, e com um plano de ação sempre foi e sempre será o caminho para resolução destes mesmos problemas.

Eu estava escrevendo um post sobre a importância dos Post Mortems em machine learning e vi que esta parte em específico estava ficando maior do que o ponto principal do outro post. Dessa forma eu resolvi quebrar esse post em um assunto específico com um pouco mais de foco e detalhes.

Aplicações de Machine Learning (ML) e Inteligência Artificial (IA) estão avançando em domínios cada vez mais críticos como medicina, aviação, setor bancário, investimentos entre outros. 

Estas aplicações estão diariamente tomando decisões de forma automatizada e em alta escala; não somente moldando a forma na qual indústrias estão operando, mas também como pessoas estão interagindo com plataformas que utilizam estas tecnologias.

Dito isso, é de fundamental importância que a cultura de engenharia em ML/AI incorpore e adapte cada vez mais conceitos como confiabilidade e robustez que são óbvios em outros campos da engenharia.

E um dos caminhos para essa adaptação é o entendimento de aspectos causais que possam elevar o risco de indisponibilidade destes sistemas.

Antes de prosseguir no texto eu recomendo a leitura do post Accountability, Core Machine Learning e Machine Learning Operations que fala um pouco de aplicações de ML em produção e da importância da engenharia na construção desses sistemas complexos.

A ideia aqui é falar sobre falhas ativas e condições latentes utilizando de forma simples o Modelo de Queijo Suíço. O objetivo é mostrar como estes dois fatores estão ligados na cadeia de eventos de indisponibilidades e/ou catastróficos em sistemas de ML.

Mas antes disso vamos entender um pouco do porque o entendimento das falhas pode ser um caminho alternativo para a melhoria da confiabilidade, e também sobre os “cases de sucesso” que vemos todos os dias na internet.

Viés de sobrevivência e aprendizado pela falha

Hoje na internet há uma miríade de informações sobre praticamente qualquer área técnica. Com todo o hype em ML e com a sua crescente adoção, estas informações materializam-se na forma de tutoriais, blog posts, fóruns de discussão, MOOCs, Twitter, entre outras fontes.

Porém, um leitor mais atento pode notar um determinado padrão em parte dessas histórias: Na maioria das vezes são cases de algo que (a) deu extremamente certo, (b) ou que gerou receita para a empresa, (c) ou como a solução o salvou X% em termos de eficiência, e/ou (d) como a nova solução de tecnologia foi uma das maiores maravilhas técnicas que já foram construídas.

Isso rende claps no Medium, posts no Hacker News, artigos em grandes portais de tecnologia, technical blog posts que que viram referências técnicas, papers e mais papers no Arxiv, palestras em conferências, etc.

Logo de antemão eu quero adiantar que eu sou um grande entusiasta da ideia de que “pessoas inteligentes aprendem com os próprios erros, e pessoas sábias aprendem com os erros dos outros”. Estes recursos, especialmente os technical blog posts e as conferências, reúnem um nível altíssimo de informações extremamente valiosas de pessoas que estão nas trincheiras técnicas.

Este bazar de ideias é extremamente saudável para a comunidade como um todo. Além do mais, este bazar está enterrando o antigo modelo de gatekeeping em que algumas consultorias de conferências surfaram por anos às custas de desinformação fazendo inúmeras empresas desperdiçarem rios de dinheiro. Ademais, este bazar de ideias está ajudando a acabar com o nefasto culto à personalidades de tecnologia em que qualquer pessoa pode ter uma voz.

Contudo, o que muitos destes posts, conference talks, papers e demais artigos não citam geralmente, são as coisas que dão/deram muito erradas durante o desenvolvimento dessas soluções; e isso essencialmente é um problema dado que estamos apenas vendo o resultado final e não o como esse resultado foi gerado e os falhas/erros cometidos no caminho.

Realizando um simples exercício de reflexão, é até compreensível que pouquíssimas pessoas socializem os erros cometidos e lições aprendidas; dado que nos dias de hoje, especialmente com as mídias sociais, a mensagem fica muito mais amplificada e distorcida.

Admitir erros não é algo fácil. Dependendo do grau de maturidade psicológica da pessoa que errou, junto com o erro pode vir uma montanha de sentimentos como constrangimento, inadequação, raiva, vergonha, negação etc. Isso pode levar a problemas de ordem psicológica em que um profissional de saúde mental tenha que acompanhar a pessoa que cometeu o erro. 

Do ponto de vista das empresas, a imagem que pode ficar em relação à relações públicas, é de desorganização corporativa, times de engenharia ruins, líderes técnicos que não sabem o que estão fazendo, etc. Isso pode afetar, por exemplo, ações de recrutamento.

Devido a estes pontos acima, isso implica que (1) talvez grande parte destes problemas podem estar acontecendo neste exato momento e estão sendo simplesmente suprimidos e (2) talvez exista um grande viés de sobrevivência nestes posts/talks/papers.

Não existe nada de errado com a forma na qual as empresas colocam os seus relatos, entretanto, um pouco de ceticismo e pragmatismo sempre é bom; pois, para cada caso de sucesso, sempre existirá uma infinidade de times que falharam miseramente, empresas que quebraram, pessoas que foram demitidas, etc.

Mas afinal, o que isso tudo tem a ver com a falhas que acontecem e porque entender os seus fatores contribuintes?

A resposta é: Porque primeiramente o seu time/solução tem que ser capaz de sobreviver à situações catastróficas para que o caso de sucesso exista. E ter a sobrevivência como aspecto motivador para aumentar a confiabilidade de times/sistemas, torna o entendimento dos erros em uma forma atrativa de aprendizado.

E quando existem cenários pequenas violações, supressão de erros, ausência de procedimentos, imperícia, imprudência ou negligência, as coisas dão espetacularmente muito errado, como nos exemplos abaixo:

Claro que nestas linhas mal escritas não haverá um ode à catástrofe ou disaster porn.

Porém, eu quero colocar um outro ponto de vista no sentido de que sempre existe uma lição a ser aprendida diante do que dá errado, e que empresas/times que mantém uma atitude introspectiva em relação aos problemas que acontecem ou analisam os fatores que possam a vir contribuir para um incidente, reforçam não somente uma cultura saudável de aprendizado como promovem uma cultura de engenharia mais orientada para aspectos de confiabilidade.

Partindo para o ponto prático, eu vou comentar um pouco sobre uma ferramenta (modelo mental) de gerenciamento de riscos que é o Modelo do Queijo Suíço que auxilia no entendimento de fatores causais que contribuem para a desastres em sistemas complexos.

O Modelo do Queijo Suíço

Se eu tivesse que dar um exemplo de indústria em que a confiabilidade pode ser considerada referência, com certeza seria a indústria da aviação [N2]. 

Em cada evento catastrófico que ocorre, há uma investigação minuciosa para entender o que aconteceu, e posteriormente endereçar os fatores contribuintes e fatores determinantes para um novo evento catastrófico nunca mais venha a acontecer.

Dessa forma, a aviação garante que aplicando o que foi aprendido devido ao evento catastrófico, todo o sistema fica mais confiável. Não é por acaso que mesmo com o aumento no número de voos (39 milhões de voos no último ano, 2019) o número de fatalidades vem caindo a cada ano que passa.

Uma das ferramentas mais utilizadas em investigação de acidentes aéreos para análise de riscos e aspectos causais é o Modelo de Queijo Suíço

Este modelo foi criado por James Reason através do artigo “The contribution of latent human failures to the breakdown of complex systems” em que houve a construção do seu framework (mas sem referência direta do termo). Entretanto, somente no paper “Human error: models and management o modelo aparece de forma mais direta.

A justificativa do modelo por parte do autor, é feita considerando um cenário de um sistema complexo e dinâmico da seguinte forma:

Defesas, barreiras e salvaguardas ocupam uma posição-chave na abordagem do sistema. Os sistemas de alta tecnologia têm muitas camadas defensivas: algumas são projetadas (alarmes, barreiras físicas, desligamentos automáticos etc.), outras contam com pessoas (cirurgiões, anestesistas, pilotos, operadores de salas de controle, etc.) e outras dependem de procedimentos e controles administrativos. Sua função é proteger possíveis vítimas e ativos contra riscos locais. Muitas das vezes essas camadas fazem isso de maneira muito eficaz, mas sempre há fraquezas.

Em um mundo ideal, cada camada defensiva estaria intacta. Na realidade, porém, são mais como fatias de queijo suíço, com muitos buracos – embora, diferentemente do queijo, esses buracos estejam continuamente abrindo, fechando e mudando de local. A presença de orifícios em qualquer “fatia” normalmente não causa um resultado ruim. Geralmente, isso pode acontecer apenas quando os orifícios em várias camadas se alinham momentaneamente para permitir uma trajetória de oportunidade de acidente – trazendo riscos para o contato prejudicial com as vítimas.

Human error: models and management

Uma forma de visualização deste alinhamento pode ser vista no gráfico abaixo:

Ou seja, neste caso cada fatia do queijo suíço seria uma linha de defesa com camadas projetadas (ex: monitoramento, alarmes, travas de push de código em produção, etc.) e/ou as camadas procedurais que envolvem pessoas (ex: aspectos culturais, treinamento e qualificação de commiters no repositório, mecanismos de rollback, testes unitários e de integração, etc.).

Ainda dentro do que o autor colocou, cada furo em alguma das fatias do queijo acontecem por dois fatores: falhas ativas e condições latentes, em que:

  • Condições latentes são como uma espécie de situações intrinsecamente residentes dentro do sistema; que são consequências de decisões de design, engenharia, de quem escreveu as normas ou procedimentos e até mesmo dos níveis hierárquicos mais altos de uma organização. Essas condições latentes podem levar a dois tipos de efeitos adversos que são situações que provocam ao erro e a criação de vulnerabilidades. Isto é, a solução possui um design que eleva a probabilidade de eventos de alto impacto negativo que pode ser equivalente a um fator causal ou fator contribuinte.  
  • Falhas Ativas são atos inseguros ou pequenas transgressões cometidos pelas pessoas que estão em contato direto com o sistema; atos estes que podem ser deslizes, lapsos, distorções, omissões, erros e violações processuais.

Se as condições latentes estão ligadas à aspectos ligados a engenharia e produto; as falhas ativas estão muito mais relacionadas com fatores humanos. Um ótimo framework para análise de fatores humanos é o Human Factors Analysis and Classification System (HFACS).

O HFACS coloca que as falhas humanas em sistema tecnológico-sociais complexos acontecem em quatro diferentes níveis como pode ser visto na imagem abaixo:

A ideia aqui no post não é discutir esses conceitos, e sim realizar um paralelo com machine learning em que alguns destes aspectos serão tratados. Para quem quiser saber mais eu recomendo a leitura do HFACS para uma leitura aprofundada do framework.

Já que temos alguns dos conceitos bem claros do que são as falhas ativas e condições latentes, vamos realizar um exercício de reflexão usando alguns exemplos com ML.

Gerenciamento de falhas ativas e condições latentes em Machine Learning

Para fazer a transposição destes fatores para a arena de ML de uma forma mais concreta, eu vou usar alguns exemplos do que eu já vi acontecer, do que já aconteceu comigo, e mais alguns dos pontos do excelente artigo de Sculley, David, et al. chamado “Hidden technical debt in machine learning systems.” apenas para efeitos didáticos. 

De maneira geral esses conjuntos de fatores (não-exaustivos) estariam representados da seguinte maneira:

Condições Latentes

  • Cultura de arranjos técnicos improvisados (workarounds): O uso de arranjos técnicos improvisados gambiarra em algumas situações é extremamente necessário. Contudo, uma cultura de voltada a workarounds [N3] em um campo que tem complexidades intrínsecas como ML tende a incluir potenciais fragilidades em sistemas de ML e tornar o processo de identificação e correção de erros muito mais lento.
  • Ausência de monitoramento e alarmística: Em plataformas de ML alguns fatores que precisam de monitoramento específico como data drift (i.e. mudança na distribuição dos dados que servem de input para o treinamento) model drift (i.e. degradação do modelo em relação aos dados que são previstos) e adversarial monitoring que é o monitoramento para assegurar que o modelo está sendo testado para coleta de informações ou ataques adversariais.
  • Resumé-Driven Development ou RDD, é quando engenheiros ou times implementam uma ferramenta em produção apenas para ter no CV que trabalharam com a mesma, potencialmente prospectando um futuro empregador. O RDD tem como principal característica de criar uma dificuldade desnecessária para vender uma facilidade inexistente se a coisa certa tivesse sido feita. 
  • Decisões de tipo democracia com pessoas menos informadas ao invés do consenso entre especialistas e tomadores de risco: O ponto aqui é simples: Decisões chave só podem ser tomadas por (a) quem estiver envolvido diretamente na construção e na operacionalização dos sistemas, (b) quem estiver financiando e/ou tomando o risco, e (c) quem tem o nível de habilidades técnicas para saber os prós e contras de cada aspecto da decisão. A razão é que essas pessoas têm ao menos a própria pele em jogo ou sabem os pontos fracos e fortes do que está sendo tratado. O Fabio Akita já fez um argumento bem interessante nesta linha que mostra o quão ruim pode ser quando pessoas sem a pele em jogo e mal informadas estão tomando decisões. Democracia em profissões de prática não existe. Essa neo-democracia corporativa coletivista não tem rosto, e logo não tem accountability caso algo dê errado. Democracia em aspectos técnicos nos termos colocados acima é uma condição latente. Algo errado nunca será correto apenas porque uma maioria decidiu.

Falhas Ativas

  • Código não revisado indo para produção: Diferentemente da boa engenharia de software tradicional em que existe um camada de revisão de código para assegurar se tudo está dentro dos padrões de qualidade, em ML isso é um tema que ainda tem muito a amadurecer, dado que grande parte dos Data Scientists não têm um background programação e versionamento de código fonte. Outro ponto que dificulta bastante é que no fluxo de trabalho de cientistas de dados muitas das ferramentas usadas, tornam a revisão de código que impossível (e.g. Knit para o R) e Jupyter Notebook para Python.
  • Glue code: Nesta categoria eu coloco os códigos que fazemos no momento da prototipação e do MVP que vai para produção da mesma forma que foram criados. Uma coisa que já vi acontecer bastante neste sentido foi ter aplicações com dependências de inúmeros pacotes e que para ter uma “integração” mínima necessitavam de muito glue code. O código ficava tão frágil que uma mudança na dependência (ex: uma simples atualização do código fonte) quebrava praticamente toda a API em produção.

Um cenário de indisponibilidade em um sistema de ML

Vamos imaginar que a uma empresa financeira fictícia chamada “Leyman Brothers” teve uma indisponibilidade na qual a sua plataforma de trading de ações ficou indisponível por 6 horas causando perdas massivas em alguns investidores.

Após a construção de um devido Post-Mortem o time chegou à seguinte narrativa em relação aos fatores determinantes e contribuintes na indisponibilidade:

O motivo da indisponibilidade foi devido a um erro do tipo falta de memória devido a um bug na biblioteca de ML.

Este erro é conhecido pelos desenvolvedores da biblioteca e existe um ticket aberto sobre o problema desde 2017, mas que até o presente momento não teve solução (Condição Latente).

Outro aspecto verificado foi que o tempo de resposta e solução foi demasiadamente longo devido ao fato de que não haviam mecanismos de alarmística, heartbeating ou monitoramento na plataforma de ML. Dessa forma, sem as informações de diagnóstico, o problema levou mais tempo do que o necessário para ser corrigido (Condição Latente).

No momento do debugging foi verificado que o desenvolvedor responsável pela implementação do trecho de código em que aconteceu a origem do erro, tinha conhecimento das alternativas de correção, mas não o fez devido ao fato de que a correção levaria a implementação de outra biblioteca em uma linguagem de programação a qual ele não têm domínio; mesmo com esta linguagem já sendo utilizada em outras partes do stack de tecnologia (Falha Ativa). 

Por fim, foi visto também que o código entrou diretamente em produção sem nenhum tipo revisão. O projeto no Github não possui nenhuma “trava” para impedir que códigos não revisados entrem em produção. (Falha Ativa devido à Condição Latente).

Transpondo o evento da narrativa para o modelo de Queijo Suíço, visualmente teríamos a seguinte imagem:

No nosso Queijo Suíço cada uma das fatias seriam camadas ou linhas de defesa em que temos aspectos como a arquitetura e engenharia dos sistemas, o stack de tecnologia, os procedimentos específicos de desenvolvimento, a cultura de engenharia da empresa e por fim as pessoas como última salvaguarda.

Os furos por sua vez seriam os elementos falhos em cada uma destas camadas de defesa que podem ser falhas ativas (ex: dar commit direto na master pelo fato de hão haver Code Review) ou condições latentes (e.g. biblioteca de ML, falta de monitoramento e alarmística).

Em uma situação ideal, após um evento de indisponibilidade, todas as condições latentes e as falhas ativas seriam endereçadas e haveria um plano de ação para a solução dos problemas para que o mesmo evento nunca mais acontecesse no futuro

Apesar da narrativa de alto nível, o ponto principal é que indisponibilidades em sistemas complexos e dinâmicos nunca acontecem devido a um fator isolado, mas sim devido à conjunção e sincronização de condições latentes e falhas ativas.

CONSIDERAÇÕES FINAIS

Claro que não existe panaceia em relação ao que pode ser feito em termos de gestão de riscos: alguns riscos e problemas podem ser tolerados e muitas das vezes não existe o tempo e os recursos necessários para aplicação dos devidos ajustes.

Entretanto, quando falamos de sistemas de missão crítica que usam ML fica claro que existem uma miríade de problemas específicos que podem acontecer além dos naturais problemas de engenharia.

O modelo do Queijo Suíço é um modelo de gerenciamento de riscos que é muito utilizado na aviação e oferece uma maneira simples de elencar condições latentes e falhas ativas em eventos que possam levar a falhas catastróficas.

O entendimento dos fatores contribuintes e determinantes em eventos de falha, pode ajudar a eliminar ou minimizar potenciais riscos e consequentemente reduzir o impacto na cadeia de consequências estes eventos.

NOTAS

[N1] – O objetivo deste post é única e exclusivamente comunicar com times de Machine Learning Engineering, Data Science, Data Product Management e demais áreas que tenham realmente a cultura de melhoria e feedback contínuo. Se você e/ou a sua empresa entende que conceitos de qualidade, robustez, confiabilidade e aprendizado são importantes, este post é dedicado especialmente a vocês.

[N2] No momento em que esse artigo estava sendo revisado apareceu essa matéria do novo avião Boeing 787 que devido ao fato de que o sistema core não consegue eliminar dados obsoletos (flush de dados) de algumas informações de sistemas críticos do avião que afetam a aeronavegabilidade, e que por isso a cada 51 dias todos os aviões deste modelo devem ser desligados. Isso mesmo, um avião Boeing precisa do mesmo tipo de reboot ao estilo “já tentou desligar a sua máquina e religar novamente?” para que um evento catastrófico não ocorra. Mas isto mostra que mesmo com uma condição latente é possível operar um sistema complexo de maneira segura.

[N3] Cultura de Gambiarras + eXtreme Go Horse (XGH) + Jenga-Oriented Architecture = Usina de indisponibilidades

[N4] – Agradecimentos especiais ao Comandante Ronald Van Der Put do canal Teaching for Free pela gentileza em me ceder alguns materiais relacionados à segurança e prevenção de acidentes.

REFERÊNCIAS

Reason, James. “The contribution of latent human failures to the breakdown of complex systems.” Philosophical Transactions of the Royal Society of London. B, Biological Sciences 327.1241 (1990): 475-484.

Reason, J. “Human error: models and management.” BMJ (Clinical research ed.) vol. 320,7237 (2000): 768-70. doi:10.1136/bmj.320.7237.768

Morgenthaler, J. David, et al. “Searching for build debt: Experiences managing technical debt at Google.” 2012 Third International Workshop on Managing Technical Debt (MTD). IEEE, 2012.

Alahdab, Mohannad, and Gül Çalıklı. “Empirical Analysis of Hidden Technical Debt Patterns in Machine Learning Software.” International Conference on Product-Focused Software Process Improvement. Springer, Cham, 2019.

Perneger, Thomas V. “The Swiss cheese model of safety incidents: are there holes in the metaphor?.” BMC health services research vol. 5 71. 9 Nov. 2005, doi:10.1186/1472-6963-5-71

“Hot cheese: a processed Swiss cheese model.” JR Coll Physicians Edinb 44 (2014): 116-21.

Breck, Eric, et al. “What’s your ML Test Score? A rubric for ML production systems.” (2016).

SEC Charges Knight Capital With Violations of Market Access Rule

Blog da Qualidade – Modelo Queijo Suíço para analisar riscos e falhas.

Machine Learning Goes Production! Engineering, Maintenance Cost, Technical Debt, Applied Data Analysis Lab Seminar

Nassim Taleb – Lectures on Fat Tails, (Anti)Fragility, Precaution, and Asymmetric Exposures

Skybrary – Human Factors Analysis and Classification System (HFACS)

CEFA Aviation – Swiss Cheese Model

A List of Post-mortems

Richard Cook – How Complex Systems Fail

Airbus – Hull Losses

Number of flights performed by the global airline industry from 2004 to 2020

Machine Learning e o modelo de queijo suíço: falhas ativas e condições latentes

Accountability, Core Machine Learning e Machine Learning Operations

Para quem acompanha o debate de tecnologia através da academia, indústria, conferências, e na mídia já percebeu que a Inteligência Artificial (AI) e suas subáreas são os assuntos mais quentes no momento.

Algumas empresas já que têm o núcleo do seu negócio em sistemas/plataformas digitais (e alguns não digitais) entenderam que o uso de Machine Learning (ML) tem um grande potencial tanto para casos de otimização na forma com a qual a empresa funciona, quanto para casos de geração direta de receita.

Isso pode ser visto em inúmeros negócios que vão desde o setor bancário, passando por sistemas de recomendação voltados para o entretenimento, e chegando até mesmo em algumas aplicações médicas.

Este post vai tentar colocar de maneira bem breve sobre como ML está moldando muitos negócios, uma breve reflexão em relação à marcha do accountability [1], e finalmente algumas breves considerações no que se refere a times de Core Machine Learning, e da abordagem de Machine Learning Operations (MLOps).

De que forma Machine Learning está moldando algumas indústrias e qual o grau de responsabilidade dos times de engenharia?

Com a adoção de machine learning por parte da indústria, isto deu início a um movimento natural que tanto machine learning quanto a indústria estão moldando um ao outro.

Se em um primeiro momento a indústria beneficia-se de plataformas de Machine Learning para obter predições, classificações, inferências e tomada de decisão em escala com custo marginal perto de zero; Machine Learning beneficia-se da indústria com o acesso a recursos de pesquisa e desenvolvimento inimagináveis na academia, acesso a recursos que teriam um custo inviável para condução de estudos, e um aumento da maturidade de seus métodos em termos de engenharia.

Entretanto, o que estamos falando aqui em última instância é da escala em que decisões são tomadas na indústria, e como a P&D em Machine Learning avançam em altíssima velocidade.

Dito isso, podemos afirmar que nos dias de hoje estes sistemas não estão mais na inofensiva arena das ideias e provas de conceito; mas sim estão como elementos ativos em processos de interação entre pessoas e negócios de forma massiva em alta escala.

E devido à esta escala, uma série de novas questões que se não eram tão preocupantes ou eram veladas no passado, hoje passam ter uma maior importância, como por exemplo:

  • Se no passado um gerente de branco recusasse um empréstimo para algum cliente por conta da cor da pele, gênero, ou deficiência; pouco ou quase nada ocorria com este gerente e/ou banco. Nos dias de hoje, algoritmos de Machine Learning sem a devida análise e monitoramento de seus outputs podem automatizar e amplificar este tipo de viés, colocando assim o banco em um passivo jurídico e de relações públicas sem precedentes. Atualmente existem pessoas trabalhando em disciplinas como equidade e ética para minimizar estes problemas.

Como podemos ver nestes exemplos, aspectos atuais como vieses humanos estruturais, falta de diversidade, promoção estrutural de injustiça, abuso de autoridade podem ser minimizados com ML usando ferramentas como equidade (Fairness), transparência, accountability, e explicabilidade.

E dado os pontos colocados acima, é desnecessário dizer a importância e a responsabilidade de cada dos profissionais de ML para assegurar que uma decisão automatizada não inclua e/ou amplifique estes vieses sistemáticos.

Uma das maiores verdades em tecnologia, é que os sistemas computacionais grande parte das vezes trabalham na amplificação de comportamentos e competências. Um sistema de ML que não leva em consideração vieses estruturais estão fadados a não somente a dar continuidade, mas como também a amplificar estes mesmos vieses em alta escala.

E dada a enorme autoridade da engenharia tem em relação à implementação destes sistemas, automaticamente o accountability virá com a mesma intensidade do grau de impacto destas soluções.

O Accountability virá de maneira voluntária e/ou coercitiva

Dado todos os cenários em que plataformas de ML têm um impacto direto na indústria, e de todos os potenciais riscos e impactos na sociedade, existe uma marcha regulatória vindo de inúmeras frentes que vão colocar uma responsabilização muito maior nas empresas e nos engenheiros de ML.

Esta responsabilização será essencialmente em relação a aspectos sensíveis que preocupam a sociedade como um todo: ética, equidade, diversidade, privacidade, segurança, direito de explicação de decisões algorítmicas (para quem está sob a GDPR), além claro de aspectos específicos de ML (e.g. reprodutibilidade, avaliação dos modelos, etc.).

Desta forma, isto mais do que nunca coloca uma pressão muito grande em todos nós engenheiros, cientistas de dados, gerentes de produto, CTOs, CEOs e demais stakeholders de não somente fazer o nosso trabalho, mas também atentar a todos estes aspectos.

Se este cenário soa distante ou fora da realidade, eu convido os mais céticos a responderem de forma honesta as seguintes perguntas em relação ao seu atual empregador:

Eu poderia colocar inúmeros outros casos que já estão acontecendo nos dias de hoje, mas acredito que consegui fazer o meu ponto. Para quem quiser saber mais, eu recomendo o livro da Cathy O ‘Neil chamado Weapons of Math Destruction que mostra alguns destes cenários ou a palestra baseada no livro, chamada ”A era da fé cega nos “Big Data” tem que acabar.

Além disso, se esta responsabilização não vier pela via de mercado, isso obrigatoriamente virá pela via coercitiva da regulamentação estatal; esta última que neste momento está sendo desenvolvida por inúmeros governos em todo o mundo para imputar responsabilização, tanto nas empresas quanto nos indivíduos.

Isso pode ser visto nos inúmeros observatórios e Think Tanks como a The AI4EU Observatory, em algumas recomendações da OECD em relação à Inteligência Artificial, e nos recentes guidelines divulgados pelas estratégias nacionais de IA em países como a Estônia, Finlândia, Alemanha, China, Estados Unidos, França e a própria Comissão da União Europeia que já disse que claramente que vai regular massivamente IA da perspectiva de riscos e transparência.  

Isto quer dizer em última instância que erros em um sistema que interage diretamente com seres humanos é algo que vai resultar em uma cadeia de consequências totalmente distinta da que temos atualmente.

Dado esse cenário extremamente complexo, podemos deduzir que se a era do “analista-com-um-script-na-própria-máquina” não acabou ela está em vias de acontecer de forma muito mais rápida do que podemos imaginar; seja pelo profissionalismo e conscientização, ou pela coerção, ameaça e/ou perdas fiduciárias.

E não se engane com quem fala que você é somente “uma pessoa que deve cumprir ordens” e que nada vai acontecer. No momento em que a sua empresa tiver algum tipo de problema cível/criminal/relações públicas você será corresponsável. E já existe precedente de engenheiro que está pegando cadeia por conta de más práticas dentro do seu ofício. E aqui não vai ser somente uma questão de “se”, mas sim “quando” isso vai chegar em engenharia de software em ML.

A mensagem que eu quero deixar aqui não é de desespero ou mesmo induzir situações de enfrentamento corporativo. O que eu quero deixar como mensagem final é apenas que devemos ter uma consciência situacional desta marcha do accountability/responsabilização e do porquê isso será inevitável.

Em outras palavras: Raciocínio crítico é parte intrínseca do trabalho, você é responsável pelo o que faz, e o valor disso já está embutido no seu salário.

Core Machine Learning

A primeira vez que eu tive contato com a abordagem de Core Machine Learning foi em meados de 2015 no Strata Data Conference e continuando em 2016 através de algumas palestras do Hussein Mehanna. Contudo, somente em 2017 no Facebook @Scale após o contato com as pessoas da indústria eu consegui entender um pouco mais do que era esta abordagem.

Não que exista uma definição formal, mas basicamente um time de Core Machine Learning seria o responsável pelo desenvolvimento de plataformas de Machine Learning dentro do Core Business das organizações; seja embutindo algoritmos nas plataformas existentes ou entregando serviços de inferência/predição via APIs.

Parte da missão desse time seria lidar diretamente todas as iniciativas de aplicações de machine learning dentro da atividade principal da empresa. Isto vai desde pesquisa aplicada, adoção de práticas de software engineering em ML, até construção da parte de infraestrutura destas aplicações.

Pensando na nova economia que chegou para ficar, a meu ver, estamos no meio de uma transição de paradigmas de desenvolvimento de produtos.

Em um lado temos um paradigma que tem o foco na construção de aplicações estáticas que tem uma preocupação com os fluxos de negócios. Em um outro lado temos um paradigma herda as mesmas características, mas que usam os dados para alavancar estas aplicações.

Óbvio que existe muito hype e muito solucionismo usando ML, mas eu estou falando aqui de empresas que conseguem aplicar ML de forma oportunística e com pragmatismo para a construção destas aplicações.

Em outras palavras: o algoritmo na plataforma passa a virou o produto em si.

Vejamos alguns exemplos de plataformas em que o algoritmo é o produto:

  • Spotify: O Discovery Weekly é um bom exemplo de uma feature de Machine Learning que acabou virando um produto dentro da plataforma;

Estes são alguns dos exemplos públicos mais famosos de alguns cases de machine learning no core business dos negócios tanto no Brasil quanto em outros lugares.

Uma forma muito interessante de entender como alguns algoritmos auxiliaram na alavancagem de produtos, pode ser vista no paper Applied Machine Learning at Facebook: A Datacenter Infrastructure Perspective do Facebook:

Claro que sabemos que internamente a coisa não é tão simples assim, mas podemos ter uma ideia de como aspectos vitais para o produto Facebook depende essencialmente da implementação de Core Machine Learning.

Pode parecer a mesma coisa em um primeiro momento, mas a principal diferença entre as atribuições de um time de Data Science para um time de Core Machine Learning, é que enquanto o primeiro geralmente tem um foco na parte de análise e modelagem; o segundo coloca tudo isto de maneira que seja escalável e automatizada dentro do núcleo principal do negócio.

Porém, dado que falamos que Core Machine Learning idealmente seria um time/abordagem que potencialmente alavanca o core business através da aplicação de ML, eu vou falar um pouco da forma como a coisa toda é operacionalizada. 

MLOps – Machine Learning Operations

Na Engenharia de Software existe um grau de maturidade altíssimo na forma em que as aplicações são construídas e as suas ferramentas que vão desde excelentes IDEs, passando por frameworks que lidam bem com inversão de controle e injeção de dependência, metodologias de desenvolvimento maduras e battle-tested, ferramentas de deployment que simplificam muito o processo de CI/CD, e ferramentas de observabilidade que facilitam o monitoramento das aplicações.

Em contraste, em machine learning existe um abismo em termos de maturidade em relação à adoção dessas práticas como também em grande parte do tempo engenheiros de machine learning trabalham com artefatos de dados como modelos e datasets.

Alguns destes artefatos (não exaustivos) são:

  • Análises de Data Science;
  • Pipelines de extração de dados e geração de features via Data Engineering;
  • Versionamento de dados que geram os modelos;
  • Tracking de treinamento de modelos;
  • Tracking dos hiperparâmetros usados nos experimentos;
  • Versionamento de modelos de Machine Learning;
  • Serialização e promoção dos modelos para produção;
  • Manutenção de privacidade dos dados e do modelo;
  • Treinamento dos modelos considerando contramedidas de segurança (e.g. ataques adversariais);
  • Monitoramento da performance dos modelos dada a natureza de degradação intrínseca de performance desses artefatos (data/model drift).

Uma das consequências de tantas distinções em termos de processos entre essas áreas, é que a operacionalização desses recursos também deve ser feita de forma totalmente distinta.

Em outras palavras, talvez DevOps pode não ser o bastante nestes casos.

Uma figura que resume bem este ponto é da talk do Luke Marsden chamada “MLOps Lifecycle Description” em que ele coloca a diferença entre essas duas áreas da seguinte forma:

MLOps Lifecycle Description

A ideia por trás é que enquanto tradicionalmente engenharia de software lida com funcionalidades e tem no código a materialização de fluxos; na abordagem de Machine Learning Operations (MLOps) além de existirem as mesmas preocupações, há uma adição de muitas partes móveis como dados, modelos e métricas e da operacionalização de todos estes aspectos [2].

Isto é, a operacionalização desde fluxo de desenvolvimento e deployment requer uma nova maneira de entrega dessas soluções de forma end-to-end.

Para isto, uma proposta de como seria uma aplicação end-to-end considerando esses aspectos operacionais de ML é apresentada no artigo “Continuous Delivery for Machine Learning: Automating the end-to-end lifecycle of Machine Learning applications dentro da perspectiva de entrega contínua:

Continuous Delivery for Machine Learning (CD4ML) is a software engineering approach in which a cross-functional team produces machine learning applications based on code, data, and models in small and safe increments that can be reproduced and reliably released at any time, in short adaptation cycles.

Continuous Delivery for Machine Learning: Automating the end-to-end lifecycle of Machine Learning applications

No mesmo artigo, ainda tem uma figura de como seria um fluxo end-to-end de uma plataforma de machine learning:

Continuous Delivery for Machine Learning: Automating the end-to-end lifecycle of Machine Learning applications

E com essas novas camadas de complexidades somadas com a pouca educação em engenharia de software por parte de grande parte dos cientistas de dados, fica claro que o espectro de potenciais problemas no que diz respeito à entrega de aplicações de machine learning fica muito maior.

Entretanto, até o momento discutimos aspectos bem de alto nível como questões de impacto dos sistemas de ML, aspectos ligados à responsabilização, Core Machine Learning e as suas responsabilidades e a abordagem de MLOps.

Porém, eu quero aprofundar um pouco mais o nível e entrar em alguns pontos mais específicos em que MLOps têm uma atuação mais; isto é, jogar um pouco de luz na trilha escura em que SysOps, DevOps, Software Engineering, e Data Science geralmente não entrariam.

Fonte: Christian Collins – shades of mirkwood

Complexidade em sistemas de Machine Learning

No clássico paper Hidden Technical Debt in Machine Learning Systems existe uma imagem que cristaliza bem o que é realmente um sistema de machine learning em relação à complexidade e esforço para cada componente deste sistema:

Hidden Technical Debt in Machine Learning Systems

Ainda que sem uma menção direta sobre MLOps, no artigo tem algumas considerações em relação aos problemas específicos de sistemas de machine learning e que acarretaria débitos técnicos e demais problemas que potencialmente deixariam essas aplicações mais frágeis em termos de escalabilidade e manutenção.

Eu resolvi pegar alguns dos sete pontos do artigo e colocar alguns exemplos práticos. A ideia é mostrar uma abordagem de MLOps em alguns cenários (hipotéticos ou não) como podemos ver abaixo:

A corrosão de limites devido à modelos complexos
Dependências de dados custam mais do que dependências de código
Ciclos de Feedback
  • O time de produtos pediu para fazer uma estratégia de experimentação com Multi-Armed Bandits com n modelos. Como os dados das estratégias perdedoras estão sendo isolados (i.e. dado que as estratégias afetam os dados presentes e o futuro treino no futuro)? Existe alguma assinatura de log que identifique estes registros?[3]
  • Um sistema recomendador retorna uma lista de itens ordenada pela probabilidade em termos de relevância para o usuário. Entretanto, o nDCG do modelo está muito baixo. Quanto tempo demoraria para você saber que o motivo é devido ao fato de que o Front-End ao invés de respeitar a ranqueamento recebido do sistema recomendador, o mesmo está refazendo a ordenação por ordem alfabética? Como seria um teste ou ciclo de feedback entre o sistema de recomendação e o Front-End neste caso?[3]
Anti-Patterns em Sistemas de Machine Learning
Débito de Configuração
  • Cada uma dos seus microserviços de ML têm configurações de logging locais e enviar esses logs para um ELK envolveria refazer os scripts e o deployment em todos esses serviços.
Lidando com mudanças no mundo externo
  • O sistema de ML que faz detecção/classificação de anomalias e que é usado para alarmística e monitoramento de receita está recebendo um aumento no volume de requisições. Porém, passado algum tempo o sistema começa a disparar inúmeros alertas de queda de receita; alertas estes que acionam os desenvolvedores para solução desse problema. Contudo, você descobre a razão dos alertas: o time de marketing fez uma campanha não recorrente que aumentou de maneira não-orgânica a receita, e o classificador “aprendeu” que aqueles níveis de receita seriam o “novo normal”. [3]
  • O seu sistema de recomendação está oferecendo os mesmos itens fora de catálogo por 15 dias seguidos, trazendo não só uma experiência de usuário horrível, mas também afetando negativamente a receita. O motivo? Não existe o monitoramento dos dados (filebeat) e nem das métricas da aplicação (metricbeat). [3]
Outras áreas de débitos técnicos relacionadas com Machine Learning, como:

Os pontos acima foram alguns exemplos de como sistemas de machine learning carregam complexidades intrínsecas que envolvem conjuntos de habilidades muito específicas e que devem ser levadas em consideração no tocante à sua operacionalização.

CONSIDERAÇÕES FINAIS

Estamos na marcha de ter cada vez mais sistemas de Machine Learning envolvidos de forma direta ou marginal no core business das empresas.

Com o aumento do impacto destes sistemas nas vidas das pessoas, na sociedade e nos negócios, é questão de tempo para termos protocolos de accountability caso alguma coisa saia do controle; em especial em aspectos ligados a equidade, transparência, e explicabilidade destes sistemas e algoritmos.

Dentro disso fica cada vez mais claro que a era do “analista-com-um-script-na-própria-máquina” está com os dias contados quando falamos de plataformas que tem interatividade com pessoas.

Ao passo que sistemas de Machine learning ainda não tem o mesmo nível de maturidade de engenharia de software em relação ao seu desenvolvimento, deployment e operacionalização, como também conta com muitos aspectos específicos; talvez exista uma avenida para o crescimento do que é conhecido hoje como MLOps, ou Machine Learning Operations.

A abordagem de MLOps não veem apenas para lidar com aspectos ligados a parte de infraestrutura ou desenvolvimento software, mas esses times vêm para atender uma demanda, ainda latente, da eliminação ou mitigação dos problemas e débitos intrínsecos da atividade de desenvolvimento Machine Learning.

NOTAS

[1] – Os pares de termos como “Data Scientist /Cientistas de Dados”, “Sistemas/Plataformas”, “Product Manager/Gerente de Produto”, “Accountability/Responsabilização”, “Fairness/Equidade” serão usados alternadamente ao longo deste texto.

[2] – Para quem tiver interessado o Luke Marsden escreveu uma espécie de MLOps Manifesto onde tem algumas dessas ideias.

[3] – Eventos em que eu fui testemunha ou que aconteceram comigo diretamente.

LINKS E REFERÊNCIAS

Accountability, Core Machine Learning e Machine Learning Operations

Por que acredito que no Brasil estamos entrando em uma bolha de Data Science?

TL;DR: Faça uma avaliação racional e pragmática baseada em fatos e informações de mercado antes de escolher uma mudança de carreira ou até mesmo alternativas de investimento em qualificações em Data Science & Machine Learning. 

Eu sei que nos dias de hoje o que eu estou falando pode parecer ser contraintuitivo, ao mesmo tempo que temos empresas anunciando que vão contratar 100 cientistas de dados em um único ano (mesmo sem nenhuma justificativa sólida do porque e principalmente do retorno esperado com essas contratações), ou quando o volume de buscas em “ciência de dados” aumenta em mais de 50% em menos de 3 anos, ou em uma busca simples podemos encontrar mais de 1.500 vagas disponíveis no LinkedIn.

Claro que a minha opinião não é a mais popular atualmente, mas o que eu vejo hoje são os mesmos padrões das bolhas passadas em tecnologia no Brasil.

Quem não se lembra da bolha de Certificações Microsoft? (alguém lembra do famigerado programa Maestro de SQL Server?)

Ou da bolha de certificações Oracle?

Do cursos da dobradinha campeã PHP e MySQL que prometiam os maiores salários do mercado?

Ou das promessas do eldorado de salários e empregabilidade como Web Designer com os cursos de Corel Draw, Dreamweaver e Flash?

E os cursos de frameworks ITIL, COBIT, TOGAF ou BABOK que nos prometiam cargos maravilhosos apenas gerenciando processos de negócios? (Sendo que muita faculdade e cursos livres igualmente picaretas ao invés de ensinarem o básico de código, jogaram uma geração inteira de universitários em frameworks de “gestão” sendo que parte deles não conseguem gerenciar nem mesmo a própria vida financeira).

Tudo o que eu vou colocar aqui diz respeito ao lado da oferta de cientistas de dados, e não da demanda propriamente dita (i.e. isso merece um post especial, mas na prática pouquíssimas empresas sabem o que estão contratando e tem uma galera contratando somente para sinalização). 

Desta forma este post vai ser muito mais voltado para gestão de carreira do que para um retrato de mercado. 

Longe de ser algum tipo de coach ou algo do semelhante, o meu objetivo vai ser convidar o leitor para uma reflexão sobre alguns aspectos que eu julgo como importantes de acordo com algumas observações que eu tenho feito no mercado como um todo de forma empírica.

Alguns aspectos que sinalizam que talvez estamos em uma bolha de Data Science e Machine Learning na minha visão são:

1) O Retorno do Investimento (ROI) em uma formação em DS em relação aos salários não compensa: Eu vou tirar desta análise os MOOCs e cursos sensacionais como o da Fast.ai do Jeremy Howard por um motivo muito simples: Nós no Brasil adoramos um diploma e o nosso sistema educacional foi moldado de uma forma que não promove o autodidatismo, mas promove um modelo baseado em tutoria em que o professor não é um facilitador mas é o responsável e guardião do  conhecimento em si. O que eu quero dizer é que esta análise do ROI vale exclusivamente para cursos de pós-graduação e cursos de extensão. Eu fiz uma pequena pesquisa em alguns cursos e existem algumas formações que custam mais de R$ 30.000. Nada contra o valor em si, porém, vamos falar que o retorno esperado deste investimento seja de 4 anos. Isso dá R$ 625/mês por 4 anos. Em outras palavras: desde o dia em que o curso termina, o nosso recém-formado já precisa de um aumento de pouco mais de R$ 600 só para ficar no empate em relação a sua formação. Ah, e lógico fora o custo de oportunidade do tempo (e.g. tempo de aula, deslocamento, alimentação, etc) e o custo de oportunidade do dinheiro (e.g. usar esse dinheiro em algum investimento, fundo de ações, etc). Tendo em vista uma recessão brutal que tivemos nos últimos anos (e com a renda praticamente estagnada) eu consideraria muito bem uma decisão de investimento (ou endividamento) desde porte sem uma perspectiva de retorno de no mínimo de 2 anos.

2) O mercado está cada vez mais competitivo e a barreira de entrada está quase nula e ao mesmo tempo que isso é bom, isso pode ser um problema. Se eu tivesse que descrever o mercado a frase que mais se assemelha de como eu vejo é Bellum omnium contra omnes, ou guerra de todos contra todos. Se você é Cientista da Computação, você vai competir com Econometristas que sabem mais de modelagem do que você; se você é Estatístico vai competir com Cientistas da Computação que codam mais que você; se você é Econometrista vai competir com Estatísticos que dominam um ferramental matemático/estatístico melhor do que o seu, e todos eles vão competir com pessoas com mestrado e doutorado. O ponto aqui é que a competição vai ficar cada vez mais brutal e isto no longo prazo não é escalável em termos de carreira dado que são disciplinas que demandam tempo para o aprendizado.

3) Assim que o mercado começar a ter a desilusão com contratações erradas e as frustrações corporativas com os cientistas de dados começarem, os processos seletivos vão ficar mais acirrados e não haverá bons espaços para todos. Uma coisa que eu aprendi como contratante em um período da minha carreira foi: A cada decepção devido a uma contratação errada duas medidas brutais entravam em cena: a) os requerimentos, testes e as exigências aumentam muito mais e b)  salário aumentava em proporção dado que a exigência seria a maior caso o candidato fosse aprovado. O que eu quero dizer aqui é que as posições vão começar a sofrer uma escalada insana de habilidades para as melhores posições e o mercado vai ser dividido em “posições boas” e “posições ruins”. Em outras palavras: entrar como Data Scientist ganhando abaixo do mercado só fazendo consulta em SQL e mexendo em macro no Excel é fácil, o difícil é ir para a tigela dos altos salários e usar ferramental moderno para resolução de problemas difíceis.

4) A enxurrada de gente sem a mínima ideia do que é Ciência ou Dados entrando na área: Pensa bem, neste exato momento milhares de pessoas estão entrando no campo sem nenhum tipo de ideia do mercado por conta de hype, influencers, mídia e outras fontes que prometem o eldorado dos altos salários ou descrevem Data Science como a profissão mais sexy do século 21. Isto não é escalável e uma hora grande parte dessas pessoas que estão se aventurando vão ter uma desilusão muito grande dado os motivos no item 3) ou mesmo quando as empresas darem conta que o maluco do Excel que está a milhares de anos da empresa manja mais do negócio e dos números do que toda a galera que fica fazendo script copiado do Towards Data Science no Macbook Pro de retina display com sticker de conferência gringa.

5) Vocês acham mesmo que repentinamente todas as empresas do sistema solar nunca ouviram falar de análise de dados básica ou estatística básica? Que somente agora elas acordaram de um torpor dos últimos 25 anos e elas decidiram que precisam de unicórnios mandados dos céus para salvar as empresas da falência através de insights gerados dos dados? Com ou sem cientistas de dados todos os dias no sistema solar negócios são fechados, vendas são feitas, pessoas compram coisas, e o dinheiro circula de uma mão para a outra.

Mas vamos supor que você me veja como um vendido ou uma pessoa com interesses ocultos por conta do que eu disse. Dessa forma, não acredite em mim, mas sim nas pessoas e instituições atores abaixo; eles sim sabem o que é melhor para a sua carreira:

a) Universidades e alguns professores de cursos de extensão e pós-graduação: Se a sua principal fonte de receita dependesse de um maior volume de alunos possível ou se a sua instituição servisse como o proxy predileto para contratação, você anunciaria que estamos em uma bolha educacional (onde já temos o incrível advento dos diplomas inúteis no Brasil) ou surfaria na onda e ofereceria cursos caça níquel que estão no mínimo 3 anos atrás do mercado? Uma coisa que eu vejo muito são instituições que estiveram dormindo por mais de 5 anos em relação a ciência de dados ou dados em geral que repentinamente abrem um curso de Data Science e Machine Learning com um corpo docente que nunca foi do mercado e com grades que não correspondem com a realidade do que está sendo feito nas empresas e nem cobrem aspectos básicos que todo cientista deveria saber. Novamente não precisam acreditar em mim: Vá nos cursos de extensão e pós-graduação e veja quais deles estão ensinando fundamentos de estatística básica, inferência causal, cálculo, álgebra, etc.

b) Mídia: Não se engane, por trás de todo anuncio de empresas contratando inúmeros cientistas de dados existe um submundo de matérias pagas para gerar algo chamado Brand Awareness. Inúmeras empresas usam a mídia para veicular matérias e “notícias” que favoreçam essas empresas (e.g. a revista faz uma matéria positiva sobre a empresa  A e meses depois uma empresa subsidiada da empresa A paga um anúncio de 300 mil reais para a mesma revista) para dar a percepção de que aquela empresa é legal e que faz coisas incríveis, quando na verdade está apenas vinculando a sua marca positivamente enquanto as vagas reais mesmo estão fechadas (isto quando estas vagas existem).

c) Papo de conferência: Eu como um bom rato de conferência tenho que dar o braço a torcer em que eu caí muito nisso no passado. Eu ia na conferência e deslumbrado com a tecnologia eu já fazia um plano de estudos para a nova ferramenta para Data Science ou Machine Learning. Você volta energizado da conferência para a sua empresa com a expectativa de implantar aqueles cases maravilhosos, mas na realidade você termina fechando ticket de tarefa sem sentido no JIRA.

d) Influencers, tecnologistas e afins: Estes adoram quando você fica mudando de tecnologias assim como muda de roupa por um motivo simples: isto dá mais views no youtube, mais comentários sobre o que está “trendando”, mais artigos em seus blogs no Medium, e mais do que isso: eles ganham credibilidade somente mostrando o que fazer e não fazendo algo corporativamente ou academicamente e pior – tudo isso sem nenhum tipo de risco envolvido caso o que eles recomendem de errado. Ciência e Engenharia são coisas que andam lentamente mas com passos firmes. Uma troca de tecnologia ou mesmo a adoção de novas ferramentas (ao menos em empresas sérias) é um processo que pode levar anos ou deve ter um motivo muito razoável para acontecer. Eu trabalhei em uma empresa que o software de fila só foi trocado depois de muitos problemas de instabilidade, e mesmo com um novo sistema o nosso “failback” ainda ficava nos velhos e sempre confiáveis arquivos texto. O ponto que eu quero deixar aqui é: ao ver influencers, tecnologistas e afins falando sobre novas ferramentas e frameworks que você precisa aprender, desconfie e entenda que as empresas não vão sair de tecnologias estabelecidas em que elas tem corpo de conhecimento e know-how para embarcar na sua aventura como Cientista de Dados “antenado” com o mercado. 

e) Amigos e colegas que já estão no mercado: Uma pequena parte desta galera nunca vai admitir que estão em uma bolha por um motivo simples: esta galera acredita realmente que são excelentes e merecedores de suas posições e salários nababescos. Entretanto, parte destes colegas esquecem dos fatores causais não identificados que os levaram a ter a posição que eles têm hoje. Por exemplo, pode ser tempo de casa, tempo na posição de DS antes do hype do mercado, track record na empresa não relacionado com DS, ou mesmo falta de alguém que tenha um conhecimento técnico mas que também conheça o negócio. E lógico não vamos esquecer que nós seres humanos somos ótimos em subestimar o papel do acaso e da sorte nas nossas vidas. No final do dia somos seres humanos e amamos uma narrativa romantizada da realidade. Agora cair na narrativa é questão de escolha.

Por fim eu quero colocar algumas mentiras que as pessoas contam sobre Data Science e Machine Learning:

As formações não estão caras: Parem pra pensar: uma formação não é somente o valor pago, mas sim o custo de oportunidade e mais o tempo que vai ser investido como eu coloquei anteriormente. Ciência de Dados hoje é uma área muito dinâmica que está mudando muito rápido. Ferramentas em menos de 1 ano ganham direcionamentos totalmente diferentes. Será que vale a pena investir 18 ou 36 meses pagando mais de R$ 1.500 em uma formação e ao final praticamente todos os frameworks ensinados já estão sendo descontinuados ou em outras versões? Tudo isso para que? Conseguir um emprego em uma vaga júnior ou no máximo ter R$ 350 de aumento sendo que você gastou R$ 40 mil em uma formação? Não parece um ROI ideal pra mim.

Há um déficit de cientistas de dados no mercado: Isto é parcialmente verdade. No caso, inúmeras empresas precisam modernizar a maneira com a qual elas fazem análise, dado que algumas ainda estão no paradigma descritivo ou diagnóstico e querem ir para a parte preditiva e prescritiva. Contudo, a não ser que você trabalhe em empresas que realmente estão usando os dados em seus produtos como por exemplo Nubank, Quinto Andar, Pipefy, Movile e etc, grande parte das empresas ainda precisam sair do excel e do combo “média-desvio-padrão-correlação-gráfico-de-pizza”. E não existe absolutamente nada de errado com isso. O ponto e o que o mercado pensa que um cientista de dados tem habilidades de Data Engineer, Data Scientist, Software Engineer, DBA, analista de requisitos tudo no mesmo papel. Então se você pensa que vai chegar na sua posição de Cientista de Dados fazendo análises  em dashboards como no Minority Report enquanto toma um delicioso vinho italiano enquanto escuta Toccata em Ré menor de Bach enquanto tem os seus insights, eu tenho uma péssima notícia: Isto não vai acontecer. No melhor dos casos você vai ficar brigando com DBA para ter acesso no banco de dados, vai encontrar muita defensividade de analistas que não tem um emprego tão sexy quanto o seu, e sem o conhecimento de negócio você vai ser sempre colocado de escanteio pela galera do Excel (esse relato antológico mostra bem isso).

Eu preciso ser Data Scientist para dar certo na vida: Existem muitas coisas bacanas em engenharia fora de Data Science que são tão importantes quanto como DevOps, Site Reliability Engineering, Front/Backend Engineering, Data Engineering, Automation, Incident Response, Mobile Development, Security, Infraestrutura, etc. E acredite são posições que pagam muito bem, exigem conhecimentos que são difíceis de serem adquiridos e sempre terá demanda e impactam diretamente no negócio.

Considerações Finais

Lendo esse relato que beira o pessimismo extremo alguns podem falar “mas poxa, então eu não devo ir para a área de Data Science?” a minha resposta e “vá, mas entenda os principais problemas da área e saiba que este não é o único caminho.Tenha em mente que frustrações de expectativas nos aspectos profissionais e financeiros podem ser uma realidade e poucas pessoas estão falando sobre isso”. Eu penso que sempre haverá espaço para bons profissionais, independente do que fazem e empresas boas sempre contratam pessoas boas mesmo se não tiver o budget, a vaga, ou mesmo a posição propriamente dita. Espero que esse pequeno relato tenha jogado um pouco de racionalidade e luz sobre a carreira em Data Science e sirva ao menos para uma reflexão.

Notas

[1] Este post foi descaradamente inspirado no relato de 2010 do Bolha Imobiliária de Brasília que viu o principal problema no seio da economia brasileira em relação à bolha de crédito.

[2] Este escriba recusa-se (ao menos aqui no blogue) a adotar o novo padrão de escrita da internet sentenças com no máximo 7 palavras muito simples. Como eu acredito que os leitores deste blogue são pessoas de capacidade cognitiva avançada, as sentenças vão ficar complexas. Reduzir a complexidade para uma linguagem que promove o emburrecimento dos leitores nunca foi e nunca será o foco aqui.

Por que acredito que no Brasil estamos entrando em uma bolha de Data Science?

Security in Machine Learning Engineering: A white-box attack and simple countermeasures

Some weeks ago during a security training for developers provided by Marcus from Hackmanit (by the way, it’s a very good course that goes in some topics since web development until vulnerabilities of NoSQL and some defensive coding) we discussed about some white box attacks in web applications (e.g.attacks where the offender has internal access in the object) I got a bit curious to check if there’s some similar vulnerabilities in ML models. 

After running a simple script based in [1],[2],[3] using Scikit-Learn, I noticed there’s some latent vulnerabilities not only in terms of objects but also in regarding to have a proper security mindset when we’re developing ML models. 

But first let’s check a simple example.

A white-box attack in a Scikit-Learn random forest object

I have a dataset called Layman Brothers that consists in a database of loans that I did grab from internet (if someone knows the authors let me know to give the credit) that contains records regarding consumers of a bank that according some variables indicates whether the consumer defaulted or not. This is a plain vanilla case of classification and for a matter of simplicity I used a Random Forest to generate a classification model. 

The main points in this post it’s check what kind of information the Scikit-Learn object (model) reveals in a white-box attack and raises some simple countermeasures to reduce the attack surface in those models.

After ran the classifier, I serialized the Random Forest model using Pickle. The model has the following performance against the test set:

# Accuracy: 0.81
# status
# 0 8071
# 1 929
view raw test-set-results.py hosted with ❤ by GitHub

Keep attention in those numbers because we’re going to talk about them later on in this post. 

In a quick search in internet the majority of applications that uses Scikit-Learn for production environments deals with a pickled (or serialized model in Joblib) object that it’s hosted in a machine or S3 bucket and an API REST take care to do the servicing of this model. The API receives some parameters in the request and bring back some response (the prediction result). 

In our case, the response value based on the independent variables (loan features) will be defaulted {1}or not {0}. Quite straightforward.  

Having access in the Scikit-Learn object I noticed that the object discloses valuable pieces of information that in the hands of a white-box attacker could be potentially very damaging for a company. 

Loading the pickled object, we can check all classes contained in a model:

So, we have a model with 2 possible outcomes, {0} and {1}. From the perspective of an attacker we can infer that this model has some binary decision containing a yes {1}or no {0}decision. 

I need to confess that I expected to have only a read accessin this object (because the Scikit-Learn documentation gives it for grant), but I got surprised when I discovered that I can write in the objecti.e. overriding the training object completely. I made that using the following snippet:

# Load model from Pickle
model_rf_reload_pkl = pickle.load(open(‘model_rf.pkl’, ‘rb’))
# Displays prediction classes
model_rf_reload_pkl.classes_
# >>> array([0, 1])

One can noticed that with this command I changed all the possible classes of the model only using a single numpy array and hereafter this model will contain only the outcome {1}.

Just for a matter of exemplification I ran the same function against the test dataset to get the results and I got the following surprise:

# Actual against test set
# Accuracy: 0.2238888888888889
# status
# 1 9000
# Previous against test set
# Accuracy: 0.8153333333333334
# status
# 0 8071
# 1 929
view raw comparison.py hosted with ❤ by GitHub

In this simple example we moved more than 8k records to the wrong class. It’s unnecessary to say how damaging this could be in production in some critical domain like that. 

If we do a simple mental exercise, where this object could be a credit score application, or some classifier for in a medical domain, or some pre-order of some market stocks; we can see that it brings a very cold reality that we’re not close to be safe doing the traditional ML using the popular tools. 

In the exact moment that we Machine Learning Engineers or Data Scientists just run some scripts without even think in terms of vulnerabilities and security, we’re exposing our employers, business and exposing ourselves in such liability risk that can cause a high and unnecessary damage because of the lack of a better security thinking in ML models/objects. 

After that, I opened an issue/question in Scikit-Learn project to check the main reason why this type of modification it’s possible. Maybe I was missing something that was thought by the developers during the implementation phase. My issue in the project can be seeing below:

And I got the following response:

Until the day when this post was published there’s no answer for my last question about this potential vulnerability in a parameter that should not be changed after model training.

This is a simple white-box attack that can interfere directly in the model object itself. Now let’s pretend that we’re not an attacker in the object, but we want to explore other attack surfaces and check which valuable information those models can give for us. 

Models revealing more than expected

Using the same object, I’ll explore the same attributes that is given in the docs to check if we’re able to fetch more information from the model and how this information can be potentially useful.

First, I’ll try to see the number of estimators:

print(fNumber of Estimators: {len(model_rf_reload_pkl.estimators_)}’)
# >>> Number of Estimators: 10
view raw estimators.py hosted with ❤ by GitHub

This Random Forest training should be not so complex, because we have only 10 estimators (i.e. 10 different trees) and grab all the complexities of this Random Forest won’t be so hard to a mildly motivated attacker. 

I’ll grab a single estimator to perform a quick assessment in the tree (estimator) complexity:

model_rf_reload_pkl.estimators_[5]
# >>> DecisionTreeClassifier(class_weight=None, criterion='gini',
# max_depth=5,max_features='auto',
# max_leaf_nodes=5, min_impurity_decrease=0.0,
# min_impurity_split=None, min_samples_leaf=100,
# min_samples_split=2, min_weight_fraction_leaf=0.0,
# presort=False, random_state=1201263687,
# splitter='best')
view raw estimators-info.py hosted with ❤ by GitHub

Then this tree it’s not using a class_weight to perform training adjustments if there’s some unbalance in the dataset. As an attacker with this piece of information, I know that if I want to perform attacks in this model, I need to be aware to alternate the classes during my requests. 

It means that if I get a single positive result, I can explore in alternate ways without being detected as the requests are following by a non-weighted distribution.

Moving forward we can see that this tree has only 5 levels of depth (max_depth) with a maximum 5 leaf nodes (max_leaf_nodes) with a minimum of 100 records per leaf (min_samples_leaf).

It means that even with such depth I can see that this model can concentrate a huge amount of cases in some leaf nodes (i.e. low depth with limited number of leaf nodes). As an attacker maybe I don’t could not have access in the number of transactions that Layman Brothers used in the training, but I know that the tree it’s simple and it’s not so deep. 

In other words, it means that my search space in terms of parameters won’t be so hard because with a small number of combinations I can easily get a single path from the root until the leaf node and explore it.

As an attacker I would like to know how many features one estimator contains. The point here is if I get the features and their importance, I can prune my search space and concentrate attack efforts only in the meaningful features. To know how many features one estimator contains, I need to run the follow snippet:

# Extract single tree
estimator = model_rf_reload_pkl.estimators_[5]
print(fNumber of Features: {estimator.n_features_}’)
# >> Number of Features: 9
view raw tree-features.py hosted with ❤ by GitHub

As we can see, we have only 9 parameters that were used in this model. Then, my job as an attacker could not be better. This is a model of dreams for an attacker. 

But 9 parameters can be big enough in terms of a search space. To prune out some non-fruitful attacks of my search space, I’ll try to check which variables are relevant to the model. With this information I can reduce my search space and go directly in the relevant part of the attack surface. For that let’s run the following snippet:

features_list = [str(x + 0) for x in range(estimator.n_features_)]
features_list
# >>> ['0', '1', '2', '3', '4', '5', '6', '7', '8']
importances = estimator.feature_importances_
indices = np.argsort(importances)
plt.figure(1)
plt.title(‘Feature Importances’)
plt.barh(range(len(indices)), importances[indices], color=b’, align=center’)
plt.yticks(range(len(indices)), indices)
plt.xlabel(‘Relative Importance’)

Let me explain: I did grab the number of the features and put an id for each one and after that I checked the relative importance using np.argsort()to assess the importance of those variables. 

As we can see I need only to concentrate my attack in the features in the position [4][3]and [5]. This will reduce my work in tons because I can discard other 6 variables and the only thing that I need to do it’s just tweak 3 knobs in the model. 

But trying something without a proper warmup could be costly for me as an attacker and I can lose the momentum to perform this attack (e.g. the ML team can update the model, someone can identify the threat and remove the model and rollback an old artifact, etc).

To solve my problem, I’ll check the values of one of trees and use it as a warmup before to do the attack. To check those values, I’ll run the following code that will generate the complete tree:

from sklearn.tree import export_graphviz
# Export as dot file
export_graphviz(estimator, out_file=tree.dot’,
feature_names = features_list,
rounded = True, proportion = False,
precision = 2, filled = True)
# Convert to png using system command (requires Graphviz)
from subprocess import call
call([‘dot’, ‘Tpng’, ‘tree.dot’, ‘o’, ‘tree.png’, ‘Gdpi=600’])
# Display in jupyter notebook
from IPython.display import Image
Image(filename =tree.png’)
view raw plot-tree.py hosted with ❤ by GitHub

Looking the tree graph, it’s clearer that to have our Loan in Layman Brothers always with false {0}in the defaultvariable we need to tweak the values in {Feature 3<=1.5 && Feature 5<=-0.5 && Feature 4<=1.5}.

Doing a small recap in terms of what we discovered: (i) we have the complete model structure, (ii) we know which features it’s important or not, (iii) we know the complexity of the tree, (iv) which features to tweak and (v) the complete path how to get our Loan in Layman Brothers bank always approved and game the system. 

With this information until the moment that the ML Team changes the model, as an attacker I can explore the model using all information contained in a single object. 

As discussed before this is a simple white-box approach that takes in consideration the access in the object. 

The point that I want to make here it’s how a single object can disclose a lot for a potential attacker and ML Engineers must be aware about it.

Some practical model security countermeasures

There are some practical countermeasures that can take place to reduce the surface attack or at least make it harder for an attacker. This list it’s not exhaustive but the idea here is give some practical advice for ML Engineers of what can be done in terms of security and how to incorporate that in ML Production Pipelines. Some of those countermeasures can be:

  • Consistency Checks on the object/model: If using a model/object it’s unavoidable, one thing that can be done is load this object and using some routine check (i) the value of some attributes (e.g. number of classes in the model, specific values of the features, tree structure, etc), (ii) get the model accuracy against some holdout dataset (e.g. using a holdout dataset that has 85% of accuracyand raise an error in any different value), (iii) object size and last modification.  

  • Use “false features: False features will be some information that can be solicited in the request but in reality, won’t be used in the model. The objective here it’s to increase the complexity for an attacker in terms of search space (e.g.a model can use only 9 features, but the API will request 25 features (14 false features)). 

  • Model requests monitoring: Some tactics can be since monitoring IP requests in API, cross-check requests based in some patterns in values, time intervals between requests.

  • Incorporate consistency checks in CI/CD/CT/CC: CI/CD it’s a common term in ML Engineering but I would like to barely scratch two concepts that is Continuous Training (CT) and Continuous Consistency (CC). In Continuous Training the model will have some constant routine of training during some period of time in the way that using the same data and model building parameters the model will always produce the same results.  In Continuous Consistency it’s an additional checking layer on top of CI/CD to assess the consistency of all parameters and all data contained in ML objects/models. In CC if any attribute value got different from the values provided by the CT, the pipeline will break, and someone should need to check which attribute it’s inconsistent and investigate the root cause of the difference.

  • Avoid expose pickled models in any filesystem (e.g. S3) where someone can have access:  As we saw before if someone got access in the ML model/objects, it’s quite easy to perform some white-box attacks, i.e.no object access will reduce the exposure/attack surface.

  • If possible, encapsulates the coefficients in the application code and make it private: The heart of those vulnerabilities it’s in the ML object access. Remove those objects and incorporates only model coefficients and/or rules in the code (using private classes) can be a good way out to disclose less information about the model.

  • Incorporate the concept of Continuous Training in ML Pipeline: The trick here it’s to change the model frequently to confuse potential attackers (e.g.different positions model features between the API and ML object, check the reproducibility of results (e.g.accuracy, recall, F1 Score, etc) in the pipeline).

  • Use heuristics and rules to prune edge cases: Attackers likes to start test their search space using some edge (absurd) cases and see if the model gives some exploitable results and fine tuning on top of that. Some heuristics and/or rules in the API side can catch those cases and throw a cryptic error to the attacker make their job quite harder.

  • Talk its silver, silence its gold: One of the things that I learned in security it’s less you talk about what you’re doing in production, less you give free information to attackers. This can be harsh but its a basic countermeasure regarding social engineering. I saw in several conferences people giving details about the training set in images like image sizing in the training, augmentation strategies, pre-checks in API side, and even disclosing the lack of strategies to deal with adversarial examples. This information itself can be very useful to attackers in order to give a clear perspective of model limitations. If you want to talk about your solution talk more about reasons (why) and less in terms of implementation (how). Telling in Social Media that I keep all my money underneath my pillow, my door has only a single lock and I’ll arrive from work only after 8PM do not make my house safer. Remember: Less information = less exposure. 

Conclusion

I’ll try to post some countermeasures in a future post, but I hope that as least this post can shed some light in the ML Security. 

There’s a saying in aviation culture (a good example of industry security-oriented) that means “the price of safety it’s the eternal vigilance” and I hope that hereafter more ML Engineers and Data Scientists can be more vigilant about ML and security. 

As usual, all codes and notebooks are in Github.

Security in Machine Learning Engineering: A white-box attack and simple countermeasures

Choosing Learning Rate?

Ben Hammel shows how to do it.

Reduce learning rate on plateau

Every time the loss begins to plateau, the learning rate decreases by a set fraction. The belief is that the model has become caught in region similar to the “high learning rate” scenario shown at the start of this post (or visualized in the ‘chaotic’ landscape of the VGG-56 model above). Reducing the learning rate will allow the optimizer to more efficiently find the minimum in the loss surface. At this time, one might be concerned about converging to a local minimum. This is where building intuition from an illustrative representation can betray you, I encourage you to convince yourself of the discussion in the “Local minima in deep learning” section.

Use a learning-rate finder

The learning rate finder was first suggested by L. Smith and popularized by Jeremy Howard in Deep Learning : Lesson 2 2018. There are lots of great references on how this works but they usually stop short of hand-wavy justifications. If you want some convincing of this method, this is a simple implementation on a linear regression problem, followed by a theoretical justification.

Behavior or different learning rate values
Choosing Learning Rate?

Machine Learning Model Degradation

In a very insightful article made by David Talby he discuss about the fact that in a second that a Machine Learning goes to production, actually this model starts degradate itself because the model contact with the reality, where the author uses the following statement:

The key is that, in contrast to a calculator, your ML system does interact with the real world. If you’re using ML to predict demand and pricing for your grocery store, you’d better consider this week’s weather, the upcoming national holiday and what your competitor across the street is doing. If you’re designing clothes or recommending music, you’d better follow opinion-makers, celebrities and current events. If you’re using AI for auto-trading, bidding for online ads or video gaming, you must constantly adapt to what everyone else is doing.

The takeaways from the article it is that every ML in production should have some simple guidelines for monitoring and reassessment like 1) A online measure of accuracy to monitor the model degradation, 2) The ML Engineers most mind the gap between the distributions in the training and test sets, and 3) Data quality alerts regarding the unexpected growth in some groups of your sample that you’re facing some bad predictions.

Machine Learning Model Degradation

Tunability, Hyperparameters and a simple Initial Assessment Strategy

Most of the time we completely rely in the default parameters of Machine Learning Algorithm and this fact can hide that sometimes we can make wrong statements about the ‘efficiency’ of some algorithm.

The paper called Tunability: Importance of Hyperparameters of Machine Learning Algorithms from Philipp Probst, Anne-Laure Boulesteix, Bernd Bischl in Journal of Machine Learning Research (JMLR) bring some light in this subject. This is the abstract:

Modern supervised machine learning algorithms involve hyperparameters that have to be set before running them. Options for setting hyperparameters are default values from the software package, manual configuration by the user or configuring them for optimal predictive performance by a tuning procedure. The goal of this paper is two-fold. Firstly, we formalize the problem of tuning from a statistical point of view, define data-based defaults and suggest general measures quantifying the tunability of hyperparameters of algorithms. Secondly, we conduct a large-scale benchmarking study based on 38 datasets from the OpenML platform and six common machine learning algorithms. We apply our measures to assess the tunability of their parameters. Our results yield default values for hyperparameters and enable users to decide whether it is worth conducting a possibly time consuming tuning strategy, to focus on the most important hyperparameters and to choose adequate hyperparameter spaces for tuning.

Probst, Boulesteix, Bischl in Tunability: Importance of Hyperparameters of Machine Learning Algorithms

I recognize that the abstract sounds not so appealing, but the most important part of the text for sure it’s related in one table and one graph about the Tunability, i.e. how tuneable one parameter is according the other default values.

As we can observe in the columns Def.P (package defaults) and Def.O (optimal defaults) even in some vanilla algorithms we have some big differences between them, specially in Part, XGBoost and Ranger.

If we check the variance across this hyper parameters, the results indicates that the problem can be worse that we imagined:

As we can see in a first sight there’s a huge variance in terms of AUC when we talk about the default parameters.

Checking these experiments two big questions arises:

  1. How much inefficiency it’s included in some process of algorithm assessment and selection because for the ‘initial model‘ (that most of the times becomes the last model) because of relying in the default values? and;
  2. Because of this misleading path to consider some algorithm based purely in defaults how many ML implementations out there is underperforming and wasting research/corporate resources (e.g. people’s time, computational time, money in cloud providers, etc…)?

Initial Assessment Strategy

A simple strategy that I use for this particular purpose it’s to use a two-phase hyperparameter search strategy where in the first phase I use to make a small knockout round with all algorithms using Random Search to grab the top 2 or 3 models, and in the second phase I use Grid Search where most of the time I explore a large number of parameters.

According the number of samples that I have in the Test and Validation sets, I usually let the search for at least 24 hours in some local machine or in some cloud provider.

I do that because with this ‘initial‘ assessment we can have a better idea which algorithm will learn more according the data that I have considering dimensionality, selectivity of the columns or complexity of the word embeddings in NLP tasks, data volume and so on.

Conclusion

The paper makes a great job to expose the variance in terms of AUC using default parameters for the practitioners and can give us a better heuristic path in terms to know which parameters are most tunable and with this information in hands we can perform better search strategies to have better implementations of Machine Learning Algorithms.

Tunability, Hyperparameters and a simple Initial Assessment Strategy

Machine Learning new version of the quote: “In God we trust, all others must bring data”

Edwards Deming said:

In God we trust, all others must bring data.

Source Wikipedia

In face of a very nice thread of Cecile Janssens in Twitter I’m making this new statement for every ML Engineer, Data Analyst, Data Scientist hereafter:

“IN GOD WE TRUST, OTHERS MUST BRING THE RAW DATA WITH THE SOURCE CODE OF THE EXTRACTION IN THE GITHUB

CLESIO, Flavio. 2019. Berlin.

Machine Learning new version of the quote: “In God we trust, all others must bring data”

Post-training quantization in FastText (or How to shrink your FastText model in 90%)

In one experiment using a very large text database I got at the end of training using train_supervised()in FastText a serialized model with more than 1Gb.

This behavior occurs because the mechanics of FastText deals with all computation embedded in the model itself: label encoding, parsing, TF-IDF transformation, word-embeddings, calculate the WordNGrams using bag-of-tricks, fit, calculate probabilities and the re-application of the label encoding.

As you noticed in a corpus with more than 200.000 words and wordNGrams > 3this can escalate very quickly in terms of storage.

As I wrote before it’s really nice then we have a good model, but the real value comes when you put this model in production; and this productionize machine learning it’s a barrier that separates girls/boy from woman/man.

With a large storage and memory footprint it’s nearly impossible to make production-ready machine learning models, and in terms of high performance APIs large models with a huge memory footprint can be a big blocker in any decent ML Project.

To solve this kind of problem FastText provides a good way to compress the size of the model with little impact in performance. This is called port-training quantization.

The main idea of Quantization it’s to reduce the size of original model compressing the vectors of the embeddings using several techniques since simple truncation or hashing. Probably this paper (Shu, Raphael, and Hideki Nakayama. “Compressing word embeddings via deep compositional code learning.”) it’s one of the best references of this kind of technique.

This is the performance metric of one vanilla model with full model:Recall:0.79

I used the following command in Python for the quantization, model saving and reload:

# Quantize the model
model.quantize(input=None,
                  qout=False,
                  cutoff=0,
                  retrain=False,
                  epoch=None,
                  lr=None,
                  thread=None,
                  verbose=None,
                  dsub=2,
                  qnorm=False,
                 )

# Save Quantized model
model.save_model('model_quantized.bin')

# Model Quantized Load
model_quantized = fastText.load_model('model_quantized.bin')

I made the retraining using the quantized model and I got the following results:

# Training Time: 00:02:46
# Recall: 0.78

info_old_model = os.path.getsize('model.bin') / 1024.0
info_new_model = os.path.getsize('model_quantized.bin') / 1024.0

print(f'Old Model Size (MB): {round(info_old_model, 0)}')
print(f'New Model Size (MB): {round(info_new_model, 0)}')

# Old Model Size (MB): 1125236.0
# New Model Size (MB): 157190.0

As we can see after the shrink in the vanilla model using quantization we had the Recall: 0.78 against 0.79 with a model 9x lighter in terms of space and memory footprint if we need to put this model in production.

Post-training quantization in FastText (or How to shrink your FastText model in 90%)

Model explainability will be a security issue

Ben Lorica talks security in terms of Software Engineering but at least for me the most important aspect of security in Machine Learning in the future it’s the model explainability where he says:

Model explainability has become an important area of research in machine learning. Understanding why a model makes specific decisions is important for several reasons, not the least of which is that it makes people more comfortable with using machine learning. That “comfort” can be deceptive, of course. But being able to ask models why they made particular decisions will conceivably make it easier to see when they’ve been compromised. During development, explainability will make it possible to test how easy it is for an adversary to manipulate a model, in applications from image classification to credit scoring. In addition to knowing what a model does, explainability will tell us why, and help us build models that are more robust, less subject to manipulation; understanding why a model makes decisions should help us understand its limitations and weaknesses. At the same time, it’s conceivable that explainability will make it easier to discover weaknesses and attack vectors. If you want to poison the data flowing into a model, it can only help to know how the model responds to data.

This discussion it’s very important as we’re having here in Europe a huge government movement against lack of explainability in the way algorithms works and how automated decisions are made.

Model explainability will be a security issue

Some quick comments about Genevera Allen statements regarding Machine Learning

Start note: Favio Vazquez made a great job in his article about it with a lot of charts and showing that in modern Machine Learning approach with the tools that we currently have the problems of replication and methodology are being tackled.

It’s becoming a great trend: Some researcher has some criticism about Machine Learning and they start to do some cherry picking (fallacy of incomplete evidence) in potential issues start with statements like “We have a problem in Machine Learning and the results it’s not reproducible“, “Machine Learning doesn’t work“, “Artificial intelligence faces reproducibility crisis, “AI researchers allege that machine learning is alchemy and boom: we have click bait, rant, bashing and a never-ending spiral of non-construcive critcism. Afterward this researcher get some spotlights in public debate about Machine Learning, goes to CNN to give some interviews and becomes a “reference in issues in Machine Learning“.

Right now it’s time for Ms. Allen do the following question/statement “Can we trust scientific discoveries made using machine learning?” where she brings good arguments for the debate, but I think she misses the point to 1) not bring any solution/proposal and 2) the statement itself its too abroad and obvious that can be applied in any science field.

My main intention here it’s just to make very short comments to prove that these issues are very known by the Machine Learning community and we have several tools and methods to tackle these issues.

The second intention here it’s to demonstrate that this kind of very broad-obvious argument brings more friction than light to debate. I’ll include the statement and a short response below:

“The question is, ‘Can we really trust the discoveries that are currently being made using machine-learning techniques applied to large data sets?'” Allen said. “The answer in many situations is probably, ‘Not without checking,’ but work is underway on next-generation machine-learning systems that will assess the uncertainty and reproducibility of their predictions.”

Comment: More data do not imply in more insights and harder to have more data it’s to have the right combination of hyperparameters, feature engineering, and ensembling/stacking the models. And every scientific statement must be checked (this is a basic assumption of the scientific method). But this trend maybe cannot be a truth in modern research, as we are celebrating scientific statements (over selling) with the researchers intentionally hiding their methods and findings. It’s like Hans Bethe hiding his discoveries about stellar nucleosynthesis because in some point in the future someone can potentially use this to make atomic bombs.

“A lot of these techniques are designed to always make a prediction,” she said. “They never come back with ‘I don’t know,’ or ‘I didn’t discover anything,’ because they aren’t made to.”

Comment: This is simply not true. A very quick check in Scikit-Learn, XGBoost and Keras (3 of the most popular libraries of ML) shattered this argument.

“In precision medicine, it’s important to find groups of patients that have genomically similar profiles so you can develop drug therapies that are targeted to the specific genome for their disease,” Allen said. “People have applied machine learning to genomic data from clinical cohorts to find groups, or clusters, of patients with similar genomic profiles. “But there are cases where discoveries aren’t reproducible; the clusters discovered in one study are completely different than the clusters found in another,”

Comment: Here it’s the classic use of misleading experience with a clear use of confirmation bias because of a lack of understanding between tools with methodology . The ‘logic‘ of this argument is: A person wants to cut some vegetables to make a salad. This person uses a salad knife (the tool) but instead to use it accordingly (in the kitchen with a proper cutting board) this person cut the vegetables on the top of a stair after drink 2 bottles of vodka (the wrong method) and end up being cut; and after that this person get the conclusion that the knife is dangerous and doesn’t work.

There’s a bunch of guidelines being proposed and there’s several good resources like Machine Learning Mastery that already tackled this issue, this excellent post of Determined ML makes a good argument and this repo has tons of reproducible papers even using Deep Learning. The main point is: Any junior Machine Learning Engineer knows that hashing the dataset and fixing a seed at the beginning of the experiment can solve at least 90% of these problems.

Conclusion

There’s a lot of researches and journalists that cannot (or do not want to) understand that not only in Machine Learning but in all science there’s a huge problem of replication of the studies (this is not the case for Ms. Allen because she had a very interesting track record in ML in terms of publications). In psychology half of the studies cannot be replicated and even the medical findings in some instance are false that proves that is a very long road to minimize that kind of problem.

Some quick comments about Genevera Allen statements regarding Machine Learning

Ensemble machine learning and forecasting can achieve 99% uptime for rural handpumps

Abstract: Broken water pumps continue to impede efforts to deliver clean and economically-viable water to the global poor. The literature has demonstrated that customers’ health benefits and willingness to pay for clean water are best realized when clean water infrastructure performs extremely well (>99% uptime). In this paper, we used sensor data from 42 Afridev-brand handpumps observed for 14 months in western Kenya to demonstrate how sensors and supervised ensemble machine learning could be used to increase total fleet uptime from a best-practices baseline of about 70% to >99%. We accomplish this increase in uptime by forecasting pump failures and identifying existing failures very quickly. Comparing the costs of operating the pump per functional year over a lifetime of 10 years, we estimate that implementing this algorithm would save 7% on the levelized cost of water relative to a sensor-less scheduled maintenance program. Combined with a rigorous system for dispatching maintenance personnel, implementing this algorithm in a real-world program could significantly improve health outcomes and customers’ willingness to pay for water services.
Discussion: From a program viewpoint, implementers are primarily interested in increasing reliable and cost-effective water services. Fig 4 illustrates the trade-off between fleet uptime and dispatch responsiveness as a function of the number of model-initiated dispatches per pump-year. The figure is faceted by dispatch delays ranging from 1 to 21 days. There are two important insights visible in this figure. First, on a per-dispatch perspective, there is very little difference between current, forecast, and combined models. The current failure model typically performs slightly better on a per-dispatch basis (as a result of its higher positive predictive value). However, the most important difference in fleet uptime results from the implementing agency’s dispatch delay, and, to a lesser extent, the implementing agency’s capacity to perform many dispatches in a pump-year. The goal of 99% fleet uptime could be achieved with our machine learning model using just 2 dispatches per pump-year paired with a 1-day dispatch delay, or 22 dispatches per pump-year with a 7-day dispatch delay.
The marginal cost of implementing sensors, machine learning, and preventative maintenance activity are spread over the total utility that the equipment (a handpump in this case), delivers to customers over its lifetime. For this reason, there would be an even greater per-dollar benefit from implementing a sensor and machine learning-enabled preventative maintenance program on larger commercial assets such as motorized borehole pumping stations. While the cost of sensors and algorithms would not be significantly changed, the total benefit delivered to customers per functional pump-year would be greatly increased because of the larger pumping capacity of these stations.
In conclusion, the highly non-linear relationship between pump performance and health & economic outcomes illustrates that pumps need to perform extremely well before their benefits to society can be realized. This non-linear relationship also suggests that there is more consumer surplus to be gained by improving the function of existing pumps rather than building ever more new pumps that function only marginally well. This study has demonstrated that a machine-learning-enabled preventative maintenance model has the potential to enable fleets of handpumps that function extremely well by driving total fleet uptime to >99%, thus providing a realistic path forward towards reliable and sustained clean water delivery.
Ensemble machine learning and forecasting can achieve 99% uptime for rural handpumps

Machine Learning Methods to Predict Diabetes Complications

Abstract: One of the areas where Artificial Intelligence is having more impact is machine learning, which develops algorithms able to learn patterns and decision rules from data. Machine learning algorithms have been embedded into data mining pipelines, which can combine them with classical statistical strategies, to extract knowledge from data. Within the EU-funded MOSAIC project, a data mining pipeline has been used to derive a set of predictive models of type 2 diabetes mellitus (T2DM) complications based on electronic health record data of nearly one thousand patients. Such pipeline comprises clinical center profiling, predictive model targeting, predictive model construction and model validation. After having dealt with missing data by means of random forest (RF) and having applied suitable strategies to handle class imbalance, we have used Logistic Regression with stepwise feature selection to predict the onset of retinopathy, neuropathy, or nephropathy, at different time scenarios, at 3, 5, and 7 years from the first visit at the Hospital Center for Diabetes (not from the diagnosis). Considered variables are gender, age, time from diagnosis, body mass index (BMI), glycated hemoglobin (HbA1c), hypertension, and smoking habit. Final models, tailored in accordance with the complications, provided an accuracy up to 0.838. Different variables were selected for each complication and time scenario, leading to specialized models easy to translate to the clinical practice.
Conclusions: This work shows how data mining and computational methods can be effectively adopted in clinical medicine to derive models that use patient-specific information to predict an outcome of interest. Predictive data mining methods may be applied to the construction of decision models for procedures such as prognosis, diagnosis and treatment planning, which—once evaluated and verified—may be embedded within clinical information systems. Developing predictive models for the onset of chronic microvascular complications in patients suffering from T2DM could contribute to evaluating the relation between exposure to individual factors and the risk of onset of a specific complication, to stratifying the patients’ population in a medical center with respect to this risk, and to developing tools for the support of clinical informed decisions in patients’ treatment.
Machine Learning Methods to Predict Diabetes Complications

Predicting Risk of Suicide Attempts Over Time Through Machine Learning

Abstract: Traditional approaches to the prediction of suicide attempts have limited the accuracy and scale of risk detection for these dangerous behaviors. We sought to overcome these limitations by applying machine learning to electronic health records within a large medical database. Participants were 5,167 adult patients with a claim code for self-injury (i.e., ICD-9, E95x); expert review of records determined that 3,250 patients made a suicide attempt (i.e., cases), and 1,917 patients engaged in self-injury that was nonsuicidal, accidental, or nonverifiable (i.e., controls). We developed machine learning algorithms that accurately predicted future suicide attempts (AUC = 0.84, precision = 0.79, recall = 0.95, Brier score = 0.14). Moreover, accuracy improved from 720 days to 7 days before the suicide attempt, and predictor importance shifted across time. These findings represent a step toward accurate and scalable risk detection and provide insight into how suicide attempt risk shifts over time.
Discussion: Accurate and scalable methods of suicide attempt risk detection are an important part of efforts to reduce these behaviors on a large scale. In an effort to contribute to the development of one such method, we applied ML to EHR data. Our major findings included the following: (a) this method produced more accurate prediction of suicide attempts than traditional methods (e.g., ML produced AUCs in the 0.80s, traditional regression in the 0.50s and 0.60s, which also demonstrated wider confidence intervals/greater variance than the ML approach), with notable lead time (up to 2 years) prior to attempts; (b) model performance steadily improved as the suicide attempt become more imminent; (c) model performance was similar for single and repeat attempters; and (d) predictor importance within algorithms shifted over time. Here, we discuss each of these findings in more detail. ML models performed with acceptable accuracy using structured EHR data mapped to known clinical terminologies like CMS-HCC and ATC, Level 5. Recent metaanalyses indicate that traditional suicide risk detection approaches produce near-chance accuracy (Franklin et al., 2017), and a traditional method—multiple logistic regression—produced similarly poor accuracy in the present study. ML to predict suicide attempts obtained greater discriminative accuracy than typically obtained with traditional approaches like logistic regression (i.e., AUC = 0.76; Kessler, Stein, et al., 2016). The present study extends this pioneering work with its use of a larger comparison group of self-injurers without suicidal intent, ability to display a temporally variant risk profile over time, scalability of this approach to any EHR data adhering to accepted clinical data standards, and performance in terms of discriminative accuracy (AUC = 0.84, 95% CI [0.83, 0.85]), precision recall, and calibration (see Table 1). This approach can be readily applied within large medical databases to provide constantly updating risk assessments for millions of patients based on an outcome derived from expert review. Although short-term risk and shifts in risk over time are often noted in clinical lore, risk guidelines, and suicide theories (e.g., O’Connor, 2011; Rudd et  al., 2006; Wenzel & Beck, 2008), few studies have directly investigated these issues. The present study examined risk at several intervals from 720 to 7 days and found that model performance improved as suicide attempts became more imminent. This finding was consistent with hypotheses; however, two aspects of the present study should be considered when interpreting this finding. First, this pattern was confounded by the fact that more data were available naturally over time; predictive modeling efforts at point of care should take advantage of this fact to improve model performance as additional data are collected. Second, due to the limitations of EHR data, we were unable to directly integrate information about potential precipitating events (e.g., job loss) or data not recorded in routine clinical care into the present models. Such information may have further improved short-term prediction of suicide attempts. Future studies should build on the present findings to further elucidate how risk changes as suicide attempts become more imminent.
Predicting Risk of Suicide Attempts Over Time Through Machine Learning

Intelligent Movie Recommender System Using Machine Learning

purpose of suggesting items to view or purchase. The Intelligent movie recommender
system that is proposed combines the concept of Human-Computer
Interaction and Machine Learning. The proposed system is a subclass of
information filtering system that captures facial feature points as well as emotions
of a viewer and suggests them movies accordingly. It recommends movies
best suited for users as per their age and gender and also as per the genres they
prefer to watch. The recommended movie list is created by the cumulative effect
of ratings and reviews given by previous users. A neural network is trained to
detect genres of movies like horror, comedy based on the emotions of the user
watching the trailer. Thus, proposed system is intelligent as well as secure as a
user is verified by comparing his face at the time of login with one stored at the
time of registration. The system is implemented by a fully dynamic interface i.e.
a website that recommends movies to the user [22].
Conclusion and Future Work
Learning method for training data as well as sentiment analysis on reviews. The system
facilitates a web-based user interface i.e. a website that has a user database and has a
Learning model tailored to each user. This interface is dynamic and updates regularly.
Afterward, it tags a movie with genres to which they belong based on expressions of
users watching the trailer. The major problem arises with this technique is when the
viewer gives neutral face expressions while watching a movie. In this case the system is
unable to determine the genre of the movie accurately. The recommendations are
refined with the help of reviews and rating taken by the users who have watched that
movie.
A user is allowed to create a single account, and only he can log in from his account
as we verify face every time. The accuracy of the proposed recommendation system
can be improved by adding more analysis factor to user behavior. Location or mood of
the user, special occasions in the year like festivals can also be taken into consideration
to recommend movies. In further updates text summarization on reviews can be
implemented which summaries user comment into single line will comments. Review
Authenticity can be applied to the system to prevent fake and misguiding reviews. Only
genuine reviews would be considered for evaluation of movie rating. In future, the
system can be used with nearby cinema halls to book movie tickets online through our
website [22]. Our approach can be extended to various application domains to
recommend music, books, etc.
Intelligent Movie Recommender System Using Machine Learning

Prediction of oxygen uptake dynamics by machine learning analysis of wearable sensors during activities of daily living

Abstract: Currently, oxygen uptake () is the most precise means of investigating aerobic fitness and level of physical activity; however, can only be directly measured in supervised conditions. With the advancement of new wearable sensor technologies and data processing approaches, it is possible to accurately infer work rate and predict during activities of daily living (ADL). The main objective of this study was to develop and verify the methods required to predict and investigate the  dynamics during ADL. The variables derived from the wearable sensors were used to create a  predictor based on a random forest method. The  temporal dynamics were assessed by the mean normalized gain amplitude (MNG) obtained from frequency domain analysis. The MNG provides a means to assess aerobic fitness. The predicted  during ADL was strongly correlated (r = 0.87, P < 0.001) with the measured  and the prediction bias was 0.2 ml·min−1·kg−1. The MNG calculated based on predicted  was strongly correlated (r = 0.71, P < 0.001) with MNG calculated based on measured  data. This new technology provides an important advance in ambulatory and continuous assessment of aerobic fitness with potential for future applications such as the early detection of deterioration of physical health.

 

Prediction of oxygen uptake dynamics by machine learning analysis of wearable sensors during activities of daily living

A machine learning approach to integrate big data for precision medicine in acute myeloid leukemia

From Nature

Abstract: Cancers that appear pathologically similar often respond differently to the same drug regimens. Methods to better match patients to drugs are in high demand. We demonstrate a promising approach to identify robust molecular markers for targeted treatment of acute myeloid leukemia (AML) by introducing: data from 30 AML patients including genome-wide gene expression profiles and in vitro sensitivity to 160 chemotherapy drugs, a computational method to identify reliable gene expression markers for drug sensitivity by incorporating multi-omic prior information relevant to each gene’s potential to drive cancer. We show that our method outperforms several state-of-the-art approaches in identifying molecular markers replicated in validation data and predicting drug sensitivity accurately. Finally, we identify SMARCA4 as a marker and driver of sensitivity to topoisomerase II inhibitors, mitoxantrone, and etoposide, in AML by showing that cell lines transduced to have high SMARCA4 expression reveal dramatically increased sensitivity to these agents.

Discussion: Due to the small sample size and the potential confounding factors in the gene expression and the drug sensitivity data, standard methods to discover gene-drug associations usually fail to identify replicable signals. We present a new way to identify robust gene-drug associations by prioritizing genes based on the multi-dimensional information on each gene’s potential to drive cancer. We demonstrate that our method increases the chance that the identified gene-drug associations are replicated in validation data. This leads us to a short list of genes which are all attractive biomarkers for different classes of drugs. Our results—including the expression, drug sensitivity data, and association statistics from patient samples—have been made freely available to academic communities.

Our results suggest that high SMARCA4 expression could be a molecular marker for sensitivity to topoisomerase II inhibitors in AML cells. These results offer a potentially enormous impact to improve patient response. Mitoxantrone is an anthracycline, like daunorubicin or idarubicin, and one of the two component classes of drugs included in nearly all upfront AML treatment regimens. It is also included (the “M”) in the CLAG-M regimen55, a triple-drug component upfront regimen now being studied as GCLAM56. Mitoxantrone and etoposide (also a topoisomerase II inhibitor) are two of the three drugs in the MEC regimen57, used together with cytarabine, as a common regimen for relapsed/refractory AML. Many modern regimens are in clinical trials that add an investigational drug to the MEC backbone, for example, an antibody to CXCR4 (NCT01120457) or an E selectin inhibitor (NCT02306291) in combination, or decitabine priming preceding the MEC regimen58. Identifying a predictor of response to mitoxantrone based on clinically available biospecimens, such as leukemic blast gene expression measured prior to treatment, could potentially increase median survival rates for patients with high expression of SMARCA4 and indicate alternative therapies for patients with low SMARCA4 expression.

The AML patients used in our study were consecutively enrolled on a protocol to obtain laboratory samples for research. They were selected solely based on sufficient leukemia cell numbers. As the patient samples were consecutively obtained and not selected for any specific attribute, we postulated that they were representative of patients seen at a tertiary referral center and that the results would be relevant to a larger, more general clinical population. Moreover, since each of the data sets from which we collected prior information (driver features) contained many more than 30 samples (e.g., TCGA AML data), it would be highly likely that MERGE results would be more generalizable to larger clinical populations than the methods that retrieve results specifically based on the 30 AML samples. In fact, Fig. 2a, b implies higher generalizability of MERGE compared to alternative methods.

While we have genotype information on FLT3 and NPM1 and the cytogenetic risk category for most of the 30 patients, the current version of the MERGE framework did not take these features into account: our main focus sought to build a general framework that could address the high-dimensionality challenge (i.e., the number of samples being much smaller than the number of genes) and make efficient use of expression data to identify robust associations. However, to consolidate our findings, we performed a covariate analysis to confirm that the top-ranked gene-drug associations discovered by MERGE remained significant when the risk group/cytogenetic features were considered in the association analysis. We checked whether the gene-drug associations shown in the heat map in Fig. 6b (highlighted as red or green) were conserved when we added each of the following as an additional covariate to the linear model: (1) cytogenetic risk, (2) FLT3 mutation status, and (3) NPM1 mutation status. In Supplementary Fig. 9, each dot corresponds to a gene-drug pair, and each color to a different covariate. Most of the dots being closer to the diagonal indicates that the associations did not decrease significantly after adding the covariates. Moreover, of 357 dots, only eight were below the horizontal red line; this indicates that 98% of the gene-drug associations MERGE uncovered were still significant (p ≤ 0.05) after modeling the covariate.

A machine learning approach to integrate big data for precision medicine in acute myeloid leukemia

Comparison of Machine Learning Approaches for Prediction of Advanced Liver Fibrosis in Chronic Hepatitis C Patients.

BACKGROUND/AIM:
Using machine learning approaches as non-invasive methods have been used recently as an alternative method in staging chronic liver diseases for avoiding the drawbacks of biopsy. This study aims to evaluate different machine learning techniques in prediction of advanced fibrosis by combining the serum bio-markers and clinical information to develop the classification models.

METHODS:
A prospective cohort of 39,567 patients with chronic hepatitis C was divided into two sets – one categorized as mild to moderate fibrosis (F0-F2), and the other categorized as advanced fibrosis (F3-F4) according to METAVIR score. Decision tree, genetic algorithm, particle swarm optimization, and multilinear regression models for advanced fibrosis risk prediction were developed. Receiver operating characteristic curve analysis was performed to evaluate the performance of the proposed models.

RESULTS:
Age, platelet count, AST, and albumin were found to be statistically significant to advanced fibrosis. The machine learning algorithms under study were able to predict advanced fibrosis in patients with HCC with AUROC ranging between 0.73 and 0.76 and accuracy between 66.3% and 84.4%.

CONCLUSIONS:
Machine-learning approaches could be used as alternative methods in prediction of the risk of advanced liver fibrosis due to chronic hepatitis C.

Comparison of Machine Learning Approaches for Prediction of Advanced Liver Fibrosis in Chronic Hepatitis C Patients.

A Machine Learning Approach Using Survival Statistics to Predict Graft Survival in Kidney Transplant Recipients: A Multicenter Cohort Study.

Abstract: Accurate prediction of graft survival after kidney transplant is limited by the complexity and heterogeneity of risk factors influencing allograft survival. In this study, we applied machine learning methods, in combination with survival statistics, to build new prediction models of graft survival that included immunological factors, as well as known recipient and donor variables. Graft survival was estimated from a retrospective analysis of the data from a multicenter cohort of 3,117 kidney transplant recipients. We evaluated the predictive power of ensemble learning algorithms (survival decision tree, bagging, random forest, and ridge and lasso) and compared outcomes to those of conventional models (decision tree and Cox regression). Using a conventional decision tree model, the 3-month serum creatinine level post-transplant (cut-off, 1.65 mg/dl) predicted a graft failure rate of 77.8% (index of concordance, 0.71). Using a survival decision tree model increased the index of concordance to 0.80, with the episode of acute rejection during the first year post-transplant being associated with a 4.27-fold increase in the risk of graft failure. Our study revealed that early acute rejection in the first year is associated with a substantially increased risk of graft failure. Machine learning methods may provide versatile and feasible tools for forecasting graft survival.
A Machine Learning Approach Using Survival Statistics to Predict Graft Survival in Kidney Transplant Recipients: A Multicenter Cohort Study.