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

Viacheslav Dubrov

2026-04-02 · Aktualisiert 2026-09-06 · 35 Min. · Retrieval- und Sprachsysteme

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

Artikel-Update

Ursprünglich veröffentlicht am 2. April 2026. Geprüft und aktualisiert am 6. September 2026. Das Update behandelt neuere GLiNER-Modelle, Streaming-PII-Erkennung, APIs für Structured Extraction und die Interpretation von Benchmarks.

Named Entity Recognition (NER) wandelt Text in markierte Bestandteile um, die ein Programm verwenden kann. Aus „Bill Gates founded Microsoft on April 4, 1975“ kann es beispielsweise die zusammenhängenden Textspans Bill Gates, Microsoft und April 4, 1975 mit den Typen Person, Organisation und Datum zurückgeben. In einem span-basierten Encoder wie GLiNER liest das Model den Text einmal und bewertet Kandidatenspans anhand der von dir vorgegebenen Labels. Die Auswahl eines NER-Systems bedeutet, festzulegen, wie viel Latency, Kosten, Label-Flexibilität und Reasoning die Extraktion benötigt.

Das begleitende Repository enthält Smoke-Tests für GLiNER, den ONNX-Export, die Generierung von Annotationen und Structured Extraction. Sein Vergleich mit drei Sätzen ist kein Model-Ranking: Der Scorer fasst wiederholte Text/Typ-Paare zusammen und kann nachfolgende Gold-Dokumente ignorieren, wenn Predictions fehlen. Auch das Teacher-Script zeigt keine demonstrierte Konvertierung in geprüfte Trainingsspans. Nutze diese Beispiele, um APIs zu untersuchen – nicht, um einen abgeschlossenen Trainings- oder Evaluations-Workflow zu behaupten. Für Workloads, die von expliziten Spans dominiert werden, sind kompakte Encoder gewöhnlich die schnellere und günstigere Option. LLMs bleiben nützlich, um Trainingsdaten zu erzeugen und Fälle zu bearbeiten, die Inferenz oder Normalisierung erfordern. Die Benchmark-Abschnitte erläutern die veröffentlichten Vergleiche und ihre Grenzen; keiner davon ist ein neuer Benchmark-Lauf für diesen Leitfaden.

Bei einer Retrieval- oder Privacy-Pipeline würde ich zuerst fragen, ob der Output eine wörtliche Mention sein muss. Diese Entscheidung trennt einen Span-Recognizer von Systemen, die zusätzlich Werte normalisieren, Datensätze verknüpfen oder Fakten ableiten.

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 findest du unter Best NER Models in 2026.

Was ist Named Entity Recognition?

Named Entity Recognition findet Spans in Text und weist ihnen Typen wie Person, Organisation, Datum, Produkt oder domänenspezifische Labels zu. Ein Span ist ein zusammenhängender Ausschnitt des Originaltexts. NER identifiziert die Mention; Entity Linking ist der separate Schritt, der sie in einen kanonischen Datensatz oder ein Ontology-Konzept auflöst.

Wo moderne Systeme NER einsetzen

NER findet weiterhin Textspans und weist ihnen Labels zu. Verändert hat sich seine Position im System. Heute liefert NER Filter für RAG, strukturierte Argumente 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: besseres Retrieval durch Entity Extraction

Similarity Search allein hat Schwierigkeiten, wenn eine Frage exakte Entities enthält. Für „what did Anthropic say about model safety in Q4 2024?“ kann Entity Extraction beispielsweise „Anthropic“ und „Q4 2024“ als Filter vorschlagen. Wende einen Hard Filter nur an, wenn die Index-Metadaten und die Datum-Semantik dies unterstützen; andernfalls nutze ihn als Ranking-Signal oder behalte einen ungefilterten Retrieval-Pfad bei. Ein übersehener Alias oder ein falsch abgeleiteter Datumsbereich kann die Antwort ausschließen.

Beim Indexing extrahierst du Entities aus jedem Chunk und speicherst sie als Metadaten: {"organizations": ["Anthropic"], "dates": ["Q4 2024"], ...}. Dadurch kannst du vor der Vector Search nach Entities filtern. Knowledge-Graph-RAG (GraphRAG, LlamaIndex Property Graphs) ergänzt benannte Beziehungen, denen das Retrieval über mehrere Hops folgen kann. Vergleiche dies mit wiederholten Vector Searches anhand der Fragen und des Corpus, die du unterstützen musst.

Zur Query-Zeit steuern aus der User-Frage extrahierte Entities das Routing. Eine Frage mit einem Firmennamen 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-Typen zur Query-Zeit ändern. Unbekannte Firmen- oder Medikamentennamen allein erfordern keine Open-Vocabulary-Labels; ein Closed-Label-Model kann neue Mentions bekannter Typen weiterhin erkennen.

AI Agents: Text in strukturierte Fakten umwandeln

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

Für Tool Routing kann eine Anfrage wie „schedule a meeting with Sarah Chen from Accenture on Thursday at 2pm“ PERSON: Sarah Chen, ORGANIZATION: Accenture, DATE: Thursday und TIME: 2pm ergeben. Ein Calendar Resolver kombiniert Datum und Uhrzeit anschließend zum von der API benötigten Timestamp. Ein lokaler Encoder vermeidet den API-Roundtrip und ist oft deutlich schneller; die Latency hängt jedoch von Model, Runtime, Hardware, Batch Size und Label Count ab. Miss beide Pfade auf dem Calendar-Workload, statt eine feste Differenz in Millisekunden anzunehmen.

NER unterstützt außerdem Entity Tracking über mehrere Conversations hinweg. Agent-Memory-Systeme müssen wissen, dass „Sarah“ in Turn 3 und „Ms. Chen“ in Turn 12 dieselbe Person sind. NER identifiziert die Spans; Coreference Resolution entscheidet anhand des Kontexts, ob sich die Mentions auf dieselbe Person beziehen. Entity Linking ordnet diese Person anschließend einem kanonischen Datensatz zu, sofern einer existiert.

In beiden Fällen ist die Einschränkung die Latency. Wenn jeder von zehn sequenziellen Schritten einen NER-Call mit 200 ms ausführt, addieren sich diese NER-Calls zu 2 Sekunden wahrgenommener Verzögerung. Ein einzelner Call benötigt 200 ms. Encoder-Modelle passen für Entity-Arbeit gewöhnlich besser in Agent Loops als LLM-basierte Extraction.

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 findet anschließend Spans für Felder wie invoice_number, vendor_name, total und due_date. Ein Schema- oder Relation-Extraction-Schritt muss Beschreibungen, Mengen und Preise von Einzelpositionen zu line_items gruppieren. Dieselbe Sequenz gilt für Verträge, medizinische Datensätze 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. GLiNER2.5 stellt Entities, Relations, Classification und strukturierte Records über eine Schema-Schnittstelle bereit. Evaluiere jeden Output separat; das ältere GLiNER2-Paper hat nicht jede heute von der Library bereitgestellte Aufgabe gebenchmarkt.

