KPIs (Métricas do Modelo vs Métricas do Produto)

Por que “KPIs” fica confuso em produtos de IA

Em projetos de IA, as equipes frequentemente falam umas pelas outras porque usam a palavra métrica para significar coisas diferentes:

• Métricas de modelo medem o quão bem um modelo prevê ou gera saídas sob uma configuração de avaliação definida (geralmente offline).
• Métricas de produto medem se o recurso cria valor real para o usuário e melhora resultados de negócio (geralmente online).

Ambas importam. Mas não são intercambiáveis: otimizar o F1 ou o ROUGE de um modelo pode facilmente não melhorar retenção, conversão ou confiança — e às vezes até prejudicá-las.

Este artigo explica como escolher KPIs que reflitam tanto valor para o usuário quanto comportamento do modelo, e como conectar a avaliação offline ao impacto no mundo real.

Links para tópicos relacionados de estratégia de produto:

• Seleção de Caso de Uso
• Estratégia de Dados
• Modos de Falha & UX de Contingência
• Construir vs Comprar

Definições centrais: KPIs, métricas de modelo e métricas de produto

KPI (Indicador-Chave de Desempenho (Key Performance Indicator))

Um KPI é uma métrica que é:

• Orientada a decisões (você vai mudar algo se ela se mover),
• Com dono (alguém é responsável),
• Operacionalizada (medida de forma confiável, monitorada e revisada).

Nem toda métrica deve ser um KPI. Painéis frequentemente contêm dezenas de números; apenas alguns deveriam conduzir decisões de “vai / não vai” e de priorização.

Métricas de modelo (exemplos típicos)

Métricas de modelo geralmente quantificam a qualidade preditiva sob uma distribuição de teste controlada:

• Classificação: acurácia, precisão/recall, F1, ROC-AUC, PR-AUC
• Ranqueamento/recomendações: NDCG, MRR, hit rate
• Regressão: MAE, RMSE
• PLN generativa (Generative NLP): proxies automáticos como BLEU/ROUGE, ou avaliações de LLM como juiz (LLM-as-judge), além de avaliação humana

Conceitos relacionados: Precisão e Recall, Calibração

Métricas de produto (exemplos típicos)

Métricas de produto quantificam resultados para o usuário e para o negócio:

• Ativação: % de usuários que experimentam o recurso
• Engajamento: frequência de uso, profundidade, tempo até o valor (time-to-value)
• Sucesso da tarefa: taxa de conclusão, tempo para conclusão, taxa de erro
• Satisfação & confiança: CSAT, taxa de reclamação, eventos de “reportar problema”, tickets de suporte
• Negócio: conversão, receita, churn, custo de atendimento (cost-to-serve), perdas por fraude

Métricas operacionais (frequentemente confundidas com KPIs)

Métricas operacionais importam, mas geralmente são grades de proteção (guardrails) em vez de métricas de “valor”:

• Latência (p95/p99), disponibilidade, timeouts
• Custo de computação por requisição
• Profundidade de fila, throughput
• Violações de política de segurança

Em equipes maduras, KPIs normalmente são um conjunto: um KPI primário de produto mais várias grades de proteção (incluindo métricas de modelo e operacionais).

O desafio central: qualidade offline não é o mesmo que valor online

Um modelo pode melhorar em dados offline e ainda assim falhar em produção devido a:

• Mudança de distribuição (distribution shift) (usuários se comportam diferente do seu conjunto de dados)
• Objetivo diferente (o sucesso do produto não é o mesmo que a função de perda do modelo)
• Efeitos de humano no loop (human-in-the-loop) (usuários se adaptam ao modelo)
• Escolhas de limiar e política (o mesmo modelo pode se comportar muito diferente dependendo do ponto de operação)
• Problemas de UX e fluxo de trabalho (usuários não entendem, não confiam ou não conseguem agir com base nas saídas)

