NER-Modellauswahl: spaCy, GLiNER, Transformers oder LLMs?
Automatische Übersetzung
Dieser Artikel wurde automatisch aus der englischen Originalversion übersetzt.
Named Entity Recognition (NER) findet und labelt Textspans, etwa Personen, Unternehmen und Produktcodes. Diese Seite richtet sich an Ingenieure, die für eine Produktionslast einen Extraktionsweg auswählen. Sie bietet einen Ausgangspunkt, den Sie anhand Ihres Schemas, Ihrer Dokumente und Ihrer betrieblichen Rahmenbedingungen testen können.
Verwenden Sie spaCy für stabile Labels und schnelle Pipelines. Wählen Sie GLiNER, wenn sich Labels häufig ändern. Testen Sie einen Bi-Encoder, wenn viele Labels wiederverwendbare gecachte Embeddings nutzen können, oder einen Transformer-Token-Classifier mit Fine-Tuning, wenn gelabelte Beispiele vorhanden sind. Verwenden Sie strukturierte Extraktion mit LLMs, wenn Sie einen komplexen Datensatz statt einer einfachen Liste von Textspans benötigen.
Wählen Sie anhand der benötigten Labels, der Sprache, der Ausgabeform, der gelabelten Daten und des Latency-Budgets.
Entscheidungstabelle
| Bedarf | Ausgangspunkt | Warum |
|---|---|---|
| Bekannte Labels und CPU-Deployment | spaCy-Baseline | Vortrainierte Pipelines und Regeln bieten eine Baseline; prüfen Sie die Genauigkeit für Sprache und Fachgebiet. |
| Neue Labels ohne vollständiges Training | GLiNER | Label-konditionierte Extraktion funktioniert gut, wenn sich das Label-Set ändert. Beginnen Sie mit klaren Typbeschreibungen statt mit bloßen Namen. |
| Großes, wiederverwendbares Label-Inventar | GLiNER bi-encoder | Label-Embeddings können vorab berechnet und gecacht werden, statt die Labels mit jedem Dokument erneut zu encoden. |
| Entitäten und Beziehungen in einem Durchlauf | GLiNER-Relex als Kandidat | Entitäts- und Beziehungstypen werden gemeinsam extrahiert. Vergleichen Sie das Modell auf dem Zielschema für Beziehungen mit separaten Stufen. |
| Entitäten plus Dokumentfelder oder Klassifikation | GLiNER2 | Das Schema-Interface kombiniert Named Entity Recognition, Klassifikation und Aufgaben zur strukturierten Extraktion. |
| Verschachtelte oder überlappende Entitäten | Decoder mit Unterstützung für Verschachtelung, einschließlich GLiNER mit flat_ner=False | Flaches Decoding unterdrückt Überlappungen. Testen Sie verschachtelte Spans mit Annotationen, die die erwarteten Überlappungsmuster enthalten. |
| Mehrsprachige Extraktion oder Extraktion über mehrere Schriftsysteme | GLiNER-X oder XLM-R-Baseline | Testen Sie jede Zielsprache, jedes Fachgebiet und die Formulierung der jeweiligen Typbeschreibungen. |
| Stabile Domain-Labels mit repräsentativen gelabelten Spans | Token-Classifier mit Fine-Tuning oder spaCy-Pipeline | Erstellen Sie eine Supervised-Baseline und vergleichen Sie anschließend Exact-Span-F1, Latency und Kosten auf Ihrem Domain-Dataset. |
| Implizite, satzübergreifende oder strukturierte Felder | LLM oder hybrider Kandidat | Structured Outputs begrenzen die Antwortform, nicht die Korrektheit der Extraktion. Validieren Sie die Feldgenauigkeit auf einem Domain-Testset. |
| PII mit hohem Risiko oder regulierter Workflow | Presidio plus GLiNER2-PII als Kandidat | Kombinieren Sie Modellausgabe mit deterministischen Prüfungen, Kontrollen zur Schwärzung und Review. |
| Exakte IDs, Produktcodes oder bekannte Begriffe | Regeln und Wörterbücher | Deterministischer Abgleich eignet sich für feste Muster; testen Sie übersehene Varianten und falsche Treffer. |
So wählen Sie aus
Schreiben Sie die Entitätstypen und einige gelabelte Beispiele auf, bevor Sie ein Modell auswählen. Nehmen Sie mehrdeutige Begriffe und Spans innerhalb anderer Spans auf, wenn die Aufgabe dies erfordert.
Wenn Labels stabil sind, testen Sie zuerst eine vorhandene Pipeline. Führen Sie Fine-Tuning für einen Token Classifier durch, wenn dessen Fehler im Fachgebiet das Training rechtfertigen und repräsentative gelabelte Beispiele vorliegen. Vergleichen Sie ihn auf einem separaten Testset aus dem Fachgebiet. Er sagt Token-Labels vorher, ohne die Antwort Token für Token zu generieren.
Wenn sich Labels häufig ändern, testen Sie GLiNER oder einen LLM-Extraktor. Schreiben Sie eine kurze Beschreibung für jeden mehrdeutigen Typ. ZeroNER evaluiert Typbeschreibungen mit Entitätstypen, die im Training nicht vorkamen. Beschreibungen verdeutlichen das Label; ein Test unbekannter Typen muss diese Typen auch vom Training ausschließen.
Wenn Sie ein großes Label-Inventar wiederverwenden, evaluieren Sie einen Bi-Encoder, bevor Sie einen gemeinsamen Label-Text-Encoder einsetzen. Das GLiNER-bi-encoder-Paper berichtet bei gliner-bi-edge-v2.0 mit gecachten Label-Embeddings einen etwa 130-mal höheren Throughput als bei gliner_small-v2.5 mit 1.024 Labels. Der Vergleich wurde auf einer H100 GPU und mit Batch Size 1 durchgeführt; die Geschwindigkeitstests umfassten Eingaben mit 64, 256 und 512 Tokens. Er zeigt, warum sich das Testen von Label-Wiederverwendung lohnt, nicht welchen Geschwindigkeitsgewinn Sie bei einem anderen Workload erwarten können.
Wenn Dokumente mehrere Sprachen umfassen, benchmarken Sie jede Zielsprache und jedes Schriftsystem. OpenNER 1.0 stellte in seiner Sammlung mit 52 Sprachen fest, dass kein einzelnes Modell in allen Sprachen am besten war. Testen Sie sowohl englische als auch lokalisierte Typbeschreibungen, da der Label-Text Teil der Modelleingabe ist.
Wenn die Ausgabe ein strukturierter Datensatz statt Spans ist, verwenden Sie einen LLM mit Structured Outputs oder eine hybride Pipeline. LangExtract ist nützlich, wenn jede Extraktion auf ihre Quellposition zurückverweisen muss. NuExtract ist eine selbst gehostete Option für multimodale Dokumentextraktion. Beide benötigen weiterhin eine Evaluation auf Feldebene mit den Zieldokumenten.
Viele geschäftliche Extraktionsaufgaben sind kein reines NER. „Finden Sie die Parteien, Pflichten, das Wirksamkeitsdatum, die Kündigungsklausel und das anwendbare Recht“ ist Dokumentverständnis mit Entitätsfeldern.
Verwenden Sie für PII ein PII-Framework wie Presidio als Integrations- und Schwärzungsschicht. Betrachten Sie GLiNER2-PII als Modellkandidaten, nicht als Compliance-Entscheidung. Messen Sie den Recall für die sensiblen Formate, Sprachen und Dokumente, die das System verarbeiten wird.
Produktionspipeline
Eine Extraktionspipeline für den Produktivbetrieb ergänzt das Modell häufig um weitere Stufen:
- Kandidatenextraktion: spaCy, GLiNER, Transformer-Modell, LLM, Regeln oder eine Kombination.
- Optionale Normalisierung oder Entity Linking: Ordnen Sie Spans kanonischen IDs, Produktcodes, Nutzern, Unternehmen oder Einträgen in Ihrem Domain-Vokabular zu.
- Validierung und Review: Verwerfen Sie unmögliche Labels, erzwingen Sie Schema-Constraints, deduplizieren Sie Spans und leiten Sie unsichere Fälle zur Prüfung weiter.
Normalisierung ordnet extrahierten Text einer stabilen ID in Ihren Daten zu. Entscheiden Sie beim Span „Apple“ zuerst, ob er das Unternehmen, die Frucht, eine Produktfamilie oder einen Aktien-Ticker bezeichnet. Ordnen Sie diese Bedeutung anschließend der entsprechenden ID zu.
Evaluations-Checkliste
Messen Sie mehr als F1 auf Entitätsebene:
Exact-Span-F1 zählt eine Vorhersage nur dann als korrekt, wenn sowohl der Span als auch das Label mit der Annotation übereinstimmen. Ein Relaxed-Score kann überlappende Spans akzeptieren; dokumentieren Sie deshalb seine Abgleichregel. Keiner der beiden Scores prüft, ob der extrahierte Name der richtigen Datenbank-ID zugeordnet wird.
- Exact-Span-F1
- Relaxed-Span-F1
- Konfusionsmatrix der Labels
- Umgang mit verschachtelten Entitäten
- Genauigkeit der Entitätsnormalisierung
- Sensitivität gegenüber Typbeschreibung und Label-Sprache
- Auswertung nach Sprache, Schriftsystem und Dokumentformat
- Falsch positive Treffer pro Label
- Kalibrierung der Konfidenz
- Latency und Kosten pro Dokument
- Rate menschlicher Korrekturen
Halten Sie das Testset von Schema-Design und Threshold-Tuning getrennt. Berichten Sie die Anzahl der Dokumente und Entitätsnennungen pro Label. Verwenden Sie Konfidenzintervalle auf Dokumentebene, wenn wiederholte Nennungen in einem Dokument andernfalls die Sicherheit künstlich erhöhen würden.
Weiterführende Lektüre
- NER-Leitfaden 2026 behandelt Encoder, LLMs und die dreistufige Produktionsarchitektur.
- Schemagestütztes Reasoning ist relevant, wenn NER zu strukturierter Extraktion wird.
Referenzen
- GLiNER-Dokumentation
- GLiNER-bi-encoder-Paper – gecachte Label-Embeddings für große Inventare.
- GLiNER2-Dokumentation
- GLiNER-Relex-Paper – gemeinsame Entitäts- und Beziehungsextraktion.
- ZeroNER-Paper – harte Zero-Shot-Evaluation mit Typbeschreibungen.
- OpenNER-1.0-Paper – mehrsprachige NER-Evaluation mit mehreren Ontologien.
- LangExtract – LLM-Extraktion mit Quellenzuordnung.
- NuExtract – selbst gehostete multimodale Extraktion.
- Presidio – Framework für PII-Erkennung und Anonymisierung.
- GLiNER2-PII-Paper – mehrsprachiger PII-Modellkandidat.
- spaCy-Dokumentation zu benannten Entitäten
- Hugging-Face-Leitfaden zur Token-Klassifikation
- OpenAI-Leitfaden zu Structured Outputs