Accountability, Core Machine Learning e Machine Learning Operations

2020 Mar 29

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.
Se antigamente a televisão empurrava todo o tipo de programação, não importando o quão degradante fosse; hoje os algoritmos da indústria do entretenimento são obrigados a levar em consideração um maior nível de qualidade, sob pena de escrutínio negativo pela opinião pública e mídia.
Se no passado os artistas menos populares eram reféns do famoso Jabá (i.e. tocar nas rádios mediante a pagamento) em um cenário em que somente os artistas com grandes empresários tinham preferência; hoje as plataformas de streaming não somente lidam com um mercado musical mais diverso com estão começando a levar em consideração a relevância para o usuário ao mesmo tempo em que tentam promover a equidade entre os artistas dentro da plataforma.
No passado se precisávamos realizar testes de retinopatia diabética em que dependíamos de apenas do médico - que é um ser falível como qualquer um outro -; hoje temos sistemas auxiliares que podem prover uma segunda opinião, e dar uma chance de revisão em casos de subdiagnóstico.
Se em tempos atrás dependíamos exclusivamente de sistemas jurídicos que poderiam ter inúmeros vieses em que o destino de alguém depender do bom humor de agentes do estado; hoje disciplinas como equidade e transparência já estão ajudando a minimizar estes vieses no setor jurídico e conseguem proporcionar um julgamento mais justo, auditável e principalmente mais célere.

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:

Será que a sua empresa teria o porte de resistir a um escrutínio da imprensa devido a um experimento inocente dos times de produto e de Data Science que por ventura teria manipulado intencionalmente quase 700 mil usuários? Experimento este que talvez tenha quebrado protocolos de ética médica?
Será que a sua empresa conseguiria passar por uma campanha de escrutínio público devido a uma campanha de marketing que o time de Data Science fez um modelo preditivo para recomendar artigos via correio para potenciais grávidas sendo que algumas delas nem sabiam que estavam grávidas, ou mesmo sequer compartilharam essa informação?
O que aconteceria se o algoritmo de credit scoring desenvolvido por você colocasse a sua empresa em uma situação de ter que se defender de um viés de discriminação de gênero nas redes sociais? Como, por exemplo, neste caso que já tem mais de 28 mil curtidas no Twitter.
Será que o seu atual empregador estaria preparado para perder 99% de valor de mercado em 6 meses, e mais uma multa de 12 milhões de dólares devido a um Glue Code que foi colocado em produção por conta de débito técnico em versionamento e revisão de código?

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:

Google: PageRank é um algoritmo que nasceu originalmente de uma dissertação de mestrado e que posteriormente virou o core business da Google;
Spotify: O Discovery Weekly é um bom exemplo de uma feature de Machine Learning que acabou virando um produto dentro da plataforma;
Netflix: Desnecessário dizer que recomendação, personalização e busca é o nome do jogo pra eles;
Uber: A gigante do serviço de mobilidade usa uma mistura de métodos clássicos e Deep Learning para fazer planejamento e previsão de seu marketplace;
Facebook: Grande parte da receita tem origem nos leilões de publicidade dentro da plataforma. A arbitragem dos leilões usa um pouco de Machine Learning como podemos ver nessa ótima talk do Eric Sodomka chamada “On How Machine Learning and Auction Theory Power Facebook Advertising”;
iFood: A gigante do food delivery brasileiro usa um sistema híbrido com regras e machine learning em um dos processos mais sensíveis da plataforma que é o combate às fraudes;
OLX: A anteriormente inocente plataforma de classificados hoje tem parte do seu negócio usando machine learning de forma massiva em seus sistemas de recomendação e matching;
Movile: Grande parte do fluxo de receita da Movile no passado era sustentado por um sistema de machine learning que fazia o trabalho de monitoramento e alarmística usando classificação em séries temporais; e
Quinto Andar: Se para alguns a plataforma é apenas um site de classificados de imóveis, nos bastidores existem sistemas de machine learning que ajudam parte dos clientes encontrem o seu próximo lar.

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

