Existe un mito persistente en el mundo de la inteligencia artificial: el de que el secreto del éxito está en elegir el algoritmo más sofisticado. Las empresas gastan meses comparando modelos, discutiendo arquitecturas, persiguiendo la técnica más reciente que vieron en una conferencia. Y, sin embargo, los profesionales experimentados saben una verdad que rara vez aparece en las diapositivas: en la abrumadora mayoría de los proyectos, lo que decide el resultado no es el algoritmo — son los datos que le damos, y sobre todo cómo los preparamos. A ese trabajo se le llama feature engineering, y es quizás la competencia más valiosa y menos glamorosa de toda la ciencia de datos.
La idea es simple de enunciar y difícil de dominar. Un modelo de machine learning no ve el mundo como nosotros; ve solo los números que le entregamos, llamados "features" o variables. El feature engineering es el arte de transformar los datos en bruto en las variables correctas — las que capturan lo que realmente importa para el problema. Es el trabajo de traducir la realidad a un lenguaje que el modelo pueda aprender. Y es aquí, mucho más que en la elección del algoritmo, donde se ganan o pierden los proyectos.
Por qué los datos correctos valen más que el algoritmo
Imagina dos escenarios. En el primero, tienes un algoritmo de gama alta, de los más avanzados que existen, pero lo alimentas con variables pobres, que no describen bien el problema. En el segundo, tienes un algoritmo modesto y simple, pero lo alimentas con variables ricas, cuidadosamente construidas para capturar los patrones relevantes. En la práctica, el segundo escenario vence casi siempre. Un buen conjunto de features hace el problema tan claro que hasta un modelo simple lo resuelve; un mal conjunto lo hace tan confuso que ni el modelo más avanzado lo salva.
Esta es una de las razones por las que los concursos de ciencia de datos los gana, tan a menudo, quien invierte más tiempo en preparar los datos que en afinar modelos. El algoritmo es una mercancía — está disponible para todos, gratis, a un clic. Las features correctas, en cambio, dependen del conocimiento del problema, la creatividad y el trabajo paciente. Ahí reside la verdadera ventaja, y por eso copiar el modelo de otra empresa rara vez basta: le falta el feature engineering hecho a la medida de tu problema.
Qué es, en la práctica, crear una buena feature
Crear una feature es transformar datos en bruto en algo más informativo para el modelo. A partir de una fecha de compra, puedes extraer el día de la semana, si fue festivo, cuántos días pasaron desde la última compra del cliente — variables que dicen mucho más que la fecha en sí. A partir de un histórico de transacciones, puedes calcular promedios, tendencias, frecuencias. Cada una de estas transformaciones inyecta en el modelo conocimiento que él, solo, no descubriría a partir del dato crudo.
Es en este trabajo donde el conocimiento del negocio se vuelve oro. Quien conoce bien el problema sabe qué señales importan. Un experto en retail sabe que la recencia de la última compra predice mejor el abandono que el total gastado; un experto en mantenimiento sabe que no es la temperatura de un sensor lo que importa, sino la rapidez con que sube. Estas intuiciones, traducidas en features, valen más que cualquier afinación de algoritmo — porque dan al modelo los ojos correctos para ver el problema.
Las transformaciones más comunes
- Extraer componentes: de una fecha, sacar día de la semana, mes, estación; de una dirección, la región.
- Agregar histórico: transformar muchas transacciones en un resumen — promedio, total, frecuencia, tendencia — por cliente o producto.
- Crear ratios y diferencias: muchas veces la relación entre dos valores dice más que cada uno aislado (margen, tasa de crecimiento).
- Codificar categorías: transformar texto (el país, el tipo de producto) en números que el modelo pueda procesar sin inventar órdenes que no existen.
El reverso de la moneda: demasiadas features también perjudican
Si las buenas features ayudan, sería tentador concluir que cuantas más, mejor. Pero no es así. Variables irrelevantes o redundantes introducen ruido, hacen el modelo más lento y más difícil de interpretar, y pueden incluso llevarlo a "aprender" patrones que son coincidencia y no realidad. El arte no está en crear el máximo de features, sino las correctas — y tener la disciplina de descartar las que no aportan señal. Menos features, bien elegidas, ganan a una avalancha de variables sin criterio.
Hay también un riesgo sutil y peligroso, el "data leakage": crear una feature que, sin querer, contiene información que solo existiría después de conocer el resultado. El modelo parece brillante en las pruebas, porque está espiando la respuesta, y luego falla rotundamente en la realidad. Evitar esta trampa exige pensar con cuidado sobre qué información estaría realmente disponible en el momento en que se hace la predicción — otro punto en que el conocimiento del problema es insustituible.
Un caso concreto
Una empresa de suscripciones quería predecir qué clientes iban a cancelar. El primer equipo se centró en probar algoritmos cada vez más complejos sobre las variables que ya tenía — el total gastado por cada cliente, el plan contratado, la fecha de adhesión. Los resultados eran mediocres y no mejoraban por más que se cambiara de modelo. Un segundo enfoque cambió el foco: en vez de perseguir algoritmos, invirtió en construir mejores features a partir del comportamiento de los clientes. Crearon variables como la tendencia de uso en las últimas semanas (subiendo o bajando), el número de días desde la última vez que el cliente usó el servicio, y la variación en el número de contactos con el soporte. Con estas nuevas features — y el mismo algoritmo simple que antes daba resultados flojos — la capacidad de predecir el abandono dio un salto enorme. Lo que cambió no fue la inteligencia del modelo, fue la calidad de los ojos que le dieron para ver el problema. El equipo se dio cuenta, tarde pero a tiempo, de que había estado afinando el instrumento equivocado.
Dónde invertir el esfuerzo
La lección práctica es clara y libera a mucha gente de la ansiedad de "tener que dominar el último algoritmo": en la mayoría de los proyectos, el esfuerzo rinde mucho más invertido en comprender el problema y construir buenas features que en perseguir la técnica más reciente. Un algoritmo estándar, bien establecido, alimentado por features cuidadas, resuelve la gran mayoría de los casos empresariales. La sofisticación del modelo es el último paso, no el primero — y muchas veces un paso que ni siquiera hace falta dar.
En la práctica
Si un proyecto de machine learning no está dando los resultados esperados, resiste el impulso de cambiar de algoritmo buscando magia. Pregunta primero: ¿las variables que le estoy dando al modelo capturan de verdad lo que importa para este problema? Muchas veces, la respuesta está en construir mejores features a partir de los datos que ya tienes, con la ayuda de quien conoce el negocio a fondo. Tu próximo avance en IA está más probablemente en una buena feature que en un algoritmo más complejo — ¿ya miraste con atención los datos que le estás dando al modelo?