Die Kosten entscheiden bei den meisten dieser Pipelines. Kalkuliere deine Kosten anhand des tatsächlichen monatlichen Dokumentvolumens einschließlich Retries und Review. Ein kompakter Encoder kann auf der CPU laufen, während ein API-basiertes LLM Inference-Kosten und Latency pro Dokument verursacht. Ein praktischer Test besteht darin, ein repräsentatives Invoice-Set mit einem LLM zu labeln. Fine-tune GLiNER auf den geprüften Records und vergleiche anschließend beide Pfade anhand von Field-Level-F1, Latency und Gesamtkosten.

PII-Erkennung und LLM-Guardrails

Die Datenschutzprinzipien und Sicherheitspflichten der DSGVO (Artikel 5, 25 und 32), die technologieneutrale Security Rule von HIPAA (HHS Guidance) sowie Kaliforniens CCPA in der Fassung der CPRA sehen 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; lass die für deine Daten und Jurisdiktion geltenden Anforderungen juristisch prüfen. NER kann Dateninventarisierung, Minimierung oder De-Identification unterstützen, ist jedoch nur ein Control, dessen Recall für die relevanten Daten und die Jurisdiktion validiert werden muss.

NER kann dies direkt erledigen. De-Identification-Modelle finden Spans wie PERSON, SSN, PHONE, EMAIL und ADDRESS und schwärzen sie entweder oder ersetzen sie durch synthetische Äquivalente. Microsoft Presidio kombiniert Recognizer mit Anonymization Operators; seine Beispiele enthalten GLiNER als Recognizer. Das 0.3B-Parameter-Modell GLiNER2-PII ist ein weiterer Kandidat: Sein Paper behandelt 42 PII-Typen auf Character-Span-Ebene. Keines von beiden ist ein Compliance-Nachweis. Validiere den Recall nach Datenformat, Jurisdiktion, Sprache und PII-Klasse, bevor du einen Detector als Control einsetzt.

Im von John Snow Labs durchgeführten Anbieter-Vergleich decken 48 von Experten annotierte Dokumente sechs PHI-Klassen ab. Provider-Labels wurden umgemappt und nicht abbildbare Predictions ausgeschlossen, was die Interpretation über Provider hinweg einschränkt. Der Providence-Report beschreibt 281 geleakte PHI-Events in einer Untersuchung von 1.000 Notes mit 34.701 Sätzen. Events sind nicht gleichbedeutend mit unterschiedlichen betroffenen Sätzen: Zähle in einer Privacy-Evaluation sowohl geleakte Instanzen als auch betroffene Dokumente.

Für LLM-Guardrails funktioniert NER als Pre-Screening-Layer: Scanne User-Input vor dem Senden an eine externe API nach PII und blockiere oder anonymisiere ihn anschließend. Das kann schneller oder einfacher sein, als das LLM zur Selbstmoderation aufzufordern. Behandle dies als Deployment-Hypothese: Miss beide Pfade auf deinem Model, deiner Hardware, deinem Input-Mix und deinem Recall-Ziel. False Negatives bleiben möglich; ergänze daher ein weiteres Control für die PII-Exposition, die dein System nicht akzeptieren kann. GLiNER ist hier besonders nützlich, weil PII-Kategorien je nach Jurisdiktion variieren. Eine API kann ein neues Label wie „genetic information“ akzeptieren, ohne dass ein Retraining erforderlich ist. Das belegt jedoch keinen Recall für die neue Kategorie; validiere sie anhand geprüfter Beispiele, bevor du dich darauf verlässt.

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

GLiNER (NAACL 2024, Zaratiana et al.) machte Encoder-basierte NER zu einem konkurrenzfähigen Ansatz gegenüber LLMs – bei einem Bruchteil der Kosten. Statt NER als Sequence Labeling oder Text Generation zu behandeln, formuliert GLiNER NER als Matching-Problem. Das Model bewertet jeden Kandidaten-Textspan (jede zusammenhängende Wortsequenz wie „Bill Gates“ oder „Microsoft“) gegen jeden Entity-Type-Label und behält die Paare mit hohem Score.

Das Model erhält Entity-Type-Labels und Input-Text als eine 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 Repräsentationsmengen. Die eine verfeinert jede Entity-Type-Repräsentation aus einer [ENT]-Tokenposition über ein kleines Feed-Forward Network (FFN), das den Encoder-Vektor transformiert. Die andere repräsentiert Textspans, indem sie Start- und End-Word-Vektoren über ein weiteres FFN kombiniert. Ein Dot Product zwischen einer Span-Repräsentation und einer Entity-Type-Repräsentation liefert einen Score.

Wende Sigmoid an, und du erhältst die Wahrscheinlichkeit, dass der Span von Wortposition $i$ bis Wortposition $j$ zum Entity-Typ $t$ gehört: $\phi(i, j, t) = \sigma(S_{ij}^T \cdot q_t)$. Dabei ist $S_{ij}$ der vom FFN erzeugte Span-Vektor und $q_t$ das vom FFN verfeinerte Entity-Type-Embedding des zugehörigen [ENT]-Tokens (Zaratiana et al., 2024, Gl. 1–2). Kandidatenspans sind auf 12 Wörter begrenzt; der Tokenizer kann ein Wort in mehrere Subword-Tokens aufteilen.

GLiNER akzeptiert bei der Inference natürliche Sprachbeschreibungen von Labels, ohne Retraining zu benötigen; die Extraction-Qualität hängt jedoch von der Formulierung des Labels und der Domain-Fit ab. Du übergibst Entity Types wie „person“, „adverse drug reaction“ oder „financial instrument“, und das Model bewertet Spans anhand dieser Labels. Die folgenden 50M-, 90M- und 300M-Konfigurationen sind die ursprünglichen Paper-Modelle. Die Model Card für v2.1 nennt dagegen englische Checkpoints mit 166M, 209M und 459M sowie einen multilingualen 209M-Checkpoint, alle unter Apache 2.0. Vergleiche Latency oder Memory dieser Generationen nicht so, als wären die Parameterbezeichnungen identisch (GLiNER v2.1 Model Card).

Für einen echten Hard-Zero-Shot-Test musst du sowohl Zieltypen als auch Zielbeispiele zurückhalten: Das Model besitzt keine gelabelten Beispiele für die Zielaufgabe. Eine Typbeschreibung wie „a medically confirmed adverse effect caused by a treatment“ liefert dem Model mehr Informationen als allein adverse event. Das ist keine Garantie für Transfer; Description-driven ZeroNER übertraf jedoch Name-only-Baselines auf den Benchmarks mit zurückgehaltenen Typen (Cocchieri et al., 2025).

Die Trainingsdaten des ursprünglichen Models stammten aus dem Pile-NER-Dataset: 44.889 Passagen mit 240K Entity-Spans über 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. F1 kombiniert Precision und Recall zu einem Score; ein höherer Score ist nur bei identischer Aufgabe und identischen Evaluationsregeln besser. Der Durchschnitt über sieben Datasets kombiniert fünf CrossNER-Datasets mit MIT Movie und MIT Restaurant:

