Guide NER 2026 : GLiNER, spaCy, Transformers et LLMs

Viacheslav Dubrov

2026-04-02 · Mis à jour 2026-08-17 · 38 min · Systèmes de recherche et de langage

Traduction automatique Cet article a été traduit automatiquement depuis la version originale en anglais.

La reconnaissance d’entités nommées (NER) couvre désormais les encodeurs compacts, les modèles à vocabulaire ouvert et l’extraction fondée sur les LLMs. Dans l’évaluation CrossNER citée, un modèle GLiNER de 300M paramètres dépasse le score F1 zero-shot publié pour UniNER-13B. Un bi-encoder plus récent affiche jusqu’à 130 fois plus de throughput que le gliner_small-v2.5 uni-encoder comparable avec 1 024 types d’entités lorsque les labels sont pré-calculés. L’article a effectué ces mesures sur un seul H100, avec une batch size de 1, pour des entrées de 64, 256 et 512 tokens. Ces résultats justifient des expérimentations, pas un classement universel pour la production.

Le repository associé fournit des exemples exécutables pour GLiNER, l’export ONNX, les labels d’entraînement générés par un LLM et l’extraction structurée. Pour les workloads dominés par des spans explicites, les encodeurs compacts sont généralement l’option la plus rapide et la moins coûteuse. Les LLMs restent utiles pour produire des données d’entraînement et traiter les cas nécessitant de l’inférence ou de la normalisation.

Ce guide s’adresse aux ingénieurs qui choisissent et évaluent des architectures NER pour des pipelines RAG, agentic, documentaires ou de protection de la vie privée. Vous repartirez avec une méthode de sélection de modèle, un plan d’évaluation borné et une architecture à trois niveaux combinant encodeurs et extraction par LLM.

Repository associé : ner-field-guide, avec des démos exécutables pour GLiNER, l’export ONNX, le pipeline LLM-as-teacher et l’extraction structurée avec Instructor.

Pour une comparaison rapide des modèles, consultez Best NER Models in 2026.

Qu’est-ce que la reconnaissance d’entités nommées ?

La reconnaissance d’entités nommées identifie des spans dans un texte et leur attribue des types tels que personne, organisation, date, produit ou des labels spécifiques au domaine. La NER identifie la mention. L’entity linking est l’étape distincte qui relie une mention à une fiche canonique ou à un concept d’ontologie.

Où les systèmes modernes utilisent-ils la NER ?

La NER continue d’identifier des spans de texte et de leur attribuer des labels. Ce qui a changé, c’est sa place dans le système. Elle fournit désormais des filtres pour le RAG, des arguments structurés pour les outils des agents et des champs pour les pipelines de traitement documentaire. Ces usages rendent la latence, le coût et la flexibilité du schéma aussi importants que la précision sur les benchmarks.

RAG : améliorer la retrieval grâce à l’extraction d’entités

La recherche par similarité seule rencontre des difficultés lorsqu’une question contient des entités exactes. Pour « que disait Anthropic à propos de la sécurité des modèles au T4 2024 ? », le système devrait extraire « Anthropic » et « T4 2024 » comme filtres de métadonnées, au lieu de s’appuyer uniquement sur les embeddings.

Lors de l’indexation, extrayez les entités de chaque chunk et stockez-les comme métadonnées : {"organizations": ["Anthropic"], "dates": ["Q4 2024"], ...}. Vous pourrez ainsi filtrer par entité avant d’exécuter la recherche vectorielle. Le knowledge graph RAG (GraphRAG, property graphs de LlamaIndex) va plus loin : la NER et l’extraction de relations construisent un graphe capable de répondre à des questions multi-hop auxquelles des embeddings plats ne peuvent pas répondre.

Au moment de la requête, les entités extraites de la question de l’utilisateur pilotent le routage. Une question mentionnant le nom d’une entreprise est dirigée vers un index financier ; une question mentionnant des noms de médicaments vers une base de connaissances cliniques. GLiNER est utile lorsque le schéma ou les types d’entités changent au moment de la requête. Des noms d’entreprises ou de médicaments inconnus ne nécessitent pas à eux seuls des labels à vocabulaire ouvert : un modèle à labels fermés peut tout de même reconnaître de nouvelles mentions de types connus.

Agents AI : transformer le texte en faits structurés

Les agents reçoivent du texte non structuré, comme des pages web, des réponses d’API et des messages utilisateur. La NER convertit ce texte en faits structurés sur lesquels l’agent peut raisonner, qu’il peut stocker ou transmettre à des outils.

Pour le routage des outils, une requête comme « planifie une réunion avec Sarah Chen d’Accenture jeudi à 14 h » nécessite PERSON: Sarah Chen, ORGANIZATION: Accenture et DATETIME: Thursday 2pm avant que l’agent n’appelle l’API de calendrier. Un encodeur local évite l’aller-retour vers l’API et est souvent nettement plus rapide, mais la latence dépend du modèle, du runtime, du matériel, de la batch size et du nombre de labels. Mesurez les deux chemins sur le workload de calendrier au lieu de supposer un écart fixe en millisecondes.

La NER prend également en charge le suivi des entités au fil des conversations. Les systèmes de mémoire des agents doivent savoir que « Sarah » au tour 3 et « Mme Chen » au tour 12 désignent la même personne. La NER identifie les spans ; l’entity linking les relie au même ID.

Dans les deux cas, la contrainte principale est la latence. Si chacune de dix étapes séquentielles effectue un appel NER de 200 ms, ces appels ajoutent 2 secondes de délai perçu. Un seul appel ajoute 200 ms. Les modèles encodeurs intègrent généralement mieux le traitement des entités dans les agent loops que l’extraction fondée sur les LLMs.

Intelligence documentaire : des images aux données structurées

L’OCR transforme les images en texte. La NER transforme ce texte en champs structurés.

Un pipeline standard utilise d’abord un OCR, comme Tesseract, Azure Document Intelligence ou AWS Textract, pour produire le texte et les bounding boxes. La NER extrait ensuite des champs tels que invoice_number, vendor_name, line_items, total et due_date. La même séquence s’applique aux contrats, aux dossiers médicaux et aux documents réglementaires.

Les pipelines documentaires modernes peuvent combiner compréhension de la mise en page, extraction d’entités et extraction de relations. L’OCR ou un modèle documentaire sensible à la mise en page fournit toujours le texte, l’ordre de lecture, les tableaux et les bounding boxes. GLiNER 2 peut ensuite combiner l’extraction structurée d’entités, de relations, de classifications et de structures hiérarchiques sur ce texte en un seul passage piloté par un schéma.

