Blog institucional

Text and Data Mining: qué hacer cuando el dato existe pero no responde a la pregunta

Text and Data Mining: qué hacer cuando el dato existe pero no responde a la pregunta

Hay una situación que se repite en equipos de inteligencia, análisis de mercado y desarrollo de modelos: el dato está ahí, es accesible, llega en volumen razonable — y aun así no sirve para responder la pregunta que se hizo al principio. No porque falte información. Sino porque la información disponible y la pregunta formulada no están alineadas en origen.

Ese desajuste es el problema real de la mayoría de proyectos de Text and Data Mining. No es un problema técnico. Es un problema de diseño.

Entender dónde se produce ese desajuste — y cómo corregirlo antes de que el pipeline esté operativo — es lo que separa un ejercicio de TDM que genera valor de uno que genera informe tras informe sin que nadie cambie ninguna decisión.


El error más frecuente: definir la fuente antes que la pregunta

Cuando un proyecto de TDM arranca con "vamos a procesar X tipo de fuente", el orden es incorrecto. La fuente debería derivarse de la pregunta, no al revés.

Si la pregunta es "¿qué percepción tiene el mercado europeo sobre la normativa de IA?", las fuentes relevantes no son todas las disponibles — son las que concentran conversación técnica y regulatoria en ese contexto geográfico: foros especializados, publicaciones institucionales, documentos legislativos públicos, menciones en entornos profesionales. Definir primero "procesamos medios generalistas" y luego intentar responder esa pregunta es trabajar con el instrumento equivocado.

Este error es costoso porque no se detecta en la fase de ingestión. Se detecta en la fase de análisis, cuando los resultados no son incorrectos — simplemente son irrelevantes para la decisión que se quería tomar.


Qué significa que un dato "no responda" la pregunta

Un dato puede estar bien estructurado, correctamente procesado y ser técnicamente impecable, y aun así no ser útil. Hay tres causas principales:

Desfase temporal. El dato llegó tarde. En contextos donde la señal tiene una vida útil de horas — una mención que puede detonar una crisis, un movimiento regulatorio que cambia el entorno competitivo —, recibir el dato con 48 horas de retraso convierte el análisis en historia, no en inteligencia.

Ausencia del contexto lingüístico o geográfico correcto. Muchos proyectos de TDM se diseñan en una lengua pero la conversación relevante ocurre en otra. El universo público de Internet no es uniforme: hay fenómenos que emergen primero en inglés, otros en lenguas locales, otros en registros técnicos que los sistemas generalistas no indexan bien. Si el sistema no cubre esa variante, el dato simplemente no está.

Granularidad inadecuada. La pregunta exige un nivel de detalle que la fuente no ofrece. Agregar millones de menciones superficiales sobre un tema puede producir una curva de tendencia, pero no explicar por qué esa tendencia se produce ni qué actores la están impulsando. A veces se necesita menos volumen y más profundidad en un subconjunto específico de fuentes.


Cómo corregir el desajuste en la fase de diseño

Antes de lanzar cualquier proceso de TDM a escala, vale la pena responder tres preguntas concretas:

1. ¿Cuál es la decisión que este análisis debe informar? No "qué quiero saber", sino qué acción cambiará en función del resultado. Si la respuesta es vaga, el análisis también lo será.

2. ¿En qué tipo de fuente está la señal que necesito? Esto determina si el foco debe estar en foros técnicos, en documentación institucional, en conversación pública en redes, en medios especializados o en cualquier combinación. La respuesta cambia radicalmente según el sector y el objetivo.

3. ¿Con qué ventana temporal es útil ese dato? Un análisis de tendencias a seis meses puede tolerar latencia. Una alerta reputacional no puede esperar ni una hora. Ese parámetro tiene que definirse antes de diseñar la infraestructura, no ajustarse a posteriori.


El rol del marco legal: Art. 4 Directiva (UE) 2019/790

El Text and Data Mining sobre fuentes públicas está amparado en el Art. 4 de la Directiva (UE) 2019/790, transpuesta en España mediante el Art. 67 bis LPI. Este marco permite el procesamiento automatizado de contenidos accesibles públicamente con fines analíticos, siempre que no implique redistribución de los contenidos originales.

Esto tiene una implicación práctica directa: el análisis derivado — tendencias, señales, patrones — es el producto legítimo del TDM, no la reproducción de los textos procesados. Cualquier arquitectura que no distinga entre ambas capas está, además de crear riesgo legal, produciendo el tipo de output equivocado.

En TrawlingWeb todo el procesamiento del universo público de Internet se enmarca explícitamente en este marco. El análisis derivado que llega al cliente no es contenido de terceros — es inteligencia generada a partir de él.


Cuándo reformular la pregunta en lugar de cambiar la fuente

Hay situaciones en las que el problema no está en las fuentes sino en la pregunta misma. Si después de revisar el diseño del proyecto los resultados siguen siendo poco accionables, conviene preguntarse si la pregunta formulada es realmente la correcta.

Un equipo que pregunta "¿cuántas menciones tiene nuestra marca esta semana?" raramente necesita ese dato en sí mismo. Lo que necesita saber es si hay un cambio de tendencia, si hay un actor nuevo amplificando negativo, si una señal específica se está acelerando. Esas son preguntas distintas que requieren métricas distintas.

El TDM no es útil por el volumen de datos que procesa. Es útil cuando la arquitectura de la pregunta y la arquitectura del dato están alineadas desde el principio. Ajustar eso no es un problema técnico que resolver con más potencia de cómputo — es una decisión de diseño que hay que tomar antes de que el sistema esté en producción.


Si estás diseñando un proyecto de Text and Data Mining y los primeros resultados no conectan con las decisiones que necesitas tomar, el problema casi nunca está en el algoritmo. Está en alguno de los tres puntos anteriores. Identificarlo a tiempo es lo que hace que el esfuerzo de escalar el procesamiento tenga sentido. Puedes explorar cómo TrawlingWeb aborda este diseño en trawlingweb.com.

← Volver al blog Hablar con el equipo