Die besten NER-Modelle 2026: spaCy, GLiNER, Transformers, LLMs
Automatische Übersetzung Dieser Artikel wurde automatisch aus der englischen Originalversion übersetzt.
Named Entity Recognition (NER) findet und labelt Textspans, etwa Personen, Unternehmen und Produktcodes. Diese Seite richtet sich an Engineers, die für einen Production-Workload einen Extraction-Ansatz auswählen. Sie bietet einen Ausgangspunkt, den Sie gegen Ihr Schema, Ihre Dokumente und Ihre betrieblichen Rahmenbedingungen testen können.
Verwenden Sie spaCy für stabile Labels und schnelle Pipelines. Wählen Sie GLiNER, wenn sich Labels häufig ändern, einen Bi-Encoder, wenn ein großes Label-Inventar gecachte Embeddings wiederverwenden kann, oder einen Fine-Tuned Transformer Token Classifier, wenn gelabelte Beispiele vorhanden sind. Verwenden Sie LLM-basierte Structured Extraction, wenn Sie statt einer einfachen Liste von Spans einen komplexen Datensatz benötigen.
Letzte Prüfung: 17.08.2026. Auswahlkriterien: Label-Stabilität, Label-Inventar, Span- versus Record-Output, Sprache, Supervised Data, Latency, Normalisierung und Review-Kosten.
Entscheidungstabelle
| Bedarf | Bester Ausgangspunkt | Warum |
|---|---|---|
| Schnelle NER mit bekannten Labels | spaCy | Ausgereifte Pipelines, gute Ergonomie, schnelle CPU-Deployments und Integration von Regeln. |
| Neue Labels ohne vollständiges Training | GLiNER | Label-Conditioned Extraction funktioniert gut, wenn sich das Label-Set ändert. Beginnen Sie mit klaren Typbeschreibungen statt mit bloßen Namen. |
| Großes, wiederverwendbares Label-Inventar | GLiNER Bi-Encoder | Label-Embeddings können vorab berechnet und gecacht werden, statt die Labels für jedes Dokument zu encoden. |
| Entities und Relations in einem Durchlauf | GLiNER-Relex Candidate | Extrahiert Entity- und Relation-Typen gemeinsam. Vergleichen Sie das Modell auf dem Ziel-Relation-Schema mit getrennten Stufen. |
| Entities plus Dokumentfelder oder Classification | GLiNER2 | Die Schema-Schnittstelle kombiniert Entity Recognition, Classification und Structured-Extraction-Tasks. |
| Verschachtelte oder überlappende Entities | Nested-fähiger Decoder, einschließlich GLiNER mit flat_ner=False | Flat Decoding unterdrückt Überlappungen. Testen Sie Nested-Spans anhand von Annotationen mit den erwarteten Überlappungsmustern. |
| Multilinguale oder Multi-Script-Extraction | GLiNER-X oder XLM-R-Baseline | Kein Modell ist in jeder Sprache überlegen. Testen Sie jede Zielsprache sowie die Formulierung ihrer Typbeschreibungen. |
| Stabile Domain-Labels mit repräsentativen gelabelten Spans | Fine-Tuned Token Classifier oder spaCy-Pipeline | Etablieren Sie eine Supervised-Baseline und vergleichen Sie dann Exact-Span-F1, Latency und Kosten auf Ihrem Domain-Dataset. |
| Implizite, satzübergreifende oder strukturierte Felder | LLM oder Hybrid Candidate | Structured Outputs begrenzen die Antwortform, nicht die Korrektheit der Extraction. Validieren Sie die Feldgenauigkeit auf einem Domain-Testset. |
| Kritische PII- oder regulierte Workflows | Presidio plus GLiNER2-PII Candidate | Kombinieren Sie Model-Output mit deterministischen Checks, Redaction Controls und Review. |
Tool-Klassen
| Klasse | Stärke | Schwäche | Geeignet für |
|---|---|---|---|
| spaCy NER | Schnell, Production-friendly, Rule-aware | Für Custom Labels sind Training oder Regeln erforderlich | Bekannte Labels in High-Throughput-Systemen. |
| GLiNER | Flexible Labels zur Inference-Zeit | Qualität hängt von Label-Formulierung und Domain-Mismatch ab | Schnelle Ontology-Iteration und Long-Tail-Labels. |
| GLiNER Bi-Encoder | Gecachte Label-Embeddings skalieren große Ontologien | Der Nutzen hängt von Label-Reuse und Workload-Struktur ab | Wiederverwendete Inventare mit Dutzenden bis Tausenden Labels. |
| GLiNER2 | Multi-Task-Schema-Extraction | Jeder Task und das kombinierte Schema müssen weiterhin evaluiert werden | Entities, Classification und strukturierte Felder. |
| GLiNER-Relex | Gemeinsame Entity- und Relation-Extraction | Neueres Modell, das einen Task-spezifischen Vergleich erfordert | Explizite Entity-Relation-Schemas. |
| Transformer Token Classifier | Hohe Supervised Accuracy | Benötigt gelabelte Spans und Retraining | Stabile Domain-Extraction mit ausreichender Datenmenge. |
| LLM Extraction | Schema-Flexibilität und Reasoning | Höhere Latency, Kosten und Non-Determinismus | Komplexe Records, implizite Werte und Workflows mit geringem Volumen. |
| Regeln und Dictionaries | Deterministisches Matching-Verhalten | Spröde Recall | Compliance, IDs, Produktcodes und Post-Filters. |
Auswahl des passenden Ansatzes
Beginnen Sie mit dem Entity-Schema, nicht mit dem Model.
Wenn Labels stabil sind und repräsentative Beispiele vorliegen, Fine-Tunen Sie einen Token Classifier. Vergleichen Sie ihn auf einem zurückgehaltenen Domain-Testset. Er sagt Token-Labels ohne autoregressive Generation voraus. Latency und Kosten hängen weiterhin von Model, Hardware, Batch-Größe und Serving-Stack ab.
Wenn sich Labels wöchentlich ändern, verwenden Sie GLiNER oder einen LLM Extractor, während sich die Ontologie stabilisiert. Schreiben Sie für jedes mehrdeutige Label eine kurze Typbeschreibung. Aktuelle Hard-Zero-Shot-NER-Forschung zeigt, dass Beschreibungen die Generalisierung verbessern und verhindern, dass Label Leakage als Zero-Shot-Fähigkeit interpretiert wird. Ziel ist es, zunächst zu verstehen, wie das Schema aussehen sollte, bevor Sie Annotation-Budget investieren.
Wenn Sie ein großes Label-Inventar wiederverwenden, evaluieren Sie zunächst einen Bi-Encoder statt eines Joint Label-Text Encoders. Das GLiNER-Bi-Encoder-Paper berichtet 61,5 Micro-F1 auf CrossNER. Unter den H100-Testbedingungen des Papers wird bei 1.024 Labels mit vorab berechneten Embeddings außerdem ein bis zu 130-fach höherer Throughput berichtet. Diese Ergebnisse zeigen ein Scaling-Verhalten. Sie sind keine Schätzung für einen anderen Production-Workload.
Wenn Dokumente mehrere Sprachen umfassen, benchmarken Sie jede Zielsprache und jedes Script. OpenNER 1.0 fand in seiner Sammlung mit 52 Sprachen kein einzelnes Modell, das überall am besten abschnitt. Testen Sie sowohl englische als auch lokalisierte Typbeschreibungen, da der Label-Text Teil des Model-Inputs ist.
Wenn der Output ein strukturierter Record statt Spans ist, verwenden Sie ein LLM mit Structured Outputs oder eine Hybrid-Pipeline. LangExtract ist nützlich, wenn jede Extraction auf ihre Source-Position zurückverweisen muss. NuExtract ist eine Self-Hosted-Option für multimodale Dokument-Extraction. Beide benötigen weiterhin eine Evaluation auf Feldebene mit den Zieldokumenten.
Viele Business-Extraction-Tasks sind keine reine NER. „Finde die Vertragsparteien, Pflichten, das Wirksamkeitsdatum, die Kündigungsklausel und das anwendbare Recht“ ist Document Understanding mit Entity-Feldern.
Für PII sollten Sie ein PII-Framework wie Presidio als Integrations- und Redaction-Layer einsetzen. Behandeln Sie GLiNER2-PII als Model Candidate, nicht als Compliance-Entscheidung. Messen Sie den Recall für die sensiblen Formate, Sprachen und Dokumente, die das System verarbeiten soll.
Production-Pipeline
Eine Production-Extraction-Pipeline ergänzt das Model häufig um zusätzliche Stufen:
- Candidate Extraction: spaCy, GLiNER, Transformer Model, LLM, Regeln oder eine Kombination.
- Optionale Normalisierung oder Entity Linking: Mappen Sie Spans auf kanonische IDs, Produktcodes, User, Unternehmen oder Ontology-Einträge.
- Validation und Review: Verwerfen Sie unmögliche Labels, erzwingen Sie Schema-Constraints, deduplizieren Sie Spans und leiten Sie unsichere Fälle an ein Review weiter.
Normalisierung macht extrahierten Text zu nutzbaren Produktdaten. Den Span „Apple“ zu finden, ist nur der erste Schritt. Das System muss weiterhin entscheiden, ob damit das Unternehmen, die Frucht, eine Produktfamilie oder ein Stock-Ticker gemeint ist, und ihn anschließend auf eine stabile ID mappen.
Eval-Checkliste
Messen Sie mehr als Entity-Level-F1:
- Exact-Span-F1
- Relaxed-Span-F1
- Label-Confusion-Matrix
- Umgang mit Nested Entities
- Genauigkeit der Entity-Normalisierung
- Sensitivität gegenüber Typbeschreibungen und Label-Sprache
- Slices nach Sprache, Script und Dokumentformat
- False Positives pro Label
- Confidence Calibration
- Latency und Kosten pro Dokument
- Human-Correction-Rate
Halten Sie das Testset von Schema-Design und Threshold-Tuning getrennt. Berichten Sie die Anzahl der Dokumente und Entity-Mentions pro Label. Verwenden Sie Confidence-Intervalle auf Dokumentebene, wenn wiederholte Mentions in einem Dokument sonst die Sicherheit künstlich erhöhen würden.
Weiterführende Lektüre
- NER Guide 2026 behandelt Encoder, LLMs und die dreistufige Production-Architektur.
- Schema-Guided Reasoning ist relevant, wenn NER zu Structured Extraction wird.
Referenzen
- GLiNER-Dokumentation
- GLiNER-Bi-Encoder-Paper – gecachte Label-Embeddings für große Inventare.
- GLiNER2-Dokumentation
- GLiNER-Relex-Paper – gemeinsame Entity- und Relation-Extraction.
- ZeroNER-Paper – Hard-Zero-Shot-Evaluation mit Typbeschreibungen.
- OpenNER-1.0-Paper – multilinguale NER-Evaluation über mehrere Ontologien.
- LangExtract – Source-Grounded LLM Extraction.
- NuExtract – Self-Hosted multimodale Extraction.
- Presidio – Framework für PII Detection und Anonymisierung.
- GLiNER2-PII-Paper – multilingualer PII Model Candidate.
- spaCy-Dokumentation zu Named Entities
- Hugging-Face-Leitfaden zur Token Classification
- OpenAI-Leitfaden zu Structured Outputs