Le coût détermine la plupart de ces pipelines. Établissez vos coûts à partir du volume mensuel réel de documents, en incluant les retries et la revue. Un encodeur compact peut s’exécuter sur CPU, tandis qu’un LLM accessible par API ajoute un coût d’inférence et une latence par document. Un test pratique consiste à faire annoter par un LLM un jeu représentatif de factures. Faites du fine-tuning de GLiNER sur les enregistrements révisés, puis comparez les deux chemins selon le F1 au niveau des champs, la latence et le coût total.

Détection des PII et guardrails pour LLMs

Les principes de protection des données et obligations de sécurité du RGPD (articles 5, 25 et 32), la Security Rule de HIPAA, neutre technologiquement (guidance du HHS), ainsi que le CCPA californien, tel qu’amendé par le CPRA, imposent des droits et des mesures de protection fondées sur les risques qui diffèrent. Les dispositions citées ne prescrivent ni la NER ni une architecture spécifique de scan pré-modèle. Ceci ne constitue pas un conseil juridique ; demandez à un conseil d’examiner les exigences applicables à vos données et à votre juridiction. La NER peut contribuer à l’inventaire des données, à la minimisation ou à la désidentification, mais elle ne constitue qu’un contrôle dont le recall doit être validé pour les données et la juridiction concernées.

La NER traite directement ce cas. Les modèles de désidentification identifient les spans PERSON, SSN, PHONE, EMAIL et ADDRESS, puis les masquent ou les remplacent par des équivalents synthétiques. Microsoft Presidio combine des recognizers avec des opérateurs d’anonymisation, et ses exemples incluent GLiNER comme recognizer. Le modèle GLiNER2-PII de 0,3B paramètres constitue une autre option : son article couvre 42 types de PII à la résolution du span de caractères. Aucun des deux ne constitue une preuve de conformité. Validez le recall selon le format des données, la juridiction, la langue et la classe de PII avant d’utiliser un détecteur comme contrôle.

Dans la comparaison menée par le fournisseur John Snow Labs sur 48 documents open source annotés par des experts et couvrant six classes de PHI, son évaluation au niveau des tokens a rapporté un F1 de 96 %. Elle rapporte 91 % pour Azure, 83 % pour AWS et 79 % pour GPT-4o. L’étude a fait correspondre les labels des fournisseurs à son schéma de référence et exclu les prédictions impossibles à mapper. Considérez-la comme une comparaison restreinte entre fournisseurs, et non comme une preuve de conformité. Un autre rapport de déploiement décrit le traitement de plus de 100 000 notes cliniques par jour par Providence.

Pour les guardrails des LLMs, la NER fonctionne comme une couche de pré-filtrage : analysez l’entrée utilisateur à la recherche de PII avant de l’envoyer à une API externe, puis bloquez-la ou anonymisez-la. Cette approche peut être plus rapide ou plus simple que de demander au LLM de s’auto-modérer. Considérez-la comme une hypothèse de déploiement : mesurez les deux chemins avec votre modèle, votre matériel, votre mix d’entrées et votre cible de recall. Des faux négatifs restent possibles ; ajoutez donc un autre contrôle adapté au niveau d’exposition aux PII que votre système ne peut pas accepter. GLiNER est particulièrement utile ici, car les catégories de PII varient selon les juridictions. Vous pouvez ajouter de nouveaux types d’entités, comme « informations génétiques », dans le cadre d’une nouvelle réglementation sans réentraîner le modèle.

GLiNER : mise en correspondance span-label pour une NER à vocabulaire ouvert

GLiNER (NAACL 2024, Zaratiana et al.) a rendu la NER fondée sur des encodeurs compétitive face aux LLMs pour une fraction du coût. Au lieu de traiter la NER comme une classification séquentielle ou une génération de texte, GLiNER la traite comme un problème de matching. Il évalue chaque span de texte candidat (chaque séquence contiguë de mots comme « Bill Gates » ou « Microsoft ») par rapport à chaque label de type d’entité, puis conserve les paires obtenant les scores les plus élevés.

Le modèle reçoit les labels des types d’entités et le texte d’entrée sous la forme d’une séquence unique : [ENT] person [ENT] organization [ENT] date [SEP] Bill Gates founded Microsoft.... Un transformer bidirectionnel (DeBERTa-v3) encode l’ensemble.

À partir de la sortie, le modèle construit deux ensembles de représentations. L’un représente les types d’entités à partir des positions de tokens [ENT]. L’autre représente les spans de texte en combinant les vecteurs des tokens de début et de fin via un petit FFN. Un produit scalaire entre une représentation de span et une représentation de type d’entité produit un score.

Appliquez une sigmoïde et vous obtenez la probabilité que le span allant du token $i$ au token $j$ appartienne au type d’entité $t$ : $\phi(i, j, t) = \sigma(S_{ij}^T \cdot q_t)$. Ici, $S_{ij}$ est le vecteur du span produit par le FFN et $q_t$ l’embedding du type d’entité issu du token [ENT] correspondant (Zaratiana et al., 2024, équations 1–2). Les spans sont limités à 12 tokens pour conserver de bonnes performances.

GLiNER accepte des descriptions de labels en langage naturel au moment de l’inférence, sans réentraînement, mais la qualité d’extraction dépend de la formulation des labels et de l’adéquation au domaine. Vous fournissez des types d’entités tels que « personne », « réaction indésirable à un médicament » ou « instrument financier », puis le modèle évalue les spans par rapport à ces types. Les configurations 50M, 90M et 300M ci-dessous sont les modèles de l’article original. La model card actuelle de v2.1 liste à la place des checkpoints anglais de 166M, 209M et 459M, ainsi qu’un checkpoint multilingue de 209M, tous sous Apache 2.0. Ne comparez pas la latence ou la mémoire entre ces générations comme si les noms de paramètres étaient identiques (model card GLiNER v2.1).

Pour un véritable test hard zero-shot, mettez de côté les types cibles ainsi que les exemples cibles. Une description de type telle que « effet indésirable médicalement confirmé causé par un traitement » fournit davantage d’informations au modèle que adverse event seul. Cela ne garantit pas le transfert, mais le ZeroNER fondé sur des descriptions a dépassé les baselines utilisant uniquement le nom sur ses benchmarks à types exclus (Cocchieri et al., 2025).

