Tech Radar: extraer la señal del flujo de una comunidad de desarrolladores
- De qué se trataba
- Mi propio servicio: recopila mensajes de una comunidad profesional, filtra el ruido con reglas explicables y compone un resumen. Funciona en mi servidor.
- Mi rol
- Planteamiento, arquitectura, desarrollo y operación, en solitario
- Periodo
- 2026, en curso
- Resultado
- 7627 mensajes de 581 autores archivados; el servicio funciona sin supervisión.
Contexto y problema inicial
Una comunidad de desarrolladores que habla de nuevas bibliotecas, herramientas y precios de API. El valor es real, pero está repartido en cientos de mensajes al día, y leerlo todo a mano no es una opción.
Tarea de negocio
No perderse nada útil sin leerlo todo. Recibir un breve resumen diario en lugar de un flujo de mensajes, y poder explicar por qué un mensaje pasó el filtro.
Restricciones e incógnitas
- Un servidor, 2 CPU / 4 GB, sin GPU
- Los mensajes son de otras personas: el archivo sigue siendo privado y solo se muestran enlaces y fragmentos
- Tiene que funcionar sin supervisión: estoy ocupado con otros trabajos
- Sin API de pago
Mi responsabilidad
Todo: la recopilación con Telethon, el esquema de la base de datos, las reglas de selección, el resumen, la unidad de systemd, las pruebas y la operación.
Decisiones clave y concesiones
- El archivo en bruto es intocable: el procesamiento nunca borra nada de items, y cada veredicto derivado se guarda aparte en item_analysis. Las reglas se pueden reescribir y volver a aplicar a todo el historial.
- Primero, reglas deterministas; un LLM, solo después. Las reglas son baratas, reproducibles y se explican solas con una lista de motivos; un modelo en dos núcleos sin GPU es lento y no puede hacerlo.
- El LLM está detrás de una interfaz ItemAnalyzer, no dentro del código de procesamiento. Añadir un modelo local supone otra implementación del mismo protocolo, no una reescritura.
- Recopilación incremental por cursor: un reinicio no vuelve a leer el historial.
- Observabilidad desde el primer día: cada ejecución del recolector se registra con su estado, incluida una terminación anómala.
Qué cambió
- 7627 mensajes de 581 autores recopilados entre marzo y agosto de 2026
- Deduplicación por texto normalizado y por enlaces canonicalizados, eliminando los parámetros de seguimiento
- El resumen indica una puntuación, una categoría y la lista de motivos por los que se seleccionó el mensaje
- El servicio funciona bajo systemd y sobrevive a un reinicio del servidor sin ningún paso manual
- 1148 líneas de código propio, cuatro dependencias externas, tres conjuntos de pruebas
Límites de divulgación y de resultados
Siguiente paso para una tarea similar
Una tarea similar: extraer la señal de un flujo de mensajes, correos o solicitudes entrantes. Empezaríamos por definir qué cuenta como señal.