Auditar um ML que chegou pronto com afirmações que o código não sustentava
Um sistema de priorização de clientes de alta renda chegou pronto e rodando, com relatório e números convincentes. Ao conferir afirmação por afirmação contra o código, várias não se sustentavam. O projeto deixou de ser "melhorar o modelo" e virou a auditoria que separa o que dá para provar do que era história bem contada.
Palavras sublinhadas têm uma explicação rápida. Toque nelas.
Pegar um pipeline de classificação que já existia e conferir cada afirmação do relatório contra o que o código de fato executa.
Sistema que chega pronto com número bonito é justamente onde mais mora afirmação que ninguém verificou. Um agrupamento dito confirmado que não foi confirmado não é erro de documentação: é uma decisão de negócio tomada em cima de nada, e que continua sendo tomada todo mês até alguém abrir o código.
Cada divergência virou um registro de decisão com um teste que impede a volta do comportamento errado. As alegações sem lastro foram apagadas do texto, e a checagem foi feita por busca no próprio código, não por leitura do relatório. A base é 100% sintética, então o retorno de cerca de 300% é cenário declarado, não medição.
Seis achados corrigidos, cada um com registro e um teste que trava o comportamento certo: um "K=6 confirmado por métrica" que era K=2; pesos ditos "calibrados por especialista" que eram uma regra fixa; o notebook e o painel calculando a nota do mesmo cliente com fórmulas diferentes. O classificador treinado foi testado e perdeu da heurística de negócio de 10 critérios (AUC 0,76 contra 0,78). Isso ficou publicado.
O modelo treinado perdeu da regra de negócio escrita à mão, e isso ficou publicado em vez de escondido. A decisão de reposicionar o projeto como auditoria veio daí: existe muita gente disputando quem tem o modelo mais preciso, e pouca gente disposta a procurar o erro que faz um sistema mentir sem dar defeito. O segundo terreno tem menos concorrência e resolve um problema mais caro.