Les données d’entraînement du modèle original provenaient du dataset Pile-NER : 44 889 passages contenant 240K spans d’entités répartis sur 13K types d’entités, tous labellisés par ChatGPT. L’entraînement de GLiNER-L a pris environ 5 heures sur un seul A100 (Zaratiana et al., 2024).

Résultats des benchmarks

Résultats zero-shot de Zaratiana et al. (2024), tableaux 1 et 2 :

Avec 90M paramètres, GLiNER-M égale presque UniNER-13B dans le tableau CrossNER de l’article (55,4 % contre 55,6 % de F1), tout en utilisant environ 140 fois moins de paramètres. GLiNER-S, avec 50M paramètres, dépasse de 5 points de F1 le résultat rapporté pour ChatGPT (GPT-3.5). La variante multilingue, entraînée uniquement sur des données anglaises, dépasse cette même baseline ChatGPT dans 8 des 10 langues non anglaises (Zaratiana et al., 2024). Ces comparaisons utilisent les versions des modèles et le harness de l’article ; elles n’établissent pas de classement face aux LLMs plus récents.

Les variantes de GLiNER couvrent les textes biomédicaux, la détection de PII, les actualités et le support multilingue.

Depuis 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

Comparaison entre GLiNER et spaCy

spaCy est l’une des bibliothèques NLP les plus établies en production. Elle fonctionne également sous des contraintes architecturales différentes de celles de GLiNER.

Les pipelines spaCy (en_core_web_sm, en_core_web_trf) effectuent une NER à vocabulaire fermé : un ensemble fixe de types d’entités (PERSON, ORG, GPE, DATE, etc.) défini lors de l’entraînement. Vous voulez un nouveau type d’entité ? Collectez des données annotées et réentraînez le modèle. Épinglez le package de modèle 3.8 maintenu, au lieu de supposer qu’une branche majeure non publiée constitue une mise à niveau de production. La model card du modèle en_core_web_trf 3.8.0 rapporte un F1 NER de 90,19 sur OntoNotes 5.0, mais uniquement pour ses 18 types prédéfinis (model card spaCy).

GLiNER effectue une NER à vocabulaire ouvert : n’importe quel label fonctionne au moment de l’inférence, sans réentraînement. C’est le meilleur choix lorsque les types d’entités sont inconnus à l’avance, changent fréquemment ou sont spécifiques au domaine (« réaction indésirable à un médicament », « instrument financier », « indicateur de menace »).

Ma recommandation : utilisez spaCy pour les types d’entités standard lorsque les pipelines préentraînés sont bien validés. Utilisez GLiNER lorsque vous avez besoin de types flexibles en zero-shot ou lorsque votre pipeline doit s’adapter sans réentraînement. Ils peuvent partager un pipeline, spaCy prenant en charge la tokenisation et la segmentation des phrases, et GLiNER l’extraction des entités.

Une baseline Transformer supervisée

Pour des labels stables accompagnés de spans annotés représentatifs, commencez par un token classifier fine-tuné tel que RoBERTa ou DeBERTa comme baseline supervisée. Cette approche échange de la flexibilité sur les labels contre une meilleure précision spécifique à la tâche. Comparez-la à spaCy et GLiNER selon le F1 sur les spans exacts, le recall par label, la calibration, la latence et le coût, sur le même jeu de données du domaine.

UniNER et NuNER : jusqu’où peut-on réduire la taille ?

UniNER (ICLR 2024, Zhou et al.) et NuNER (EMNLP 2024, Bogdanov et al.) distillent tous deux des annotations de LLMs dans des modèles NER plus petits — mais leurs conclusions divergent sur la taille minimale possible.

UniNER : l’approche maximaliste

UniNER effectue le fine-tuning de LLaMA-7B/13B sur 45 889 paires entrée-sortie générées par ChatGPT. Pour chaque type d’entité, le modèle répond à la question « Qu’est-ce qui décrit [type] dans le texte ? » et produit des listes JSON. Une astuce d’entraînement essentielle : l’échantillonnage négatif fondé sur la fréquence fait passer le F1 de 31,5 % à 53,4 % (Zhou et al., 2024).

UniNER-7B atteint 41,7 % de F1 zero-shot sur 43 datasets, dépassant les 34,9 % de ChatGPT de 7 points. La variante 13B atteint 43,4 %, soit seulement 1,7 point supplémentaire pour près de deux fois plus de compute (Zhou et al., 2024).

Le compromis pour la production : la configuration UniNER à meilleur score de l’article interroge chaque type d’entité séquentiellement. Sa variante tout-en-un utilise une seule réponse, mais obtient en moyenne 3,3 % de moins. En FP16, un checkpoint 7B nécessite environ 14 Go rien que pour les poids ; une quantification en nombre de bits inférieur peut réduire cette empreinte. Le modèle est également soumis à une licence CC BY-NC 4.0 restrictive.

NuNER : l’approche minimaliste

NuNER part de RoBERTa-base (125M paramètres) et utilise un entraînement contrastif avec 4,38 millions d’annotations GPT-3.5 couvrant 200K concepts. Après l’entraînement, l’encodeur de concepts est supprimé ; l’encodeur de texte s’intègre à n’importe quel pipeline NER standard en remplacement de RoBERTa (Bogdanov et al., 2024).

NuNER dépasse RoBERTa standard de 6 à 15 points de F1 pour toutes les tailles few-shot. Avec seulement une douzaine d’exemples par type d’entité, NuNER égale UniNER-7B tout en étant 56 fois plus petit (Bogdanov et al., 2024).

Les deux articles montrent qu’il est possible de distiller des annotations de LLMs dans des modèles NER plus petits. NuNER montre qu’un encodeur de 125M paramètres peut atteindre le résultat rapporté pour UniNER-7B lorsqu’il dispose de données de fine-tuning spécifiques à la tâche, avec une licence MIT et une inférence adaptée au CPU.

GLiNER 2 : un modèle, quatre tâches

L’écosystème GLiNER original séparait la NER, l’extraction de relations, la classification et l’extraction au niveau document dans des modèles distincts. L’article GLiNER2 publié à EMNLP 2025 a unifié la NER, la classification et l’extraction hiérarchique dans un modèle de 205M paramètres ; les releases actuelles ont ensuite ajouté l’extraction de relations à la même interface de schéma.

L’architecture conserve la conception cross-encoder, mais étend le contexte à 2 048 tokens (4 fois plus que l’original) et ajoute des schémas déclaratifs pour définir les tâches d’extraction. L’entraînement utilise 135 698 documents réels annotés avec GPT-4o ainsi que 118 636 exemples synthétiques (Zaratiana et al., 2025).