Por isso, o desenho de KPIs deve começar com valor para o usuário e trabalhar de trás para frente até a avaliação do modelo — e não o contrário.

Um framework prático: conectar valor do usuário → métricas de produto → métricas de modelo

Uma forma útil de evitar desalinhamento é uma “cadeia de métricas”:

1. Declaração de valor para o usuário (qual resultado melhora para o usuário?)
2. KPI primário de produto (como você vai medir esse resultado)
3. Métricas de produto de suporte (indicadores antecedentes, etapas do funil)
4. Métricas de comportamento do modelo (dimensões de qualidade que impulsionam esses resultados de produto)
5. Grades de proteção (segurança, latência, custo, equidade, risco de marca)

Exemplo: cadeia de métricas para um chatbot de suporte

1. Valor para o usuário: “Resolver problemas mais rápido sem precisar de um agente humano.”
2. KPI primário de produto: Taxa de resolução de problemas (em até 24h).
3. Métricas de suporte: tempo até a resolução (time-to-resolution), taxa de transferência (handoff rate), taxa de contato repetido (repeat contact rate).
4. Métricas de modelo: utilidade da resposta (avaliação humana), fundamentação (groundedness), taxa de alucinação (hallucination rate), taxa de sucesso de chamada de ferramenta (tool-call success rate).
5. Grades de proteção: toxicidade, vazamento de PII, latência p95, custo por ticket resolvido.

Observe: “pontuação BLEU” não está na lista — porque raramente explica resultados reais de suporte.

Escolhendo KPIs de produto: meça resultados, não qualidade de saída

Comece com uma métrica de resultado “North Star”

Bons KPIs de produto são orientados a resultados. Eles medem o que os usuários realmente se importam:

• “O usuário conseguiu concluir a tarefa?”
• “Reduzimos tempo/custo/esforço?”
• “Aumentamos a confiança e reduzimos danos?”

Exemplos por caso de uso:

• Detecção de fraude: valor em $ de fraude evitada (líquido de recusas falsas)
• Busca/recomendação: sessões bem-sucedidas, retenção de longo prazo, conversão a jusante
• Assistente de escrita: tempo economizado, taxa de aceitação com checagens de satisfação
• Triagem médica: acurácia de encaminhamento seguro, redução de eventos adversos (com grades de proteção rigorosas)

Use indicadores antecedentes — mas não os confunda com valor

Você frequentemente precisa de indicadores antecedentes porque métricas de resultado podem demorar:

• Resultado: retenção em 30 dias
  Indicador antecedente: taxa de conclusão do “momento aha”, uso semanal repetido

• Resultado: redução do custo de atendimento
  Indicador antecedente: taxa de automação, taxa de deflexão, tempo médio de atendimento

Indicadores antecedentes se tornam perigosos quando são fáceis de manipular. Por exemplo, um chatbot pode “aumentar a deflexão” recusando-se a escalar — mesmo quando a escalada é apropriada — prejudicando resolução e confiança.

Instrumentação: defina eventos e denominadores

Muitas falhas de métricas são falhas de medição. Registre:

• Numerador e denominador
• Critérios de inclusão (quais sessões/usuários contam)
• Janela de tempo (mesmo dia, 7 dias, 30 dias)
• Atribuição (quais interações “contam” como impulsionadas por IA)

Exemplo: “taxa de conclusão de tarefa” precisa especificar o que conta como tarefa e como a conclusão é detectada.

Escolhendo métricas de modelo: selecione métricas que reflitam modos de falha relevantes ao produto

Métricas de modelo devem refletir os modos de falha que os usuários vivenciam, não apenas o que é conveniente de calcular.

Sistemas de classificação: métricas por limiar superam “acurácia geral”

Para problemas desbalanceados, acurácia pode não significar nada. Prefira:

• Precisão/recall no limiar operacional
• PR-AUC (quando positivos são raros)
• Medidas ponderadas por custo (custo de falso positivo vs custo de falso negativo)

