Datos para IA: La verdad incómoda que nadie quiere oír (y por qué es mi prioridad número uno)

He visto proyectos de IA tropezar, no por un algoritmo mal elegido o un ajuste pobre de hiperparámetros, sino por algo mucho más básico y, a menudo, ignorado: la calidad de los datos. Y te lo digo sin rodeos: si los datos son basura, tu IA también lo será. Punto. No hay magia, ni arquitectura de redes neuronales, ni fine-tuning que salve una base podrida.

La decepción de la ‘promesa’ de la IA

Recuerdo una vez, al inicio de mi carrera, estaba emocionado con un modelo de detección de anomalías. Pasé semanas optimizando, probando librerías, y la verdad, los números en mi entorno de desarrollo se veían espectaculares. Cuando lo desplegamos en producción, fue un desastre. Falsos positivos a mansalva, falsos negativos importantes… Pasé noches enteras depurando, revisando el código, las métricas, todo. ¿La culpa? Unos logs de entrada que, en teoría, estaban “limpios”, pero en realidad tenían valores nulos camuflados, errores de tipografía en las etiquetas y cambios de formato que nadie había documentado. Aquello me marcó a fuego: el 80% del problema de la IA está en los datos, no en el algoritmo.

¿Qué es un buen dato para la IA? (Mi definición personal)

Para mí, un buen dato no es solo un montón de números en un CSV. Un buen dato es:

• Preciso: Refleja la realidad sin errores. Si una transacción es de 100€, es 100€, no 10€. Parece obvio, pero los errores de entrada manual o de sistemas legacy son una plaga.
• Completo: No faltan piezas clave. Un NaN puede ser una señal o un agujero negro que el modelo intentará adivinar, y créeme, lo hará mal la mayoría de las veces. Aquí siempre pienso en el famoso “garbage in, garbage out”.
• Consistente: Sigue las mismas reglas y formatos a lo largo del tiempo. New York, NY, Nueva York… Para el modelo, son entidades distintas a menos que las unifiques.
• Relevante: Es útil para el problema que intentas resolver. De poco sirve tener gigabytes de datos si la mayoría no aporta señal.
• Oportuno: Está disponible cuando se necesita y refleja el estado actual del mundo (o el período de interés).

Mis batallas diarias: lo que me quita el sueño

1. Valores Faltantes (Missing Values): Siempre es la primera trinchera. ¿Los imputo? ¿Con qué valor? ¿Media, mediana, un modelo predictivo? Mi regla de oro: el menos invasivo posible. Si tengo muchos nulos en una columna, a veces es mejor quitarla que inventarme una realidad. Y si los imputo, lo documento hasta el aburrimiento. Una vez, un cliente tenía nulos que significaban “no aplica”, no “desconocido”, y eso cambió todo el enfoque del problema. El contexto es El Contexto lo es todo en Agentes de IA: Por qué un buen prompt no basta (y cómo lo construyo yo).

2. Ruido y Outliers: Estos son veneno. Un par de valores extremos pueden sesgar medias, desviaciones estándar, y hacer que tu modelo aprenda patrones que no existen. Mis ojos están entrenados para buscar histogramas extraños, diagramas de caja con puntos lejanos. Y no, no siempre los quito; a veces son la señal que buscamos, pero hay que entenderlos.

3. Inconsistencias y Duplicados: La pesadilla de las bases de datos mal diseñadas. Correos duplicados, identificadores que cambian, formatos de fecha aleatorios. Esto me hace perder horas, y es una razón por la que siempre, siempre, hago un análisis exploratorio de datos (EDA) exhaustivo antes de tocar un solo algoritmo.

4. Sesgos Ocultos: Este es el más traicionero. Tus datos pueden ser perfectos técnicamente (sin nulos, consistentes), pero reflejar prejuicios del mundo real. Si tu modelo aprende de datos sesgados, replicará y amplificará ese sesgo. Es una batalla constante y delicada. Para profundizar, ya escribí sobre El sesgo implícito en tus datos: mi pesadilla más recurrente (y cómo intento no pasarla por alto).

Mi proceso (y por qué no es glamuroso)

Cuando empiezo un proyecto de IA, mi primer paso no es import tensorflow. Es import pandas y mucho mirar, limpiar y entender. Mi ritual incluye:

• Exploración profunda: No me fío de los resúmenes. Histogramas, diagramas de dispersión, tablas de frecuencias. Quiero ver los datos, sentir su forma, sus aberraciones. df.describe() y df.info() son mis primeros amigos, pero solo el inicio.
• Definición de reglas de limpieza: Una vez entiendo las anomalías, defino reglas claras. ¿Cómo trataré los nulos en columna_A? ¿Y los outliers en columna_B? Esto es vital, no solo para el modelo, sino para la observabilidad futura del sistema.
• Automatización de la limpieza (cuando se puede): Para datos que llegan continuamente, la limpieza debe ser parte del pipeline. Aquí uso herramientas como Great Expectations o simplemente funciones robustas que he escrito yo mismo para aplicar mis reglas. Esto reduce el error humano y garantiza consistencia.
• Documentación obsesiva: Cada decisión de limpieza, cada imputación, cada eliminación de outliers debe estar documentada. Es el rastro de pan rallado para cuando algo falle o alguien más tenga que entender mi trabajo.

El valor de la paciencia (y la frustración)

Sé que limpiar datos es la parte menos sexy del Machine Learning. No es lo que se enseña en los cursos de “IA para todos”. Pero es, con diferencia, lo más importante. Una vez un buen ingeniero de datos me dijo: “Tu modelo es tan bueno como tu peor dato”. Y en mi experiencia, no hay verdad más rotunda. Deja de buscar el algoritmo mágico y empieza por asegurarte de que lo que le das de comer no es veneno. Te prometo que te ahorrará muchas noches de debugging y frustración.