Sur CrossNER zero-shot, GLiNER 2 obtient un F1 de 0,590, proche du 0,599 de GPT-4o dans le benchmark de l’article datant de mi-2025. Pour la classification, sa moyenne est de 0,72 sur 7 benchmarks, contre 0,69 pour DeBERTa-v3-large. Sur CPU, l’article rapporte une latence de classification de 130 à 208 ms selon les nombres de labels testés. La baseline DeBERTa passe de 1 714 ms pour 5 labels à 16 897 ms pour 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"))
text = "Acme launched a $19 widget in Berlin."
results = extractor.extract(text, schema)

Les releases actuelles de GLiNER2 exposent la reconnaissance d’entités, la classification, l’extraction hiérarchique et l’extraction de relations via un seul schéma. L’article EMNLP évalue la NER et la classification ; il ne fournit pas de benchmark d’extraction hiérarchique et ne couvre pas la relation API ajoutée ultérieurement. Considérez le chemin à quatre tâches comme une capacité de déploiement à benchmarker, et non comme la preuve qu’un seul modèle conserve la précision de quatre modèles spécialisés.

Ajouts 2026 : choisir l’architecture qui correspond au bottleneck

L’écosystème GLiNER dispose désormais d’architectures distinctes. Ce sont des candidates pour une comparaison dans votre domaine, pas les modèles d’un leaderboard unique.

L’article GLiNER original, l’article sur le bi-encoder et GLiNER-Relex utilisent chacun leurs propres modèles et harnesses. Les model cards de GLiNER-X et de GLiNER Decoder décrivent des checkpoints publiés, mais il ne s’agit pas d’un benchmark comparable évalué par les pairs. Conservez cette distinction dans un decision record d’architecture.

Les licences des checkpoints font partie du choix du modèle

Vérifiez les conditions exactes applicables au code, aux poids et aux datasets avant le déploiement. Les releases actuellement citées ne sont pas interchangeables :

Les indications de licence ne constituent pas un conseil juridique. Une revue de production doit inclure les conditions du modèle de base, des données d’entraînement et des fournisseurs.

Le bi-encoder : passer à la NER avec un million de labels

GLiNER original encode conjointement les labels et le texte. Cet encodage conjoint devient progressivement plus coûteux, car le texte des labels consomme du contexte et doit être réencodé avec chaque document. Le point de bascule dépend du checkpoint, des descriptions de labels et du matériel. Lorsque le même inventaire volumineux de types est réutilisé sur de nombreux documents, faites du GLiNER bi-encoder votre première comparaison. Il sépare l’encodage du texte et celui des labels en deux transformers distincts (Stepanov et al., 2026).

L’encodeur de texte utilise ModernBERT (famille Ettin), tandis que l’encodeur de labels utilise des sentence transformers (BGE ou MiniLM). Les spans et les labels sont évalués par produit scalaire. Cette séparation signifie que les embeddings des types d’entités peuvent être pré-calculés une seule fois et mis en cache. Lors de l’inférence, seul le texte doit être encodé ; le côté labels devient une lecture du cache.

Quatre tailles de modèles sont disponibles, toutes évaluées sur CrossNER (Stepanov et al., 2026, tableau 1) :

Avec 1 024 types d’entités, le bi-encoder gliner-bi-edge-v2.0 pré-calculé ne perd que 5,2 % de throughput par rapport à un seul label (19,3 → 18,3 ex/s). Le uni-encoder gliner_small-v2.5 comparable en perd 98,7 % (10,7 → 0,14 ex/s). Dans les tests de l’article réalisés sur un seul H100, avec une batch size de 1 et des entrées de 64, 256 et 512 tokens, le bi-encoder pré-calculé atteint jusqu’à 130 fois plus de throughput que gliner_small-v2.5. Avec 100 types d’entités sur un seul H100, le bi-encoder traite 1,96 million de prédictions par jour, contre 368K pour le cross-encoder (Stepanov et al., 2026).

La précision reste également solide. Bi-encoder-large atteint 61,5 % de F1 CrossNER, soit légèrement plus que les 60,9 % du cross-encoder. Les auteurs recommandent bi-base-v2.0 (194M) comme meilleur compromis : 98 % de la précision du grand modèle à 2,6 fois sa vitesse (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)

Les applications incluent la NER biomédicale sur l’ontologie UMLS (plus de 4M concepts), les taxonomies d’entreprise qui évoluent sans réentraînement du modèle et l’entity linking via le framework associé GLiNKER.

Les LLMs comme enseignants : une étude de cas $70 et un pipeline déployable

Le pattern LLM-as-teacher sépare l’annotation coûteuse de l’inférence moins chère. Deux études de cas publiées montrent comment des équipes l’ont appliqué dans des conditions différentes.

L’étude de cas CFM

Dans une étude de cas Hugging Face, Capital Fund Management a extrait les noms d’entreprises d’environ 900 000 titres d’actualités financières. GLiNER zero-shot a obtenu un F1 de 87,0 %. L’équipe a utilisé Llama 3.1-70B pour annoter le dataset en environ 8 heures pour environ $70, puis a révisé 2 714 échantillons via Argilla pendant 8 heures supplémentaires.

Le fine-tuning de GLiNER sur ces données a atteint 93,4 % de F1 dans l’étude de cas, contre 92,7 % pour le teacher Llama-70B. Les auteurs rapportent $0,10 par heure sur CPU pour le modèle fine-tuné et $8 par heure pour le teacher (étude de cas CFM). Ces chiffres décrivent une tâche d’actualités financières et une configuration d’infrastructure particulières.

L’étude de Refuel AI

Le rapport technique de Refuel AI évalue le labelling par LLM sur 8 datasets NLP, dont CoNLL-2003. Il rapporte 88,4 % d’accord avec la vérité terrain pour GPT-4 (mars 2023) et 86,2 % pour les annotateurs humains dans sa configuration, ainsi qu’un labelling 20 fois plus rapide et 7 fois moins cher. Son ensemble de modèles achemine les exemples faciles vers des modèles moins coûteux et les exemples difficiles vers GPT-4, atteignant plus de 95 % d’accord dans les expériences rapportées (rapport technique de Refuel AI). Considérez ces résultats comme des résultats rapportés par un fournisseur, obtenus selon le protocole d’annotation de cette étude.

Un pipeline de production

Un flux de production pratique comporte six étapes :

