Text and Data Mining con APIs: lo que separa un prototipo de un sistema en producción
Text and Data Mining con APIs: lo que separa un prototipo de un sistema en producción
Hay una distancia enorme entre un notebook de Jupyter que parsea titulares y un sistema de Text and Data Mining que opera en producción, con volumen real, bajo un marco legal claro y sin que el equipo de datos tenga que apagar fuegos cada semana. Esa distancia no suele estar en el modelo. Está en todo lo que rodea al modelo.
La mayoría de los equipos técnicos que abordan TDM por primera vez subestiman tres cosas: el coste real de normalizar fuentes heterogéneas, la fricción que introduce la incertidumbre legal sobre los datos que procesan, y la diferencia entre señal y ruido cuando el volumen escala. Este post trata de esas tres cosas con concreción.
TDM no empieza con el modelo: empieza con la fuente
El error más común en proyectos de Text and Data Mining es asumir que el problema técnico principal es el NLP. No lo es. El problema es que las fuentes del universo público de Internet son ruidosas, inconsistentes y cambian sin avisar.
Un artículo de medios de comunicación procesado desde su fuente original puede llegar con metadatos incompletos, texto partido por elementos de navegación, fechas en formatos distintos según el país de origen, o duplicados casi exactos publicados en varios dominios. Antes de pasar una sola cadena de texto por un modelo de clasificación o extracción de entidades, necesitas resolver todo eso. Y resolverlo de forma reproducible, no manual.
Lo que un equipo técnico maduro hace en esta fase:
- Estandarización de esquemas: todo dato que entra al pipeline tiene que tener los mismos campos mínimos garantizados (fecha, fuente, idioma, texto limpio). Si no puedes garantizarlo upstream, tienes que hacerlo tú — y eso tiene coste.
- Deduplicación semántica, no solo exacta: dos piezas sobre el mismo evento publicadas con horas de diferencia no son duplicados exactos, pero procesan la misma señal. Si no tienes esto resuelto, tus métricas de volumen mienten.
- Detección de idioma y segmentación por mercado: un modelo entrenado para español de España no se comporta igual con texto en español de México o Colombia. TDM a escala global necesita esta capa antes del análisis.
El marco legal no es un problema jurídico: es un problema de arquitectura
El Art. 4 de la Directiva (UE) 2019/790 sobre Text and Data Mining establece que el procesamiento de fuentes públicas con fines de análisis es lícito cuando se realiza desde acceso legítimo. El Art. 67 bis de la LPI española transpone esa regulación al derecho nacional. Esto no es un detalle que gestiona el departamento legal y luego se olvida: afecta directamente a cómo diseñas tu pipeline.
¿Por qué? Porque la diferencia entre redistribuir contenido y producir análisis derivado no está solo en la intención, sino en la arquitectura técnica. Si tu sistema almacena texto completo de terceros y lo sirve directamente, estás redistribuyendo. Si tu sistema procesa ese texto para generar señales, métricas, clasificaciones o insights, y son esos derivados los que almacenas y expones, estás haciendo TDM.
Esto tiene implicaciones concretas:
- No almacenes texto completo si no es necesario. Almacena los derivados que te importan: categorías, entidades, sentimiento, relevancia, metadatos.
- Documenta el origen del dato y el propósito del procesamiento. No como burocracia, sino porque lo necesitarás cuando alguien lo pregunte.
- Usa APIs que operen bajo este marco desde el origen. Un proveedor que procesa fuentes públicas bajo TDM te traslada parte de esa cobertura legal. Uno que no tiene claridad sobre su propio modelo de licencia te genera exposición.
Señal útil vs. volumen bruto: la trampa del big data en TDM
Más fuentes no siempre significa más señal. Este es uno de los aprendizajes más duros en proyectos de media intelligence con TDM a escala. Cuando procesas decenas de miles de menciones diarias sobre un tema, el volumen bruto crece, pero la señal útil — la que realmente informa una decisión — puede mantenerse constante o incluso degradarse si no tienes filtros bien diseñados.
Los equipos que llevan tiempo operando pipelines de TDM en producción suelen tener resueltas estas capas de filtrado:
1. Relevancia temática real, no coincidencia de keywords. Un sistema que filtra por palabras clave va a traer ruido masivo. Un sistema que clasifica por contexto semántico trae señal. La diferencia en el ratio señal/ruido puede ser de 10x.
2. Peso por autoridad de fuente, no por volumen. Una mención en un medio de referencia tiene un peso informativo distinto que cien menciones en blogs sin audiencia. Si tu sistema no pondera esto, estás procesando ruido como si fuera señal.
3. Detección de patrones temporales, no solo instantáneas. Lo que importa en TDM no es solo "cuánto se habla de X ahora", sino "cómo ha evolucionado ese volumen y con qué velocidad". Los picos sin contexto histórico son casi inútiles para tomar decisiones.
Pay-as-you-go y TDM: el modelo que sí encaja con el ciclo real de un proyecto
Los proyectos de Text and Data Mining no tienen consumo lineal. Hay fases de exploración donde el volumen de llamadas es bajo y experimental. Hay fases de validación donde el volumen escala de golpe. Y hay fases de producción donde el consumo se estabiliza pero debe ser predecible en coste.
Un modelo de licencia con seats fijos o con compromisos anuales de volumen penaliza las fases de exploración y no se adapta a la realidad de cómo los equipos técnicos construyen estos sistemas. El modelo pay-as-you-go — donde pagas exactamente por el procesamiento que consumes — es el que encaja con el ciclo real de desarrollo de un proyecto TDM.
Plataformas como FeedScale están diseñadas con esta lógica: acceso programático a análisis derivado de fuentes públicas, sin compromisos de volumen mínimo, con APIs REST que permiten integrar el procesamiento en el pipeline propio del equipo sin depender de dashboards de terceros.
Lo que diferencia un sistema TDM maduro
Un sistema de Text and Data Mining en producción no es el que tiene el modelo más sofisticado. Es el que tiene resueltas las capas previas: normalización de fuentes, cobertura legal del procesamiento, filtrado de señal real sobre volumen bruto, y un modelo de coste que no penaliza la exploración.
Los equipos que llegan a producción sin fricciones son los que entienden TDM como una disciplina de ingeniería de datos, no como un proyecto de ciencia de datos. El modelo es el último paso. Todo lo demás viene antes.
Si estás en la fase de evaluar si tu arquitectura actual puede sostener un pipeline TDM real, la pregunta útil no es "qué modelo uso" — es "de dónde viene el dato, quién lo ha procesado, bajo qué marco, y cómo me llega".