NER-Leitfaden 2026: GLiNER, spaCy, Transformers und LLMs

Viacheslav Dubrov

2026-04-02 · Aktualisiert 2026-08-17 · 31 Min. · Retrieval- und Sprachsysteme

Automatische Übersetzung Dieser Artikel wurde automatisch aus der englischen Originalversion übersetzt.

Named Entity Recognition (NER) umfasst inzwischen kompakte Encoder, Open-Vocabulary-Modelle und LLM-basierte Extraktion. In der zitierten CrossNER-Evaluation übertrifft ein GLiNER-Modell mit 300M Parametern den berichteten Zero-Shot-F1-Wert von UniNER-13B. Ein neuerer Bi-Encoder erreicht bei 1.024 Entity Types, deren Labels vorab berechnet wurden, bis zu den 130-fachen Throughput des vergleichbaren gliner_small-v2.5 Uni-Encoders. Das Paper maß dies auf einer einzelnen H100 mit Batch Size 1 für Inputs mit 64, 256 und 512 Tokens. Diese Ergebnisse sprechen für Experimente, nicht für ein allgemeingültiges Production-Ranking.

Das begleitende Repository enthält ausführbare Beispiele für GLiNER, den ONNX-Export, von LLMs generierte Training Labels und Structured Extraction. Für Workloads, die hauptsächlich aus expliziten Spans bestehen, sind kompakte Encoder meist die schnellere und günstigere Option. LLMs bleiben nützlich, um Training Data zu erzeugen und Fälle zu verarbeiten, die Inference oder Normalisierung erfordern.

Dieser Leitfaden richtet sich an Engineers, die NER-Architekturen für RAG-, Agent-, Dokument- oder Privacy-Pipelines auswählen und evaluieren. Am Ende verfügen Sie über einen Model-Selection-Pfad, einen begrenzten Evaluation-Plan und ein dreistufiges Design zur Kombination von Encodern mit LLM-Extraktion.

Begleitendes Repo: ner-field-guide mit ausführbaren Demos für GLiNER, ONNX-Export, die LLM-as-Teacher-Pipeline und Structured Extraction mit Instructor.

Den kurzen Model-Vergleich finden Sie unter Best NER Models in 2026.

Was ist Named Entity Recognition?

Named Entity Recognition findet Spans in Texten und weist ihnen Types wie Person, Organisation, Datum, Produkt oder domänenspezifische Labels zu. NER identifiziert die Mention. Entity Linking ist der separate Schritt, der eine Mention einem kanonischen Datensatz oder einem Ontology-Konzept zuordnet.

Wo moderne Systeme NER einsetzen

NER findet weiterhin Text-Spans und weist ihnen Labels zu. Verändert hat sich seine Position im System. Heute liefert NER Filter für RAG, Structured Arguments für Agent Tools und Felder für Document-Processing-Pipelines. Dadurch werden Latency, Kosten und Schema-Flexibilität ebenso wichtig wie Benchmark Accuracy.

RAG: besserer Retrieval durch Entity Extraction

Similarity Search allein hat Schwierigkeiten, wenn eine Frage exakte Entities enthält. Bei „what did Anthropic say about model safety in Q4 2024?“ sollte das System „Anthropic“ und „Q4 2024“ als Metadata Filter extrahieren, statt sich ausschließlich auf Embeddings zu stützen.

Beim Indexing extrahieren Sie Entities aus jedem Chunk und speichern sie als Metadata: {"organizations": ["Anthropic"], "dates": ["Q4 2024"], ...}. Dadurch können Sie vor dem Vector Search nach Entities filtern. Knowledge-Graph-RAG (GraphRAG, LlamaIndex Property Graphs) geht weiter: NER plus Relation Extraction erstellt einen Graphen, der Multi-Hop-Fragen beantworten kann, bei denen flache Embeddings nicht ausreichen.

Zur Query-Zeit steuern aus der Nutzerfrage extrahierte Entities das Routing. Eine Frage mit einem Unternehmensnamen geht an einen Finance Index, eine Frage mit Medikamentennamen an eine Clinical Knowledge Base. GLiNER ist nützlich, wenn sich das Schema oder die Entity Types zur Query-Zeit ändern. Unbekannte Unternehmens- oder Medikamentennamen allein erfordern keine Open-Vocabulary-Labels; ein Closed-Label-Model kann neue Mentions bekannter Types weiterhin erkennen.

AI Agents: Text in strukturierte Fakten umwandeln

Agents erhalten unstrukturierten Text wie Webseiten, API Responses und User Messages. NER wandelt diesen Text in strukturierte Fakten um, über die der Agent Reasoning ausführen, die er speichern oder an Tools übergeben kann.

Für das Tool Routing erfordert eine Anfrage wie „schedule a meeting with Sarah Chen from Accenture on Thursday at 2pm“ vor dem Aufruf der Calendar API PERSON: Sarah Chen, ORGANIZATION: Accenture und DATETIME: Thursday 2pm. Ein lokaler Encoder vermeidet den API Round Trip und ist oft deutlich schneller. Die Latency hängt jedoch von Model, Runtime, Hardware, Batch Size und Label Count ab. Messen Sie beide Pfade auf dem Calendar Workload, statt von einer festen Differenz in Millisekunden auszugehen.

NER unterstützt außerdem Entity Tracking über mehrere Conversations hinweg. Agent-Memory-Systeme müssen erkennen, dass „Sarah“ in Turn 3 und „Ms. Chen“ in Turn 12 dieselbe Person sind. NER identifiziert die Spans; Entity Linking ordnet sie derselben ID zu.

Die Einschränkung ist in beiden Fällen die Latency. Wenn jeder von zehn sequentiellen Schritten einen NER Call mit 200 ms ausführt, verursachen diese NER Calls eine wahrgenommene Verzögerung von 2 Sekunden. Ein einzelner Call benötigt 200 ms. Encoder-Modelle integrieren Entity Work meist besser in Agent Loops als LLM-basierte Extraktion.

Document Intelligence: von Bildern zu strukturierten Daten

OCR wandelt Bilder in Text um. NER wandelt diesen Text in strukturierte Felder um.

Eine Standard-Pipeline verwendet zunächst OCR, etwa Tesseract, Azure Document Intelligence oder AWS Textract, um Text und Bounding Boxes zu erzeugen. NER extrahiert anschließend Felder wie invoice_number, vendor_name, line_items, total und due_date. Die gleiche Sequenz gilt für Verträge, medizinische Akten und regulatorische Einreichungen.

Moderne Document-Pipelines können Layout Understanding, Entity Extraction und Relation Extraction kombinieren. OCR oder ein Layout-aware Document Model liefert weiterhin Text, Lesereihenfolge, Tabellen und Bounding Boxes. GLiNER 2 kann anschließend Entity, Relation, Classification und hierarchische Structured Extraction über diesen Text in einem Schema-driven Pass kombinieren.

Die Kosten entscheiden über die meisten dieser Pipelines. Kalkulieren Sie Ihre tatsächlichen monatlichen Dokumentenvolumina einschließlich Retries und Review. Ein kompakter Encoder kann auf der CPU laufen, während ein API-basiertes LLM pro Dokument zusätzliche Inference-Kosten und Latency verursacht. Ein praktikabler Test besteht darin, einen repräsentativen Rechnungsdatensatz mit einem LLM zu labeln. Fine-Tunen Sie GLiNER auf den geprüften Datensätzen und vergleichen Sie anschließend beide Pfade anhand von Field-Level F1, Latency und Gesamtkosten.

