Themen, die ihren Namen verdienen müssen

Teil 2 der Serie „Hinter der Karte" — wie aus tausenden Freitexten benannte, belastbare Themen werden

Kurzfassung

Freitext automatisch in Themen zu gruppieren klingt nach einem gelösten Problem — TF-IDF und k-means gibt es seit Jahrzehnten. Naiv angewendet lügt das Verfahren aber auf drei verschiedene Arten: Es macht aus dem App-Namen selbst ein „Thema", es kollabiert bei kleinen Stichproben in einen einzigen Mega-Cluster, und es lässt sich von zu aggressivem Filtern in eine falsche Balance drängen. Dieser Artikel zeigt, mit welchen drei zusätzlichen Regeln YelmeAtlas ein Thema erst dann einen Namen tragen lässt, wenn es sich diesen Namen tatsächlich verdient hat — belegt mit den gemessenen Vorher/Nachher- Vergleichen, die zu jeder Regel geführt haben.

1. Diagnose: wo naives Clustering lügt

Text-Clustering bedeutet: Bewertungen werden zu Vektoren, ähnliche Vektoren landen im selben Topf, jeder Topf bekommt aus seinen häufigsten Wörtern einen Namen. So weit die Theorie. In der Praxis produzierte genau dieser naive Ansatz an echten App-Bewertungen drei konkrete, reproduzierbare Fehler:

Fehler 1 — der App-Name wird zum Thema. Läuft die Namensgebung nur über Häufigkeit, gewinnt fast immer der Name der App selbst: Jede Instagram- Bewertung erwähnt mit hoher Wahrscheinlichkeit das Wort „Instagram". Reale Testläufe erzeugten auf diese Weise Themen wie „instagram", „whatsapp" und „netflix" — technisch korrekt geclustert, inhaltlich wertlos. Ein Thema, das jede Bewertung gleichermaßen betrifft, unterscheidet nichts voneinander.

Fehler 2 — die schnelle Variante lügt bei kleinen Stichproben. Es gibt zwei gängige Varianten des k-means-Algorithmus: die vollständige Version, die jeden Punkt in jeder Runde betrachtet, und eine „Mini-Batch"-Variante, die nur zufällige Teilmengen ansieht — gedacht für Datensätze, die nicht ins Silikon passen. Ein Bewertungsfenster hat aber ein paar hundert kurze Dokumente, nicht Millionen. Gemessen an denselben 100 echten Instagram- Bewertungen:

Die „schnellere" Variante war auf dieser Größenordnung nicht ungenauer — sie war praktisch nutzlos: ein einziger Riesen-Cluster plus Rauschen.

Fehler 3 — zu aggressives Filtern kollabiert die Trennung. Wörter wie „schnell", „langsam", „neu" oder „alt" sind schlechte Themen-Namen (sie sagen nicht, worum es geht), aber gute Trennungs-Merkmale (sie unterscheiden eine Beschwerde über Geschwindigkeit von einer über Werbung). Wurden sie versuchsweise ganz aus der Berechnung entfernt statt nur aus der Namensgebung, schnellte der größte Cluster bei Instagram von rund der Hälfte des Fensters auf 90 % — eine Aufteilung, die praktisch gar nichts mehr trennt.

2. Bisherige Lösungsansätze und ihre Grenzen

• Feste Stichwortlisten (Lexikon-Ansatz) sind vorhersagbar und stabil, erkennen aber nur, was vorher hineingeschrieben wurde — ein neues Problem bleibt unsichtbar, bis jemand die Liste erweitert.
• Naives k-means ohne Nachprüfung produziert genau die drei Fehler oben.
• Ein Sprachmodell zur Themenbenennung würde alle drei Fehler vermutlich vermeiden — aber nicht deterministisch, nicht kostenfrei pro Anfrage, und mit dem Risiko, ein Thema zu erfinden, das im Text so nicht vorkommt (siehe Teil 1, Kapitel 5).

YelmeAtlas nutzt beide erstgenannten Verfahren tatsächlich nebeneinander — den Lexikon-Ansatz als deterministische, ohne Modell-Abhängigkeit wählbare Alternative — setzt aber standardmäßig auf k-means, abgesichert durch eine Nachprüfung, die kein Sprachmodell braucht.

3. Der Ansatz von YelmeAtlas

Das Prinzip: Clustering findet Kandidaten, drei Regeln entscheiden, ob ein Kandidat seinen Namen behalten darf. Wer die Prüfung nicht besteht, wird nicht gelöscht — die Bewertungen bleiben in einem ehrlich beschrifteten Sammelbecken „Sonstiges", sichtbar, aber abgesetzt, nie in der Überschrift.

4. Der Algorithmus im Detail

