Datos para Machine Learning: calidad, estructura y significado

Cómo “se ve” un dataset por dentro

En Machine Learning, casi siempre trabajas con una tabla (como una hoja de cálculo): cada fila representa un caso y cada columna representa una característica de ese caso. Entender esta estructura te ayuda a preparar datos que un modelo pueda aprender sin “confundirse”.

Fila (registro, ejemplo, observación)

Una fila es una instancia concreta del problema. Si estás prediciendo abandono de clientes, una fila puede ser un cliente. Si estás prediciendo precio de casas, una fila puede ser una casa.

• Ejemplo: Fila = Cliente #1532 con su edad, plan, consumo, etc.
• Regla práctica: una fila debe corresponder a una unidad coherente (persona, transacción, sesión, producto), sin mezclar niveles.

Columna (atributo, característica, variable)

Una columna describe una propiedad medible o descriptiva de cada fila. Algunas columnas son “entrada” (lo que el modelo usa para aprender) y una columna suele ser la “salida” (lo que queremos predecir).

• Ejemplo: edad, plan, minutos_usados, pais.
• Regla práctica: una columna debe tener el mismo significado para todas las filas (misma unidad, misma escala, misma definición).

Variable objetivo (target, etiqueta)

La variable objetivo es lo que quieres predecir. En clasificación suele ser una categoría (por ejemplo, “abandona / no abandona”). En regresión suele ser un número (por ejemplo, “precio”).

• Ejemplo clasificación: abandono ∈ {0,1}
• Ejemplo regresión: precio = 245000

Una forma simple de pensarlo: las columnas de entrada responden “¿qué sabemos?” y la variable objetivo responde “¿qué queremos adivinar?”.

Continúa en nuestra aplicación.

• Escuche el audio con la pantalla apagada.
• Obtenga un certificado al finalizar.
• ¡Más de 5000 cursos para que explores!

O continúa leyendo más abajo...

Descargar la aplicación

Tipos de datos: numéricos, categóricos y texto (intuición rápida)

Los modelos no “entienden” el mundo como nosotros: entienden patrones en representaciones. Por eso importa distinguir el tipo de dato, porque cada tipo suele requerir un tratamiento distinto.

Datos numéricos

Son cantidades con sentido matemático: puedes sumar, promediar o comparar distancias.

• Ejemplos: edad, ingresos, temperatura, tiempo_en_app.
• Señal de alerta: unidades mezcladas (kg vs lb), escalas inconsistentes, valores imposibles (edad = -3).

Datos categóricos

Son etiquetas o grupos. A veces tienen orden (bajo/medio/alto) y a veces no (color, país).

• Ejemplos sin orden: pais = “MX”, “AR”, “ES”.
• Ejemplos con orden: nivel_satisfaccion = “bajo”, “medio”, “alto”.
• Señal de alerta: categorías escritas de múltiples formas ("México", "Mexico", "MX") que en realidad significan lo mismo.

Texto

Es lenguaje natural: reseñas, descripciones, correos, chats. El texto suele contener mucha información, pero hay que convertirlo a una representación que el modelo pueda usar.

• Ejemplos: comentario = “El envío llegó tarde pero el producto es bueno”.
• Señal de alerta: texto con datos sensibles o con pistas directas de la respuesta (por ejemplo, “cliente canceló” dentro del comentario cuando quieres predecir cancelación).

Por qué la calidad de datos cambia lo que el modelo “aprende”

Un modelo aprende patrones a partir de lo que ve. Si los datos tienen huecos, errores o sesgos, el modelo puede aprender reglas equivocadas o poco generalizables. A continuación, problemas típicos y cómo se sienten en la práctica.

Valores faltantes (missing values)

Ocurren cuando una columna no tiene dato para algunas filas: campo vacío, null, “N/A”, “-”.

• Impacto: el modelo puede perder información útil o interpretar el faltante como una señal accidental (por ejemplo, “si falta el ingreso, entonces…”).
• Preguntas clave: ¿falta al azar o falta por una razón? (No es lo mismo “no respondió” que “no aplica”).

Errores y valores imposibles

Incluye typos, mediciones mal registradas o valores fuera de rango.

• Ejemplos: edad = 999, fecha_fin anterior a fecha_inicio, precio negativo.
• Impacto: introduce ruido; el modelo intenta ajustar excepciones que no representan la realidad.

Duplicados

Filas repetidas o casi repetidas (mismo cliente/operación) aparecen por integraciones, reintentos de carga o uniones mal hechas.

• Impacto: el modelo “sobrevalora” esos casos, como si ocurrieran más veces de las reales.
• Señal típica: el conteo de filas crece sin explicación o aparecen IDs repetidos cuando deberían ser únicos.

Sesgos

Un sesgo aparece cuando el dataset no representa bien el mundo que quieres predecir, o cuando refleja decisiones históricas que no quieres perpetuar.

• Ejemplo: si solo tienes datos de clientes de una región, el modelo puede fallar en otras regiones.
• Ejemplo: si una variable proxy (como código postal) correlaciona con atributos sensibles, el modelo puede aprender diferencias injustas.
• Impacto: rendimiento desigual entre grupos, decisiones inconsistentes y riesgo reputacional o legal según el contexto.

Guía práctica: revisión paso a paso antes de entrenar