GLiNER-M mit 90M Parametern erreicht im Durchschnitt der sieben Datasets des Papers nahezu UniNER-13B (55,4 % gegenüber 55,6 % F1) bei ungefähr 140-mal weniger Parametern. Das 50M-Modell GLiNER-S übertrifft das berichtete Ergebnis von ChatGPT (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-Erkennung, News und multilingualen Support ab.

Das begleitende Repository verwendet für den Quickstart weiterhin v2.1. Für einen neuen Cross-Encoder-Vergleich solltest du zusätzlich die gepflegten GLiNER-v2.5-Checkpoints einbeziehen; Versionsnummern sind kein Beleg für einen Domain-F1-Gewinn. GLiNER v2.5 und Fastino GLiNER2.5 unten sind unterschiedliche Model-Familien.

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 GLiNER im Vergleich zu spaCy abschneidet

spaCy ist eine der etabliertesten NLP-Libraries im Production-Einsatz. Die Library arbeitet außerdem unter anderen architektonischen Rahmenbedingungen als GLiNER.

Die spaCy-Pipelines (en_core_web_sm, en_core_web_trf) führen Closed-Vocabulary-NER aus: eine feste Menge von Entity Types (PERSON, ORG, GPE, DATE usw.), die zur Trainingszeit definiert werden. Die Erweiterung der trainierten ner-Komponente erfordert gelabelte Beispiele und Training. Für IDs oder ein kontrolliertes Wörterbuch kann der EntityRuler über Patterns eigene Labels ohne Retraining hinzufügen; teste den Recall außerhalb dieser Patterns. Pinne das gepflegte 3.8-Model-Package, statt anzunehmen, dass eine unveröffentlichte Major-Version automatisch ein Production-Upgrade darstellt. Die en_core_web_trf-Model-Card 3.8.0 berichtet 90,19 NER-F1 auf OntoNotes 5.0, jedoch nur für ihre 18 vordefinierten Typen (spaCy Model Card).

GLiNER führt Open-Vocabulary-NER aus: Neue Label-Texte werden zur Inference-Zeit ohne Retraining akzeptiert. Das garantiert keine nützliche Extraction für jedes Label; Formulierung und Domain-Fit bleiben relevant. GLiNER ist ein starker Kandidat, wenn Entity Types im Voraus unbekannt sind, sich häufig ändern oder domänenspezifisch sind („adverse drug reaction“, „financial instrument“, „threat indicator“).

Meine Empfehlung: Verwende spaCy für Standard-Entity-Types, wenn die vortrainierten Pipelines gut validiert sind. Verwende GLiNER, wenn du flexible Zero-Shot-Typen benötigst oder wenn sich deine 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

Bei stabilen Labels und repräsentativen annotierten Spans solltest du als überwachte Baseline mit einem Fine-Tuned Token Classifier wie RoBERTa oder DeBERTa beginnen. Er tauscht Label-Flexibilität gegen aufgabenspezifische Accuracy. Vergleiche 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-Annotationen in kleinere NER-Modelle – unterscheiden sich aber darin, wie klein man werden kann.

UniNER: der maximalistische Ansatz

UniNER fine-tunt LLaMA-7B/13B auf 45.889 Input-Output-Paaren, die von ChatGPT erzeugt 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 steigert F1 von 31,5 % auf 53,4 % (Zhou et al., 2024).

UniNER-7B erreicht 41,7 % Zero-Shot-F1 über 43 Datasets hinweg und übertrifft ChatGPT mit 34,9 % um 7 Punkte. Die 13B-Variante erreicht 43,4 %, also nur 1,7 Punkte mehr bei nahezu doppelt so vielen Parametern (Zhou et al., 2024).

Der Production-Trade-off: Das im Paper besser abschneidende UniNER-Setup fragt jeden Entity Type sequenziell ab. Die All-in-One-Variante verwendet eine Response, lag aber im Mittel 3,3 % niedriger. Bei FP16 benötigt ein 7B-Checkpoint allein für die Weights ungefähr 14 GB; Quantization mit weniger Bits kann diesen Footprint reduzieren. Der UniNER-7B-all-Checkpoint ist mit CC BY-NC 4.0 ausgewiesen; prüfe den exakten Checkpoint, statt dieses Label auf jede Variante zu übertragen.

NuNER: der minimalistische Ansatz

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

Tabelle 3 von NuNER berichtet bei eingefrorenen Encodern und linearen Heads über vier Datasets und verschiedene gesampelte Trainingsgrößen hinweg ungefähr 6,1–16,2 Punkte Vorsprung gegenüber RoBERTa beim Macro-Average-Token-Classification-F1. Das Paper vergleicht außerdem Task-spezifisches Fine-Tuning mit UniNER-7B; die separate Diskussion von mehr als einem Dutzend Beispielen betrifft GPT-4 In-Context Learning, nicht einen Schwellenwert für das Erreichen von UniNER (Bogdanov et al., 2024).

Beide Papers unterstützen das Lernen aus LLM-Annotationen. Sie belegen nicht, dass ein kleineres Model in einer neuen Domain seinen Teacher übertrifft. Behalte ein separat geprüftes Test-Set zurück.

GLiNER2 und GLiNER2.5: Paper und Checkpoint getrennt betrachten

Das ursprüngliche GLiNER-Ökosystem verteilte NER, Relation Extraction, Classification und Document-Level-Extraction auf separate Modelle. Das GLiNER2-Paper von EMNLP 2025 vereinte NER, Classification und hierarchische Extraction in einem 205M-Parameter-Modell; spätere Releases ergänzten Relation Extraction über dieselbe Schema-Schnittstelle.

Diese Architektur von 2025 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-Aufgaben. Das Training verwendet 135.698 reale Dokumente, annotiert mit GPT-4o, sowie 118.636 synthetische Beispiele (Zaratiana et al., 2025).

Auf CrossNER im Zero-Shot-Modus erreicht GLiNER 2 0,590 F1, nahe an GPT-4o mit 0,599 im Mid-2025-Benchmark des Papers. Bei Classification liegt der Durchschnitt über 7 Benchmarks bei 0,72, verglichen mit 0,69 für DeBERTa-v3-large. Für die CPU berichtet das Paper über die getesteten Label Counts hinweg eine Classification-Latency von 130–208 ms. Die Zero-Shot-DeBERTa-Baseline benötigt einen Forward Pass pro Kandidaten-Label und steigt von 1.714 ms bei 5 Labels auf 16.897 ms bei 50; dies ist nicht die Runtime eines überwachten DeBERTa-Classifiers (Zaratiana et al., 2025).

Das folgende Beispiel lädt dagegen GLiNER2.5: 194M Parameter, eine Boundary-Architektur und ein konfiguriertes 4.096-Token-Window. AutoExtractor wählt BoundaryExtractor; der Legacy-GLiNER2-Loader ist dafür ungeeignet. Sparse Start/End-Pairing verändert, welche Spans gescored werden, nicht das endliche Context-Limit. Verwende dokumentierte Overlapping-Chunk-Helper für lange Dokumente und prüfe remappte Offsets. Die oben genannten Scores von 2025 beschreiben diesen Checkpoint nicht.

from gliner2 import AutoExtractor

# Requires `pip install gliner2[local]` and downloads the checkpoint.
extractor = AutoExtractor.from_pretrained("fastino/gliner2.5-base-v1")

# Compose tasks through the current schema interface
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 behandelt nicht die spätere Relation-API. Betrachte den Vier-Task-Pfad als Deployment-Fähigkeit, die gebenchmarkt werden muss – nicht als Beleg dafür, dass ein Model die Accuracy von vier spezialisierten Modellen beibehält.

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

Das GLiNER-Ökosystem verfügt inzwischen über unterschiedliche Architekturen. Sie sind Kandidaten für einen Domain-Vergleich, keine gemeinsame Leaderboard-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-Benchmark, der einen direkten Vergleich erlaubt. Halte diese Unterscheidung in einem Architecture Decision Record fest.

Streaming-PII verändert, wann du Text freigeben kannst

GLiNER Streaming PII ergänzt inkrementelle Erkennung mit einem kausalen Qwen3-0.6B-Backbone und gecachtem Session State. Seine API gibt den aktuellen vollständigen Session Snapshot mit Offsets in den akkumulierten Text zurück. Bewahre Chunk-Grenzen, halte Labels bis zu einem vollständigen Recompute unverändert und lösche abgeschlossene Sessions. Erfordert wird GLiNER 0.2.28 oder höher.

Beim Streaming-Redaction würde ich noch nicht freigegebenen Text puffern und Entities testen, die über Chunk-Grenzen hinweg aufgeteilt sind. Wenn eine Telefonnummer erst erkannt wird, nachdem ihre erste Hälfte gesendet wurde, kannst du diese Bytes nicht zurückholen. Miss sowohl geleakte Zeichen vor der Freigabe und die zusätzliche Verzögerung als auch den Recall finaler Spans. Die Model Card berichtet PIIMB Masking F2 getrennt von Strict Typed-Span F1; beide Metriken beantworten unterschiedliche Fragen. Die multilinguale Schwäche spricht ebenfalls dagegen, den veröffentlichten Checkpoint als universellen Privacy Filter zu behandeln.

Checkpoint-Lizenzen gehören zur Model-Auswahl

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

Lizenzangaben sind keine Rechtsberatung. Ein Production Review muss Bedingungen des Base Models, der Trainingsdaten und des Providers einbeziehen.

Der Bi-Encoder: NER mit Millionen Labels skalieren

Der ursprüngliche GLiNER encodiert Labels und Text gemeinsam. Gemeinsames Encoding wird mit wachsendem Label-Text zunehmend teurer, da dieser Context verbraucht und für jedes Dokument erneut encodiert werden muss. Der Crossover hängt von Checkpoint, Label-Beschreibungen und Hardware ab. Wenn dasselbe große Type-Inventory über viele Dokumente hinweg 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 gescored. Dadurch können Entity-Type-Embeddings einmalig vorab berechnet und gecacht werden. Bei der Inference vermeiden gecachte Labels das wiederholte Label-Encoding. Das Scoring von Kandidatenspans gegen diese Labels benötigt weiterhin Compute und Memory; eine Anwendung mit einer Million Labels benötigt außerdem begrenztes Candidate Retrieval oder Batching, wobei der Recall für vor dem Scoring ausgeschlossene Labels gemessen werden muss.

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 auf einer einzelnen H100 verarbeitet der Bi-Encoder 1,96 Millionen Predictions pro Tag gegenüber 368K beim Cross-Encoder (Stepanov et al., 2026).

Das Bi-Encoder-Paper berichtet 61,5 % für gliner-bi-large-v2.0 gegenüber 60,9 % für gliner_large-v2.5 auf demselben CrossNER-plus-MIT-Durchschnitt. Das ursprüngliche GLiNER-Paper berichtet ebenfalls 60,9 %, jedoch für einen anderen Checkpoint und eine andere Evaluation. Behandle den Vergleich des Bi-Papers als Paper-Ergebnis und teste anschließend beide Architekturen auf dem Domain-Set. Die Autoren empfehlen bi-base-v2.0 (194M) als Sweet Spot: 98 % der Accuracy des großen Models bei 2,6-facher Geschwindigkeit (Stepanov et al., 2026).

from gliner import GLiNER

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

# Pre-compute embeddings for a reused label set; rebuild this cache when labels or the checkpoint change.
entity_types = ["person", "organization", "date"]  # Small example; large inventories need bounded candidate selection
entity_embeddings = model.encode_labels(entity_types, batch_size=8)

# Encode text and score spans against the cached labels
texts = ["Bill Gates founded Microsoft on April 4, 1975."]
outputs = model.batch_predict_with_embeds(texts, entity_embeddings, entity_types)

Der Timing Sweep endet bei 1.024 Labels und verwendet eine H100, Batch Size 1 und zehn Forward Passes pro Konfiguration. Er misst keinen deployed Million-Label-Service. Größere biomedizinische oder Enterprise-Inventories sind Anwendungen, die evaluiert werden müssen; Entity Linking ist über das begleitende GLiNKER-Framework verfügbar.

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

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

Die CFM-Case-Study

In einer Hugging-Face-Case-Study extrahierte Capital Fund Management Firmennamen aus etwa 900.000 Financial-News-Headlines. Zero-Shot-GLiNER erreichte 87,0 % F1. Das Team verwendete Llama 3.1-70B, um das 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.

Fine-Tuning von GLiNER auf diesen Daten erreichte in der Case-Study 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-Case-Study). Diese Werte beschreiben eine Financial-News-Aufgabe und ein bestimmtes Infrastructure-Setup.