1. Rédiger les consignes d’annotation en langage naturel
2. Créer des jeux de validation et de test held-out annotés par des humains, dimensionnés selon la prévalence des entités, les besoins de slices par label et la largeur souhaitée des intervalles de confiance. Un pilote de 50 à 200 documents peut aider à calibrer les consignes, mais ne constitue pas une taille d’évaluation de production par défaut.
3. Utiliser un LLM avec un prompt versionné et un schéma de sortie explicite pour labelliser les données d’entraînement en volume ; conserver la version du modèle, le prompt et le texte source avec chaque label
4. Réviser un sous-ensemble via Argilla ou Label Studio
5. Faire du fine-tuning d’un encodeur compact (GLiNER, SpanMarker, RoBERTa)
6. Déployer uniquement si l’encodeur atteint le quality gate et réduit le coût total mesuré. CFM a rapporté un coût d’infrastructure horaire 16 à 80 fois inférieur dans sa configuration ; incluez les coûts d’annotation, de revue, de serving et de réentraînement dans votre comparaison.

Le LLM peut réduire le volume d’annotations manuelles, mais l’équipe reste responsable du jeu de validation, des consignes d’annotation, de la revue ciblée et de l’analyse des erreurs.

Là où GLiNER échoue et où les LLMs restent utiles

Le benchmark Sease (octobre 2025) a comparé GLiNER à GPT-4.1-mini sur 30 tâches d’analyse de requêtes. GPT-4.1-mini a obtenu 100 % de réponses entièrement correctes. GLiNER en a obtenu 53 % (16 sur 30). En revanche, GLiNER répondait en 0,08 seconde, contre 1,21 seconde pour le LLM — soit 15 fois plus rapide.

Dans ce benchmark de 30 tâches, GLiNER a échoué selon trois schémas récurrents :

1. Entités implicites : extraire « événement » de « Elton John s’est produit au Madison Square Garden » — le texte ne contient littéralement pas « événement », mais le LLM infère « concert »
2. Sensibilité à la formulation du label : « 2022 » obtient un score de 0,388 face à « date », mais 0,958 face à « year » — de petites variations de label entraînent de grands écarts de score
3. Mapping de valeurs : GLiNER renvoie le texte exact (« family houses ») au lieu de la valeur canonique (« Single family house »). Un LLM peut effectuer cette normalisation lorsque son prompt et son schéma définissent les valeurs cibles.

Entités imbriquées et chevauchantes

GLiNER utilise par défaut un décodage plat, qui supprime les spans chevauchants. Son API prend également en charge flat_ner=False ; les prédictions imbriquées sont donc possibles, même si leur qualité dépend du checkpoint, des labels et des données du domaine. Évaluez les deux modes de décodage sur un jeu de test au niveau des spans contenant des entités imbriquées avant de choisir un modèle spécialisé.

Utilisez GLiNER pour l’extraction d’entités explicites et acheminez vers un LLM les cas nécessitant inférence, raisonnement ou mapping vers des ontologies prédéfinies. Le seuil de routage doit provenir d’un jeu de données annoté du domaine.

Évaluer la NER : métriques, pièges et jeux de test

Un modèle peut obtenir 95 % de F1 sur un jeu de test soigneusement constitué et tout de même échouer sur le mix de documents rencontré après le déploiement. Construisez le jeu d’évaluation à partir de la distribution de production et conservez des slices pour les formats et types d’entités rares que le F1 agrégé peut masquer.

Les métriques essentielles

• F1 au niveau des entités : la métrique standard. Une prédiction n’est correcte que si les limites du span et le type correspondent exactement à la vérité terrain. C’est ce que rapportent la plupart des articles.
• F1 au niveau des tokens : chaque token est évalué indépendamment. Cette métrique gonfle les résultats, car identifier correctement la majeure partie d’une entité longue rapporte un crédit partiel. Préférez le F1 au niveau des entités.
• Precision et Recall : leurs coûts sont souvent asymétriques. Pour la désidentification, le recall est plus important — manquer un nom est pire que masquer trop de texte. Pour l’extraction vers une base de données, la precision est plus importante — les fausses entrées corrompent l’analyse downstream.

Pièges courants de l’évaluation

1. Gonflement dû aux correspondances partielles : « Bill » est extrait alors que le label de référence est « Bill Gates » — certains scripts comptent cela comme une correspondance partielle. Utilisez une correspondance exacte des spans, sauf raison particulière.
2. Confusion de types : « Microsoft » est correctement identifié comme span, mais labellisé PERSON au lieu de ORG ; le score devrait être nul. Vérifiez que votre code d’évaluation gère ce cas.
3. Fuite du jeu de test : si les entités du test recouvrent celles de l’entraînement, les scores sont gonflés. Les benchmarks zero-shot (CrossNER, Few-NERD) servent à tester la généralisation.
4. Prompts de labels non contrôlés : un nom de type court et une description de type testée sont des entrées différentes. Versionnez les descriptions de labels, les seuils, les révisions de checkpoints et le mode de décodage avec le score.
5. Affirmations zero-shot dans une seule langue : n’inférez pas la qualité multilingue à partir de l’anglais. OpenNER couvre 36 corpus et 52 langues, et ses baselines n’ont trouvé aucun modèle unique meilleur dans toutes les langues (Palen-Michel et al., 2025). Dans les expériences FiNERweb, le passage de labels anglais à des labels dans la langue cible a modifié le F1 de 0,02 à 0,09 selon la configuration (Golde et al., 2026). Testez les deux langues de labels lorsque le produit utilise une terminologie locale.
6. Un seul run ne constitue pas un verdict : lorsque c’est pertinent, rapportez la variation entre seeds aléatoires, les sweeps de seuils et des échantillons de production répétés. Un faible nombre d’exemples dans une slice rend le classement des modèles instable.

Construire un jeu de test de domaine

Pour l’évaluation en production, je recommande :

1. Échantillonnez des données de production, pas des exemples sélectionnés. Incluez les documents imparfaits que votre modèle verra réellement.
2. Dimensionnez le jeu de test pour l’estimation nécessaire. Choisissez le nombre d’exemples selon la prévalence des entités, la taille des slices par label et la largeur souhaitée de l’intervalle de confiance. Rapportez des intervalles de confiance bootstrap ou analytiques.
3. Utilisez au moins deux annotateurs sur un sous-ensemble de calibration. Arbitrez les désaccords et rapportez une mesure d’accord tenant compte des spans. L’accord permet de diagnostiquer l’ambiguïté et la qualité des consignes ; il ne constitue pas un plafond de performance du modèle.
4. Stratifiez par difficulté — cas faciles (texte propre, types standard) et difficiles (entités ambiguës, jargon, texte bruité).
5. Conservez des slices de confidentialité et d’équité. Pour les PII, rapportez le recall par type de PII, langue, région, format documentaire et slices démographiques ou liées à l’origine des noms pertinentes. Limitez l’accès des évaluateurs au texte sensible brut, définissez des durées de conservation et examinez les faux négatifs.

