Medindo a qualidade de entregas envolvendo IA

Cada vez mais a aplicação de modelos com inteligência artificial têm se tornado commodity e aparece com mais frequência permeando soluções em diversos setores. Seja pelo uso de um AutoML ou pelo desenvolvimento de um modelo de machine learning (ML) in-house, as soluções que utilizam essas técnicas de inteligência artificial (IA) estão sujeitas a falhas como qualquer produto de software normal, ainda mais caso sejam mal projetadas e confeccionadas.

Aqui no PicPay levamos bastante a sério a segurança, qualidade e estabilidade das nossas soluções, com isso definimos um guia de boas práticas para o desenvolvimento de modelos de IA orientado por um Definition of Done (DoD). Diferente do Definition of Ready (DoR) que disponibilizamos no artigo anterior da série, o DoD possui tópicos e requisitos necessários para que possamos definir uma entrega como feita. Não necessariamente estamos falando sobre um produto estar concluído (até porque isso nem existe né?), mas sim de uma fase de um projeto, seja ela um MVP ou uma primeira versão estável.

Neste DoD levamos em conta alguns pilares, que são como dimensões e podem ser avaliados separadamente. O conjunto desses pilares sinalizam o quanto uma entrega está boa e quais os débitos técnicos que devem ser corrigidos em outras oportunidades. Os pilares são os seguintes:

• Ambientes;
• Versionamento;
• Cobertura de Teste;
• Projeção de Performance;
• Explicabilidade;
• Testes de Performance;
• Monitoramento.

Hoje, já temos aqui dentro muita coisa pronta levando em consideração esses pilares. Já estamos com aplicações em Busca, Recomendação, Fraude, Crédito, Growth, Atendimento, entre outras. A seguir vamos explicar um pouquinho mais sobre cada um dos pilares.

Ambientes

Photo by Noah Buscher on Unsplash

Aqui no PicPay utilizamos alguns ambientes para produzir os modelos de ML. Temos os ambientes de Desenvolvimento, QA e Produção. Cada um deles é composto por aplicações diversas em clusters Kubernetes, e dados processados nos clusters Databricks e salvos na AWS.

O ambiente de Desenvolvimento deve estar com o modelo em um formato simples de reproduzir, de ser compartilhado e recriado (infra as code). Ele é usado para todo o desenvolvimento do modelo e primeiros testes. Tudo aqui deve ser pensado em como melhorar a reprodutibilidade e em como alcançar os objetivos propostos inicialmente.

Em QA, temos um cenário similar ao de produção, que aumenta a confiança e permite que as integrações e dados do modelo funcionem perfeitamente. Esse ambiente é importante para validarmos a qualidade dos modelos, principalmente os que possam ter grande impacto em Produção.

Produção deve ser o passo final do modelo com os devidos requisitos de qualidade já desenvolvidos e monitorados. Aqui, vamos validar hipóteses com populações menores para minimizar o impacto.

Como boas práticas os pipelines e modelos de ML desenvolvidos, são testados em Desenvolvimento e em QA antes da passagem para Produção.

Versionamento

Quando a gente pensa no pilar de versionamento precisamos nos preocupar com mais do que somente código para entregas envolvendo ML. As entregas são compostas por:

• Sim, um código ou alguma espécie de configuração para AutoML;
• Um artefato binário de modelo gerado pelo código;
• Os dados (features) utilizados por aquele modelo, seja para treino ou predição;
• As métricas daquele modelo para conseguirmos comparar com outras versões.

Uma vez que temos o versionamento de cada uma dessas entregas, precisamos conseguir vincular a versão do código com a versão dos dados usados e a versão do modelo binário gerado. Com esse vínculo conseguimos reprodutibilidade de todas as partes, inclusive se o binário do modelo ficar corrompido. 😢

Aqui no PicPay, utilizamos Git (tags) e MLflow para ajudar com esse versionamento e vínculos, mas existem várias ferramentas hoje que podem te ajudar com isso, como o DVC.

Cobertura de Teste

Como qualquer artefato de software, qualquer aplicação com AI, tal qual um modelo de ML, precisa de testes automatizados que garantam sua qualidade e estabilidade. O básico de testes que usamos por aqui são os testes unitários. Testamos isoladamente cada parte do código para garantir que cada unidade esteja funcionando adequadamente.

Dado que "unitariamente" (se é que isso existe), consegue garantir a qualidade de cada parte do código, como a parte de tratamento de features e confecção do modelo e, também precisamos validar "metamorficamente" se o modelo tem o comportamento esperado. Pelo menos um teste metamórfico é interessante para validar a estabilidade do modelo. Um teste metamórfico é como um teste caixa preta em que você sabe que ao dar um determinado grupo de features para o modelo, ele vai retornar a tendência esperada. Por exemplo, podemos testar em um modelo de aprovação de crédito se quando colocamos a variável renda_mensal similar a do Neymar o crédito será aprovado.💰

