Text and Data Mining: cómo extraer señales accionables sin ahogar el pipeline en volumen
Text and Data Mining: cómo extraer señales accionables sin ahogar el pipeline en volumen
Hay un problema que aparece tarde, siempre en producción, y casi nunca en la fase de diseño: el pipeline procesa más de lo que puede absorber con sentido. El equipo celebró el acceso a millones de señales del universo público. Nadie calculó que el 94% de ese volumen no tenía valor analítico para el caso de uso en cuestión.
Text and Data Mining (TDM) no es un problema de infraestructura. Es un problema de criterio. La infraestructura aguanta — o se escala. Pero si el criterio de selección falla desde el inicio, escalar solo multiplica el ruido y el coste.
Este post es para equipos técnicos que ya tienen acceso a APIs de análisis del universo público y quieren diseñar la capa TDM con lógica, no con fuerza bruta.
El error de tratar el volumen como sinónimo de cobertura
Más menciones no implica más cobertura analítica útil. Este es el primer axioma que el pipeline debe interiorizar.
El universo público de Internet genera señales heterogéneas: algunas son editoriales con contexto rico, otras son réplicas sindicadas, otras son fragmentos sin referente claro. Ingestar todo con la misma prioridad es una decisión que destruye el ratio señal/ruido antes de que llegue cualquier modelo de análisis.
La estrategia correcta parte de una pregunta simple: ¿qué tipo de señal necesita realmente el consumidor final del dato? Si la respuesta es "menciones de una entidad en fuentes de alto impacto con contexto semántico suficiente", el filtrado debe ocurrir en la ingestión, no en la visualización.
Aplicar TDM sin esta decisión previa equivale a minar todo un yacimiento para encontrar tres gramos de material útil. Técnicamente posible. Económicamente absurdo.
Dónde colocar la lógica de extracción: antes del modelo, no después
Un error frecuente en arquitecturas TDM es delegar todo el criterio de relevancia al modelo de lenguaje o al motor de análisis. El modelo recibe un volumen sin filtrar, lo procesa y devuelve resultados. Esto funciona en demos. En producción, el coste por llamada se dispara y la latencia crece.
La lógica de extracción debe operar en capas:
Capa 1 — Filtrado estructural. Antes de cualquier procesamiento semántico: longitud mínima del texto, idioma detectado, tipo de fuente, fecha de publicación. Estas reglas son baratas y eliminan un porcentaje alto de volumen no útil.
Capa 2 — Filtrado por relevancia léxica. Presencia de términos clave, entidades o patrones de expresión regular. No es semántica, pero es suficiente para reducir drásticamente el conjunto que pasa a la capa siguiente.
Capa 3 — Análisis semántico y enriquecimiento. Solo aquí interviene el modelo. En este punto, el corpus ya es manejable y la señal tiene densidad suficiente para que el procesamiento aporte valor real.
Este diseño en cascada no es nuevo, pero muy pocos pipelines lo implementan con rigor desde el inicio. La presión por "ver resultados rápido" lleva a saltarse capas 1 y 2 y pagar el precio más tarde.
Normalización: el paso que nadie documenta y todos sufren
El universo público no viene normalizado. La misma entidad aparece con decenas de variantes textuales. La misma tendencia se expresa con vocabulario radicalmente distinto según la fuente, la región o el momento.
Un pipeline TDM sin normalización produce análisis fragmentados. Las métricas de frecuencia mienten porque cuentan variantes como entidades distintas. Los modelos de clasificación trabajan con representaciones inconsistentes y degradan su rendimiento en producción.
Las decisiones de normalización que deben estar explícitas en el diseño:
- Resolución de entidades: mapear variantes textuales a un identificador canónico antes del análisis. No después.
- Gestión de duplicados y contenido sindicado: identificar y colapsar menciones que comparten origen aunque provengan de fuentes distintas. Contar diez veces la misma señal no es cobertura, es distorsión.
- Estandarización temporal: alinear timestamps a una zona horaria común y resolver ambigüedades de fecha en fuentes con metadatos inconsistentes.
Ninguno de estos pasos es glamuroso. Todos son críticos. Y todos deben documentarse explícitamente en el esquema del pipeline, no tratarse como un detalle de implementación que "ya se verá".
El coste real del TDM sin marco legal claro
Desde la Directiva (UE) 2019/790 y su transposición en el Art. 67 bis LPI, el Text and Data Mining sobre fuentes públicas tiene un marco legal definido para uso de investigación y análisis. Pero muchos equipos técnicos trabajan con esta capa completamente opaca: no saben si el proveedor de datos opera bajo ese marco, ni cómo se documenta.
Esto importa en producción por una razón práctica: si el proveedor no opera bajo un marco TDM documentado, el pipeline hereda una exposición legal que nadie contrató conscientemente.
Las preguntas que el equipo técnico debe hacer al proveedor de API antes de integrar:
- ¿El procesamiento se encuadra explícitamente en TDM (Art. 4 Directiva 2019/790)?
- ¿El proveedor entrega análisis derivado o redistribuye contenidos de terceros?
- ¿Existe documentación de la cadena de origen de las señales?
Plataformas como FeedScale operan bajo este marco: el producto es análisis derivado, no redistribución. Para el equipo que integra, esto elimina una clase de riesgo que no siempre está en el radar técnico pero sí en el legal.
Qué medir para saber si el pipeline TDM funciona de verdad
La métrica de éxito en TDM no es el volumen procesado. Es la proporción de señales que generan una acción o una decisión en el sistema consumidor.
Un pipeline que procesa 500.000 menciones al día y genera 200 insights accionables tiene un ratio del 0,04%. No es necesariamente malo — depende del caso de uso — pero debe medirse y optimizarse de forma explícita.
Las métricas que sí indican salud del pipeline TDM:
- Tasa de rechazo por capa: cuánto volumen se descarta en cada filtro. Si la capa 3 rechaza un porcentaje alto, el problema está en las capas anteriores.
- Tasa de duplicados: porcentaje de señales colapsadas por ser contenido sindicado. Un valor alto indica que el universo de fuentes tiene solapamiento elevado.
- Latencia de señal: tiempo entre la publicación de la señal en la fuente y su disponibilidad enriquecida en el sistema consumidor. Crítico para casos de uso en tiempo casi-real.
- Cobertura temática: ¿el pipeline está capturando el espectro completo de señales relevantes o tiene puntos ciegos sistemáticos por diseño del filtrado?
Revisar estas métricas de forma periódica — no solo cuando hay un incidente — es lo que separa un pipeline TDM que escala con control de uno que escala con deuda técnica acumulada.
El Text and Data Mining no es una tecnología. Es una disciplina de diseño. Los equipos que lo tratan como una decisión de infraestructura tardan meses en darse cuenta de que el problema estaba en el criterio, no en la capacidad de cómputo. Diseñar las capas, documentar la normalización y medir lo que importa es lo que convierte el volumen bruto del universo público en inteligencia que alguien puede usar.