Este esquema sirve como checklist para preparar datos de forma segura y con significado. La idea no es “limpiar por limpiar”, sino entender qué representa cada columna y evitar señales engañosas.

Paso 1: Entender el origen del dato (contexto y trazabilidad)

• Fuente: ¿viene de un sistema transaccional, un CRM, logs, encuestas, sensores?
• Momento: ¿cuándo se registró cada columna? (muy importante para evitar fugas de información).
• Definición: documenta qué significa cada columna, unidad, rango esperado y ejemplos válidos.
• Grano (granularidad): confirma qué representa una fila: ¿cliente, pedido, sesión? Evita mezclar (por ejemplo, una fila por cliente pero columnas agregadas por pedido sin control).

Paso 2: Revisar estructura básica (sanity checks)

• Tipos: verifica si cada columna es numérica, categórica o texto (y si está almacenada correctamente).
• Unicidad: identifica claves como id_cliente o id_transaccion y comprueba si deberían ser únicas.
• Rangos: define límites razonables (edad 0–120, descuentos 0–100, etc.).
• Consistencia temporal: valida reglas como fecha_inicio ≤ fecha_fin.

Paso 3: Medir faltantes y decidir qué significan

• Cuánto falta: porcentaje de valores faltantes por columna y por segmento (por ejemplo, por país o canal).
• Patrones: ¿faltan juntos? (si faltan varias columnas a la vez puede indicar un problema de captura).
• Semántica: diferencia “desconocido” vs “no aplica”. A veces conviene crear una categoría explícita (por ejemplo, plan = 'desconocido').

Paso 4: Detectar errores, outliers y codificaciones raras

• Valores imposibles: negativos donde no corresponde, fechas inválidas, códigos fuera de catálogo.
• Outliers: valores extremos que podrían ser reales o errores (por ejemplo, consumo 1000× mayor).
• Formato: decimales con coma vs punto, monedas mezcladas, texto con espacios extra.

Paso 5: Buscar duplicados y “casi duplicados”

• Duplicado exacto: filas idénticas.
• Duplicado por clave: mismo id con pequeñas variaciones (puede indicar actualizaciones o registros parciales).
• Regla de negocio: define qué hacer: conservar el más reciente, agregar, o consolidar.

Paso 6: Verificar consistencia entre columnas (reglas cruzadas)

• Ejemplo: si pais = “ES”, ¿el codigo_postal tiene el patrón esperado?
• Ejemplo: si tipo_envio = “express”, ¿el costo_envio suele ser mayor que “estándar”?
• Ejemplo: si edad es baja, ¿hay productos/planes que no deberían aparecer?

Paso 7: Detectar fugas de información (leakage): señales que no deberían estar

La fuga de información ocurre cuando una columna contiene información que, en la vida real, no estaría disponible en el momento de hacer la predicción, o que está demasiado cerca de la respuesta. Esto hace que el modelo parezca excelente en pruebas, pero falle en producción.

• Señales “del futuro”: columnas calculadas después del evento objetivo. Ejemplo: quieres predecir abandono y tienes fecha_cancelacion o estado_final.
• Variables derivadas de la etiqueta: monto_reembolsado puede implicar que hubo devolución, que a su vez está ligado a la etiqueta.
• Campos operativos: “motivo_de_cierre”, “resultado_de_gestion” suelen estar contaminados por el proceso que ocurre tras el evento.
• Identificadores con información oculta: algunos IDs codifican fecha, región o tipo; si el ID se asigna de forma no aleatoria, puede introducir patrones engañosos.

Chequeo práctico: para cada columna, pregúntate: “¿Esta información existiría en el instante exacto en que quiero predecir?” Si la respuesta es no, esa columna no debe entrar como entrada del modelo.

Paso 8: Revisar sesgos y cobertura del dataset

• Representatividad: compara distribución por segmentos (región, canal, tipo de cliente) con la realidad donde se usará el modelo.
• Rendimiento por grupo (si ya tienes un modelo base): evalúa métricas por segmento para detectar degradación desigual.
• Variables proxy: identifica columnas que podrían actuar como sustitutos de atributos sensibles (según el contexto) y decide cómo tratarlas.

Paso 9: Dejar un “diccionario de datos” mínimo

Para que el dataset sea reutilizable y auditable, crea una tabla simple con: nombre de columna, tipo, definición, unidad/rango, reglas de validación y si está permitida como entrada (especialmente tras revisar fugas).

Mini-ejemplo integrador (para aterrizar conceptos)

Supón que quieres predecir si un cliente abandonará el servicio el próximo mes.

Fila (cliente):  10293 | edad=34 | plan='premium' | tickets_soporte=2 | pais='CL' | comentario='Se cae mucho' | abandono=1
Columna:         edad, plan, tickets_soporte, pais, comentario (entradas)
Objetivo:        abandono (lo que quieres predecir)

• Si tickets_soporte tiene muchos faltantes porque un canal no registra tickets, el modelo puede aprender diferencias por canal en vez de por comportamiento real.
• Si aparece una columna estado_final que ya indica “cancelado”, sería una fuga: el modelo “adivina” porque le diste la respuesta disfrazada.
• Si hay duplicados del mismo cliente por una unión mal hecha, ese cliente pesa más de lo debido.