AutomatisierungIntegrationen
Tech Radar: Signale aus dem Feed einer Entwickler-Community filtern
- Worum es ging
- Mein eigener Service: Er sammelt Nachrichten aus einer Fach-Community, filtert das Rauschen mit erklärbaren Regeln und stellt einen Digest zusammen. Läuft auf meinem Server.
- Meine Rolle
- Konzeption, Architektur, Entwicklung, Betrieb – allein
- Zeitraum
- 2026, laufend
- Ergebnis
- 7.627 Nachrichten von 581 Autoren archiviert; der Service läuft unbeaufsichtigt.
Kontext und Ausgangsproblem
Eine Entwickler-Community, die über neue Bibliotheken, Tools und API-Preise diskutiert. Der Nutzen ist real, verteilt sich aber auf Hunderte Nachrichten pro Tag, und alles von Hand zu lesen ist keine Option.
Geschäftliche Aufgabe
Nichts Nützliches verpassen, ohne alles zu lesen. Statt eines Feeds eine kurze tägliche Zusammenfassung erhalten – und erklären können, warum eine Nachricht ausgewählt wurde.
Einschränkungen und Unbekannte
- Ein Server, 2 CPU / 4 GB, keine GPU
- Die Nachrichten stammen von anderen: Das Archiv bleibt privat, nach außen gehen nur Links und Ausschnitte
- Es muss unbeaufsichtigt laufen – ich bin mit anderer Arbeit beschäftigt
- Keine kostenpflichtige API
Meine Verantwortung
Alles: Erfassung über Telethon, Datenbankschema, Auswahlregeln, Digest, die systemd-Unit, Tests und Betrieb.
Schlüsselentscheidungen und Kompromisse
- Das Rohdatenarchiv ist unantastbar: Die Verarbeitung löscht nie etwas aus items, und jede abgeleitete Bewertung liegt separat in item_analysis. Regeln lassen sich umschreiben und erneut über die gesamte Historie laufen lassen.
- Zuerst deterministische Regeln, erst danach ein LLM. Regeln sind günstig, reproduzierbar und erklären sich selbst über eine Liste von Gründen; ein Modell auf zwei Kernen ohne GPU ist langsam und kann das nicht.
- Das LLM sitzt hinter einer ItemAnalyzer-Schnittstelle statt im Verarbeitungscode. Ein lokales Modell hinzuzufügen bedeutet eine weitere Implementierung desselben Protokolls, keinen Umbau.
- Inkrementelle Erfassung per Cursor: Ein Neustart liest die Historie nicht erneut ein.
- Observability ab dem ersten Tag – jeder Lauf des Collectors wird mit seinem Status protokolliert, auch ein abnormaler Abbruch.
Was sich geändert hat
- 7.627 Nachrichten von 581 Autoren, gesammelt zwischen März und August 2026
- Deduplizierung anhand von normalisiertem Text und kanonisierten Links, Tracking-Parameter werden entfernt
- Der Digest liefert einen Score, eine Kategorie und die Liste der Gründe, warum eine Nachricht ausgewählt wurde
- Der Service läuft unter systemd und übersteht einen Server-Neustart ohne manuellen Eingriff
- 1.148 Zeilen eigenen Codes, vier externe Abhängigkeiten, drei Test-Suites
Grenzen der Offenlegung und der Ergebnisse
Nächster Schritt bei einer ähnlichen Aufgabe
Eine ähnliche Aufgabe: Signale aus einem Strom von Nachrichten, E-Mails oder eingehenden Anfragen herausfiltern. Wir würden damit beginnen festzulegen, was als Signal zählt.