Métricas de DS: Modelos Publicados, Impacto no Negócio, Degradação do Modelo

Você passou seis semanas empurrando o AUC de 0,84 para 0,89. Seu VP olha para o slide, acena com a cabeça e pergunta: "Ok, o que isso nos trouxe?" Você não tem um número. A sala fica em silêncio pelo motivo errado.

Essa é a lacuna em que a maioria dos Data Scientists cai. Medimos a precisão do modelo. O CFO mede dólares. Quando essas duas colunas não se reconciliam em um slide de QBR, as revisões de headcount não perguntam "qual foi o seu F1?" Elas perguntam "o que a equipe de DS publicou?" Se você não consegue traduzir o trabalho de modelos para a linguagem de negócio, você é cortado antes do engenheiro que publicou um botão.

Então vamos corrigir as métricas. Cinco delas. Cada uma é defensável em uma sala com um parceiro financeiro que nunca abriu um notebook Jupyter e não tem planos de abrir.

Por que isso importa agora

Toda equipe de DS que vi sobreviver a um ciclo de orçamento tinha a mesma característica: o líder conseguia nomear números em dólares. Não "melhoramos a precisão em 3 pontos." Não "publicamos 12 experimentos." Dólares. Horas. Tickets desviados. Margem recuperada.

As equipes que foram cortadas falavam sobre qualidade de modelos isoladamente. Tinham matrizes de confusão lindas e zero evidência de que alguma decisão na empresa mudou por causa de um modelo.

As conversas sobre headcount em 2026 são mais afiadas do que eram há três anos. A era do dinheiro barato ensinou as equipes de DS a medir entradas (artigos, experimentos, AUC). A era atual só conta saídas que aparecem em um P&L. Se você cresceu com as regras antigas, precisa se retreinar, rápido. As métricas abaixo são como você faz isso.

As 5 métricas que realmente importam

1. Modelos publicados em produção

A contagem de modelos servindo tráfego real de produção, vinculados a uma decisão real, com um responsável real de plantão.

Não notebooks. Não "implantado no staging." Não "rodou um backfill uma vez e enviou os resultados por e-mail para operações." Um modelo que está servindo requisições, tem um runbook e quebra algo visível se ficar fora do ar.

Meta: 2 a 4 modelos publicados por IC por ano.

Esse número parece baixo. Não é. Um modelo publicado significa: pipeline de dados em produção, pipeline de treinamento em produção, stack de disponibilização em produção, monitoramento em produção, consumidor downstream conectado. A maioria dos DS superestima quantos realmente fizeram porque conta notebooks. Conte o que está de plantão. O número fica honesto rápido.

Se você publicou zero no ano passado, essa é a conversa. Por quê? Foi a plataforma? Foi o escopo? Foi uma parte interessada que nunca integrou o seu output? Cada resposta aponta para uma correção diferente, e nenhuma delas é "preciso de um modelo melhor."

2. Impacto no negócio em dólares

Todo modelo publicado recebe um número em dólares associado. Receita aumentada, custo economizado, horas devolvidas (multiplicadas pela taxa horária carregada), rotatividade prevenida, fraude capturada.

Meta: cada modelo publicado deve ter impacto anualizado de pelo menos $250K, ou elimine-o.

O piso de $250K é aproximado. Ajuste para o tamanho da empresa. Uma startup de 30 pessoas pode defender modelos de $50K se forem baratos de rodar; uma empresa pública não deveria se preocupar com menos de $500K. O princípio vale: todo modelo tem um número, e se o número é pequeno, o modelo desaparece ou o headcount que ele consome desaparece.

Como realmente calcular (não teoricamente, em um slide):

• Modelo de receita: lift na taxa de conversão × tráfego de linha de base × valor médio do pedido × anualizado. Peça à área financeira para concordar com a linha de base antes de publicar. O acordo prévio é tudo; afirmações de lift pós-hoc são questionadas para sempre.
• Modelo de custo: tickets desviados × custo por ticket. Horas economizadas × taxa carregada. Baixa de inventário evitada. Obtenha um número da área financeira para custo por ticket, e não adivinhe.
• Modelo de risco: fraude capturada × perda média por caso. Dívida ruim evitada × taxa de baixa.

O que quer que você calcule, coloque a metodologia em uma nota de rodapé no slide. "Lift medido contra a linha de base pré-lançamento aprovada pelo FP&A em 14/02/2026." Essa frase vale mais do que o número em si, porque significa que o número não será questionado no próximo trimestre.

3. Taxa de degradação do modelo

A queda percentual na sua métrica de produção versus a métrica no momento do treinamento, medida mensalmente.

A maioria dos modelos perde 5 a 20% da sua métrica principal nos primeiros 90 dias de produção. Desvio nas distribuições de entrada, vazamento de labels que não apareceu na avaliação offline, sazonalidade que os dados de treinamento não cobriram. Coisa normal. O perigo não é a degradação. É a degradação silenciosa.