PII Detection und LLM Guardrails

Die Datenschutzprinzipien und Sicherheitsanforderungen der DSGVO (Artikel 5, 25 und 32), die technologieneutrale Security Rule von HIPAA (HHS Guidance) sowie Kaliforniens CCPA in der durch CPRA geänderten Fassung schreiben unterschiedliche Rechte und risikobasierte Schutzmaßnahmen vor. Die zitierten Bestimmungen schreiben weder NER noch eine bestimmte Pre-Model-Scanning-Architektur vor. Dies ist keine Rechtsberatung. Lassen Sie die für Ihre Daten und Jurisdiktion geltenden Anforderungen von einer Rechtsberatung prüfen. NER kann Data Inventory, Minimierung oder De-Identification unterstützen, ist jedoch nur ein einzelner Control, dessen Recall für die relevanten Daten und die betreffende Jurisdiktion validiert werden muss.

NER kann dies direkt übernehmen. De-Identification-Modelle finden Spans wie PERSON, SSN, PHONE, EMAIL und ADDRESS und schwärzen sie oder ersetzen sie durch synthetische Äquivalente. Microsoft Presidio kombiniert Recognizers mit Anonymization Operators; die Beispiele enthalten GLiNER als Recognizer. Das 0.3B-Parameter-Modell GLiNER2-PII ist ein weiterer Kandidat: Das Paper behandelt 42 PII Types auf Character-Span-Auflösung. Keines der beiden Modelle ist ein Compliance-Nachweis. Validieren Sie den Recall vor dem Einsatz eines Detectors als Control nach Datenformat, Jurisdiktion, Sprache und PII-Klasse.

In einem von John Snow Labs durchgeführten Anbietervergleich mit 48 von Experten annotierten Open-Source-Dokumenten aus sechs PHI-Klassen wurde bei der Token-Level-Evaluation ein F1 von 96 % berichtet. Für Azure wurden 91 %, für AWS 83 % und für GPT-4o 79 % angegeben. Die Studie bildete Provider-Labels auf ihr Ground-Truth-Schema ab und schloss nicht abbildbare Predictions aus. Betrachten Sie sie als engen Provider-Vergleich, nicht als Compliance-Nachweis. Ein separater Deployment-Bericht beschreibt die Verarbeitung von mehr als 100.000 klinischen Notizen pro Tag durch Providence.

Für LLM Guardrails kann NER als Pre-Screening Layer dienen: Scannen Sie User Input auf PII, bevor Sie ihn an eine externe API senden, und blockieren oder anonymisieren Sie ihn anschließend. Das kann schneller oder einfacher sein, als das LLM zur Selbstmoderation aufzufordern. Behandeln Sie dies als Deployment-Hypothese: Messen Sie beide Pfade auf Ihrem Model, Ihrer Hardware, Ihrem Input Mix und Ihrem Recall Target. False Negatives bleiben möglich. Ergänzen Sie daher einen weiteren Control für die PII-Exposure, die Ihr System nicht akzeptieren kann. GLiNER ist hier besonders nützlich, weil PII-Kategorien je nach Jurisdiktion variieren. Sie können unter einer neuen Regulierung neue Entity Types wie „genetic information“ hinzufügen, ohne neu zu trainieren.

GLiNER: Span-to-Label Matching für Open-Vocabulary NER

GLiNER (NAACL 2024, Zaratiana et al.) machte Encoder-basierte NER zu einem Bruchteil der Kosten konkurrenzfähig zu LLMs. Statt NER als Sequence Labeling oder Text Generation zu behandeln, modelliert GLiNER es als Matching-Problem. Das Model bewertet jeden potenziellen Text-Span – jede zusammenhängende Wortfolge wie „Bill Gates“ oder „Microsoft“ – gegen jeden Entity-Type-Label und behält die Paare mit hohen Scores.

Das Model erhält Entity-Type-Labels und Input Text als eine gemeinsame Sequenz: [ENT] person [ENT] organization [ENT] date [SEP] Bill Gates founded Microsoft.... Ein bidirektionaler Transformer (DeBERTa-v3) encodiert alles gemeinsam.

Aus dem Output erstellt das Model zwei Mengen von Representations. Eine repräsentiert Entity Types anhand der Token-Positionen [ENT]. Die andere repräsentiert Text-Spans, indem sie Start- und End-Token-Vektoren durch ein kleines FFN kombiniert. Ein Dot Product zwischen einer Span Representation und einer Entity-Type Representation ergibt einen Score.

Wenden Sie Sigmoid an, erhalten Sie die Probability, dass der Span von Token $i$ bis Token $j$ zum Entity Type $t$ gehört: $\phi(i, j, t) = \sigma(S_{ij}^T \cdot q_t)$. Dabei ist $S_{ij}$ der vom FFN erzeugte Span Vector und $q_t$ das Entity-Type-Embedding des entsprechenden [ENT] Tokens (Zaratiana et al., 2024, Gleichungen 1–2). Spans werden auf 12 Tokens begrenzt, um die Verarbeitung schnell zu halten.

GLiNER akzeptiert natürliche Label-Beschreibungen zur Inference-Zeit, ohne dass ein Retraining erforderlich ist. Die Extraction Quality hängt jedoch von der Formulierung der Labels und ihrer Passung zur Domäne ab. Sie übergeben Entity Types wie „person“, „adverse drug reaction“ oder „financial instrument“, und das Model bewertet Spans gegen diese Types. Die folgenden Konfigurationen mit 50M, 90M und 300M stammen aus den Originalmodellen des Papers. Die aktuelle Model Card für v2.1 listet dagegen englische Checkpoints mit 166M, 209M und 459M sowie einen multilingualen Checkpoint mit 209M, alle unter Apache 2.0. Vergleichen Sie Latency oder Memory dieser Generationen nicht so, als wären die Parameternamen identisch (GLiNER v2.1 Model Card).

Für einen echten Hard-Zero-Shot-Test müssen sowohl Ziel-Types als auch Zielbeispiele zurückgehalten werden. Eine Type Description wie „a medically confirmed adverse effect caused by a treatment“ liefert dem Model mehr Informationen als allein adverse event. Das garantiert keinen Transfer, doch Description-driven ZeroNER übertraf Name-only-Baselines auf Benchmarks mit zurückgehaltenen Types (Cocchieri et al., 2025).

Die Trainingsdaten des Originalmodells stammten aus dem Dataset Pile-NER: 44.889 Passages mit 240K Entity Spans aus 13K Entity Types, alle von ChatGPT gelabelt. Das Training von GLiNER-L dauerte auf einer einzelnen A100 etwa 5 Stunden (Zaratiana et al., 2024).

Benchmark-Ergebnisse

Zero-Shot-Ergebnisse aus Zaratiana et al. (2024), Tabellen 1 und 2:

GLiNER-M mit 90M Parametern erreicht im CrossNER-Table des Papers nahezu UniNER-13B (55,4 % gegenüber 55,6 % F1) und verwendet dabei etwa 140-mal weniger Parameter. GLiNER-S mit 50M übertrifft das berichtete ChatGPT-Ergebnis (GPT-3.5) um 5 F1-Punkte. Die multilinguale Variante, die ausschließlich auf englischen Daten trainiert wurde, übertrifft dieselbe ChatGPT-Baseline in 8 von 10 nicht-englischen Sprachen (Zaratiana et al., 2024). Diese Vergleiche verwenden die Model-Versionen und den Evaluation Harness des Papers; sie begründen kein Ranking gegenüber neueren LLMs.

