Al cerrar el módulo anterior prometimos poner la estadística a trabajar sobre datos reales e imperfectos, y aquí cumplimos esa promesa. Los datasets de MercaFresh —como los de cualquier empresa real— llegan con duplicados, errores de captura, valores imposibles y categorías escritas de tres formas distintas. Ningún algoritmo del módulo 4 puede compensar un dato de entrada corrupto: si entrenamos el modelo de churn con clientes duplicados o edades negativas, aprenderá patrones que no existen. En esta lección aprenderás a auditar un dataset, detectar sus problemas y corregirlos de forma sistemática con pandas. Es, según la mayoría de profesionales, la fase donde se invierte más tiempo de un proyecto de ML: hacerla bien marca la diferencia entre un modelo útil y uno engañoso.

1. Por qué los datos reales están sucios
2. El dataset de clientes de MercaFresh
3. Auditoría inicial: conocer el terreno
4. Duplicados: exactos y lógicos
5. Errores de captura y valores imposibles
6. Inconsistencias de texto y categorías
7. Tipos de datos incorrectos
8. Outliers: detectarlos y decidir qué hacer

Los datasets de los tutoriales vienen limpios; los de las empresas, no. Las causas son siempre parecidas:

• Entrada manual: un teleoperador de MercaFresh teclea "BCN" un día y "Barcelona" al siguiente.
• Integración de sistemas: la web, la app móvil y el call center guardan los datos con formatos distintos (fechas 2025-03-14 vs 14/03/2025).
• Errores de software: un bug registró durante dos semanas importes de pedido a 0 €.
• Migraciones históricas: al cambiar de CRM en 2023, algunos clientes se importaron dos veces.
• Valores centinela: alguien usó -1 o 999 para decir "no lo sé", y ahora parecen datos reales.

La consecuencia práctica se resume en la frase clásica garbage in, garbage out: un modelo entrenado con basura produce predicciones basura, pero con apariencia de precisión matemática. Por eso la limpieza no es un trámite, sino parte del análisis.

Este es el orden que seguiremos: primero entender, luego corregir de lo más obvio a lo más sutil.

Trabajaremos con un extracto ficticio pero realista de la tabla de clientes, exportada del CRM para el proyecto de churn. Vamos a construirlo en código para que puedas reproducir todo lo que sigue:

A simple vista ya se intuyen problemas: el cliente 102 aparece dos veces, hay una edad de -5 y otra de 127, la ciudad "Barcelona" está escrita de cuatro maneras, el gasto es texto y hay una fecha de alta en 2027 (¡en el futuro!). En un dataset de 10 filas los ves de un vistazo; en uno de 200.000 necesitas método.

Antes de tocar nada, hay que radiografiar el dataset. Tres funciones de pandas cubren el 80 % de la auditoría inicial:

info() responde tres preguntas: ¿cuántas filas hay?, ¿de qué tipo es cada columna?, ¿cuántos valores no nulos tiene cada una? Aquí descubrimos el primer problema silencioso: gasto_total es de tipo object (texto), no numérico. Un object donde esperabas números es una alarma roja.

describe() nos da media, desviación, mínimo, máximo y cuartiles — exactamente los estadísticos del módulo 2 (lección 02-01). Su gran utilidad en limpieza es mirar min y max: una edad mínima de -5 y máxima de 127 no necesitan más análisis para saber que algo va mal.

nunique() cuenta valores distintos por columna. Si sabemos que MercaFresh opera en 4 ciudades pero ciudad tiene 7 valores únicos, hay inconsistencias de escritura. unique() nos las enseña: ['Barcelona' 'BCN' ' barcelona ' 'Valencia' 'VALENCIA' 'Madrid' 'madrid' 'Sevilla'].

Un duplicado exacto es una fila idéntica a otra en todas sus columnas. En MercaFresh, el cliente 102 (Luis Gil) se importó dos veces durante la migración del CRM:

Puntos clave de drop_duplicates:

• keep="first" (por defecto) conserva la primera copia; keep="last", la última; keep=False elimina todas.
• Devuelve un DataFrame nuevo: hay que reasignarlo (df = df.drop_duplicates()).

¿Por qué importa para el modelo de churn? Un cliente duplicado pesa el doble en el entrenamiento: el modelo "verá" dos veces sus patrones y sesgará sus conclusiones hacia ese perfil.

Más peligrosos son los duplicados lógicos: filas que representan la misma entidad pero no son idénticas byte a byte. Por ejemplo, el mismo cliente dado de alta dos veces con el gasto repartido entre ambas fichas, o el mismo pedido registrado por la web y por la app con ids distintos. Para cazarlos, se busca duplicidad solo en las columnas que definen la identidad:

Con duplicados lógicos, borrar sin mirar es arriesgado: a veces lo correcto es fusionar (sumar los pedidos de ambas fichas) en lugar de eliminar. Es una decisión de negocio, no solo técnica: pregunta siempre qué representa cada fila.

Un valor imposible es aquel que viola las reglas del mundo real o del negocio. La técnica consiste en definir reglas de validez explícitas y comprobar cuántas filas las incumplen:

¿Y qué hacemos con ellos? Hay tres opciones, en orden de preferencia:

1. Corregir, si conocemos el error: una edad de -5 con signo cambiado puede ser 5 (imposible, menor de edad) o un teclazo; si el CRM original tiene el dato bueno, se recupera de allí.
2. Marcar como faltante (np.nan), si no podemos saber el valor real: es honesto reconocer que no lo sabemos, y en la próxima lección veremos cómo tratar esos nulos.
3. Eliminar la fila, solo si el registro entero es irrecuperable y son pocos casos.

Fíjate en df.loc[condición, columna] = valor: es la forma segura en pandas de modificar un subconjunto (evita el famoso SettingWithCopyWarning).

Los importes a 0 merecen reflexión aparte: un gasto_total de 0 con num_pedidos de 0 puede ser legítimo (cliente registrado que nunca compró — ¡muy relevante para churn!), mientras que gasto 0 con 12 pedidos es un error. La misma cifra puede ser dato válido o error según el contexto: valida combinaciones de columnas, no columnas aisladas.

La columna ciudad es el ejemplo perfecto: "Barcelona", "BCN" y " barcelona " son la misma ciudad para un humano, pero tres categorías distintas para pandas y para cualquier modelo. Si no lo arreglamos, el futuro one-hot encoding (lección 03-04) creará tres columnas donde debería haber una.

La normalización sigue una receta en tres pasos con los métodos de cadena str.*:

Detalle importante: str.strip() y str.lower() transforman el texto carácter a carácter, mientras que replace() sustituye valores completos usando un diccionario. Para sustituciones dentro del texto (por ejemplo, quitar puntos de "S.L.") existe str.replace("...", "..."), que es otro método distinto — confundirlos es un clásico.

Para descubrir alias que no conocías, value_counts() es tu aliado: ordena las categorías por frecuencia y las variantes raras aparecen al final de la lista con conteos de 1 o 2.

Que un número esté almacenado como texto es un problema invisible hasta que explota: no puedes calcular medias, los ordenamientos son alfabéticos ("15400" < "890" porque "1" < "8") y describe() lo ignora.

El parámetro format merece atención: "14/03/2025" puede ser 14 de marzo o (en convención americana) un error. Especificar format="%d/%m/%Y" elimina la ambigüedad. Convertir las fechas a datetime real además desbloquea operaciones que usaremos en la lección 03-03: extraer el mes, calcular antigüedad, restar fechas.

Los outliers ya los conoces del módulo 2: en 02-01 los viste asomar en los boxplots de importes de pedido, y en 02-02 aprendiste que un z-score alto señala una rareza. Ahora los aplicamos como herramientas de limpieza sobre gasto_total.

