[!NOTE] Automatische Übersetzung Dieser Artikel wurde automatisch aus der englischen Originalversion übersetzt.

Der umfassende Leitfaden zu NER im Jahr 2026: Encoder, LLMs sowie die dreistufige Produktionsarchitektur

Die Erkennung benannter Entitäten (NER) erfolgt heute mithilfe von Spans-basierten kompakten Encodern, Open-Vocabulary Models-Methoden sowie extractionbasierten Ansätzen, die auf LLM beruhen. In den vorgestellten Ergebnissen von CrossNER übertrifft ein GLiNER mit 300 M Parametern Model die F1-Wert im Zero-Shot-Modus des 13B großen UniNER. Ein neuerer Bi-Encoder erreicht dabei 130 Mal so hohe Throughput-Werte wie der ursprüngliche Cross-Encoder bei 1.024 Entitätsarten. Diese Ergebnisse stützen ein praktikables Vorgehen für die explizite Span-Extraktion: Man verwendet zunächst einen LLM, um Domänendaten zu kennzeichnen, prüft anschließend eine Stichprobe, feinjustiert einen kompakten Encoder und setzt ihn schließlich unter Verwendung von ONNX oder Rust in Produktion.

Der begleitende Repository enthält ausführbare Beispiele für GLiNER. ONNX exportieren, LLM-eingebildete Trainingsetiketten sowie strukturierte Extraktion. Für Arbeitslasten, die von expliziten Daten dominiert werden SpansCompakte Encoder bieten eine hohe Leistungsfähigkeit. Latency sowie der Kostenpfad. LLMs bleiben weiterhin nützlich zur Erstellung von Trainingsdaten sowie zur Bearbeitung von Fällen, die eine solche Verarbeitung erfordern. Inference oder Normalisierung.

Zusatz-Repository: ner-Feldleitfaden, zusammen mit ausführbaren Demos für GLiNER, ONNX Export, den LLM-als-Lehrer Pipeline sowie für strukturierte Extraktion mithilfe von Instructor.

TL;DR: Verwenden Sie GLiNER, wenn Sie ein offenes Wortschatzkonzept benötigen. Span Extraktion und CPU Deployment. Für domänenspezifische Aufgaben sollten Sie den LLM-as-Lehrer- Pipeline: Erstellen von Labels, Überprüfung eines Beispiels, Feinabstimmung eines Encoders sowie Bewertung desselben anhand eines von Menschen gelabelten Datensatzes. Weiterhin die Verarbeitung impliziter Entitäten, das Ontologie-Mapping sowie weitere Reasoning-Einsatzfälle mit hohem Aufwand an LLM über Instructor oder Outlines. Die dreistufige Architektur kombiniert diese Pfade, ohne von einem festen Verkehrsanteil auszugehen.


Wo moderne Systeme NER einsetzen

NER erkennt weiterhin Spans-Elemente im Text und weist ihnen Etiketten zu. Was sich geändert hat, ist seine Position innerhalb des Systems: Mittlerweile stellt es Filter für RAG bereit, strukturierte Argumente für Agent-Tools sowie Felder für die Verarbeitung von Dokumenten im Rahmen von Pipelines. Dadurch werden Latency, die Kosten sowie die Skalierbarkeit der Strukturen genauso wichtig wie die Benchmark-Genauigkeit.

RAG: Verbesserung von Retrieval durch Entitätenextraktion

Eine reine Ähnlichkeitssuche stößt an Grenzen, wenn eine Anfrage exakte Entitäten enthält. Bei der Frage „Was hat Anthropic zu Model-Sicherheit im vierten Quartal 2024 gesagt?“ sollte das System „Anthropic“ sowie „Q4 2024“ als Metadatenfilter extrahieren, anstatt sich ausschließlich auf Embeddings zu verlassen.

Während des Indexierens extrahieren Sie Entitäten aus jedem Chunk und speichern diese als Metadaten: {"organizations": ["Anthropic"], "dates": ["Q4 2024"], ...}. Dadurch können Sie vor dem Ausführen von Vector Search nach Entitäten filtern. Knowledge Graphs RAG (GraphRAG, LlamaIndex Property Graphs) gehen noch einen Schritt weiter: Durch NER in Kombination mit Relationsextraktion entsteht ein Graph, der mehrstufige Fragen beantworten kann, die einfache Embeddings-Strukturen nicht bewältigen können.

Während der Abfragedauer steuern die aus der Anfrage des Benutzers extrahierten Entitäten Routing. Eine Frage, in der ein Firmenname erwähnt wird, wird an einen Finanzindex weitergeleitet; eine Frage mit genannten Arzneimittelnlandnamen gelangt hingegen in eine klinische Wissensdatenbank. GLiNER eignet sich hier hervorragend, da die Abfragenentitäten unvorhersehbar sind – es ist nicht möglich, für jeden neuen Entitätstyp, den Nutzer fragen könnten, erneut zu trainieren.

AI Agents: Umwandlung von Text in strukturierte Fakten

Agents erhalten unstrukturierte Texte – Webseiten, API-Antworten sowie Benutzernachrichten – und müssen darauf reagieren. NER wandelt diesen Text in strukturierte Fakten um, über die die Agent logisch arbeiten, speichern oder an andere Tools weitergeben kann.

Zwei Bereiche, in denen es am wichtigsten ist.

Der erste Fall betrifft ein Tool Routing. Wenn ein Benutzer sagt „Planen Sie ein Treffen mit Sarah Chen von Accenture für Donnerstag um 14:00 Uhr“, muss der Agent diese Informationen extrahieren PERSON: Sarah Chen, ORGANIZATION: Accenture, und DATETIME: Thursday 2pm vor dem Aufruf des Kalenders API. Ein Encoder NER Model erledigt dies in weniger als 10 ms. Ein LLM verursacht pro Aufruf einen Zeitverzug von 1–2 Sekunden, wobei sich diese Verzögerung bei mehrstufigen Workflows-Abläufen summiert, bis eine ursprünglich „schnelle“ Agent-Verarbeitung nicht mehr als solche wahrgenommen wird.

