Text and Data Mining: cómo normalizar datos heterogéneos antes de que envenenen el análisis
Text and Data Mining: cómo normalizar datos heterogéneos antes de que envenenen el análisis
El pipeline falla. No en producción, no en el modelo, no en la API. Falla antes: en el momento en que intentas unificar datos que vienen de diez fuentes distintas y que, sobre el papel, representan lo mismo.
Eso es lo que diferencia un pipeline de Text and Data Mining funcional de uno que sobrevive a duras penas. No es la potencia del modelo de NLP. No es la frecuencia de ingesta. Es la capacidad de tratar datos heterogéneos como lo que son: registros que comparten un nombre de campo pero no necesariamente un significado operativo.
Este post va de eso. De la capa previa al análisis que la mayoría de los equipos subestima hasta que tiene el modelo entrenado con basura.
El problema real: mismo campo, distinto contrato
Imagina que tienes una señal de texto con campo fecha. Parece inocente. Pero en fuente A, la fecha es UTC. En fuente B, es hora local sin zona declarada. En fuente C, el campo viene como timestamp Unix. En fuente D, es una cadena libre tipo "hace 3 horas".
¿Cuántos equipos han pasado por esto? Prácticamente todos los que trabajan con datos del universo público de Internet en volumen real. El problema no es técnico en el sentido estricto. Es contractual: cada fuente tiene su propio contrato implícito sobre qué significa cada campo.
Sin una fase de normalización explícita, el análisis temporal queda distorsionado. Los modelos de detección de tendencias generan falsos positivos. Las alertas se disparan tarde o nunca. Y lo peor: el sistema no lanza ningún error. Produce resultados, pero incorrectos.
Cuatro dimensiones de heterogeneidad que nadie documenta
1. Encodings y caracteres no esperados
UTF-8 es el estándar. Pero en cuanto procesas fuentes públicas de alcance amplio, encuentras Latin-1 sin declarar, Windows-1252 disfrazado de UTF-8, y campos con secuencias de escape HTML sin decodificar (&, ", entidades numéricas como ’).
El resultado: tokens que el tokenizador parte mal, entidades nombradas que el NER no reconoce, y frecuencias de términos completamente sesgadas porque "España" y "Espa\u00f1a" cuentan como dos términos distintos.
Acción concreta: añade una fase de normalización de encoding antes de tokenizar. No después. Nunca después.
2. Granularidad temporal inconsistente
El análisis de tendencias depende de comparar señales en ventanas de tiempo. Si tus fechas no están alineadas a una referencia única —UTC, en general— cualquier agregación temporal es una ficción.
El caso más silencioso: fuentes que actualizan su timestamp al republicar contenido. Un dato analizado hoy puede llevar una fecha de hoy aunque el texto original tenga meses. Sin detectar esto, contaminas el análisis de señales recientes con ruido histórico.
Acción concreta: guarda siempre la fecha de primera observación separada de la fecha del campo fuente. Son dos cosas distintas. Tratalas como tales.
3. Entidades nombradas con variantes de superficie
"Pedro Sánchez", "P. Sánchez", "el presidente del Gobierno", "Sánchez" como apellido suelto. Cuatro formas de referirse al mismo sujeto. Si tu pipeline cuenta menciones, vas a tener cuatro contadores distintos que en realidad miden lo mismo.
Esto escala rápido. En un corpus de análisis de cobertura mediática, sin resolución de entidades, los grafos de co-ocurrencia se fragmentan, los rankings de relevancia pierden fiabilidad y los modelos de clasificación aprenden variantes como si fueran conceptos distintos.
Acción concreta: implementa un paso de canonicalización antes de agregar. No hace falta un sistema de resolución de entidades de nivel enterprise desde el día uno. Un diccionario de alias controlado ya reduce el ruido de forma significativa.
4. Longitud y estructura del texto
Una señal de 12 palabras y una de 1.200 no pueden tratarse con el mismo pipeline de extracción sin ajustes. Los vectorizadores basados en TF-IDF se comportan de forma distinta según la longitud del documento. Los embeddings de frases tienen sesgos según si el texto es un titular, un párrafo o un hilo de varias entradas.
Sin segmentar por tipo estructural de texto antes de procesar, mezclas distribuciones incompatibles. El modelo aprende una representación promedio que no representa bien ninguna de las dos.
Acción concreta: clasifica tus datos por tipología estructural en la ingesta, no en el modelo. Es una decisión de arquitectura, no de ML.
La normalización no es limpieza: es semántica
Hay una confusión frecuente entre normalizar y limpiar. Limpiar elimina ruido: HTML residual, caracteres de control, espacios duplicados. Normalizar unifica representaciones distintas de un mismo concepto.
Las dos operaciones son necesarias, pero no son intercambiables ni tienen el mismo coste. Limpiar es barato y se puede estandarizar. Normalizar requiere conocer el dominio: saber que en tu corpus "EEUU", "EE.UU.", "Estados Unidos" y "US" deben colapsar en un único término canónico.
Eso no lo hace ningún preprocesador genérico. Lo hace quien entiende qué datos está procesando y para qué.
Cuándo construir la normalización y cuándo delegarla
La normalización ad hoc —hecha para cada proyecto— no escala. Si tu equipo replica lógica de normalización en cada pipeline nuevo, estás acumulando deuda técnica invisible. Cada variante introduce pequeñas diferencias que hacen los resultados incomparables entre proyectos.
La alternativa es construir una capa de normalización centralizada que actúe como contrato interno: cualquier dato que entra al sistema de análisis ha pasado por ella. Eso permite comparar resultados entre fuentes, entre fechas, entre proyectos.
Plataformas como FeedScale entregan datos ya procesados desde el universo público bajo un esquema consistente, lo que reduce —aunque no elimina— el coste de esta fase. El esquema homogéneo resuelve la heterogeneidad estructural. La normalización semántica sigue siendo responsabilidad del equipo de análisis.
Antes de añadir más datos, normaliza los que tienes
La tentación habitual es ampliar el corpus. Más fuentes, más señales, más cobertura. Pero añadir volumen sobre una base heterogénea no mejora el análisis: lo degrada de forma proporcional.
Un corpus más pequeño, correctamente normalizado, produce modelos más fiables, alertas más precisas y resultados reproducibles. La escala tiene sentido cuando la base es sólida. Añadir fuentes antes de tener esa base es un error que los equipos suelen detectar solo cuando los resultados en producción no cuadran con las expectativas del prototipo.
La normalización no es una tarea que se hace una vez al principio. Es una disciplina continua. Cada fuente nueva introduce potencialmente nuevas variantes. Cada cambio en una fuente existente puede romper las asunciones anteriores.
El pipeline robusto no es el que procesa más datos. Es el que sabe exactamente qué está procesando en cada momento.