Antes de Treinar o Modelo: Framework de Cinco Etapas para Auditar se sua Base Aguenta o Projeto de IA

Uma pergunta resolve mais projeto de inteligência artificial do que a escolha da arquitetura do modelo: quantos registros da base têm, ao mesmo tempo, o rótulo correto, as variáveis preenchidas e a garantia de que essas variáveis já existiam no instante em que a decisão precisava ser tomada? Em auditorias de base feitas antes de projetos de classificação, esse número costuma ficar bem abaixo do total que aparece no relatório do banco. Quedas de metade ou mais são comuns quando os três filtros são aplicados juntos — a magnitude varia bastante por setor e por maturidade de coleta, então trate isso como padrão observado, não como percentual fechado.

O framework abaixo é uma sequência de cinco verificações, cada uma com um número de saída. A ordem importa: cada etapa reduz a base que a seguinte examina, e parar na etapa 2 com uma base já inviável economiza semanas de engenharia de features sobre dados que não sustentariam o resultado.

Etapa 1 — Cobertura efetiva: quantas linhas o modelo vai realmente ver

A primeira medição separa registros existentes de registros utilizáveis. Um pedido de crédito arquivado há seis anos existe na tabela, mas se o formulário mudou de campos em 2024, ele não contribui com as mesmas variáveis dos pedidos recentes. O procedimento é simples e quase sempre revelador:

1. Conte o total bruto de registros no período que interessa. Defina o período pela estabilidade do processo, não pela disponibilidade do dado — se a regra de negócio mudou, o corte é ali.
2. Aplique o filtro de completude por variável obrigatória. Para cada campo que o modelo vai usar, meça o percentual de preenchimento; qualquer variável abaixo de 70% de preenchimento é candidata a ser cortada ou tratada como categoria própria.
3. Meça a interseção, não a média. Este é o erro mais frequente da etapa. Cinco variáveis com 90% de preenchimento cada não produzem uma base 90% completa: se as ausências forem independentes, sobram cerca de 59% dos registros com todas as cinco preenchidas. Na prática as ausências são correlacionadas e o número real fica em algum ponto entre 59% e 90%, mas quase nunca perto do topo.

O mercado tende a tratar dado faltante como problema de imputação. Em boa parte dos casos, ausência não é ruído — é sinal. Um campo de renda vazio pode significar que o analista não perguntou porque já tinha decidido negar. Imputar a mediana ali destrói informação e infla artificialmente a performance de treino.

Etapa 2 — Procedência do rótulo: quem decidiu que aquilo é verdade

Modelo supervisionado aprende a reproduzir um rótulo. Se o rótulo foi gerado por um processo enviesado, o modelo aprende o viés com eficiência exemplar. A auditoria de rótulo responde três perguntas antes de qualquer treino.

Quem produziu o rótulo? Rótulo automático (o cliente cancelou ou não cancelou) tem procedência diferente de rótulo humano (o analista marcou como fraude). O segundo carrega a subjetividade e a carga de trabalho de quem marcou. Se três analistas rotularam a base e um deles marcou 40% mais casos positivos que os outros dois, existe uma variável oculta chamada “quem analisou” que o modelo vai capturar.

O rótulo é observável para todos os registros? Aqui mora o viés de seleção mais caro de projetos de crédito e de triagem. Só se sabe se um cliente pagaria se ele recebeu o crédito. A base de treino contém apenas quem passou pelo filtro anterior — e o modelo treinado nela extrapola para uma população que nunca observou. Não há solução puramente estatística; a mitigação envolve reservar uma fatia de decisões aleatórias para gerar rótulo em toda a distribuição, com o custo que isso implica.

Qual a taxa de concordância entre rotuladores? Onde houver julgamento humano, rotule uma amostra em duplicata. Concordância abaixo de 80% em tarefa binária significa que o teto de acurácia do modelo já está definido pela inconsistência do rótulo, e nenhuma arquitetura vai passar disso.

Etapa 3 — Vazamento temporal: o dado existia no momento da decisão?

Esta é a etapa que mais frequentemente explica o modelo que acerta 94% em validação e desaba em produção. A verificação é conceitualmente trivial e operacionalmente trabalhosa: para cada variável, determine o carimbo de tempo em que aquele valor ficou disponível e compare com o carimbo do momento da inferência.

Os vazamentos mais comuns não são grosseiros. Ninguém coloca a variável alvo entre as features por descuido. O que acontece é mais sutil:

• Campo atualizado no lugar de versionado. A tabela de cadastro guarda o status atual do cliente, não o status na data do pedido. Se o campo “situação cadastral” foi sobrescrito depois do evento, ele já contém o desfecho.
• Agregado com janela mal fechada. “Média de compras nos últimos 90 dias” calculada com corte na data de extração, e não na data de cada evento, contamina todos os registros antigos com informação futura.
• Dado de terceiro com atraso de entrega. Um score externo pode existir na base com data de referência de segunda-feira, mas só chegar ao sistema na quinta. Em produção ele não estará lá no momento da decisão.