Exemplo: filtro de spam

• Falsos positivos (email bom marcado como spam) são muito custosos para a confiança do usuário.
• Um KPI pode ser “reclamações sobre email perdido” e “tempo para recuperar”.
• Uma métrica de modelo pode enfatizar alta precisão com recall aceitável.

Ranqueamento/recomendação: NDCG offline não é o fim

Métricas offline de ranqueamento correlacionam com resultados online apenas quando:

• Dados logados são representativos,
• Viés é tratado (viés de posição, viés de exposição),
• Objetivos coincidem.

Muitas vezes você precisa de experimentos online para saber se +0,01 de NDCG importa para retenção.

IA generativa: avalie dimensões que os usuários realmente percebem

Para recursos com LLMs, as métricas de modelo são multidimensionais:

• Utilidade / sucesso da tarefa
• Factualidade / fundamentação (especialmente com recuperação)
• Seguimento de instruções
• Segurança (toxicidade, autoagressão, assédio)
• Consistência de estilo e tom
• Correção de recusa (recusar o inseguro, cumprir o seguro)
• Qualidade de citações (se você cita fontes)

Métricas automáticas (por exemplo, ROUGE) podem ser proxies fracos. Avaliação de alta qualidade frequentemente mistura:

• conjuntos de teste curados,
• avaliações humanas,
• red teaming direcionado,
• e sinais online (com interpretação cuidadosa).

Conectando offline e online: deixe a relação explícita

A etapa de “tradução de métrica”: da matriz de confusão ao impacto no negócio

Uma forma limpa de alinhar equipes é traduzir erros do modelo em custo/benefício do produto.

Exemplo: modelo de fraude (classificador binário)

• Verdadeiro positivo: fraude detectada → economiza $X
• Falso negativo: fraude não detectada → perde $Y
• Falso positivo: transação legítima bloqueada → perde $Z + confiança do usuário

Então escolha um limiar operacional que maximize utilidade esperada, não F1.

Um cálculo simplificado de utilidade pode parecer com:

def expected_utility(tp, fp, fn, tn, value_tp=50, cost_fp=10, cost_fn=100):
    return tp * value_tp - fp * cost_fp - fn * cost_fn

# Compare thresholds by computing tp/fp/fn/tn on validation data

Isso não substitui KPIs de produto, mas torna os trade-offs visíveis e conecta o comportamento do modelo aos resultados.

Calibração e abstenção: “cobertura” é uma decisão de produto

Muitos sistemas permitem abstenção (por exemplo, “não estou confiante — transferir para humano”). Isso pode melhorar a correção, mas reduzir a automação.

Acompanhe:

• Cobertura (percentual de casos tratados automaticamente)
• Qualidade na cobertura (taxas de erro entre os casos tratados)
• Taxa de contingência e sucesso da contingência

Isso se conecta diretamente a Modos de Falha & UX de Contingência: uma boa experiência de contingência pode tornar “abster com mais frequência” uma boa escolha de produto.

Teste A/B: o árbitro para KPIs de produto

Se você consegue rodar experimentos, prefira usar KPIs de produto como critério primário de sucesso e trate métricas de modelo como diagnósticos.

Padrão comum:

• KPI primário: taxa de sucesso da tarefa
• Secundários: tempo para concluir, satisfação
• Grades de proteção: taxa de reclamação, latência, custo, incidentes de segurança

Cuidado com:

• efeitos de novidade (picos de engajamento de curto prazo),
• sazonalidade,
• incompatibilidade de razão amostral (sample ratio mismatch),
• interferência (usuários compartilham conteúdo entre variantes).

Projetando conjuntos de KPIs: primário, secundários e grades de proteção

Um desenho robusto de KPIs inclui:

KPI primário (um, idealmente)

A única métrica que você otimiza no nível do produto. Exemplos:

