Text and Data Mining: por qué normalizar el texto antes de analizar destruye menos señal de la que crees
Text and Data Mining: por qué normalizar el texto antes de analizar destruye menos señal de la que crees
El paso que más se infravalora en un pipeline de Text and Data Mining no es la extracción ni el modelado. Es la normalización. El momento en que decides qué hacer con las mayúsculas, los signos de puntuación, los emojis, las entidades nombradas y las palabras compuestas. Esas decisiones, tomadas en minutos, determinan qué información llega viva al análisis y qué se descarta sin posibilidad de recuperación.
El problema no es que los equipos normalicen mal. Es que normalizan rápido, copiando recetas genéricas de tutoriales de NLP que asumen texto limpio, homogéneo y en inglés. Los datos del universo público de Internet no son ninguna de esas tres cosas.
La normalización no es un paso neutro
Convertir todo a minúsculas parece inofensivo. No lo es. "Apple" (empresa) y "apple" (fruta) dejan de distinguirse. "COVID" y "covid" pueden comportarse de forma diferente en clasificadores entrenados sobre corpus anteriores a 2020. "US" (Estados Unidos) y "us" (pronombre) son tokens distintos con pesos radicalmente diferentes en embeddings especializados.
El mismo problema aparece con la eliminación de stopwords. Las listas estándar de stopwords en español incluyen "no", "sin", "nunca". Si tu objetivo es sentiment analysis o detección de negación, eliminar esas palabras antes de analizar no limpia el ruido: destruye la señal que ibas a medir.
La regla de oro es simple pero rara vez se aplica: la decisión de normalización debe tomarse en función del objetivo analítico, no del pipeline genérico.
Cuatro decisiones de normalización que cambian el resultado final
1. Stemming vs. lematización: no son intercambiables
El stemming trunca morfológicamente las palabras para reducirlas a una raíz común. Es rápido y determinista. Pero "crisis" y "crisis" (errata frecuente) pueden colapsar en el mismo stem, mientras que "banco" (entidad financiera) y "banco" (mueble) mantienen la misma forma sin distinción posible.
La lematización consulta el contexto gramatical antes de reducir la palabra. Es más lenta, requiere un modelo lingüístico de calidad, pero produce un token con semántica más estable. Para análisis sobre fuentes públicas —donde la variación morfológica es alta y los errores tipográficos son constantes— la lematización produce pipelines más robustos aunque añada latencia.
Si el volumen de texto es masivo y la latencia importa, una estrategia híbrida funciona: lematización para entidades nombradas y términos clave del dominio; stemming para el resto del vocabulario.
2. El tratamiento de las entidades nombradas (NER) antes de normalizar
Un error frecuente es aplicar normalización global antes de ejecutar el reconocimiento de entidades nombradas. Si transformas "Telefónica" en "telefonica" o eliminas la tilde de "Ángeles" antes de que el modelo NER lo procese, el reconocedor pierde precisión porque fue entrenado sobre texto no transformado.
El orden correcto: NER primero, normalización después. Las entidades detectadas se reemplazan por tokens protegidos (__ORG_0__, __PER_1__) que sobreviven intactos a cualquier transformación posterior. Al final del pipeline se reintegran con su forma canónica.
Este patrón no es nuevo, pero sorprende cuántos pipelines productivos lo ignoran porque alguien decidió «simplificar» el preprocesamiento en la fase de prototipado y nadie lo revisó después.
3. Texto con estructura implícita: no todo es prosa libre
Los datos del universo público incluyen titulares, subtítulos, pies de foto, transcripciones, hilos de redes sociales, foros técnicos y comentarios. Cada uno tiene gramática implícita distinta.
Un titular de medios omite artículos y verbos auxiliares: "Gobierno aprueba presupuestos sin consenso". Tokenizado junto a prosa convencional, el modelo aprende patrones espurios. Una transcripción de audio tiene muletillas, interrupciones y cambios de tema bruscos que contaminan cualquier análisis de coherencia textual.
La solución no es compleja: etiquetar el tipo de fuente como metadato antes de normalizar y aplicar estrategias de preprocesamiento diferenciadas por tipo. Un campo source_type en el esquema del pipeline es suficiente para bifurcar el tratamiento.
4. Caracteres especiales, URLs y menciones: cuándo eliminar y cuándo transformar
Eliminar URLs a ciegas borra contexto. Una URL que contiene el nombre de un producto o de una campaña es información. Lo correcto es extraer el dominio como token (__DOMAIN_elpais_com__) y descartar el resto.
Las menciones en redes sociales (@usuario) pueden ser ruido o pueden ser nodos de red relevantes para análisis de influencia. La decisión no es técnica, es analítica. El pipeline debe recibir esa instrucción como parámetro configurable, no como constante hardcoded.
El coste real de normalizar mal en producción
Un pipeline que normaliza de forma incorrecta no falla ruidosamente. Falla en silencio. Los modelos downstream aprenden sobre texto transformado, generan resultados que parecen coherentes y nadie detecta el problema hasta que los insights producidos no coinciden con la realidad observable.
En pipelines que consumen señales de fuentes públicas a través de APIs —como los que se construyen sobre plataformas como FeedScale— el volumen de texto entrante puede ser lo suficientemente alto como para que los errores de normalización se propaguen durante días antes de que un analista note la desviación. A ese punto, reentrenar o recalibrar cuesta semanas.
Instrumentar el pipeline con métricas de cobertura de vocabulario por lote —cuántos tokens nuevos aparecen respecto al lote anterior, cuántos tokens se pierden por truncado— permite detectar derivas en la normalización antes de que afecten a los modelos de análisis.
Qué revisar en el pipeline antes de la próxima iteración
Si el pipeline ya está en producción, estas son las tres auditorías más rentables de hacer en orden:
Auditar el orden de operaciones. Comprueba que NER, detección de idioma y clasificación de tipo de fuente se ejecutan antes de cualquier transformación destructiva. Si no es así, el refactor es corto pero el impacto es alto.
Revisar las listas de stopwords. Si usas una lista genérica, filtra las palabras que en tu dominio tienen peso semántico real. Una sesión de una hora con el equipo analítico produce una lista de excepciones que mejora la precisión de forma inmediata.
Parametrizar las decisiones de normalización. Las reglas que hoy son correctas pueden no serlo cuando cambia el tipo de fuente o el idioma predominante del corpus. Si están hardcoded, cada ajuste requiere un despliegue. Si son parámetros de configuración, el equipo analítico puede iterar sin tocar código.
La normalización es donde se decide silenciosamente qué entiende el sistema y qué ignora. No es un paso técnico menor. Es la primera decisión analítica del pipeline, y merece el mismo rigor que cualquier otra.