Text and Data Mining: por qué la calidad del dato de entrada decide el análisis antes de que empiece

Cuando un proyecto de Text and Data Mining produce resultados inesperados, el primer instinto es revisar el modelo. Ajustar parámetros. Cambiar el enfoque de clasificación. Pocas veces el equipo vuelve al origen y se pregunta qué había exactamente en los datos que alimentaron ese proceso.

Es un error sistemático. Y es costoso.

El TDM no fracasa principalmente por problemas de algoritmo. Fracasa por datos que parecen válidos pero no lo son: fuentes que duplican señales, registros con metadatos corruptos, textos truncados por limitaciones técnicas de origen, idiomas mezclados sin etiqueta, fechas de publicación inconsistentes con el momento real de aparición. Todo eso entra en el pipeline, se procesa y produce una salida que nadie puede confiar del todo, aunque tenga buena pinta.

La pregunta que hay que hacerse antes de cualquier ejercicio de TDM no es ¿qué quiero analizar? sino ¿qué me garantiza que lo que tengo es lo que creo que tengo?

El problema de la procedencia opaca

Una parte significativa del universo público de Internet no llega etiquetada. Un texto puede proceder de un agregador que lo redistribuyó, de una fuente secundaria que lo reescribió, o de una versión automatizada generada a partir de otro texto original. Si el sistema de TDM no distingue la procedencia real, el análisis toma como señales independientes lo que en realidad son ecos del mismo origen.

Esto importa especialmente en análisis de tendencias y detección de narrativas emergentes. Si el 40% de los registros sobre un tema provienen de una sola fuente redistribuida en múltiples puntos del universo público, la tendencia que detecta el modelo no refleja un consenso real: refleja la amplitud de distribución de una sola voz. El análisis es técnicamente correcto y analíticamente engañoso.

La solución no es eliminar esas fuentes. Es conocerlas, clasificarlas y ponderar su peso en el análisis de forma explícita. Eso requiere que la infraestructura de procesamiento documente la procedencia, no solo el contenido.

Duplicados, cuasi-duplicados y el efecto de amplificación espuria

Los duplicados exactos son fáciles de detectar. El problema real son los cuasi-duplicados: textos que comparten entre el 60% y el 85% de su contenido pero con variaciones suficientes para pasar los filtros de deduplicación estándar. Son frecuentes en el universo público porque los sistemas de distribución de contenido tienen esa lógica incorporada: versiones para distintas audiencias, titulares reformulados, aperturas adaptadas por mercado.

En un corpus de TDM sin tratamiento de cuasi-duplicados, esos textos inflan la frecuencia de ciertos términos, expresiones y marcos narrativos. El modelo aprende que algo es más relevante de lo que realmente es, porque lo ha visto más veces de lo que debería. La salida del análisis tiene sesgos que no aparecen en ningún log de error.

Detectar cuasi-duplicados exige comparación semántica, no solo textual. Y eso tiene un coste computacional que los equipos suelen evitar, especialmente cuando el corpus es grande. El problema es que ese ahorro se paga después, en forma de conclusiones que no aguantan la revisión manual.

Fechas que mienten y lo que implican para el análisis temporal

El TDM aplicado a fuentes públicas tiene una dependencia crítica con las marcas temporales. Un análisis de evolución de narrativas, de velocidad de propagación de una señal o de estacionalidad en menciones depende de que la fecha asociada a cada registro sea la fecha real de publicación, no la fecha de indexación, redistribución o última modificación técnica del documento.

En el universo público esto es un problema estructural. Muchas fuentes no tienen metadatos temporales fiables. Otras los tienen pero en formatos inconsistentes entre sí. Algunas actualizan la marca de tiempo cada vez que modifican cualquier elemento de la página, aunque el texto no haya cambiado. El resultado es un corpus donde los registros de una misma semana pueden tener distribuciones temporales que no reflejan cuándo ocurrió nada, sino cuándo el sistema los vio por última vez.

Para cualquier análisis con dimensión temporal, esto es determinante. Un pico de menciones que parece ocurrir en un martes puede ser el artefacto de una re-indexación masiva. Una tendencia que parece acelerarse puede ser simplemente la consecuencia de que más fuentes empezaron a ser procesadas ese mes.

Auditar las marcas temporales antes del análisis no es opcional cuando el tiempo es una variable del modelo.

Lo que la infraestructura debe garantizar antes del análisis

Hay decisiones que no se toman en el momento del análisis, sino en el diseño de la infraestructura que entrega los datos. Cuando esa infraestructura no está pensada para TDM, el analista recibe materiales que requieren un trabajo de limpieza y validación que no siempre se hace de forma sistemática.

Una infraestructura preparada para TDM debe garantizar, como mínimo:

• Procedencia documentada para cada registro, con distinción entre fuente original y fuente de distribución.
• Normalización temporal basada en señales de publicación originales, no en fechas de procesamiento.
• Gestión de duplicados y cuasi-duplicados antes de que los datos lleguen al pipeline de análisis.
• Etiquetado de idioma y variante lingüística validado, no inferido únicamente por dominio geográfico.
• Indicadores de integridad que señalen registros truncados, con codificación deficiente o con campos clave vacíos.

Ninguno de estos elementos es sofisticado desde un punto de vista conceptual. Pero su ausencia convierte cualquier ejercicio de TDM en una operación con incertidumbre no cuantificada en su base.

Antes de confiar en el análisis, hay que confiar en los datos

El Text and Data Mining, aplicado al universo público de Internet, tiene una característica que lo distingue de otros entornos analíticos: los datos no los genera quien los analiza. Proceden de millones de fuentes con lógicas, formatos y motivaciones distintas. Esa heterogeneidad es exactamente lo que hace valioso el TDM como disciplina. Y es también lo que lo hace frágil si la infraestructura no está diseñada para gestionarla.

En TrawlingWeb, el procesamiento del universo público está diseñado desde la infraestructura, no desde el análisis. Eso significa que la validación de procedencia, la normalización temporal y el tratamiento de duplicados ocurren antes de que los datos lleguen al cliente, no después de que el análisis haya fallado.

La siguiente vez que un resultado de TDM sorprenda negativamente, antes de revisar el modelo, vale la pena preguntarse si alguien auditó lo que entró.