Zum Inhalt

Automatische Übersetzung

Dieser Artikel wurde automatisch aus der englischen Originalversion übersetzt.

Der definitive Leitfaden für NER im Jahr 2026: Encoder, LLMs und die 3-stufige Produktionsarchitektur

Vor zwei Jahren bedeutete die Wahl eines NER-Ansatzes noch, sich zwischen Geschwindigkeit (Encoder-Modelle) und Genauigkeit (LLMs) zu entscheiden. Dieser Trade-off ist weg. Ein GLiNER-Modell mit 300M Parametern erreicht die Zero-Shot-Genauigkeit eines 13B-UniNER und läuft dabei 100x schneller. Eine neuere Bi-Encoder-Variante skaliert auf Millionen von Entitätstypen mit einem 130x Durchsatzvorteil gegenüber dem ursprünglichen Cross-Encoder. Das daraus entstandene Produktionsmuster: LLMs zum Labeln von Daten verwenden, kompakte Encoder feinabstimmen und mit ONNX oder Rust deployen.

Ich habe das begleitende Repo gebaut und jeden wichtigen Ansatz benchmarked. Encoder haben den Produktionsmarkt für NER gewonnen. LLMs sind weiterhin essenziell, aber als Generatoren von Trainingsdaten statt als Inferenz-Engines. Dieser Leitfaden behandelt die Papers, Benchmarks und Deployment-Muster hinter diesem Wandel.

Begleit-Repo: ner-field-guide — ausführbare Demos für GLiNER, ONNX-Export, LLM-as-Teacher-Pipeline und strukturierte Extraktion mit Instructor.

TL;DR: Du musst NER-Modelle nicht mehr von Grund auf selbst bauen. Für Zero-Shot-Extraktion schlägt GLiNER auf CPU via ONNX selbst die neuesten LLMs bei nahezu null Kosten. Für domänenspezifische Aufgaben liefert die LLM-as-Teacher-Pipeline (LLM labelt → Review → Fine-Tuning) Encoder mit 90-93%+ F1. Für Fälle, die Reasoning brauchen, nutze Instructor oder Outlines mit einer LLM-API — kalkuliere aber \$2+/1K Dokumente ein. Die 3-stufige Architektur kombiniert alle drei.

Warum NER jetzt wichtiger ist: Agents, RAG und Document Intelligence

NER bedeutet immer noch dasselbe: benannte Spans im Text finden und klassifizieren. Geändert hat sich, wo es auftaucht. Früher war es der letzte Schritt in einer NLP-Pipeline, das stille Utility-Element, über das niemand Blogposts schrieb. Heute ist es ein Baustein in RAG-Systemen, Agent-Loops und Plattformen zur Dokumentenverarbeitung. Deshalb ist die NER-Forschungswelle von 2024-2026 auch jenseits akademischer Benchmarks relevant.

RAG: Bessere Retrieval-Ergebnisse durch Entitätsextraktion

Standard-RAG — Text chunken, einbetten, nach Ähnlichkeit abrufen, aufs Beste hoffen — bricht auseinander, wenn Nutzer nach spezifischen Entitäten fragen. Wenn jemand fragt: "was hat Anthropic über model safety in Q4 2024 gesagt?", muss das System "Anthropic" und "Q4 2024" als Filter erkennen und darf sich nicht nur auf Embedding-Ähnlichkeit verlassen.

Beim Indexing extrahierst du Entitäten aus jedem Chunk und speicherst sie als Metadaten: {"organizations": ["Anthropic"], "dates": ["Q4 2024"], ...}. So kannst du vor der Vektorsuche nach Entitäten filtern. Knowledge-Graph-RAG (GraphRAG, LlamaIndex property graphs) geht noch weiter: NER plus Relation Extraction baut einen Graphen, der Multi-Hop-Fragen beantworten kann, an denen flache Embeddings scheitern.

Zur Query-Zeit steuern aus der Benutzerfrage extrahierte Entitäten das Routing. Eine Frage mit einem Firmennamen geht an einen Finanzindex, eine mit Medikamentennamen an eine klinische Wissensbasis. GLiNER funktioniert hier gut, weil Query-Entitäten unvorhersehbar sind — du kannst nicht für jeden neuen Entitätstyp neu trainieren, nach dem Nutzer fragen könnten.

AI Agents: Text in strukturierte Fakten umwandeln

Agents erhalten unstrukturierten Text — Webseiten, API-Antworten, Nutzernachrichten — und müssen darauf handeln. NER wandelt diesen Text in strukturierte Fakten um, über die der Agent schlussfolgern, die er speichern oder an Tools weitergeben kann.

Es gibt zwei Stellen, an denen das besonders wichtig ist.

Die erste ist Tool-Routing. Wenn ein Nutzer sagt: "schedule a meeting with Sarah Chen from Accenture on Thursday at 2pm", muss der Agent PERSON: Sarah Chen, ORGANIZATION: Accenture und DATETIME: Thursday 2pm extrahieren, bevor er die Kalender-API aufruft. Ein Encoder-NER-Modell macht das in unter 10ms. Ein LLM fügt pro Aufruf 1-2 Sekunden hinzu, und das summiert sich über mehrstufige Workflows, bis sich dein "instant" Agent anfühlt, als würde er mit einem Philosophiestudium laufen.

Die zweite ist Entitäts-Tracking über Gespräche 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; Entity Linking löst sie auf dieselbe ID auf.