Der zweite Aspekt betrifft das Tracking von Entitäten über mehrere Gespräche hinweg. Agent Memory-Systeme müssen erkennen können, dass „Sarah“ in Turnus 3 und „Frau Chen“ in Turnus 12 dieselbe Person sind. NER identifiziert die Spans; die Entitätsverknüpfung stellt anschließend eine Zuordnung zu derselben ID her.

In beiden Fällen gilt die Beschränkung durch Latency. Ein 200 ms langer NER-Aufruf innerhalb einer 10-stufigen Agent-Kette führt zu einer insgesamt 2 Sekunden langen wahrnehmbaren Verzögerung. Aus diesem Grund sind Encoder Models – und nicht extraktionsbasierte Verfahren auf Basis von LLM – die richtige Wahl für die Entity-Verarbeitung innerhalb von Agent-Schleifen.

Dokumentintelligenz: Vom Bild zum strukturierten Datenformat

OCR wandelt Bilder in Text um. NER wandelt Text in strukturierte Felder um. Gemeinsam ermöglichen sie die skalierte Digitalisierung von Dokumenten.

Ein herkömmlicher Pipeline nutzt zunächst OCR, wie beispielsweise Tesseract, Azure Document Intelligence oder AWS Textract, um Text sowie Begrenzungskästen zu erzeugen. Anschließend extrahiert der NER Felder wie invoice_number, vendor_name, line_items, total, und due_date.Die gleiche Vorgehensweise gilt für Verträge, Krankenakten sowie regulatorische Unterlagen.

Moderne Plattformen kombinieren drei Schritte: das Verständnis der Struktur (handelt es sich um einen Überschriftsblock oder um ein Tabellenzelle?), die Extraktion von Entitäten (welcher Texttyp liegt vor?) sowie die Extraktion von Beziehungen (welche Werte gehören zusammen?). GLiNER 2 bewältigt alle drei Schritte in einem einzigen Vorwärtslauf; eine einzige Aufrufung von Model kann die Ergebnisse liefern. {vendor: "Acme Corp", amount: "\$4,200", due_date: "2026-04-15"} aus einer Rechnung.

Genau hier spielt die Kostenfrage eine entscheidende Rolle. Der Preis für Pipeline sollte an dem tatsächlichen monatlichen Dokumentenvolumen festgelegt werden – einschließlich aller Wiederholungsversuche und Überprüfungen. Ein kompakter Encoder kann auf CPU laufen, während ein auf API basierender LLM zusätzliche Kosten pro Dokument in Form von Inference sowie Latency verursacht. Ein praktischer Test besteht darin, eine repräsentative Gruppe von Rechnungen mit einem LLM zu kennzeichnen, GLiNER anhand der überprüften Datensätze fein abzustimmen und anschließend beide Ansätze hinsichtlich der Feldebene, der Latency-Werte sowie der Gesamtkosten miteinander zu vergleichen.

Erkennung personenbezogener Daten und LLM Guardrails

Durch Datenschutzvorschriften wie GDPR, HIPAA und CCPA ist es erforderlich, personenbezogene Daten bereits vor deren Erreichen von nachgelagerten Systemen aufzuspüren. Im Kontext von LLM Deployments bedeutet dies das Scannen der Eingaben, bevor diese den Model erreichen, sowie das Scannen der Ausgaben, bevor sie den Endnutzer erreichen.

NER kümmert sich direkt darum. Die Models Entdeidentifizierung findet statt. PERSON, SSN, PHONE, EMAIL, und ADDRESS Spans müssen entweder entfernt oder durch synthetische Äquivalente ersetzt werden. In seinem eigenen Vergleich der Anbieter, John Snow Labs gibt Berichte heraus. 96 % F1‑Wert bei der Erkennung von PHI – im Vergleich zu Azure mit 91 %, AWS mit 83 % und GPT-4o mit 79 %. Ein separater Bericht über Deployment beschreibt, dass Providence täglich mehr als 100.000 klinische Notizen verarbeitet.

Für LLM Guardrails fungiert NER als Vorfilterungsschicht: Sie prüft die von Benutzern eingegebenen Daten auf PII, bevor diese an eine externe API übermittelt werden, und blockiert oder anonymisiert die betreffenden Informationen anschließend. Dies ist schneller und einfacher, als von der LLM zu verlangen, dass sie selbst reguliert. GLiNER ist in diesem Zusammenhang besonders nützlich, da sich die Kategorien von PII je nach Rechtsgebiet unterscheiden. Unter neuen Vorschriften können neue Entitätsarten wie „gentechnische Informationen“ hinzugefügt werden, ohne dass ein Neutraining erforderlich ist.


GLiNER verändert die Wirtschaftswissenschaften durch einen NER mit 300 Millionen Parametern eines Model

GLiNER (NAACL 2024, Zaratiana et al.) machte encoderbasierte NER-Ansätze im Wettbewerb mit LLMs konkurrenzfähig – und zwar zu einem Bruchteil der Kosten. Anstatt NER als Sequenzkennzeichnung oder Textgenerierung zu betrachten, behandelt GLiNER dies als ein Abgleichsproblem: Jeder mögliche Text Span (jede kontinuierliche Wortfolge wie „Bill Gates“ oder „Microsoft“) wird gegen jede mögliche Entitätsart-Label verglichen, wobei anschließend nur die hochbewerteten Paare behalten werden.

Der Model empfängt die Typbezeichnungen der Entitäten sowie den Eingabetext als eine einzige Sequenz: [ENT] person [ENT] organization [ENT] date [SEP] Bill Gates founded Microsoft.... Ein bidirektionaler Transformer (DeBERTa-v3) kodiert alles gemeinsam.

