Adressparser in 2026: Tokenisierung, Mehrdeutigkeit, Fallbacks

Parsing gewinnt Struktur zurück, die im Text vorhanden war: die Postleitzahl, den Regionscode, die Stadt und die Straßenzeile, in dieser Reihenfolge der Zuverlässigkeit. Es kann keine Informationen zurückgewinnen, die nie niedergeschrieben wurden. Ein String ohne Einheitenbezeichner enthält keine Einheitennummer, und keine noch so große Inferenz sollte eine erfinden.

Es kann auch nicht bestätigen, dass die Felder wahr sind. Das Parsen von „123 Main St, Springfield, IL 62701“ erzeugt kohärente Felder, und die Adresse kann trotzdem fiktiv sein oder die Stadt nicht zur ZIP passen. Parsing ist eine Textoperation. Verifikation ist eine Datenoperation, und die beiden sollten niemals einen Funktionsnamen oder eine Erfolgsmeldung teilen.

Stufe eins ist die Normalisierung: trimmen, interne Leerzeichen zusammenfassen, geschützte Leerzeichen ersetzen, Interpunktionsvarianten normalisieren und entscheiden, ob in Großbuchstaben umgewandelt wird. Das Original bleibt für den Fallback unangetastet. Stufe zwei ist die Segmentierung: an Kommas aufteilen, wenn welche vorhanden sind, sonst nach der Grammatik des Landes aufteilen. Stufe drei ist die Klassifizierung: jedes Segment mit dem Regelsatz des Landes als Postleitzahl, Region, Stadt, Straße oder Einheit kennzeichnen. Stufe vier ist die Zuweisung: Labels den Feldern zuordnen, Konflikte auflösen und das Ergebnis bewerten.

Die Stufen getrennt zu halten macht die Fehlermodi trennbar. Ein Segmentierungsfehler sieht anders aus als ein Klassifizierungsfehler, und jede Stufe kann mit ihrem eigenen Korpus per Unit-Test geprüft werden. Außerdem kann man früh abbrechen: Ist das Land unbekannt, überspringt man die Klassifizierung ganz und gibt die Segmente mit der Konfidenz „unbekannt“ pro Feld zurück.

Die Feldreihenfolge ist die größte einzelne Fehlerquelle bei falschen Parses, weil dieselben Tokens ihre Position wechseln. Die Vereinigten Staaten, Kanada, das Vereinigte Königreich und Australien setzen die Postleitzahl nach die Stadt. Deutschland, Frankreich, die Niederlande und Belgien setzen sie vor die Stadt. Japan setzt sie an den Anfang, vor die Präfektur. Brasilien setzt die Postleitzahl nach dem Bundesstaat mit einem Trennzeichen.

Deshalb muss der Parser das Land kennen, bevor er irgendetwas klassifiziert. Das Land aus dem String selbst abzuleiten ist zirkulär: Das Postleitzahlenmuster kann eines nahelegen, aber viele Muster überschneiden sich. Frage das Land aus dem Formular, dem Locale oder einem expliziten Selektor ab und markiere den Parse als niedrige Konfidenz, wenn es fehlt, statt aus einem zweibuchstabigen Token zu raten, das ein Bundesstaat oder ein Land sein könnte.

Sekundäre Einheitenbezeichner sind die häufigste Mehrdeutigkeit. „Apt“, „Ste“, „Unit“, „Fl“ und „Rm“ sind zuverlässig, wenn ein Bezeichner folgt, aber „Unit 5“ kann auch ein Straßenname sein, und „Building 3“ kann die Primäradresse eines Campus sein. Ein Parser sollte eine Einheit nur extrahieren, wenn auf den Bezeichner eine Zahl oder ein kurzes alphanumerisches Token folgt und er nach der Hausnummer erscheint.

Straßensuffixe sind die zweite Falle. Ein Token wie „Way“, „Court“ oder „Park“ kann ein Suffix, ein Straßenname oder eine Stadt sein. Richtungsangaben haben dasselbe Problem: „N“ kann eine vorangestellte Richtung, eine Abkürzung eines Straßennamens oder eine Region sein. Nutze die Position relativ zur Hausnummer und die Kommastruktur, und wenn zwei Lesarten beide plausibel sind, behalte das Originalsegment und senke die Konfidenz, statt zu wählen.

