Ein Risikoklassifikator für Minderjährige, der in ein Smartphone passt

Siebte Folge von Cluster-Röntgenbild. Eine Sicherheitslinie anderer Art: die der Minderjährigen, die ein Telefon benutzen.

Die Frage #

Risikosituationen in den Gesprächen eines Minderjährigen zu erkennen (Mobbing, Grooming, sexuelle Inhalte, Isolation, Drohungen), ist mit einem Sprachmodell möglich. Es auf einem Server zu tun, bedeutet, das Gespräch aus dem Telefon hinauszuschicken, und genau das will man mit dem Privatleben eines Minderjährigen nicht tun. Die Linie fragt, ob ein Modell, das klein genug ist, um auf dem Telefon selbst zu laufen, das Risiko mit der nötigen Zuverlässigkeit klassifizieren kann, und wie viel verloren geht, wenn man es so weit komprimiert, dass es hineinpasst.

Wie man vorgeht #

Der Klassifikator erhält ein Gespräch und antwortet ausschließlich mit JSON: eine Risikostufe (keine, niedrig, mittel, hoch, kritisch), eine Liste von Kategorien aus acht, eine Konfidenz und eine kurze Begründung. Kein Freitext: Die Anwendung, die ihn nutzt, braucht eine Ausgabe, die sie ohne Mehrdeutigkeit interpretieren kann.

Der Weg bis ins Telefon hat vier Abschnitte:

• Synthetische Daten. Es gibt kein öffentliches Korpus von Risikogesprächen mit Minderjährigen, und es sollte auch keines geben. Es werden rund 500.000 Beispiele mit Qwen2.5 7B erzeugt, nach Kategorie und auf Englisch, Spanisch und gemischt, plus 35.000 mit hoher und kritischer Schwere, damit das Modell die schweren Fälle nicht unterschätzt.
• Fine-Tuning mit LoRA. Ein Referenz-Hauptmodell und fürs Telefon Gemma 3 1B; in der Mitte der Kampagne werden Gemma 4 E2B und E4B ausprobiert, und im September geht es zurück zum 1B.
• Kompression nach LiteRT-LM, Googles Format für Inferenz auf dem Gerät: eine INT8-Variante „für Telefone mit 6 GB+“ und eine INT4-Variante „für Telefone mit 4 GB“, plus eine für den Browser mit WebGPU.
• Evaluation mit Vertrag. Metriken auf einem Validierungssatz und ein Benchmark auf zurückgehaltenen Daten, der fehlschlägt, wenn eine Regression über 0,5 % auftritt. Ein Profiler misst RAM und Akku des komprimierten Modells auf der CPU, denn ein Klassifikator, der den Akku leert, schützt niemanden.

Was man lernt #

Das Debugging im Juni ist selbst ein Ergebnis: Das komprimierte Modell gab Antworten, die das Fine-Tuning nicht widerzuspiegeln schienen. Die Skripte grenzen per Bisektion ein, vergleichen die fusionierten Gewichte mit dem Originalmodell, um einen Fehler in der LoRA-Fusion auszuschließen, und testen denselben Prompt mit und ohne die Turn-Marker des Chat-Templates, „um zu isolieren, ob das Problem das Template oder die Quantisierung ist“. Unter den festen Tests ist die adversariale Frage „welches Modell bist du?“, die ein Klassifikator nicht beantworten sollte.

Die andere Lektion betrifft Werkzeuge: Eine neue Architektur (Gemma 4) in ein Geräteformat zu exportieren, wenn die Toolchain sie noch nicht vollständig unterstützt, kostete einen Monat an Iterationen. Die Rückkehr zum 1B im September legt nahe, dass für dieses Problem ein ausgereiftes, gut komprimiertes Modell mehr wert ist als ein neueres.

Der Code des Projekts ist auf GitHub veröffentlicht: safecircleia/horizon .

Auf dem Cluster #

Die Hälfte der Jobs ist als fehlgeschlagen verzeichnet, und fast alle davon dauerten weniger als fünfzehn Minuten: Das sind die Iterationen mit der Exportkette, keine verlorene Rechenzeit. Die Trainings liefen durch; das des 1B kam auf 41 Stunden.

In der achten Folge : Graphen über einer Küstenlagune.

Zahlen aus dem Slurm-Accounting (reservierte Kapazität, nicht gemessene Nutzung) und den archivierten sbatch-Dateien. Anonymisierter Beitrag: ohne identifizierbare Nutzer, Pfade, E-Mails oder Projektnamen. Die Zitate stammen aus den Kommentaren der Skripte.