La NER continue nécessite un jeu de régression immuable

Les taxonomies de production évoluent. Ajoutez de nouveaux types sans modifier silencieusement la signification d’un type existant. Conservez un jeu de régression versionné et immuable pour les types existants, un jeu de test distinct pour le nouveau type et un changelog des modifications des consignes d’annotation. Rapportez séparément les scores des anciens et des nouveaux types avant de remplacer un checkpoint. C’est le moyen le plus simple de détecter l’oubli et la dérive de taxonomie.

La NER en production dans quatre secteurs

Voici une sélection d’exemples industriels avec des chiffres précis dans les conditions rapportées. Les sources combinent des comparaisons rapportées par des fournisseurs, des études de cas rapportées par des entreprises ou des projets et des articles évalués par les pairs ou des preprints. Considérez-les comme des exemples pratiques, pas comme un classement de maturité.

Santé

John Snow Labs propose des modèles d’entités cliniques mappés vers ICD-10, SNOMED CT, LOINC et RxNorm. Dans sa comparaison rapportée par le fournisseur sur 48 documents et six classes, son évaluation au niveau des tokens a rapporté un F1 de 96 %, contre 91 % pour Azure, 83 % pour AWS et 79 % pour GPT-4o. La comparaison a remappé les labels et exclu les prédictions impossibles à mapper. Une étude de cas distincte rapportée par le fournisseur décrit Providence St. Joseph Health traitant 100 000 à 500 000 notes cliniques par jour.

Dans son bilan de projet 2025, le projet open source OpenMed rapporte plus de 380 modèles NER biomédicaux, 29,7 millions de téléchargements Hugging Face et les meilleurs résultats sur 10 des 12 benchmarks biomédicaux publics.

NER financière

Le principal cas d’usage est l’extraction de documents déposés auprès de la SEC. Finance NLP de John Snow Labs extrait plus de 11 types d’entités de documents 10-K/10-Q (adresses, tickers, exercices fiscaux, places boursières). Des variantes de FinBERT-MRC évaluées par les pairs atteignent un F1 de 0,87 à 0,93 sur des tâches d’entités financières. Les difficultés principales sont les documents longs et les entités imbriquées dans des instruments financiers complexes.

E-commerce

Des articles évalués par les pairs rapportent que le système EAMT de Walmart (KDD 2023) s’entraîne sur 965 millions de requêtes, avec environ 60 labels d’entités, et a produit une hausse de 0,51 % du GMV lors de tests A/B. Le framework TripleLearn de Home Depot (AAAI 2021) a fait passer le F1 NER de 69,5 à 93,3 grâce à un entraînement itératif.

Cybersécurité

Le système iACE, évalué par les pairs (CCS 2016), a traité 71 000 articles issus de 45 blogs de sécurité et extrait 900K éléments OpenIOC avec une precision de 95 % et une couverture supérieure à 90 %. Un rapport de projet consacré à des systèmes modernes comme CyNER décrit la combinaison de DeBERTa (F1 >91 %) avec des heuristiques IOC fondées sur des regex. Le preprint CyberNER présente un dataset unifié 2025 harmonisant quatre datasets en 21 types d’entités alignés sur STIX 2.1, avec un F1 de 0,736 pour RoBERTa.

Optimisation du déploiement : de Python à une inférence à plus faible latence

Le repository associé montre l’export GLiNER vers ONNX et le packaging INT8. Il consigne les tailles des artefacts, mais ne reproduit pas les chiffres de latence ou de F1 rapportés par des projets externes.

Serving natif de GLiNER

Avant de passer à un nouveau runtime, testez le chemin Ray Serve du projet. gliner[serve] fournit du dynamic batching, un dimensionnement des batchs tenant compte de la mémoire, une mise à l’échelle multi-réplicas et un client HTTP. Il peut supprimer l’overhead de mise en file d’attente d’un service multi-utilisateur tout en conservant le même code de modèle. Mesurez la latence en file d’attente, la latence à chaud, le throughput et le F1 sur les spans exacts avec votre mix de requêtes avant de le comparer à ONNX ou à Rust.

Export ONNX

GLiNER dispose d’une conversion ONNX native, et des modèles préconvertis existent sur Hugging Face (onnx-community/gliner_small-v2.1). Mesurez la latence par rapport au même checkpoint PyTorch, avec la même batch size, le même matériel et le même protocole de warm-up.

Depuis scripts/02_onnx_export.py :

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

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

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

Quantification INT8

La quantification dynamique peut réduire les besoins en stockage et en mémoire d’un modèle ONNX. Son effet sur la latence et le F1 par label dépend du checkpoint et du CPU ; le script d’export constitue donc une preuve de packaging, pas un benchmark de déploiement.

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 : réimplémentation en Rust

gline-rs (Apache 2.0) supprime le runtime Python du chemin d’inférence. Son benchmark v0.9.0 en mode token, réalisé sur un Intel i9 avec trois labels, rapporte 6,67 seq/s contre 1,61 pour Python, et son résultat sur RTX 4080 est de 248,75 seq/s. Ces chiffres proviennent des conditions propres au projet et n’ont pas été reproduits par le repository associé. Il prend en charge les modèles span et token, le GPU/NPU via ONNX Runtime, et est distribué sous forme de crate sur crates.io.

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%)

Le package fast-gliner fournit des bindings Python via PyO3.

Ce que couvrent les éléments de preuve d’optimisation

Extraction structurée : native schemas, Instructor et décodeurs locaux

Lorsque vous avez besoin de davantage de flexibilité que les modèles encodeurs — entités implicites, raisonnement, mapping d’ontologie — commencez par le mécanisme de schéma natif du fournisseur. OpenAI prend en charge les formats de réponse stricts json_schema, les structured outputs d’Anthropic prennent en charge les sorties JSON et les tool inputs stricts, et la Gemini API prend en charge un sous-ensemble de JSON Schema. Un modèle Pydantic ou Zod partagé peut décrire le contrat, mais chaque fournisseur accepte un sous-ensemble de schéma différent et présente des comportements différents en matière de refus et de complexité.