Recordatorio de 02-02: si los datos fueran normales, solo un 0,3 % de los valores caería más allá de |z| > 3. El cliente 107, con 15.400 € de gasto y 210 pedidos, se dispara. El z-score tiene una debilidad: la media y la desviación que usa se contaminan por los propios outliers, así que en muestras pequeñas o muy sesgadas puede fallar.

El método del rango intercuartílico (02-01) es más robusto porque los cuartiles apenas se inmutan ante valores extremos:

Es exactamente la regla que dibuja los "bigotes" del boxplot que ya conoces.

Aquí está el matiz que separa la limpieza mecánica de la buena limpieza: un outlier no es necesariamente un error. El cliente 107 podría ser un restaurante que compra a diario en MercaFresh — un cliente valiosísimo, no un dato corrupto. Las opciones:

La regla de oro: nunca elimines un outlier sin poder explicar por qué. Documenta cada decisión — tu yo del futuro (y el modelo de churn) te lo agradecerán.

• Limpiar sin auditar primero. Ejecutar drop_duplicates "por si acaso" antes de entender los datos puede borrar registros legítimos. Primero info(), describe(), nunique(); después, actuar.
• Olvidar reasignar. df.drop_duplicates() sin df = no cambia nada: la mayoría de operaciones de pandas devuelven una copia.
• Confundir replace() con str.replace(). El primero sustituye valores completos de la Serie; el segundo, subcadenas dentro de cada texto.
• Eliminar outliers automáticamente con |z| > 3. Es un detector, no un juez: cada outlier merece un diagnóstico (¿error o cliente excepcional?).
• Validar columnas de forma aislada. Gasto 0 puede ser válido o no según num_pedidos: las reglas de validez potentes cruzan columnas.
• No documentar los cambios. Guarda el número de filas eliminadas y las reglas aplicadas; en un proyecto real te pedirán cuentas de cada registro descartado.
• Consejo: escribe la limpieza como una función reproducible (def limpiar_clientes(df): ...) en lugar de celdas sueltas. Cuando llegue la exportación del mes siguiente, la aplicarás en segundos.

Con el DataFrame df original de la lección (antes de limpiar), escribe el código que: (a) cuente los duplicados exactos, (b) los elimine conservando la primera aparición y (c) compruebe si queda algún id_cliente repetido.

El equipo de MercaFresh te pasa esta columna de una nueva exportación: ["Madrid", "MAD", " madrid", "Màdrid", "madriz"]. Normalízala para que todos los valores acaben siendo "Madrid". Pista: necesitarás strip, lower y un diccionario de alias que incluya los errores tipográficos.

La tabla de pedidos tiene una columna importe con estos valores: [22.5, 19.0, 24.3, 21.7, 480.0, 23.1, 20.9, 18.4]. Detecta outliers con el método IQR y razona (en un comentario) si el valor detectado debería eliminarse, conservarse o investigarse, sabiendo que MercaFresh también sirve a pequeños restaurantes.

Ejercicio 1

Si (c) devolviera más de 0, habría que inspeccionar esas filas con keep=False y decidir si fusionar o eliminar.

Ejercicio 2

Los errores tipográficos (madriz) no se arreglan con reglas generales: hay que descubrirlos con value_counts() y añadirlos al diccionario de alias uno a uno.

Ejercicio 3

En esta lección has aprendido a convertir un dataset caótico en uno confiable: auditar con info(), describe() y nunique(); eliminar duplicados exactos y diagnosticar los lógicos con drop_duplicates; definir reglas de validez para cazar valores imposibles; unificar categorías con str.strip/lower y replace; corregir tipos con astype, to_numeric y to_datetime; y detectar outliers con z-score e IQR sabiendo que detectarlos no es sentenciarlos. La idea central: la limpieza es análisis, no trámite — cada corrección es una decisión que debe poder explicarse.

Habrás notado que varias veces la solución honesta fue convertir un valor sospechoso en NaN: hemos ido acumulando huecos deliberadamente. En la próxima lección abordamos precisamente eso: los datos faltantes de MercaFresh, por qué faltan (que no siempre es azar) y las estrategias para eliminarlos o imputarlos sin engañar al modelo.