Feature Engineering: El siguiente paso después de preparar los datos
Existen muchas etapas que debemos recorrer antes de iniciar el entrenamiento de un modelo de Machine Learning. En las entregas pasadas de esta saga hemos trabajado en la exploración de los datos: identificamos outliers, detectamos columnas sin sentido, valores duplicados y comprendimos, en cierta medida, la distribución de los datos.
Esta es una etapa inicial y fundamental dentro del trabajo de cualquier científico de datos.
En nuestro caso, los datos provienen de un origen bastante controlado, ya que se trata de un ejercicio meramente didáctico. No obstante, en escenarios reales los orígenes de datos pueden ser muy variados: tablas, archivos PDF, bases de datos transaccionales, logs, entre otros. Por esta razón, la preparación de los datos suele ser una tarea laboriosa y altamente iterativa.
Este es solo el inicio del camino. Una vez que contamos con los datos crudos debidamente preparados, podemos avanzar al siguiente paso: el proceso de selección y construcción de features, conocido como Feature Engineering.
En esta etapa, el objetivo es ir un paso más allá y enriquecer el dataset, transformándolo en un conjunto de datos más representativo, consistente y adecuado para su uso en modelos de Machine Learning.
Para lograrlo, no basta con aplicar técnicas de forma mecánica. Es fundamental comprender la teoría que respalda el Feature Engineering, ya que las decisiones que tomamos en esta fase impactan directamente en:
- La calidad del modelo
- Su capacidad de generalización
- La reutilización futura de los datos
🔁 Un proceso altamente iterativo
Como verán, estos procesos son altamente iterativos. Y aunque pueda parecer que ya hemos “limpiado nuestro set de datos”, la realidad es que se requieren más iteraciones para convertirlo en un conjunto verdaderamente adecuado para que un modelo logre aprender de forma precisa.
Y algo muy importante: debemos presentar los features de la manera más apropiada posible.
Es por esto que en las siguientes secciones hablaremos de Feature Engineering y continuaremos preparando el dataset. Al final, no tendremos simplemente datos curados: los habremos transformado en features.
🧠 Feature Engineering – Comprendiendo lo que implica
El Feature Engineering no es un término elegante ni una práctica cosmética dentro de un pipeline de Machine Learning; es una de las fases con mayor impacto técnico en el desempeño final del modelo.
En términos prácticos, la capacidad predictiva de un algoritmo está fuertemente condicionada por la calidad, relevancia y representatividad de las variables con las que aprende.
Al igual que la etapa de preparación de datos —donde exploramos distribuciones, detectamos outliers, tratamos valores nulos y eliminamos inconsistencias— el Feature Engineering es inherentemente iterativo. No es un paso lineal que se ejecuta una sola vez; implica ciclos continuos de:
- Hipótesis
- Transformación
- Validación
- Ajuste
📚 Conceptos base
En aprendizaje supervisado:
- Feature: cada variable o atributo que se entrega al modelo como entrada durante el entrenamiento.
- Label (o variable objetivo): la variable que deseamos predecir.
Las features constituyen el espacio de representación del problema. Es sobre ellas que el modelo identifica patrones, estima relaciones y construye su función de predicción.
🎴 Aplicado a nuestro ejemplo práctico
En nuestro caso:
| Tipo | Variable | Descripción |
|---|---|---|
| Feature | Rareza | Nivel de rareza asociado a la carta |
| Feature | Costo máximo | Valor máximo del rango de costo |
| Feature | Costo mínimo | Valor mínimo del rango de costo |
| Label | Costo de la carta | Variable numérica que deseamos predecir |
🔎 Punto clave: El modelo no aprende directamente del “concepto” de una carta, sino de cómo representamos matemáticamente sus atributos.
🔬 ¿Qué abarca el Feature Engineering?
Desde una perspectiva técnica, el Feature Engineering incluye principalmente:
1️⃣ Selección de variables relevantes
Eliminación de ruido y reducción de dimensionalidad para conservar únicamente aquellas variables con verdadera capacidad explicativa.
2️⃣ Transformación de variables existentes
- Escalamiento (normalización o estandarización).
- Codificación de variables categóricas (One-Hot Encoding, Target Encoding, etc.).
- Transformaciones matemáticas (logarítmica, polinómica, interacción entre variables).
3️⃣ Creación de nuevas features (Feature Construction)
Generación de variables derivadas que capturen mejor la señal del problema, por ejemplo:
- Variables agregadas.
- Indicadores binarios derivados de umbrales.
El objetivo es mejorar las entradas para que el modelo capture la estructura real del problema y no lo carguemos simplemente con ruido.
🎯 ¿Qué ganamos con una correcta aplicación?
1️⃣ Reducción de costos computacionales
Un conjunto de features optimizado reduce dimensionalidad innecesaria, lo que implica:
- Menor tiempo de entrenamiento.
- Menor consumo de memoria.
- Menor costo de cómputo (especialmente relevante en entornos cloud).
2️⃣ Mejora del rendimiento del modelo
Seguramente han escuchado la frase: garbage in, garbage out.
En Machine Learning, esto es especialmente relevante.
Features bien diseñadas ayudan a:
- Mejorar la relación señal–ruido.
- Reducir el overfitting.
- Mejorar la capacidad de generalización.
💡 Pro Tip: En muchos escenarios prácticos, una mejora en la calidad de las features tiene mayor impacto que cambiar de algoritmo.
🧩 ¿Cuál es la naturaleza del problema?
Las transformaciones y estrategias dependen directamente de la naturaleza del problema. Algunos tipos comunes son:
📈 Problema de regresión
Cuando el objetivo es predecir un valor numérico continuo (por ejemplo, el valor de un auto, un inmueble o una carta).
El modelo estima una función:
f(X) → y donde y ∈ ℝ
🏷️ Problema de clasificación
Cuando el objetivo es predecir una categoría discreta (por ejemplo, fraude vs. no fraude, correo auténtico vs. spam).
Aquí el modelo aprende fronteras de decisión en el espacio de features.
Puede tratarse de:
- Clasificación binaria
- Clasificación multiclase
En ambos casos, el objetivo es la categorización.
Cada tipo de problema impone distintos criterios de evaluación, distintas transformaciones y distintas consideraciones estadísticas.
🏁 En síntesis
El Feature Engineering es el puente entre los datos crudos y la capacidad de realizar predicciones reales y efectivas.
De nada sirve un modelo sofisticado si está alimentado con malas features.
🔄 Feature Transformation
Las técnicas de transformación que apliquemos dependen directamente del tipo de dato con el que estemos trabajando y del objetivo del modelo. No intento desarrollar una tesis exhaustiva sobre el tema, sino establecer criterios técnicos que nos permitan tomar decisiones informadas al momento de convertir un dataset en un conjunto de features útiles.
En Feature Transformation no existen recetas de cocina. La elección correcta depende de múltiples factores:
- La naturaleza del problema (regresión o clasificación).
- La distribución de los datos.
- El volumen de información disponible.
- El algoritmo que utilizaremos.
- Restricciones operativas como costo o latencia.
La transformación no es un proceso automático. En una ocasión formé parte de un equipo que recibió un dataset con el histórico de ventas de los últimos 14 años. A primera vista parecía un volumen considerable; sin embargo, al analizar la frecuencia real de transacciones por año, el tamaño efectivo de muestra era limitado.
Esto impactaba directamente las decisiones de transformación y modelado, ya que ciertas técnicas requieren suficiente densidad estadística para aportar valor real.
🧮 Transformaciones por tipo de variable
📊 Datos numéricos o cuantitativos
Pueden ser discretos o continuos y suelen requerir tratamiento cuando presentan:
- Diferencias significativas de escala.
- Distribuciones altamente asimétricas.
- Presencia de outliers.
- Valores faltantes.
Técnicas comunes:
- Imputación (media, mediana, modelos predictivos).
- Escalado (Min-Max o estandarización Z-score).
- Transformaciones logarítmicas o de potencia para reducir sesgo.
🏷️ Datos categóricos o cualitativos
Representan atributos no numéricos y requieren conversión a formato numérico antes del entrenamiento.
Se clasifican en:
- Nominales: no poseen orden inherente (por ejemplo, tipo de carta o categoría).
- Ordinales: existe un orden lógico entre categorías (por ejemplo, nivel de rareza).
Técnicas utilizadas:
- One-Hot Encoding para variables nominales.
- Ordinal Encoding cuando el orden tiene significado real.
- Target Encoding, con especial cuidado para evitar data leakage.
Una mala codificación puede introducir relaciones artificiales o sesgos en el modelo, por lo que esta decisión debe ser cuidadosamente evaluada.
🧾 Datos de texto e imágenes
No pueden ser utilizados directamente por la mayoría de los algoritmos tradicionales y requieren transformaciones más sofisticadas.
En texto:
- Bag of Words
- TF-IDF
- Embeddings
En imágenes:
- Extracción de vectores de características.
- Representaciones generadas por redes convolucionales.
En ambos escenarios, el objetivo es transformar datos no estructurados en representaciones numéricas que capturen información semántica relevante.
Existen numerosas técnicas adicionales. Me centraré principalmente en aquellas que utilicé en el esquema práctico del artículo y compartiré un listado de las más relevantes según el tipo de dato trabajado.
⚙️ Técnicas aplicadas y justificación técnica
El dataset base presenta una combinación de variables numéricas y categóricas, además de valores extremos que, tras el análisis exploratorio, no correspondían a ruido sino a comportamientos inherentes al dominio del problema.
Este punto es crítico: no todo outlier debe eliminarse.
En algunos casos representa señal relevante, y removerlo podría introducir sesgo o pérdida de información.
A continuación, detallo las transformaciones aplicadas según el tipo de dato, junto con su justificación.
🏷️ Técnicas aplicadas a datos categóricos
🔹 One-Hot Encoding
El One-Hot Encoding se utiliza cuando trabajamos con variables categóricas nominales, es decir, aquellas donde no existe un orden inherente entre sus categorías.
Asignar valores numéricos directos (por ejemplo, 1, 2, 3) a este tipo de variable introduce un orden artificial que el modelo puede interpretar como relación de magnitud, generando sesgos en el aprendizaje.
La técnica consiste en:
- Crear una columna binaria por cada categoría posible.
- Asignar valor 1 cuando la categoría está presente.
- Asignar valor 0 cuando no lo está.
🧪 Ejemplo práctico
Supongamos el atributo type_1 de un Pokémon, cuyos valores posibles son:
Fire, Water, Grass.
Después de aplicar One-Hot Encoding, la representación se transforma de la siguiente manera:
| Pokémon | type_1_Fire | type_1_Water | type_1_Grass |
|---|---|---|---|
| Personaje 1 | 1 | 0 | 0 |
| Personaje 2 | 0 | 1 | 0 |
| Personaje 3 | 0 | 0 | 1 |
Nota: Los personajes de Pokémon se utilizan con fines exclusivamente didácticos.
✅ Resultado de la transformación
Con esta técnica:
- No se introduce un orden implícito entre categorías.
- Cada categoría es tratada como una dimensión independiente.
- Se evita que el modelo asuma relaciones inexistentes (por ejemplo, que Fire sea “mayor” que Water).
Si en lugar de esto se hubieran asignado valores secuenciales (1, 2, 3), un modelo lineal podría interpretar diferencias de magnitud entre categorías, lo cual no refleja la naturaleza real del dato.
⚠️ Consideración sobre cardinalidad
En este ejemplo, el atributo presenta baja cardinalidad, es decir, un número reducido de categorías posibles. En estos escenarios, One-Hot Encoding es una técnica apropiada y computacionalmente manejable.
Sin embargo, cuando trabajamos con variables de alta cardinalidad (por ejemplo, cientos o miles de categorías únicas), esta técnica puede:
- Incrementar excesivamente la dimensionalidad.
- Aumentar el riesgo de overfitting.
- Elevar el costo computacional.
Este tipo de escenarios requiere estrategias alternativas.
🔢 Ordinal Encoding
Aunque esta técnica no fue aplicada en el dataset del caso práctico —porque no existían variables categóricas con orden inherente— es importante mencionarla, ya que forma parte del conjunto fundamental de herramientas en Feature Transformation.
El Ordinal Encoding se utiliza cuando trabajamos con variables categóricas ordinales, es decir, cuando el orden entre las categorías tiene significado semántico y forma parte de la naturaleza del dato.
A diferencia de las variables nominales, en este escenario asignar valores numéricos no introduce un sesgo artificial, siempre que el orden refleje correctamente la jerarquía real del atributo.
🧪 Ejemplo práctico
Un ejemplo clásico es el nivel de riesgo crediticio dentro del dominio financiero. Las categorías presentan un orden natural explícito definido por el negocio.
Por ejemplo:
- Low Risk = 1
- Medium Risk = 2
- High Risk = 3
Mediante Ordinal Encoding, cada categoría se transforma en un valor numérico que preserva la jerarquía del riesgo. De esta forma, el modelo puede interpretar correctamente que un cliente clasificado como High Risk representa mayor riesgo que uno Medium Risk.
Es importante notar que el objetivo no es modelar una distancia exacta entre categorías, sino capturar la relación de orden.
⚠️ Consideraciones técnicas importantes
Al aplicar Ordinal Encoding, se debe validar cuidadosamente que:
- El orden asignado refleje fielmente la estructura del dominio.
- La codificación no introduzca interpretaciones erróneas de distancia si el modelo es sensible a magnitudes (por ejemplo, modelos lineales).
- No se asuma que la diferencia entre 1 y 2 es equivalente a la diferencia entre 2 y 3, salvo que la representación real del problema lo respalde.
En síntesis, el Ordinal Encoding es una técnica adecuada cuando el orden es parte intrínseca del dato.
De haber existido y sido relevante la evolución del personaje (primera, segunda o tercera evolución), esta técnica habría sido apropiada.
💡 Pro Tip: La clave no está en convertir categorías en números, sino en respetar la semántica real del problema.
📊 Técnicas para datos numéricos
Las variables numéricas suelen concentrar gran parte de la señal predictiva, pero también son las que más fácilmente pueden introducir sesgos si no se transforman adecuadamente.
A continuación, presento un resumen de las técnicas más relevantes y posteriormente profundizaremos en las utilizadas en el caso práctico.
📋 Resumen de técnicas
| # | Técnica | ¿Qué hace? | ¿Cuándo aplicar? | Fórmula |
|---|---|---|---|---|
| 1 | Imputation | Sustituye valores nulos o ausentes | Datos con valores faltantes | Media, mediana, moda o valor constante |
| 2 | Log / Log1p | Reduce asimetría y comprime valores extremos | Variables long-tail, precios, conteos | log1p(x) = ln(1 + x) |
| 3 | Standardization | Centra y escala por desviación estándar | Modelos sensibles a escala (regresión, PCA) | (x − μ) / σ |
| 4 | Min-Max Scaling | Escala a un rango fijo (ej. 0–1) | Cuando se requiere preservar proporciones | (x − min) / (max − min) |
| 5 | Robust Scaling | Usa estadísticos robustos frente a outliers | Datos con valores extremos frecuentes | (x − mediana) / IQR |
| 6 | Clipping / Capping | Limita valores extremos a umbrales definidos | Control de outliers por reglas de negocio | x = min(max(x, l), u) |
| 7 | Binning | Convierte variables continuas en intervalos | Capturar relaciones no lineales | Discretización por rangos |
🧮 Imputation (Imputación de valores faltantes)
La imputación es una de las primeras transformaciones que deben abordarse en cualquier pipeline de Feature Engineering. Muchos algoritmos de Machine Learning no manejan valores nulos de forma nativa; ignorarlos o eliminar registros indiscriminadamente puede reducir el tamaño efectivo de la muestra y alterar la distribución original de los datos.
La elección del método debe basarse en la distribución de la variable y en el contexto del dominio.
🧪 Ejemplo: impacto de media vs mediana
Supongamos una variable que representa el valor de venta (en miles):
[10, 12, 11, 13, 12, 200]
Aquí existe un valor extremo (200).
Cálculo de la media
Media = (10 + 12 + 11 + 13 + 12 + 200) / 6
Media = 258 / 6 = 43
Cálculo de la mediana
Ordenando los valores:
[10, 11, 12, 12, 13, 200]
La mediana es el promedio de los valores centrales (12 y 12):
Mediana = 12
🔎 Observación técnica
- La media (43) se ve fuertemente desplazada por el outlier.
- La mediana (12) representa mejor el comportamiento típico del conjunto.
Si imputáramos valores faltantes usando la media, estaríamos introduciendo un valor artificialmente alto respecto a la mayoría de los datos. En cambio, la mediana preserva mejor la tendencia central cuando la distribución es asimétrica o presenta valores extremos.
📌 Técnicas de imputación más utilizadas
Imputación por la media
Adecuada cuando la distribución es aproximadamente normal y no existen outliers significativos.Imputación por la mediana
Más robusta ante asimetrías y valores extremos. Es una de las más utilizadas en datasets reales.Imputación por la moda
Más común en variables categóricas o discretizadas.Imputación con valor constante
Útil cuando el valor faltante tiene significado propio (por ejemplo, “sin historial”).Imputación basada en modelos (KNN, regresión)
Utiliza la relación entre variables para estimar valores faltantes de forma más informada. Es más compleja, pero potencialmente más precisa.
⚠️ Consideración crítica
La imputación no es una simple operación matemática; introduce supuestos estadísticos sobre la distribución de los datos. Cada método modifica la varianza, la media o incluso la estructura de correlación entre variables.
Por ello, la decisión debe alinearse con:
- La naturaleza estadística de la variable.
- El volumen de datos disponibles.
- El impacto que puede tener en el modelo final.
- El contexto del negocio.
Una imputación mal elegida puede distorsionar la señal original más que los valores faltantes que intenta corregir.
📉 Transformaciones logarítmicas (log / log1p)
Las transformaciones logarítmicas son ampliamente utilizadas en Feature Engineering para reducir la asimetría (skewness) de variables numéricas y comprimir valores extremos.
Resultan especialmente útiles cuando una pequeña fracción de observaciones concentra valores significativamente más altos que el resto, situación común en precios, conteos, ingresos o métricas de uso.
En el análisis del dataset de cartas Pokémon, esta técnica fue aplicada durante la estandarización de los precios. La distribución presentaba un comportamiento long-tail: la mayoría de las cartas tenía precios bajos o moderados, mientras que unas pocas alcanzaban valores considerablemente altos.
Sin una transformación adecuada, estos valores extremos podrían dominar el entrenamiento y distorsionar el ajuste del modelo, especialmente en algoritmos sensibles a magnitudes.
🔎 ¿Qué es log1p?
La transformación log1p se define como:
log1p(x) = ln(1 + x)
Se prefiere sobre la transformación tradicional ln(x) por varias razones técnicas:
- Permite manejar valores iguales a cero sin generar errores matemáticos.
- Ofrece mayor estabilidad numérica en rangos pequeños.
- Es adecuada para distribuciones long-tail típicas en precios, ingresos o conteos.
Mientras que ln(0) es indefinido, ln(1 + 0) = 0, lo que evita problemas durante el preprocesamiento.
🧪 Ejemplo práctico
Supongamos los siguientes precios:
x = [0, 5, 20, 100, 1000]
Al aplicar la transformación:
| Valor original (x) | log1p(x) = ln(1 + x) |
|---|---|
| 0 | 0.000 |
| 5 | 1.792 |
| 20 | 3.045 |
| 100 | 4.615 |
| 1000 | 6.909 |
📊 Interpretación del resultado
Observaciones clave:
- El valor 0 no genera errores.
- Las distancias entre valores altos se comprimen significativamente.
- El orden relativo se mantiene (1000 sigue siendo mayor que 100).
- La distribución resultante es más balanceada y menos sesgada.
Por ejemplo:
- Diferencia original entre 100 y 1000 → 900
- Diferencia después de log1p → aproximadamente 2.29
Esto reduce la dominancia de valores extremos sin perder información ordinal.
🎯 Casos de uso típicos
Las transformaciones logarítmicas son especialmente útiles en:
- Costos y precios.
- Volúmenes de transacciones.
- Frecuencia de eventos.
- Métricas financieras o de uso acumulativo.
En términos prácticos, aplicar log1p no elimina la señal de valores altos; la reescala para que el modelo pueda aprender patrones más estables.
Es una transformación matemática simple, pero con impacto significativo en estabilidad y capacidad de generalización.
🛠️ Camino al dataset model-ready
Seré muy honesta: aplicar transformaciones dentro de la herramienta es, en sí mismo, un proceso operativo sencillo. Basta con seleccionar la transformación, elegir la técnica adecuada y definir los parámetros correspondientes. Desde el punto de vista técnico, el flujo es claro y accesible.
Lo verdaderamente complejo no es la herramienta, sino el manejo del dataset.
Cuando trabajamos con datos reales, aparecen inevitablemente los desafíos propios de entornos productivos:
- Valores inconsistentes.
- Registros mal tipados.
- Categorías mal formateadas.
- Outliers que no son ruido, sino comportamiento legítimo del negocio.
- Casos excepcionales que no resultan evidentes en una primera revisión.
Es durante la construcción del flujo cuando se hace evidente que existen factores no considerados inicialmente. Esto obliga a iterar: revisar, ajustar, deshacer transformaciones, validar nuevamente y reconstruir el pipeline.
Este proceso iterativo no es señal de error, sino parte natural del ciclo de ingeniería de datos.
💡 Pro Tip: Antes de aplicar cualquier transformación estructural —como un One-Hot Encoding— es indispensable revisar los datos exhaustivamente.
Herramientas como Data Wrangler incorporan capacidades de análisis visual que permiten observar distribuciones, detectar anomalías y validar supuestos antes de modificar el espacio de features.
En mi caso particular, identifiqué un único valor numérico dentro de una variable categórica que había pasado desapercibido. Ese solo registro fue suficiente para provocar un error durante la aplicación del One-Hot Encoding.
Este tipo de situaciones refuerza una lección fundamental: la calidad del encoding depende directamente de la limpieza previa del dato.
🧩 Tratamiento de la variable extrarity
En el dataset, extrarity es una variable categórica relevante para el modelo. Sin embargo, presenta un 10,32 % de valores nulos, lo que obliga a intervenirla antes de aplicar cualquier técnica de codificación.
Dado que su cardinalidad es baja, el One-Hot Encoding es una técnica adecuada y no genera una expansión excesiva del espacio de características.
1️⃣ Tratamiento de valores nulos
El primer paso consistió en crear una categoría explícita para los valores faltantes, asignando el valor: unknown
Esta decisión técnica permite:
- Evitar la pérdida de registros.
- Preservar el tamaño de muestra.
- Hacer explícita la ausencia de información.
- Permitir que el modelo determine si la falta de dato tiene valor predictivo.
Es importante entender que un valor faltante no siempre es irrelevante; en ciertos contextos, la ausencia de información puede estar correlacionada con el comportamiento objetivo.
Para implementarlo, se agregó una transformación visual en Data Wrangler destinada al manejo de valores nulos, especificando el reemplazo por la categoría definida.
Con esto, se garantiza consistencia antes de aplicar el One-Hot Encoding en etapas posteriores del pipeline.
🔄 Aplicación de One-Hot Encoding
Una vez tratados los valores faltantes en extrarity, la variable queda lista para aplicar One-Hot Encoding sin riesgo de errores derivados de nulos o inconsistencias tipológicas.
En esta etapa es fundamental definir correctamente el formato de salida (output style), ya que esta decisión impacta la interpretabilidad, la reutilización y la integración del dataset en etapas posteriores del pipeline.
📦 Selección del formato de salida
En este caso, se seleccionó el formato columnar, por las siguientes razones:
- El formato vectorial suele emplearse en escenarios de deep learning o en pipelines cerrados donde la interpretabilidad no es prioritaria y el consumo lo realiza directamente un modelo.
- El formato columnar es preferido cuando las features deben ser:
- Interpretables.
- Reutilizables.
- Persistidas en un Feature Store.
- Inspeccionadas por equipos de datos o negocio.
En términos prácticos, “salida en columnas” significa que cada categoría se convierte en una columna independiente, manteniendo un prefijo asociado al nombre original de la variable.
Por ejemplo, si la variable es extrarity, las nuevas columnas podrían materializarse como:
extrarity_commonextrarity_rareextrarity_ultra_rareextrarity_unknown
🧭 Buenas prácticas
Conservar el prefijo del nombre original de la variable no es un detalle menor. Esta práctica:
- Facilita la trazabilidad de las features.
- Mejora la legibilidad del dataset transformado.
- Reduce ambigüedad cuando existen múltiples variables categóricas.
- Simplifica el mantenimiento y la reutilización en otros modelos o proyectos.
En entornos productivos, donde múltiples pipelines conviven, la nomenclatura consistente es parte de la gobernanza de datos.
💡 Pro Tip: Es prácticamente inevitable realizar ajustes durante la construcción del pipeline.
En Data Wrangler no es posible insertar directamente un nodo intermedio en la vista visual sin que se genere una nueva rama del flujo.
La forma correcta de aplicar una corrección consiste en:
- Ir a la vista Data.
- Localizar el listado de transformaciones aplicadas.
- Crear el nuevo paso intermedio.
- Reordenarlo arrastrándolo hasta la posición adecuada dentro del flujo. Este enfoque permite mantener un pipeline limpio, reproducible y coherente, evitando bifurcaciones innecesarias que puedan dificultar la trazabilidad del proceso de transformación.
Veamos ahora como se ven las columnas
El nuevo flujo es este como pueden ver no hay errores
🔐 La importancia de la llave primaria antes de registrar en el Feature Store
Después de aplicar las transformaciones sobre las variables categóricas y numéricas, el siguiente paso fue registrar el dataset en el Feature Store para definir explícitamente qué columnas correspondían a features y cuáles no.
Fue en ese momento cuando surgió un problema crítico: el dataset no contaba con una llave única por registro.
Un Feature Store requiere identificar cada entidad de forma inequívoca. Si no es posible distinguir cada fila de manera única, no se puede:
- Versionar correctamente los datos.
- Actualizar registros sin ambigüedad.
- Garantizar integridad en entrenamiento e inferencia.
- Evitar sobrescrituras accidentales.
En otras palabras, sin clave primaria, el pipeline pierde trazabilidad y consistencia.
🔎 Identificación del problema
Al revisar el dataset en detalle, se evidenció que no existía una columna que identificara de forma única cada carta. Esto implicaba que, aunque las features estuvieran correctamente transformadas, el registro en el Feature Store sería inconsistente.
Era necesario crear una llave compuesta, pero no podía ser arbitraria. La clave debía construirse a partir de atributos que, combinados, garantizaran unicidad real dentro del dominio.
🧩 Construcción de la llave compuesta
Al recorrer el dataset, cada carta contenía:
product_idextNumber
Si bien product_id por sí solo no era único, la combinación con extNumber —que representa una numeración del tipo ###/###— sí permitía diferenciar cada carta de forma inequívoca.
Se creó entonces una nueva columna llave compuesta:
card_id = product_id + "_" + extNumber
Esta columna:
- No es una feature.
- No participa en el entrenamiento del modelo.
- No aporta señal predictiva.
- Su propósito es exclusivamente identificador.
Sin embargo, es fundamental para la arquitectura del sistema.
🧹 Eliminación de duplicados
La validación de la nueva llave reveló registros duplicados en el dataset. Esto confirmaba que el problema no era solo la ausencia de clave primaria, sino también la presencia de filas repetidas.
Por lo tanto, fue necesario:
- Validar la unicidad de la nueva llave.
- Eliminar registros duplicados.
- Confirmar que cada fila representara una entidad única.
Solo después de garantizar integridad y unicidad, el dataset quedó en condiciones adecuadas para su registro en el Feature Store.
💡 Pro Tip:
Antes de optimizar features, debemos garantizar identidad e integridad de la entidad.
Un modelo puede estar estadísticamente bien construido, pero si la estructura de identificación es incorrecta, todo el trabajo previo pierde validez operacional.
En este caso,card_idno es una feature, pero es el pilar que permite que todas las features tengan contexto y consistencia dentro del sistema.
📦 Exportación a S3
Aunque Data Wrangler permite continuar el flujo directamente en Canvas, en este laboratorio se optó por exportar el dataset a Amazon S3 para mantener control explícito sobre los datos y preparar las features para su registro en el Feature Store.
Se seleccionó el formato Parquet, adecuado para:
- Almacenamiento columnar eficiente.
- Compresión optimizada.
- Compatibilidad con procesos analíticos y entrenamiento.
🏗 Feature Store como cierre arquitectónico del pipeline
Una vez que las variables fueron limpiadas, imputadas, transformadas y validadas, surge una pregunta fundamental desde una perspectiva de producción:
¿Cómo garantizamos que estas mismas transformaciones se mantengan consistentes en futuros reentrenamientos y en escenarios de inferencia?
Aquí es donde el uso de un Feature Store deja de ser opcional y se convierte en una decisión arquitectónica.
📚 ¿Qué es un Feature Store?
Un Feature Store es un componente dentro de la arquitectura de Machine Learning cuyo propósito es:
- Centralizar features ya transformadas.
- Versionarlas y gobernarlas.
- Servirlas de forma consistente para entrenamiento e inferencia.
- Separar la ingeniería de features del código del modelo.
En entornos AWS, este rol lo cumple Amazon SageMaker Feature Store, que permite administrar features como activos de primera clase dentro del ciclo de vida del modelo.
El beneficio principal es eliminar riesgos clásicos como:
- Data leakage por transformaciones inconsistentes.
- Desalineación entre entrenamiento y producción.
- Reprocesamiento manual repetitivo.
🗂 Feature Group: la unidad lógica
Dentro del Feature Store existe un concepto clave: el Feature Group, que es la unidad lógica donde se almacenan las features asociadas a una entidad.
Si el Feature Store es el repositorio central, el Feature Group es la “tabla estructurada” que contiene:
- El identificador único de la entidad (Record Identifier).
- El timestamp del evento (Event Time).
- El conjunto de features relacionadas.
💡 Pro Tip:
Un Feature Group funciona conceptualmente como una tabla versionada con control temporal.
Al crearlo, se deben definir explícitamente:
Record Identifier Name
En este caso:card_id
→ Identifica de forma única cada carta.Event Time Feature Name
→ Permite versionar las features en el tiempo.Feature Definitions
→ Nombre y tipo de dato exacto de cada columna.
El esquema actúa como un contrato. Si el dataset no coincide exactamente con esa definición, el servicio devolverá un error de validación.
🔄 Separación entre features estáticas y dinámicas (mejor práctica)
Una decisión arquitectónica relevante fue separar las features según su naturaleza temporal.
1️⃣ Feature Group Estático
Contiene atributos que no cambian en el tiempo, por ejemplo:
- Rareza (
rarity) - Características físicas de la carta
- Identificadores estructurales
Estas features se registran una sola vez por entidad.
2️⃣ Feature Group Dinámico
Contiene variables que evolucionan en el tiempo, como:
- Precios históricos
- Métricas agregadas temporales
- Indicadores de mercado
Estas features requieren versionamiento temporal.
Esta separación sigue una buena práctica en sistemas ML productivos: desacoplar identidad estructural de señales dependientes del tiempo.
🆔 Identificación única: card_id + timestamp
Para que el Feature Store funcione correctamente, cada registro debe tener:
-
Record Identifier (Primary Key) →
card_id -
Event Time →
timestampque indica cuándo esa versión del feature fue válida
En el Feature Store, record_identifier_name y event_time_feature_name son obligatorios en cada Feature Group.
⚠ Consideraciones críticas al crear Feature Groups
Al crear los Feature Groups es obligatorio definir:
- Nombre exacto de cada columna.
- Tipo de dato correcto.
- Campo identificador.
- Campo temporal.
Si existe cualquier discrepancia entre el esquema declarado y el dataset cargado, el servicio devolverá un error de validación.
🚀 Carga (ingestión) de datos
El siguiente paso natural es poblar los Feature Groups mediante cargas en Python, normalmente desde SageMaker Studio.
El flujo típico consiste en:
- Crear el Feature Group.
- Esperar a que el estado sea
Created. - Ejecutar la ingestión mediante
ingest()oPutRecord. - Validar almacenamiento en:
- Online Store (para inferencia en tiempo real).
- Offline Store en S3 (para entrenamiento).
🎯 Conclusión
En proyectos de Machine Learning, el desempeño del modelo suele acaparar la atención. Sin embargo, la verdadera complejidad reside en la calidad estructural de los datos y en la arquitectura que garantiza su consistencia a lo largo del tiempo.
A lo largo de este trabajo se abordaron transformaciones estadísticas necesarias —imputación robusta, reducción de asimetrías y estabilización de varianza— pero el aprendizaje más relevante surgió al enfrentar problemas de identidad, unicidad y versionamiento.
La creación de una llave compuesta (card_id), la eliminación de duplicados y la validación de integridad no fueron ajustes menores: fueron decisiones que aseguraron trazabilidad y coherencia sistémica.
La adopción de Amazon SageMaker Feature Store permitió estructurar las features como activos gobernados, separando atributos estáticos de dinámicos y modelando explícitamente la dimensión temporal mediante event_time.
Este ejercicio reafirma principios fundamentales:
- Sin identidad única no existe sistema confiable.
- Sin modelado temporal no existe control sobre la evolución del dato.
- Sin contratos de esquema no existe gobernanza.
- Y sin gobernanza, no existe producción sostenible.
El resultado no es únicamente un conjunto de features preparadas, sino una arquitectura preparada para escalar, evolucionar y sostener modelos en entornos reales.
Top comments (0)