Signal-Scoring-Pipeline: Deterministische Wissens-Triage

Die meisten Wissensmanagement-Ansätze basieren auf Bauchgefühl. Sie speichern eine Notiz, weil sie sich „wichtig anfühlt”. Sechs Monate später haben Sie 7.000 Notizen und keine Ahnung, welche davon relevant sind. Ich habe eine deterministische Scoring-Pipeline gebaut, die mir das sagt.

Das System umfasst 733 Zeilen Python. Es bewertet jedes eingehende Signal über vier gewichtete Dimensionen, berechnet einen zusammengesetzten Score und leitet das Signal an einen von 12 Domänenordnern, einen Eingang zur manuellen Überprüfung oder ins Leere weiter. Kein manuelles Taggen. Kein „später überprüfen”, das nie passiert. Der Algorithmus entscheidet.

TL;DR

Ein gewichteter zusammengesetzter Score (Relevanz 35 %, Umsetzbarkeit 30 %, Tiefe 20 %, Autorität 15 %) erzeugt eine Bewertung von 0,0–1,0 für jedes Signal. Das Routing verwendet drei Schwellenwerte: >= 0,55 schreibt automatisch in einen Domänenordner, >= 0,30 reiht zur manuellen Überprüfung ein, < 0,30 wird stillschweigend übersprungen. Über 7.700 Notizen wurden über 14 Monate verarbeitet, wobei Development (2.837) und Design (1.709) die Verteilung dominieren. Der interessanteste Fehler: Die Tiefendimension misst Metadaten-Reichhaltigkeit, nicht Inhaltsqualität – ein gut getaggter Tweet über ein Blumenfoto erreicht einen Score von 0,85.

Das Problem mit dem Bauchgefühl

Ich nutze Obsidian als Wissensbasis. Signale kommen aus RSS-Feeds, Twitter-Lesezeichen, GitHub-Stars, Newslettern und manueller Erfassung. Vor der Pipeline landete jedes Signal in einem einzigen Eingangsordner. Ein Eingang mit über 400 unverarbeiteten Notizen häufte sich innerhalb von zwei Monaten an.

Standardratschläge („wöchentlich durchsehen, beim Ablegen taggen, ein Ordnersystem verwenden”) setzen voraus, dass die Überprüfung tatsächlich stattfindet. Das tut sie nicht. Eingänge werden zu reinen Schreibspeichern: Elemente gehen hinein, aber kommen nie wieder heraus. Wissen, das Sie erfasst haben, ist funktional identisch mit Wissen, das Sie nie erfasst haben. Clay Shirky formulierte das Problem präzise: „It’s not information overload. It’s filter failure.”⁸

Ich brauchte ein System, das 7.700+ Notizen schneller auswerten kann als ich sie lesen kann, mit Kriterien, die ich einmal definiere und einheitlich anwende. Keine Empfehlungsmaschine. Einen Scoring-Algorithmus.

Der zusammengesetzte Score

Die Scoring-Formel ist eine gewichtete Linearkombination aus vier Dimensionen – ein Standardansatz in der multikriteriellen Entscheidungsanalyse (MCDA):⁹

composite = (
    relevance     * 0.35 +
    actionability * 0.30 +
    depth         * 0.20 +
    authority     * 0.15
)

Jede Dimension erzeugt einen Float zwischen 0,0 und 1,0. Die Formel rundet den zusammengesetzten Score auf drei Dezimalstellen. Die Gewichtungen spiegeln eine bewusste Prioritätenreihenfolge wider: was mir wichtig ist (Relevanz) überwiegt was ich nutzen kann (Umsetzbarkeit), was wiederum wie reichhaltig die Metadaten sind (Tiefe) überwiegt, was wiederum wie vertrauenswürdig die Quelle ist (Autorität) überwiegt.¹

Die vier Dimensionen

Relevanz (35 %): Interessenabgleich

Relevanz nutzt ein manuell kuratiertes Schlüsselwort-Wörterbuch mit über 40 Einträgen, jeweils bewertet von 0,15 (nft) bis 1,0 (claude code, swiftui). Die Bewertung kombiniert den besten Treffer mit dem Durchschnitt aller Treffer:

# 60% best match, 40% average of all matches
return min(1.0, best_score * 0.6 + avg_score * 0.4)

Elemente ohne Treffer erhalten eine Grundlinie von 0,25, nicht 0,0. Das System bestraft ein unbekanntes Thema weniger hart als ein irrelevantes. Die Grundlinie ist der am häufigsten angepasste Parameter: Zu hoch, und irrelevanter Inhalt flutet den Eingang; zu niedrig, und tatsächlich neue Interessen werden herausgefiltert, bevor ich sie überhaupt sehe.²

Umsetzbarkeit (30 %): Lernpotenzial

Umsetzbarkeit gleicht gegen 22 handlungsorientierte Schlüsselwörter ab: tutorial, guide, how-to, build, github.com. URLs werden besonders behandelt:

if "github.com" in url:
    hits += 2  # Repositories are inherently actionable