Bewerte jedes Feld, dann den Datensatz. Ein Feld hat hohe Konfidenz, wenn es auf ein verankertes Landesmuster passte und seine Position mit der erwarteten Reihenfolge übereinstimmte. Mittlere Konfidenz liegt vor, wenn das Muster passte, die Position aber abgeleitet wurde, und niedrige, wenn es durch Ausschluss zugewiesen wurde. Ein Datensatz hat nur dann hohe Konfidenz, wenn jedes Pflichtfeld hohe Konfidenz hat und keine nicht platzierten Segmente vorhanden sind.

Lege einen Schwellenwert fest und setze ihn durch. Über dem Schwellenwert akzeptieren und speichern. Darunter den Originalstring behalten und den Datensatz zur Prüfung markieren, statt eine Vermutung in die strukturierten Spalten zu schreiben. Gib den Score und die Gründe in der API-Antwort aus, denn der Prüfer muss wissen, welches Feld fehlgeschlagen ist, nicht nur dass etwas fehlgeschlagen ist.

Ein Parse-Ergebnis sollte explizite Ergebnisse haben, keinen Boolean. Fehlendes Land bedeutet, dass die Grammatik nicht laufen kann. Eine fehlende Postleitzahl ist in Ländern mit Postleitzahl ein Fehler und in Hongkong und den VAE normal. Ein nicht platzierbares Segment bedeutet, dass die Kommastruktur und die Grammatik nicht übereinstimmen, und der Datensatz braucht menschliche Augen.

Gib jedem Ergebnis einen stabilen Code, damit Aufrufer verzweigen können, ohne Prosa zu parsen. Gib die normalisierte Eingabe, die Originaleingabe, die Feldwerte mit Konfidenz und die Liste der nicht platzierten Segmente zurück. Diese Nutzlast erlaubt es einer UI, genau das fehlgeschlagene Token hervorzuheben, statt oben im Formular einen generischen Fehler anzuzeigen.

Beginne mit einem kleinen, manuell verifizierten Korpus, ein bis drei Adressen pro Land, jeweils mit den erwarteten Feldwerten, geschrieben von jemandem, der die Post dieses Landes liest. Zwanzig bis vierzig Fälle reichen aus, um strukturelle Regressionen zu erkennen, und sind klein genug, um in einem Pull Request geprüft zu werden. Speichere ihn als Daten, nicht als in Testcode vergrabene Assertions.

Dann mutiere jeden Fall mechanisch: Kommas entfernen, Groß-/Kleinschreibung ändern, doppelte Leerzeichen zusammenfassen, ein geschütztes Leerzeichen einfügen, zwei Zeilen vertauschen, ein Suffix abkürzen und eine Einheit anhängen. Die erwartete Ausgabe für eine Mutation ist nicht immer identisch, sollte aber innerhalb einer definierten Toleranz bleiben, und die Konfidenz sollte sinken, statt dass sich die Felder stillschweigend ändern. Verfolge Precision und Recall pro Feld, damit ein Fix für die Stadt nicht stillschweigend die Postleitzahl kaputt macht.

Parse keine Freitextnotizen, Lieferanweisungen oder irgendetwas, das ein Mensch als Prosa geschrieben hat. „Leave at the side gate, second house after the blue one“ hat keine Felder, und das Extrahieren von Tokens daraus erzeugt selbstsicheren Müll. Behalte es als Textblob, der an die Bestellung angehängt wird.

Parse keine Schriftsysteme, die dein Regelsatz nicht abdeckt. Eine japanische Adresse in Kanji braucht eine japanische Grammatik; ein Latin-Script-Tokenizer darüber wird an den falschen Grenzen trennen und die Präfektur verlieren. Parse keine Adressen ohne Hausnummer oder solche, die einen Gebäudenamen als primären Standort verwenden, was in Teilen Asiens und bei Campusadressen üblich ist. In all diesen Fällen ist die korrekte Ausgabe der Originalstring plus ein klarer Status „nicht geparst“.