Aus dem Ausgabeergebnis erstellt der Model zwei Mengen an Repräsentationen: eine für Entity-Typen (aus [ENT] an den Positionen von Token sowie einen weiteren für den Text Spans (durch Kombination der Start- und End Token-Vektoren mithilfe eines kleinen FFNs). Das Skalarprodukt zwischen einer Span-Repräsentation und einer Repräsentation des Entitäts types liefert eine Bewertungswert.

Wird die Sigmoid-Funktion angewendet, erhält man die Wahrscheinlichkeit, dass der Span vom Token ii bis zum Token jj zur Entitätenart tt gehört: ϕ(i,j,t)=σ(SijTqt)\phi(i, j, t) = \sigma(S_{ij}^T \cdot q_t), wobei SijS_{ij} der Span-Vektor ist, der durch das FFN erzeugt wird, und qtq_t die Entitätenart Embedding aus der entsprechenden [ENT] Token (Zaratiana et al., 2024, Gleichung 1): Spans sind auf 12 Tokens begrenzt, um eine schnelle Ausführung zu gewährleisten.

GLiNER-Architektur: Der Entitätstyp Tokens sowie der Text Tokens werden gemeinsam mithilfe von DeBERTa kodiert, wobei anschließend die daraus resultierenden Span-Repräsentationen mittels Skalarprodukt gegenüber dem Entitätstyp Embeddings bewertet werden.

In der Praxis bedeutet das, dass jede natursprachliche Beschreibung zu jedem Zeitpunkt als Etikett für Inference verwendet werden kann – ohne erneutes Trainieren. Man gibt einfach die gewünschten Entitätsarten an („Person“, „schädliche Arzneimittelwirkung“, „Finanzinstrument“) und der Model bewertet die Spans im Vergleich dazu. Es stehen drei Größen zur Verfügung: GLiNER-S (50 M Parameter), GLiNER-M (90 M) sowie GLiNER-L (300 M). Die Trainingsdaten stammen aus dem Pile-NER Dataset: 44.889 Textabschnitte mit 240.000 Entitäten Spans aus 13.000 Entitätsarten, alle von ChatGPT gelabelt. Das Trainieren von GLiNER-L dauert auf einem einzelnen A100 etwa 4 Stunden.Zaratiana et al., 2024).

Ergebnisse von Benchmark

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

ModelParameterCrossNER F1-ScoreDurchschnittswert (20 Datasets)
GLiNER-L300 Millionen60.9%47.8%
GoLLIE7B58.0%
UniNER-13B13 Milliarden55.6%
GLiNER-M90 Millionen55.4%
UniNER-7B7B53.7%45.7%
GLiNER-S50 Millionen52.7%
ChatGPT (GPT-3.5)47.5%36.5%

GLiNER-M mit 90 M Parametern erreicht in der CrossNER-Tabelle des Papers fast denselben Wert wie UniNER-13B (55,4 % gegenüber 55,6 % F1), benötigt dabei jedoch nur etwa 140 Mal weniger Parameter. Die Variante GLiNER-S mit 50 M Parametern übertrifft das gemeldete Ergebnis von ChatGPT (GPT-3,5) um 5 F1-Punkte. Die mehrsprachige Version, die ausschließlich mit englischen Daten trainiert wurde, liegt in 8 von 10 Nicht-Englisch-Sprachen über diesemselben ChatGPT-Baseline.Zaratiana et al., 2024). Bei diesen Vergleichen werden die im Paper genannten Model-Versionen sowie die Bewertungsmethoden Harness herangezogen; sie liefern jedoch keine Rangfolge im Verhältnis zu neueren LLMs-Versionen.

Das Ökosystem ist sehr umfangreich: Auf HuggingFace gibt es mehr als 280 GLiNER-kompatible Models, monatlich etwa 350.000 Downloads über PyPI sowie rund 2.800 GitHub-Sterne. Die verfügbaren Varianten decken biomedizinische Texte, die Erkennung von PII, Nachrichten sowie mehrsprachige Anwendungen ab.

Von 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

Jede Anleitung zu NER wäre unvollständig ohne spaCyetwa 21 Millionen Downloads pro Monat, und eine der langlebigsten NLP-Bibliotheken in der Produktion. Allerdings arbeitet sie unter grundlegend anderen architektonischen Einschränkungen als GLiNER.

spaCy’s Pipelines (en_core_web_sm, en_core_web_trf) werden geschlossene Vokabulare NER verwendet: ein fester Satz an Entitätsarten (PERSON, ORG, GPE, DATE usw.), der bereits während des Trainings definiert wird. Möchten Sie eine neue Entitätsart hinzufügen? Sammeln Sie gelabelte Daten und trainieren Sie erneut. Dabei kommt ein auf Transformer-Technologie basierender en_core_web_trf Aufrufe 89,8 % F1 auf OntoNotes 5.0, doch ausschließlich für seine 18 vorgefertigten Typen.

GLiNER unterstützt offenes Vokabular NER: Jeder mögliche Label kann zu jedem Zeitpunkt bei der Inference Verarbeitung verwendet werden, ohne dass ein erneutes Trainieren erforderlich ist. Dadurch eignet sich die Lösung besonders gut, wenn die Entity-Typen im Voraus unbekannt sind, häufig wechseln oder domänenspezifisch sind (zum Beispiel „schädliche Arzneimittelwirkung“, „Finanzinstrument“ oder „Bedrohungssignal“).

Meine Empfehlung: Verwenden Sie spaCy für Standard-Entitätsarten, bei denen die vorgefertigten Pipelines gut überprüft sind. Nutzen Sie hingegen GLiNER, wenn Sie flexible, zero-shot-basierte Entitätsarten benötigen oder Ihr Pipeline ohne Neutraining angepasst werden muss. Beide Modelle können denselben Pipeline teilen, wobei spaCy für die Tokenization-Verarbeitung sowie die Satzteilung zuständig ist und GLiNER für die Entitätsextraktion.


UniNER und NuNER: Wie klein kann man gehen?

UniNER (ICLR 2024, Zhou et al.) sowie NuNER (EMNLP 2024, Bogdanov et al.) reduzieren beide die LLM-Annotierungen auf kleinere NER Models – doch sie weichen in Bezug darauf ab, wie klein diese Strukturen tatsächlich sein dürfen.

