¿Qué son los datos de entrenamiento y por qué son tan importantes?

Los datos de entrenamiento son los ejemplos históricos que un modelo de machine learning estudia para aprender a hacer predicciones.

¿Cuántos datos necesitas realmente?

Antes de continuar, responde esta pregunta mentalmente: si quisieras entrenar un modelo para detectar fraudes en pagos con tarjeta, ¿cuántos registros crees que necesitas? ¿Mil? ¿Diez mil? ¿Un millón?

La respuesta real sorprende a la mayoría. Un equipo de ingeniería de FEMSA reportó que su primer modelo de predicción de inventario funcionó aceptablemente con solo 8,000 registros limpios. Otro equipo que usó 500,000 registros sucios obtuvo resultados peores. La cantidad importa menos de lo que crees. La calidad lo es todo.

Eso es el principio central de esta lección: los datos de entrenamiento son la materia prima del ML, y la materia prima sucia produce productos defectuosos.

El Principio de la Arcilla

Piensa en un modelo de machine learning como un escultor. Los datos de entrenamiento son la arcilla. Si la arcilla tiene piedras, grietas y partes secas, el escultor puede ser el más talentoso del mundo y aún así producir una pieza rota.

Este concepto tiene un nombre formal en la industria: GIGO (Garbage In, Garbage Out). En español: basura entra, basura sale. Pero en el contexto de ML mexicano, preferimos llamarlo el Principio de la Arcilla: la calidad del resultado depende directamente de la calidad del material con el que trabajas.

Un estudio de IBM de 2023 estimó que las empresas pierden en promedio el 12% de sus ingresos anuales por decisiones tomadas con datos de mala calidad. Para una empresa mediana mexicana con ingresos de $50,000,000 al año, eso representa $6,000,000 perdidos. No por falta de tecnología, sino por datos mal preparados.

¿Qué contienen los datos de entrenamiento?

Los datos de entrenamiento tienen dos partes fundamentales.

La primera es la característica (o feature en inglés). Es la información de entrada que el modelo puede observar. Por ejemplo: el precio de un producto, el número de visitas a una página, o el historial de compras de un cliente.

La segunda es la etiqueta (o label). Es la respuesta correcta que el modelo debe aprender a predecir. Por ejemplo: si el cliente compró o no compró, si el producto tuvo alta o baja demanda.

Imagina que trabajas en Mercado Libre y quieres predecir si un anuncio recibirá muchas visitas. Tus datos de entrenamiento podrían verse así:

Las primeras tres columnas son características. La última columna es la etiqueta. El modelo estudia miles de filas como estas y aprende qué combinaciones de características predicen la etiqueta correcta.

Los Tres Enemigos de tus Datos

Existen tres problemas que destruyen la calidad de los datos de entrenamiento. Los llamamos los Tres Enemigos.

Enemigo 1: Los valores faltantes

Un valor faltante ocurre cuando una celda en tu tabla de datos está vacía. En la práctica, esto es muy común. Los clientes no siempre completan todos los campos de un formulario. Los sensores de una planta de Bimbo pueden fallar por unos minutos y dejar de registrar temperatura. Los sistemas heredados del SAT a veces no migran todos los campos correctamente.

¿Qué hace el modelo cuando encuentra un valor faltante? Depende de cómo lo configures. Si no haces nada, muchos algoritmos simplemente ignoran esa fila completa. Si el 20% de tus datos tienen valores faltantes, perdiste el 20% de tu información.

La solución más común se llama imputación: reemplazar el valor faltante con el promedio, la mediana, o el valor más frecuente de esa columna. No es perfecta, pero es mejor que perder datos.

Enemigo 2: Los valores atípicos (outliers)

Un outlier es un dato que se aleja mucho del resto. Si registras los salarios de 1,000 empleados en México y la mayoría gana entre $10,000 y $30,000 al mes, pero un CEO gana $2,500,000, ese dato es un outlier.

El problema es que los outliers pueden "jalarse" el modelo hacia ellos. Si tu modelo intenta aprender patrones y un dato grita muy fuerte por ser extremo, el modelo le hará demasiado caso y se equivocará con los casos normales.