Meta: qualquer coisa degradando mais de 15% por trimestre sem um plano de retreinamento é um passivo. Ou corrija ou elimine.

Um exemplo prático. Suponha que o seu modelo de fraude treinado ficou em AUC 0,91. Após a publicação:

• Mês 1: AUC 0,89 em produção. Queda = (0,91 - 0,89) / 0,91 = 2,2%. Dentro do ruído.
• Mês 2: 0,86. Queda = 5,5%. Fique de olho.
• Mês 3: 0,81. Queda = 11,0%. Você tem um problema; investigue.
• Mês 4: 0,76. Queda = 16,5% em relação ao treinamento. Passivo.

Se você não tem um pipeline de retreinamento que consiga detectar isso no mês 2, construa um antes de construir qualquer modelo novo. Um modelo que degrada silenciosamente é pior do que nenhum modelo. Ele dá ao negócio uma falsa confiança.

O dashboard de uma linha que o seu VP quer sobre isso: "X de N modelos em produção têm alarmes de desvio conectados e um SLA de retreinamento. Y de N não têm." Essa proporção diz a eles quanto da superfície está realmente sob controle.

4. Tempo do experimento à produção

Dias entre "o notebook funciona" (a avaliação offline passa no critério) e "o tráfego de produção está atingindo o modelo."

Meta: menos de 45 dias. 60 dias é aceitável para um modelo difícil. Acima de 90 dias significa que a plataforma está quebrada, não você.

Essa é a métrica que a maioria dos Data Scientists não vai colocar em um slide porque os faz parecer lentos. Coloque no slide mesmo assim. Se o seu número é 120 dias, essa é uma conversa sobre plataforma, não uma conversa sobre desempenho. A solução é repositórios de atributos, pipelines de treinamento, registros de modelos e automação de deploy, não "o Data Scientist precisa trabalhar mais."

Quando um VP vê esse número e está ruim, ele deveria estar tendo uma conversa sobre design organizacional: precisamos de um engenheiro de plataforma de ML? Precisamos consolidar a cadeia de ferramentas de implantação? Precisamos parar de deixar cada equipe publicar o próprio stack de disponibilização personalizado?

A primeira vez que entrei em um QBR e coloquei o tempo de ciclo no slide, a reação inicial do meu VP foi defensiva. Ao final da reunião, ela havia escrito "plataforma de ML: prioridade do Q2" no quadro branco. Esse número desbloqueou uma contratação.

5. NPS de parceiros de negócio

Uma pesquisa trimestral de duas perguntas para os PMs, líderes de operações e analistas que consomem os seus modelos.

1. Em uma escala de 0 a 10, qual a probabilidade de você recomendar trabalhar com nossa equipe de DS a um par em outra empresa?
2. Por quê?

Abaixo de 30 (NPS) significa que você está resolvendo os problemas errados, sua comunicação é ruim, sua entrega é pouco confiável, ou alguma combinação disso. A resposta em texto livre diz qual.

Meta: NPS maior ou igual a 50, com um piso rígido de 30. Abaixo de 30 é um sinal de repriorização, não um sinal de "faça melhor no próximo trimestre".

Por que incluir isso com métricas concretas? Porque as quatro métricas acima são todas defasadas. Quando a degradação ou a contagem de modelos publicados conta a história, dois trimestres já passaram. O NPS de parceiros lidera. Quando o PM que você apoia para de pedir para escopo novos trabalhos, você tem seis meses antes de o número em dólares ficar estável. O NPS detecta isso antes.

Execute. Envie um formulário, não um e-mail. Anonimize as respostas. Leia o texto livre. Ajuste.

O diagnóstico de "alta precisão, sem impacto"

Aqui está o momento em que você vai se encontrar: um modelo com ótimas métricas offline, implantado por dois trimestres, que ninguém no lado do negócio consegue apontar como tendo mudado algo. Execute este checklist antes que o seu VP execute em você.

Diagnóstico de 4 perguntas (copie isso no seu documento de preparação de QBR):

[ ] 1. O output do modelo estava vinculado a uma decisão específica?
      (Não "estratégia informada." Uma decisão específica: desconto sim/não,
       prioridade do ticket alta/baixa, roteamento de lead para o rep A ou rep B.)

[ ] 2. Essa decisão realmente mudou por causa do modelo?
      (Alguém se comportou diferente? Puxe os dados antes/depois.
       Se a taxa de decisão é idêntica antes e depois do lançamento, o
       modelo é decoração.)

[ ] 3. A decisão modificada valeu dinheiro?
      (As decisões podem mudar sem gerar valor. Se os reps começaram a rotear
       leads de forma diferente, mas a conversão não se moveu, isso é $0.)

