Sistema de Noticias Autónomo con IA Sin Control Manual

# # Sistema de Noticias Autónomo con IA: Cómo Reemplazar Siete Flujos de Trabajo con una Arquitectura Unificada

En poco más de un mes y medio, un pipeline de noticias fragmentado con siete flujos de trabajo de n8n se transformó en un sistema estable con 160 fuentes, 11 workers y 5 agentes de IA. Ahora, el procesamiento de 7127 registros en la base de datos ocurre sin intervención manual, y un LLM local en un mini-PC reemplaza las API en la nube. Desglosamos la arquitectura que elimina puntos de fallo y garantiza un funcionamiento 24/7.

De Siete Puntos de Fallo a un Sistema Único

Inicialmente, el pipeline de noticias consistía en siete flujos de trabajo independientes de n8n: recolección de datos, filtrado, traducción, generación de imágenes y publicación. Cada etapa operaba de forma aislada, lo que generaba fallos en cascada. Un problema típico: un flujo marcaba una tarea como "completada", pero la salida estaba vacía. Como las etapas carecían de un sistema de monitoreo unificado, los diagnósticos tomaban horas. La vulnerabilidad crítica era la ausencia de un estado único para cada noticia. Si un flujo se colgaba, los demás seguían procesando, generando datos inconsistentes.

La solución surgió tras un análisis con Perplexity y experimentos con Claude Code. En lugar de reescribir manualmente la lógica en Python, el asistente de IA recibió los flujos fuente y los requisitos arquitectónicos. En una hora, generó una aplicación contenedorizada con una clara separación de responsabilidades. Cambio clave: transición de flujos basados en triggers a un pipeline orientado a estados, donde cada noticia pasa por etapas estrictamente definidas con el estado fijado en la base de datos.

Procesamiento Local: Por Qué Qwen 3.5 en un Mini-PC

Traducir noticias mediante API en la nube resultó económicamente inviable: 160 fuentes actualizándose cada 15 minutos requerirían decenas de miles de solicitudes diarias. La solución: desplegar un LLM local en un mini-PC doméstico con Ubuntu y optimizar para Vulkan mediante llama.cpp. Se eligió el modelo Qwen 3.5 (qwen3.5-9b-q5_k_m.gguf) por su equilibrio entre velocidad y calidad para el idioma ruso.

La configuración incluyó:

• Ajuste fino para arquitectura de CPU mediante Cursor
• Calibración del número de hilos para minimizar la latencia
• Configuración de caché de resultados intermedios

El sistema maneja hasta 50 solicitudes por minuto sin sobrecargar la CPU. Los datos nunca salen de la red local, lo cual es crítico para fuentes con restricciones de claves API. En comparación: la traducción en la nube costaría ~$120/mes con el volumen actual, local — $0 tras la configuración inicial.

Arquitectura del Pipeline: Cómo Funcionan los 11 Workers

Construido sobre el principio "un proceso — una tarea". Cada worker está aislado, eliminando fallos en cascada. Flujo de procesamiento:

collector → scraper → deduplicator → ai_filter → translator
    → llm_editor → image_worker → publisher

collector se ejecuta cada 15 minutos, analiza RSS/API de 160 fuentes (incluyendo arXiv, TechCrunch, GitHub). scraper extrae el texto completo mediante una instancia local de Jina Reader — esto eliminó los límites de servicios en la nube. deduplicator usa comparación semántica basada en embeddings, no coincidencia exacta de texto. ai_filter asigna relevance_score (0-100), filtrando elementos por debajo de 75 puntos.

Atención especial a la etapa llm_editor. Allí, MiniMax M2.7 formatea el texto al estilo del canal: añade emojis a los titulares, estructura el contenido, agrega atribución. El modelo está entrenado con datos históricos del canal, asegurando un formato consistente. Todos los workers interactúan mediante cola de mensajes con garantía de entrega, permitiendo reanudación tras fallos desde el último checkpoint.

Gestión mediante Agentes de IA: De Comandos de Telegram a Acciones

El coordinador basado en OpenClaw reemplaza la gestión manual. Se ejecuta en el mismo mini-PC y tiene acceso a herramientas vía API. El sistema usa 5 agentes especializados:

• AgentLLMEditor: corrige texto cada 20 minutos
• AgentPipelineManager: distribuye publicaciones a slots 4 veces al día
• AgentSourceAuditor: desactiva fuentes no funcionales semanalmente
• AgentAnalyst: genera analíticas a las 21:05
• Coordinator: gestiona a los otros agentes

Un comando de Telegram como "Coordinator, reduce el límite de publicación a 8 por día" se convierte en una llamada API al gestor del pipeline. El agente verifica la configuración actual, realiza cambios y confirma la ejecución. Esto elimina la necesidad de acceso SSH y conocimiento de sintaxis de archivos de configuración. Para operaciones críticas (p. ej., desactivar una fuente), el sistema requiere confirmación mediante worker human-in-the-loop (hitl).

Dashboard: Monitoreo en Tiempo Real

La interfaz combina 9 pestañas: visión general, agentes, fuentes, cola, workers, slots, publicadas, configuración, GitHub Discovery. Métricas clave:

• Tasa de aprobación por fuentes: Anthropic News (100%) vs iXBT.com (14%)
• Tiempo de procesamiento por etapa: traducción (4 min) vs filtrado (2 min)
• Estado de workers: procesos activos/inactivos

Al detectar anomalías (p. ej., cola de traducción atascada), el dashboard crea automáticamente una tarea en el grupo de trabajo de Telegram. La integración con GitHub Discovery rastrea repos con crecimiento brusco de estrellas — estos datos se muestran en una pestaña separada con gráfico de actividad. El sistema advierte de problemas antes de que afecten las publicaciones: p. ej., si la tasa de aprobación de una fuente cae por debajo del 10% durante una semana.

Ahorros mediante Selección: De 1000 Noticias a 8 Publicaciones al Día

El sistema no publica todo. ~1000 elementos procesados por semana, pero solo 56 publicaciones van al aire (8 por día). Criterios de selección:

• relevance_score ≥ 80 (ai_filter)
• Aprobado por editor LLM (estado approved)
• Coincide con slot de horario

Horario ligado a zonas horarias:

• Mañana (08:00–11:00): 2 publicaciones
• Día (12:00–16:00): 2 publicaciones
• Tarde (18:00–22:00): 2 publicaciones
• Noche (00:00–06:00): 2 publicaciones

Anteriormente 28 publicaciones por día, pero las analíticas mostraban que los usuarios leían solo las últimas 1-2. Ahora, reducir el volumen aumentó la retención en un 37% — los lectores ven todas las publicaciones del slot. Las tasas de aprobación por fuente permiten ajustes semanales en la lista: ya se desactivaron 20 feeds RSS de baja eficiencia.

Lo que Importa

• Sistema de estados unificado reemplaza flujos aislados: cada noticia tiene un estado claro, acelerando diagnósticos de fallos 5x.
• LLM locales ahorran hasta $120/mes en traducción y edición, con latencia no superior a 4 minutos para 50 tareas paralelas.
• Agentes de IA eliminan la gestión manual: comandos de Telegram se convierten en llamadas API sin intervención del operador.
• Selección estricta de contenido (8 publicaciones/día en lugar de 28) impulsó la retención de audiencia en un 37% al reducir el ruido.

— Editorial Team