Text and Data Mining: cuando el volumen de datos no garantiza el resultado

Hay una suposición que se repite en casi todos los proyectos que arrancan con Text and Data Mining: si se tiene acceso a más fuentes, a más volumen, el análisis será mejor. Es una lógica intuitiva. También es uno de los errores más caros que comete quien diseña un pipeline de TDM desde cero.

El volumen importa, pero no lidera. Lo que define la utilidad real del proceso es la cadena de decisiones que viene antes y después del dato bruto: qué se procesa, con qué criterio se filtra, cómo se normaliza y en qué contexto se interpreta. Sin esa cadena bien construida, más datos equivalen a más ruido con mejor cobertura estadística.

Este post no trata de cómo obtener más datos del universo público de Internet. Trata de qué hacer con ellos para que el análisis derivado tenga valor operativo real.

El problema empieza en la definición del corpus

Todo proceso de Text and Data Mining comienza, técnicamente, con la delimitación del corpus. En la práctica, muchos equipos la delegan al proveedor o la dejan abierta "para no perder cobertura". El resultado es predecible: un conjunto de señales heterogéneo donde conviven fuentes con autoridad editorial contrastada, agregadores de baja calidad, contenido duplicado y entidades lingüísticas que el modelo posterior no sabrá distinguir.

Un corpus mal definido no penaliza solo la fase de análisis. Penaliza todo lo que viene después: el entrenamiento de modelos, la detección de tendencias, la clasificación de entidades, la generación de alertas. El daño es acumulativo y difícil de diagnosticar una vez que el pipeline está en producción.

La delimitación del corpus es una decisión editorial, no solo técnica. Requiere criterios explícitos: tipología de fuentes, idiomas, frecuencia de actualización, peso relativo de cada dominio temático. Quien no los define al principio los define implícitamente por defecto —y rara vez esos valores por defecto son los adecuados.

Normalización: el paso que más se subestima

Una vez que el dato entra al sistema, el siguiente punto crítico es la normalización. En TDM, normalizar no significa solo limpiar ruido tipográfico. Significa alinear entidades, resolver ambigüedades, gestionar variantes lingüísticas y establecer una estructura semántica que permita comparar señales entre sí.

El problema concreto: dos menciones al mismo actor, en fuentes distintas, pueden aparecer con denominaciones completamente diferentes. Si el proceso de normalización no las reconoce como equivalentes, el análisis las trata como señales independientes. El resultado es una fragmentación artificial que distorsiona cualquier métrica de frecuencia, relevancia o tendencia.

Este error es especialmente costoso en análisis multilingüe. El universo público de Internet no habla un solo idioma, y la mayoría de los pipelines de TDM están diseñados con un idioma dominante en mente. Cuando se expanden a otros mercados, la normalización falla primero y en silencio: los datos siguen llegando, los dashboards siguen mostrando cifras, pero la coherencia interna del análisis se ha roto.

El marco legal como variable operativa, no como trámite

El Art. 4 de la Directiva (UE) 2019/790 establece el derecho a realizar Text and Data Mining sobre contenidos a los que se tiene acceso lícito, con fines de investigación o análisis, sin necesidad de autorización adicional de los titulares de derechos. Este marco, transpuesto en el Art. 67 bis de la LPI española, tiene implicaciones operativas directas que van más allá del cumplimiento formal.

La primera: el perímeto del análisis debe poder justificarse como derivado, no como reproducción. Un pipeline de TDM que produce análisis original —clasificaciones, tendencias, agregaciones semánticas— está dentro del marco. Un sistema que entrega fragmentos textuales identificables de fuentes originales, aunque sea de forma automatizada, opera en un espacio diferente con riesgos diferentes.

La segunda: la trazabilidad del proceso importa. No solo para auditorías legales, sino porque un sistema que no puede explicar cómo llegó a una conclusión analítica no es útil en contextos de toma de decisiones donde la responsabilidad es exigible.

Integrar el marco legal como variable de diseño —no como validación posterior— cambia la arquitectura del pipeline. Reduce riesgos futuros y, paradójicamente, mejora la calidad del análisis derivado porque obliga a ser explícito sobre qué se está produciendo.

Cuándo el TDM falla en producción

Los fallos más frecuentes en proyectos de TDM en producción no son técnicos en origen. Son consecuencia de decisiones tomadas —o no tomadas— en fases anteriores:

• Deriva del corpus: las fuentes del universo público cambian. Dominios desaparecen, otros cambian de orientación editorial, algunos aumentan su frecuencia de publicación de forma artificial. Un corpus que no se revisa activamente se convierte en una muestra sesgada sin que nadie lo advierta.
• Clasificadores congelados: los modelos de clasificación entrenados sobre un corpus en un momento dado no se actualizan solos. El lenguaje del dominio evoluciona, aparecen nuevas entidades, cambian los marcos de referencia semánticos. Un clasificador sin ciclo de revisión empieza a fallar silenciosamente.
• Ausencia de métricas de calidad internas: muchos sistemas miden el output (número de menciones, frecuencia de señales) pero no la calidad interna del proceso (tasa de duplicados, coherencia de clasificación, deriva de cobertura). Sin esas métricas, es imposible detectar degradación antes de que el análisis sea visiblemente incorrecto.

Identificar estos puntos de fallo antes de que se manifiesten en producción es la diferencia entre un pipeline de TDM que funciona a los seis meses y uno que requiere reconstrucción.

Lo que separa el análisis útil del análisis abundante

La utilidad de un proceso de Text and Data Mining no se mide en el volumen de señales procesadas. Se mide en la capacidad de producir análisis derivado que informe decisiones reales en contextos reales.

Eso exige criterio en la definición del corpus, rigor en la normalización, coherencia legal en la arquitectura del pipeline y métricas internas que permitan detectar degradación antes de que sea visible en el output.

En TrawlingWeb el enfoque parte de esa premisa: el análisis del universo público de Internet solo tiene valor si el proceso que lo genera es lo suficientemente robusto para mantener su coherencia en el tiempo, no solo en el lanzamiento.

Si estás revisando o diseñando un pipeline de TDM y quieres contrastar cómo se resuelven estos puntos en la práctica, es el momento de hacerlo antes de que el sistema esté en producción, no después.