Text and Data Mining: cómo evitar que el análisis empiece donde debería terminar

Hay un error que se repite con precisión en proyectos de Text and Data Mining: el equipo dedica semanas a afinar el modelo y casi ningún tiempo a revisar qué datos lo alimentan. Cuando los resultados llegan, el problema ya ocurrió mucho antes del primer entrenamiento.

El TDM no es una técnica de análisis. Es un proceso que empieza en la selección de fuentes y termina —si todo va bien— en una conclusión accionable. Cada paso intermedio que se ignora se convierte en un vector de error silencioso. Y los errores silenciosos en TDM son los más caros, porque no se detectan hasta que alguien toma una decisión equivocada con confianza.

Este post no trata de definir qué es el TDM. Trata de señalar exactamente dónde se rompe, y qué variables controlan esa ruptura.

El perímetro del análisis no lo define el equipo, lo define la cobertura

Cuando un equipo de inteligencia diseña un proceso de TDM, tiende a pensar en el modelo, en las categorías de análisis, en los dashboards. Lo que rara vez define con precisión es el perímetro real de las fuentes que va a procesar.

Ese perímetro lo determina la infraestructura de acceso al universo público de Internet. Y ese universo no es estable. Las fuentes cambian su estructura sin previo aviso. Aparecen nuevas publicaciones relevantes que no estaban en el corpus inicial. Otras dejan de actualizarse sin que nadie lo notifique.

Si el perímetro de cobertura no se valida de forma continua, el análisis se va achicando sin que nadie lo vea. En seis meses, un modelo diseñado para cubrir 500 fuentes puede estar procesando, en la práctica, 320 —porque el resto ha rotado o ha cambiado de formato.

El resultado: patrones que parecen tendencias pero son artefactos de cobertura incompleta.

La granularidad temporal cambia la naturaleza del análisis

No es lo mismo procesar menciones con una latencia de 15 minutos que hacerlo cada 24 horas. No porque una sea "mejor" en abstracto, sino porque cada frecuencia habilita un tipo distinto de decisión.

Con latencia alta, el TDM sirve para análisis retrospectivos: ¿qué pasó esta semana?, ¿cómo evolucionó una tendencia en el último mes? Con latencia baja, habilita intervención: detección temprana de crisis, señales de cambio de narrativa, alertas operativas.

El error habitual es diseñar el análisis para una latencia y operar con otra. Un sistema pensado para detección temprana que recibe datos con 18 horas de retraso no falla en el modelo: falla en el contrato implícito con el usuario.

Antes de definir qué se analiza, hay que fijar con qué latencia se necesita el resultado —y construir la cadena de procesamiento hacia atrás desde ese requisito.

La normalización es donde muere más análisis del que se reconoce

El universo público de Internet no habla un solo idioma estructural. Una misma señal —un pico de menciones en torno a un tema— puede aparecer como texto libre en un foro, como metadata en un feed RSS, como texto extraído de un PDF institucional o como comentarios en hilos desestructurados.

Hacer TDM sobre esa heterogeneidad sin una capa de normalización produce análisis que comparan cosas incomparables. El modelo no lo sabe. Procesa lo que recibe. Si recibe basura estructural, produce patrones que parecen significativos pero no lo son.

La normalización no es un paso de limpieza que se hace una vez al principio. Es un proceso continuo que debe adaptarse cada vez que una fuente cambia su formato, cada vez que se incorpora un nuevo tipo de contenido, cada vez que el corpus crece en cobertura geográfica o idiomática.

Los equipos que tratan la normalización como un coste operativo suelen descubrir, demasiado tarde, que era su principal variable de calidad.

El marco legal no es un obstáculo: es la palanca que hace el TDM posible

El Art. 4 de la Directiva (UE) 2019/790 —transpuesto en España como Art. 67 bis LPI— establece que cualquier entidad con acceso legítimo a fuentes públicas puede realizar Text and Data Mining sobre esas fuentes sin necesidad de autorización expresa de los titulares de los derechos.

Esto no es un tecnicismo. Es la base legal que permite operar sobre el universo público de Internet a escala, sin tener que negociar licencias fuente por fuente. Pero ese derecho tiene condiciones: el acceso debe ser legítimo, el procesamiento debe generar análisis derivado —no redistribución—, y las fuentes deben ser públicamente accesibles.

Los equipos que no conocen este marco suelen ser excesivamente conservadores en su cobertura —descartan fuentes que podrían procesar legalmente— o excesivamente laxos —incorporan fuentes cuyo uso no está amparado—. Ambos errores tienen consecuencias: uno reduce la calidad del análisis, el otro introduce riesgo legal.

El TDM bien ejecutado empieza por entender qué se puede procesar y bajo qué condiciones. No por el modelo.

Qué separa un proceso de TDM funcional de uno que acumula deuda oculta

Un proceso de TDM funcional tiene cuatro características observables:

Cobertura auditada. El perímetro de fuentes se revisa de forma regular. Se documenta qué fuentes están activas, cuáles han cambiado de estructura y cuáles han dejado de ser relevantes.

Latencia declarada. El equipo sabe con precisión cuánto tiempo pasa entre que un contenido aparece en una fuente pública y cuándo está disponible para el análisis. Y ese tiempo está alineado con el tipo de decisión que el proceso debe habilitar.

Normalización versionada. Cada vez que cambia el formato de una fuente o se incorpora un nuevo tipo de contenido, hay un proceso documentado para adaptar la capa de normalización. No se improvisa.

Marco legal operativo. El equipo no solo sabe que el TDM está permitido por el Art. 4 de la Directiva. Sabe qué fuentes están dentro del perímetro legal, qué tipo de procesamiento está cubierto y qué constituiría redistribución no autorizada.

La mayoría de los proyectos que fracasan en TDM no tienen un problema de modelo. Tienen un problema en alguno de estos cuatro puntos. Y generalmente lo descubren cuando ya han invertido meses en el análisis.

La infraestructura que permite hacer TDM a escala sobre el universo público de Internet no es un componente técnico entre otros. Es la condición de posibilidad de todo lo que viene después. En TrawlingWeb trabajamos exactamente en esa capa: el acceso estructurado, continuo y legalmente fundado a las fuentes públicas que alimentan el análisis.

Si tu proceso de TDM está produciendo resultados inconsistentes, la pregunta que vale la pena hacerse primero no es qué falla en el modelo. Es qué le estás dando al modelo para trabajar.