UniNER: Der maximalistische Ansatz

UniNER führt eine Feinabstimmung von LLaMA-7B/13B anhand von 44.889 NER Paaren (240.000 Entitäten, 13.000 Typen) durch, die von ChatGPT erzeugt wurden. Für jeden Entitätstyp beantwortet der Model die Frage „Was beschreibt [Typ] im Text?“ und gibt JSON-Listen aus. Ein entscheidender Trainingstrick besteht darin, dass frequency-based negative sampling den F1-Wert von 31,5 % auf 53,4 % erhöht.Zhou et al., 2024).

UniNER-7B erreicht einen 41,7 %igen Zero‑Shot‑F1‑Wert bei 43 Datasets – womit es ChatGPTs 34,9 % um 7 Punkte übertrifft. Die 13B‑Variante kommt auf 43,4 %, also nur 1,7 Punkte mehr, obwohl sie fast doppelt so viele Rechenressourcen benötigt.Zhou et al., 2024).

Das Produktionsproblem: Als 7B-autoregressiver Model benötigt UniNER N Vorwärtsübertragungen für jeweils einen Entitätstyp, verbraucht mehr als 14 GB an VRAM (was bedeutet, dass bereits vor dem Mittagessen Ihr GPU-Budget aufgebraucht ist), und unterliegt außerdem einer restriktiven CC BY-NC 4.0-Lizenz.

NuNER: der minimalistische Ansatz

NuNER basiert auf RoBERTa-base (125 M Parameter) und nutzt ein kontrastives Trainingsverfahren mit 4,38 Millionen Annotierungen von GPT-3.5 für 200.000 Konzepte – die Gesamtkosten für die Annotierung liegen dabei unter $500. Nach dem Training wird der Konzeptencoder weggelassen; der Textencoder kann anschließend in jeden Standard-NER Pipeline-Encoder als Ersatz für RoBERTa eingebunden werden.Bogdanov et al., 2024).

Die Ergebnisse: NuNER übertrifft das reine RoBERTa-Modell um 6–15 F1-Punkte bei allen Few-Shot-Größen. Schon mit nur einem Dutzend Beispielen pro Entitätsart erreicht NuNER das Niveau von UniNER-7B – obwohl es 56-mal kleiner ist.Bogdanov et al., 2024).

Beide Arbeiten befürworten die Verdichtung von LLM-Annotierungen zu kleineren NER Models-Strukturen. NuNER zeigt, dass ein Encoder mit 125 M Parametern unter Verwendung von task-spezifischen Fine-Tuning-Daten zu denselben Ergebnissen wie UniNER-7B gelangen kann – und zwar unter Berücksichtigung der MIT-Lizenz sowie von CPU-konformen Inference-Anforderungen.


GLiNER 2: ein Model, vier Aufgaben

Das ursprüngliche GLiNER-Ecosystem wies ein zunehmendes Problem auf: Es gab separate Models für NER (GLiNER), die Relationsextraktion (GLiREL), die Klassifizierung (GLiClass) sowie die RE-Ebene auf Dokumentebene (GLiDRE) – wobei jede dieser Komponenten eigene Deployment, Docker-Container, Überwachungssysteme sowie Mechanismen zur Fehlerbehandlung benötigte. GLiNER 2 (EMNLP 2025, Zaratiana et al.) integriert alle vier Komponenten in einen einzigen 205-Millionen-Parameter großen Model mit einer schemabasierten Schnittstelle.

Die Architektur behält das Cross-Encoder-Design bei, erweitert jedoch den Kontext auf 2.048 Tokens (viermal so viel wie ursprünglich) und fügt deklarative Schemata zur Definition von Extraktionsaufgaben hinzu. Zur Trainierung werden 135.698 echte Dokumente verwendet, die mit GPT-4o annotiert wurden, sowie 118.636 synthetische Beispiele.Zaratiana et al., 2025).

Bei Zero-Shot CrossNER erzielt GLiNER 2 einen F1-Wert von 0,590, was nahe am Wert von 0,599 von GPT-4o liegt, wie im Paper aus Mitte 2025 Benchmark berichtet wird. Bei der Klassifizierung liegt der Durchschnitt bei 0,72 für 7 Benchmarks, im Vergleich zu 0,69 bei DeBERTa-v3-large. Für CPU geben die Untersuchungen eine Klassifizierungszeit von 130–208 ms Latency bei den getesteten Anzahlungen an Labels an. Der DeBERTa-Referenzmodell steigt dabei von 1.714 ms für 5 Labels auf 16.897 ms für 50 Labels an.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)

In Anwendungen, die alle vier Aufgaben erfüllen müssen, kann der gemeinsame Model vier separate Deployments ersetzen, ohne dabei die in der Literatur gemeldete Genauigkeit zu beeinträchtigen.


Der Bi-Encoder: Skalierung auf Millionen von Labels NER

Der ursprüngliche GLiNER kodiert Labels und Text gemeinsam – wodurch ein Bottleneck entsteht. Mehr Entity-Typen führen zu einer längeren Eingabesequenz, und die Leistungsfähigkeit sinkt bereits ab etwa 30 Typen rapide. Der GLiNER Bi-Encoder (Februar 2026, Stepanov et al.; arXiv 2602.18487) behebt dieses Problem, indem er die Kodierung von Text und Label in zwei getrennte Transformer-Modelle aufteilt.

Cross-Encoder gegen Bi-Encoder: Der Cross-Encoder kodiert Labels und Text gemeinsam, während der Bi-Encoder separate Encoder mit vorberechneten Labels verwendet Embeddings

Der Textencoder verwendet ModernBERT (Ettin-Familie), während der Labelencoder auf Sentence Transformers zurückgreift (BGE oder MiniLM). Spans sowie die Labels werden mithilfe des Skalarprodukts bewertet. Der Vorteil besteht darin, dass der Entity-Typ Embeddings einmal im Voraus berechnet und im Cache gespeichert werden kann. Bei Inference muss lediglich der Text kodiert werden – die Abfrage der Labels erfolgt somit sofort.