flowchart TD
    A["Freitext der Bewertungen"] --> B["TF-IDF-Vektorisierung<br/>seltene, wiederkehrende Wörter<br/>zählen mehr als Füllwörter"]
    B --> C["Vollständiges k-means<br/>nicht die Mini-Batch-Variante"]
    C --> D["Nomen-Erkennung ohne Wörterbuch<br/>groß geschriebene Wörter<br/>mitten im Satz"]
    D --> E{"Drei-Tor-Validierung je Cluster"}
    E -->|"Unterstützung ≥ 40 %<br/>Auffälligkeit ≥ 1,5×<br/>Außen-Anteil ≤ 50 %"| F["Benanntes Thema"]
    E -->|"eines der Tore nicht bestanden"| G["Sammelbecken „Sonstiges"<br/>gedimmt, nie in der Überschrift"]

Schritt 1 — TF-IDF. Jedes Wort bekommt ein Gewicht: hoch, wenn es in wenigen Bewertungen oft vorkommt (typisch für ein echtes Thema), niedrig, wenn es überall gleich häufig ist (typisch für Füllwörter). Das ist der Standardtrick, der verhindert, dass „die", „und" oder „app" die Berechnung dominieren.

Schritt 2 — Clustering mit vollständigem k-means. Wie in Kapitel 1 gemessen: die Mini-Batch-Variante bringt auf dieser Datenmenge keinen Vorteil, aber einen erheblichen Qualitätsverlust. Die vollständige Variante ist bei ein paar hundert kurzen Texten schnell genug, dass der Geschwindigkeitsvorteil der Näherung schlicht nicht gebraucht wird.

Schritt 3 — Nomen-Erkennung ohne Wörterbuch. Damit ein Themen-Name ein Hauptwort ist („Werbung", nicht „schnell"), müsste man eigentlich ein Wörterbuch oder ein Sprachmodell befragen. Es gibt aber einen einfacheren Weg, der zur deutschen Sprache passt: Im Deutschen werden praktisch nur Hauptwörter mitten im Satz großgeschrieben. Ein Wort, das nicht am Satzanfang steht und trotzdem groß beginnt, ist mit hoher Treffsicherheit ein Nomen — ganz ohne Wörterbuch, ohne Sprachmodell, ohne zusätzliche Abhängigkeit.

Schritt 4 — die Drei-Tor-Validierung. Das ist die eigentliche Antwort auf Fehler 1 aus Kapitel 1. Ein Cluster darf seinen vorgeschlagenen Namen nur behalten, wenn er alle drei Bedingungen erfüllt:

Erst wer alle drei Tore passiert, gibt einem Thema seinen Namen. Was keins der drei Tore besteht, landet in „Sonstiges" — sichtbar, aber ehrlich als Restmenge gekennzeichnet.

5. Ein gemessenes Beispiel

Vor der Drei-Tor-Validierung erzeugte dasselbe Verfahren auf echten Läufen Themen wie „instagram", „whatsapp" und „netflix" — jeweils der Name der App selbst. Nach Einführung der Validierung fallen genau diese Begriffe durch das Auffälligkeits-Tor: Sie sind zwar unterstützt (jede Bewertung erwähnt die App), aber nicht auffällig — sie sind überall gleich häufig und unterscheiden damit nichts. Die verbleibenden, validierten Themen sind die inhaltlich tragfähigen: in der Spotify-Auswertung aus Teil 1 etwa „Werbung", „Free-Tier-Grenzen" und „Benachrichtigungen" — jedes davon unterscheidet tatsächlich einen Teil der Bewertungen vom Rest.

6. Grenzen der Methode

• Rein wortbasiert, nicht bedeutungsbasiert. Zwei Bewertungen, die dasselbe Problem mit völlig verschiedenen Worten beschreiben, können in unterschiedlichen Clustern landen. Das Verfahren erkennt Muster in der Wortwahl, kein tieferes Sprachverständnis. <br/>*(Absichtlich so — siehe Teil 1, Kapitel 5: dieselbe Vorhersagbarkeit, die hier Grenzen setzt, macht das Ergebnis andernorts nachvollziehbar.)*
• Deterministisch bei festem Zufalls-Startwert, aber nicht global stabil. Zwischen unterschiedlichen Programmbibliotheks-Versionen können die internen Cluster-Kennungen die Reihenfolge tauschen — verglichen wird daher immer die Gruppierung selbst, nie eine rohe interne Nummer.
• Braucht eine Mindestmenge an Text, um überhaupt sinnvoll zu trennen. Bei sehr wenigen Bewertungen im Fenster liefert das Verfahren ehrlich einen einzigen Sammel-Cluster statt erfundener Feinheit.

7. Fazit

Der eigentliche Fortschritt liegt nicht im Clustering-Algorithmus selbst — TF-IDF und k-means sind Lehrbuchstoff. Er liegt in der Erkenntnis, dass Clustering Gruppen findet, aber nichts darüber aussagt, ob der naheliegendste Name für eine Gruppe auch ein guter ist. Die Drei-Tor- Validierung trennt genau diese beiden Fragen: Wie werden Bewertungen gruppiert? Und verdient diese Gruppe überhaupt einen eigenen Namen? Ohne diese zweite Frage hätte jede Instagram-Auswertung als „Top-Thema: Instagram" geendet — richtig gruppiert, aber nichtssagend.

Der nächste Teil bleibt bei den Daten selbst: wie die Bewertungen überhaupt ohne Entwicklerkonto ins System kommen — und warum ein nächtlicher Archivierungslauf gegen ein Problem kämpft, das die Stores selbst verursachen: sie vergessen schneller, als Menschen sich einloggen. → Teil 3: Ohne Entwicklerkonto an die Daten (folgt)

← Teil 1: Eine Karte für tausende Freitexte