O Pré-processamento Descartou o Sinal em Silêncio

Existe uma etapa nesse tipo de trabalho que quase todo mundo trata como um serviço braçal e enfadonho de faxina: o pré-processamento — a limpeza, o escalonamento e a remodelagem dos seus dados antes que eles cheguem à parte que de fato realiza o aprendizado. Eu o tratei exatamente assim, como uma tarefa neutra a ser despachada antes de o trabalho de verdade começar. Ele não é neutro, e tratá-lo como tal me custou caro. Uma transformação rotineira que apliquei, sem pensar duas vezes, descartou em silêncio justamente a informação de que eu mais precisava, e então passei semanas perplexo com o fato de o sistema parecer cego a algo que estava obviamente ali, à vista de todos.

O tempo todo, eu estava olhando no lugar errado. Eu insistia em interrogar as partes sofisticadas, convencido de que a falha morava em algum lugar dentro da esperteza. A falha havia acontecido muito antes, na parte que eu nem sequer tinha me dado ao trabalho de enxergar como uma decisão.

O pré-processamento parece neutro. Não é.

Quando você normaliza, escalona, suaviza ou remodela dados, aquilo genuinamente parece uma limpeza — como passar um pano na bancada antes de começar a cozinhar. Neutro, higiênico, obviamente correto. Essa sensação é a armadilha, porque cada uma dessas operações é, na verdade, uma decisão: uma decisão sobre qual informação manter e qual informação jogar fora.

O pré-processamento “padrão” é especialmente sedutor aqui, porque a palavra padrão faz com que pareça um valor predefinido neutro e consolidado, em vez de uma escolha. Mas uma transformação padrão é apenas um conjunto de valores predefinidos que alguém, em algum lugar, escolheu para um caso genérico. Embutida em cada uma há uma suposição sobre o que importa e o que não importa — e essas suposições, perfeitamente razoáveis em geral, podem estar redonda e catastroficamente erradas para o seu problema específico. Você herda a suposição sem que ela jamais lhe seja mostrada, porque ela chega disfarçada de rotina.

A transformação que apagou o significado

No meu caso — e vou manter isso genérico de propósito — uma etapa de normalização completamente rotineira teve o efeito de achatar um tipo de informação que, para o meu problema específico, por acaso era justamente a parte significativa. A transformação em si estava correta. Era padrão. Era o tipo de coisa que todo tutorial recomenda como praxe. E, para o meu problema, ela estava apagando o sinal enquanto preservava fielmente o ruído.

Essa foi uma descoberta genuinamente humilhante, porque significava que o modelo nunca havia falhado em aprender, em momento algum. Ele havia sido cegado antes mesmo de os dados chegarem. Eu havia, com minhas próprias mãos, removido a distinção relevante durante a limpeza, e então sentado o sistema diante do resultado esfregado e impecável, perguntando-me por que ele não conseguia ver o que já não estava mais ali.

Você não pode aprender o que não pode ver

Este é o princípio que deveria ter sido óbvio e não foi: o modelo só pode, em qualquer hipótese, trabalhar com aquilo que sobrevive ao pré-processamento. O que quer que suas transformações removam antes de os dados chegarem simplesmente se foi, permanentemente, no que diz respeito a tudo o que vem depois. Nenhuma quantidade de sofisticação posterior consegue recuperar informação que foi apagada antes. Você não pode raciocinar de volta até uma distinção que já apagou.

Então eu tinha invertido todo o esforço. Eu insistia em tentar tornar o modelo mais inteligente, em dar a ele mais capacidade, em ajudá-lo a encontrar o padrão — quando o problema real era que eu havia jogado fora o padrão lá no início e agora pedia ao modelo que redescobrisse algo que eu mesmo havia apagado. É um tipo estranho de crueldade exigir que um sistema encontre o que você já removeu de seu alcance, e depois julgá-lo por não conseguir.