Die Einschränkung in beiden Fällen ist Latenz. Ein NER-Call mit 200ms in einer 10-stufigen Agent-Kette addiert 2 Sekunden wahrgenommene Verzögerung. Deshalb sind Encoder-Modelle und nicht LLM-basierte Extraktion die richtige Wahl für Entitätsarbeit innerhalb von Agent-Loops.

Document Intelligence: Von Bildern zu strukturierten Daten

OCR macht aus Bildern Text. NER macht aus Text strukturierte Felder. Zusammen ermöglichen sie Dokumentendigitalisierung im großen Maßstab.

Die Standardpipeline: OCR ausführen (Tesseract, Azure Document Intelligence, AWS Textract), um Text und Bounding Boxes zu erhalten, dann NER ausführen, um strukturierte Felder — invoice_number, vendor_name, line_items, total, due_date — aus dem zu extrahieren, was vorher ein JPEG einer Papierrechnung war. Derselbe Ansatz funktioniert für Verträge, Patientenakten und regulatorische Einreichungen.

Moderne Plattformen kombinieren drei Schritte: Layout-Verständnis (ist das ein Header oder eine Tabellenzelle?), Entitätsextraktion (welchen Typ hat dieser Text?) und Relation Extraction (welche Werte gehören zusammen?). GLiNER 2 beherrscht alle drei in einem Forward Pass; ein einzelner Modellaufruf kann {vendor: "Acme Corp", amount: "\$4,200", due_date: "2026-04-15"} aus einer Rechnung zurückgeben.

Hier zählen Kosten. Eine mittelgroße Wirtschaftsprüfung verarbeitet monatlich Zehntausende Rechnungen. Jede einzelne durch ein LLM zu routen, selbst durch ein kosteneffizientes Modell wie GPT-5.4 Nano, kostet Hunderte Dollar pro Tag. Ein feinabgestimmtes GLiNER auf CPU kostet Centbeträge. Dein CFO wird den Unterschied bemerken. Der Pfad: 500 Beispielrechnungen mit einem LLM annotieren, GLiNER auf den Ergebnissen feinabstimmen, auf CPU für \$0.10/Stunde deployen.

PII-Erkennung und LLM-Guardrails

Datenschutzregulierungen (GDPR, HIPAA, CCPA) verlangen, personenbezogene Daten zu finden, bevor sie in nachgelagerte Systeme gelangen. Bei LLM-Deployments bedeutet das: Eingaben prüfen, bevor sie das Modell erreichen, und Ausgaben prüfen, bevor sie den Nutzer erreichen.

NER löst das direkt. De-Identifikationsmodelle finden PERSON-, SSN-, PHONE-, EMAIL- und ADDRESS-Spans und schwärzen sie entweder oder ersetzen sie durch künstliche Äquivalente. Die klinischen Modelle von John Snow Labs erreichen 96% F1 bei PHI-Erkennung (vs. Azure 91%, AWS 83%, GPT-4o 79%) und verarbeiten dabei 100K+ klinische Notizen pro Tag.

Für LLM-Guardrails funktioniert NER als Pre-Screening-Layer: Nutzereingaben vor dem Senden an eine externe API auf PII scannen und dann blockieren oder anonymisieren. Das ist schneller und einfacher, als das LLM um Selbstmoderation zu bitten. GLiNER ist hier besonders nützlich, weil PII-Kategorien je nach Rechtsraum variieren. Du kannst neue Entitätstypen wie "genetic information" unter einer neuen Regulierung hinzufügen, ohne neu zu trainieren.

GLiNER schreibt die NER-Ökonomie mit einem Modell mit 300M Parametern neu

GLiNER (NAACL 2024, Zaratiana et al.) hat encoderbasiertes NER zu einem Bruchteil der Kosten konkurrenzfähig mit LLMs gemacht. Statt NER als Sequence Labeling oder Textgenerierung zu behandeln, behandelt GLiNER es als Matching-Problem: jeden Kandidaten-Text-Span (jede zusammenhängende Wortfolge wie "Bill Gates" oder "Microsoft") gegen jedes Entitätstyp-Label bewerten und dann die hoch bewerteten Paare behalten.

Das Modell nimmt Entitätstyp-Labels und Eingabetext als eine einzelne Sequenz: [ENT] person [ENT] organization [ENT] date [SEP] Bill Gates founded Microsoft.... Ein bidirektionaler Transformer (DeBERTa-v3) kodiert alles gemeinsam.

Aus der Ausgabe erzeugt das Modell zwei Repräsentationsmengen: eine für Entitätstypen (aus [ENT]-Tokenpositionen) und eine für Text-Spans (durch Kombination von Start- und End-Token-Vektoren über ein kleines FFN). Ein Dot Product zwischen einer Span-Repräsentation und einer Entitätstyp-Repräsentation ergibt einen Score.

Wendet man sigmoid an, erhält man die Wahrscheinlichkeit, dass der Span von Token \(i\) bis Token \(j\) zum Entitätstyp \(t\) gehört: \(\\phi(i, j, t) = \\sigma(S_{ij}^T \\cdot q_t)\), wobei \(S_{ij}\) der vom FFN erzeugte Span-Vektor ist und \(q_t\) das Entitätstyp-Embedding aus dem entsprechenden [ENT]-Token (Zaratiana et al., 2024, Gl. 1). Spans sind auf 12 Token begrenzt, um die Geschwindigkeit hochzuhalten.

GLiNER-Architektur: Entitätstyp-Token und Text-Token werden gemeinsam von DeBERTa kodiert, dann werden Span-Repräsentationen per Dot Product gegen Entitätstyp-Embeddings bewertet