GLiNER-Varianten decken biomedizinische Texte, PII Detection, News und multilingualen Support ab.

Aus scripts/01_gliner_quickstart.py:

from gliner import GLiNER

model = GLiNER.from_pretrained("urchade/gliner_medium-v2.1")
text = "Bill Gates founded Microsoft on April 4, 1975."
labels = ["person", "organization", "date"]
entities = model.predict_entities(text, labels, threshold=0.5)

for entity in entities:
    print(f"  {entity['text']} => {entity['label']}")
# Bill Gates => person
# Microsoft => organization
# April 4, 1975 => date

Wie sich GLiNER mit spaCy vergleicht

spaCy ist eine der etabliertesten NLP-Libraries in Production. Die Architektur unterliegt jedoch anderen Constraints als GLiNER.

Die spaCy-Pipelines (en_core_web_sm, en_core_web_trf) verwenden Closed-Vocabulary NER: ein festes Set von Entity Types (PERSON, ORG, GPE, DATE usw.), das zur Trainingszeit definiert wird. Sie möchten einen neuen Entity Type hinzufügen? Dann sammeln Sie gelabelte Daten und trainieren neu. Verwenden Sie das gepflegte 3.8 Model Package, statt eine unveröffentlichte Major-Version als Production-Upgrade anzunehmen. Die en_core_web_trf 3.8.0 Model Card berichtet 90,19 NER F1 auf OntoNotes 5.0, allerdings nur für die 18 vordefinierten Types (spaCy Model Card).

GLiNER verwendet Open-Vocabulary NER: Jedes Label funktioniert zur Inference-Zeit, ohne dass Retraining erforderlich ist. Das macht GLiNER zur besseren Wahl, wenn Entity Types im Voraus unbekannt sind, sich häufig ändern oder domänenspezifisch sind („adverse drug reaction“, „financial instrument“, „threat indicator“).

Meine Empfehlung: Verwenden Sie spaCy für Standard-Entity-Types, für die Pretrained Pipelines gut validiert sind. Verwenden Sie GLiNER, wenn Sie flexible Zero-Shot-Types benötigen oder wenn sich Ihre Pipeline ohne Retraining anpassen muss. Beide können sich eine Pipeline teilen: spaCy übernimmt Tokenization und Sentence Splitting, GLiNER die Entity Extraction.

Eine überwachte Transformer-Baseline

Beginnen Sie bei stabilen Labels und repräsentativen annotierten Spans mit einem Fine-Tuned Token Classifier wie RoBERTa oder DeBERTa als Supervised Baseline. Dieser tauscht Label-Flexibilität gegen Task-spezifische Accuracy. Vergleichen Sie ihn mit spaCy und GLiNER anhand von Exact-Span-F1, Recall pro Label, Calibration, Latency und Kosten auf demselben Domain Set.

UniNER und NuNER: Wie klein kann man werden?

UniNER (ICLR 2024, Zhou et al.) und NuNER (EMNLP 2024, Bogdanov et al.) destillieren beide LLM-Annotations in kleinere NER-Modelle – sie unterscheiden sich jedoch darin, wie klein diese Modelle werden können.

UniNER: der maximalistische Ansatz

UniNER fine-tunt LLaMA-7B/13B auf 45.889 Input-Output-Paaren, die von ChatGPT generiert wurden. Für jeden Entity Type beantwortet das Model die Frage „What describes [type] in the text?“ und gibt JSON-Listen aus. Ein wichtiger Training Trick: Frequency-based Negative Sampling erhöht den F1-Wert von 31,5 % auf 53,4 % (Zhou et al., 2024).

UniNER-7B erreicht 41,7 % Zero-Shot-F1 über 43 Datasets und übertrifft ChatGPTs 34,9 % um 7 Punkte. Die 13B-Variante erreicht 43,4 % – nur 1,7 Punkte mehr bei nahezu doppeltem Compute (Zhou et al., 2024).

Der Production Trade-off: Das UniNER-Type-Setup mit höherem Score fragt jeden Entity Type sequenziell ab. Die All-in-One-Variante verwendet eine Response, lag aber im Durchschnitt 3,3 % niedriger. Bei FP16 benötigt ein 7B-Checkpoint allein für die Weights ungefähr 14 GB; niedrigere Bitbreiten bei der Quantization können diesen Footprint reduzieren. Das Model steht außerdem unter einer restriktiven CC-BY-NC-4.0-Lizenz.

NuNER: der minimalistische Ansatz

NuNER startet mit RoBERTa-base (125M Parameter) und verwendet Contrastive Training mit 4,38 Millionen GPT-3.5-Annotations über 200K Concepts. Nach dem Training wird der Concept Encoder entfernt; der Text Encoder kann in jeder Standard-NER-Pipeline als RoBERTa-Ersatz eingesetzt werden (Bogdanov et al., 2024).

NuNER übertrifft einfaches RoBERTa über alle Few-Shot-Größen hinweg um 6–15 F1-Punkte. Mit nur einem Dutzend Beispielen pro Entity Type erreicht NuNER das Niveau von UniNER-7B, obwohl es 56-mal kleiner ist (Bogdanov et al., 2024).

Beide Papers unterstützen die Destillation von LLM-Annotations in kleinere NER-Modelle. NuNER zeigt, dass ein Encoder mit 125M Parametern das berichtete UniNER-7B-Ergebnis erreichen kann, wenn task-spezifische Fine-Tuning-Daten verfügbar sind – bei MIT-Lizenz und CPU-freundlicher Inference.

GLiNER 2: ein Model, vier Tasks

Das ursprüngliche GLiNER-Ökosystem verteilte NER, Relation Extraction, Classification und Document-Level Extraction auf mehrere Modelle. Das GLiNER2-Paper aus EMNLP 2025 vereinte NER, Classification und hierarchische Extraction in einem Model mit 205M Parametern. Aktuelle Releases haben später Relation Extraction an dieselbe Schema-Schnittstelle angebunden.

Die Architektur behält das Cross-Encoder-Design bei, erweitert den Context auf 2.048 Tokens (das Vierfache des Originals) und ergänzt deklarative Schemas zur Definition von Extraction Tasks. Für das Training wurden 135.698 reale Dokumente mit GPT-4o annotiert sowie 118.636 synthetische Beispiele verwendet (Zaratiana et al., 2025).

Auf CrossNER im Zero-Shot-Setting erreicht GLiNER 2 0,590 F1 und liegt damit nahe an GPT-4o mit 0,599 im Mid-2025-Benchmark des Papers. Bei Classification liegt der Durchschnitt über 7 Benchmarks bei 0,72, gegenüber 0,69 für DeBERTa-v3-large. Auf der CPU berichtet das Paper eine Classification-Latency von 130–208 ms über die getesteten Label Counts. Die DeBERTa-Baseline steigt von 1.714 ms bei 5 Labels auf 16.897 ms bei 50 Labels (Zaratiana et al., 2025).

from gliner2 import GLiNER2
extractor = GLiNER2.from_pretrained("fastino/gliner2-base-v1")

# Multi-task composition in ONE forward pass
schema = (extractor.create_schema()
    .entities({"person": "Names of people", "company": "Organization names"})
    .classification("sentiment", ["positive", "negative", "neutral"])
    .relations(["works_for", "founded", "located_in"])
    .structure("product_info")
        .field("name", dtype="str")
        .field("price", dtype="str"))
