Sentiment Analysis API: los errores que solo aparecen cuando el sistema ya está en producción

Sentiment Analysis API: los errores que solo aparecen cuando el sistema ya está en producción

El modelo funciona en el sandbox. La precisión en el conjunto de evaluación es razonable. El pipeline consume la API sin errores 500. Y entonces llegas a producción y el sistema empieza a clasificar como "positivo" un artículo sobre una crisis reputacional porque la entradilla menciona que la marca "lidera el mercado".

Ese es el problema central de integrar una sentiment analysis API en un sistema de análisis real: los fallos técnicos son los más fáciles de resolver. Los fallos semánticos son los que destruyen la utilidad del sistema.

Este post no va sobre cómo llamar a un endpoint de sentiment. Va sobre qué rompe el análisis cuando ya está corriendo, y cómo diseñar la integración para que eso no ocurra.

El dato que entra decide el resultado antes de que el modelo lo vea

Una sentiment analysis API no analiza contexto editorial. Analiza texto. Y el texto que le envíes determina el 60-70% del resultado antes de que el modelo ejecute ninguna inferencia.

El error más común: enviar el cuerpo completo de un documento cuando el dato relevante es solo un fragmento. Un artículo de 800 palabras sobre los despidos de una empresa puede incluir citas de portavoces, declaraciones de sindicatos, contexto histórico positivo y proyecciones futuras optimistas. Si la API recibe el documento entero, el resultado será ambiguo o directamente incorrecto respecto a la señal que te interesa.

La solución no es cambiar el modelo. Es cambiar qué le envías al modelo.

Antes de llamar a la API, define la unidad semántica de análisis. Puede ser el titular más el primer párrafo. Puede ser solo los párrafos donde aparece la entidad objetivo. Puede ser cada oración de forma independiente para después agregar por reglas propias. Esa decisión es arquitectónica, no técnica, y debe tomarse antes de la integración, no después.

# Ejemplo: extraer fragmentos relevantes por entidad antes de llamar a la API
def extract_entity_context(text, entity, window=2):
    sentences = text.split('. ')
    relevant = [
        s for s in sentences
        if entity.lower() in s.lower()
    ]
    return '. '.join(relevant[:window])

fragment = extract_entity_context(article_body, entity="Nombre de la marca")
sentiment_result = sentiment_api.analyze(text=fragment, lang="es")

Esto no es un truco. Es el paso que separa un sistema de análisis de un sistema de ruido etiquetado.

El problema del idioma mixto y las fuentes heterogéneas

Si tu pipeline consume señales del universo público de Internet —foros, medios especializados, redes sociales, agregadores— el texto que llega no es homogéneo. Hay mezcla de idiomas dentro de un mismo documento. Hay siglas en inglés en contextos en castellano. Hay tecnicismos de sector que los modelos generalistas no han visto en entrenamiento.

El impacto en sentiment es directo: los modelos multilingües generales degradan notablemente en dominios especializados o en textos mixtos. Un titular en castellano con terminología financiera en inglés puede ser clasificado con el idioma equivocado internamente, y el resultado no tiene valor.

Dos prácticas que mitigan esto en producción:

1. Detección de idioma antes del enrutamiento. No delegues en la API la detección del idioma si el volumen es alto. Detecta tú antes con una librería liviana (langdetect, fasttext-langid) y enruta a un endpoint o modelo especializado por idioma. Reduce coste y mejora precisión.

2. Normalización de entidades antes del análisis. Si la entidad que monitorizas tiene formas canónicas distintas según la fuente, normaliza antes de pasar el texto. El modelo no sabe que "BBVA", "Banco Bilbao" y "bbva.com" son la misma entidad. Tú sí lo sabes. Esa información debe entrar preprocesada.

Granularidad del score: qué puedes agregar y qué no

La mayoría de APIs de sentiment devuelven un score numérico continuo (0-1) o una etiqueta categórica (positivo/negativo/neutro). El error de integración aquí es agregar esos scores como si fueran magnitudes físicas.

Promediar scores de sentiment entre 500 documentos de fuentes distintas, con pesos iguales, no produce una métrica útil. Produce una cifra que parece precisa y no lo es.

Lo que sí funciona en sistemas reales:

• Ponderación por autoridad o alcance estimado de la fuente. No todas las señales tienen el mismo peso. Una mención en un medio de referencia no equivale a una mención en un sitio de tráfico marginal.
• Separación por tipo de fuente antes de agregar. Agregar sentiment de medios especializados por separado del sentiment de foros da dos señales distintas con lecturas distintas. Mezclarlas sin ponderar destruye información.
• Ventanas temporales cortas para detectar cambios. El valor operativo del sentiment no está en el número absoluto sino en la variación. Un sistema que solo reporta el score medio diario pierde los picos que son la señal relevante para alertas o inteligencia competitiva.

# Ejemplo simplificado: agregación ponderada por score de autoridad de fuente
def weighted_sentiment(results):
    total_weight = sum(r['source_weight'] for r in results)
    if total_weight == 0:
        return None
    return sum(r['score'] * r['source_weight'] for r in results) / total_weight

Alertas basadas en sentiment: el umbral que nadie calibra

Muchos equipos conectan la API de sentiment a un sistema de alertas sin calibrar el umbral sobre datos reales del dominio. Usan el default del proveedor o un valor arbitrario como 0.3 o 0.7.

El resultado: o demasiadas alertas que nadie lee (ruido), o alertas tan tardías que el evento ya fue notado por otros canales antes.

La calibración del umbral requiere retrospectiva real: tomar un conjunto de eventos pasados conocidos (crisis reputacional, lanzamiento positivo, incidente de producto), ejecutar el análisis sobre las señales de esas fechas y ajustar el umbral a lo que el sistema habría detectado de forma útil. No es una tarea de una hora, pero evita meses de alertas inútiles.

En plataformas como FeedScale, donde el acceso a datos históricos del universo público está disponible vía API, ese ejercicio de calibración retroactiva es viable sin depender de logs propios. Puedes consultar la cobertura de un período pasado y ajustar tu modelo de alertas antes de activarlo en producción.

Lo que el proveedor de la API no puede hacer por ti

Una API de sentiment entrega una clasificación sobre el texto que recibe. No entiende el contexto editorial de tu sector. No sabe que en tu industria "reducción de costes" es una señal negativa aunque gramaticalmente sea neutra. No distingue entre ironía de un columnista y declaración literal de un directivo.

Esa capa de interpretación es tuya. Significa que el valor real de integrar sentiment analysis en un pipeline de media intelligence no está en el endpoint. Está en la combinación de preprocesado inteligente, enrutamiento por fuente e idioma, agregación ponderada y calibración de umbrales sobre datos reales.

El modelo es el componente más visible. Pero en producción, rara vez es el que falla primero.

Si estás diseñando o revisando la integración de sentiment en tu pipeline de análisis de señales públicas, empieza por auditar qué le envías a la API, no por cambiar el modelo que la procesa.

← Volver al blog