La conformité au schéma rend le parsing fiable. Elle ne prouve pas qu’un span extrait existe dans le texte source ni qu’une valeur normalisée est correcte. Validez les valeurs des champs, conservez les offsets ou les citations lorsque c’est possible et évaluez la précision sémantique sur un jeu annoté.

Instructor encapsule les clients fournisseurs avec une validation Pydantic et des retries optionnels après les échecs de validation.

Adapté du pattern Instructor dans scripts/05_structured_extraction.py :

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

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

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

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

Outlines, développé par dottxt, adopte une approche différente : la génération de tokens contrainte par des finite-state machines. Le décodeur masque les tokens qui violeraient la grammaire cible au lieu d’attendre un échec de validation puis de lancer un retry. Une présentation AWS cite une adhérence au schéma de 98 %, contre 76 % pour la validation post-génération. Elle reprend séparément l’affirmation de .txt Engineering selon laquelle son approche de coalescence permettrait une génération jusqu’à 5 fois plus rapide ; la page ne publie pas suffisamment de méthodologie pour considérer ces deux chiffres comme un benchmark contrôlé unique.

import outlines
from transformers import AutoModelForCausalLM, AutoTokenizer

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

LangExtract est utile lorsqu’un champ généré doit être ancré dans la source : il renvoie des intervalles de caractères et prend en charge des backends LLM hébergés ou locaux. Pour l’extraction documentaire self-hosted, NuExtract convertit les schémas JSON en templates et inclut des modèles documentaires multimodaux. Considérez ces deux outils comme des systèmes d’extraction structurée, et non comme des remplaçants automatiques de la NER sur spans. Leurs objectifs en matière de champs, d’offsets, de mise en page documentaire et de latence nécessitent leurs propres tests.

Le choix dépend de l’endroit où vous exécutez vos modèles. Les native schemas constituent le chemin demandant le moins d’effort pour un fournisseur pris en charge. Instructor ajoute une couche de validation et de retry Pydantic indépendante du fournisseur. Outlines contraint la génération locale selon un schéma. LangExtract donne la priorité à l’ancrage dans la source, tandis que NuExtract cible l’extraction documentaire self-hosted. Tous les chemins LLM incluent néanmoins une génération autorégressive. Évaluez chaque chemin par rapport à un encodeur avec la même batch size, le même matériel, le même schéma d’entités et la même grille de précision sémantique.

L’architecture de production à trois niveaux

Je routerais la NER de production selon la forme de la tâche plutôt que selon un classement unique des modèles.

Niveau 1 : modèles encodeurs pour les spans explicites. Utilisez un GLiNER cross-encoder pour un petit inventaire de types. Lorsqu’un inventaire important est réutilisé, comparez le bi-encoder avec des embeddings de types mis en cache. Effectuez le fine-tuning via le pipeline LLM-as-teacher, puis déployez avec le serving natif, ONNX, INT8 ou gline-rs uniquement si ce chemin réussit le benchmark du domaine.

Niveau 2 : extraction multi-tâche ou de relations. Lorsqu’une requête nécessite simultanément la NER, la classification et des champs hiérarchiques, testez le modèle partagé 205M paramètres de GLiNER2. Lorsque l’exigence centrale porte sur des spans et des relations conjointes, testez GLiNER-Relex. L’article GLiNER2 rapporte une latence de classification CPU de 130 à 208 ms selon les nombres de labels testés ; cela ne constitue pas une preuve pour la relation API ultérieure ni pour un déploiement différent.

Niveau 3 : LLMs pour l’extraction exigeant du raisonnement. Acheminez les entités implicites, l’inférence contextuelle et le mapping d’ontologie vers une native schema API ou Instructor pour les APIs cloud, et vers Outlines pour une sortie locale contrainte. Utilisez LangExtract lorsque les intervalles dans la source sont essentiels et NuExtract lorsque le document lui-même constitue l’entrée. Journalisez ces cas, car ils sont candidats pour le prochain jeu d’entraînement du niveau 1.

L’étude de cas CFM fournit une référence de coût pour le niveau 1 : 93,4 % de F1 pour un coût rapporté de $0,10 par heure sur CPU, contre 92,7 % de F1 et $8 par heure pour son teacher Llama-70B. Recalculez cette comparaison avec votre matériel, votre modèle teacher, votre jeu de labels et vos coûts de revue.

Compromis et limites

Pour chacun des compromis ci-dessous, les questions utiles sont de savoir où il apparaît et si vous pouvez le mesurer avant le déploiement.

Les erreurs du LLM-as-teacher se propagent. Si le LLM se trompe systématiquement sur un type d’entité donné (par exemple en confondant les noms de filiales et ceux des sociétés mères), l’encodeur fine-tuné hérite de ce biais. La solution consiste à effectuer une revue humaine ciblée — concentrez l’effort sur les types d’entités pour lesquels la confiance du LLM est faible ou instable, plutôt que sur un échantillonnage aléatoire.

Un schéma valide peut contenir de faux faits. Les structured outputs natives, Instructor et les décodeurs contraints peuvent rendre une réponse parsable. Ils ne peuvent pas garantir que chaque champ est ancré dans la source, que les limites d’un span sont correctes ou qu’une valeur normalisée correspond au bon enregistrement. Conservez les preuves sources et validez séparément la sémantique.

Les pertes dues à la quantification dépendent du checkpoint et des données. Le repository associé crée un artefact INT8 quantifié dynamiquement, mais ne mesure pas son F1. Les recommandations GLiNER actuelles préconisent le quantization-aware training lorsque la précision INT8 doit être préservée. Comparez les checkpoints quantifié et original selon le F1 sur les spans exacts et le recall par label avant le déploiement.

Quand l’architecture à trois niveaux est excessive. Un domaine unique avec des types d’entités stables et suffisamment d’exemples labellisés peut n’avoir besoin que d’un pipeline RoBERTa ou spaCy fine-tuné. Le pattern à trois niveaux convient à plusieurs domaines, à des types d’entités qui évoluent ou à un mix mesuré d’extraction explicite et exigeant du raisonnement. Un pipeline de factures étroit qui extrait des noms et des dates peut s’arrêter au niveau 1.

La qualité du bi-encoder varie selon le dataset. L’encodage conjoint peut aider sur certains datasets, tandis que le bi-encoder remporte la comparaison CrossNER de l’article et que le uni-encoder le devance légèrement sur CoNLL-2003. Évaluez les deux sur le jeu du domaine ; choisissez selon la qualité mesurée sur les spans exacts, la calibration, le nombre de labels et le throughput, plutôt que d’utiliser « haut risque » comme règle de sélection d’une famille de modèles.