text = "Acme launched a $19 widget in Berlin."
results = extractor.extract(text, schema)

Aktuelle GLiNER2-Releases stellen Entity Recognition, Classification, hierarchische Extraction und Relation Extraction über ein gemeinsames Schema bereit. Das EMNLP-Paper evaluiert NER und Classification; es berichtet keinen Benchmark für hierarchische Extraction und deckt die spätere Relation API nicht ab. Betrachten Sie den Four-Task-Pfad als Deployment-Fähigkeit, die Sie benchmarken müssen, nicht als Beleg dafür, dass ein Model die Accuracy von vier spezialisierten Modellen beibehält.

Ergänzungen für 2026: Wählen Sie die Architektur passend zum Bottleneck

Das GLiNER-Ökosystem umfasst inzwischen verschiedene Architekturen. Sie sind Kandidaten für einen Domain-Vergleich, keine gemeinsame Rangliste.

Das ursprüngliche GLiNER-Paper, das Bi-Encoder-Paper und GLiNER-Relex verwenden jeweils eigene Modelle und Harnesses. Die Model Cards von GLiNER-X und GLiNER Decoder beschreiben veröffentlichte Checkpoints, sind jedoch kein Peer-Reviewed- und vergleichbarer Benchmark. Halten Sie diese Unterscheidung in einem Architecture Decision Record fest.

Checkpoint-Lizenzen gehören zur Model-Auswahl

Prüfen Sie vor dem Deployment die genauen Bedingungen für Code, Weights und Datasets. Die aktuell zitierten Releases sind nicht austauschbar:

Lizenzangaben sind keine Rechtsberatung. Ein Production Review muss Base-Model-, Training-Data- und Provider-Bedingungen einschließen.

Der Bi-Encoder: NER auf Millionen von Labels skalieren

GLiNER encodiert Labels und Text gemeinsam. Joint Encoding wird zunehmend teurer, weil Label-Text Context verbraucht und für jedes Dokument erneut encodiert werden muss. Der Crossover hängt von Checkpoint, Label Descriptions und Hardware ab. Wenn dasselbe große Type Inventory in vielen Dokumenten wiederverwendet wird, sollte der GLiNER Bi-Encoder der Standardvergleich sein. Er teilt Text- und Label-Encoding auf zwei separate Transformer auf (Stepanov et al., 2026).

Der Text Encoder verwendet ModernBERT (Ettin-Familie), der Label Encoder Sentence Transformers (BGE oder MiniLM). Spans und Labels werden per Dot Product bewertet. Durch diese Trennung können Entity-Type-Embeddings einmal vorab berechnet und gecacht werden. Zur Inference muss nur der Text encodiert werden; die Label-Seite wird zu einem Cache Read.

Vier Model-Größen sind verfügbar, alle auf CrossNER gebenchmarkt (Stepanov et al., 2026, Tabelle 1):

Bei 1.024 Entity Types verliert der vorab berechnete gliner-bi-edge-v2.0 Bi-Encoder gegenüber einem einzelnen Label nur 5,2 % Throughput (19,3 → 18,3 Ex/s). Der vergleichbare gliner_small-v2.5 Uni-Encoder verliert 98,7 % (10,7 → 0,14 Ex/s). In den Single-H100-Tests des Papers mit Batch Size 1 über Inputs mit 64, 256 und 512 Tokens erreicht der vorab berechnete Bi-Encoder einen bis zu 130-fachen Throughput-Vorteil gegenüber gliner_small-v2.5. Bei 100 Entity Types verarbeitet der Bi-Encoder auf einer einzelnen H100 1,96 Millionen Predictions pro Tag, gegenüber 368.000 beim Cross-Encoder (Stepanov et al., 2026).

Auch die Accuracy bleibt konkurrenzfähig. Bi-Encoder-large erreicht 61,5 % CrossNER F1 und liegt damit knapp vor den 60,9 % des Cross-Encoders. Die Autoren empfehlen bi-base-v2.0 (194M) als Sweet Spot: 98 % der Accuracy des Large-Modells bei 2,6-fachem Speed (Stepanov et al., 2026).

from gliner import GLiNER

model = GLiNER.from_pretrained("knowledgator/gliner-bi-base-v2.0")

# Pre-compute embeddings for massive label sets — encode once, use forever
entity_types = ["person", "organization", "date"]  # Can be thousands or millions
entity_embeddings = model.encode_labels(entity_types, batch_size=8)

# Inference only encodes text — labels are a cached lookup
outputs = model.batch_predict_with_embeds(texts, entity_embeddings, entity_types)

Zu den Applications gehören Biomedical NER gegen die UMLS-Ontologie (mehr als 4M Concepts), Enterprise-Taxonomien, die sich ohne Model-Retraining weiterentwickeln, und Entity Linking über das begleitende GLiNKER-Framework.

LLMs als Teacher: eine $70-Fallstudie und eine deploybare Pipeline

Das LLM-as-Teacher-Muster trennt teure Annotation von günstigerer Inference. Zwei veröffentlichte Fallstudien zeigen, wie Teams es unter unterschiedlichen Bedingungen eingesetzt haben.

Die CFM-Fallstudie

In einer Hugging-Face-Fallstudie extrahierte Capital Fund Management Unternehmensnamen aus etwa 900.000 Financial-News-Headlines. Zero-Shot-GLiNER erreichte 87,0 % F1. Das Team verwendete Llama 3.1-70B, um den Dataset in ungefähr 8 Stunden für etwa $70 zu annotieren, und prüfte anschließend in weiteren 8 Stunden 2.714 Samples über Argilla.

Das Fine-Tuning von GLiNER auf diesen Daten erreichte in der Fallstudie 93,4 % F1, verglichen mit 92,7 % beim Llama-70B-Teacher. Die Autoren berichten $0,10 pro Stunde auf der CPU für das Fine-Tuned Model und $8 pro Stunde für den Teacher (CFM-Fallstudie). Diese Zahlen beschreiben eine einzelne Financial-News-Aufgabe und ein bestimmtes Infrastructure Setup.

Die Studie von Refuel AI

Der Technical Report von Refuel AI benchmarkt LLM Labeling über 8 NLP-Datasets, darunter CoNLL-2003. Für GPT-4 (März 2023) berichtet er in seinem Setup 88,4 % Übereinstimmung mit Ground Truth und 86,2 % für menschliche Annotatoren, außerdem ein 20-mal schnelleres und 7-mal günstigeres Labeling. Das Ensemble routet einfache Beispiele an günstigere Models und schwierige Beispiele an GPT-4 und erreicht in den berichteten Experimenten mehr als 95 % Übereinstimmung (Technical Report von Refuel AI). Betrachten Sie diese Ergebnisse als vendor-reported Results unter dem Annotation Protocol dieser Studie.

Eine Production-Pipeline

Ein praktikabler Production Flow umfasst sechs Schritte:

1. Schreiben Sie Annotation Guidelines in natürlicher Sprache
2. Erstellen Sie Human-Labeled Validation- und Held-Out-Test-Sets, deren Größe sich aus Entity Prevalence, Slice-Anforderungen pro Label und der gewünschten Breite des Confidence Intervals ergibt. Ein Pilot mit 50–200 Dokumenten kann die Guidelines kalibrieren, ist aber keine standardmäßige Größe für eine Production Evaluation.
3. Verwenden Sie ein LLM mit versioniertem Prompt und explizitem Output Schema, um umfangreiche Training Data zu labeln; speichern Sie Model-Version, Prompt und Quelltext zusammen mit jedem Label
4. Prüfen Sie eine Teilmenge über Argilla oder Label Studio
5. Fine-Tunen Sie einen kompakten Encoder (GLiNER, SpanMarker, RoBERTa)
6. Deployen Sie nur, wenn der Encoder den Quality Gate erfüllt und die gemessenen Gesamtkosten senkt. CFM berichtete in seinem Setup stündliche Infrastructure-Kosten, die 16–80-mal niedriger waren; berücksichtigen Sie in Ihrem Vergleich Annotation, Review, Serving und Retraining.

Das LLM kann das Volumen manueller Annotation reduzieren. Das Team bleibt jedoch für Validation Set, Annotation Guidelines, gezieltes Review und Error Analysis verantwortlich.

Wo GLiNER scheitert und LLMs weiterhin nützlich sind

Der Sease-Benchmark (Oktober 2025) verglich GLiNER mit GPT-4.1-mini auf 30 Query-Parsing-Tasks. GPT-4.1-mini erreichte 100 % vollständig korrekte Ergebnisse. GLiNER erreichte 53 % (16 von 30). GLiNER antwortete jedoch in 0,08 Sekunden gegenüber 1,21 Sekunden beim LLM – also 15-mal schneller.

In diesem 30-Task-Benchmark scheiterte GLiNER in drei wiederkehrenden Mustern:

1. Implizite Entities: „event“ aus „Elton John performed at Madison Square Garden“ extrahieren – im Text steht nicht wörtlich „event“, aber das LLM schließt auf „concert“
2. Sensitivität gegenüber Label-Formulierungen: „2022“ erreicht gegen „date“ einen Score von 0,388, gegen „year“ jedoch 0,958 – kleine Label-Änderungen verursachen große Score-Schwankungen
3. Value Mapping: GLiNER gibt den exakten Surface Text („family houses“) statt des kanonischen Werts („Single family house“) zurück. Ein LLM kann diese Normalisierung durchführen, wenn Prompt und Schema die Zielwerte definieren.

Verschachtelte und überlappende Entities

GLiNER verwendet standardmäßig Flat Decoding, das überlappende Spans unterdrückt. Seine API unterstützt außerdem flat_ner=False, sodass verschachtelte Predictions möglich sind. Die Quality hängt jedoch von Checkpoint, Labels und Domain Data ab. Benchmarken Sie beide Decoding-Modi auf einem Span-Level-Testset mit verschachtelten Entities, bevor Sie ein spezialisiertes Model auswählen.

Verwenden Sie GLiNER für explizite Entity Extraction und routen Sie Fälle, die Inference, Reasoning oder Mapping auf vordefinierte Ontologies erfordern, an ein LLM. Der Routing Threshold sollte aus einem gelabelten Domain Set abgeleitet werden.

NER evaluieren: Metrics, Fallstricke und Test Sets

Ein Model kann auf einem kuratierten Test Set 95 % F1 erreichen und nach dem Deployment trotzdem auf dem tatsächlichen Document Mix scheitern. Erstellen Sie das Evaluation Set aus der Production Distribution und behalten Sie Slices für seltene Formate und Entity Types, die der aggregierte F1 verbergen kann.

Die zentralen Metrics

• Entity-Level-F1: Die Standard-Metric. Eine Prediction ist nur korrekt, wenn sowohl Span-Grenzen als auch Type exakt mit Ground Truth übereinstimmen. Dies berichten die meisten Papers.
• Token-Level-F1: Bewertet jeden Token einzeln. Diese Metric überschätzt Ergebnisse, weil das korrekte Erkennen eines Großteils einer langen Entity teilweise angerechnet wird. Bevorzugen Sie Entity-Level-F1.
• Precision vs. Recall: Diese haben oft asymmetrische Kosten. Bei De-Identification ist Recall wichtiger – einen Namen zu übersehen ist schlimmer als zu viel zu redigieren. Bei Database Extraction ist Precision wichtiger – False Entries verfälschen nachgelagerte Analysen.

Häufige Evaluation-Fallstricke

1. Überschätzung durch Partial Matches: „Bill“ wird extrahiert, obwohl das Gold-Label „Bill Gates“ lautet – manche Scripts zählen dies als Partial Match. Verwenden Sie Exact-Span-Matching, sofern es keinen Grund dagegen gibt.
2. Type Confusion: „Microsoft“ wurde korrekt als Span erkannt, aber mit PERSON statt ORG gelabelt und sollte daher mit null bewertet werden. Prüfen Sie, ob Ihr Evaluation Code dies korrekt behandelt.
3. Test-Set-Leakage: Wenn Test-Entities mit Training-Entities überlappen, werden Scores überschätzt. Zero-Shot-Benchmarks wie CrossNER und Few-NERD testen Generalization.
4. Unkontrollierte Label Prompts: Ein kurzer Type Name und eine getestete Type Description sind unterschiedliche Inputs. Versionieren Sie Label Descriptions, Thresholds, Checkpoint-Revisions und Decoding Mode zusammen mit dem Score.
5. Zero-Shot-Claims in nur einer Sprache: Leiten Sie multilingualen Quality nicht aus Englisch ab. OpenNER umfasst 36 Corpora und 52 Sprachen; seine Baselines zeigten, dass kein einzelnes Model in jeder Sprache am besten ist (Palen-Michel et al., 2025). In FiNERweb-Experimenten veränderte der Wechsel von englischen zu zielsprachlichen Labels den F1-Wert je nach Setting um 0,02–0,09 (Golde et al., 2026). Testen Sie beide Label-Sprachen, wenn das Produkt lokale Terminologie verwendet.
6. Ein Run ist ein Urteil: Berichten Sie, soweit relevant, Variationen über Random Seeds, Threshold Sweeps und wiederholte Production Samples. Kleine Slice Counts machen ein Model-Ranking instabil.

Ein Domain Test Set erstellen

Für Production Evaluation empfehle ich:

1. Aus Production Data sampeln, nicht aus kuratierten Beispielen. Beziehen Sie die unordentlichen Dokumente ein, die Ihr Model tatsächlich sehen wird.
2. Das Test Set auf die benötigte Schätzung auslegen. Wählen Sie die Anzahl aus Entity Prevalence, Slice-Größen pro Label und der gewünschten Breite des Confidence Intervals. Berichten Sie Bootstrap- oder analytische Confidence Intervals.
3. Mindestens zwei Annotators für ein Calibration Subset einsetzen. Schlichten Sie Disagreements und berichten Sie ein span-aware Agreement-Maß. Agreement diagnostiziert Ambiguität und die Qualität der Guidelines; es ist keine Obergrenze für Model Performance.
4. Nach Schwierigkeit stratifizieren – einfache Fälle (sauberer Text, Standard-Types) und schwierige Fälle (ambige Entities, Jargon, verrauschter Text).
5. Privacy- und Fairness-Slices beibehalten. Berichten Sie bei PII den Recall nach PII Type, Sprache, Locale, Dokumentformat und relevanten demografischen oder Name-Origin-Slices. Minimieren Sie den Zugriff der Evaluators auf unveränderten sensiblen Text, setzen Sie Retention Limits und prüfen Sie False Negatives.

Continual NER benötigt ein unveränderliches Regression Set

