Text and Data Mining: cómo ajustar la granularidad semántica sin romper el pipeline
Text and Data Mining: cómo ajustar la granularidad semántica sin romper el pipeline
Hay un momento preciso en el que un pipeline de Text and Data Mining deja de ser útil. No es cuando falla la conexión a la API. No es cuando la fuente cambia el formato. Es cuando el nivel de granularidad semántica que elegiste al diseñar el sistema ya no corresponde a las preguntas que el negocio necesita responder.
Ese desajuste es silencioso. El pipeline sigue corriendo. Los datos llegan. Las cifras se actualizan. Pero las inferencias que produce el sistema son demasiado gruesas —o demasiado finas— para lo que se les exige. El coste de ese error no aparece en los logs.
Este post trata de cómo tomar esa decisión de diseño correctamente desde el principio, y cómo ajustarla sin destruir lo que ya funciona.
Qué significa granularidad semántica en la práctica
Granularidad semántica no es un concepto de NLP teórico. Es una decisión de ingeniería con consecuencias directas sobre el volumen de procesamiento, la latencia y la precisión del análisis.
En términos operativos, significa: ¿en qué unidad semántica vas a trabajar?
- Documento completo: útil para clasificación temática amplia, detección de idioma, agrupamiento por áreas de cobertura.
- Párrafo: apropiado cuando un mismo documento mezcla señales contradictorias —algo habitual en análisis de menciones en fuentes largas.
- Oración: necesario para sentiment analysis con atribución de entidad, donde la polaridad varía frase a frase.
- Entidad-contexto: el nivel más costoso, pero el único que permite responder preguntas como "¿qué se dice de esta marca en relación a esta otra, en este segmento de fuentes?".
El error más común no es elegir mal el nivel. Es no elegirlo conscientemente y dejar que la librería por defecto decida por ti.
El problema de trabajar demasiado fino
Bajar la granularidad al nivel de oración o entidad multiplica el número de unidades a procesar. Un documento de 800 palabras puede generar entre 30 y 60 oraciones, cada una de las cuales necesita tokenización, lematización, resolución de entidades y asignación de polaridad.
A escala —pongamos 500.000 documentos al día, un volumen habitual en pipelines de monitorización de fuentes públicas— estás hablando de entre 15 y 30 millones de unidades de análisis diarias. Sin batching inteligente y sin priorización, ese volumen destruye la latencia del sistema y dispara el coste computacional.
Además, granularidad fina sin un esquema de agregación bien definido produce ruido analítico. Detectar que una oración tiene polaridad negativa no dice nada por sí solo. Lo que importa es si esa polaridad está asociada a una entidad relevante, en qué proporción aparece en el corpus y cómo evoluciona en el tiempo.
El resultado práctico: un sistema sobredimensionado en granularidad produce más datos pero menos información.
El problema de trabajar demasiado grueso
El extremo contrario tiene su propio coste. Trabajar a nivel de documento completo colapsa señales que van en direcciones opuestas.
Un análisis de cobertura sobre una marca tecnológica puede encontrar documentos que mencionan positivamente el lanzamiento de un producto y negativamente su política de privacidad, en el mismo texto. Clasificar ese documento como "positivo" o "neutro" oculta exactamente la señal que el equipo de comunicación necesita.
Este problema es especialmente agudo cuando las fuentes son heterogéneas en longitud: un post corto de blog y un reportaje largo no tienen el mismo peso semántico por documento. Tratarlos como unidades equivalentes distorsiona cualquier métrica de frecuencia o tendencia.
Cómo diseñar la granularidad como parámetro, no como constante
La solución no es elegir el nivel correcto una vez y fijarlo para siempre. Es construir el pipeline de forma que la granularidad sea un parámetro configurable, aislado de la lógica de extracción y almacenamiento.
Esto implica tres decisiones de arquitectura:
1. Separar el almacenamiento del procesamiento semántico. Guarda el texto en bruto y los metadatos estructurados por separado de las unidades semánticas procesadas. Cuando necesites cambiar la granularidad, reprocesan las unidades sin tocar la capa de ingesta.
2. Diseñar esquemas de agregación en el momento del análisis, no en la ingesta. La granularidad fina solo es útil si tienes el esquema de agregación listo antes de procesar. Define primero qué quieres medir a nivel macro —tendencia, frecuencia, polaridad por entidad— y luego decide qué nivel de detalle necesitas para calcularlo.
3. Usar índices semánticos intermedios. En lugar de procesar siempre desde el texto en bruto, construye representaciones intermedias —vectores, embeddings, grafos de entidades— que se puedan reutilizar con diferentes niveles de granularidad sin represar el corpus completo.
Cuándo revisar el nivel de granularidad que ya tienes
Hay señales claras de que el nivel actual no está funcionando:
- Los analistas reportan "demasiado ruido": generalmente indica granularidad demasiado fina sin agregación adecuada.
- Las métricas de sentimiento son siempre moderadas: señal de que la granularidad por documento está colapsando señales contradictorias.
- Los tiempos de procesamiento escalan de forma no lineal con el volumen: indica falta de batching y priorización en el nivel semántico.
- El sistema no detecta cambios de tendencia hasta días después: la granularidad temporal es demasiado gruesa; el pipeline no está diseñado para señales de alta frecuencia.
En plataformas como FeedScale, donde el modelo de uso es pay-as-you-go sobre fuentes del universo público de Internet, la decisión de granularidad tiene también un impacto directo en el coste: procesar más unidades de las necesarias no es solo ineficiente, es un gasto real por cada llamada.
Lo que la granularidad no resuelve sola
Ajustar la granularidad semántica es necesario pero no suficiente. El sistema sigue dependiendo de la calidad del texto de entrada —ruido, idioma mezclado, errores OCR en fuentes digitalizadas— y de la coherencia del esquema de entidades que usas para la agregación.
Un pipeline de Text and Data Mining robusto trata la granularidad como una variable de diseño explícita, revisable y documentada. No como una decisión técnica enterrada en la configuración de una librería que nadie recuerda haber tomado.
La siguiente vez que un equipo de negocio diga que el análisis "no refleja la realidad", antes de mirar los modelos, revisa el nivel en el que estás trabajando. Probablemente la respuesta esté ahí.