Les affirmations sur les PII et le multilingue nécessitent des slices. Un score agrégé élevé peut masquer une perte dangereuse de recall pour une région, une forme de nom, une mise en page documentaire ou une classe rare de PII. Considérez un modèle de confidentialité comme une défense en profondeur parmi d’autres, définissez un processus de traitement des faux négatifs et réévaluez-le lorsque la taxonomie, le mix linguistique ou la source des données évolue.

Points clés à retenir

1. Utilisez un encodeur compact pour les spans explicites uniquement après son passage sur un jeu de test du domaine incluant le support par type et les intervalles de confiance.
2. Utilisez GLiNER pour les vocabulaires de labels changeants. Comparez d’abord son bi-encoder lorsqu’un inventaire volumineux de types est réutilisé ; n’activez flat_ner=False qu’après avoir mesuré la qualité sur les spans imbriqués.
3. Utilisez des descriptions de types testées pour les affirmations hard zero-shot et évaluez séparément la formulation anglaise et localisée des labels pour les produits multilingues.
4. Conservez l’OCR, la NER, l’extraction de relations et l’entity linking comme étapes d’évaluation distinctes, même lorsqu’un modèle expose plusieurs tâches.
5. Considérez un LLM teacher comme un système de proposition d’annotations. Les consignes humaines, l’arbitrage, les jeux de régression immuables et un jeu de test held-out restent nécessaires.
6. Utilisez les native schemas pour les fournisseurs LLM pris en charge, mais validez séparément la justesse sémantique et l’ancrage dans la source de la validité JSON.
7. Évaluez séparément et conjointement les chemins de serving natif, ONNX, quantification et Rust. Ne multipliez jamais des gains de vitesse non mesurés.

Références

Articles

• GLiNER: Generalist Model for Named Entity Recognition using Bidirectional Transformer - Zaratiana et al., NAACL 2024. Architecture fondatrice de mise en correspondance span-entité.
• GLiNER2: An Efficient Multi-Task Information Extraction System with Schema-Driven Interface - Zaratiana et al., démonstrations de systèmes EMNLP 2025. Unifie la NER, la classification et l’extraction hiérarchique ; les releases actuelles ont ensuite ajouté l’extraction de relations.
• GLiNER Bi-Encoder: Scalable Named Entity Recognition with Bi-Encoder Architecture - Stepanov et al., février 2026. Encodage découplé pour l’échelle du million de labels.
• GLiNER-Relex: A Unified Framework for Joint Named Entity Recognition and Relation Extraction - Stepanov et al., 2026. Extraction zero-shot conjointe d’entités et de relations.
• GLiNER2-PII: A Multilingual Model for Personally Identifiable Information Extraction - Zaratiana et al., 2026. 42 types de PII à la résolution du span de caractères.
• ZeroNER: Fueling Zero-Shot Named Entity Recognition via Entity Type Descriptions - Cocchieri et al., ACL 2025. Évaluation hard zero-shot avec descriptions de types.
• OpenNER 1.0: Standardized Open-Access Named Entity Recognition Datasets in 50+ Languages - Palen-Michel et al., EMNLP 2025. 36 corpus, 52 langues et baselines multi-ontologies.
• FiNERweb: Datasets and Artifacts for Scalable Multilingual Named Entity Recognition - Golde et al., EACL 2026. Labels multilingues et évaluation du transfert.
• UniNER: Universal NER using Large Language Models - Zhou et al., ICLR 2024. NER universelle fondée sur les LLMs via distillation depuis ChatGPT.
• NuNER: Entity Recognition Encoder Pre-training via LLM-Annotated Data - Bogdanov et al., EMNLP 2024. Montre que 125M paramètres suffisent avec des données d’entraînement générées par un LLM.

Articles industriels

• EAMT: Entity-Aware Multi-Task Learning for Query Understanding - Walmart, KDD 2023. 965M requêtes, hausse de 0,51 % du GMV.
• TripleLearn: End-to-End NER for E-Commerce Search - Home Depot, AAAI 2021. F1 de 69,5 à 93,3.
• iACE: Automatic Collection of Cyber Threat Intelligence - CCS 2016. 71K articles, 900K IOC.
• CyberNER: A Harmonized STIX Corpus for Cybersecurity NER - 21 types d’entités alignés sur STIX 2.1.
• FinBERT-MRC: Financial NER via Machine Reading Comprehension - F1 de 0,87 à 0,93 sur des tâches d’entités financières.

Études de cas

• CFM Case Study: Fine-tuning GLiNER for Financial NER - Pipeline de labelling LLM de Capital Fund Management à $70, atteignant 93,4 % de F1.
• Refuel AI: LLM Labeling Technical Report - GPT-4 atteignant 88,4 % d’accord d’annotation, devant les annotateurs humains.
• Sease: GLiNER as an Alternative to LLMs for Query Parsing - Là où GLiNER échoue et où les LLMs restent nécessaires.
• John Snow Labs: Medical Text De-Identification Benchmark - Comparaison de détection PHI entre fournisseurs, avec 96 % de F1.
• OpenMed: Year in Review 2025 - Plus de 380 modèles NER biomédicaux, 29,7M téléchargements HuggingFace.

Outils et frameworks

• ner-field-guide demo repo - Démos associées à cet article : quickstart GLiNER, export ONNX, LLM-as-teacher et extraction structurée.
• gline-rs: Rust reimplementation of GLiNER - Accélération CPU de 4,1x par rapport à Python, sous licence Apache 2.0.
• GLiNER serving - Chemin Ray Serve avec dynamic batching et déploiement multi-réplicas.
• spaCy English pipelines - Métriques versionnées d’un pipeline à labels fermés.
• Microsoft Presidio - Analyse et anonymisation des PII avec des recognizers personnalisés.
• Instructor - Extraction structurée par LLM via des modèles Pydantic.
• Outlines - Génération de tokens contrainte via des FSMs, avec un benchmark rapporté d’adhérence au schéma.
• LangExtract - Extraction structurée ancrée dans la source avec intervalles de caractères.
• NuExtract - Extraction documentaire self-hosted, du schéma vers le template.
• OpenAI Structured Outputs - Référence du format de réponse JSON Schema strict.
• Anthropic Structured Outputs - Sorties JSON et tool inputs stricts.
• Gemini Structured Outputs - Sous-ensemble de JSON Schema pour les réponses structurées.
• AWS: Structured Output with Outlines - Benchmark d’adhérence au schéma à 98 %.