Production-Taxonomien ändern sich. Fügen Sie neue Types hinzu, ohne die Bedeutung alter Types unbemerkt zu verändern. Bewahren Sie ein versioniertes, unveränderliches Regression Set für bestehende Types, ein separates Test Set für den neuen Type und ein Changelog für Änderungen an Annotation Guidelines auf. Berichten Sie Scores für alte und neue Types getrennt, bevor Sie einen Checkpoint ersetzen. So erkennen Sie Forgetting und Taxonomy Drift am einfachsten.

Production NER in vier Branchen

Dies sind ausgewählte Industry Examples mit konkreten Zahlen unter den jeweils berichteten Bedingungen. Die Quellen umfassen vendor-reported Comparisons, von Unternehmen oder Projekten berichtete Case Studies sowie Peer-Reviewed Papers oder Preprints. Betrachten Sie sie als praktische Beispiele, nicht als Maturity Ranking.

Healthcare

John Snow Labs bietet Clinical-Entity-Modelle, die auf ICD-10, SNOMED CT, LOINC und RxNorm abgebildet sind. In seinem vendor-reported Vergleich mit 48 Dokumenten und sechs Klassen wurden bei der Token-Level-Evaluation 96 % F1 berichtet, gegenüber 91 % für Azure, 83 % für AWS und 79 % für GPT-4o. Der Vergleich bildete Labels neu ab und schloss nicht abbildbare Predictions aus. Eine separate Provider-Reported Case Study beschreibt Providence St. Joseph Health bei der Verarbeitung von 100.000–500.000 klinischen Notizen täglich.

In seinem 2025-Projektbericht berichtet das Open-Source-OpenMed-Projekt über mehr als 380 Biomedical-NER-Modelle, 29,7 Millionen Hugging-Face-Downloads und führende Ergebnisse auf 10 von 12 öffentlichen Biomedical-Benchmarks.

Financial NER

Der zentrale Use Case ist die Extraktion aus SEC Filings. John Snow Labs’ Finance NLP extrahiert mehr als 11 Entity Types aus 10-K-/10-Q-Filings (Adressen, Ticker, Geschäftsjahre, Börsen). Peer-Reviewed-Varianten von FinBERT-MRC erreichen bei Financial-Entity-Tasks 0,87–0,93 F1. Die schwierigen Punkte sind lange Dokumente und verschachtelte Entities in komplexen Finanzinstrumenten.

E-Commerce

Peer-Reviewed Papers berichten, dass WalMarts EAMT-System (KDD 2023) auf 965 Millionen Queries mit etwa 60 Entity Labels trainiert wird und in A/B-Tests einen GMV-Lift von 0,51 % erzielt. Home Depots TripleLearn-Framework (AAAI 2021) steigerte NER F1 durch iteratives Training von 69,5 auf 93,3.

Cybersecurity

Das Peer-Reviewed-iACE-System (CCS 2016) verarbeitete 71.000 Artikel aus 45 Security Blogs und extrahierte 900K OpenIOC-Items mit 95 % Precision und über 90 % Coverage. Ein Project Report zu modernen Systemen wie CyNER beschreibt die Kombination von DeBERTa (F1 >91 %) mit Regex-basierten IOC-Heuristiken. Der CyberNER-Preprint harmonisiert in seinem Unified Dataset von 2025 vier Datasets zu 21 STIX-2.1-aligned Entity Types; RoBERTa erreicht dabei 0,736 F1.

Deployment-Optimierung: von Python zu Inference mit geringerer Latency

Das begleitende Repo demonstriert den GLiNER-ONNX-Export und INT8 Packaging. Es erfasst Artifact-Größen, reproduziert aber nicht die von externen Projekten berichteten Latency- oder F1-Werte.

Native GLiNER Serving

Bevor Sie zu einer neuen Runtime wechseln, testen Sie den Ray-Serve-Pfad des Projekts. gliner[serve] bietet Dynamic Batching, Memory-aware Batch Sizing, Multi-Replica Scaling und einen HTTP Client. Damit kann sich der Queueing Overhead eines Multi-User-Services reduzieren, während derselbe Model Code erhalten bleibt. Benchmarken Sie Queue Latency, Warm Latency, Throughput und Exact-Span-F1 unter Ihrem Request Mix, bevor Sie ONNX oder Rust vergleichen.

ONNX-Export

GLiNER unterstützt native ONNX Conversion; außerdem sind vor-convertierte Models auf Hugging Face verfügbar (onnx-community/gliner_small-v2.1). Messen Sie die Latency gegenüber demselben PyTorch-Checkpoint, mit identischer Batch Size, Hardware und Warm-up-Protokoll.

Aus scripts/02_onnx_export.py:

# Export with quantization
# python convert_to_onnx.py --model_path model/ --save_path onnx/ --quantize True

# Load the exported ONNX model
from gliner import GLiNER
model = GLiNER.from_pretrained("path/to/model", load_onnx_model=True)

entities = model.predict_entities(text, labels, threshold=0.5)

INT8 Quantization

Dynamic Quantization kann Storage- und Memory-Anforderungen eines ONNX-Models reduzieren. Die Auswirkungen auf Latency und F1 pro Label hängen von Checkpoint und CPU ab. Das Export Script liefert daher Packaging Evidence, aber keinen Deployment Benchmark.

from onnxruntime.quantization import quantize_dynamic, QuantType

# Quantize weights dynamically, then evaluate the result
quantize_dynamic("gliner.onnx", "gliner_int8.onnx", weight_type=QuantType.QInt8)

gline-rs: Rust-Reimplementation

gline-rs (Apache 2.0) entfernt die Python Runtime aus dem Inference Path. Sein Token-Mode-Benchmark v0.9.0 auf einem Intel i9 mit drei Labels berichtet 6,67 Seq/s gegenüber 1,61 bei Python; für die RTX 4080 werden 248,75 Seq/s angegeben. Dies sind die eigenen Bedingungen des Projekts und keine vom begleitenden Repo reproduzierten Ergebnisse. Es unterstützt Span- und Token-Models, GPU/NPU über ONNX Runtime und ist als Crate auf crates.io verfügbar.

use gliner::{GLiNER, TokenMode, Parameters, RuntimeParameters, TextInput};

let model = GLiNER::<TokenMode>::new(
    Parameters::default(), RuntimeParameters::default(),
    "tokenizer.json", "model.onnx")?;

let input = TextInput::from_str(
    &["My name is James Bond."], &["person", "vehicle"])?;
let output = model.inference(input)?;
// => "James Bond" : "person" (99.7%)

Das Package fast-gliner stellt Python Bindings über PyO3 bereit.

Was die Optimization Evidence abdeckt

Structured Extraction: native Schemas, Instructor und lokale Decoders

Wenn Sie mehr Flexibilität benötigen als Encoder-Models bieten – etwa implizite Entities, Reasoning oder Ontology Mapping –, beginnen Sie mit dem nativen Schema-Mechanismus des Providers. OpenAI unterstützt Strict json_schema Response Formats, Anthropic Structured Outputs unterstützt JSON Outputs und Strict Tool Inputs, und die Gemini API unterstützt eine Teilmenge von JSON Schema. Ein gemeinsames Pydantic- oder Zod-Model kann den Contract beschreiben, doch jeder Provider akzeptiert eine andere Schema-Teilmenge und zeigt ein anderes Verhalten bei Refusals und Complexity.

