Por que confiar em uma métrica exige muito mais do que verificar se o número foi calculado corretamente.
Existe uma pergunta aparentemente simples que pode gerar uma discussão surpreendentemente longa:
Quantos cartões ativos temos?
Parece que deveríamos conseguir consultar um banco de dados e voltar com um número.
O problema começa quando perguntamos:
O que exatamente chamamos de cartão ativo?
Um cartão que não foi cancelado?
Um que está habilitado para realizar transações?
Um que teve pelo menos uma transação nos últimos 30 dias?
Nos últimos 90?
Um cartão emitido, mas que nunca foi utilizado, conta como ativo?
Dependendo da definição, podemos chegar a números completamente diferentes.
E o mais interessante é que todos eles podem estar corretamente calculados.
O problema não está necessariamente no dado.
Está no que acreditamos que ele significa.
Dois números diferentes nem sempre significam que um deles está errado. Às vezes, significam que nunca chegamos a um acordo sobre o que estávamos medindo.
Na prática, parte desse problema pode ser resolvida tornando a definição explícita.
Documentá-la ajuda. Versioná-la também, porque as métricas mudam, assim como a forma como uma organização entende o próprio negócio.
Isso não elimina todas as discussões.
Mas faz com que a discussão seja sobre a definição, e não sobre qual das duas queries é "a correta".
Um dado pode estar corretamente calculado e ainda assim estar errado para a decisão
Quando falamos de qualidade de dados, normalmente pensamos primeiro em erros.
Uma fonte que deixou de atualizar.
Um status que não mudou quando deveria.
Registros duplicados.
Dados ausentes.
Uma transformação incorreta.
Todos são problemas reais. Encontrei vários deles ao longo dos anos.
Mas existe outra categoria, muito mais silenciosa.
O pipeline funciona.
A consulta está correta.
O dashboard está atualizado.
O número está matematicamente correto.
E, mesmo assim, duas pessoas o interpretam de maneiras diferentes.
Antes de confiar em uma métrica, portanto, não basta perguntar:
Esse número está correto?
Também precisamos perguntar:
O que exatamente esse número significa?
Há décadas, pesquisas sobre qualidade de dados mostram que avaliar a qualidade apenas pela exatidão é insuficiente. O dado também precisa ser adequado ao contexto em que será utilizado e compreensível para quem o consome.
Essa ideia continua surpreendentemente atual.
Porque uma métrica tecnicamente perfeita, mas com uma definição ambígua, pode nos levar a uma decisão perfeitamente errada.
A definição faz parte da métrica
Mais de uma vez participei de reuniões em que duas áreas apresentavam números diferentes para o que, supostamente, era a mesma métrica.
Em uma dessas situações, ambas as equipes estavam convencidas de que seu número era o correto.
A primeira reação foi procurar o erro: revisar queries, fontes e transformações.
E sim, às vezes encontramos erros.
Mas, em outras ocasiões, encontramos algo mais interessante.
As fontes não eram as mesmas.
Os filtros eram diferentes.
Uma área incluía determinados status e a outra não.
Uma utilizava a data de criação e a outra, a data de aprovação.
Uma considerava um período de calendário e a outra analisava os últimos 30 dias.
O erro não estava necessariamente no cálculo.
Estávamos usando o mesmo nome para descrever coisas diferentes.
Voltemos aos "cartões ativos".
Se a área Financeira considera ativo qualquer cartão habilitado, enquanto Produto considera ativo apenas um cartão que realizou uma transação nos últimos 30 dias, provavelmente teremos dois números diferentes.
E ambos podem estar certos.
O wording de uma métrica, portanto, não é apenas um detalhe de documentação.
Ele faz parte da própria métrica.
Uma boa definição deveria permitir entender o que estamos medindo, o que estamos deixando de fora, qual fonte estamos utilizando, como a métrica é calculada e a qual período ela se aplica.
Sem isso, um dashboard pode criar uma ilusão de precisão.
Temos um número com duas casas decimais.
O que talvez não tenhamos é um significado compartilhado.
O tempo muda o significado do dado
No artigo anterior, escrevi sobre a importância de preservar a dimensão temporal dos nossos sistemas.
Ela aparece novamente aqui, mas de outra perspectiva.
O tempo também faz parte da definição de uma métrica.
Suponhamos que alguém pergunte:
Quantos clientes temos?
Podemos responder quantos existem hoje.
Quantos estavam ativos no fechamento do mês passado.
Quantos fizeram uma compra nos últimos 30 dias.
Quantos tiveram alguma atividade durante o último ano.
Quantos já foram clientes alguma vez.
São perguntas diferentes escondidas por trás de uma frase aparentemente simples.
Isso se torna ainda mais importante quando comparamos períodos.
Se mudarmos a definição de uma métrica, trocarmos sua fonte ou incorporarmos informações que antes não estavam disponíveis, podemos quebrar a comparabilidade histórica sem perceber.
O gráfico continua tendo uma linha.
Mas talvez uma parte dessa linha passe a significar algo diferente do restante.
Uma métrica sem uma definição temporal clara pode estar correta hoje e ser incomparável consigo mesma amanhã.
Quando analiso um número, tento entender não apenas como ele foi calculado.
Mas também quando.
As médias também contam histórias incompletas
Existe outra área em que procuro ter um cuidado especial: médias e agregações.
Suponhamos que alguém diga:
"Em média, um cliente leva 48 horas para concluir o processo."
O número pode estar completamente correto.
Mas ainda sabemos muito pouco.
A maioria dos clientes leva aproximadamente 48 horas?
Ou metade conclui em dez minutos, enquanto um pequeno grupo leva várias semanas?
A composição dos clientes mudou?
Existem segmentos com comportamentos completamente diferentes?
Estamos comparando populações equivalentes?
Uma média resume.
E justamente porque resume, ela achata a realidade.
Pode esconder se os casos estão relativamente concentrados em torno daquele valor ou se temos uma distribuição muito assimétrica, na qual uma pequena quantidade de casos extremos — uma cauda longa — empurra a média para cima.
Isso não transforma a média em uma métrica ruim. Apenas significa que ela precisa de contexto.
Às vezes, olhar para a mediana, alguns percentis ou simplesmente para a distribuição completa conta uma história bastante diferente.
Uma vez alguém me disse algo que ficou comigo:
Os mesmos números podem sustentar interpretações diferentes.
Acho que isso é verdade.
Os dados restringem as histórias que podemos contar, mas raramente eliminam completamente a necessidade de interpretação.
Quando vejo uma conclusão construída a partir de uma média ou agregação, quero entender a fonte, a distribuição, a população, o período e como aquela métrica foi construída.
Não porque eu desconfie do dado.
Mas porque quero entender qual conclusão ele realmente permite sustentar.
Dados ausentes e dados incorretos não têm o mesmo risco
Se eu tivesse que escolher entre não ter um dado e ter um dado incorreto, prefiro saber que não tenho aquela informação.
Quando uma informação está ausente, a incerteza fica visível.
Podemos dizer:
"Não sabemos."
Podemos procurar outra fonte, construir uma aproximação, adiar uma decisão ou tomá-la reconhecendo explicitamente qual informação está faltando.
Um dado incorreto tem uma característica diferente.
Ele pode esconder a incerteza.
Permite que entremos em uma reunião, olhemos para um dashboard e tomemos uma decisão convencidos de que temos evidências.
É isso que o torna perigoso.
Quando o dado está ausente, sabemos que não sabemos. Quando o dado está errado, podemos estar convencidos de que sabemos algo que nunca foi verdade.
Um dado ambíguo pode produzir um efeito semelhante.
O número pode estar correto.
Mas, se pessoas diferentes entendem coisas diferentes ao lê-lo, a organização também não está tomando decisões a partir de uma realidade compartilhada.
Antes de confiar em uma métrica
Com o tempo, desenvolvi algumas perguntas bastante simples que faço quando surge um número importante. Elas não formam um framework sofisticado, nem pretendem substituir um processo formal de governança de dados. São apenas uma maneira de entender o que estou olhando antes de construir uma conclusão a partir daquilo.
- O que exatamente estamos medindo?
- Como isso é calculado?
- Qual é a fonte?
- Qual população está incluída e qual está excluída?
- Qual é o eixo temporal?
- Estamos comparando coisas comparáveis?
- O que existe por trás desse número?
Essa última pergunta se torna especialmente importante quando estamos olhando para médias, agregações ou variações significativas.
Nem sempre precisamos responder a todas elas com o mesmo nível de profundidade. Uma métrica operacional que acompanhamos todos os dias pode exigir um nível de controle diferente de um número que será utilizado para tomar uma decisão de investimento importante.
O nível de confiança que exigimos deveria ser proporcional ao custo de estarmos errados.
Quando duas áreas têm números diferentes, o problema nem sempre é de Data
Quando duas equipes chegam com números diferentes, é tentador enviar o problema para a equipe de Data e pedir que ela determine qual é o "correto".
Às vezes, é exatamente isso que precisa acontecer.
Mas, se o problema é que a organização nunca definiu o que significa "cliente ativo", Data não consegue resolver isso tecnicamente.
Pode mostrar as diferenças.
Pode quantificá-las.
Pode documentá-las.
Pode construir uma única métrica quando existir uma definição acordada.
Mas alguém ainda precisa tomar uma decisão de negócio:
O que queremos dizer quando utilizamos esse termo?
É aqui que entra algo que considero fundamental.
Governança de dados não diz respeito apenas a permissões, catálogos e ferramentas.
Também significa construir uma linguagem compartilhada.
Para que, quando duas pessoas falem em "conversão", "cliente ativo", "venda", "inadimplência" ou "rentabilidade", saibam se realmente estão falando sobre a mesma coisa.
Com IA, o problema muda de escala
Até pouco tempo atrás, muitas dessas discussões terminavam em um dashboard.
Uma pessoa olhava para um número.
Interpretava.
Talvez fizesse uma pergunta.
Talvez percebesse que algo não fazia sentido.
Agora estamos começando a construir algo diferente.
Agentes que consultam informações.
Sistemas que interpretam resultados.
Modelos que recomendam ações.
Automações que executam essas ações diretamente.
E isso aumenta o nível de exigência.
Suponhamos que digamos a um agente:
"Entre em contato com todos os clientes inativos."
Parece uma instrução perfeitamente clara.
Até fazermos a mesma pergunta do início:
O que significa inativo?
Ou imaginemos outra instrução:
"Priorize os clientes de alto risco."
Alto risco segundo qual modelo?
Qual versão?
Com dados de quando?
Sobre qual população o modelo foi construído?
Existe informação mais recente disponível?
E o que exatamente significa "priorizar"?
Quando um analista encontra uma ambiguidade, ele pode levantar a mão e perguntar.
Não deveríamos assumir que um agente fará o mesmo.
Ele pode receber uma definição incompleta, inferir o que está faltando e continuar. E, quando esse sistema também tem capacidade de agir, a ambiguidade deixa de ser apenas um problema analítico.
Ela se transforma em um problema operacional.
Um dashboard com um dado ambíguo pode gerar uma discussão. Um agente com um dado ambíguo pode executar uma decisão.
Isso também muda a forma como penso sobre governança de IA.
Não basta saber quais modelos estamos utilizando, quanto são usados ou quais informações conseguem acessar. Se queremos delegar progressivamente tarefas e decisões, também precisamos entender sobre quais dados esses sistemas estão raciocinando, quais definições recebem e quais ações estão autorizados a executar.
A observabilidade de um agente não deveria terminar em tokens, latência ou quantidade de execuções.
Também deveríamos conseguir reconstruir todo o caminho que levou a uma ação. Algo semelhante à linhagem que há anos tentamos construir em torno dos dados, mas agora aplicada às decisões:
Uma linhagem de decisões.
- Quais informações o sistema recebeu.
- Como interpretou essas informações a partir das definições disponíveis.
- A qual conclusão ou inferência chegou.
- Qual ação executou concretamente sobre o negócio.
Se queremos delegar decisões, também precisamos conseguir reconstruir como elas foram tomadas.
Essa não é apenas uma preocupação teórica. Os frameworks atuais de gestão de risco em IA colocam cada vez mais ênfase em confiabilidade, transparência, mensuração e governança ao longo de todo o ciclo de vida desses sistemas.
A IA não elimina nossos problemas de dados.
Ela pode transformá-los em ações.
Talvez precisemos começar pela linguagem
Durante muito tempo, pensamos que melhorar nossa capacidade de trabalhar com dados significava construir pipelines, warehouses, modelos e dashboards melhores.
Tudo isso continua sendo necessário.
Mas estou cada vez mais convencido de que uma parte importante do problema é muito menos tecnológica.
Precisamos chegar a um acordo sobre o que as coisas significam.
O que é uma venda?
O que é um cliente?
O que significa ativo?
Quando uma conversão começa e termina?
Qual data utilizamos?
O que exatamente representa cada número que colocamos diante de alguém que precisa tomar uma decisão?
No artigo anterior, argumentei que a infraestrutura de dados começa muito antes do data warehouse.
Acho que existe aqui uma ideia complementar:
A qualidade do dado também começa antes do dado. Começa na definição.
Podemos ter a arquitetura perfeita.
Podemos ter pipelines sem erros.
Podemos atualizar informações em tempo real.
Podemos ter modelos extraordinariamente sofisticados.
Mas, se duas pessoas olham para o mesmo termo e entendem coisas diferentes, ainda temos um problema.
E, à medida que delegarmos mais decisões a agentes e sistemas automatizados, essa precisão deixará de ser apenas uma boa prática analítica.
Ela se tornará uma condição necessária para automatizar com confiança.
Porque, no fim, não basta que um número esteja correto.
Também precisamos saber exatamente o que ele significa.
Algumas leituras que acompanham estas ideias
Beyond Accuracy: What Data Quality Means to Data Consumers — Richard Wang e Diane Strong. Um trabalho clássico sobre por que a qualidade dos dados vai muito além de um número estar simplesmente correto.
NIST AI Risk Management Framework. Um framework para pensar sobre confiabilidade e riscos à medida que incorporamos inteligência artificial a processos e decisões.
NIST Generative AI Profile. Uma extensão do framework anterior focada especificamente nos riscos e desafios dos sistemas de IA generativa.