Ingeniería de variables: construir lo que el modelo mira

Hay una frase que circula entre quienes llevan años poniendo modelos en producción y que al principio suena exagerada: dale buenas variables a un modelo mediocre y ganará a un modelo brillante con variables malas. Después de ver suficientes proyectos reales, deja de sonar exagerada. El algoritmo que elijas (bosque, boosting, el que sea) importa menos de lo que la gente cree. Lo que de verdad decide si un modelo funciona es qué le das de comer: las variables, las columnas, lo que el modelo tiene delante para mirar. Y esas variables casi nunca vienen listas; hay que construirlas. Ese trabajo tiene nombre: ingeniería de variables (en inglés feature engineering).

Que esto sea verdad choca con la imagen romántica del trabajo con datos, donde lo que brilla es el algoritmo ingenioso. La realidad es más terrena: la mayor parte del tiempo de un proyecto que acaba funcionando no se va en elegir el modelo, se va en entender los datos y en preparar las variables que el modelo necesita. En las competiciones de datos, donde todo el mundo tiene acceso a los mismos algoritmos y los mismos datos de partida, quien gana no suele ser quien usa un modelo más exótico, sino quien construyó las variables que a los demás no se les ocurrieron. El modelo es casi un bien común; las variables son donde está la ventaja. Interiorizar eso cambia dónde pones tu esfuerzo, y por eso esta lección y las dos siguientes importan tanto como las de los modelos.

La idea es sencilla de enunciar y difícil de dominar: a partir de las columnas que tienes, creas columnas nuevas que le ponen más fácil al modelo encontrar el patrón. No inventas datos de la nada; recombinas y transformas lo que ya hay para que la señal, que estaba escondida, salga a la superficie. Cada buena variable que construyes es una relación que el modelo ya no tiene que descubrir por su cuenta: se la das hecha, y el modelo puede dedicar su esfuerzo a lo que de verdad no sabe.

Conviene empezar entendiendo por qué los datos casi nunca vienen en la forma que al modelo le conviene. Las columnas que tienes se recogieron para operar un negocio, no para alimentar un modelo: una fecha se guarda porque hay que saber cuándo pasó algo, un importe porque hay que facturarlo, un código postal porque hay que enviar un paquete. Nadie los diseñó pensando en que algún día servirían para predecir. Así que lo normal es que la información que de verdad discrimina esté ahí, pero repartida, enterrada o en una forma que al modelo le cuesta aprovechar. El trabajo de ingeniería de variables es, en esencia, traducir los datos del idioma en que se recogieron al idioma en que el modelo los entiende mejor.

Y aquí es donde entra algo que las máquinas todavía no tienen y tú sí: el conocimiento del dominio. Saber que la gente cobra a fin de mes, que las ventas suben los fines de semana, que un pedido de muchas unidades baratas no es lo mismo que uno de pocas caras, que en invierno se consume distinto que en verano. Nada de eso está escrito en los datos de forma explícita; está en tu cabeza o en la de quien conoce el negocio, y es lo que te permite construir la variable que al modelo le ahorra descubrir una regla por su cuenta. Por eso la ingeniería de variables es, de todas las partes de este oficio, la que más depende de entender el problema real y menos de la técnica pura.

## De una fecha salen diez variables

Piensa en una columna de fechas de compra. Para un modelo, una fecha en bruto es casi inútil: un número grande que crece con el tiempo y no dice nada sobre el comportamiento. Pero dentro de esa fecha hay oro escondido. ¿Qué día de la semana es? Las ventas de un sábado no se parecen a las de un martes. ¿Es festivo? ¿Es principio o fin de mes, cuando la gente cobra? ¿Qué mes, para captar la estacionalidad? ¿Cuántos días han pasado desde la última compra de ese cliente? De una sola columna de fecha puedes extraer un puñado de variables, y cada una le cuenta al modelo algo que la fecha en bruto le ocultaba.

Lo mismo pasa combinando columnas. Si tienes el importe total de un pedido y el número de unidades, el precio unitario (importe dividido entre unidades) suele significar mucho más que las dos columnas por separado: distingue un pedido grande de muchas cosas baratas de un pedido pequeño de algo caro, y esa distinción puede ser justo lo que separa a un cliente de otro. Dos columnas combinadas en una razón con sentido valen más que las dos sueltas.