Photo by Gustavo Ferreira on Unsplash

Além dos testes unitários e metamórficos, prezamos também por pelo menos um teste end-to-end validando o fluxo completo do modelo, desde do tratamento de features até a predição no ambiente de QA.

Falando em testes, também é uma boa prática fazer validações estatísticas no resultado do modelo para identificar, por exemplo, se a distribuição estatística obtida no resultado é a esperada. Como exemplo, para um modelo de detecção de fraude, é esperado que existam menos fraudadores do que idôneos na sua população aleatória (ou sua empresa está com sérios problemas 😅).

Todos esses testes são incorporados dentro de um fluxo de CI (Continuous Integration), que garante que os testes sejam executados e dá visibilidade da qualidade e sua cobertura. Existem várias ferramentas que proporcionam um fluxo de CI, aqui usamos o Drone integrado ao Sonar. O Sonar nos ajuda a saber a qualidade daquele código por meio de uma nota e, mostra os principais problemas relativos à qualidade ou segurança.

Projeção de Performance

Uma das primeiras coisas que precisamos nos perguntar quando fazemos um modelo de ML é qual a métrica que queremos otimizar. Pode parecer muito simples, mas escolher a métrica ideal depende de caso a caso e fará toda a diferença na sua modelagem.

Beleza, vamos dizer que a métrica já está muito bem escolhida e vamos tentar otimizar algo como a "precisão". Você consegue fazer testes offline e predizer como será o comportamento do seu modelo? E para diferentes segmentos da sua população, como ele se comporta? Qual a métrica de negócio que você vai impactar e mais se aproxima da "precisão" definida? A métrica que você definiu é um bom proxy para a métrica de negócio? Todas essas perguntas precisam ser respondidas para conseguirmos ter certeza que aquele modelo está impactando corretamente o que ele foi criado para fazer.

Além disso tudo, uma última avaliação que prezamos muito é o tempo de predição daquele modelo de ML. Em alguns casos você pode ter desenvolvido uma rede neural tão profunda e lenta que pode não responder tão rápido quanto uma aplicação em tempo real necessite. Essa informação é bastante necessária para entendermos em quais arquiteturas podemos usar aquele modelo de ML criado.

Explicabilidade

Photo by Laurentiu Iordache on Unsplash

Ok, entendemos que nem tudo é tão simples de explicar, mas precisamos levar a sério alguns assuntos como vieses e ir além da importância de features, overfitting, underfitting ou shap values. Buscamos por qualquer discriminação, preconceito, efeito em minorias e o que mais fizer sentido para o modelo em questão, porque realmente zelamos muito pela diversidade e inclusão na empresa.

Determinar incertezas do modelo de conhecimento e de dados, é outro ponto que nos permite identificar situações onde possa não funcionar bem como corner cases, e validar se os vários segmentos de usuários permanecem com resultados consistentes mesmo em produção.

Testes de Performance

Entendemos que o teste de performance acontece de verdade em ambiente de produção, porque é o momento que devemos coletar os feedbacks por meio experimentos controlados e melhorar cada vez mais nossos modelos.

Basicamente os testes consistem em validar se o que testamos em desenvolvimento / QA está de acordo e, se não estiver precisamos validar qual feature ou comportamento estamos esquecendo de contemplar.

Durante os testes de hipótese buscamos sempre contemplar amostras significativas e comparar distribuições estatísticas semelhantes entre amostras, além de levar em conta possíveis efeitos de sazonalidade. Para evitar a maioria desses problemas usamos testes A/B sempre que possível.

Aqui temos até um guia de como fazer experimentação, mas isso fica para outro conteúdo.😉

Monitoramento

Photo by Shane Hauser on Unsplash

Para monitorar os modelos já em produção usamos uma stack MUITO BOA, produzida internamente pelo nosso time de MLOps (também fica para um próximo post 😉), que já nos fornece praticamente de graça tudo que monitoramos. Os itens normalmente monitorados são:

• Métricas alvo de treino e predição;
• Tempo de treinamento;
• Tempo de predição por item;
• Quantidade de resultados por predição;
• Consumo de memória e CPU;
• Concept Drift e Data Drift;
• Uso de predições do modelo (modelo que não é usado é apagado ☠🗡);
• Métricas de negócio que sejam influenciadas pelo modelo.

Quando essas métricas saem do padrão, é possível configurar alarmes no Slack para avaliarmos os problemas.

Agradecimento a todos (as) os (as) cientistas de dados e engenheiros (as) de ML, envolvidos na confecção do nosso DoD, em especial a Bianca Kodama e Jeobara, que colaboraram com o contexto de modelos aplicados a crédito e Waner Miranda, com a revisão e o conhecimento na stack de MLOps.

Espero que gostem de como estamos fazendo modelos de ML aqui no PicPay e aceitamos sugestões! Quer fazer parte dessa empresa incrível? Vem com a gente!