In der Praxis bedeutet das, dass jede natürlichsprachliche Beschreibung zur Inferenzzeit als Label funktioniert. Kein Retraining. Du gibst einfach die gewünschten Entitätstypen an ("person", "adverse drug reaction", "financial instrument"), und das Modell bewertet Spans dagegen. Es gibt drei Größen: GLiNER-S (50M Parameter), GLiNER-M (90M) und GLiNER-L (300M). Die Trainingsdaten stammen aus dem Pile-NER-Datensatz: 44.889 Passagen mit 240K Entitätsspans über 13K Entitätstypen, alle von ChatGPT gelabelt. Das Training von GLiNER-L dauert etwa 4 Stunden auf einer einzelnen A100 (Zaratiana et al., 2024).

Benchmark-Ergebnisse

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

Model Params CrossNER F1 Avg (20 datasets)
GLiNER-L 300M 60.9% 47.8%
GoLLIE 7B 58.0% --
UniNER-13B 13B 55.6% --
GLiNER-M 90M 55.4% --
UniNER-7B 7B 53.7% 45.7%
GLiNER-S 50M 52.7% --
ChatGPT (GPT-3.5) -- 47.5% 36.5%

GLiNER-M mit 90M Parametern erreicht fast UniNER-13B (55.4% vs. 55.6% F1) und ist dabei 140x kleiner. Selbst das kleine GLiNER-S mit 50M schlägt ChatGPT (GPT-3.5) um 5 F1-Punkte. Die mehrsprachige Variante — nur auf englischen Daten trainiert — schlägt ChatGPT in 8 von 10 nicht-englischen Sprachen (Zaratiana et al., 2024). Hinweis: Neuere LLMs (GPT-5.4, Claude 4.6) erzielen auf diesen Benchmarks wahrscheinlich höhere Werte, aber die Kostenlücke ist nur größer geworden — diese Modelle sind weiterhin Größenordnungen teurer als ein 90M-Encoder auf CPU.

Das Ökosystem ist groß: 280+ GLiNER-kompatible Modelle auf HuggingFace, etwa 350.000 PyPI-Downloads pro Monat, etwa 2.800 GitHub-Stars. Varianten decken biomedizinische Texte, PII-Erkennung, Nachrichten und Mehrsprachigkeit ab.

Aus 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']} ({entity['score']:.3f})")
# Bill Gates => person (0.987)
# Microsoft => organization (0.991)
# April 4, 1975 => date (0.974)

Wie GLiNER im Vergleich zu spaCy abschneidet

Jeder NER-Leitfaden wäre unvollständig ohne spaCy — ~21M Downloads pro Monat, die Kakerlake unter den NLP-Bibliotheken (liebevoll gemeint — sie überlebt alles). Aber spaCy löst ein anderes Problem als GLiNER.

Die spaCy-Pipelines (en_core_web_sm, en_core_web_trf) machen Closed-Vocabulary-NER: ein festes Set an Entitätstypen (PERSON, ORG, GPE, DATE usw.), das beim Training definiert wird. Du willst einen neuen Entitätstyp? Dann musst du gelabelte Daten sammeln und neu trainieren. Das transformerbasierte en_core_web_trf erreicht 89.8% F1 auf OntoNotes 5.0, aber nur für seine 18 vordefinierten Typen.

GLiNER macht Open-Vocabulary-NER: Jedes Label funktioniert zur Inferenzzeit, Retraining ist nicht nötig. Das macht es zur besseren Wahl, wenn Entitätstypen im Voraus unbekannt sind, sich häufig ändern oder domänenspezifisch sind ("adverse drug reaction", "financial instrument", "threat indicator").

Meine Empfehlung: Nutze spaCy für Standard-Entitätstypen, bei denen vortrainierte Pipelines gut validiert sind. Nutze GLiNER, wenn du flexible, Zero-Shot-Typen brauchst oder wenn sich deine Pipeline ohne Retraining anpassen muss. Beide funktionieren gut zusammen — spaCy übernimmt Tokenisierung und Satzsegmentierung, GLiNER die Entitätsextraktion.

UniNER und NuNER: Wie klein kann man gehen?

UniNER (ICLR 2024, Zhou et al.) und NuNER (EMNLP 2024, Bogdanov et al.) destillieren beide LLM-Annotationen in kleinere NER-Modelle — aber sie sind sich uneinig, wie klein man gehen kann.

UniNER: Der maximalistische Weg

UniNER finetuned LLaMA-7B/13B auf 44.889 NER-Paaren (240K Entitäten, 13K Typen), die von ChatGPT erzeugt wurden. Für jeden Entitätstyp beantwortet das Modell "What describes [type] in the text?" und gibt JSON-Listen aus. Ein zentraler Trainingstrick: frequenzbasiertes negatives Sampling steigert F1 von 31.5% auf 53.4% (Zhou et al., 2024).

UniNER-7B erreicht 41.7% Zero-Shot-F1 über 43 Datensätze hinweg — 7 Punkte besser als ChatGPT mit 34.9%. Die 13B-Variante kommt auf 43.4%, also nur 1.7 Punkte mehr bei fast doppeltem Compute-Bedarf (Zhou et al., 2024).

Das Produktionsproblem: Als autoregressives 7B-Modell benötigt UniNER N Forward Passes für N Entitätstypen, braucht 14GB+ VRAM (damit ist dein GPU-Budget vor dem Mittagessen weg) und hat eine restriktive CC BY-NC 4.0-Lizenz.