Las razones y proporciones son, de hecho, una de las fuentes de buenas variables más fiables, porque capturan algo relativo que los valores absolutos esconden. Piensa en un comercio que quiere detectar devoluciones sospechosas: el número de devoluciones de un cliente, suelto, dice poco, porque quien compra mucho devuelve más en términos absolutos sin que haya nada raro. Pero la proporción de devoluciones sobre compras lo pone todo en su sitio: devolver tres de cada cuatro pedidos es una señal, hagas tres pedidos o trescientos. Lo mismo con el gasto por visita, los errores por cada mil operaciones, las ventas por metro cuadrado de una tienda. Cuando notes que una cifra solo tiene sentido comparada con otra, ahí hay una variable esperando a ser construida.

Otra familia de variables muy útil nace de resumir el pasado de cada caso. Si predices algo sobre clientes y tienes su historial, puedes construir cuántas compras lleva, cuánto suma su gasto acumulado, cuántos días han pasado desde la última vez que apareció, con qué frecuencia media vuelve. Esas variables de historial condensan en pocos números un comportamiento que de otro modo estaría disperso en cientos de filas, y suelen ser de las más predictivas que existen, porque el mejor indicio de lo que alguien hará mañana es a menudo lo que ha hecho hasta hoy. Eso sí, son justo las que más fácil llevan a la trampa que veremos enseguida, porque mirar el pasado y mirar el futuro se parecen peligrosamente cuando no tienes cuidado con las fechas.

Lo que el diagrama muestra y conviene retener es la dirección del trabajo: de pocas columnas en bruto salen varias con sentido, no al revés. Una fecha se abre en día de la semana, fin de semana, mes; dos columnas numéricas se funden en una razón. No es magia ni estadística avanzada: es conocer el problema lo bastante bien para saber qué cálculo hace visible lo que importa.

## Por qué una buena variable le ahorra trabajo al modelo

Un modelo con árboles puede, en teoría, descubrir él solo que lo que importa es el precio unitario: le bastaría con aprender a dividir el importe entre las unidades a base de muchas preguntas encadenadas. Pero eso le cuesta esfuerzo y datos, y a menudo no llega del todo. Si tú le das el precio unitario ya calculado, se ahorra ese descubrimiento y puede usar su capacidad para lo demás. Es la diferencia entre darle a alguien un plano o pedirle que deduzca el plano caminando por el edificio: con el plano llega antes y mejor.

Hay un tipo de variable que casi ningún modelo deduce solo y que tú tienes que darle hecho: las variables de categorías. Una columna como el método de pago, con valores tarjeta, transferencia o contra reembolso, no es un número, y la mayoría de los modelos solo entienden números. La forma habitual de traducirla es crear una columna por cada valor posible, que vale uno si la fila es de ese valor y cero si no; se llama codificación one-hot, y es ingeniería de variables pura y necesaria. Sin ella, una columna de texto es invisible para el modelo o, peor, se interpreta mal si le pones números arbitrarios que sugieren un orden que no existe. Convertir lo categórico en algo que el modelo pueda leer es uno de los pasos de preparación más comunes, y conviene saber que es parte de este trabajo.

Esto se nota especialmente cuando la relación que importa no es una línea recta. Un modelo lineal, por ejemplo, solo sabe sumar y restar variables con pesos; no sabe dividir una por otra. Si la señal está en una razón entre dos columnas, un modelo lineal con las columnas crudas no la verá por mucho que lo entrenes, mientras que el mismo modelo con la razón ya calculada la aprovecha de inmediato. Lo verás con tus propios ojos en los ejercicios: la misma señal, el mismo modelo, y un salto de acierto que viene solo de haber construido la variable adecuada.

## El peligro que ya conoces: una variable del futuro es fuga

Aquí hay una trampa que debes vigilar, y es exactamente la fuga de datos que ya aprendiste a cazar, con disfraz de variable nueva. Cuando construyes una variable, tienes que preguntarte si, en el momento real en que el modelo tendría que predecir, ese dato ya existiría. Si la respuesta es no (si la variable usa información que solo se conoce después de que ocurra lo que intentas predecir), estás construyendo una fuga. El modelo acertará maravillosamente en tus pruebas y fracasará en producción, porque en producción esa variable no estará disponible todavía.