Die Refuel-AI-Studie

Der technische Report von Refuel AI benchmarkt LLM-Labeling auf 8 NLP-Datasets, darunter CoNLL-2003. Er berichtet in seinem Setup 88,4 % Übereinstimmung mit der Ground Truth für GPT-4 (März 2023) und 86,2 % für die menschlichen Annotatoren sowie ein 20-mal schnelleres und 7-mal günstigeres Labeling. Ein separates Ensemble-Experiment mit proprietären Daten überschritt 95 % Übereinstimmung, wobei das beste einzelne LLM 89 % erreichte. Confidence-basiertes Routing zu günstigeren oder leistungsfähigeren Models ist ein vorgeschlagener Use Case, nicht der gemessene Mechanismus hinter dem Acht-Dataset-Ergebnis (Technischer Report von Refuel AI). Behandle dies als vom Anbieter berichtete Ergebnisse unter dem Annotation-Protokoll der Studie.

Eine Production-Pipeline

Ein praktischer Production-Flow umfasst sechs Schritte:

1. Verfasse Annotation Guidelines in natürlicher Sprache.
2. Erstelle von Menschen gelabelte Validation- und Held-out-Test-Sets. Ihre Größe sollte sich aus Entity-Prevalence, Anforderungen an Slices pro Label und der gewünschten Breite des Confidence-Intervals ergeben. Ein Pilotprojekt mit 50–200 Dokumenten kann die Guidelines kalibrieren, ist aber keine Standardgröße für eine Production-Evaluation.
3. Verwende ein LLM mit versioniertem Prompt und explizitem Output-Schema, um Trainingslabels in größerem Umfang vorzuschlagen. Bewahre das angeforderte und das tatsächlich verwendete Model, den Prompt, den Quelltext und den Fallback-Status auf. Lehne unbekannte Typen und Spans ab, die sich nicht am Quelltext ausrichten lassen; das begleitende Repository führt derzeit stillschweigend einen Fallback aus und muss korrigiert werden, bevor sein Output als Training-Gold behandelt wird.
4. Prüfe eine Teilmenge über Argilla oder Label Studio.
5. Fine-tune einen kompakten Encoder (GLiNER, SpanMarker, RoBERTa).
6. Deploye erst, nachdem der Encoder einen Held-out-Quality- und Total-Cost-Check bestanden hat. CFM berichtete in seinem Setup 16–80-mal niedrigere stündliche Infrastructure-Kosten; beziehe Annotation, Review, Serving und Retraining in den Vergleich ein.

