Eine KI-gestützte Pipeline zur automatischen Verknüpfung von Personen, Orten und Organisationen in TEI-XML-Registern mit Normdaten aus der Gemeinsamen Normdatei (GND) und Wikidata. Entwickelt für die Anforderungen frühneuzeitlicher und antiker Editionsprojekte.
Historische Editionen enthalten hunderte bis tausende Personen, Orte und Organisationen in ihren Registern. Die manuelle Zuordnung von Normdaten-Identifikatoren (GND, Wikidata) ist zeitaufwändig, fehleranfällig und erfordert Expertise in Normdaten-Recherche.
Die TEI-NER Pipeline automatisiert diesen Prozess: Sie durchsucht Wikidata und die GND nach passenden Kandidaten, bewertet sie anhand von Register-Metadaten (Notizen, Lebensdaten, Alternativnamen) und verifiziert die Zuordnungen mittels eines Large Language Models. Das Ergebnis: Normierte, maschinenlesbare TEI-Register mit vollständiger Provenienz-Dokumentation.
Parallele Suche in Wikidata und GND/LOBID. Sprach-Kaskade (Latein immer aktiv), SPARQL-Fallback. Externe Datenbanken: 6,5M Personen (persons.db) + 524K Orte (Places.db).
SPARQL-Batch-Preloading lädt Normdaten vor dem Pipeline-Lauf in lokalen SQLite-Cache. Phase 1 von ~40 Minuten auf ~30 Sekunden. Offline-Betrieb nach Preload möglich.
Single-Entity LLM-Verifikation mit ID-basierter Antwort. Qwen3.6-35B-A3B via vLLM/Swift (lokal, empfohlen), Gemma 4, Gemini 2.5 Flash (API) oder Mistral Small 3.2. Goldstandard-validiert: 100% Entity-Korrektheit (quellen-tolerant) über 4 Modelle.
Latein, Altgriechisch, Frühneuhochdeutsch, Französisch. Historische Schreibweisen erkennen (Phase 1.7 + Phase 2.7). Alt-Namen in Originalsprache durchsuchen.
Völker, Stämme, Dynastien im Personenregister erkennen. Drucker-Erben und Offizinen als Körperschaften behandeln.
"Karl der Große", "Friedrich der Weise", "Karl V. (Kaiser)" — Beinamen und Epitheta korrekt in GND-Namenskonvention übersetzen.
Multi-Signal-Scoring: Note-Keywords, Domänen-Boost, Geo-Kontext aus Corpus-Profil, Typ-Mismatch-Erkennung. SPARQL-Fallback für Gottheiten. Anachronismus-Erkennung im Code.
Interaktiver Report mit Suchfeld, Filtern, Confidence-Badges. GND/Wikidata-Links. Konflikte hervorgehoben. Export als CSV.
Jedes Pipeline-Element mit @resp und @cert. Editoriale IDs werden nie überschrieben. --crossref-editorial ermöglicht Kreuzreferenz auch für editorische IDs.
Ergebnisse als Fine-Tuning-Dataset exportieren. Kandidaten-Splitting, Stratifizierung. Gezieltes Training für Schwachstellen (Alt-Namen, Regionen, Kollektive). ChatML, Alpaca, Conversation.
Standard: Qwen3.6-35B-A3B via vLLM/Swift oder LM Studio-kompatibles Backend. Backend-Benchmarks zeigen 3,4s p50 im Single-Szenario und 75,9 Output-Token/s im Batch.
VERIFIED_NONE-Entities mit Kandidaten werden erneut per Schreibweisen-Analyse geprüft. Rettet Einträge, bei denen alle Kandidaten abgelehnt wurden.
Die Pipeline läuft als Docker-Container und kommuniziert mit externen APIs (Wikidata, GND/LOBID), externen Datenbanken (persons.db, Places.db) und einem LLM-Backend (lokal via LM Studio oder Cloud).
Die letzten lokalen Messungen trennen drei Fragen: Welches LLM-Backend liefert genügend Durchsatz für Verifikation, wie schlagen sich klassische NER-Modelle auf Neuss-Goldstandards, und ob hmBERT für Standoff-NER gegen ein lokales Qwen3.6-LLM bestehen kann.
Mehr Batch-Durchsatz im gemessenen Qwen3.6-35B-A3B-Szenario: 75,9 statt 11,4 Output-Token/s; p50-Latenz sinkt von 108,3s auf 22,9s.
Bestes Neuss-Ergebnis auf 121 Gold-Spans: hmBERT HIPE2020 erreicht 36,7% exact typed F1 und 74,1% relaxed overlap F1; spaCy liegt bei 21,1% / 59,3%.
hmBERT verarbeitet die 40-Gold-Span-Probe in 12,8s und erreicht 52,3% relaxed F1; Qwen3.6 lokal braucht 958,8s und erreicht 34,7%.
| Messung | System | Requests / Gold | Fehler | p50 / Sekunden | Output TPS | F1 |
|---|---|---|---|---|---|---|
| Backend Single | vLLM/Swift Qwen3.6 | 8 Requests | 0 | 3,41s | 63,3 | — |
| Backend Batch | vLLM/Swift Qwen3.6 | 24 Requests | 0 | 22,94s | 75,9 | — |
| Backend Batch | dflash Qwen3.6 | 24 Requests | 0 | 108,28s | 11,4 | — |
| Neuss NER | hmBERT HIPE2020 | 121 Gold | — | 4,86s | — | 36,7% exact · 74,1% relaxed |
| Neuss NER | spaCy de_core_news_lg | 121 Gold | — | 3,22s | — | 21,1% exact · 59,3% relaxed |
| Band 39d | hmBERT Standoff-NER | 40 Gold | — | 12,82s | — | 25,2% exact · 52,3% relaxed |
| Band 39d | Qwen3.6 Local LLM | 40 Gold | — | 958,76s | — | 21,3% exact · 34,7% relaxed |
benchmarks/results/20260427_*, shared-data/output/*_20260504*/summary.csv.
Exact = typed exact span F1; relaxed = overlap F1.
Von regelbasierter NER über Cloud-LLM-Verifikation zum lokalen Agentic Entity Linking.
| Modell | Architektur | Strikt | Tolerant | Fehler | Laufzeit |
|---|---|---|---|---|---|
| Qwen3-30B-A3B ★ | MoE 30B/3B | 93% | 100% | 0 | ~11 min |
| Gemma 4 26B-A4B | MoE 26B/4B | 94% | 99% | 1 | ~18 min |
| Gemini 2.5 Flash | Cloud API | 98% | 100% | 0 | ~8 min |
| Mistral Small 3.2 | Dense 24B | 93% | 98% | 2 | ~25 min |
| hmBERT v9 ⚡ | Encoder 110M | 91% | 94% | 6 | ~6 min |
dbmdz/bert-base-historic-multilingual-cased. ~900 MB statt 15–18 GB.--bert-linker: BERT ersetzt LLM komplett (91% strikt, 94% tolerant)--bert-prefilter: BERT reduziert Kandidaten, LLM verifiziert (Hybrid)
Aktuelle Pipeline-Architektur: Confidence-Router, Agentic Whitelisting, Entity-Search-Tool. Whitelisting vs. Blacklisting, Ergebnisse, technische Details.
Programmablaufplan der v6-Architektur: Corpus-Profiler, Normdaten-Suche, Filter & Scoring, LLM-Verifikation (Blacklisting), Kreuzreferenz.
Visuelle Darstellung des v6-Workflows. Datenflüsse, Mechanismen, Live-Beispiel (Echo).