Text and Data Mining: el problema no es leer muchas fuentes, es hacerlas hablar igual

Ampliar el número de fuentes que alimentan un proceso de Text and Data Mining (TDM) se percibe, casi siempre, como una mejora. Más cobertura, más señales, más contexto. La lógica parece sólida. El problema aparece cuando esas fuentes no comparten ni la misma estructura, ni el mismo idioma de datos, ni el mismo ritmo de actualización — y el sistema trata de analizarlas como si lo hicieran.

El resultado no es un análisis más rico. Es un análisis contaminado por inconsistencias que no siempre se detectan a tiempo.

Este es uno de los puntos de fricción más frecuentes en proyectos reales de TDM: no la falta de datos, sino la imposibilidad de hacer que datos de orígenes distintos se comporte como un conjunto coherente. Y es, precisamente, donde la mayoría de las implementaciones acumulan deuda analítica sin saberlo.

Qué significa que dos fuentes "no hablen igual"

Cuando se trabaja con el universo público de Internet, las fuentes son estructuralmente heterogéneas por naturaleza. Un foro no organiza su información igual que un sitio de análisis sectorial. Una red social no comparte la misma densidad semántica que un documento técnico publicado en abierto. Una fuente que actualiza en tiempo real no se comporta igual que una que agrega contenido por lotes semanales.

Esta heterogeneidad tiene consecuencias concretas:

• Granularidad temporal desigual. Si una fuente emite señales cada hora y otra cada semana, cualquier análisis de tendencias que las mezcle sin control introduce distorsión cronológica. No es un problema filosófico: es un problema de representatividad.
• Vocabulario no normalizado. El mismo fenómeno puede describirse con terminología técnica en una fuente y con lenguaje coloquial en otra. Si el proceso TDM no resuelve esta brecha antes del análisis, los resultados aparecen fragmentados o, peor, duplicados con identidad distinta.
• Metadatos ausentes o inconsistentes. Fecha de publicación, autoría, ámbito geográfico, categoría temática: cuando estos campos no son fiables o directamente faltan, el análisis aguas abajo pierde anclaje. Se puede procesar el texto, pero no se puede contextualizar lo que dice.

El momento en que se suele detectar el problema (y por qué llega tarde)

La inconsistencia entre fuentes raramente se manifiesta en la fase de ingesta. Los datos entran, el volumen crece, los dashboards se llenan. La señal de alarma llega más tarde: cuando un analista compara dos períodos y los resultados no tienen sentido, o cuando un modelo entrenado con esos datos genera outputs que contradicen la realidad observable.

En ese momento, el diagnóstico correcto —"las fuentes no están normalizadas"— compite con diagnósticos incorrectos pero más intuitivos: "el modelo necesita más datos", "el algoritmo falla", "la cobertura es insuficiente". Se invierte tiempo y recursos en la dirección equivocada.

El coste real no es técnico. Es el tiempo que transcurre entre el problema y su identificación correcta, y las decisiones que se toman en ese intervalo sobre la base de análisis con grietas invisibles.

Dónde actuar antes de que el problema escale

Hay tres puntos de intervención que, si se abordan desde el diseño del pipeline TDM, evitan buena parte de esta acumulación de inconsistencias:

1. Normalización en el punto de entrada, no en el punto de uso. La tendencia habitual es posponer la limpieza y normalización de datos al momento en que se necesitan para un análisis específico. Esto crea inconsistencias acumuladas y dificulta la reproducibilidad. Normalizar estructura, timestamps y metadatos clave en el momento de la ingesta es más costoso a corto plazo y más rentable a lo largo de toda la vida del sistema.

2. Catálogo activo de fuentes con metadatos de comportamiento. No basta con saber qué fuentes se procesan. Es necesario saber cómo se comportan: frecuencia de actualización real (no declarada), tasa de cambio de estructura, idiomas presentes, densidad semántica típica. Sin este catálogo, añadir o retirar una fuente es una operación ciega.

3. Tests de coherencia entre fuentes, no solo tests de calidad por fuente. Los procesos de validación de datos tienden a evaluar cada fuente de forma aislada: ¿los campos están completos? ¿El formato es correcto? Pero la coherencia cruzada — ¿esta fuente describe el mismo fenómeno de forma compatible con las demás? — raramente se testea. Incorporar este tipo de validación reduce la tasa de contaminación silenciosa en el análisis consolidado.

Lo que diferencia un corpus TDM de una colección de textos

Un proceso de TDM bien construido no produce una colección de textos procesados. Produce un corpus: un conjunto de datos con estructura interna coherente, donde cada elemento puede relacionarse con los demás bajo criterios reproducibles.

Esa distinción importa especialmente cuando el análisis tiene que sostenerse en el tiempo. Un corpus coherente permite detectar cambios reales en el universo público que monitoriza. Una colección inconsistente genera ruido que se amplifica con cada ciclo de análisis.

En TrawlingWeb, el trabajo sobre el universo público de Internet se orienta precisamente a este punto: no solo al volumen de fuentes procesadas, sino a la consistencia del conjunto resultante. El marco legal que lo habilita — el Art. 4 de la Directiva (UE) 2019/790 sobre TDM — no distingue entre procesar muchas fuentes y procesarlas bien. Esa distinción es operativa, y tiene consecuencias directas en la utilidad del análisis.

La pregunta que conviene hacerse antes de añadir una fuente nueva

Antes de incorporar cualquier fuente nueva a un proceso TDM, hay una pregunta que raramente se formula de forma explícita: ¿esta fuente puede integrarse en el corpus existente sin degradar su coherencia?

No es una pregunta técnica, aunque tenga respuesta técnica. Es una pregunta de diseño. Responderla bien exige conocer tanto la fuente nueva como el corpus al que se incorpora.

El TDM que escala sin hacerse esa pregunta no crece. Acumula.