• “Tickets resolvidos por 100 conversas”
• “Taxa de conversão no checkout”
• “Usuários ativos semanais que concluem o fluxo de trabalho principal”

Métricas secundárias (explicam *por quê*)

Etapas do funil e resultados diagnósticos:

• adoção (entrada no recurso)
• profundidade de engajamento
• tempo de conclusão
• taxa de escalonamento para humano
• taxa de retrabalho (edições do usuário, desfazer ações)

Grades de proteção (evitam dano e regressões)

• Segurança: violações de política, vazamento de PII, denúncias de abuso
• Confiabilidade: taxa de crash, timeouts
• Desempenho: latência p95
• Custo: $ por resultado bem-sucedido
• Equidade: disparidade entre segmentos (quando aplicável)

Uma regra útil: Se uma métrica pode subir piorando o produto, ela deve ser pareada com uma grade de proteção.

Exemplos práticos: alinhando métricas de modelo e de produto

Exemplo 1: Sumarização de documentos para clínicos

Valor para o usuário: revisão de prontuário mais rápida sem perder riscos importantes.

• KPIs de produto:
  • tempo até a decisão (com checagens de qualidade)
  • taxa de “informação crítica perdida” (auditoria amostrada)
  • nota de confiança do clínico
• Métricas de modelo:
  • fundamentação (afirmações do resumo suportadas pela fonte)
  • taxa de omissão em campos críticos (avaliação direcionada por checklist)
  • consistência entre formatos
• Grades de proteção:
  • severidade de alucinação
  • latência
  • conformidade no manuseio de PHI

Aqui, ROUGE pode ser irrelevante; um checklist direcionado de “fatos críticos” correlaciona melhor com dano ao usuário.

Exemplo 2: Agente de suporte com recuperação aumentada (RAG (Retrieval-augmented support agent))

Valor para o usuário: respostas precisas fundamentadas em documentos da empresa.

• KPIs de produto:
  • resolução no primeiro contato
  • tempo médio de atendimento (AHT)
  • taxa de escalonamento (com causa raiz pós-escalonamento)
• Métricas de modelo:
  • recall@k da recuperação (buscou o documento certo?)
  • correção de citações
  • fundamentação da resposta
• Grades de proteção:
  • taxa de “confiante e errado” (alucinações de alta confiança)
  • desvio de frescor dos documentos (conhecimento desatualizado)

Este exemplo se conecta diretamente a Estratégia de Dados: se os documentos não são atualizados e rotulados, melhorias no modelo não vão corrigir respostas desatualizadas.

Exemplo 3: Recomendações em um marketplace

Valor para o usuário: encontrar itens relevantes rapidamente; valor para o negócio: maior conversão.

• KPI de produto:
  • conversão a jusante por sessão (ou receita por sessão)
• Secundários:
  • sessões de “busca bem-sucedida”, taxa de adicionar ao carrinho
  • diversidade/novidade (para evitar bolhas de filtro)
• Métricas de modelo:
  • NDCG/MRR offline em dados logados (ciente de vieses)
  • cobertura sobre o inventário
• Grades de proteção:
  • latência
  • restrições de equidade para vendedores (se necessário)
  • taxa de reclamação de clientes

Melhorias offline de ranqueamento precisam ser validadas online porque o comportamento do usuário e a dinâmica do marketplace importam.

Anti-padrões comuns (e como evitá-los)

Anti-padrão: “Acurácia do modelo é nosso KPI”

Acurácia raramente é o objetivo do produto. Usuários não pagam por acurácia; eles pagam por resultados.

Correção: Defina primeiro um KPI de resultado (conclusão de tarefa, resolução, conversão) e então identifique quais tipos de erro do modelo bloqueiam esse resultado.

Anti-padrão: Otimizar um proxy que é fácil de manipular

Exemplo: “taxa de automação” para um chatbot pode subir se o bot se recusar a escalar.