La solución depende del contexto. A veces los outliers son errores de captura y se eliminan. Otras veces son datos reales y valiosos (un fraude bancario, por ejemplo, es un outlier que definitivamente quieres detectar).

Enemigo 3: El sesgo de representación

Este es el enemigo más peligroso porque es invisible. Ocurre cuando tus datos de entrenamiento no representan bien la realidad.

Ejemplo real: una empresa de crédito en México entrenó un modelo con datos históricos de sus clientes. Pero sus clientes históricos eran principalmente hombres de entre 30 y 50 años en CDMX. El modelo aprendió a aprobar créditos para ese perfil y a rechazar casi todo lo demás. Cuando la empresa quiso expandirse a mujeres jóvenes en Monterrey, el modelo fallaba sistemáticamente.

Los datos no eran incorrectos. Solo eran incompletos. Eso es sesgo de representación.

Cómo preparar datos de entrenamiento: el Proceso de las 4 L

En la práctica, preparar datos de entrenamiento sigue cuatro pasos. Los llamamos el Proceso de las 4 L.

1. Localizar: Identifica de dónde vienen tus datos. ¿Son registros del ERP de tu empresa? ¿Datos del IMSS? ¿Encuestas de satisfacción? Saber el origen te ayuda a entender sus limitaciones.

2. Limpiar: Elimina duplicados, corrige errores de captura, imputa valores faltantes y decide qué hacer con los outliers. Esta etapa suele tomar el 60% del tiempo total de un proyecto de ML.

3. Labelar (etiquetar): Si tus datos no tienen etiquetas, alguien tiene que crearlas. Esto puede ser automático (si tienes registros históricos de resultados) o manual (si necesitas que expertos humanos clasifiquen cada ejemplo). Liverpool, por ejemplo, tiene equipos que etiquetan manualmente imágenes de productos para entrenar modelos de clasificación visual.

4. Levantar (estructurar): Organiza los datos en el formato que el algoritmo espera. Algunas columnas de texto deben convertirse en números. Las fechas deben descomponerse en día, mes y año por separado. Los valores categóricos como "Ciudad de México", "Guadalajara" y "Monterrey" deben transformarse en representaciones numéricas.

¿Cuántos datos son suficientes?

No existe una regla universal, pero hay guías prácticas útiles.

Para un modelo de clasificación simple (¿compra o no compra?), muchos expertos recomiendan al menos 1,000 ejemplos por categoría. Si tienes dos categorías, necesitas mínimo 2,000 registros limpios.

Para modelos más complejos, como reconocimiento de imágenes o procesamiento de lenguaje, puedes necesitar cientos de miles de ejemplos.

Lo más importante: más datos sucios no superan a menos datos limpios. Un equipo de análisis de FEMSA demostró internamente que reducir su dataset de 400,000 registros a 80,000 registros cuidadosamente limpios mejoró la precisión de su modelo en un 14%.

Errores comunes al preparar datos

El error más frecuente es mezclar datos del futuro con datos del pasado. Se llama "data leakage" o fuga de datos. Ocurre cuando incluyes en el entrenamiento información que en la vida real no tendrías disponible al momento de hacer la predicción. El modelo aprende demasiado bien en entrenamiento, pero falla completamente en producción.

El segundo error es normalizar antes de dividir tus datos en conjunto de entrenamiento y de prueba. Si calculas el promedio de toda tu tabla y luego divides, tu conjunto de prueba ya "contaminó" el entrenamiento. Primero divide, luego normaliza cada parte por separado.

El tercer error es ignorar el balance de clases. Si tienes 95% de transacciones normales y 5% de fraudes, un modelo perezoso puede predecir "normal" siempre y tener 95% de aciertos. Pero nunca detectará un fraude. Ese modelo es inútil.

La regla práctica para recordar

Antes de entrenar cualquier modelo, hazte estas tres preguntas: ¿Mis datos representan bien la realidad que quiero predecir? ¿Están limpios de errores evidentes? ¿Las etiquetas son confiables?

Si las tres respuestas son sí, puedes avanzar. Si alguna es no, dedica tiempo ahí primero. Ningún algoritmo, por sofisticado que sea, puede compensar datos fundamentalmente defectuosos.