Es stehen vier Model-Größen zur Verfügung, die alle auf CrossNER getestet wurden.Stepanov et al., 2026, Tabelle 1:

ModelParameterCrossNER F1-ScoreThroughput (H100)Mit vorberechneten Etiketten
bi-edge-v2.060 Millionen54.0%13,64 Ex/S24,62 Ex/S
bi-small-v2.0108 Mio.57.2%7,99 € pro Sekunde15,22 Ex/S
bi-base-v2.0194 Mio.60.3%5,91 Ex/s9,51 Ex/S
bi-large-v2.0530 Mio.61.5%2,68 Ex/S3,60 Ex/S

Bei 1.024 Entitätsarten verliert der Bi-Encoder (Edge, vorberechnet) lediglich 5,2 % Throughput im Vergleich zu einem einzigen Label. Der Cross-Encoder hingegen verliert 98,7 % (von 10,7 auf 0,14 Ex/S). Das entspricht einem 130-fachen Throughput Vorteil bei größeren Skalen. Bei 100 Entitätsarten auf einem einzelnen H100 führt der Bi-Encoder zu 1,96 Millionen Vorhersagen pro Tag, während der Cross-Encoder nur 368.000 erreicht.Stepanov et al., 2026).

Auch die Genauigkeit bleibt auf hohem Niveau. Der Bi-Encoder-Large erzielt einen 61,5 %igen CrossNER F1-Wert, was leicht über dem Wert von 60,9 % beim Cross-Encoder liegt. Die Autoren empfehlen bi-base-v2.0 (194 M) als optimale Lösung, da dieser Modelltyp 98 % der Genauigkeit des großen Model erreicht – und das bei 2,6‑mal höherer Geschwindigkeit.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)

Anwendungen umfassen biomedizinische NER-Systeme auf der Grundlage der UMLS-Ontologie (mehr als 4 Mio. Konzepte), Unternehmenstaxonomien, die sich ohne erneutes Model-Training weiterentwickeln können, sowie das Verknüpfen von Entitäten mithilfe des dazugehörigen Tools. GLiNKER Framework.


LLMs als Lehrmittel: Eine Fallstudie mit Kosten von 70 Dollar sowie ein einsetzbarer Pipeline

Das LLM-als-Lehrer-Muster trennt kostspielige Annotierungsarbeiten von günstigeren Inference-Prozessen. Zwei veröffentlichte Fallstudien zeigen, wie Teams dieses Vorgehen unter unterschiedlichen Bedingungen angewandt haben.

Der LLM-als-Lehrer Pipeline: LLM kennzeichnet Rohdaten, Menschen prüfen einen Teil davon, der Encoder wird feinabgestimmt und zu einem 80-mal geringeren Kostenniveau eingesetzt.

Die Fallstudie CFM

In einer Hugging Face-Fallstudie extrahierte Capital Fund Management Firmennamen aus etwa 900.000 Schlagzeilen aus Finanznachrichten. Zero-shot GLiNER erzielte einen Wert von 87,0 % F1. Das Team nutzte Llama 3.1-70B, um die Dataset innerhalb von rund 8 Stunden zu annotieren – was etwa 70 US-Dollar kostete – und prüfte anschließend über Argilla weitere 2.714 Beispiele in weiteren 8 Stunden.

Fine-Tuning In dem Fallstudium erreichte GLiNER auf diesen Daten einen F1-Wert von 93,4 %, während der Lehrmodelle Llama-70B 92,7 % erzielte. Die Autoren geben an, dass die feinabgestimmten Model 0,10 USD pro Stunde auf CPU kosten, während der Lehrmodelle 8 USD pro Stunde verlangt werden.Fallstudie CFM). Diese Diagramme beschreiben eine Aufgabe im Bereich Finanznachrichten sowie eine Infrastrukturkonfiguration.

Die Refuel AI-Studie

Der technische Bericht von AI wird durch Benchmarks LLM-Bewertungen in insgesamt 8 NLP Datasets-Datensets, darunter CoNLL-2003, ergänzt. Er weist eine Übereinstimmungsrate von 88,4 % mit den Referenzwerten für GPT-4 (März 2023) sowie 86,2 % bei den menschlichen Annotatoren in der verwendeten Konfiguration auf. Zudem erfolgt die Annotation 20 Mal schneller und zu 70 % günstiger. Das Ensemble-Verfahren leitet einfache Beispiele an kostengünstigere Models-Systeme weiter und schwierige Beispiele an GPT-4, wodurch in den durchgeführten Experimenten eine Übereinstimmungsrate von mehr als 95 % erreicht wird.Nachbereitung des technischen Berichts zu AI). Betrachten Sie diese als von dem Anbieter gemeldete Ergebnisse gemäß dem Annotationsschema dieser Studie.

Eine Produktivumgebung Pipeline

Ein praktischer Produktionsfluss umfasst sechs Schritte:

  1. Verfassen Sie Leitlinien für die Annotierung in natürlicher Sprache.
  2. Erstellen Sie einen kleinen, von Menschen gelabelten Validierungsdatensatz (50–200 Dokumente).
  3. Wenden Sie ein LLM (GPT-5.4 Mini, Llama 4 Maverick oder Qwen3.5) zur Automatisierung der Labelung der Großmengendaten an.
  4. Überprüfen Sie einen Teil des Datensatzes manuell. Ton oder Label Studio
  5. Feinabstimmung eines kompakten Encoders (GLiNER, Spannungsmarkierung, RoBERTa)
  6. Bereitstellung zu 16–80-mal geringeren Inference Kosten

Der LLM kann das Volumen der manuellen Annotation verringern, doch das Team behält weiterhin die Kontrolle über den Validierungsdatensatz, die Anleitung zur Annotation, die gezielte Überprüfung sowie die Fehleranalyse.


Wo GLiNER versagt und LLMs weiterhin nützlich sind

