Sentiment Analysis API: por qué analizar a nivel de entidad cambia el resultado del pipeline
Sentiment Analysis API: por qué analizar a nivel de entidad cambia el resultado del pipeline
Un texto puede mencionar tres marcas competidoras en el mismo párrafo. La primera recibe críticas directas. La segunda aparece como referencia neutral. La tercera se lleva el elogio implícito de la comparación. Si invocas la API con el documento completo, el modelo devuelve un único score: probablemente neutro. Has perdido tres señales distintas en una sola llamada.
Este es el problema central de los pipelines de sentiment que operan a nivel de documento. No es un fallo del modelo. Es un fallo de diseño previo a la llamada a la API.
El scope de entrada decide el scope de la respuesta
La mayoría de las APIs de análisis de sentimiento aceptan texto libre y devuelven un score por fragmento enviado. La granularidad del resultado depende directamente de cómo fragmentes el texto antes de enviarlo.
Tres estrategias habituales, con sus consecuencias reales:
Documento completo. Máxima velocidad, mínima precisión. Útil solo cuando el texto trata un único sujeto y no contiene referencias cruzadas. Fuera de ese caso, el score agrega señales contradictorias y pierde información diferencial.
Párrafo o frase. Mejor resolución. Permite detectar cambios de tono dentro de un mismo documento. El coste sube (más llamadas), pero la señal mejora de forma no lineal. Un análisis de cobertura mediática sobre un sector industrial gana mucho con este enfoque: el primer párrafo puede ser positivo sobre la industria y el tercero crítico con un actor concreto.
Fragmento centrado en entidad. El enfoque más preciso técnicamente. Implica un paso previo de Named Entity Recognition (NER) para identificar qué entidades aparecen en el texto, extraer el contexto inmediato de cada mención (ventana de ±N palabras, o la frase completa que las contiene) y enviar ese fragmento a la API de sentimiento. El resultado queda vinculado a una entidad específica, no al documento.
Cómo afecta esto al diseño del pipeline
El pipeline clásico tiene forma lineal: ingesta → análisis → almacenamiento. El problema es que la etapa de análisis se trata como una caja negra que procesa en bloque.
Un pipeline con granularidad de entidad añade una etapa intermedia que transforma el dato antes de enviarlo a la API:
ingesta
→ normalización de texto
→ NER (extracción de entidades)
→ generación de fragmentos por entidad
→ llamada a sentiment API por fragmento
→ almacenamiento con clave (doc_id, entidad, score, contexto)
Esto tiene tres implicaciones directas en la arquitectura:
Volumen de llamadas multiplica por N entidades. Si un documento menciona una media de cuatro entidades relevantes, el coste en llamadas API se cuadruplica respecto al análisis por documento. Hay que modelarlo antes de escalar.
El esquema de almacenamiento cambia. Ya no es una fila por documento. Es una fila por par (documento, entidad). El modelo relacional o el índice de búsqueda tienen que aceptar esa cardinalidad desde el inicio del diseño.
La etapa NER se convierte en dependencia crítica. Si el modelo de NER falla o clasifica mal una entidad, el error se propaga a todos los scores vinculados a esa entidad. Necesita su propio ciclo de validación.
Qué validar antes de asumir que el modelo entiende tu dominio
No todos los modelos de sentimiento funcionan igual sobre todos los dominios. Un modelo entrenado sobre reseñas de consumo puede interpretar el término "agresivo" en un contexto financiero como negativo, cuando en ese contexto describe una estrategia de crecimiento percibida positivamente por el mercado.
Antes de integrar la API en producción, vale la pena ejecutar este proceso de validación mínima:
- Selecciona 50-100 fragmentos representativos de tu dominio real.
- Etiquétalos manualmente (positivo / negativo / neutro) con criterio editorial propio.
- Compara con la salida de la API.
- Mide precisión por categoría, no solo accuracy global. Los errores en la categoría negativa suelen ser los más costosos operativamente.
Si la precisión cae por debajo del umbral que tolera tu caso de uso, considera dos opciones: ajustar el prompt si la API es un modelo de lenguaje instruible, o añadir una capa de post-procesamiento que reescale o corrija el score para términos con comportamiento atípico en tu dominio.
El caso del texto ambiguo: cuándo el score no es suficiente
Algunos fragmentos no tienen sentimiento neto. El modelo devuelve un score cercano a 0.5 o un vector de probabilidades con distribución plana. Tratar ese resultado como "neutro" es una decisión, no una evidencia.
En pipelines de media intelligence, los textos ambiguos suelen concentrarse en dos situaciones: menciones en contexto informativo factual (sin carga valorativa) y menciones en contexto de ironía o sarcasmo (donde el sentimiento superficial invierte el real).
La práctica más robusta no es forzar una etiqueta sobre esos casos. Es crear una categoría operativa propia —"señal débil" o "indeterminado"— y tratarlos en un flujo separado que puede implicar revisión manual o descarte para el análisis cuantitativo.
Forzar una etiqueta sobre texto ambiguo introduce sesgo sistemático en los agregados. Si el 20% del corpus es ambiguo y lo clasificas todo como neutro, el ratio positivo/negativo final está sesgado sin que el dashboard lo refleje.
Cómo gestionar la evolución del modelo en producción
Las APIs de sentimiento no son estáticas. Los proveedores actualizan los modelos subyacentes, a veces sin comunicarlo con antelación suficiente. Un cambio de modelo puede desplazar el score medio de un corpus estable varios puntos porcentuales, rompiendo comparativas históricas.
Dos medidas de mitigación que tienen sentido a escala B2B:
Fija una versión de API si el proveedor lo permite. Muchos endpoints aceptan un parámetro de versión. Úsalo. La migración a una nueva versión debe ser un proceso controlado, con comparación A/B sobre el mismo corpus antes de promoverla a producción.
Mantén un corpus de referencia con scores históricos. Un conjunto pequeño de fragmentos etiquetados manualmente que usas como test de regresión cada vez que el modelo cambia. Si los scores se desvían más de un umbral definido, el pipeline lanza una alerta antes de que el cambio contamine el análisis en curso.
En plataformas como FeedScale, donde el análisis opera sobre señales del universo público de Internet en tiempo cuasi-real, esta estabilidad del contrato de salida es tan importante como la latencia de ingesta.
El sentimiento a nivel de documento es una heurística rápida. Puede ser útil para dashboards ejecutivos donde la resolución no importa. Pero si tu pipeline toma decisiones —o alimenta modelos que las toman— sobre entidades concretas, la granularidad de entidad no es una mejora opcional. Es la única forma de que el dato que almacenas corresponda a lo que realmente ocurre en el texto.