Zum Inhalt springen

/work · In production use

Schwärzwerk

DSGVO-Schwärzung für deutschen Text: Regex über offizielle Formate gewinnt bei Überschneidungen, ein nachtrainiertes GLiNER2-Modell findet den Rest. F1 0,916, bei Firmen im Einsatz.

Python · GLiNER2 · PyTorch · mDeBERTa · Regex-Hybrid · Kaggle T4

Problem

Firmen in Deutschland kopieren personenbezogene Daten den ganzen Tag: ins Support-Ticket, ins Testsystem, an den Dienstleister. Die DSGVO bewertet dafür keine Anstrengung, sie verlangt, dass die Daten weg sind, bevor die Kopie das Haus verlässt. Die Werkzeuge, die es dafür zu kaufen gibt, versagen auf deutschem Text.

Das Versagen hat eine Form: Internationale Detektoren kennen US-Formate und englische Namen und bleiben bei Sozialversicherungsnummer, Steuer-Identifikationsnummer, KVNR und Kfz-Kennzeichen stehen. PIIBench 2026, der breiteste öffentliche Benchmark, lässt acht Systeme antreten: Alle bleiben unter F1 0,14, Microsoft Presidio als bestes System erreicht 0,1385 und findet auf den meisten Typen gar nichts. Eine eigene deutsche Auswertung gibt es im Benchmark gar nicht erst. Die kommerziellen Suiten kosten trotzdem Enterprise-Geld.

Architektur: zwei Schichten, klare Zuständigkeit

Die Kernentscheidung ist, welche Schicht entscheidet. Offizielle deutsche Kennungen haben publizierte Formate, und genau deshalb gehören sie in eine deterministische Regex-Schicht: 14 Mustergruppen für SVNR, Steuer-Identifikationsnummer, W-IdNr, Personalausweis und Reisepass (seit November 2021 über den Buchstabenpool unterscheidbar), KVNR, Kfz-Kennzeichen und den Rest. Wo Regex und Modell überlappen, gewinnt die Regex. Wo eine Spezifikation existiert, schlägt Determinismus Wahrscheinlichkeit.

Die Modell-Schicht nimmt, was kein Format hat: Namen, freie Adressen, Passwörter im Kontext. Sie besteht aus einem nachtrainierten GLiNER2-Modell, 307 Millionen Parametern auf einem mDeBERTa-Backbone, trainiert für die 17 PII-Typen. Die Nachbearbeitung fügt die Splitter zusammen, die der Tokenizer hinterlässt: die Hausnummer, die von der Straße abdriftet, der Titel, der vom Namen abrückt.

Die Trennung beantwortet nebenbei die LLM-Frage. Ein allgemeines Sprachmodell entscheidet hier nichts; es half bei Formaten und Formulierungen und verwechselte die Steuernummer mit jeder anderen Ziffernfolge des Belegs. Die erste Version, nur Modell, erreichte bei Steuer-IDs ein F1 von 0,452. Jedes Muster der finalen Regex-Schicht wurde von Hand gegen die offizielle Spezifikation geprüft.

Daten: synthetisch, über 50.000 Beispiele

Echte Kundenbelege sind das eine Material, auf dem dieses Projekt nicht trainiert; der ganze Punkt ist, genau dieses Material später zu schwärzen. Der Trainingskorpus ist deshalb synthetisch: über 50.000 Beispiele aus Musterfamilien, Adressen in deutscher, österreichischer und Schweizer Schreibung, Steuernummer in alter und einheitlicher Form, Kreditkarten, Führerscheinnummern, KVNR, Kennzeichen, IP-Adressen, URLs, Passwörter, dazu realistische Negativbeispiele.

Die Generatoren kodieren die offiziellen Spezifikationen und folgen deren Änderungen: die Nummernpools, die Personalausweis und Reisepass trennen, sind die Regeln ab November 2021. Öffentliche Korpora ergänzen die Stellen, an denen freier Text fehlt. Ein zurückgehaltener Benchmark von 188 Beispielen deckt alle 17 Typen mit Grenzfällen ab: namensähnliche Strings in Nicht-PII-Rollen, unvollständige IBANs, gemischte Kontextsätze.

Training: fünf Epochen auf Kaggles freier T4

Das Training läuft auf Kaggles kostenloser T4-Stufe, einer 16-GB-GPU, auf die ein volles Fine-Tuning mit 307 Millionen Parametern noch passt. Ein Lauf dauert rund eine halbe Stunde über fünf oder mehr Epochen, mit fp16, Cosine-Schedule, Warmup und Early Stopping. Die GPU ist der billigste Teil dieses Projekts.

Die Stellschrauben zählten mehr als die Hardware. Die zweite Version fuhr Lernraten, die zehn- bis hundertfach unter den GLiNER2-Empfehlungen lagen, und einen Trainingssatz ohne einen einzigen Text ohne PII, sodass das Modell überall personenbezogene Daten sah. Die benannten Fehler brachten mehr F1 als jede zusätzliche Epoche.

Ergebnisse (gemessen) & Einsatz

Der aktuelle Stand misst F1 0,916 auf dem 188-Beispiele-Benchmark. Die schwachen Stellen stehen im Protokoll: person bei 0,87 und address bei 0,86, beide durch die Präzision gezogen (0,775 und 0,750), password bei 0,74. Das Ziel der nächsten Datenrevision ist F1 0,95, die Fehlerliste ist schon geschrieben: Lernraten, Negativbeispiele, englische Label-Beschreibungen.

Das System läuft im Produktiveinsatz bei Firmen, als CLI über Dokumente und Tickettexte: Regex-only-Modus für die strukturierten Felder, das Modell für den Rest, jede Schwärzung als Kategorie-Platzhalter. Als Open Source ist es noch nicht veröffentlicht; kommerzielle Nutzung läuft über info@dimitripisarev.com. Eine öffentliche Model Card und eine gehostete API sind die nächsten Schritte.