Der Sease Benchmark (Oktober 2025) Es wurde getestet, wie GLiNER sich gegenüber GPT-4.1-mini bei 30 Aufgaben zur Abfrageanalyse schlägt. GPT-4.1-mini erzielte 100 % vollständig korrekte Ergebnisse. GLiNER erreichte hingegen 53 % (16 von 30). Allerdings reagierte GLiNER in 0,08 Sekunden, während der LLM 1,21 Sekunden benötigte – das sind 15-mal schnellere Reaktionszeiten.

In diesem Test mit 30 Aufgaben Benchmark versagte GLiNER bei drei wiederkehrenden Mustermustern:

  1. Implizite Entitäten: Extraktion von „Event“ aus dem Satz „Elton John performed at Madison Square Garden“ – im Text steht zwar nicht wörtlich „Event“, doch der LLM schließt auf „Konzert“.
  2. Empfindlichkeit der Etikettformulierungen: Für „2022“ ergibt sich eine Bewertung von 0,388 im Vergleich zu „Datum“, während sie bei „Jahr“ bei 0,958 liegt – geringe Änderungen der Etiketten führen daher zu starken Schwankungen der Bewertung.
  3. Wertkartei: GLiNER gibt den exakten Ausdruck aus dem Eingabetext zurück („family houses“) anstelle des kanonischen Wertes („Einfamilienhaus“). Ein LLM kann diese Normalisierung durchführen, sofern seine Prompt sowie das zugehörige Schema die Zielwerte definieren.

Verschachtelte und überschneidende Entitäten

GLiNER hat ebenfalls Schwierigkeiten mit verschachtelten Entitäten. In „New York University“ könnte ein Mensch sowohl „New York“ (ORT) als auch „New York University“ (ORGANISATION) kennzeichnen. GLiNER wählt dabei nur die Entität mit der höchsten Bewertung für Span aus. Dies ist von Bedeutung in biomedizinischen Texten („akute myeloide Leukämie“ umfasst sowohl eine Krankheit als auch einen Modifikator) sowie in rechtlichen Dokumenten (verschachtelte Organisationshierarchien). Spezialisierte Models-Lösungen können solche Verschachtelungen bewältigen, doch das flache Span-Design von GLiNER nicht.

Wenden Sie GLiNER für die explizite Entitätenextraktion an und leiten Sie Fälle, bei denen Inference, Reasoning oder eine Zuordnung zu vorgefertigten Ontologien erforderlich sind, an einen LLM weiter. Der Schwellenwert von Routing muss aus einem gelabelten Domänenensemble abgeleitet werden.


Bewertung von NER: Metriken, Fallstricke und Testmengen

Ein Model kann auf einem sorgfältig zusammengestellten Testdatensatz eine F1-Wertung von 95 % erzielen und dennoch bei der Verarbeitung einer Mischung aus Dokumenten, die er nach Deployment zu Gesicht bekommt, versagen. Erstellen Sie den Bewertungsdatensatz anhand der Produktionsverteilung und behalten Sie Ausschnitte der seltenen Formate sowie Entitätsarten bei, da aggregierte F1-Werte sonst mögliche Probleme verbergen könnten.

Die Kernmetriken

Häufige Fehler bei der Bewertung

  1. Teilweise Übereinstimmungs-Inflation: Es wird „Bill“ extrahiert, obwohl die Gold-Labeling-Information „Bill Gates“ lautet – einige Skripte werten dies als Teilübereinstimmung. Verwenden Sie ausschließlich eine exakte Span-Übereinstimmung, es sei denn, es gibt einen triftigen Grund dagegen.
  2. Typenverwechslung: „Microsoft“ wird zwar korrekt als Span identifiziert, sollte aber aufgrund der Klassifizierung als PERSON statt ORG einen Score von null erhalten. Überprüfen Sie, ob Ihr Bewertungskodex dieses Szenario berücksichtigt.
  3. Leckagen im Testdatensatz: Wenn die Entitäten des Testsets mit denen des Trainingsdatensets überschneiden, werden die Scores überhöht. Für die Überprüfung der Generalisierbarkeit stehen zero-shot Benchmarks-Methoden (CrossNER, Few-NERD) zur Verfügung.

Erstellung eines Domänen-Testsets

Für die Evaluierung in der Produktion empfehle ich:

  1. Beispiele aus Produktionsdaten, nicht sorgfältig ausgewählte Fallbeispiele. Enthalten Sie auch die unstrukturierten Dokumente, mit denen Ihr Model tatsächlich konfrontiert wird.
  2. 200–500 annotierte Dokumente liefern zuverlässige Schätzungen für den F1-Wert. Bei weniger als 100 Dokumenten sind die Konfidenzintervalle zu breit.
  3. Mindestens zwei Annotatoren sind erforderlich, wobei eine Übereinstimmung zwischen ihnen vorliegen muss (Cohen’s Kappa > 0,8). Falls Menschen unterschiedlicher Meinung sind, kann Ihr Model keine besseren Ergebnisse erzielen.
  4. Stratifizieren Sie nach Schwierigkeitsgrad – einfache Fälle (reiner Text, Standardtypen) sowie schwierige Fälle (ambige Entitäten, Fachjargon, störender Text).

Produktion NER in vier Branchen

Hier sind die am weitesten entwickelten NER Deployments, die ich gefunden habe, zusammen mit konkreten Zahlen.

Gesundheitswesen

Der Gesundheitssektor verfügt über die am weitesten entwickelten Tools für NER. John Snow Labs stellt mehr als 2.500 vorgefertigte Models zur Verfügung, darunter über 1.200 speziell für den Gesundheitsbereich, die 400+ verschiedene klinische Entitätsarten abdecken und mit ICD-10, SNOMED CT, LOINC sowie RxNorm verknüpft sind. Bei dem Unternehmen Vergleich der Anbieter, seine De-Identifizierung Models erreichte einen F1-Wert von 96 %, im Vergleich zu Azure mit 91 %, AWS mit 83 % und GPT-4o mit 79 %. Ein separates Fallstudie berichtet Providence St. Joseph Health verarbeitet täglich 100.000 bis 500.000 klinische Notizen..

