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 Extraktionsweg auswählen. Sie bietet einen Ausgangspunkt, den Sie anhand Ihres Schemas, Ihrer Dokumente und Ihrer 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. Testen Sie einen Bi-Encoder, wenn viele Labels wiederverwendbare gecachte Embeddings nutzen können, oder einen Fine-Tuned Transformer Token Classifier, wenn gelabelte Beispiele vorhanden sind. Verwenden Sie LLM-basierte Structured Extraction, wenn Sie einen komplexen Datensatz statt einer einfachen Liste von Textspans benötigen.
Letzte Überprüfung: 2026-09-08. Auswahlkriterien: Label-Stabilität, Label-Inventar, Span- gegenüber Record-Output, Sprache, überwachte Daten, Latency, Normalisierung und Review-Kosten.
Entscheidungstabelle
| Bedarf | Bester Ausgangspunkt | Warum |
|---|---|---|
| Schnelles NER mit bekannten Labels | spaCy | Ausgereifte Pipelines, gute Ergonomie, schnelles CPU-Deployment und Integration von Rules. |
| Neue Labels ohne vollständiges Training | GLiNER | Label-konditionierte Extraktion 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 mit jedem Dokument erneut zu encoden. |
| Entities und Relations in einem Durchlauf | GLiNER-Relex candidate | Entity- und Relation-Typen werden gemeinsam extrahiert. Vergleichen Sie das Modell auf dem Ziel-Relation-Schema mit separaten Stufen. |
| Entities plus Dokumentfelder oder Klassifikation | GLiNER2 | Das Schema-Interface kombiniert Named Entity Recognition, Klassifikation 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 verschachtelte Spans mit Annotationen, die die erwarteten Überlappungsmuster enthalten. |
| Multilinguale oder Multi-Script-Extraktion | GLiNER-X oder XLM-R-Baseline | Kein Modell ist in jeder Sprache überlegen. Testen Sie jede Zielsprache und die Formulierung ihrer Typbeschreibungen. |
| Stabile Domain-Labels mit repräsentativen gelabelten Spans | Fine-Tuned Token Classifier oder spaCy-Pipeline | Erstellen Sie eine Supervised-Baseline und vergleichen Sie anschließend Exact-Span-F1, Latency und Kosten auf Ihrem Domain-Dataset. |
| Implizite, satzübergreifende oder strukturierte Felder | LLM oder hybrider Kandidat | Structured Outputs begrenzen die Antwortform, nicht die Korrektheit der Extraktion. Validieren Sie die Feldgenauigkeit auf einem Domain-Testset. |
| Hochrisiko-PII oder regulierter Workflow | 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-tauglich, Rule-aware | Benötigt Training oder Rules für Custom Labels | Bekannte Labels in High-Throughput-Systemen. |
| GLiNER | Flexible Labels zur Inference-Zeit | Qualität hängt von Label-Formulierung und Domain-Mismatch ab | Wechselnde Entity-Typen und seltene Labels. |
| GLiNER bi-encoder | Gegachte Label-Embeddings unterstützen große Typ-Inventare | Nutzen hängt von Label-Wiederverwendung und Workload-Form ab | Wiederverwendete Inventare mit Dutzenden bis Tausenden Labels. |
| GLiNER2 | Multi-Task-Schema-Extraktion | Jeder Task und das kombinierte Schema müssen weiterhin evaluiert werden | Entities, Klassifikation und strukturierte Felder. |
| GLiNER-Relex | Gemeinsame Entity- und Relation-Extraktion | Neueres Modell, das einen Task-spezifischen Vergleich erfordert | Explizite Entity-Relation-Schemas. |
| Transformer Token Classifier | Starke Supervised-Genauigkeit | Benötigt gelabelte Spans und Retraining | Stabile Domain-Extraktion mit ausreichenden Daten. |
| LLM-Extraktion | Schema-Flexibilität und Reasoning | Höhere Latency, Kosten und Non-Determinismus | Komplexe Records, implizite Werte und Workflows mit geringem Volumen. |
| Rules und Dictionaries | Deterministisches Matching-Verhalten | Spröde Recall | Compliance, IDs, Produktcodes und Post-Filter. |
So wählen Sie aus
Beginnen Sie mit dem Entity-Schema, nicht mit dem Modell.
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 vorher. Latency und Kosten hängen weiterhin von Modell, Hardware, Batch-Größe und Serving-Stack ab.
Wenn sich Labels wöchentlich ändern, verwenden Sie GLiNER oder einen LLM-Extractor, während sich das Set der Entity-Typen stabilisiert. Schreiben Sie für jedes mehrdeutige Label eine kurze Typbeschreibung. ZeroNER verwendet ausführlichere Typbeschreibungen und evaluiert ein strengeres Setting, in dem die Testtypen während des Trainings unbekannt sind. Beschreibungen können ein Label präzisieren; um Leakage zu vermeiden, müssen Trainings- und Testtypen getrennt werden. Ziel ist, zuerst zu verstehen, wie das Schema aussehen sollte, bevor Sie Annotation-Budget investieren.
Wenn Sie ein großes Label-Inventar wiederverwenden, evaluieren Sie einen Bi-Encoder, bevor Sie einen gemeinsamen Label-Text-Encoder einsetzen. Das GLiNER-bi-encoder-Paper berichtet bei gliner-bi-edge-v2.0 mit gecachten Label-Embeddings einen etwa 130-mal höheren Throughput als bei gliner_small-v2.5 mit 1.024 Labels. Der Vergleich wurde auf einer H100 GPU und mit Batch Size 1 durchgeführt; die Speed-Tests umfassten Inputs mit 64, 256 und 512 Tokens. Er zeigt, warum sich das Testen von Label-Wiederverwendung lohnt, nicht welchen Speedup Sie bei einem anderen Workload erwarten können.
Wenn Dokumente mehrere Sprachen umfassen, benchmarken Sie jede Zielsprache und jedes Script. OpenNER 1.0 stellte in seiner Sammlung mit 52 Sprachen fest, dass kein einzelnes Modell in allen Sprachen am besten war. 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 hybride Pipeline. LangExtract ist nützlich, wenn jede Extraktion auf ihre Quellposition zurückverweisen muss. NuExtract ist eine Self-Hosted-Option für multimodale Dokumentextraktion. Beide benötigen weiterhin eine Evaluation auf Feldebene mit den Zieldokumenten.
Viele Business-Extraction-Tasks sind kein reines NER. „Finden Sie die Parteien, Pflichten, das Wirksamkeitsdatum, die Kündigungsklausel und das anwendbare Recht“ ist Dokumentverständnis mit Entity-Feldern.
Verwenden Sie für PII ein PII-Framework wie Presidio als Integrations- und Redaction-Layer. Betrachten Sie GLiNER2-PII als Model-Kandidaten, nicht als Compliance-Entscheidung. Messen Sie den Recall für die sensiblen Formate, Sprachen und Dokumente, die das System verarbeiten wird.
Production-Pipeline
Eine Production-Extraction-Pipeline ergänzt das Modell häufig um weitere Stufen:
- Kandidatenextraktion: spaCy, GLiNER, Transformer-Modell, LLM, Rules oder eine Kombination.
- Optionale Normalisierung oder Entity Linking: Ordnen Sie Spans kanonischen IDs, Produktcodes, Users, Unternehmen oder Einträgen in Ihrem Domain-Vokabular zu.
- Validierung und Review: Verwerfen Sie unmögliche Labels, erzwingen Sie Schema-Constraints, deduplizieren Sie Spans und leiten Sie unsichere Fälle an das 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 Aktien-Ticker gemeint ist, und ihn anschließend einer stabilen ID zuordnen.
Evaluations-Checkliste
Messen Sie mehr als Entity-Level-F1:
- Exact-Span-F1
- Relaxed-Span-F1
- Label-Confusion-Matrix
- Umgang mit verschachtelten Entities
- Genauigkeit der Entity-Normalisierung
- Sensitivität gegenüber Typbeschreibung und Label-Sprache
- Slices nach Sprache, Script und Dokumentformat
- False Positives pro Label
- Confidence Calibration
- Latency und Kosten pro Dokument
- Rate menschlicher Korrekturen
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 andernfalls 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-Extraktion.
- ZeroNER-Paper – harte Zero-Shot-Evaluation mit Typbeschreibungen.
- OpenNER-1.0-Paper – multilinguale, Multi-Ontology-NER-Evaluation.
- LangExtract – Source-Grounded LLM-Extraktion.
- NuExtract – Self-Hosted-Multimodal-Extraktion.
- Presidio – Framework für PII-Erkennung und Anonymisierung.
- GLiNER2-PII-Paper – multilingualer PII-Model-Kandidat.
- spaCy-Dokumentation zu Named Entities
- Hugging-Face-Leitfaden zur Token-Klassifikation
- OpenAI-Leitfaden zu Structured Outputs