Só pra complementar: Pegadinhas de Engenharia de Features

Esse post não vem de nenhuma seção obrigatória do lab, é o que sobrou depois que eu separei o essencial de engenharia de features e overfitting no post principal. Curiosamente, essa é a primeira vez que eu consigo mostrar de verdade a solução pro problema que o post anterior só diagnosticou.

Normalizo depois de criar a feature, não antes

A ordem importa. Se eu normalizasse $x$ primeiro e só depois elevasse ao quadrado, chegaria em $\left(\frac{x-\mu}{\sigma}\right)^2$, que não é a mesma feature que normalizar $x^2$ direto. As duas funcionam, mas produzem colunas diferentes, e a segunda ordem (criar a feature, normalizar depois) é a que eu uso desde o post principal.

Já adianto o final feliz: o RMSE das duas ordens acaba praticamente igual, então relaxa, não é um erro grave se você inverter. O motivo é que $\left(\frac{x-\mu}{\sigma}\right)^2$ dá pra abrir em $\frac{x^2 - 2\mu x + \mu^2}{\sigma^2}$, que é só uma combinação linear de $x^2$, $x$ e uma constante, três coisas que o modelo já tem à disposição (o próprio $x$ e o viés $b$). Ou seja, normalizar antes ou depois não muda o que o modelo consegue representar, só reescreve a mesma função numa base de coordenadas diferente. O que muda de verdade é a escala dos pesos e a velocidade com que o gradiente descendente converge até eles, não o resultado final. (Detalho a conta inteira no Exercício 2, lá embaixo, se quiser ver isso na régua.)

Features polinomiais são extremamente colineares

$x$, $x^2$ e $x^3$ carregam quase a mesma informação num intervalo estreito. Isso deixa a matriz $\mathbf{X}^\top\mathbf{X}$ mal condicionada. Calculei a razão entre a amplitude cru da maior e da menor coluna por grau:

No grau 13 essa razão já está perto do limite de precisão do ponto flutuante de 64 bits (~2.2×10⁻¹⁶ de precisão relativa). Não é exagero dizer que a matriz crua nesse grau está no limiar da singularidade numérica.

E "mal condicionada" não é só um adjetivo assustador, tem uma consequência bem concreta pro peso que sai do ajuste. Resolver a equação normal envolve, no fundo, inverter essa matriz, e quando ela está quase singular, essa inversão se parece muito com dividir por um número quase zero: um tremelique pequeno no numerador (um pouquinho de ruído nos dados, um arredondamento de ponto flutuante) vira uma resposta gigante e instável do outro lado. Na prática, isso significa que dois conjuntos de dados quase idênticos podem produzir pesos $w_j$ completamente diferentes, às vezes com sinais opostos se cancelando quase perfeitamente, mesmo que a curva final prevista pareça igualzinha. Os pesos individuais deixam de significar algo confiável, só a combinação deles ainda presta.

Normalizar (o que meu componente do post principal já faz por baixo dos panos) melhora isso em várias ordens de grandeza, mas não resolve a colinearidade intrínseca entre as potências, só a diferença de escala entre elas. Pra colinearidade de verdade, o remédio é regularização, que eu mostro mais embaixo.

Guardo $\mu$ e $\sigma$, sempre

Bati nessa tecla no post de normalização e bato de novo aqui: sem guardar a média e o desvio-padrão do treino, não dá pra normalizar nenhum dado novo do mesmo jeito, e o modelo vira enfeite. Todo componente que eu construí pra esse post guarda isso internamente antes de prever qualquer coisa.

Mais features nunca piora o erro de treino

Isso não é coincidência, é praticamente um teorema: acrescentar uma coluna só amplia o espaço de modelos possíveis, então o mínimo do custo de treino só pode cair ou empatar, nunca subir. Por isso erro de treino sozinho não serve pra escolher a complexidade do modelo, sempre precisa de um conjunto separado (o que eu já mostrei no post principal).

Engenharia de feature não é só potência