In seiner Projektbewertung für das Jahr 2025 prüft die Open-Source- OpenMed-Projekt Es werden mehr als 380 biomedizinische NER Models veröffentlicht, es gab 29,7 Millionen Hugging Face Downloads, und das System erzielt führende Ergebnisse in 10 von insgesamt 12 öffentlichen biomedizinischen Benchmarks.

Finanzen NER

Der Hauptanwendungsfall: Extraktion von Informationen aus SEC-Berichten. Das Finanz-NLP-Tool von John Snow Labs erkennt mehr als 11 verschiedene Entitätsarten aus 10-K/10-Q-Berichten – darunter Adressen, Aktienkennungen, Geschäftsjahre sowie Börsenplätze. FinBERT-MRC Die Varianten erzielen bei Aufgaben zur Erkennung von Finanzentitäten Werte im F1-Score-Bereich von 0,87 bis 0,93. Die zentrale Herausforderung bestehen dabei in langen Dokumenten sowie verschachtelten Entitäten in komplexen Finanzinstrumenten.

E-Commerce

Walmarts EAMT-System (KDD 2023) wird anhand von 965 Millionen Abfragen mit etwa 60 Entitätsetiketten trainiert; in den A/B-Tests wird ein Anstieg des GMV um 0,51 % berichtet. Bei Home Depot’s TripleLearn Framework (AAAI 2021) führte durch iteratives Training einen Anstieg des NER F1-Werts von 69,5 auf 93,3 herbei.

Cybersicherheit

Der iACE-System (CCS 2016) wurden 71.000 Artikel aus 45 Sicherheitsblogs verarbeitet, wodurch 900.000 IOC-Einträge mit einer Präzision von 98 % und einem Recall von 93 % extrahiert werden konnten. Moderne Systeme wie CyNER kombiniere DeBERTa (F1 >91%) mit auf regulären Ausdrücken basierenden IOC-Hybristiken. Die CyberNER Die unified Dataset (2025) vereint vier Datasets zu 21 Entitätsarten, die mit STIX 2.1 kompatibel sind, wobei RoBERTa einen F1-Score von 0,736 erzielt.


Deployment-Optimierung: Vom Python zu einem weniger-Latencyen Inference

Im begleitenden Repository habe ich drei Methoden getestet, um GLiNER für den Produktivbetrieb zu beschleunigen.

ONNX Exportieren

GLiNER verfügt über eine native ONNX-Konvertierung, und vorkonvertierte Models-Exemplare sind auf HuggingFace verfügbar.onnx-community/gliner_small-v2.1). ONNX Runtime ermöglicht eine 1,5‑ bis 3‑fach schnellere Ausführung bei CPU im Vergleich zu PyTorch und bietet vier Optimierungsstufen – von Basis bis hin zu gemischter Präzision.

Von 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 Quantization

Dynamische Quantization-Verkleinerung verringert die Größe von Models um 2,4-fach (von 438 MB auf 181 MB), wobei der F1-Verlust unter 0,6 % bleibt. Die Geschwindigkeit steigt auf CPU um 1,8-fach an. Unter Verwendung von Intel VNNI CPUs zusammen mit ONNX Runtime erreicht INT8 eine Beschleunigung von bis zu 6-fach im Vergleich zu 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: Neureализierung in Rust

gline-rs (Apache 2.0) beseitigt die Overhead-Kosten von Python. Auf CPU: 6,67 Sequenzen/Sekunde im Vergleich zu 1,61 bei Python – das entspricht einer 4,1-fachen Beschleunigung. Auf einer RTX 4080: 248,75 Sequenzen/Sekunde.gline-rs Benchmarks). Es unterstützt Span sowie Token und Models, außerdem GPU über NPU mittels ONNX Runtime, und ist als Crate auf crates.io verfügbar.

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

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

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

Der Schnellläufer-Agent Das Paket stellt Python-Bindings über PyO3 bereit – Geschwindigkeit von Rust in Kombination mit der Benutzerfreundlichkeit von Python.

Zusammenfassung des Optimierungsstacks

OptimierungGeschwindigkeitssteigerung im Vergleich zu PyTorchModel GrößeF1-EinflussAm besten geeignet für
ONNX Runtime1,5–3-malDerselbeKeinerSchneller Erfolg – beliebige Hardware
INT8 Quantization3–6 Mal2,4‑mal kleiner<0,6 % Verlust>CPU Deployment, mit begrenzten Speicherressourcen
4.1x (CPU)ONNX FormatKeinerhochgradig Throughput, Latency-kritisch
gline-rs + INT84–8 Mal2,4‑mal kleiner1%-VerlustProduktionsumgebung im großen Maßstab

Strukturierte Extraktion: Dozentenkonfiguration versus Ausarbeitungspläne

Wenn Sie mehr Flexibilität benötigen als die von Encoder Models gebotene – wie implizite Entitäten, Reasoning sowie Ontologie-Kartierung – dann übernehmen zwei Bibliotheken die strukturierte Extraktion aus LLMs.

Lehrer (~12.600 GitHub-Sterne, ~8,8 M Downloads pro Monat Stand März 2026) hat Jason Liu den LLM SDKs so modifiziert, dass er Pydantic-Antworten Models verarbeiten kann, wobei dabei automatische Wiederholungsversuche bei Validierungsfehlern erfolgen. Er unterstützt mehr als 15 Anbieter und diente als Vorlage für die eingebettete Structured Output-Funktion von OpenAI.

Von 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'), ...]

