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:

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:

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:

Applied Machine Learning at Facebook: A Datacenter Infrastructure Perspective

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.