Potência é o exemplo didático mais fácil de mostrar. No mundo real, as features mais úteis costumam vir de conhecimento de domínio: raiz quadrada, log, razões, produtos entre colunas. Testei isso com um alvo $y=\sqrt{x}$:

Uma única feature $\sqrt{x}$ zera o erro com 2 parâmetros, enquanto três potências gastam 4 parâmetros e ainda erram. Conhecimento de domínio vale mais que força bruta.

Domando o overfitting: regularização

O post principal terminou com uma pergunta em aberto: dá pra manter toda a flexibilidade de um grau alto sem pagar o preço do overfitting? A resposta é regularização L2, ou Ridge. Em vez de escolher um grau discreto, eu adiciono uma penalidade contínua $\lambda$ que castiga pesos grandes:

$J_{ridge}(\mathbf{w}, b) = J(\mathbf{w}, b) + \lambda \sum_j w_j^2$

Por que isso funciona, na prática? Um polinômio de grau alto decorando 10 pontos de treino precisa, em algum lugar da curva, subir muito rápido e descer muito rápido pra passar exatamente em cima de cada ponto ruidoso, e isso só é possível se alguns pesos $w_j$ ficarem enormes (frequentemente com sinais opostos se cancelando na maior parte do domínio, e "descancelando" bem na hora de fazer aquela curva colar num ponto específico). Se eu simplesmente proíbo os pesos de ficarem grandes demais, cobrando um preço ($\lambda \sum_j w_j^2$) proporcional ao tamanho deles ao quadrado, a curva perde a capacidade física de fazer essas curvas fechadas em volta de cada ponto individual. Ela é forçada a "escolher" uma tendência mais suave que passa perto da maioria dos pontos, em vez de exatamente em cima de cada um, o que é outra forma de dizer: ela para de decorar o ruído e passa a acompanhar o sinal.

Implementei isso na minha própria solução exata (somando $\lambda$ à diagonal de $\mathbf{X}^\top\mathbf{X}$, excluindo o viés, que é exatamente a forma fechada que o Ridge do scikit-learn resolve por baixo dos panos). Não tenho scikit-learn instalado nesse ambiente, mas aqui está o equivalente calculado de verdade, não só o princípio: mesmo caso ruidoso de 10 pontos, grau 9, do post principal, variando $\lambda$:

Repara no padrão: sem regularização o treino vai a zero (10 parâmetros pra 10 pontos, ajuste exato) e o teste é o pior de todos. Conforme $\lambda$ cresce, o treino piora e o teste melhora, até um ponto ($\lambda \approx 0.01$ aqui) onde o teste passa a piorar de novo porque o modelo já ficou rígido demais. É o mesmo trade-off viés-variância do post principal, só que controlado por um botão contínuo em vez da escolha discreta de grau.

Testa você mesmo, arrastando $\lambda$:

Repara como a curva para de decorar cada ponto de treino e vira parecida com o formato verdadeiro assim que $\lambda$ sai de zero, sem eu precisar mexer no grau.

Exercícios

Tenta antes de abrir a resposta.

Exercício 1: descubra a transformação

Gere y = 3 * log(x + 1) + 2 pra x de 0 a 19. Ajusta (a) só com x, (b) com x, x², x³ e (c) com log(x+1). Compara os RMSE.

Exercício 2: a ordem da normalização importa?

Compara ajustar zscore(x)² contra zscore(x²). Os RMSE finais são iguais? E os pesos?

Exercício 3: quantos pontos são necessários?

Mantendo o grau 13, repete a análise treino/teste com 40, 100 e 500 pontos em $[0, 19]$. O overfitting some?

Exercício 4: interações entre variáveis

Com duas variáveis de entrada, features polinomiais de grau 2 geram x1, x2, x1², x1x2, x2². O termo x1x2 é uma interação. Constrói um alvo em que a interação seja essencial (y = x1 * x2) e mostra que um modelo sem ela falha.

Exercício 5: critério de parada honesto

Se eu tivesse usado gradiente descendente em vez de solução exata, como eu pararia de forma confiável?