Übersicht by dottxt verfolgt einen anderen Ansatz: die restriktierte Token-Generierung mittels endlicher-State Machines. Der Dekoder maskiert Tokens, die gegen die Zielgrammatik verstoßen würden, anstatt auf einen Validierungsfehler zu warten und erneut zu versuchen. In einem AWS Benchmark, Dieser Pfad erreichte eine 98 %ige Konformität zum Schema, im Vergleich zu 76 % bei der Validierung nach der Generierung, und erzeugte die Ausgabe fünfmal schneller als der getestete, unbeschränkte Workflow mit Wiederholungsversuchen. Das Ergebnis hängt von diesem Model, dem definierten Schema sowie der Serving-Konfiguration ab.

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 Sie Ihren Models ausführen. Instructor bietet cloudbasierten LLM APIs eine vertraute Pydantic-Validierungs- und Wiederholungslogik. Outlines beschränkt die lokale Generierung auf ein vorgegebenes Schema. Beide Ansätze unterstützen die extraktionsbasierte Verarbeitung im Stil von NER, wobei deren Latency weiterhin eine autoregressive Model-Generierung beinhaltet. Benchmark nutzt in beiden Fällen denselben Encoder bei derselben Batch-Größe, demselben Hardware-Setup sowie dem gleichen Entitätschema.


Die dreistufige Produktionsarchitektur

Ich würde die Verarbeitung in der Produktion NER nach der Struktur der Aufgaben steuern anstelle einer Rangliste basierend auf einem einzigen Model.

Eine dreistufige NER-Architektur, die explizite Spans an Encoder weiterleitet, mehrstufige Extraktionsaufgaben an GLiNER 2 überträgt und fälle mit hohem Reasoning-Anteil an LLMs sendet.

Ebene 1: Encoder Models für explizite Spans. Verwenden Sie einen GLiNER-Cross-Encoder bei kleineren Etikettensätzen und testen Sie den Bi-Encoder, wenn die Anzahl der Etiketten zunimmt. Führen Sie eine Feinabstimmung mittels des LLM-als-Lehrer-Verfahrens bei Pipeline durch und setzen Sie das Modell anschließend mit ONNX, INT8 oder gline-rs ein, sofern diese Ansätze die Anforderungen des jeweiligen Domänenkontexts Benchmark erfüllen.

Ebene 2: GLiNER 2 für die Mehraufgabenauswertung. Wenn eine Anfrage mehrere Aufgaben erfordert NERKlassifizierung, Relationsextraktion sowie strukturierte Daten – hier wird GLiNER 2 mit seinen 205-Millionen-Parameter gemeinsam getestet. ModelDer Artikel gibt Werte von 130–208 ms an. CPU Klassifizierung Latency über die Anzahl der getesteten Labels.

Ebene 3: LLMs für extraktionsintensive Aufgaben mit hohem Anteil an Reasoning. Implizite Entitäten, kontextbezogene Inference sowie Ontologie-Kartierungen werden über Instructor für cloudbasierte APIs-Lösungen oder über Outlines für lokale Models-Umgebungen an einen LLM weitergeleitet. Diese Fälle sollten protokolliert werden, da sie als Kandidaten für den nächsten Trainingsdatensatz der Ebene 1 in Frage kommen.

Die Fallstudie zu CFM liefert einen Kostenvergleich für die erste Kategorie: 93,4 % F1 bei einem angegebenen Preis von 0,10 US-Dollar pro Stunde auf CPU, im Vergleich zu 92,7 % F1 sowie 8 US-Dollar pro Stunde für den Lehrmodell von Llama-70B. Erstellen Sie einen erneuten Vergleich unter Verwendung Ihrer eigenen Hardware, Ihres Lehrmodells Model sowie des Etikettensatzes, um die Kosten zu bewerten.


Kompromisse und Einschränkungen

ML-Systeme weisen stets Kompromisse auf. Die entscheidende Frage ist, wo sich dieser Kompromiss zeigt und ob er vor dem Deployment gemessen werden kann.

LLM-as-teacher Fehler breiten sich aus. Wenn der LLM konsequent einen bestimmten Entitätstyp falsch einordnet (z. B. Tochtergesellschaftsnamen mit Muttergesellschaften verwechselt), übernimmt der feinabgestimmte Encoder dieses Verhalten. Die Lösung besteht in gezielten menschlichen Überprüfungen – man sollte die Anstrengungen auf jene Entitätsarten richten, bei denen das Vertrauensniveau des LLM niedrig oder inkonsistent ist, anstatt zufällige Stichproben zu verwenden.

Quantization-Verluste weisen keine gleichmäßige Verteilung auf. Der durchschnittliche F1-Verlust von etwa 0,6 % bei INT8 kann bei seltenen Entitätsarten mit subtilen Grenzmustern – wie chemischen Verbindungen oder mehrwörigen Abkürzungen – höher ausfallen. Es ist daher unbedingt notwendig, die Benchmark-quantifizierten Models-Werte für Ihre spezifischen Entitätsarten einzeln zu prüfen, anstatt lediglich den aggregierten F1-Wert zu betrachten.

Wenn die dreistufige Architektur übertrieben ist. Ein einzelner Domänenbereich mit stabilen Entitätsarten sowie ausreichend gelabelten Beispielen benötigt möglicherweise lediglich eine feinabgestimmte RoBERTa- oder spaCy-Instanz Pipeline. Das dreistufige Muster eignet sich hingegen für mehrere Domänen, sich wandelnde Entitätsarten oder eine abgewogene Kombination aus expliziter Extraktion sowie extraktionstechniken, die stark auf Reasoning beruhen. Eine einfache Rechnung Pipeline, bei der nur Namen und Daten extrahiert werden, kann bereits in der ersten Stufe abgeschlossen werden.

Obergrenze der Qualität beim Bi-Encoder. Der Bi-Encoder tauscht gemeinsame Attention gegen Throughput ein. Wenn die Semantik der Etiketten mit dem Textkontext kollidiert (z. B. „Datum“, „Jahr“ oder „Zeitraum“ für denselben Span), hat der Cross-Encoder weiterhin die Nase vorn. Verwenden Sie den Cross-Encoder bei kritischen Aufgaben mit geringer Anzahl an Etiketten; der Bi-Encoder eignet sich hingegen besser für umfassende Analyseaufgaben.


Referenzen

Arbeiten / Publikationen

Branchenpapiere

Fallstudien

Werkzeuge und Frameworks