Das LLM kann den Umfang 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) testete GLiNER gegen GPT-4.1-mini auf 30 Query-Parsing-Aufgaben. 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 Benchmark mit 30 Aufgaben scheiterte GLiNER wiederholt in drei Mustern:

1. Implizite Entities: Extraktion von „event“ aus „Elton John performed at Madison Square Garden“ – im Text steht nicht wörtlich „event“, aber das LLM leitet „concert“ ab.
2. Sensitivität gegenüber der Label-Formulierung: „2022“ erzielt 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 Oberflächentext („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, wodurch überlappende Spans unterdrückt werden. Seine API unterstützt außerdem flat_ner=False, sodass verschachtelte Predictions möglich sind; die Qualität hängt jedoch von Checkpoint, Labels und Domain-Daten ab. Benchmarte beide Decoding-Modi auf einem verschachtelten Span-Level-Test-Set, bevor du ein spezialisiertes Model auswählst.

Verwende GLiNER für explizite Entity Extraction und leite Fälle, die Inferenz, Reasoning oder Mapping auf vordefinierte Ontologies erfordern, an ein LLM weiter. Der Routing-Schwellenwert sollte aus einem gelabelten Domain-Set stammen.

NER evaluieren: Metriken, Fallstricke und Test-Sets

Ein Model kann auf einem kuratierten Test-Set 95 % F1 erzielen und dennoch auf dem Dokument-Mix scheitern, den es nach dem Deployment sieht. Erstelle das Evaluation-Set aus der Production-Distribution und behalte Slices für seltene Formate und Entity Types bei, die der aggregierte F1 verbergen kann.

Die Kernmetriken

Identifiziere jede Occurrence anhand von Document ID, Half-Open-Start-/End-Offsets und Type und prüfe, ob text[start:end] die Mention wiederherstellt. Zwei Occurrences von „John“ sind zwei Targets. Validiere vor dem Matching die Dokumentanzahl: Fehlende Predictions müssen False Negatives erzeugen und dürfen nicht durch zip() verschwinden. Zähle falsche Typen oder Offsets als nicht gematchte Prediction und als nicht gematchten Gold-Span. Berichte Micro-Precision, Recall und F1, Support und Recall pro Typ und definiere Macro-Aggregation sowie Fälle mit leerer Menge.

• Entity-Level-F1: Die Standardmetrik. Eine Prediction ist nur dann korrekt, wenn sowohl Span-Grenzen als auch Type exakt mit der Ground Truth übereinstimmen. Dies berichten die meisten Papers.
• Token-Level-F1: Bewertet jedes Token unabhängig. Dadurch kann eine teilweise korrekte Boundary besser aussehen als ein Exact-Span-Score. Berichte Exact-Span-F1, wenn Boundary-Korrektheit relevant ist; verwende Token-Level-Metriken nur, wenn die Downstream-Entscheidung auf Token-Ebene erfolgt.
• Precision vs. Recall: Diese Größen haben oft asymmetrische Kosten. Bei De-Identification ist Recall wichtiger – einen Namen zu übersehen ist schlimmer als eine zu große Redaction. Bei Database Extraction ist Precision wichtiger – falsche Einträge verfälschen die nachgelagerte Analyse.

Häufige Evaluationsfehler

1. Inflation durch Partial Matches: Wenn „Bill“ extrahiert wird, obwohl das Gold-Label „Bill Gates“ lautet, zählen manche Scripts dies als Partial Match. Verwende Exact-Span-Matching, sofern es keinen Grund dagegen gibt.
2. Type Confusion: „Microsoft“, korrekt als Span identifiziert, aber als PERSON statt ORG gelabelt, muss mit null Punkten bewertet werden. Prüfe, ob dein Evaluationscode dies berücksichtigt.
3. Leakage aus dem Test-Set: Halte Duplikate und nahezu identische Records, Dokumente und Annotationen aus dem Test-Set heraus. Für einen Hard-Zero-Shot-Claim müssen auch die Ziel-Entity-Types aus dem Training ausgeschlossen werden; identische Oberflächenstrings allein sind kein Leakage.
4. Unkontrollierte Label-Prompts: Ein kurzer Typname und eine getestete Typbeschreibung sind unterschiedliche Inputs. Versioniere Label-Beschreibungen, Thresholds, Checkpoint-Revisions und Decoding-Modus zusammen mit dem Score.
5. Zero-Shot-Claims aus nur einer Sprache: Leite keine multilinguale Qualität aus Englisch ab. OpenNER umfasst 36 Corpora und 52 Sprachen; die Baselines fanden kein einzelnes Model, das in jeder Sprache am besten ist (Palen-Michel et al., 2025). In FiNERweb-Experimenten veränderte der Wechsel von englischen zu Labels in der Zielsprache den F1 je nach Setting um 0,02–0,09 (Golde et al., 2026). Teste beide Label-Sprachen, wenn das Product lokale Terminologie verwendet.
6. Ein Lauf ist kein Urteil: Berichte, sofern anwendbar, die Variation über Random Seeds, Threshold Sweeps und wiederholte Production Samples. Kleine Slice Counts machen ein Model-Ranking instabil.

Halte Normalisierung, Entity Linking, Record Grouping und Relation Endpoints getrennt vom extraktiven F1. Berichte für Privacy geleakte Instanzen und betroffene automatisch akzeptierte Dokumente, False Redactions und den Review-Anteil. Berichte für Serving Completion Rate, p50/p95 Document Latency, Cold- und Warm-Runs, Batch- und Label-Größen, Peak Memory und Kosten pro akzeptiertem Dokument.

Ein Domain-Test-Set erstellen

Für eine Production-Evaluation empfehle ich:

1. Sample aus Production-Daten, nicht aus kuratierten Beispielen. Beziehe die unordentlichen Dokumente ein, die dein Model tatsächlich sehen wird.
2. Dimensioniere das Test-Set für die benötigte Schätzung. Wähle die Anzahl anhand von Entity-Prevalence, Slice-Größen pro Label und der gewünschten Breite des Confidence-Intervals. Berichte Bootstrap- oder analytische Confidence-Intervals.
3. Verwende auf einem Calibration-Subset mindestens zwei Annotatoren. Schlichte Disagreements und berichte ein Span-aware-Agreement-Maß. Agreement diagnostiziert Ambiguität und die Qualität der Guidelines; es ist keine Obergrenze für Model-Performance.
4. Stratifiziere nach Schwierigkeit – einfache Fälle (sauberer Text, Standardtypen) und schwierige Fälle (mehrdeutige Entities, Jargon, verrauschter Text).
5. Behalte Privacy- und Fairness-Slices bei. Berichte für PII den Recall nach PII-Typ, Sprache, Locale, Dokumentformat und relevanten demografischen oder nach Namensherkunft gebildeten Slices. Beschränke den Zugriff der Evaluatoren auf den rohen sensiblen Text, setze Aufbewahrungsgrenzen und prüfe False Negatives.

Continual NER benötigt ein unveränderliches Regression Set

Production-Taxonomien ändern sich. Füge neue Typen hinzu, ohne die Bedeutung eines alten Typs stillschweigend zu verändern. Bewahre ein versioniertes, unveränderliches Regression Set für bestehende Typen, ein separates Test-Set für den neuen Typ und ein Changelog für Änderungen an den Annotation Guidelines auf. Berichte Scores für alte und neue Typen separat, bevor du einen Checkpoint ersetzt. Dies ist der einfachste Weg, Forgetting und Taxonomy Drift zu erkennen.

Production-NER in vier Branchen

Dies sind ausgewählte Branchenbeispiele mit spezifischen Zahlen unter den jeweils berichteten Bedingungen. Die Quellen kombinieren von Anbietern berichtete Vergleiche, von Unternehmen oder Projekten berichtete Case Studies sowie Peer-Reviewed-Papers und Preprints. Behandle sie als Praxisbeispiele, nicht als Reifegrad-Ranking.

Healthcare

Die oben genannten Beispiele von John Snow Labs und Providence zeigen, warum De-Identification sowohl Entity-Level- als auch Document-Level-Reporting benötigt. Ihre Evaluationsprotokolle sind für die Planung eines Reviews hilfreicher als ein unqualifiziertes Provider-Ranking.

Das OpenMed-Retrospektiv, veröffentlicht am 6. Januar 2026, berichtet über 481 Models; 380+ beschreibt den Bestand zum Launch im Juli. Downloads messen Distribution, nicht Deployments. Der Claim, bei 10 von 12 Benchmarks führende Ergebnisse zu erzielen, stammt aus einem separaten Autoren-Preprint vom August 2025 und nicht aus unabhängig verifizierten Production-Ergebnissen.

Financial NER

Financial Extraction umfasst Company Mentions in News sowie Felder in Filings; ihre Schemas und Dokumentlängen unterscheiden sich. Die CFM-Case-Study behandelt den ersten Fall. FinBERT-MRC formuliert Extraction als Machine Reading Comprehension und berichtet 92,78 ± 0,56 F1 auf ChFinAnn sowie 96,80 ± 0,38 auf AdminPunish, beides chinesische Datasets. Diese Ergebnisse belegen keine Accuracy für englische SEC-Filings. Teste lange Dokumente und verschachtelte finanzielle Entities in der vorgesehenen Sprache.

E-Commerce

Wal­marts KDD-2023-Paper verwendet QU-965M-Multitask-Query-Daten; seine ungefähr 60 NER-Labels sind IOB2-Klassen. Abschnitt 6.8 schreibt den 0,51-%-GMV-Lift der MTDNN-Baseline zu, die auf diesen Daten trainiert wurde, während EAMTs Online-Evaluation als zukünftige Arbeit offenblieb. Die Business-Differenz kann nicht allein NER zugeschrieben werden. Home Depots TripleLearn berichtet eine Verbesserung des Held-out-F1 von 69,5 auf 93,3, ein Online-Experiment und mehr als neun Monate im Production-Einsatz. Die übertragbare Erkenntnis ist iterative Domain-Supervision, nicht ein aktuelles Architektur-Ranking.

Cybersecurity

iACE ist ein historisches Beispiel für automatisierte Threat-Intelligence-Extraction. Das CyNER-Paper kombiniert Neural Recognition mit weiteren Extraction-Quellen und berichtet 76,66 Span-Micro-F1 für XLM-RoBERTa-large, evaluiert mit seqeval. Der CyberNER-Preprint harmonisiert vier Datasets zu 21 STIX-2.1-ausgerichteten Labels und berichtet für RoBERTa 0,736 F1. Dies sind Forschungsergebnisse und kein Beleg für Production-Adoption.

Deployment-Optimierung: von Python zu Inference mit niedrigerer Latency

Das begleitende Repository demonstriert GLiNER-ONNX-Export und INT8-Packaging. Es zeichnet Artifact-Größen auf, reproduziert jedoch nicht die von externen Projekten berichteten Latency- oder F1-Werte.

Native GLiNER-Serving

Bevor du zu einer neuen Runtime wechselst, teste den Ray-Serve-Pfad des Projekts. gliner[serve] bietet Dynamic Batching, Memory-aware Batch Sizing, Multi-Replica-Scaling und einen HTTP-Client. Batching und Replicas können den Throughput verbessern und gleichzeitig den Model-Code unverändert lassen; Batching kann jedoch zusätzliche Wartezeit verursachen, und Replicas beseitigen Queueing nicht. Benchmarte Queue Latency, Warm Latency, Throughput und Exact-Span-F1 unter deinem Request-Mix, bevor du den Pfad mit ONNX oder Rust vergleichst.

ONNX-Export

GLiNER verfügt über native ONNX-Konvertierung; vorab konvertierte Models existieren auf Hugging Face (onnx-community/gliner_small-v2.1). Miss die Latency mit demselben PyTorch-Checkpoint, derselben Batch Size, Hardware und demselben Warm-up-Protokoll.

Führe scripts/02_onnx_export.py aus dem begleitenden Repository aus, um ein Model zu exportieren und sein ONNX-Artifact dynamisch zu quantisieren. Das Script benötigt diese Umgebung und lädt einen Checkpoint herunter; es ist daher ein dort auszuführender Befehl und kein eigenständiger Artikel-Snippet:

uv run python scripts/02_onnx_export.py

INT8-Quantization

Dynamic Quantization kann die Speicher- und Memory-Anforderungen eines ONNX-Models reduzieren. Der Effekt auf Latency und F1 pro Label hängt von Checkpoint und CPU ab; das Export-Script liefert daher Packaging-Evidence und 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-Reimplementierung

gline-rs (Apache 2.0) entfernt die Python-Runtime aus dem Inference-Pfad. 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 auf 100 NuNER-Samples. Ein separates v0.9.1-Experiment auf einer RTX 4080 mit 1.000 Samples berichtet 248,75 Seq/s, jedoch ohne passenden Python-GPU-Vergleich. Dies sind die eigenen Bedingungen des Projekts und keine vom begleitenden Repository reproduzierten Ergebnisse. Es unterstützt Span- und Token-Models, GPU/NPU über ONNX Runtime und wird als Crate auf crates.io veröffentlicht.

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 fast-gliner-Package stellt Python Bindings über PyO3 bereit.

Was die Optimierungs-Evidence abdeckt

Structured Extraction: native Schemas, Instructor und lokale Decoder

Wenn du mehr Flexibilität benötigst, als Encoder-Modelle bieten – implizite Entities, Reasoning, Ontology Mapping –, beginne mit dem nativen Schema-Mechanismus des Providers. OpenAI unterstützt strikt validierte json_schema-Response-Formate, Anthropic Structured Outputs unterstützt JSON-Outputs und strikte Tool Inputs, und die Gemini API unterstützt ein Subset von JSON Schema. Ein gemeinsames Pydantic- oder Zod-Model kann den Contract beschreiben; jeder Provider akzeptiert jedoch ein anderes Schema-Subset und zeigt ein anderes Verhalten bei Refusals und Komplexität.

Schema-Konformität macht Parsing zuverlässig. Sie beweist jedoch nicht, dass ein extrahierter Span im Quelltext existiert oder dass ein normalisierter Wert korrekt ist. Validiere Feldwerte, bewahre nach Möglichkeit Offsets oder Quotations auf und bewerte semantische Accuracy auf einem gelabelten Set.

Instructor umschließt Provider-Clients mit Pydantic-Validation und optionalen Retries nach fehlgeschlagener Validation.

Adaptiert aus dem Instructor-Pattern in scripts/05_structured_extraction.py. Es benötigt die aufgelisteten Packages und einen OPENAI_API_KEY; das begleitende Script fällt auf GLiNER zurück, wenn kein Key verfügbar ist. Dieser Artikel verwendet nun GPT-5.6 Terra, dessen Model Card Chat Completions, Function Calling, Structured Outputs und none Reasoning Effort unterstützt. Vergleiche es mit der günstigeren älteren Baseline, bevor du einen High-Volume-Extractor umstellst; eine neue Generation belegt keine bessere NER-Accuracy.

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.6-terra", reasoning_effort="none",
    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 Zielgrammatik verstoßen würden, anstatt auf einen Validation Failure zu warten und anschließend einen Retry auszuführen. Eine AWS-Übersicht nennt 98 % Schema Adherence gegenüber 76 % bei Post-Generation-Validation. Separat wird dort der Claim von .txt Engineering wiederholt, die Coalescence-Approach erzeuge eine bis zu 5-mal schnellere Generation; die Seite veröffentlicht nicht genug Methodik, um beide Werte als einen kontrollierten Benchmark zu behandeln.

Das folgende kleine lokale Beispiel behält Phi-3 als historisches Beispiel für Decoder-Integration bei, nicht als Model-Empfehlung für 2026. Für einen neuen Self-Hosted-Extraction-Vergleich solltest du aktuelle Qwen3.8-27B- oder kleinere Qwen3.5-Checkpoints einbeziehen. Verwende ihren dokumentierten Model Loader, ihr Chat Template und ihren Serving-Backend; allein das Ersetzen des folgenden Strings belegt keine Kompatibilität mit einer multimodalen Architektur oder deren Reasoning-Format.

import outlines
from transformers import AutoModelForCausalLM, AutoTokenizer
from pydantic import BaseModel
from typing import Literal

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

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

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 Quelltext geerdet sein muss: Es gibt Character Intervals zurück und unterstützt gehostete oder lokale LLM-Backends. Für Self-Hosted-Document-Extraction konvertiert NuExtract JSON Schemas in Templates und enthält multimodale Document Models. Behandle beide als Structured-Extraction-Systeme und nicht als automatische Ersatzlösungen für Span-NER. Ihre Ziele hinsichtlich Feldern, Offsets, Dokumentlayout und Latency benötigen eigene Tests.

Die Wahl hängt davon ab, wo du deine Models ausführst. Native Schemas sind für einen unterstützten Provider der reibungsärmste Pfad. Instructor ergänzt eine provider-agnostische Pydantic-Validation- und Retry-Schicht. Outlines beschränkt lokale Generation auf ein Schema. LangExtract priorisiert Source Grounding, während NuExtract auf Self-Hosted-Document-Extraction zielt. Alle LLM-Pfade enthalten weiterhin autoregressive Generation. Benchmarte jeden Pfad gegen einen Encoder mit derselben Batch Size, Hardware, Entity-Schema und einem identischen Rubric für semantische Accuracy.

Die Drei-Tier-Production-Architektur

Ich würde Production-NER nach der Aufgabenstruktur routen und nicht nach einem einzelnen Model-Ranking.

Tier 1: Encoder-Modelle für explizite Spans. Verwende einen GLiNER Cross-Encoder für ein kleines Type-Inventory. Bei einem großen Inventory solltest du den Bi-Encoder mit gecachten Type-Embeddings vergleichen. Fine-tune über die LLM-as-Teacher-Pipeline und deploye anschließend mit nativer Serving-Umgebung, ONNX, INT8 oder gline-rs – aber nur, wenn dieser Pfad den Domain-Benchmark besteht.

Tier 2: Multi-Task- oder Relation Extraction. Wenn ein Request NER, Classification und hierarchische Felder benötigt, teste den aktuellen 194M-Parameter-Checkpoint GLiNER2.5 gegen separate Baselines pro Aufgabe. Wenn die zentrale Anforderung gemeinsame Spans plus Relations sind, teste GLiNER-Relex. Das GLiNER2-Paper berichtet eine CPU-Classification-Latency von 130–208 ms über die getesteten Label Counts hinweg; dies ist kein Beleg für die spätere Relation-API oder ein anderes Deployment.

Tier 3: LLMs für Reasoning-intensive Extraction. Leite implizite Entities, kontextuelle Inferenz und Ontology Mapping an eine native Schema-API oder bei Cloud-APIs an Instructor weiter; für lokale Constrained Outputs verwende Outlines. Verwende LangExtract, wenn Source Intervals unverzichtbar sind, und NuExtract, wenn das Dokument selbst der Input ist. Logge diese Fälle für das Review. Nur explizite, am Quelltext ausgerichtete Spans können zu gewöhnlichen Tier-1-Trainingszielen werden; inferierte Fakten und normalisierte Werte benötigen eigene Targets und Evaluation.

Die CFM-Case-Study liefert einen Kostenreferenzwert für Tier 1: 93,4 % F1 bei berichteten $0,10 pro Stunde auf der CPU, verglichen mit 92,7 % F1 und $8 pro Stunde für ihren Llama-70B-Teacher. Stündliche Instance-Preise bestimmen ohne Throughput nicht die Kosten pro Dokument. Rechne mit deiner Hardware, deinem Teacher-Model, Label-Set, deiner Auslastung und deinen Review-Kosten neu.

Trade-offs und Einschränkungen

Bei jedem der folgenden Trade-offs ist die entscheidende Frage, wo er auftritt und ob du ihn vor dem Deployment messen kannst.

Fehler des LLM-as-Teacher propagieren sich. Wenn das LLM einen bestimmten Entity Type systematisch falsch behandelt (z. B. Tochtergesellschaften mit Muttergesellschaften verwechselt), übernimmt der Fine-Tuned Encoder dieses Bias. Prüfe Low-Confidence- oder inkonsistente Typen besonders intensiv und halte eine stratifizierte Zufallsstichprobe zurück, um selbstsichere systematische Fehler zu erkennen.

Ein valides Schema kann falsche Fakten enthalten. Native Structured Outputs, Instructor und Constrained Decoders können eine Response parsebar machen. Sie stellen nicht sicher, dass jedes Feld geerdet ist, eine Span-Boundary korrekt ist oder ein normalisierter Wert dem richtigen Record zugeordnet wird. Bewahre Source Evidence auf und validiere die Semantik separat.

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

Wann die Drei-Tier-Architektur Overkill ist. Eine einzelne Domain mit stabilen Entity Types und ausreichend gelabelten Beispielen benötigt möglicherweise nur eine Fine-Tuned-RoBERTa- oder spaCy-Pipeline. Das Drei-Tier-Pattern eignet sich für mehrere Domains, sich entwickelnde Entity Types oder einen gemessenen Mix aus expliziter und Reasoning-intensiver Extraction. Eine schmale Invoice-Pipeline, die Namen und Daten extrahiert, kann bei Tier 1 bleiben.

Die Qualität des Bi-Encoders variiert je nach Dataset. Gemeinsames Encoding kann auf manchen Datasets helfen; im CrossNER-Vergleich des Papers gewinnt jedoch der Bi-Encoder, während der Uni-Encoder auf CoNLL-2003 knapp vorne liegt. Benchmarte beide auf dem Domain-Set; entscheide anhand gemessener Exact-Span-Quality, Calibration, Label Count und Throughput und nicht anhand einer Model-Familienregel wie „high stakes“.

PII- und multilinguale Claims benötigen Slices. Ein hoher aggregierter Score kann gefährlichen Recall-Verlust für eine Locale, Namensform, ein Dokumentlayout oder eine seltene PII-Klasse verbergen. Behandle ein Privacy Model als eine Maßnahme in einer Defense-in-Depth-Strategie, definiere einen Prozess für False Negatives und evaluiere erneut, wenn sich Taxonomie, Sprachen-Mix oder Datenquelle ändern.

Zentrale Erkenntnisse

1. Verwende einen kompakten Encoder für explizite Spans erst, nachdem er ein Domain-Test-Set mit Support pro Typ und Confidence-Intervals bestanden hat.
2. Verwende GLiNER für wechselnde Label-Vocabularies. Vergleiche zuerst seinen Bi-Encoder, wenn ein großes Type-Inventory wiederverwendet wird; aktiviere flat_ner=False erst nach einer Messung der Qualität verschachtelter Spans.
3. Verwende für Hard-Zero-Shot-Claims getestete Typbeschreibungen und teste englische sowie lokalisierte Label-Formulierungen für multilinguale Produkte separat.
4. Behandle OCR, NER, Relation Extraction und Entity Linking als getrennte Evaluationsstufen, auch wenn ein Model mehrere Aufgaben bereitstellt.
5. Behandle einen LLM-Teacher als System für Annotation-Vorschläge. Menschliche Guidelines, Adjudication, unveränderliche Regression Sets und ein Held-out-Test-Set bleiben erforderlich.
6. Verwende Native Schemas für unterstützte LLM-Provider, validiere aber semantische Korrektheit und Source Grounding getrennt von der JSON-Gültigkeit.
7. Benchmarte native Serving-, ONNX-, Quantization- und Rust-Pfade separat und gemeinsam. Multipliziere niemals nicht gemessene Speedups.

Referenzen

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; spätere Releases ergänzten Relation Extraction.
• 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-Typen auf Character-Span-Ebene.
• ZeroNER: Fueling Zero-Shot Named Entity Recognition via Entity Type Descriptions – Cocchieri et al., ACL 2025. Hard-Zero-Shot-Evaluation mit Typbeschreibungen.
• 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.
• UniversalNER: Targeted Distillation from Large Language Models for Open Named Entity Recognition – Zhou et al., ICLR 2024. LLM-basierte universelle NER durch Distillation von ChatGPT.
• NuNER: Entity Recognition Encoder Pre-training via LLM-Annotated Data – Bogdanov et al., EMNLP 2024. Untersuchung eines 125M-Encoders, der auf LLM-Annotationen vortrainiert wurde.

Industry Papers

• EAMT: Entity-Aware Multi-Task Learning for Query Understanding – Walmart, KDD 2023. Multitask-Query-Studie; das Online-Ergebnis gehört zu ihrer MTDNN-Baseline.
• TripleLearn: End-to-End NER for E-Commerce Search – Home Depot, AAAI 2021. F1 von 69,5 auf 93,3.
• Acing the IOC Game: Toward Automatic Discovery and Analysis of Open-Source Cyber Threat Intelligence – Liao et al., CCS 2016. Historischer Extraction-Ansatz.
• CyberNER: A Harmonized STIX Corpus for Cybersecurity NER – 21 an STIX 2.1 ausgerichtete Entity Types.
• FinBERT-MRC: Financial NER via Machine Reading Comprehension – MRC-Formulierung, evaluiert auf chinesischen Financial-Datasets.

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 Annotatoren.
• 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 – Anbieter-Studie mit Label-Remapping und Ausschlüssen.
• OpenMed: Year in Review 2025 – Retrospektive vom Januar 2026; Inventory und Downloads sind keine Deployments.

Tools und Frameworks

• ner-field-guide demo repo – Begleitende Demos zu diesem Artikel: GLiNER-Quickstart, ONNX-Export, LLM-as-Teacher und Structured Extraction.
• gline-rs: Rust reimplementation of GLiNER – Separate CPU- und GPU-Experimente des Maintainers; Apache-2.0-Code.
• GLiNER serving – Ray-Serve-Pfad mit Dynamic Batching und Multi-Replica-Deployment.
• spaCy English pipelines – Versionierte Closed-Label-Pipeline-Metriken.
• Microsoft Presidio – PII-Analyse und Anonymisierung mit Custom Recognizers.
• Instructor – Structured LLM Extraction über Pydantic-Modelle.
• 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 ein strikt validiertes JSON-Schema-Response-Format.
• Anthropic Structured Outputs – JSON-Outputs und strikte Tool Inputs.
• Gemini Structured Outputs – JSON-Schema-Subset für strukturierte Responses.
• AWS: Structured Output with Outlines – Benchmark mit 98 % Schema Adherence.