/ Proyectos / Negocios / Análisis de sentimiento en tiempo real
Análisis de sentimiento en redes sociales en tiempo real con una arquitectura 100% serverless en AWS
Monitorear cómo se percibe un tema en la conversación pública, casi en vivo, sin pagar por un servidor que espera datos que aún no llegan.
El objetivo era simple de enunciar y menos simple de sostener: saber en tiempo casi real qué se está diciendo sobre un tema en redes sociales, de dónde viene esa conversación y si el tono es positivo, negativo o neutro. No como un reporte que se corre una vez a la semana, sino como un tablero vivo que se actualiza mientras la gente sigue publicando.
El reto de ingeniería no estaba en el modelo de sentimiento en sí, sino en el pipeline completo alrededor de él: mantener una conexión de streaming abierta, transformar cada publicación en algo aprovechable, y decidir qué parte de ese trabajo vale la pena correr en un servidor fijo y qué parte conviene delegar a un servicio que solo cobra por ejecución. Ese último punto terminó siendo la decisión de arquitectura más importante de todo el proyecto.
Mapa del casoContenido
- Diagrama de la solución. El recorrido completo, del stream de datos al tablero
- Construcción de la solución. Por qué cada pieza de la arquitectura quedó donde quedó
- Condiciones del proyecto. Restricciones reales y opciones descartadas antes de construir
- Pasos. Qué se dejó al agente y qué criterio se aplicó en cada uno
- Proceso de iteración. Una limitación real, documentada sin maquillaje
- Descargables. Notebook, diagrama y repositorio del proyecto
- Lecciones importantes. La lección concreta que deja este caso
Estructura de alto nivelDiagrama de la solución
Pasa el cursor sobre cada bloque para ver qué hace ese paso.
Solo el listener de streaming vive en un servidor que corre sin parar. Todo lo que ocurre después de que el dato ya está en reposo en S3 se ejecuta por evento, en Lambda, sin pagar por tiempo de espera.
De la decisión a la ejecuciónConstrucción de la solución
Condiciones del proyecto
| Restricción | Dato |
|---|---|
| Objetivo inicial | Prueba de concepto, sin exigencia de manejar un volumen de producción a gran escala |
| Prioridad del proyecto | Minimizar la inversión en infraestructura, con margen de tiempo para explorar y ajustar |
| Naturaleza del dato de entrada | Stream continuo, no un batch que se pueda procesar en horarios fijos |
| Idioma del clasificador de sentimiento | Más confiable en inglés que evaluando directamente el texto original |
| Opción | Por qué se descartó |
|---|---|
| Correr todo el pipeline dentro de la misma instancia EC2 | Más simple, pero desaprovecha la capa gratuita más grande que ofrece Lambda para el procesamiento posterior al streaming |
| Clasificar el sentimiento directamente en español | El clasificador de polaridad usado es menos confiable fuera del inglés |
| EC2 solo para el listener persistente + Lambda disparada por evento de S3 para todo el análisis | Aprovecha la capa gratuita de Lambda donde el trabajo sí puede dispararse por evento, y deja en EC2 solo lo que por diseño no puede vivir en una función de ejecución corta |
Pasos
Elegir dónde vive el procesamiento: EC2 vs. Lambda
Agente: propuso mantener todo el flujo, desde la escucha hasta el envío al tablero, dentro de la misma instancia EC2.
Criterio aplicado: separar el listener persistente, que por naturaleza no puede vivir en una función de ejecución corta, del resto del procesamiento, que sí es disparable por evento. Ese segundo bloque se movió a Lambda para aprovechar su capa gratuita más generosa, a costa de un poco más de configuración inicial.
Empaquetar las dependencias de la Lambda
Agente: sugirió instalar las librerías directamente en el entorno de despliegue de la función.
Criterio aplicado: construir una capa de Lambda independiente con las dependencias, generada desde una instancia EC2 de Cloud9, para que la función se mantenga liviana y la capa sea reutilizable en futuras versiones del proyecto.
Traducción antes de clasificar el sentimiento
Agente: propuso clasificar el sentimiento directamente sobre el texto original.
Criterio aplicado: traducir primero el texto al inglés, porque el analizador de polaridad usado es notablemente más confiable en ese idioma, y solo entonces calcular la polaridad y la palabra más representativa.
Formato de intercambio entre el listener y la Lambda
Agente: generó un primer borrador que serializaba cada registro como JSON estructurado desde el listener.
Criterio aplicado: concatenar el texto, la ubicación y las coordenadas con delimitadores de texto simples, para evitar el costo de escapar comillas y caracteres especiales en esa etapa temprana del pipeline. Esta decisión se documenta honestamente como una limitación real en la sección de iteración.
Proceso de iteración
Ajuste documentado, no forzado
El formato de delimitadores de texto entre el listener y la Lambda, en vez de JSON estructurado, funcionó bien en la mayoría de los casos, pero es frágil por diseño: si el texto de una publicación llegara a contener alguna de las palabras usadas como separador, o si la ubicación del usuario viniera vacía, el registro no se parte en las tres partes esperadas y la Lambda lo descarta en silencio. Para esta prueba de concepto el volumen de registros afectados fue marginal, pero es una limitación real que cualquier versión productiva de este pipeline tendría que resolver con un formato más robusto.
CierreLecciones importantes
La decisión de arquitectura con más impacto fue la más aburrida: qué pieza corre en un servidor fijo y cuál se mueve a una función serverless. No hay una respuesta universal. Si el proyecto es una prueba de concepto donde el tiempo de configuración sobra y el presupuesto no, vale la pena optimizar el código para aprovechar la capa gratuita de Lambda en todo lo que sea disparable por evento, aunque eso suba un poco la complejidad de despliegue. Si en cambio se busca simplicidad operativa y se tiene presupuesto para mantenimiento, correr todo en EC2, o incluso en una opción económica como Lightsail, puede ser la decisión correcta. Ninguna de las dos es la arquitectura "correcta" en abstracto.
Si quieres ver un enfoque publicado que usa redes sociales como sensor social en tiempo real con datos geolocalizados, esta referencia es un buen punto de comparación del tipo de problema: Earthquake shakes Twitter users: real-time event detection by social sensors.
Termina ya tu proyecto
¿Tienes un proyecto similar y no sabes por dónde empezar? Yo te ayudo a diseñarlo.
El 92% de los profesionales de datos desbloquea sus proyectos al ver ejemplos completos resueltos.
Sin registro. Acceso inmediato