Hybrid Agentic Entity Linking · April/Mai 2026
Warum lokale LLMs mit dem klassischen Ansatz scheitern — und wie Whitelisting das löst.
Das LLM bekommt einen langen System-Prompt (~5.000 Tokens) mit Regeln, Projekt-Kontext und vorgefertigten Kandidaten. Es soll entscheiden: MATCH oder NONE.
Problem: Lokale Modelle (Gemma 4) werden skeptisch und lehnen im Zweifel alles ab. Je länger der Prompt, desto mehr NONE.
Das LLM bekommt nur Name + Note (~50 Tokens) und Kandidaten als Vorschläge. Es wählt aktiv den besten Match und kann selbst in der DB nachsuchen.
Effekt: Konstruktive Aufgabenstellung. Das LLM sucht die Lösung statt Fehler zu finden.
Dreistufig: Code entscheidet → Agent wählt → NONE nur bei echtem Datenmangel.
Analysiert das Korpus und generiert einen minimalen Projekt-Kontext (1 Zeile statt 5.000 Tokens).
36 Sprachen, 26 Epochen, Regionen, Korrespondenz-Netzwerk. Optional mit LLM-Analyse.
persons.db (11,8M Personen) und Places.db (524K Orte) werden VOR der API konsultiert. Spart 95% der API-Calls.
Sprach-Kaskade (Latein immer aktiv), SPARQL-Fallback nur wenn DB nichts findet. Multi-Signal-Scoring: Note-Keywords, Domänen-Boost, Anachronismus-Filter.
Code entscheidet autonom basierend auf dem Scoring-Ergebnis. Kein LLM nötig.
Beispiele die der Router allein löst: Aristoteles (1 klarer Treffer), Helvetier (Score 1.0), Hesperus (einziger Kandidat).
Das LLM bekommt Kandidaten als Vorschläge (nicht zum Prüfen) und kann selbst in der DB suchen. Minimaler System-Prompt (~50 Tokens).
Das Entity-Search-Tool sucht in persons.db / Places.db mit automatischer Stoppwort-Bereinigung und Occupation-Boost für biblische/mythologische Einträge.
Schreibt verifizierte IDs ins TEI-XML mit Provenienz-Attributen (@resp, @cert). 3-Stufen-Kreuzreferenz ergänzt fehlende GND/Wikidata-IDs. HTML-Report mit Suchfeld und Filtern.
Antike Orte (Mykene, Arkadien, Phthia), Flüsse (Lahn, Weser), biblische Stätten (Sodom, Ninive), moderne Städte (Wien, Nürnberg). Einziger Ausfall: „römisch“ (Adjektiv, kein Ort).
Reformatoren (Calvin, Zwingli), Kirchenväter (Augustinus), mythologische Figuren (Eurydike, Alkmaion), Kaiser (Karl V., Maximilian I.), Völker (Helvetier, Franke).
Messstand aus den lokalen Runs vom 27. April und 4. Mai 2026.
Im Batch-Szenario erreicht vLLM/Swift 75,9 Output-Token/s gegenüber 11,4 bei dflash. Gleichzeitig sinkt die p50-Latenz von 108,3s auf 22,9s. Alle gemessenen Requests wurden ohne Fehler abgeschlossen.
| Backend | Szenario | Requests | Req/s | Output TPS | p50 | p95 |
|---|---|---|---|---|---|---|
| vLLM/Swift | single | 8 | 0,288 | 63,3 | 3,41s | 3,70s |
| vLLM/Swift | batch | 24 | 0,345 | 75,9 | 22,94s | 24,40s |
| vLLM/Swift | continuous | 64 | 0,332 | 73,1 | 48,53s | 49,33s |
| dflash | single | 8 | 0,092 | 20,3 | 6,96s | 21,20s |
| dflash | batch | 24 | 0,052 | 11,4 | 108,28s | 150,68s |
tei-ner-pipeline/benchmarks/results/20260427_*. Batch-Konfigurationen unterscheiden sich in der Parallelität (dflash 6, vLLM/Swift 8).Auf Neuss-Goldstandard und Band-39d-Probe erreicht hmBERT die besseren F1-Werte als spaCy bzw. ein lokales Qwen3.6-LLM. Besonders deutlich ist der Laufzeitunterschied auf Band 39d: 12,8s gegenüber 958,8s.
| Datensatz | System | Gold | Pred | Sek. | Exact typed F1 | Relaxed F1 |
|---|---|---|---|---|---|---|
| Neuss | hmBERT HIPE2020 | 121 | 173 | 4,86 | 36,7% | 74,1% |
| Neuss | spaCy de_core_news_lg | 121 | 230 | 3,22 | 21,1% | 59,3% |
| Band 39d | hmBERT Standoff-NER | 40 | 71 | 12,82 | 25,2% | 52,3% |
| Band 39d | Qwen3.6 Local LLM | 40 | 35 | 958,76 | 21,3% | 34,7% |
shared-data/output/hmbert_neuss_ner_eval_20260504/summary.csv, spacy_neuss_ner_eval_20260504/summary.csv, neuss_band39d_*_20260504/eval/summary.csv.Domänenspezifischer Encoder für historisches Entity-Linking — 94% LLM-Qualität bei 20× geringerem Ressourcenbedarf.