Existe isolamento e encapsulamento dos códigos que geraram os modelos? Se algo mudar em um dos componentes, qual será impacto no desempenho do modelo de produção? (e.g. extração de dados, análise de distribuição das variáveis, treinamento do modelo, experimentação com os hiperparâmetros, deployment do modelo e da API, etc.).
Imaginando que o seu time fez uma biblioteca interna de NLP que usa um conjunto de stopwords e stemming específicos, modificações nestes componentes podem potencialmente gerar um efeito cascata negativo no desempenho de outros modelos?[3]
Em uma de suas APIs você notou que houve um aumento no volume de requisições. O motivo: um outro time estava batendo na API de produção com assinatura de uma aplicação cliente para fazer um inocente “heartbeat”. Identificado este problema, como realizar a separação dos dados reais e das chamadas inválidas na API para o posterior retreino do modelo?[3]

Dependências de dados custam mais do que dependências de código

Você colocou em produção um ensemble de modelos em uma arquitetura do tipo Local Classifier per Parent Node. O seu ensemble depende de uma ontologia das classes para uma tarefa de classificação de textos. O que pode acontecer com a performance do seu modelo se o time de negócios mudar essa ontologia?

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

Por algum motivo do passado alguém fez um fork do Tidyverse e colocou no core da plataforma de ML. Contudo, você descobre que o Tidyverse tem licença GPLv3 e agora você vai ter que encher a sua aplicação de Glue Code para descaracterizar esta licença para não gerar um passivo financeiro para a sua empresa, ou pior: ter que obedecer a obrigatoriedade de abrir todo o código fonte desta parte da aplicação.
Um pipeline jungle seria algo parecido com o seguinte cenário: (a) extração de dados ocorrendo via um SQL dentro de bash script que está armazenado em um CRON job sem nenhum tipo de orquestração, monitoramento e controle de versão, (b) que posteriormente manda esses dados para o S3 de produção em que, (c) estes dados puros são processados por um Zeppelin notebook totalmente em Scala (que não tem controle de versão) que posteriormente (d) realiza o pré-processamento e (e) por fim faz um dump desses dados em um outro diretório do S3 na conta de… Staging? [3].
O processo de code review conseguiria identificar um aumento de complexidade ciclomática devido o aumento do glue code que tornou praticamente impossível colocar o modelo em produção? [3]
O seu processo de code review conseguiria pegar problemas de data leakage básicos, como o não uso de Pipelines para Cross-Validation no Scikit-Learn?
Digamos que o cientista de dados colocou o Scikit-Learn como dependência apenas para calcular o RMSE, ao invés de escrever uma função em numpy sozinho já resolveria a coisa toda. O seu code review pegaria este débito de abstração?
No passado o time de Core Machine Learning tinha uma preferência muito grande por Java. Isso levou à uma escolha de uma biblioteca de Machine Learning quase morta em produção. Como seria a integração de novos engenheiros de ML e das novas tecnologias (e.g. PyTorch, Keras, Scikit-Learn, MLExtend, etc.) dado que essa antiga plataforma carrega inúmeros de problemas subjacentes (e.g. Common Smells, custo de transferência de conhecimento, reescrita de código etc.)?[3]

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:

Débito de teste dos dados, pela falta de um filebeat;
Débito de reprodutibilidade. Exemplo: a utilização de uma biblioteca que, por design, não permite colocar uma semente randômica que garanta a reprodutibilidade dos experimentos. [3]
Débito de processo, como os recorrentes problemas entre os times de produtos e ML devido à utilização de frameworks de gerenciamento de projetos que não levam em consideração as especificidades dos times de dados (aqui tem um bom exemplo de como isso pode ser feito de maneira satisfatória)
Débito cultural, que acontece quando as vezes temos conflitos em princípios básicos de engenharia, como, por exemplo, reprodutibilidade, pragmatismo, simplicidade no desenvolvimento das plataformas e modelos, observabilidade, e controlabilidade. [3]

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.