Toda transformação tem perda e tem opinião

A verdade geral por trás disso é que não existe transformação neutra. Toda remodelagem de dados privilegia alguns de seus aspectos e suprime outros; é nisso que transformar dados consiste. O escalonamento, na prática, declara que a magnitude absoluta não importa. A suavização declara que o detalhe de curto prazo não importa. Cada uma é uma opinião sobre o seu problema — uma afirmação sobre o que é sinal e o que é ruído — e cada uma é asseverada em silêncio, como valor predefinido, antes de você ter tido qualquer chance de concordar ou discordar.

Esse silêncio é a parte perigosa. Os valores predefinidos são traiçoeiros precisamente porque você não os vivencia como escolhas. Uma decisão apresentada como tarefa braçal não recebe o escrutínio que uma decisão merece. Você jamais aceitaria “esta parte não importa” como uma afirmação casual sobre o seu problema — mas é exatamente isso que você aceita, sem examinar, toda vez que aplica uma transformação padrão sem perguntar o que ela pressupõe.

Olhe os dados antes e depois

A disciplina que surgiu disso é quase constrangedoramente básica: de fato olhe o que o seu pré-processamento faz com os dados. Compare-os antes e depois de cada etapa. Veja, concretamente, o que mudou e o que desapareceu. Pergunte, para cada transformação: “o que isto acabou de remover, e eu realmente posso me dar ao luxo de perdê-lo?”

É um trabalho tedioso, e parece nitidamente indigno do problema interessante. Mas essa comparação maçante e nada glamourosa é onde algumas das decisões mais consequentes de todo o pipeline são tomadas em silêncio — tomadas por valor predefinido, por inércia, pela recomendação de um tutorial, sem que ninguém de fato decida nada. Escolher olhar é escolher transformar de volta aqueles valores predefinidos silenciosos em escolhas visíveis e examináveis.

As partes que parecem baratas escondem os erros caros

A esta altura do projeto, isso já havia se cristalizado em um padrão que eu via por toda parte. As etapas que parecem baratas e enfadonhas — o pré-processamento, a configuração, os humildes valores predefinidos — são exatamente onde os erros caros e invisíveis se acumulam, precisamente porque é a sua aparente trivialidade que as isenta de escrutínio. As partes glamourosas e difíceis recebem toda a atenção cuidadosa. O encanamento recebe suposições e um dar de ombros.

E o encanamento é por onde a água de fato escorre. Um valor predefinido errado numa etapa enfadonha não se anuncia como importante; ele apenas envenena em silêncio tudo o que vem depois, enquanto cada par de olhos está fixo na maquinaria empolgante lá em cima. O descompasso entre onde os problemas moram e para onde a atenção vai é, estou agora convencido, uma das fontes mais confiáveis de meses desperdiçados em toda essa empreitada.

A lição mais profunda: desconfie da palavra “só”

O que acabei tirando de tudo isso foi uma profunda desconfiança de uma palavrinha: só. É só normalização. É só limpar os dados. É só uma transformação padrão, só pré-processamento, só rotina. Essa palavra, “só”, é precisamente onde o perigo se esconde. Ela é o marcador linguístico de uma etapa sobre a qual você decidiu de antemão não pensar — uma bandeira que você finca no chão para dizer a si mesmo que ali não há nada que valha a pena examinar.

Muitas vezes há, sim, algo ali que vale a pena examinar. Agora, quando algo está falhando de um jeito que não faz sentido, uma das minhas primeiras perguntas já não é, de modo algum, sobre a parte esperta. Ela é: o que foi que eu fiz com estes dados, lá atrás nas etapas enfadonhas, antes de a parte interessante sequer ter a chance de vê-los? Mais de uma vez, a resposta foi que eu joguei fora justamente aquilo que estava procurando, e rotulei o ato de “só uma limpeza”.

— Sem sinais, sem retornos, não é recomendação de investimento.