Warum wir Suche, Tagging und Empfehlungen aus der Cloud verlagert haben

Die meisten „KI-gestützten“ Browser-Erweiterungen senden alles an einen Server – selbst jene Bestandteile, die überhaupt nichts mit KI zu tun haben. Suche, Tag-Bereinigung, „ähnliche Artikel finden“: Das sind jahrzehntealte, bewährte Verfahren. Sie benötigen kein Sprachmodell und definitiv keinen Netzwerk-Roundtrip. Wir sind AI Summary Helper Funktion für Funktion durchgegangen und haben uns jeweils gefragt: Braucht das wirklich die Cloud – oder nutzen wir sie nur aus Gewohnheit, weil es die einfachere Architektur ist?

Die meisten davon brauchten sie nicht.

Was tatsächlich lokal auf das Gerät verlagert wurde

Suche. Ursprünglich glich die Erweiterung nur Artikeltitel und Tags ab – schnell, aber blind für den eigentlichen Artikeltext. Anstatt bei jedem Tastenanschlag den gesamten Text per Brute-Force zu durchsuchen oder jede Anfrage an einen Server zu schicken, haben wir einen kompakten TF-IDF-Index aus dem lokal gespeicherten Archiv der Nutzer aufgebaut. Günstige Felder wie Titel und Tags werden weiterhin sofort und ohne Mehraufwand geprüft. Längere Suchanfragen werden über den Index erweitert, der einmal pro Sitzung erstellt und inkrementell aktualisiert wird – ohne Neuscan bei jedem Tastendruck.

Duplikaterkennung. Bevor ein Speichervorgang abgeschlossen wird, durchläuft er eine mehrstufige Prüfung: Zuerst ein exakter, normalisierter URL-Abgleich (effizient, O(1)), danach eine Titel-Ähnlichkeitsprüfung für die wenigen verbleibenden Treffer und erst dann – für die allerletzten Kandidaten – ein vollständiger TF-IDF-Kosinus-Ähnlichkeitsvergleich. Die meisten Speichervorgänge erreichen die rechenintensivste Stufe gar nicht erst, da sie bereits in den vorgeschalteten Schritten aufgelöst werden.

Tag-Normalisierung. Mit der Zeit weichen Tags unweigerlich voneinander ab: „ML“, „Machine Learning“ und „machine-learning“ bedeuten für Menschen dasselbe, für einen Filter jedoch nicht. Eine kleine Alias-Tabelle fängt die offensichtlichen Fälle ab; ein unscharfer Edit-Distanz-Abgleich über den gesamten Tag-Bestand übernimmt den Rest. Dabei wird stets die Schreibweise als kanonische Form gewählt, die Sie am häufigsten verwendet haben, anstatt Ihnen eine vorgegebene „korrekte“ Version aufzuzwingen.

Lesbarkeit und Tonalität. Der Flesch-Kincaid-Lesbarkeitsindex basiert auf reiner Arithmetik von Satz- und Silbenzahlen – ganz ohne Modell. Die Sentiment-Analyse nutzt eine integrierte AFINN-Wortliste mit einer einfachen Negationsprüfung für die zwei vorangegangenen Tokens. Nichts davon muss jemals Ihren Browser verlassen.

„Ähnliche Artikel“ und Digest. Beide Funktionen greifen auf exakt dieselben TF-IDF-Vektoren zurück, die bereits für die Suche erstellt wurden. Es wäre ein Leichtes gewesen, drei separate Ähnlichkeitssysteme für drei verschiedene Funktionen zu entwickeln. Durch die Nutzung eines einzigen gemeinsamen Index für Suche, Empfehlungen und Digest-Kuration bleibt das Gesamtsystem schlank – und jede Optimierung des Index kommt sofort allen drei Funktionen gleichzeitig zugute.

Was wir bewusst in der Cloud belassen haben

Die eigentliche Zusammenfassung – jener Schritt, der tatsächlich ein großes Sprachmodell erfordert – benötigt weiterhin einen Netzwerkaufruf. Bei den aktuellen Größen lokaler Modelle führt daran kein Weg vorbei, wenn man die Ausgabequalität führender Cloud-Modelle erreichen möchte. Nutzer hinterlegen für diesen Schritt ihren eigenen API-Schlüssel (OpenAI, Gemini, Mistral, DeepSeek) oder verknüpfen die Erweiterung mit einer lokalen Ollama-Instanz, um auch hier vollständig netzwerkunabhängig zu bleiben. Dies ist der einzige Bereich, in dem „On-Device“ nicht der Standard ist, sondern optional aktiviert werden kann – denn der Kompromiss ist real: Ein lokales Modell arbeitet langsamer und liefert geringere Qualität als ein gehostetes Modell, und wir möchten Ihnen hier nichts vormachen.

Warum dies mehr als ein Datenschutz-Argument ist

Der Datenschutzaspekt ist real: Wenn eine Browser-Erweiterung mit weitreichenden Host-Berechtigungen Seiteninhalte für Aufgaben an Server übermittelt, die dies gar nicht erfordern, ist das eine handfeste Vertrauensfrage – nicht bloß Kosmetik. Der pragmatischere Grund liegt jedoch schlicht in sauberem Software-Engineering: Eine TF-IDF-Suche braucht keine 200 ms Netzwerklatenz. Eine Tag-Deduplizierung benötigt keine laufenden API-Kosten. Wenn man das passende Werkzeug für die konkrete Aufgabe wählt, statt standardmäßig alles über die Cloud abzuwickeln, entsteht ein System, das schneller arbeitet, kostengünstiger im Betrieb ist und auch offline zuverlässig funktioniert. Der Gewinn an digitaler Souveränität und Datenschutz fällt dabei ganz natürlich ab – und nicht erst als nachträgliches Verkaufsargument.