Existe um mito persistente no mundo da inteligência artificial: o de que o segredo do sucesso está em escolher o algoritmo mais sofisticado. Empresas gastam meses a comparar modelos, a discutir arquiteturas, a perseguir a técnica mais recente que viram numa conferência. E, no entanto, os profissionais experientes sabem uma verdade que raramente aparece nos slides: na esmagadora maioria dos projetos, o que decide o resultado não é o algoritmo — são os dados que lhe damos, e sobretudo a forma como os preparamos. A esse trabalho chama-se feature engineering, e é talvez a competência mais valiosa e menos glamorosa de toda a ciência de dados.
A ideia é simples de enunciar e difícil de dominar. Um modelo de machine learning não vê o mundo como nós; vê apenas os números que lhe entregamos, a que se chama "features" ou variáveis. Feature engineering é a arte de transformar os dados em bruto nas variáveis certas — as que capturam o que realmente importa para o problema. É o trabalho de traduzir a realidade numa linguagem que o modelo consiga aprender. E é aqui, muito mais do que na escolha do algoritmo, que se ganham ou perdem os projetos.
Porque os dados certos valem mais que o algoritmo
Imagina dois cenários. No primeiro, tens um algoritmo topo de gama, dos mais avançados que existem, mas alimenta-lo com variáveis pobres, que não descrevem bem o problema. No segundo, tens um algoritmo modesto e simples, mas alimenta-lo com variáveis ricas, cuidadosamente construídas para capturar os padrões relevantes. Na prática, o segundo cenário vence quase sempre. Um bom conjunto de features torna o problema tão claro que até um modelo simples o resolve; um mau conjunto torna-o tão confuso que nem o modelo mais avançado o salva.
Esta é uma das razões por que os concursos de ciência de dados são ganhos, tão frequentemente, por quem investe mais tempo a preparar os dados do que a afinar modelos. O algoritmo é uma mercadoria — está disponível para todos, gratuito, com um clique. As features certas, essas, dependem de conhecimento do problema, criatividade e trabalho paciente. É aí que reside a verdadeira vantagem, e é por isso que copiar o modelo de outra empresa raramente basta: falta o feature engineering feito à medida do teu problema.
O que é, na prática, criar uma boa feature
Criar uma feature é transformar dados em bruto em algo mais informativo para o modelo. A partir de uma data de compra, podes extrair o dia da semana, se foi feriado, quantos dias passaram desde a última compra do cliente — variáveis que dizem muito mais do que a data em si. A partir de um histórico de transações, podes calcular médias, tendências, frequências. Cada uma destas transformações injeta no modelo conhecimento que ele, sozinho, não descobriria a partir do dado cru.
É neste trabalho que o conhecimento do negócio se torna ouro. Quem conhece bem o problema sabe que sinais importam. Um especialista em retalho sabe que a recência da última compra prevê melhor o abandono do que o total gasto; um especialista em manutenção sabe que não é a temperatura de um sensor que importa, mas a rapidez com que ela sobe. Estas intuições, traduzidas em features, valem mais do que qualquer afinação de algoritmo — porque dão ao modelo os olhos certos para ver o problema.
As transformações mais comuns
- Extrair componentes: de uma data, tirar dia da semana, mês, estação; de um endereço, a região.
- Agregar histórico: transformar muitas transações num resumo — média, total, frequência, tendência — por cliente ou produto.
- Criar rácios e diferenças: muitas vezes a relação entre dois valores diz mais do que cada um isolado (margem, taxa de crescimento).
- Codificar categorias: transformar texto (o país, o tipo de produto) em números que o modelo consiga processar sem inventar ordens que não existem.
O reverso da moeda: features a mais também prejudicam
Se boas features ajudam, seria tentador concluir que quantas mais, melhor. Mas não é assim. Variáveis irrelevantes ou redundantes introduzem ruído, tornam o modelo mais lento e mais difícil de interpretar, e podem até levá-lo a "aprender" padrões que são coincidência e não realidade. A arte não está em criar o máximo de features, mas as certas — e ter a disciplina de descartar as que não acrescentam sinal. Menos features, bem escolhidas, batem uma avalanche de variáveis sem critério.
Há também um risco subtil e perigoso, o "data leakage": criar uma feature que, sem querer, contém informação que só existiria depois de o resultado ser conhecido. O modelo parece brilhante nos testes, porque está a espreitar a resposta, e depois falha redondamente na realidade. Evitar esta armadilha exige pensar com cuidado sobre que informação estaria realmente disponível no momento em que a previsão é feita — outro ponto em que o conhecimento do problema é insubstituível.
Um caso concreto
Uma empresa de subscrições queria prever que clientes iam cancelar. A primeira equipa focou-se em testar algoritmos cada vez mais complexos sobre as variáveis que já tinha — o total gasto por cada cliente, o plano contratado, a data de adesão. Os resultados eram medíocres e não melhoravam por mais que se trocasse de modelo. Uma segunda abordagem mudou o foco: em vez de perseguir algoritmos, investiu em construir features melhores a partir do comportamento dos clientes. Criaram variáveis como a tendência de utilização nas últimas semanas (a subir ou a descer), o número de dias desde a última vez que o cliente usou o serviço, e a variação no número de contactos com o apoio. Com estas novas features — e o mesmo algoritmo simples que antes dava resultados fracos — a capacidade de prever o abandono deu um salto enorme. O que mudou não foi a inteligência do modelo, foi a qualidade dos olhos que lhe deram para ver o problema. A equipa percebeu, tarde mas a tempo, que tinha andado a afinar o instrumento errado.
Onde investir o esforço
A lição prática é clara e liberta muita gente da ansiedade de "ter de dominar o último algoritmo": na maioria dos projetos, o esforço rende muito mais investido em compreender o problema e construir boas features do que em perseguir a técnica mais recente. Um algoritmo padrão, bem estabelecido, alimentado por features cuidadas, resolve a grande maioria dos casos empresariais. A sofisticação do modelo é o último passo, não o primeiro — e muitas vezes um passo que nem sequer é preciso dar.
Na prática
Se um projeto de machine learning não está a dar os resultados esperados, resiste ao impulso de trocar de algoritmo à procura de magia. Pergunta primeiro: as variáveis que estou a dar ao modelo capturam mesmo o que importa para este problema? Muitas vezes, a resposta está em construir features melhores a partir dos dados que já tens, com a ajuda de quem conhece o negócio a fundo. O teu próximo avanço em IA está mais provavelmente numa boa feature do que num algoritmo mais complexo — já olhaste com atenção para os dados que estás a dar ao modelo?