NuNER: Der minimalistische Weg

NuNER startet von RoBERTa-base (125M Parameter) und nutzt kontrastives Training mit 4,38 Millionen GPT-3.5-Annotationen über 200K Konzepte — Gesamtkosten für Annotation unter \$500. Nach dem Training wird der Konzept-Encoder verworfen; der Text-Encoder kann als RoBERTa-Ersatz in jede Standard-NER-Pipeline eingesetzt werden (Bogdanov et al., 2024).

Die Ergebnisse: NuNER schlägt einfaches RoBERTa über alle Few-Shot-Größen hinweg um 6-15 F1-Punkte. Mit nur einem Dutzend Beispiele pro Entitätstyp erreicht NuNER UniNER-7B, obwohl es 56x kleiner ist (Bogdanov et al., 2024).

Beide Papers zeigen dasselbe: Die Destillation von LLM-Annotationen in kleinere Modelle erzeugt NER, das den Lehrer schlägt. Und du brauchst keine 7B Parameter — 125M reichen aus, wenn Fine-Tuning-Daten verfügbar sind, mit MIT-Lizenz und CPU-freundlicher Inferenz.

GLiNER 2: Ein Modell, vier Aufgaben

Das ursprüngliche GLiNER-Ökosystem hatte ein wachsendes Problem: separate Modelle für NER (GLiNER), Relation Extraction (GLiREL), Klassifikation (GLiClass) und dokumentweite RE (GLiDRE) — jedes mit eigenem Deployment, eigenem Docker-Container und eigenem Eintrag in deiner Tabelle "services we pray don't break". GLiNER 2 (EMNLP 2025, Zaratiana et al.) führt alle vier in einem einzigen 205M-Parameter-Modell mit schema-getriebener Schnittstelle zusammen.

Die Architektur behält das Cross-Encoder-Design bei, erweitert aber den Kontext auf 2.048 Token (4x das Original) und ergänzt deklarative Schemas zur Definition von Extraktionsaufgaben. Das Training nutzt 135.698 reale Dokumente, annotiert mit GPT-4o, plus 118.636 synthetische Beispiele (Zaratiana et al., 2025).

