Características y etiquetas en Machine Learning: lo que el modelo aprende realmente

Qué son las características (features) y qué es la etiqueta (label)

En Machine Learning, el modelo no “ve” la realidad directamente: solo ve una tabla (o estructura similar) con características y, en algunos casos, una etiqueta.

• Características (features): son señales medibles que describen un caso. Responden a “¿qué sé sobre este ejemplo?”
• Etiqueta (label): es la respuesta que queremos que el modelo aprenda a predecir. Responde a “¿qué quiero adivinar?”

Ejemplo simple (predicción de abandono de suscripción):

• Características: número de sesiones en la última semana, días desde el último inicio de sesión, tipo de plan, incidencias reportadas.
• Etiqueta: “abandona en los próximos 30 días” (sí/no).

La idea clave: el modelo aprende relaciones entre características y etiqueta. Si las características no capturan bien la señal, el modelo no tiene “de dónde” aprender, aunque uses un algoritmo muy avanzado.

La misma realidad, distintas representaciones: por qué cambia el resultado

Dos equipos pueden observar el mismo fenómeno y construir datasets distintos. Ambos describen la misma realidad, pero con señales diferentes; por eso el modelo puede rendir mejor o peor.

Ejemplo 1: Predecir el precio de una vivienda

Realidad: una vivienda en una ciudad.

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

Representación A (características más directas):

• metros cuadrados
• número de habitaciones
• barrio
• estado (reformada / no reformada)

Representación B (características “pobres” o indirectas):

• color de la fachada
• día de la semana en que se publicó el anuncio
• número de fotos en el anuncio

Ambas representaciones describen “la vivienda”, pero la A contiene señales más conectadas con el precio. Con la B, el modelo puede encontrar patrones accidentales (por ejemplo, anuncios publicados en cierto día tienden a ser más caros) que no se sostienen en el tiempo.

Ejemplo 2: Clasificar correos como spam

Realidad: un email.

Representación A (señales útiles):

• presencia de ciertas palabras o expresiones típicas
• dominio del remitente
• si incluye enlaces y cuántos
• si el remitente está en contactos

Representación B (señales engañosas):

• longitud exacta del asunto sin contexto
• hora de recepción
• número de mayúsculas en el cuerpo (puede ayudar, pero sola suele ser insuficiente)

La etiqueta sería “spam” (sí/no). La diferencia no es el algoritmo: es qué señales le das.

Ejemplo 3: Un mismo dato puede convertirse en varias características

Realidad: “fecha de compra”.

Posibles características derivadas:

• día de la semana (lunes, martes…)
• mes del año
• si fue fin de semana
• si fue periodo de rebajas (según calendario del negocio)

Dependiendo del problema, una derivación puede ser mucho más informativa que otra.

Etiqueta: cuidado con definirla mal

La etiqueta no es solo una columna: es una decisión de negocio o producto traducida a datos. Dos etiquetas distintas cambian por completo lo que el modelo “aprende”.

Ejemplo (retención):

• Etiqueta 1: “¿volverá a comprar en 30 días?”
• Etiqueta 2: “¿volverá a comprar en 90 días?”

Con la etiqueta 1, el modelo tenderá a priorizar señales de comportamiento inmediato; con la 2, señales más estables (historial, preferencias, estacionalidad). Ninguna es “mejor” en abstracto: depende de la decisión que quieras automatizar.

Guía práctica para crear buenas características (paso a paso)

Paso 1: Asegura relevancia (que la señal tenga sentido para la etiqueta)

Pregunta práctica: “Si esta característica cambia, ¿podría cambiar la etiqueta de forma razonable?”

• Para predecir impago, “historial de pagos” suele ser relevante.
• “Color favorito del usuario” probablemente no lo es (salvo casos muy específicos).

Consejo: empieza con señales que un experto humano usaría para tomar la decisión.

Paso 2: Verifica disponibilidad (que exista cuando la necesites)

Una característica puede ser excelente en teoría, pero inútil si no está disponible en el momento de predecir.

• Ejemplo: para aprobar un préstamo en tiempo real, “ingresos verificados” puede tardar días en confirmarse. Si tu predicción debe ocurrir en segundos, necesitas una alternativa disponible (por ejemplo, “ingresos declarados” con controles adicionales).

Checklist rápido:

• ¿La característica se captura para todos los casos o hay muchos vacíos?
• ¿Está disponible en el mismo sistema donde se hará la predicción?
• ¿Llega a tiempo (latencia)?

Paso 3: Asegura estabilidad en el tiempo (que no cambie su significado)

Una característica puede “romperse” sin que nadie lo note si cambia la forma de medirla o el contexto.

• Ejemplo: “canal de adquisición” puede cambiar de valores cuando marketing renombra campañas o migra de herramienta. El modelo aprende con un significado y luego recibe otro.
• Ejemplo: “precio” puede verse afectado por cambios de moneda, impuestos o promociones; conviene estandarizar la definición (precio final, precio base, etc.).

Práctica recomendada:

• Define cada característica con una descripción clara y mantenla versionada.
• Monitorea si la distribución de valores cambia bruscamente (señal de que algo cambió).

Paso 4: Evita información futura (fugas de información)

Una de las trampas más comunes: incluir una característica que, sin querer, contiene información que solo se conoce después del momento en que quieres predecir. Esto hace que el modelo parezca “mágico” en pruebas, pero falle en producción.

Ejemplos típicos de fuga:

• Predecir “abandono en 30 días” usando “número de tickets de soporte en los próximos 30 días”.
• Predecir “entrega tardía” usando “fecha real de entrega” (obvio, pero ocurre en variables derivadas).
• Predecir “fraude” usando “cuenta bloqueada” si el bloqueo ocurre como consecuencia de detectar fraude.

Regla práctica: para cada característica, escribe: “¿esto se conoce en el instante exacto en que haré la predicción?” Si la respuesta es no, no debe entrar (o debe redefinirse para usar solo información pasada).

Transformaciones simples de características (sin matemática)

Muchas mejoras de rendimiento vienen de transformar señales para que sean más consistentes y comparables. Estas transformaciones no “inventan” información, pero la hacen más utilizable.

1) Normalizar (poner valores en una escala comparable)

Problema: algunas características tienen rangos muy distintos (por ejemplo, “ingresos anuales” y “número de compras”). En ciertos modelos, esto puede hacer que una característica “domine” solo por su escala.

Transformación: convertir valores a una escala común. En la práctica, significa representar “qué tan grande es” un valor comparado con el resto, en lugar de usar el número crudo.

Ejemplo:

• En vez de usar ingresos tal cual, usar una versión “escalada” para que valores típicos queden en un rango similar al de otras variables.

Cuándo ayuda: cuando combinas señales con unidades muy diferentes o cuando notas que el modelo es sensible a magnitudes.

2) Agrupar categorías (reducir ruido y rarezas)

Problema: variables categóricas con demasiados valores (por ejemplo, miles de “modelos de dispositivo” o “ciudades”) generan rarezas: categorías con muy pocos casos que el modelo no aprende bien.

Transformación: agrupar categorías poco frecuentes en “Otros” o agrupar por una jerarquía más estable.

Ejemplos:

• “Modelo exacto de móvil” → “marca” o “gama (alta/media/baja)”.
• “Ciudad” → “región” o “tamaño de ciudad”.
• “Fuente de tráfico” → “orgánico / pago / referido”.

Beneficio: menos fragmentación, señales más robustas y estables.

3) Extraer longitud de un texto (convertir texto en una señal simple)

Problema: el texto libre es difícil de usar directamente si no vas a aplicar técnicas específicas de lenguaje. Aun así, puedes extraer señales simples.

Transformaciones útiles:

• Longitud del texto (corto vs largo).
• Número de palabras.
• Si contiene enlace (sí/no).
• Si contiene números (sí/no).

Ejemplo práctico:

• Para predecir si un ticket de soporte será “complejo”, la longitud del mensaje inicial puede ser una señal: mensajes muy largos suelen indicar más contexto y, a veces, problemas más enredados.

4) Convertir fechas en señales operativas

Problema: una fecha como “2026-02-03” no es tan útil por sí sola.

Transformaciones típicas:

• “días desde el último evento” (recencia)
• “número de eventos en los últimos X días” (frecuencia)
• “es fin de semana / es festivo”

Ejemplo:

• Para predecir recompra, “días desde la última compra” suele ser más informativo que la fecha exacta.

Mini-checklist de calidad de características (para revisar antes de entrenar)