Ich habe in den letzten Wochen eine Datenbank aufgebaut. Keine kleine: bisher 1.826 Kirchenorte aus Thüringen und Sachsen-Anhalt, fünf historische Zeitschnitte. Quellenwerke wie Güldenapfel (1931, 1.368 Orte), Machholz (1925, 1.680 Orte), die EKMD-Kirchenlandkarte (2026), das Genealogische Ortsverzeichnis (GOV), die Thüringer Pfarrerbücher und die Pfarrerbücher der Kirchenprovinz Sachsen (KPS). Hier sogar bis 1820 zurückreichend.
Irgendwann muss man diese Quellen aufeinander abbilden. Gleiche Orte, andere Namen, andere Schreibweisen, andere Epochen. Das ist Matching-Arbeit – und ich war neugierig, wie weit ich dabei mit automatisierten Methoden komme.
Die Antwort: weit. Aber nicht weit genug. Und die Stellen, an denen es nicht funktioniert hat, sind lehrreicher als die Stellen, an denen es geklappt hat.
KI in der Genealogie – was funktioniert und was nicht
In einem früheren Artikel habe ich beschrieben, wie ich KI-Tools grundsätzlich in der Forschung einsetze – als Werkzeug, nicht als Orakel. Transkribus für Kirchenbücher, Sprachmodelle für strukturierte Extraktion, Skripte für den Gramps-Import. Das funktioniert gut.
Beim Ortsname-Matching historischer Quellen verlässt mich das Vertrauen.
Warum Ortsname-Matching eigentlich einfach klingt
Auf dem Papier ist es trivial. Du hast zwei Listen. Du vergleichst Namen. Du nimmst Levenshtein-Distanz, Fuzzy-Matching, vielleicht noch eine Phonetik-Bibliothek. Treffer ab 80 % Ähnlichkeit gelten als Match. Fast schon wie beim Online-Dating, wo Du entweder nach rechts oder nach links wischst.
In der Praxis bricht das beim ersten historischen Quellenwerk zusammen.
Der Grund ist nicht, dass Algorithmen schlecht wären. Der Grund ist, dass Ortsnamen in historischen Quellen kein Normdatenproblem sind – sie sind ein Wissenproblem. Und Wissen über Orte ist nicht formalisierbar. Es ist implizit, regional, historisch aufgeladen. Kein Trainingsdatensatz der Welt bildet das vollständig ab.
Ich zeige dir, was ich meine.
Fall 1: *Gamitädt* ≠ *Gamstädt*
Im Güldenapfel von 1931 steht Gamstädt – korrekt. Das Problem entstand beim OCR-Durchlauf meines eigenen Scans: Tesseract las Gamitädt. Der Algorithmus, der diese OCR-Ausgabe gegen GOV und EKMD abgeglichen hat, fand keinen Match – zu wenig Zeichenähnlichkeit. Und er hatte formal recht. Es sind verschiedene Zeichenketten. Wir Menschen können so etwas erkennen, ohne viel darüber nachzudenken. Eislcbcn hab ich direkt als Eisleben erkannt.
Ich habe sofort gewusst, was gemeint ist. Nicht weil ich besonders schlau bin. Sondern weil ich die Karte kenne. Gamstädt liegt östlich von Gotha, auf halbem Wege nach Erfurt. Da kann nur Gamstädt gemeint sein. Das ist ein OCR-Fehler in meinem eigenen Workflow – und OCR-Fehler in Fraktur-Drucken aus dem frühen 20. Jahrhundert erkennt kein Matching-Algorithmus, wenn er nur die fehlerhafte Ausgabe sieht.
Dasselbe Problem taucht bei Pfarrernamen auf. Mein Import aus dem Thüringer Pfarrerbuch lieferte Einträge wie ı75ı Schmeißer – das dotless-i der Frakturschrift, das Tesseract als Buchstabe liest statt als Ziffer. Oder 1553. Zimmermann, wo ein Jahrespunkt direkt an den Nachnamen klebte. Für den Algorithmus: valide Namen. Für mich: sofort erkennbare OCR-Artefakte. Ich kenne keine Pfarrer, die so hießen.
Fall 2: Vier Schreibweisen, zwei Orte
Dörnfeld auf der Heide und Dörnfeld an der Ilm – zwei verschiedene Orte in Thüringen, beide tatsächlich vorhanden. Im Quellenabgleich tauchen sie so auf: Dörnfeld a.d.H., Dörnfeld a.d.Ilm, Dörnfeld auf der Heide, Dörnfeld an der Heide. Vier Schreibweisen für zwei Orte, verteilt über vier Quellen.
Ein Algorithmus, der auf Zeichenähnlichkeit matcht, sieht vier fast-identische Strings und kollabiert sie zu einem Ort. Falsch. Ich weiß, dass es zwei sind – weil ich weiß, dass es in Thüringen häufig gleichnamige Dörfer gibt, die durch geografische Zusätze unterschieden werden. Das ist Geografie-Wissen, kein Muster im Text.
Fall 3: *Wanderleben* = *Wandersleben* – aber nicht offensichtlich
Wandersleben liegt im Kreis Gotha, im Gebiet der Drei Gleichen. Im Machholz von 1925 steht Wanderleben. Levenshtein-Distanz: 1. Eigentlich sollte das ein sicherer Match sein.
Das Problem: Es gibt im deutschen Sprachraum weitere Orte mit ähnlichem Namen. Und der Algorithmus weiß nicht, ob das eine historische Schreibvariante desselben Ortes ist oder ein anderer Ort. Ich weiß es – weil der Kontext stimmt. Machholz erfasst die Kirchenprovinz Sachsen, Wandersleben liegt in deren Gebiet, die umliegenden Einträge passen. Das ist Kontextwissen, kein Zeichenvergleich.
Fall 4: *Sundhausen*, *Elxleben* – gleichnamige Orte in Sichtweite
Goldbach gibt es in Thüringen zweimal, aber die beiden Orte liegen weit auseinander. Das gefährlichere Problem sind Namensdoppelungen, bei denen die Orte fast nebeneinander liegen.
Sundhausen zum Beispiel: Es gibt ein Sundhausen bei Gotha und ein Sundhausen bei Langensalza – beide im selben Kirchenkreisgebiet, keine 25 Kilometer voneinander entfernt. Wer dem Algorithmus einen Pfarrer aus dem Kirchspiel Sundhausen übergibt, bekommt im Zweifel den falschen Ort. Und der Fehler fällt erst auf, wenn man die Koordinaten auf der Karte prüft – oder weiß, dass es zwei davon gibt. Übrigens gibt es auch noch ein Sundhausen bei Nordhausen…
Noch enger liegt das Problem bei Elxleben: Auch hier gibt es zwei Orte, die in historischen Quellen auftauchen und deren Kirchspiele sich in den Quellenwerken berühren. Ein Algorithmus, der auf Namensgleichheit matcht, entscheidet sich nach Datenbankreihenfolge. Das Prinzip lautet „first match wins“. Ich entscheide mich nach Kirchspielkontext – welche Nachbarorte stehen in derselben Quellenzeile, welcher Superintendenturbezirk ist eingetragen, welches Archiv hat die Kirchenbücher?
Das ist kein exotisches Problem. In Thüringen gibt es dutzende Ortsnamen, die mindestens zweimal vorkommen. Der Algorithmus kennt keine davon – er kennt nur Strings.
Fall 5: Gotha bei Eilenburg – nicht das Gotha, das du meinst
Gotha gibt es zweimal. Die Residenzstadt des Herzogtums Sachsen-Gotha in Thüringen – und ein Dorf namens Gotha bei Eilenburg in Sachsen. Und Genealogen kennen natürlich auch „den Gotha“. Wer im GOV nach dem Standesamt Gotha sucht und dem ersten Treffer folgt, kann sich schnell im Kursächsischen wähnen, obwohl er Thüringen meint.
Die Archive des Herzogtums Sachsen-Gotha liegen in Gotha. Das sächsische Dorf Gotha bei Eilenburg hat damit nichts zu tun. Für einen Algorithmus, der auf Namensgleichheit matcht, sind beide Gotha – identische Strings, unterschiedliche Bedeutung. Ich erkenne die Verwechslung sofort: durch Territorialgeschichte, durch Koordinatenvergleich, durch den schlichten Gedanken „Gotha im Kursächsischen? Das kann nicht stimmen.“
Fall 6: Preußen mitten in Thüringen
Wandersleben und Mühlberg – beide im Kirchspiel-Kontext bei Machholz – gehören zur Kirchenprovinz Sachsen. Das bedeutet: preußisches Territorium, kirchlich der KPS unterstellt, nicht der Thüringischen Landeskirche.
Für einen Algorithmus, der einfach Ortsnamen abgleicht, ist das irrelevant. Er matcht Namen. Ob ein Ort 1925 preußisch oder thüringisch war, steht nicht im String. Ich habe es gewusst – und damit die falsche Zuordnung zu einem Thüringer Kirchenkreis vermieden. Nur kenne auch ich nicht jeden der über 3.000 Orte in Thüringen. Da gibt es sehr viel zwischen Wüstung und Großstadt.
Ein ähnliches Kontextproblem tritt bei Amtstiteln auf. Im Pfarrerbuch der Kirchenprovinz Sachsen tauchen Bezeichnungen wie Archidiaconus oder Subdiaconus auf – lateinische Titel, die im KPS-Gebiet gebräuchlich waren. In den Thüringer Pfarrerbüchern fehlen sie fast vollständig. Wer einen Algorithmus auf beide Quellenwerke loslässt, bekommt im besten Fall Lücken – im schlechtesten Fall die falsche Person an der falschen Stelle. Das Wissen, dass diese beiden Quellenwerke schlicht unterschiedliche Kirchenterminologien verwenden, liegt nirgendwo im Text.
Fall 7: „Schmiedefeld mit Vesser“ – ein Kirchenbuch, zwei Orte
In historischen Kirchenbüchern führten Hauptkirchen häufig die Eintragungen für ihre Filialen mit. Das Buch heißt dann nicht „Schmiedefeld“ – es heißt „Schmiedefeld mit Vesser“. Für einen Algorithmus, der Ortsnamen aus Kirchenbuch-Titeln extrahiert, ist das ein einzelner Ort. Einen Ort namens „Schmiedefeld mit Vesser“ gibt es nicht.
Im besten Fall ignoriert der Algorithmus den zweiten Namensteil. Im schlechtesten Fall legt er eine neue Entität an. Richtig wäre: beide Siedlungen als separate Orte erfassen und das Kirchenbuch beiden zuordnen. Aber das setzt voraus, dass man weiß, welcher der beiden Orte die Mutterkirche hatte und welcher die Filiale war – und dass man das Muster „X mit Y“ überhaupt als Kirchspiel-Hinweis liest. Das steht nicht im Titel. Es ist Strukturwissen über kirchliche Verwaltung.
Fall 8: Wüstungen – Orte, die es 2026 nicht mehr gibt
Im Pfarrerbuch der Kirchenprovinz Sachsen von 1820 tauchen Orte auf, die in keiner modernen Ortsdatenbank mehr stehen. Kein GOV-Eintrag, kein Treffer in der EKMD-Kirchenlandkarte. Der Algorithmus meldet: kein Match.
Stimmt – aber die richtige Schlussfolgerung ist nicht „Datenfehler“, sondern: der Ort ist eine Wüstung oder wurde seit 1820 vollständig eingemeindet. Den Unterschied zwischen einem falschen Ortsnamen und einem historisch aufgelösten Ort erkennt kein Matching-Algorithmus aus sich heraus. Ich erkenne ihn, weil ich weiß, dass meine Quelldaten von 1820 sind und meine Referenzdatenbank von 2026. Zweihundert Jahre sind eine lange Zeit für Dörfer und Städte in Thüringen.
Fall 9: Grenzorte – wenn zwei Quellen denselben Ort verschiedenen Kirchenkreisen zuweisen
Manche Orte lagen exakt auf der historischen Grenze zwischen Kirchenkreisen – oder die Grenzen haben sich zwischen den Quellenwerken verschoben. Der Güldenapfel von 1931 weist einen Ort einem Kirchenkreis zu, die EKMD-Kirchenlandkarte von 2026 einem anderen. Nicht weil eine der Quellen falsch ist, sondern weil sich kirchliche Verwaltungsgrenzen in neunzig Jahren verändert haben.
Ein Algorithmus, der blind einer einzigen Quelle vertraut, arbeitet korrekt – er ist nur falsch. Ich merke es, wenn ein Pfarrer plötzlich in zwei Kirchenkreisen gleichzeitig erscheint. Dann schaue ich nach, welche Quelle welches Jahr abbildet, und ordne manuell zu. Das lässt sich automatisieren – aber nur, wenn man das Problem überhaupt kennt. Und das Problem sieht man erst, wenn man mindestens zwei Quellen nebeneinanderlegt.
Warum das kein Problem der KI ist – und trotzdem eines
Ich mache es mir zu leicht, wenn ich sage: die KI ist halt nicht gut genug. Das stimmt, aber es ist nicht der Kern.
Der Kern ist, dass diese Art von Wissen strukturell schwer formalisierbar ist. Es ist nicht falsch im Quellenwerk – es ist korrekt, aber kontextabhängig. Zwei Orte mit demselben Namen sind korrekt benannt. Eine historische Schreibvariante ist korrekt transkribiert. Ein Tippfehler ist ein Tippfehler – aber ohne Kartenkenntnis ist er nicht als solcher erkennbar.
Algorithmen matchen auf Zeichenähnlichkeit. Menschen matchen auf Bedeutung. Das ist kein gradueller Unterschied, den man mit mehr Trainingsdaten überbrückt. Es ist ein anderer Ansatz.
Was das für deine Forschung bedeutet: Wenn du automatisierte Matching-Werkzeuge einsetzt – ob eigene Skripte, ChatGPT oder kommerzielle Dienste –, dann lies die Ergebnisse. Besonders die scheinbar sicheren Treffer. Die falschen Matches haben oft nicht weniger Ähnlichkeit als die richtigen. Sie sehen nur anders aus, wenn man die Karte kennt.
Wo hast du beim Quellenabgleich schon einmal einen Match bekommen, der falsch war – und den du nur durch Ortskenntnis oder historisches Wissen erkannt hast? Ich bin neugierig, welche Fälle euch begegnet sind.