Schema Conformance macht Parsing zuverlässig. Sie beweist jedoch nicht, dass ein extrahierter Span im Source Text vorkommt oder dass ein normalisierter Wert korrekt ist. Validieren Sie Field Values, bewahren Sie nach Möglichkeit Offsets oder Quotations und bewerten Sie die semantische Accuracy auf einem gelabelten Set.

Instructor kapselt Provider Clients mit Pydantic Validation und optionalen Retries nach Validation Failures.

Angepasst aus dem Instructor Pattern in scripts/05_structured_extraction.py:

import instructor
from pydantic import BaseModel
from typing import List, Literal
from openai import OpenAI

class Entity(BaseModel):
    name: str
    label: Literal["PERSON", "ORGANIZATION", "LOCATION"]

class ExtractEntities(BaseModel):
    entities: List[Entity]

client = instructor.from_openai(OpenAI())
result = client.chat.completions.create(
    model="gpt-5.4-mini", temperature=0.0,
    response_model=ExtractEntities,
    messages=[{"role": "user", "content": "BioNTech SE acquired InstaDeep in the U.K."}])
# entities=[Entity(name='BioNTech SE', label='ORGANIZATION'), ...]

Outlines von dottxt verfolgt einen anderen Ansatz: Constrained Token Generation durch Finite-State Machines. Der Decoder maskiert Tokens, die gegen die Ziel-Grammar verstoßen würden, statt erst auf einen Validation Failure zu warten und zu retrien. Eine AWS-Übersicht nennt 98 % Schema Adherence gegenüber 76 % bei Post-Generation Validation. Sie wiederholt separat die Behauptung von .txt Engineering, dass der Ansatz durch seine Coalescence bis zu 5-mal schnellere Generation ermöglicht; die Seite veröffentlicht nicht genug Methodik, um beide Werte als einen kontrollierten Benchmark zu behandeln.

import outlines
from transformers import AutoModelForCausalLM, AutoTokenizer

model_id = "microsoft/Phi-3-mini-4k-instruct"
model = outlines.from_transformers(
    AutoModelForCausalLM.from_pretrained(model_id),
    AutoTokenizer.from_pretrained(model_id),
)
result = model(
    "Extract entities from: BioNTech SE acquired InstaDeep in the U.K.",
    ExtractEntities,
)

LangExtract ist nützlich, wenn ein generiertes Feld im Source verankert sein muss: Es liefert Character Intervals und unterstützt Hosted- oder lokale LLM-Backends. Für Self-Hosted Document Extraction wandelt NuExtract JSON Schemas in Templates um und umfasst Multimodal Document Models. Betrachten Sie beide als Structured-Extraction-Systeme, nicht als automatische Ersatzlösungen für Span NER. Ihre Anforderungen an Felder, Offsets, Document Layout und Latency benötigen eigene Tests.

Die Wahl hängt davon ab, wo Sie Ihre Models ausführen. Native Schemas sind der reibungsärmste Pfad für einen unterstützten Provider. Instructor ergänzt eine Provider-agnostic Pydantic Validation- und Retry-Layer. Outlines beschränkt lokale Generation anhand eines Schemas. LangExtract priorisiert Source Grounding, während NuExtract auf Self-Hosted Document Extraction zielt. Alle LLM-Pfade umfassen weiterhin autoregressive Generation. Benchmarken Sie jeden Pfad gegen einen Encoder mit derselben Batch Size, Hardware, Entity-Schema und Semantic-Accuracy-Rubric.

Die dreistufige Production-Architektur

Ich würde Production-NER nach der Form der Aufgabe routen, nicht nach einem einzelnen Model-Ranking.

Tier 1: Encoder-Models für explizite Spans. Verwenden Sie einen GLiNER Cross-Encoder für ein kleines Type Inventory. Wenn ein großes Inventory wiederverwendet wird, vergleichen Sie den Bi-Encoder mit gecachten Type Embeddings. Fine-Tunen Sie über die LLM-as-Teacher-Pipeline und deployen Sie anschließend mit Native Serving, ONNX, INT8 oder gline-rs – aber nur, wenn dieser Pfad den Domain Benchmark besteht.

Tier 2: Multi-Task- oder Relation Extraction. Wenn eine Anfrage NER, Classification und hierarchische Felder benötigt, testen Sie das gemeinsame Model mit 205M Parametern von GLiNER2. Wenn die zentrale Anforderung gemeinsame Spans plus Relations sind, testen Sie GLiNER-Relex. Das GLiNER2-Paper berichtet eine CPU Classification Latency von 130–208 ms über die getesteten Label Counts; dies ist kein Beleg für die spätere Relation API oder ein anderes Deployment.

Tier 3: LLMs für Reasoning-intensive Extraction. Routen Sie implizite Entities, kontextuelle Inference und Ontology Mapping an eine native Schema API oder Instructor für Cloud APIs sowie an Outlines für lokalen Constrained Output. Verwenden Sie LangExtract, wenn Source Intervals wesentlich sind, und NuExtract, wenn das Dokument selbst der Input ist. Loggen Sie diese Fälle, da sie Kandidaten für das nächste Tier-1-Training Set sind.

Die CFM Case Study liefert eine Kostenreferenz für Tier 1: 93,4 % F1 bei berichteten $0,10 pro Stunde auf der CPU, gegenüber 92,7 % F1 und $8 pro Stunde für den Llama-70B-Teacher. Berechnen Sie diesen Vergleich mit Ihrer Hardware, Ihrem Teacher Model, Ihrem Label Set und Ihren Review-Kosten neu.

Trade-offs und Limitationen

Bei jedem der folgenden Trade-offs sind die entscheidenden Fragen, wo er sichtbar wird und ob Sie ihn vor dem Deployment messen können.

Fehler des LLM-as-Teacher propagieren sich. Wenn das LLM einen bestimmten Entity Type regelmäßig falsch erkennt (z. B. Tochtergesellschaften mit Muttergesellschaften verwechselt), übernimmt der Fine-Tuned Encoder diesen Bias. Die Lösung ist gezieltes Human Review: Konzentrieren Sie den Aufwand auf Entity Types, bei denen die Confidence des LLM niedrig oder inkonsistent ist, statt zufällig zu sampeln.

Ein valides Schema kann falsche Fakten enthalten. Native Structured Output, Instructor und Constrained Decoders können eine Response parsebar machen. Sie können jedoch nicht sicherstellen, dass jedes Feld Grounded ist, dass eine Span-Grenze korrekt ist oder dass ein normalisierter Wert dem richtigen Record zugeordnet wird. Bewahren Sie Source Evidence auf und validieren Sie die Semantik separat.

Quantization Losses hängen von Checkpoint und Daten ab. Das begleitende Repo erstellt ein dynamisch quantisiertes INT8-Artefakt, misst dessen F1 jedoch nicht. Die aktuelle GLiNER Guidance empfiehlt Quantization-Aware Training, wenn die Accuracy bei INT8 erhalten bleiben muss. Vergleichen Sie quantisierte und originale Checkpoints vor dem Deployment anhand von Exact-Span-F1 und Recall pro Label.

Wann die dreistufige Architektur Overkill ist. Eine einzelne Domäne mit stabilen Entity Types und genügend gelabelten Beispielen benötigt möglicherweise nur eine Fine-Tuned-RoBERTa- oder spaCy-Pipeline. Das Three-Tier-Muster passt zu mehreren Domänen, sich entwickelnden Entity Types oder einem gemessenen Mix aus expliziter und Reasoning-intensiver Extraction. Eine schmale Invoice-Pipeline, die Namen und Daten extrahiert, kann bei Tier 1 bleiben.