[ ] 4. A área financeira concordou com a metodologia?
      (Obtenha isso por escrito ANTES do QBR. "FP&A aprovou a
       linha de base em AAAA-MM-DD" é a frase mágica.)

Se você responder "não" a qualquer uma das quatro, você não tem uma métrica de impacto no negócio. Você tem uma história. Histórias não sobrevivem a um CFO. Ou corrija a lacuna subjacente ou elimine o modelo e libere o headcount.

A armadilha em que a maioria das equipes cai é a pergunta 1: publicam uma pontuação de propensão e chamam o trabalho de concluído. Uma pontuação não é uma decisão. A pontuação sentada em um banco de dados não vale nada. A regra de decisão que consome a pontuação e muda o comportamento é de onde vêm os dólares. Se essa regra não existe, o modelo é um hobby.

O slide de QBR

Um slide. Cinco linhas. Último trimestre, este trimestre, delta. Uma história de modelo com um número em dólares abaixo.

Veja como o meu parece (números são ilustrativos, formato é real):

Destaque do Q2: Lead-scoring v2 (publicado em 14 de abril) Roteia leads inbound para reps com base na propensão de conversão. Substituiu o round-robin. Medido contra a linha de base pré-lançamento (aprovada pelo FP&A em 22/03/2026): taxa de conversão de 4,1% para 5,6%. Impacto anualizado: $1,1M em nova receita. Alarmes de desvio conectados; SLA de retreinamento de 30 dias.

Esse é o slide inteiro. Cinco números. Uma história de modelo. Uma nota de rodapé citando a linha de base do FP&A. Nenhum AUC em lugar algum na página.

Eu poderia ter colocado AUC? Claro. O modelo está em 0,87, acima dos 0,81 da v1. Ninguém naquela sala se importa. Se se importassem, perguntariam, e eu responderia. Eles não vão perguntar. Vão perguntar se $1,1M é real, quem aprovou a linha de base e qual é a rotação de plantão quando quebrar.

Essa é a conversa que uma métrica deve iniciar. O AUC não inicia essa conversa. Dólares, sim.

Armadilhas de métricas de vaidade

Cinco métricas que vejo líderes de DS acidentalmente otimizar, que parecem produtivas e não são.

Contagem de publicações. Artigos são ótimos para contratar DS sênior em organizações de pesquisa. Não são o que o seu VP defende em uma revisão de P&L. Se você está em uma equipe aplicada e sua métrica principal é publicações, está jogando o jogo errado. O CFO não lê NeurIPS.

Ranking no Kaggle. Útil para marca pessoal. Inútil para impacto na empresa. Um DS sênior sem perfil no Kaggle e quatro modelos de receita publicados supera um Kaggle Grandmaster com dois notebooks toda vez na pergunta que importa: o negócio melhorou.

AUC do modelo isolado. AUC é uma métrica de qualidade do modelo. Qualidade do modelo é um meio; resultado de negócio é o fim. AUC em um slide sem dólares ao lado faz a sala pensar que você está escondendo algo. Com frequência, você está, inclusive de si mesmo.

Contagem de notebooks. Já vi currículos de DS que listam "rodei 47 experimentos." Quarenta e sete experimentos e zero modelos publicados é um sinal pior do que quatro experimentos e quatro modelos publicados. A proporção de publicações para experimentos é o número real.

"Modelos construídos". Fique atento a essa formulação. "Construído" não é "publicado." "Construído e demonstrado para a equipe" não é "publicado." "Construído e integrado em um dashboard que os PMs às vezes olham" não é "publicado." Se um modelo não está servindo tráfego de produção em uma decisão real, está em uma gaveta. O número que vai no slide é o número que está realmente em produção.

O padrão em todos os cinco: eles medem o trabalho realizado, não o valor entregue. CFOs medem o valor entregue. Você também deveria.

Colocando isso no seu calendário

Se você levar uma coisa deste guia:

1. Até sexta-feira: conte seus modelos publicados (definição real) e escreva o número em dólares para cada um.
2. Até o próximo QBR: peça ao FP&A para aprovar uma linha de base para qualquer modelo que não tenha uma. Por escrito.
3. Mensalmente, registre a métrica de produção versus treinamento para cada modelo. Se a degradação for maior que 15%, escale.
4. Trimestralmente, envie a pesquisa de NPS de 2 perguntas. Leia o texto livre.
5. Em todo QBR, traga o slide de 5 linhas. Comece com dólares, não com AUC.

O trabalho não é qualidade do modelo. O trabalho é impacto publicado. AUC é um meio; dólares são o fim. Se você não consegue nomear o número em dólares para cada modelo que publicou, você não tem uma métrica. Você tem um hobby.

Saiba Mais

• Descrição de Cargo para Data Scientist
• Seus Primeiros 30/60/90 Dias como Novo Data Scientist
• Trabalhando com Seu VP de IA / Líder de DS
• Eliminando um Modelo Que Não Está Funcionando