Un ejemplo típico: quieres predecir si un cliente va a cancelar su suscripción, y construyes una variable fecha_de_cancelacion o lo decides a partir de ella. Esa variable solo existe cuando el cliente ya ha cancelado; en el momento de predecir no la tendrías. Es la columna envenenada de siempre. La regla práctica es dibujar una línea en el tiempo: el momento de la predicción, y todo lo que esté a su derecha (lo que pasa después) está prohibido como variable. Construir variables es poderoso justamente porque te deja crear lo que el modelo mira, y por eso mismo te deja crear una fuga sin querer.

Las fugas de este tipo son especialmente traicioneras porque se disfrazan de éxito. El modelo con una variable del futuro no acierta un poco más: acierta sospechosamente bien, porque le has dado, sin querer, una pista que contiene parte de la respuesta. Y esa cifra brillante es justo lo que apaga tu desconfianza y te hace cerrar el trabajo contento. Por eso un acierto demasiado bueno debería dispararte una alarma en lugar de una celebración: cuando un modelo parece casi perfecto en un problema que sabes que es difícil, la primera hipótesis no es que seas un genio, es que hay una fuga escondida en alguna variable. Comprobarlo antes de presumir del resultado es lo que separa a quien lleva tiempo en esto de quien está a punto de llevarse un disgusto en producción.

El caso más sutil no es una columna que grita futuro, sino una que lo contiene de forma indirecta. Imagina que para predecir si un pedido se entregará tarde construyes el número de llamadas al servicio de atención relacionadas con ese pedido. Suena legítimo, pero piénsalo: la mayoría de esas llamadas se hacen porque el pedido ya iba tarde, así que la variable es, en realidad, una consecuencia de lo que intentas predecir y no una causa anterior. En el momento de predecir, cuando el pedido acaba de salir, esas llamadas aún no existen. Detectar estas fugas indirectas exige preguntarse, para cada variable, no solo si el dato existe, sino cuándo se genera en relación con lo que predices. Es un hábito mental que se entrena, y el ejercicio de clasificar de esta lección está hecho justo para empezar a entrenarlo.

## Hazlo bien: construir sin contaminar

Un último cuidado técnico. Cuando una variable se construye con un cálculo que mira el conjunto de los datos (por ejemplo, restar la media de una columna, o escalar por su máximo), ese cálculo debe hacerse solo con el entrenamiento, nunca con todos los datos juntos. Si calculas la media sobre el conjunto completo antes de partir, la media ya ha visto la prueba, y eso contamina. Es la segunda cara de la fuga que ya conoces, la del orden de las operaciones. Las transformaciones sencillas que no miran al resto de filas (extraer el día de una fecha, dividir dos columnas de la misma fila) son seguras; las que resumen el conjunto exigen la misma disciplina de partir primero y calcular después.

La forma de no equivocarte nunca con esto es la misma que ya has visto para otras transformaciones: meter la construcción de variables dentro de un Pipeline que aprenda sus parámetros solo con el entrenamiento en cada paso de la validación. Así, cuando una variable necesita una media, una escala o una categoría codificada, esos valores se calculan con los datos de entrenamiento de ese momento y se aplican a los de validación o prueba sin que estos hayan participado en el cálculo. Es la diferencia entre decidir cómo transformar mirando solo lo que ya conoces y decidirlo haciendo trampa con lo que deberías tener tapado. Cuando dudes de si una transformación contamina, hazte la pregunta de siempre: ¿este cálculo ha mirado alguna fila de la prueba? Si la respuesta es sí, hay fuga.

Vale la pena cerrar con una idea de proporción, porque es fácil obsesionarse creando variables sin fin. No se trata de generar cientos de columnas por si acaso: eso trae de vuelta los problemas de las variables que sobran, que verás a continuación. Se trata de crear unas pocas con sentido, guiadas por lo que sabes del problema, y comprobar con tu validación honesta si de verdad aportan. Una variable que no mejora la cifra en datos nuevos no es una buena variable por mucho que a ti te parezca ingeniosa. La ingeniería de variables buena es artesanía con criterio, no producción en masa: pocas piezas bien pensadas valen más que un almacén lleno de columnas que nadie ha comprobado.

## El cierre: has aprendido a crear; ahora, a quitar

Acabas de ver que crear variables puede ser lo que más mejore un modelo. Pero existe el problema contrario, y es igual de real: a veces no faltan variables, sobran. Un montón de columnas que no aportan nada no solo no ayudan, estorban, porque añaden ruido, invitan al sobreajuste y hacen el modelo más lento y más difícil de explicar. Saber cuáles quitar es tan importante como saber cuáles crear, y es lo que viene a continuación.