A premissa cara que sustenta a arquitetura
Toda a infraestrutura de dados contemporânea foi desenhada sobre uma premissa específica: transformar dados é caro. Movimentar, limpar, juntar e normalizar consome tempo de engenharia e recurso de máquina, e por isso a arquitetura se organiza para transformar o mínimo possível. Modelos normalizados, camadas intermediárias, pipelines que evitam recomputação. Cada uma dessas escolhas é uma resposta racional a esse custo.
Vale lembrar como essas premissas envelhecem. Houve uma época em que computação era mais cara que armazenamento, e a arquitetura refletia isso. Depois a computação ficou abundante, depois mais rápida, e a cada mudança as ferramentas ficaram para trás, porque foram desenhadas para a restrição anterior. A história da engenharia de dados é uma sequência de arquiteturas ótimas para um mundo que já não existe.
Se a transformação deixa de ser o item caro, a pergunta muda de lugar. Não é mais como transformar menos, e sim o que exatamente transformar, para responder a qual pergunta. E aí aparece um problema que nenhuma capacidade computacional resolve: a maioria dos dados armazenados não sabe para que vai servir.
Não existe um esquema universal
A explicação mais comum para migrações e ontologias fracassarem é falta de adesão. É verdade e é insuficiente. Mesmo que toda a organização fosse migrada instantaneamente para um modelo único, o modelo único não existiria.
Existem pelo menos quatro esquemas operando ao mesmo tempo, e nenhum deles é opcional.
O primeiro é o da fonte: o que o sistema de origem consegue registrar, com que precisão, e sob quais condições. O segundo é o do armazenamento: há um limite físico para o que se pode gravar, e esse limite impõe perdas silenciosas. O terceiro é o da decisão: por que essa informação está sendo capturada. O quarto, que costuma passar despercebido, é o das premissas de quem interpreta, incluindo as do modelo.
O ponto decisivo é que ninguém conhece os quatro simultaneamente. Há exatamente um momento em que eles se tornam compatíveis: quando a decisão é feita.
Considere a entidade mais básica de qualquer modelo: o cliente. Para o faturamento, cliente é quem paga. Para o suporte, é quem abre chamado. Para a conformidade, é por quem a empresa responde. As três definições são corretas e incompatíveis. Nenhuma delas é a verdadeira, porque a pergunta que a torna verdadeira ainda não foi feita. No instante em que a pergunta existe, por exemplo se este pedido deve ser reembolsado, a definição necessária fica óbvia.
O esquema nasce na pergunta
Se o esquema depende da pergunta, então transformar dados não é aplicar um modelo preexistente. É uma operação de composição: pegar o contexto em que a informação foi registrada e combiná-lo com o contexto da decisão que se quer tomar. O resultado dessa composição é o que torna o dado útil, e ele é específico daquela pergunta.
Isso reposiciona o trabalho de modelagem. Em vez de projetar a estrutura definitiva antes de saber o que será perguntado, constrói-se a transformação quando a pergunta aparece, preservando duas coisas junto com ela: o contexto de origem e a evidência que sustenta o resultado.
Preservar esses dois itens é o que permite reutilizar. Um esquema construído para uma pergunta específica, com o contexto rotulado e a evidência anexada, deixa de ser descartável quando a mesma pergunta reaparece em outro conjunto de dados. E esquemas assim não competem entre si: cada um é válido dentro do escopo que declara, desde que o escopo esteja explícito.
A consequência prática é que a qualidade da modelagem passa a depender menos de acertar a estrutura e mais de registrar por que aquela estrutura foi escolhida.
O agente sempre responde
Durante muito tempo, uma equipe de dados podia escolher não produzir um número. Se a amostra era pequena demais para sustentar uma conclusão, a decisão correta era não calcular. Um número mal fundamentado é pior que nenhum número, porque no momento em que existe ele passa a defender um resultado.
Essa opção praticamente desapareceu. Um agente interativo não devolve silêncio. Ele responde, responde rápido, e responde com confiança proporcional ao pedido, não à evidência disponível. O efeito é que os erros deixam de ser pontuais e passam a se acumular: cada resposta plausível vira insumo da próxima, e uma sessão de trabalho pode produzir uma cadeia inteira de transformações erradas que ninguém vai auditar porque cada elo parecia razoável.
O agente errar seria administrável. O que desorganiza é a assimetria entre a facilidade de produzir e a dificuldade de verificar.
O erro vem das premissas
A classe de falha mais frequente em trabalho de dados assistido por modelo não é falta de capacidade de raciocínio. É premissa não declarada.
O modelo chega com crenças sobre como o mundo deveria estar. Ele espera que um certo termo apareça escrito de uma forma, e quando o arquivo usa outra variante, ele não levanta a mão: ele interpreta o que encontrou como a coisa mais próxima que faz sentido para ele, e segue. Um campo que deveria ter um significado é contado como outro, sem aviso.
O caso dos formatos de data é o exemplo mais limpo do mecanismo. O modelo testa os formatos que conhece, o arquivo usa um formato que não está na lista, e o resultado é uma percentagem altíssima de campos vazios. As contagens de linhas batem. Os totais batem. As validações de esquema passam. Nada acusa erro, porque o erro foi cometido exatamente na etapa que as validações não cobrem.
Há uma variante mais perigosa, porque envolve julgamento e não sintaxe. Valores negativos em uma coluna de valores financeiros parecem redundantes para um olho desatento, e transformá-los em valor absoluto parece uma limpeza razoável. O sinal, porém, era o dado. O que era um saldo devedor vira dívida multiplicada, agora com aparência de consistência, e múltiplos modelos concordando com o resultado porque todos compartilham a mesma premissa.
Modelos maiores não corrigem isso de forma automática. Em alguns casos pioram, porque se apegam às próprias crenças com mais firmeza e defendem com mais eloquência uma interpretação que já estava errada na origem.
Cruzar premissas em vez de confiar em sensação
Se a falha vem de premissa compartilhada, a defesa mais eficiente é não compartilhar premissa. Colocar dois modelos de linhagens diferentes para responder à mesma pergunta e olhar onde eles discordam transforma confiança difusa em superfície de inspeção.
O padrão observado em trabalho desse tipo é consistente: quando dois modelos de origens distintas concordam, a taxa de acerto é muito alta; quando discordam, os erros se concentram ali. Tratar a discordância como ruído a suprimir desperdiça o sinal mais útil que ela produz: a lista do que precisa de olho humano.
Isso reduz o problema a uma classe menor, ainda que persistente. Modelos treinados a partir do mesmo material tendem a compartilhar as mesmas convenções, então concordam por motivo errado. A diversidade de linhagem importa mais que a diversidade de tamanho.
Há também uma correção que não custa modelo nenhum e que costuma ser subestimada: reescrever a pergunta. Se um critério de prova não foi explicitado, o modelo decide por conta própria o que conta como evidência suficiente, e uma resposta negativa confiante pode ser apenas a aplicação de um critério mais estrito do que o pretendido. Dizer explicitamente o que conta como prova muda o resultado sem trocar modelo, sem mudar limite e sem aumentar orçamento.
O que fazer na prática
Primeiro, pare de tratar o modelo de dados definitivo como pré-requisito. Defina o esquema quando a pergunta existir, e registre junto o contexto de origem e a evidência que sustenta cada resultado.
Segundo, defina a superfície de falha antes de começar. Não é possível otimizar o que não pode falhar de forma observável, e a maior parte dos erros caros acontece em etapas que nenhuma validação cobre. Um conjunto pequeno com verificação manual estabelece o piso contra o qual o resto será medido.
Terceiro, orçe a verificação como parte do trabalho, não como sobra. Verificar custa mais que produzir, e o custo cai à medida que o pipeline madura, porque a estrutura construída para uma pergunta é reaproveitável na seguinte.
Quarto, separe os papéis. Projetar o pipeline e executar dentro dele exigem modelos com características opostas: um precisa de raciocínio lento e denso, o outro de custo baixo, velocidade e repetibilidade. Misturar os dois na mesma chamada é a origem de boa parte da ineficiência.
A inteligência barata não elimina o problema de modelar dados. Ela remove a desculpa de não modelar, o que é diferente e mais exigente: agora o gargalo é saber qual pergunta está sendo respondida, e essa informação não está em nenhum arquivo.