if "/docs" in url or "/tutorial" in url:
    hits += 1

Die Bewertung basiert auf einer Stufenfunktion, nicht linear: 0 Treffer → 0,10, 1 Treffer → 0,40, 2 Treffer → 0,60, 3+ Treffer → min(1.0, 0.70 + hits * 0.05). Die Stufenfunktion belohnt das Vorhandensein von Umsetzbarkeitssignalen stärker als deren Menge. Ein einzelner Tutorial-Link ist mehr wert als der Unterschied zwischen drei und vier Schlüsselwörtern.³

Tiefe (20 %): Metadaten-Reichhaltigkeit

Tiefe ist rein strukturell. Sie misst das Vorhandensein und die Länge von Feldern, nicht die Inhaltsqualität:

Tiefe ist die Dimension, der ich am wenigsten vertraue. Ein Tweet über ein Blumenfoto mit vollständiger Beschreibung und vier Tags erreicht einen Tiefenwert von 0,85. Reichhaltige Metadaten, irrelevanter Inhalt: ein hübsches Foto von Blumen.⁴

Autorität (15 %): Quellenglaubwürdigkeit

Autorität beginnt bei einer Grundlinie von 0,40 und wird nach Quellentyp angepasst:

if source in ("twitter", "x"):        score = 0.50
elif source in ("blog", "newsletter"): score = 0.60
elif source in ("github", "docs"):     score = 0.70

Eine Domänen-Positivliste überschreibt nach oben (nie nach unten): github.com, anthropic.com, apple.com, arxiv.org, docs.python.org und andere setzen die Autorität auf mindestens 0,75. Die Positivliste kodiert die Einschätzung, dass diese Quellen standardmäßig ein höheres Vertrauen verdienen.

Schwellenwert-Routing

Drei Routing-Bereiche bestimmen, was mit jedem bewerteten Signal geschieht:

THRESHOLD_AUTO_WRITE = 0.55   # → domain folder
THRESHOLD_INBOX      = 0.30   # → 00-Inbox (manual review)
# Below 0.30 → silently skipped

Die Pipeline schreibt Signale mit einem Score >= 0,55 direkt in einen von 12 Domänenordnern, abgeleitet aus Tag- und Titelabgleich. Signale im mittleren Bereich (0,30–0,55) gehen in einen Eingang zur manuellen Überprüfung. Alles unter 0,30 erreicht das Vault nie.

Der Bereich 0,30–0,55 ist die „Ambiguitätszone”, in der das System am wenigsten zuversichtlich ist. Ein optionales --llm-triage-Flag sendet diese Signale an Claude zur Auswertung, das den zusammengesetzten Score um bis zu ±0,20 anpassen kann, wodurch ein Signal potenziell über den automatischen Schreibschwellenwert verschoben wird. Claude sieht ausschließlich ambige Signale, niemals hoch oder niedrig bewertete. API-Tokens für Signale auszugeben, die der deterministische Scorer bereits bearbeitet hat, wäre Verschwendung.⁵

Die Domäneninferenz verwendet ein Abstimmungssystem. Jeder Tag wird einer Domäne zugeordnet, jedes Schlüsselwort im Titel gibt eine Stimme ab. Die Domäne mit den meisten Stimmen gewinnt. Bei Gleichstand entscheidet die Dict-Reihenfolge (faktisch willkürlich). Standard-Fallback: „Inspiration.”

Die Ergebnisse

Nach über 7.700 verarbeiteten Notizen über 14 Monate:

Die Verteilung spiegelt die Realität wider. Ich konsumiere mehr Development- und Design-Inhalte als alles andere. Eingangs-Elemente (420) repräsentieren die Ambiguitätszone – Signale, die der Algorithmus nicht zuverlässig automatisch zuordnen konnte.⁶

Was der Algorithmus falsch gemacht hat

Die Tiefenfalle

Ein Tweet über Hainblumenfotos erzielte composite 0.36, relevance 0.25, actionability 0.10, depth 0.85, authority 0.50. Er wurde in den Eingang geleitet, weil Tiefe (0,85) und Autorität (0,50) die nahezu null Relevanz und Umsetzbarkeit kompensierten. Reichhaltige Metadaten, irrelevanter Inhalt: ein hübsches Foto von Blumen.

Das Beispiel veranschaulicht die fundamentale Einschränkung von Metadaten-Proxy-Bewertungen. Tiefe misst „die Quelle hat strukturierte Daten bereitgestellt”, nicht „der Inhalt ist wertvoll”. Twitter liefert vollständige Beschreibungen und Tags für jeden Tweet. Ein gut getaggter Tweet über das Frühstück erreicht einen Tiefenwert von 0,85. Die Forschung zum Information Retrieval bezeichnet die zugrunde liegende Spannung als Precision/Recall-Kompromiss: Die Optimierung auf Recall (alles Relevante erfassen) lässt zwangsläufig falsch-positive Ergebnisse zu.¹⁰