Auf Zero-Shot-CrossNER erzielt GLiNER 2 0.590 F1 — nahe an den 0.599 von GPT-4o, wie im Paper benchmarked (Mitte 2025). Neuere Modelle wie GPT-5.4 erreichen wahrscheinlich höhere Werte, aber zu einem Bruchteil der Geschwindigkeit und Kosten von GLiNER 2. Für Klassifikation erreicht es 0.72 im Mittel über 7 Benchmarks und schlägt damit DeBERTa-v3-large (0.69). Auf CPU läuft Klassifikation mit GLiNER 2 in 130-208ms, unabhängig von der Label-Anzahl. DeBERTa skaliert linear: 1.714ms für 5 Labels, 16.897ms für 50 (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"))
results = extractor.extract(text, schema)

Ein Modell-Deployment ersetzt vier. Einfachere Infrastruktur, wettbewerbsfähige Genauigkeit.

Der Bi-Encoder: Skalierung auf NER mit Millionen Labels

Das ursprüngliche GLiNER kodiert Labels und Text gemeinsam — und genau das erzeugt einen Bottleneck. Mehr Entitätstypen bedeuten eine längere Eingabesequenz, und die Performance fällt jenseits von ~30 Typen schnell ab. Der GLiNER Bi-Encoder (Februar 2026, Stepanov et al.; arXiv 2602.18487) behebt das, indem Text- und Label-Encoding in zwei separate Transformer aufgeteilt werden.

Cross-Encoder vs. Bi-Encoder: Der Cross-Encoder kodiert Labels und Text gemeinsam, während der Bi-Encoder separate Encoder mit vorab berechneten Label-Embeddings verwendet

Der Text-Encoder nutzt ModernBERT (Ettin-Familie), der Label-Encoder Sentence Transformers (BGE oder MiniLM). Spans und Labels werden per Dot Product bewertet. Der Trick: Entitätstyp-Embeddings können einmal vorab berechnet und gecacht werden. Zur Inferenzzeit muss nur noch der Text kodiert werden — Label-Lookup erfolgt sofort.

Vier Modellgrößen sind verfügbar, alle auf CrossNER benchmarked (Stepanov et al., 2026, Tabelle 1):

Model Parameters CrossNER F1 Throughput (H100) With Pre-computed Labels
bi-edge-v2.0 60M 54.0% 13.64 ex/s 24.62 ex/s
bi-small-v2.0 108M 57.2% 7.99 ex/s 15.22 ex/s
bi-base-v2.0 194M 60.3% 5.91 ex/s 9.51 ex/s
bi-large-v2.0 530M 61.5% 2.68 ex/s 3.60 ex/s

Bei 1.024 Entitätstypen verliert der Bi-Encoder (edge, vorab berechnet) gegenüber einem einzelnen Label nur 5.2% Durchsatz. Der Cross-Encoder verliert 98.7% (10.7 → 0.14 ex/s). Das ist ein 130x Durchsatzvorteil im großen Maßstab. Mit 100 Entitätstypen auf einer einzelnen H100 verarbeitet der Bi-Encoder 1,96 Millionen Vorhersagen pro Tag gegenüber 368K für den Cross-Encoder (Stepanov et al., 2026).

Auch die Genauigkeit hält sich. Bi-encoder-large erreicht 61.5% CrossNER F1 und liegt damit leicht vor den 60.9% des Cross-Encoders. Die Autoren empfehlen bi-base-v2.0 (194M) als Sweet Spot, da es 98% der Genauigkeit des großen Modells bei 2,6x Geschwindigkeit erreicht (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)

Anwendungsfälle umfassen biomedizinisches NER gegen die UMLS-Ontologie (4M+ Konzepte), Enterprise-Taxonomien, die sich ohne Modell-Retraining weiterentwickeln, und Entity Linking über das begleitende Framework GLiNKER.

LLMs als Lehrer: Die \\(70-Pipeline, die das \\\)8/Stunde-Modell schlägt

Das LLM-as-Teacher-Muster ist zu einer Standardpipeline in der Produktion geworden. Drei Studien zeigen, was es kostet und was man dafür bekommt.

Die LLM-as-Teacher-Pipeline: Das LLM labelt Rohdaten, Menschen prüfen einen Teil, der Encoder wird feinabgestimmt und zu 80x geringeren Kosten deployt

Die CFM-Fallstudie

Capital Fund Management extrahierte Firmennamen aus ~900K Schlagzeilen zu Finanznachrichten. Zero-Shot-GLiNER erreichte 87.0% F1. Sie nutzten Llama 3.1-70b (damals das stärkste offene Modell), um den kompletten Datensatz in ~8 Stunden für ~\$70 zu annotieren, und prüften anschließend 2.714 Samples in weiteren 8 Stunden manuell über Argilla.

Das Fine-Tuning von GLiNER auf diesen Daten steigerte die Performance auf 93.4% F1 — und schlug sogar den Llama-70b-Lehrer mit 92.7%. Das feinabgestimmte Modell läuft für \\(0.10/Stunde auf CPU** gegenüber \\\)8/Stunde für den Lehrer — 80x günstiger** bei besserer Genauigkeit (CFM Case Study). Heute würdest du mit Llama 4 Maverick oder GPT-5.4 Mini noch bessere Lehrer-Annotationen zu ähnlichen oder geringeren Kosten bekommen.

Die Refuel-AI-Studie

Refuel AI benchmarkte LLM-Labeling auf 8 NLP-Datensätzen, darunter CoNLL-2003. GPT-4 (März 2023) erreichte 88.4% Übereinstimmung mit Ground Truth — über den 86.2% erfahrener menschlicher Annotatoren. LLMs waren 20x schneller und 7x günstiger. Ihr Ensembling-Ansatz — günstige Modelle für einfache Beispiele, GPT-4 für schwierige — erreichte 95%+ Übereinstimmung bei gleichzeitig niedrigen Kosten (Refuel AI Technical Report). Mit GPT-5.4 und Claude 4.6 ist die Lehrerqualität inzwischen nur besser geworden.

Tonic.ai Clinical NER

Tonic.ai zeigte, dass das Muster auch für klinisches NER funktioniert. LLM-Annotationen allein trainierten ein RoBERTa-LoRA-Modell auf 0.70 F1 auf dem NCBI Disease Corpus (vs. 0.81 mit vollständig menschlich gelabelten Daten). Bei der Extraktion von Healthcare-IDs erreichte es 0.947 F1 — über dem Produktionsschwellenwert von 0.914 — ganz ohne menschlich gelabelte Daten.

Die Standardpipeline

Das Produktionsrezept hat sich auf sechs Schritte eingependelt:

  1. Annotationsrichtlinien in natürlicher Sprache schreiben
  2. Ein kleines, von Menschen gelabeltes Validierungsset anlegen (50-200 Dokumente)
  3. Ein LLM (GPT-5.4 Mini, Llama 4 Maverick oder Qwen3.5) verwenden, um Bulk-Trainingsdaten zu labeln
  4. Einen Teil über Argilla oder Label Studio prüfen
  5. Einen kompakten Encoder feinabstimmen (GLiNER, SpanMarker, RoBERTa)
  6. Zu 16-80x geringeren Inferenzkosten deployen

Die Kosten von NER sind nicht mehr "alle Trainingsdaten annotieren, indem man eine Armee von Studierenden anheuert". Es ist jetzt: "ein gutes Validierungsset bauen, klare Richtlinien schreiben und das LLM den Rest machen lassen".

Wo GLiNER scheitert und LLMs essenziell bleiben

Der Sease-Benchmark (Oktober 2025) testete GLiNER gegen GPT-4.1-mini auf 30 Query-Parsing-Aufgaben. GPT-4.1-mini erzielte 100% vollständig korrekte Ergebnisse. GLiNER erreichte 53% (16 von 30). Aber GLiNER antwortete in 0.08 Sekunden gegenüber 1.21 Sekunden für das LLM — also 15x schneller.

GLiNER scheitert in drei spezifischen Mustern:

  1. Implizite Entitäten: "event" aus "Elton John performed at Madison Square Garden" extrahieren — im Text steht nicht wörtlich "event", aber das LLM inferiert "concert"
  2. Sensitivität gegenüber Label-Formulierungen: "2022" erhält einen Score von 0.388 gegen "date", aber 0.958 gegen "year" — kleine Label-Änderungen verursachen große Score-Sprünge
  3. Value Mapping: GLiNER gibt den exakten Oberflächentext ("family houses") zurück statt des kanonischen Werts ("Single family house") — LLMs machen das natürlich

Verschachtelte und überlappende Entitäten

GLiNER hat auch Probleme mit verschachtelten Entitäten. In "New York University" würde ein Mensch vielleicht sowohl "New York" (LOCATION) als auch "New York University" (ORGANIZATION) labeln. GLiNER wählt nur den Span mit dem höchsten Score. Das ist in biomedizinischen Texten wichtig ("acute myeloid leukemia" enthält sowohl eine Krankheit als auch einen Modifikator) und in juristischen Texten (verschachtelte Organisationshierarchien). Spezialisierte Modelle können Verschachtelung verarbeiten, aber GLiNERs Flat-Span-Design nicht.

In der Praxis: GLiNER übernimmt explizite Entitätsextraktion — den Kern von Produktions-NER. LLMs kommen ins Spiel, wenn Extraktion Inference, Reasoning oder Mapping auf vordefinierte Ontologien erfordert. Nutze beides.

NER evaluieren: Metriken, Fallstricke und Testsets aufbauen

Ich habe Teams Modelle mit 95% F1 auf ihrem Testset deployen sehen, die in Produktion scheiterten — weil das Testset nicht die reale Dokumentverteilung abbildete. Dein Testset ist nicht deine Produktionsdaten. Ich weiß, das klingt offensichtlich. Ich habe trotzdem gesehen, wie es schiefgeht.

Die Kernmetriken

  • Entity-level F1: Die Standardmetrik. Eine Vorhersage ist nur dann korrekt, wenn sowohl die Span-Grenzen als auch der Typ exakt mit der Ground Truth übereinstimmen. Das berichten die meisten Papers.
  • Token-level F1: Bewertet jedes Token unabhängig. Bläht Ergebnisse auf, weil man für den Großteil einer langen Entität Teil-Credit bekommt. Bevorzuge Entity-level F1.
  • Precision vs Recall: Diese haben oft asymmetrische Kosten. Für De-Identifikation ist Recall wichtiger — einen Namen zu übersehen ist schlimmer als zu viel zu schwärzen. Für Datenbankextraktion ist Precision wichtiger — False Positives korrumpieren nachgelagerte Analysen.

Häufige Evaluationsfehler

  1. Inflation durch Partial Matches: "Bill" wurde extrahiert, während das Gold-Label "Bill Gates" ist — manche Skripte zählen das als partiellen Treffer. Nutze exaktes Span-Matching, wenn du keinen guten Grund dagegen hast.
  2. Typverwechslung: "Microsoft" wurde korrekt als Span erkannt, aber als PERSON statt ORG gelabelt, sollte null Punkte bekommen. Prüfe, ob dein Evaluationscode das korrekt behandelt.
  3. Leakage im Testset: Wenn Test-Entitäten mit Trainings-Entitäten überlappen, werden Scores aufgebläht. Zero-Shot-Benchmarks (CrossNER, Few-NERD) existieren, um Generalisierung zu testen.

Ein Domänen-Testset aufbauen

Für Produktionsevaluation empfehle ich:

  1. Aus Produktionsdaten samplen, nicht aus kuratierten Beispielen. Nimm die chaotischen Dokumente auf, die dein Modell tatsächlich sehen wird.
  2. 200-500 annotierte Dokumente liefern stabile F1-Schätzungen. Unter 100 sind die Konfidenzintervalle zu breit.
  3. Mindestens zwei Annotatoren, mit Inter-Annotator-Agreement (Cohen's kappa > 0.8). Wenn Menschen sich nicht einig sind, kann dein Modell nicht besser sein.
  4. Nach Schwierigkeit stratifizieren — einfache Fälle (sauberer Text, Standardtypen) und schwierige Fälle (mehrdeutige Entitäten, Jargon, verrauschter Text).

Produktions-NER in vier Branchen

Hier sind die ausgereiftesten NER-Deployments, die ich gefunden habe, mit konkreten Zahlen.

Gesundheitswesen

Das Gesundheitswesen hat die ausgereiftesten NER-Tools. John Snow Labs hat 2.500+ vortrainierte Modelle, darunter 1.200+ für Healthcare, die 400+ klinische Entitätstypen abdecken und auf ICD-10, SNOMED CT, LOINC und RxNorm gemappt sind. Ihre De-Identifikationsmodelle erreichen 96% F1 (vs. Azure 91%, AWS 83%, GPT-4o 79%), wobei Providence St. Joseph Health täglich 100K-500K klinische Notizen verarbeitet.

Das Open-Source-OpenMed-Projekt bietet 380+ biomedizinische NER-Modelle mit 29.7M HuggingFace-Downloads und setzt auf 10 von 12 öffentlichen biomedizinischen Benchmarks neue Bestwerte.

Financial NER

Der wichtigste Use Case: SEC-Filing-Extraktion. Finance NLP von John Snow Labs extrahiert 11+ Entitätstypen aus 10-K/10-Q-Filings (Adressen, Ticker, Geschäftsjahre, Börsenplätze). Varianten von FinBERT-MRC erreichen 0.87-0.93 F1 bei finanziellen Entitätsaufgaben. Die zentrale Herausforderung: lange Dokumente und verschachtelte Entitäten in komplexen Finanzinstrumenten.

E-Commerce

NER im massiven Maßstab. Walmarts EAMT-System (KDD 2023) trainiert auf 965 Millionen Queries mit ~60 Entitätslabels und erzeugt in A/B-Tests einen 0.51% GMV-Lift — Millionen an zusätzlichem Umsatz. Das Framework TripleLearn von Home Depot (AAAI 2021) steigerte NER-F1 durch iteratives Training von 69.5 auf 93.3.

Cybersicherheit

Das iACE-System (CCS 2016) verarbeitete 71.000 Artikel aus 45 Security-Blogs und extrahierte 900K IOC-Items bei 98% Precision und 93% Recall. Moderne Systeme wie CyNER kombinieren DeBERTa (F1 >91%) mit regexbasierten IOC-Heuristiken. Der vereinheitlichte Datensatz CyberNER (2025) harmonisiert vier Datensätze in 21 an STIX 2.1 ausgerichtete Entitätstypen, wobei RoBERTa 0.736 F1 erreicht.

Deployment-Optimierung: Von Python zu Inferenz unter einer Millisekunde

Ich habe im Begleit-Repo drei Wege getestet, um GLiNER für die Produktion zu beschleunigen.

ONNX-Export

GLiNER hat native ONNX-Konvertierung, und vorab konvertierte Modelle existieren auf HuggingFace (onnx-community/gliner_small-v2.1). ONNX Runtime liefert auf CPU 1.5-3x Geschwindigkeitsgewinn gegenüber PyTorch, mit vier Optimierungsstufen von basic bis mixed-precision.

Aus onnx_export.py:

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

# Load ONNX model — same API, faster inference
from gliner import GLiNER
model = GLiNER.from_pretrained("path/to/model", load_onnx_model=True)

# Same predict_entities call, 1.5-3x faster on CPU
entities = model.predict_entities(text, labels, threshold=0.5)

INT8-Quantisierung

Dynamische Quantisierung schrumpft Modelle um 2.4x (438MB → 181MB) bei weniger als 0.6% F1-Verlust. Die Geschwindigkeit verbessert sich auf CPU um 1.8x. Auf Intel-VNNI-CPUs mit ONNX Runtime erreicht INT8 bis zu 6x Speedup gegenüber PyTorch FP32.

from onnxruntime.quantization import quantize_dynamic, QuantType

# One-line quantization — 2.4x smaller, <1% F1 loss
quantize_dynamic("gliner.onnx", "gliner_int8.onnx", weight_type=QuantType.QInt8)

gline-rs: Rust-Reimplementierung

gline-rs (Apache 2.0) eliminiert Python-Overhead. Auf CPU: 6.67 seq/s gegenüber 1.61 in Python — ein 4.1x Speedup. Auf einer RTX 4080: 248.75 seq/s (gline-rs benchmarks). Es unterstützt Span- und Token-Modelle, GPU/NPU via ONNX Runtime und wird als Crate auf crates.io ausgeliefert.

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 Paket fast-gliner stellt Python-Bindings via PyO3 bereit — Rust-Geschwindigkeit mit Python-Ergonomie.

Zusammenfassung des Optimierungs-Stacks

Optimization Speedup vs PyTorch Model Size F1 Impact Best For
ONNX Runtime 1.5-3x Same None Quick win, any hardware
INT8 Quantization 3-6x 2.4x smaller <0.6% loss CPU deployment, memory-constrained
gline-rs (Rust) 4.1x (CPU) ONNX format None High-throughput, latency-critical
gline-rs + INT8 4-8x 2.4x smaller <1% loss Production at scale

Strukturierte Extraktion: Instructor vs. Outlines

Wenn du mehr Flexibilität brauchst, als Encoder-Modelle bieten — implizite Entitäten, Reasoning, Ontology Mapping — übernehmen zwei Bibliotheken die strukturierte Extraktion aus LLMs.

Instructor (~12.600 GitHub-Stars, ~8.8M Downloads/Monat im März 2026) von Jason Liu patcht LLM-SDKs so, dass sie Pydantic-Response-Modelle akzeptieren, mit automatischen Retries bei Validierungsfehlern. Es unterstützt 15+ Provider und inspirierte OpenAIs native Structured-Output-Funktion.

Aus 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 (~13.600 GitHub-Stars) von dottxt verfolgt einen anderen Ansatz: konstruierte Tokengenerierung via Finite State Machines. Statt erst Output zu generieren und bei Validierungsfehlern neu zu versuchen, verhindert Outlines ungültige Tokens von vornherein — 100% Schema-Compliance, keine Retries. AWS-Benchmarks zeigen 98% Schema-Adherence gegenüber 76% bei Post-Generation-Validierung, mit 5x schnellerer Generierung im Vergleich zu unbeschränkter Generierung mit nachträglichen Validierungs-Retries.

import outlines

model = outlines.models.transformers("microsoft/Phi-3-mini-128k-instruct")
generator = outlines.generate.json(model, ExtractEntities)
result = generator("Extract entities from: BioNTech SE acquired InstaDeep in the U.K.")

Die Wahl hängt davon ab, wo du deine Modelle ausführst. Instructor ist am besten für Cloud-LLM-APIs — schnelles Prototyping, Multi-Provider-Support, vertraute Pydantic-Muster. Outlines gewinnt bei lokalen Modellen, wenn du Formatgarantien ohne externe Abhängigkeiten brauchst. Beide funktionieren gut für NER-artige Extraktion, aber keiner erreicht den Durchsatz von Encodern: Instructor fügt pro Aufruf 200ms-2s API-Latenz hinzu, und Outlines hängt von der Geschwindigkeit lokaler Modelle ab. Für NER mit hohem Durchsatz sind Encoder weiterhin 10-100x schneller.

Die 3-stufige Produktionsarchitektur

So würde ich all das für produktives NER zusammensetzen.

Die 3-stufige Architektur: Encoder-Modelle verarbeiten 90%+ des Volumens zu niedrigen Kosten, GLiNER 2 übernimmt Multi-Task-Extraktion, und LLMs übernehmen die schwierigsten 10% und trainieren gleichzeitig Tier-1-Modelle

Tier 1 — Encoder-Modelle für bekannte Entitätstypen. GLiNER (Cross-Encoder für <30 Typen, Bi-Encoder für 30+), feinabgestimmt über die LLM-as-Teacher-Pipeline. Deployment mit ONNX + INT8 oder gline-rs. Verarbeitet >90% des Volumens bei unter 50ms Latenz und nahezu null Kosten. Der Bi-Encoder skaliert mit vorab berechneten Embeddings auf Millionen von Entitätstypen.

Tier 2 — GLiNER 2 für Multi-Task-Extraktion. Wenn eine Anfrage NER + Klassifikation + Relation Extraction + strukturierte Daten braucht, ersetzt das 205M-Parameter-Modell von GLiNER 2 vier Deployments. Es läuft auf CPU in 130-208ms unabhängig von der Label-Anzahl — gut für Dokumentpipelines, die mehrere Extraktionsaufgaben in einem Pass benötigen.

Tier 3 — LLMs für extraktionslastige Aufgaben mit viel Reasoning. Wenn Entitäten implizit sind, kontextuelle Inferenz brauchen oder Ontology Mapping erfordern, route zur LLM-Schicht (GPT-5.4 Mini, Claude Sonnet 4.6, Llama 4 Maverick) via Instructor (Cloud) oder Outlines (lokal). Das deckt die ~10% der Queries ab, die Encoder verpassen. Dieselben LLMs erzeugen auch Trainingsdaten für Tier 1.

Was kostet das? Ein feinabgestimmtes GLiNER erreicht 93.4% F1 bei \\(0.10/Stunde auf CPU** und entspricht damit den **92.7% F1** seines Llama-70b-Lehrers bei **\\\)8/Stunde — 80x günstiger.

Trade-offs und Grenzen

Nichts hiervon ist kostenlos. In ML gibt es immer einen Haken — die einzige Frage ist, wann du ihn entdeckst.

Fehler aus LLM-as-Teacher propagieren weiter. Wenn das LLM einen bestimmten Entitätstyp konsistent falsch erkennt (z. B. Tochtergesellschaften mit Muttergesellschaften verwechselt), übernimmt der feinabgestimmte Encoder diesen Bias. Die Lösung ist gezieltes menschliches Review — konzentriere den Aufwand auf Entitätstypen, bei denen die Konfidenz des LLM niedrig oder inkonsistent ist, statt zufällig zu sampeln.

Quantisierungsverluste sind nicht gleichmäßig. Der durchschnittliche F1-Verlust von ~0.6% durch INT8 kann bei seltenen Entitätstypen mit subtilen Boundary-Mustern größer ausfallen (chemische Verbindungen, mehrwortige Abkürzungen). Benchmarker quantisierte Modelle immer auf deinen konkreten Entitätstypen, nicht nur auf aggregiertem F1.

Wann die 3-stufige Architektur Overkill ist. Einzelne Domäne, klar definierte Entitätstypen, 500+ gelabelte Beispiele? Eine feinabgestimmte RoBERTa- oder spaCy-Pipeline ist einfacher und ausreichend. Das 3-Tier-Muster lohnt sich bei (a) mehreren Domänen, (b) sich entwickelnden Entitätstypen oder (c) einem Mix aus einfachen und schwierigen Extraktionsaufgaben. Wenn du nur Namen und Daten aus Rechnungen extrahierst, reicht Tier 1 allein.

Qualitätsgrenze des Bi-Encoders. Der Bi-Encoder tauscht gemeinsame Attention gegen Durchsatz. Wenn Label-Semantik mit Textkontext interagiert ("date" vs. "year" vs. "period" für denselben Span), gewinnt der Cross-Encoder weiterhin. Nutze Cross-Encoder für High-Stakes-Aufgaben mit wenigen Labels; Bi-Encoder für Breite.

Wichtige Erkenntnisse

  1. Encoder haben gewonnen. GLiNER und Bi-Encoder-Varianten schlagen LLMs auf Standard-NER-Benchmarks bei 80-130x geringeren Kosten. Selbst mit GPT-5.4 Nano und Llama 4, die Preise drücken, ist ein LLM für jede NER-Query nicht mehr zu rechtfertigen.
  2. LLMs sind essenziell — als Lehrer. Sie labeln Trainingsdaten für \$70, die menschliche Annotation Tausende kosten würde, und der feinabgestimmte Encoder schlägt am Ende typischerweise das LLM, das ihn trainiert hat.
  3. Der Bi-Encoder ermöglicht Skalierung auf Millionen Labels. Vorab berechnete Embeddings lösen das Problem quadratischer Komplexität, mit nur 5.2% Durchsatzverlust bei 1.024 Labels.
  4. GLiNER 2 konsolidiert Multi-Task-Extraktion. Ein 205M-Modell für NER + Klassifikation + RE + strukturierte Extraktion.
  5. Evaluiere auf deinen Daten. Nutze Entity-level F1, baue Testsets aus Produktionsdokumenten und benchmarke quantisierte Modelle auf deinen konkreten Entitätstypen.
  6. Nutze das Hybrid-Muster. Tier 1/2 für schnelle Extraktion, Tier 3 für Reasoning. Dieselben LLMs, die die schwierigsten 10% abdecken, erzeugen die Trainingsdaten für die 90%.

Referenzen

Papers

Industry Papers

Fallstudien

Tools und Frameworks