Para a maioria dos cientistas de dados, finalizar uma solução de Machine Learning (ML) é um momento de celebração. Criar apresentações de saída dos modelos e mostrar os ganhos nos KPI´s também é muito gratificante.
Implantar esta mesma solução com áreas parceiras, negócio e tecnologia, é motivo também de muita alegria e alívio!
No entanto, muitas vezes o horizonte pós implantação dos modelos não é tão tranquilo quanto imaginamos.
O período pós-implantação de um modelo torna-se motivo de atenção para clientes e todos aqueles que o utilizam. Neste artigo, pretendo apresentar um desses desafios: definir contingências.
Por que definir contingências?
Porque garante robustez durante o uso da solução e também mitiga possíveis problemas nos inputs dos modelos, provenientes de fatores externos.
Monitoramento das Soluções
Antes de falar das contingências no deploy de ML , é necessário que essas soluções já comecem com monitoramento das entradas e saídas do modelo.
Além de identificar se o desempenho da solução de ML está aderente e sem inconsistências para o negócio, é fundamental também monitorar as entradas de dados.
Alterações nas distribuições, identificação de outliers e novos valores para features são os principais usos para os monitoramentos.
É fundamental configurar, automatizar e analisar os monitoramentos dos inputs e outputs para mitigar possíveis problemas nos dados e corrigir rapidamente os modelos.
Contingências para características categóricas — novos valores de dados
Caso novos de dados apareçam durante e uso do modelo, é importante que sejam revisitados e reclassificados dentro do mesmo.
Por exemplo, suponha que a feature “escolaridade” faça parte do modelo. E num determinado momento, a categoria “pós-graduação concluída no momento” começou a aparecer no banco de dados, sendo que este registro não foi encontrado no modelo. Assim, se não classificados, vão causar uma distorção no output.
Neste caso, o modelo pode classificar como “outros” ou “ em falta ” ou ainda entre os casos mais próximos, conceitualmente, de registros cuja escolaridade é “graduação completa”.
É importante que qualquer de/para alinhado seja construído junto com os usuários do modelo na ponta.
Características contínuas: valores discrepantes
Valores muito discrepantes que não foram observados durante o treino do modelo podem ter um impacto durante o uso, dependendo da magnitude.
Primeiro é necessário entender se esses valores “ outliers ” estão corretos ou se são inconsistentes.
Por exemplo, uma idade igual a 200 anos configura claramente um erro no banco de dados. Já os valores financeiros, classificados como outliers, podem ser observados de fato.
Uma alternativa válida seria delimitar valores “fixos”, como no exemplo abaixo:
“se idade >= 100 então idade = 100”
Não são incomuns também que valores negativos apareçam, sejam financeiros ou transacionais. É fundamental verificar se os valores são coerentes com o contexto. No caso de saldo na conta corrente, os valores negativos são factíveis , uma vez que é possível entrar no limite de crédito e apresentar valores negativos na prática.
Outro caso comum em bancos de dados financeiros ou pagamentos são dias de atraso . Ele é calculado como a diferença entre os dados de pagamento e os dados de vencimento. Caso o pagamento seja feito antes do vencimento , configura um pagamento antecipado e o atraso será negativo.
Para eventos em que os valores devam ser, conceitualmente, sempre maiores que 0, e caso os valores apareçam no banco de dados sem uma explicação, podem ser alterados para valores mínimos do banco de dados ou iguais a 0.
Bases de dados
Quando pensamos em bancos de dados que alimentam os modelos de ML , quaisquer mudanças nos nomes dos campos ou nos formatos, ou mesmo na atualização do banco de dados (d+1, d+2, etc.), impactam os outputs e processos envolvidos . Sugiro que essas mudanças sejam mapeadas o quanto antes e que os planos de contingência sejam mapeados assim que possível.
Resumindo
Antes de implementar soluções de ML:
- Certifique-se de que o monitoramento será implementado e analisado;
- Mapeie possíveis problemas em cada aspecto do modelo em produção, como: novos valores de dados, outliers e possíveis mudanças nos valores de dados;
- Tenha planos de contingência para problemas em cada uma das possíveis mudanças citadas acima.
Para conhecer mais sobre as soluções da Datarisk, acesse o nosso site.
Líder de DS