Die Korrektur, die ich erwog und verwarf: Eine Reduzierung der Tiefengewichtung von 0,20 auf 0,10 würde falsch-positive Ergebnisse durch gut getaggte irrelevante Inhalte reduzieren, würde aber auch tatsächlich tiefgründige Inhalte von Quellen mit spärlichen Metadaten benachteiligen. Die aktuelle Gewichtung ist ein Kompromiss.

Das Relevanz-Grundlinien-Problem

Eine Grundlinie von 0,25 für Relevanz bei null Treffern bedeutet, dass jedes gut strukturierte Signal von einer vernünftigen Quelle mindestens 0,30 erreicht und im Eingang landet. Die Grundlinie erzeugt einen Boden für falsch-positive Ergebnisse: Der Eingang akkumuliert Signale, die gut getaggt und von vernünftigen Quellen stammen, aber nichts mit meinen Interessen zu tun haben.

Die tatsächliche Korrektur: Regelmäßige Überprüfung des Eingangs bleibt notwendig. Die Pipeline reduziert die Überprüfungsoberfläche von 7.700 Elementen auf 420 (eine Reduktion um ~95 %), kann aber die manuelle Überprüfung der Ambiguitätszone nicht eliminieren.

Implementierungshinweise

Die Pipeline läuft als CLI-Tool. Die Eingabe ist ein JSON-Array von Signalen (aus RSS, Twitter API oder manueller Eingabe). Die Ausgabe sind Obsidian-kompatible Markdown-Dateien, die in Domänenordner geschrieben werden.

python triage.py --input signals.json --vault ~/obsidian-signals/
python triage.py --input signals.json --vault ~/obsidian-signals/ --llm-triage
python triage.py --input signals.json --min-score 0.60  # Stricter routing

Vor der Bewertung wird eine Vorfilterung durchgeführt: URL-Deduplizierung gegen bestehende Vault-Notizen, Filterung leerer Inhalte und eine Sperrliste für Rauschquellen. Doppelte Notizen und Spam-Quellen erreichen die Bewertungsphase nie.

Die Scoring-Funktionen sind pur: keine Seiteneffekte, keine API-Aufrufe, kein Dateisystemzugriff. Jede Funktion nimmt ein Signal-Dict entgegen und gibt ein Scores-Dict zurück. Der pure Ansatz macht sie isoliert testbar und komponierbar mit der LLM-Triage-Stufe, die nur auf der ambigen Teilmenge läuft.⁷

Kernerkenntnisse

Für Ingenieure, die Triage-Systeme bauen:

• Deterministische Bewertung schlägt manuelle Kuratierung bei Skalierung. 7.700 Notizen in 14 Monaten. Manuelle Triage hätte über 50 Stunden Überprüfungszeit erfordert. Die Pipeline verarbeitete sie in Minuten mit einer Routing-Rate von ~95 % (nur 5,5 % erforderten manuelle Überprüfung).

• Metadaten-Proxys haben bekannte Fehlermodi. Tiefe misst Struktur, nicht Qualität. Autorität misst die Quelle, nicht die Genauigkeit. Beide Proxys funktionieren auf aggregierter Ebene, erzeugen aber vorhersagbare falsch-positive Ergebnisse auf der Ebene einzelner Signale. Die Fehlermodi anzuerkennen ist ehrlicher, als zu behaupten, der Algorithmus „funktioniert”.

Für Wissensmanagement-Praktiker:

• Gewichtete Composite-Scores legen Ihre tatsächlichen Prioritäten offen. Gewichtungen von 35/30/20/15 sind nicht willkürlich. Sie kodieren ein spezifisches Urteil: Relevanz zählt mehr als Umsetzbarkeit, die mehr zählt als Metadaten-Reichhaltigkeit, die mehr zählt als Quellenglaubwürdigkeit. Gewichtungen explizit und anpassbar zu machen ist der Unterschied zwischen einem System und einer Gewohnheit.

• Die Ambiguitätszone ist irreduzibel. Signale zwischen 0,30 und 0,55 sind tatsächlich ambig: Der deterministische Scorer kann sie nicht auflösen. LLM-Triage hilft, eliminiert die Zone aber nicht. Manuelle Überprüfung der ambigen Teilmenge bleibt notwendig.

Ich habe den Beitrag als Ingenieursproblem gerahmt, nicht als Produktivitätstipp. Composite-Scoring lässt sich auf jede Domäne anwenden, in der Elemente deterministisch zugeordnet werden müssen: Support-Tickets, Content-Moderation, Lead-Qualifizierung, Anomalieerkennung. Meine spezifischen Gewichtungen und Schwellenwerte kodieren persönliche Prioritäten, aber die Architektur ist allgemeingültig. Mehr darüber, wie akkumuliertes Wissen nichtlinearen Wert schafft, finden Sie unter Mental Compound Interest. OODA Loop for Prompt Engineering untersucht ein verwandtes Muster: strukturierte Beobachtung als Alternative zur Intuition. Jede Pipeline-Komponente (Scoring, Routing, Triage) ist einzeln nützlich und verstärkt sich mit den anderen – dem Compounding Engineering-Muster folgend.