Correção: Pareie métricas proxy com métricas de resultado (resolução, satisfação) e grades de proteção (reclamações, novo contato).

Anti-padrão: Uma métrica única para todos os usuários

Agregados escondem falhas em segmentos importantes (por exemplo, novos usuários, usuários que não são nativos no idioma, enterprise vs gratuito).

Correção: Sempre segmente o reporte de KPIs por:

• coorte de usuários,
• geografia/idioma,
• dispositivo,
• principais níveis de clientes,
• e contextos de alto risco.

Anti-padrão: Sem dono, sem limiares, sem ação

Métricas sem donos viram decoração de painel.

Correção: Para cada KPI, defina:

• dono,
• cadência de revisão,
• limiares de meta e de alerta,
• e ações pré-planejadas quando limiares forem ultrapassados.

Operacionalizando KPIs: de definições a painéis e decisões

Crie “especificações de métricas” (leves, mas explícitas)

Para cada KPI, escreva uma especificação curta:

• Nome e intenção
• Fórmula exata (com denominador)
• Fonte de dados (eventos, logs, tabelas do data warehouse)
• Atraso (tempo real, diário, semanal)
• Vieses e ressalvas conhecidos
• Dono e plantão/alertas (para grades de proteção)

Monitore drift e loops de feedback

Mesmo modelos estáveis degradam quando o mundo muda.

Acompanhe:

• drift de entrada (distribuições de features),
• drift de rótulo (taxas base do desfecho),
• drift de desempenho (métricas de qualidade ao longo do tempo),
• e drift de política (mudanças em limiares, UX ou roteamento).

Conceito relacionado: Concept Drift

Conecte a revisão de KPIs a gates de release

Prática típica:

• Antes de lançar: cumprir limiares de métricas offline + checagens de segurança
• Depois de lançar: teste A/B mostra melhoria no KPI de produto com grades de proteção aprovadas
• Pós-lançamento: monitoramento contínuo, com critérios de rollback

Isso é especialmente importante em produtos com LLMs, onde pequenas mudanças de prompt ou política podem causar grandes mudanças de comportamento.

Construir vs comprar: implicações de KPIs

Se você usa um modelo de API de terceiros (Construir vs Comprar):

• Você pode ter visibilidade limitada sobre métricas de treino e internals.
• Você deve intensificar:
  • KPIs de produto,
  • avaliação online,
  • logging robusto de prompts/saídas (com controles de privacidade),
  • e SLAs do fornecedor para latência/disponibilidade/custo.

Se você constrói seu próprio modelo, pode adicionar KPIs de modelo mais ricos (calibração, desempenho por fatia, métricas de drift), mas ainda precisa de KPIs de produto para garantir que está construindo a coisa certa.

Checklist: escolhendo KPIs que refletem valor para o usuário e comportamento do modelo

• Defina o valor para o usuário em uma frase.
• Escolha um KPI primário de produto que meça esse valor.
• Adicione 2–5 métricas secundárias que expliquem o funil e o comportamento.
• Escolha métricas de modelo que correspondam a modos de falha visíveis ao usuário.
• Adicione grades de proteção para segurança, latência, custo e confiança.
• Especifique segmentos onde falha é inaceitável.
• Decida como você vai validar: limiares offline + experimentos online.
• Atribua donos, limiares e ações (rollback, retreinar, mudança de UX, mudança de política).
• Garanta que logging e rotulagem suportem o plano (Estratégia de Dados).

Resumo

O principal papel dos KPIs em produtos de IA é manter a otimização apontada para valor real para o usuário enquanto mantém controle sobre o comportamento do modelo. Métricas de modelo dizem o que o modelo está fazendo; métricas de produto dizem se isso importa. Os melhores sistemas de KPIs conectam explicitamente os dois via uma cadeia de métricas, usam validação online sempre que possível e incluem grades de proteção para evitar modos de falha previsíveis.