Die Quality des Bi-Encoders variiert je nach Dataset. Joint Encoding kann bei manchen Datasets helfen, während der Bi-Encoder den Cross-Encoder im CrossNER-Vergleich des Papers übertrifft und der Uni-Encoder bei CoNLL-2003 knapp vorn liegt. Benchmarken Sie beide auf dem Domain Set. Wählen Sie anhand gemessener Exact-Span-Quality, Calibration, Label Count und Throughput, statt „High Stakes“ als Regel für die Model-Familie zu verwenden.

PII- und multilinguale Claims benötigen Slices. Ein hoher aggregierter Score kann gefährlichen Recall-Verlust für eine Locale, Namensform, ein Document Layout oder eine seltene PII-Klasse verbergen. Betrachten Sie ein Privacy Model als eine Defense-in-Depth-Maßnahme, definieren Sie einen Response Process für False Negatives und evaluieren Sie erneut, wenn sich Taxonomy, Sprachen-Mix oder Datenquelle ändert.

Zentrale Erkenntnisse

1. Verwenden Sie einen kompakten Encoder für explizite Spans erst, nachdem er ein Domain Test Set mit Support pro Type und Confidence Intervals bestanden hat.
2. Verwenden Sie GLiNER für wechselnde Label-Vocabularies. Vergleichen Sie zunächst den Bi-Encoder, wenn ein großes Type Inventory wiederverwendet wird; aktivieren Sie flat_ner=False erst, nachdem Sie die Quality verschachtelter Spans gemessen haben.
3. Verwenden Sie für Hard-Zero-Shot-Claims getestete Type Descriptions und testen Sie bei multilingualen Produkten englische und lokalisierte Label-Formulierungen getrennt.
4. Behandeln Sie OCR, NER, Relation Extraction und Entity Linking als separate Evaluation-Stages, auch wenn ein Model mehrere Tasks anbietet.
5. Betrachten Sie einen LLM-Teacher als System für Annotation Proposals. Human Guidelines, Adjudication, unveränderliche Regression Sets und ein Held-Out-Testset bleiben erforderlich.
6. Verwenden Sie Native Schemas für unterstützte LLM-Provider, validieren Sie jedoch Semantic Correctness und Source Grounding unabhängig von der JSON Validity.
7. Benchmarken Sie Native Serving, ONNX, Quantization und Rust-Pfade sowohl separat als auch gemeinsam. Multiplizieren Sie niemals ungemessene Speedups.

References

Papers

• GLiNER: Generalist Model for Named Entity Recognition using Bidirectional Transformer – Zaratiana et al., NAACL 2024. Die grundlegende Span-Entity-Matching-Architektur.
• GLiNER2: An Efficient Multi-Task Information Extraction System with Schema-Driven Interface – Zaratiana et al., EMNLP 2025 System Demonstrations. Vereint NER, Classification und hierarchische Extraction; aktuelle Releases haben später Relation Extraction ergänzt.
• GLiNER Bi-Encoder: Scalable Named Entity Recognition with Bi-Encoder Architecture – Stepanov et al., Februar 2026. Entkoppeltes Encoding für den Maßstab von Millionen Labels.
• GLiNER-Relex: A Unified Framework for Joint Named Entity Recognition and Relation Extraction – Stepanov et al., 2026. Gemeinsame Zero-Shot Entity und Relation Extraction.
• GLiNER2-PII: A Multilingual Model for Personally Identifiable Information Extraction – Zaratiana et al., 2026. 42 PII Types auf Character-Span-Auflösung.
• ZeroNER: Fueling Zero-Shot Named Entity Recognition via Entity Type Descriptions – Cocchieri et al., ACL 2025. Hard-Zero-Shot-Evaluation mit Type Descriptions.
• OpenNER 1.0: Standardized Open-Access Named Entity Recognition Datasets in 50+ Languages – Palen-Michel et al., EMNLP 2025. 36 Corpora, 52 Sprachen und Multi-Ontology-Baselines.
• FiNERweb: Datasets and Artifacts for Scalable Multilingual Named Entity Recognition – Golde et al., EACL 2026. Multilinguale Labels und Transfer-Evaluation.
• UniNER: Universal NER using Large Language Models – Zhou et al., ICLR 2024. LLM-basierte Universal-NER durch Distillation von ChatGPT.
• NuNER: Entity Recognition Encoder Pre-training via LLM-Annotated Data – Bogdanov et al., EMNLP 2024. Zeigt, dass 125M Parameter bei LLM-generierten Trainingsdaten ausreichen.

Industry Papers

• EAMT: Entity-Aware Multi-Task Learning for Query Understanding – Walmart, KDD 2023. 965M Queries, 0,51 % GMV Lift.
• TripleLearn: End-to-End NER for E-Commerce Search – Home Depot, AAAI 2021. F1 von 69,5 auf 93,3.
• iACE: Automatic Collection of Cyber Threat Intelligence – CCS 2016. 71K Artikel, 900K IOCs.
• CyberNER: A Harmonized STIX Corpus for Cybersecurity NER – 21 STIX-2.1-aligned Entity Types.
• FinBERT-MRC: Financial NER via Machine Reading Comprehension – 0,87–0,93 F1 bei Financial-Entity-Tasks.

Case Studies

• CFM Case Study: Fine-tuning GLiNER for Financial NER – Die $70-LLM-Labeling-Pipeline von Capital Fund Management erreicht 93,4 % F1.
• Refuel AI: LLM Labeling Technical Report – GPT-4 erreicht 88,4 % Annotation Agreement und übertrifft menschliche Annotators.
• Sease: GLiNER as an Alternative to LLMs for Query Parsing – Wo GLiNER scheitert und LLMs weiterhin benötigt werden.
• John Snow Labs: Medical Text De-Identification Benchmark – Vergleich der PHI Detection mit 96 % F1 über mehrere Provider.
• OpenMed: Year in Review 2025 – Mehr als 380 Biomedical-NER-Models, 29,7M Hugging-Face-Downloads.

Tools und Frameworks

• ner-field-guide demo repo – Begleitende Demos für diesen Artikel: GLiNER Quickstart, ONNX-Export, LLM-as-Teacher und Structured Extraction.
• gline-rs: Rust reimplementation of GLiNER – 4,1-facher CPU-Speedup gegenüber Python, unter Apache 2.0 lizenziert.
• GLiNER serving – Ray-Serve-Pfad mit Dynamic Batching und Multi-Replica Deployment.
• spaCy English pipelines – Versionierte Metrics einer Closed-Label-Pipeline.
• Microsoft Presidio – PII Analysis und Anonymization mit Custom Recognizers.
• Instructor – Structured LLM Extraction über Pydantic Models.
• Outlines – Constrained Token Generation über FSMs mit einem berichteten Schema-Adherence-Benchmark.
• LangExtract – Source-grounded Structured Extraction mit Character Intervals.
• NuExtract – Self-Hosted, Schema-to-Template Document Extraction.
• OpenAI Structured Outputs – Referenz für Strict JSON-Schema Response Formats.
• Anthropic Structured Outputs – JSON Outputs und Strict Tool Inputs.
• Gemini Structured Outputs – JSON-Schema-Subset für strukturierte Responses.
• AWS: Structured Output with Outlines – Benchmark mit 98 % Schema Adherence.