Parte 2: Linhas orientadoras para transformar uma PoC num produto de IA
Na primeira parte deste artigo, analisámos os diferentes tipos de projetos de ciência de dados que existem e como estes são fundamentalmente distintos. Nesta parte, fiamo-nos no tipo mais interessante de projeto de ciência de dados: aquele que se transforma numa solução ou num produto de IA. Mas como se explicam os esforços necessários para construir um produto de IA? Afinal de contas, não é mais ou menos o mesmo que uma PoC?
O carro conceptual num salão automóvel internacional
Gosto de pensar nas PoCs de ciência de dados de forma semelhante aos carros em exposição num salão automóvel internacional. O carro está em cima da plataforma giratória. É bonito, é brilhante, desperta interesse, dá uma amostra do que é viável e está ali para impressionar os potenciais clientes.
No entanto, o carro também foi construído especificamente para a exposição. Pode ser pesado demais, é certamente demasiado dispendioso para ser produzido da mesma forma, algumas peças são impressões 3D personalizadas e pode ser desajeitado ou não cumprir todas as normas de segurança exigidas. Poderá até avariar a cada 300 km.
Aqui está a tradução para português do restante artigo, mantendo o tom profissional e a estrutura clara:
O desafio de transformar “o carro em exposição num produto” significa dar resposta a estas questões. Como podemos estruturar fábricas para construir estes carros? Como produzimos as peças de forma robusta e eficiente? Existirá uma estratégia de plataforma modular a partir da qual este carro possa ser adaptado? Como será a distribuição de peças de substituição e de que formação precisam os mecânicos para poderem fazer a manutenção deste veículo? Afinal de contas, o cliente procura um carro com “zero tempo de inatividade” e que exija “baixa manutenção”. Considerações semelhantes aplicam-se aos projetos de ciência de dados.
De PoC a Produto de IA
Há uma quantidade considerável de trabalho a ser feito para transformar uma prova de conceito num produto de IA completo. Abaixo, reuni uma lista não exaustiva de aspetos que precisa de ter sob o seu radar. Esta lista pode não estar completa, mas todos os elementos são fatores-chave para superar com sucesso a lacuna entre a PoC e o produto.
1. Construa a pensar no ambiente de produção – não no seu computador portátil
Sob o falso pretexto de não perder tempo e porque “é mais fácil”, os cientistas de dados começam a desenvolver os modelos nos seus computadores portáteis. Embora concordemos que este é o local lógico para começar, é fundamental ir além dos ambientes locais e, desde cedo, construir a pensar no ambiente final de produção. Isto reduzirá o número de surpresas mais tarde e ajudará também na escalabilidade.
2. Pipelines de dados robustas
Afinal de contas, chama-se “ciência de dados”. Os dados são o novo petróleo e precisam de ser precisos e fluir corretamente. É por isso que é de suma importância que a equipa de ciência de dados tenha acesso aos dados certos (e em quantidade suficiente) desde muito cedo. Ter as pipelines de engenharia de dados devidamente configuradas é importante para a automação. Mas os dados não devem apenas fluir continuamente; devem também ser recolhidos onde fizer mais sentido.
3. Recolha dados de feedback
Desde o início, a recolha de dados de feedback deve ser acautelada. Isto pode ser tão simples como um polegar para cima ou para baixo por parte do utilizador para indicar se a previsão foi boa. Ao criar continuamente novos dados rotulados (labeled data), garantimos que o retorno de informação é possível e que o reajuste dos modelos pode acontecer. Este conselho é fundamental para qualquer empresa que queira seriamente tornar-se totalmente digital.
4. A manutenção dos modelos deve ser contínua
O MLOps (Machine Learning Operations) visa encurtar o ciclo de vida do desenvolvimento analítico e aumentar a estabilidade dos modelos através da automação de passos repetíveis nos fluxos de trabalho. Normalmente, um modelo está otimizado para o momento exato em que entra em produção. A partir desse instante, o mundo ao redor muda e os dados começam a divergir daquilo sobre o qual o modelo foi inicialmente construído. Se o modelo não for alimentado com novos dados brutos ou de feedback, o seu desempenho irá diminuir com o tempo. É por isso que é importante recolher métricas sobre o desempenho do modelo e fazer com que o seu reajuste faça parte das atividades de manutenção.
5. Implementar IA à escala
A implementação de IA à escala é um dos desafios mais importantes na construção de um produto de IA. Por um lado, existem os desafios técnicos de treinar os modelos num ecossistema de dados cada vez maior e em constante mutação. Aqui, a computação na nuvem pode ajudar a ultrapassar os estrangulamentos do poder de processamento ao introduzir a elasticidade necessária. Mas, obviamente, isto acarreta um custo de computação, pelo que encontrar o equilíbrio certo entre o custo e a frequência de reajuste é fundamental.
Por outro lado, existem também desafios organizacionais: assim que as implementações se tornam maiores, mais pessoas na organização ficam ocupadas a monitorizar os componentes e as métricas, já que a probabilidade de falhas aumenta. Diferentes modelos precisam de ser empacotados e podem coexistir em produção. É necessário planear cenários de contingência (fallback), pois há mais coisas que podem correr mal — e o impacto será maior. Aqui, a automação é a chave para garantir a repetibilidade das implementações, bem como a estabilidade do sistema e dos modelos.
6. Documentação
A maioria dos programadores não gosta de escrever documentação — mas todos gostam de a ler. É óbvio que a documentação é um aspeto essencial de qualquer produto (de IA) e precisa de ser mantida atualizada. A documentação deve incluir informações sobre as APIs para aceder ao modelo, mas também documentação interna sobre como funcionam aspetos específicos do mesmo. Por último, mas não menos importante, deve também explicar, como uma espécie de guia do utilizador, de que forma as pessoas não técnicas podem utilizar o produto de IA.
7. Ética e vieses na IA
Os sistemas de IA não estão isentos de tomar decisões injustas e, por vezes, isso traz consequências graves. Hoje em dia, os modelos de IA decidem se obtemos um empréstimo, uma bolsa de estudo, um emprego, se podemos viajar ou se somos detidos. Enquanto a investigação se foca muito no uso indevido intencional da IA, as consequências de uma utilização não intencional podem ser igualmente prejudiciais.
Embora possa ser impossível livrar os sistemas de IA do viés humano, é crucial ter cautela para minimizar os seus efeitos. Isto pode ser feito através de uma seleção cuidadosa dos dados de treino, de uma monitorização rigorosa, de uma governação contínua dos dados e de uma amostra populacional diversa que cubra um amplo espetro de inputs e ofereça uma representação justa das nossas estruturas sociais. É por isso que é importante compreender a equidade dos seus modelos e monitorizar de perto os vieses ao longo do tempo nos seus produtos de IA.
Conclusão
Neste artigo, partilhei a minha visão sobre como distingo os três principais tipos de projetos de ciência de dados. Foquei-me depois no tipo de solução e produto de IA, aprofundando a forma de explicar a gestores seniores e decisores o que é necessário para passar de uma simples PoC para uma solução ou produto de IA produtivo.
Como principal conclusão, gostaria de realçar que, ao termos em mente bons processos e o stack tecnológico correto, a transição entre a PoC e os produtos de IA produtivos pode ser feita de forma previsível e robusta. Escusado será dizer que as competências certas são fundamentais. Integrar engenheiros de dados e de software no processo desde o início pode ajudar a transformar os modelos de ciência de dados em artefactos geridos e fáceis de implementar que funcionam à escala.