O teste prático que revela quase todos: treine o modelo, ordene as features por importância e examine as três primeiras. Se alguma delas explica muito mais do que o especialista de negócio esperava, o cenário mais provável não é que o modelo descobriu algo — é vazamento.

Etapa 4 — Aderência à distribuição de produção

A base histórica descreve o passado do processo. O modelo vai operar sobre o presente. Quanto essas duas distribuições diferem determina quanto da performance medida em validação vai sobreviver.

A verificação mínima compara, variável a variável, a distribuição da base de treino com a de uma janela recente de produção — os últimos 30 a 60 dias, tipicamente. Para variáveis numéricas, compare os quartis; para categóricas, compare a frequência relativa das dez categorias mais comuns. Diferenças grandes em variáveis de alta importância exigem decisão explícita: reponderar a base, encurtar o período de treino ou aceitar que o modelo precisará de retreino frequente.

Vale medir também a estabilidade do próprio processo. Se a política comercial mudou em março, dados de janeiro descrevem outro fenômeno. Uma base de três anos que atravessa duas mudanças de política costuma render menos que uma base de dez meses sob regra estável — e essa é uma troca que o time de dados precisa fazer conscientemente, não por acidente.

Etapa 5 — Custo assimétrico do erro e a métrica que decorre dele

A última etapa não olha o dado, olha a decisão. Antes de escolher a métrica de avaliação, é preciso estimar o custo de um falso positivo e o de um falso negativo em unidade comparável — reais, horas de analista, chamados abertos. Sem isso, a discussão sobre limiar de corte vira preferência estética.

Quando os custos são assimétricos — e quase sempre são —, acurácia deixa de significar qualquer coisa. Num problema com 2% de eventos positivos, um modelo que responde “não” para tudo entrega 98% de acurácia e valor zero. A métrica útil nesse cenário é precisão em uma taxa de recall fixada pela capacidade operacional: se a equipe consegue analisar 200 casos por dia, o que importa é a precisão nos 200 casos de maior score, não a área sob a curva.

A recomendação, quando há discordância no time: fixe a métrica pela restrição operacional antes de treinar. Escolher a métrica depois de ver os resultados é o caminho mais curto para justificar um modelo que não resolve o problema.

Como pontuar as cinco etapas e decidir

Cada etapa produz um veredito. A tabela abaixo resume o critério de corte que costuma funcionar como ponto de partida — os limiares devem ser calibrados por contexto, mas servem para tirar a decisão do campo da opinião.

A etapa 3 é a única que funciona como bloqueio absoluto. As outras quatro admitem projeto com ressalva documentada. Vazamento temporal, não: um modelo com vazamento produz um número de performance que não descreve nada e cria expectativa que a operação vai cobrar depois.

Atualmente, com o custo de treinar modelos caindo e a barreira técnica diminuindo, o gargalo dos projetos migrou de forma bem clara da modelagem para a base. Rodar essas cinco verificações consome tipicamente de uma a três semanas de trabalho de um analista com acesso ao dado e a um especialista de negócio. É o investimento com melhor retorno em um projeto de IA aplicada, porque é o único que impede que os meses seguintes sejam gastos otimizando uma métrica que não descreve o problema real.

Perguntas frequentes

Qual o volume mínimo de dados para treinar um modelo? Não existe número universal, e a pergunta melhor formulada é sobre a classe minoritária. Para classificação binária tabular, o gargalo costuma ser a quantidade de exemplos positivos, não o total de linhas. Poucas centenas de casos positivos já permitem um modelo simples com validação honesta; alguns milhares abrem espaço para modelos mais expressivos. Abaixo disso, uma regra de negócio bem calibrada tende a competir de igual para igual — e é mais fácil de auditar.

Dá para pular a auditoria e testar direto em produção com uma fatia pequena? Testar em produção é útil, mas não substitui as etapas 2 e 3. Um teste A/B com rótulo enviesado ou com vazamento vai medir a coisa errada com mais precisão. A auditoria e o teste controlado são complementares: a primeira garante que a métrica significa algo, o segundo mede o efeito real.

Como convencer a diretoria de que a base não está pronta? Com o número da etapa 1. A frase “os dados precisam melhorar” não move orçamento; “temos 41 mil pedidos na base, mas 6,8 mil com todas as variáveis preenchidas na data da decisão, e destes 380 são casos positivos” muda a conversa, porque transforma um julgamento técnico em uma restrição contável.

Modelos de linguagem grandes dispensam esse tipo de auditoria? Dispensam a etapa de rotulagem em massa quando usados sem ajuste fino, mas herdam versões próprias das outras quatro. Cobertura vira qualidade e completude dos documentos recuperados; vazamento vira contaminação do conjunto de avaliação; aderência de distribuição vira diferença entre as perguntas testadas e as perguntas reais dos usuários; e o custo assimétrico do erro continua sendo a decisão que define qual limiar de confiança justifica responder em vez de encaminhar para um humano.