Guide NER 2026 : GLiNER, spaCy, Transformers et LLMs

Viacheslav Dubrov

2026-04-02 · Mis à jour 2026-09-06 · 44 min · Systèmes de recherche et de langage

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

Mise à jour de l’article

Publié initialement le 2 avril 2026. Relu et mis à jour le 6 septembre 2026. Cette mise à jour couvre les nouveaux modèles GLiNER, la détection streaming des PII, les APIs d’extraction structurée et l’interprétation des benchmarks.

La reconnaissance d’entités nommées (NER) transforme le texte en segments étiquetés qu’un programme peut exploiter. À partir de « Bill Gates founded Microsoft on April 4, 1975 », elle peut renvoyer les segments contigus Bill Gates, Microsoft et April 4, 1975, avec les types personne, organisation et date. Dans un encoder fondé sur les spans tel que GLiNER, le modèle lit le texte une seule fois et évalue les spans candidats par rapport aux labels que vous fournissez. Choisir un système de NER revient à déterminer le niveau de latence, de coût, de flexibilité des labels et de raisonnement nécessaire à cette extraction.

Le dépôt compagnon fournit des exemples smoke test pour GLiNER, l’export ONNX, la génération d’annotations et l’extraction structurée. Sa comparaison en trois phrases ne constitue pas un classement de modèles : le scorer fusionne les paires texte/type répétées et peut ignorer les documents gold finaux lorsque des prédictions manquent. Le script teacher ne montre pas non plus de conversion en spans d’entraînement relus. Utilisez ces exemples pour examiner les APIs, et non pour revendiquer un workflow complet d’entraînement ou d’évaluation. Pour les workloads dominés par des spans explicites, les encoders compacts sont généralement plus rapides et moins coûteux. Les LLMs restent utiles pour produire des données d’entraînement et traiter les cas nécessitant inférence ou normalisation. Les sections consacrées aux benchmarks expliquent les comparaisons publiées et leurs limites ; aucune ne correspond à une nouvelle exécution de benchmark pour ce guide.

Dépôt compagnon : 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 Meilleurs modèles NER en 2026.

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

La reconnaissance d’entités nommées identifie des spans dans le texte et leur attribue des types tels que personne, organisation, date, produit ou des labels propres au domaine. Un span est un segment contigu du texte d’origine. La NER identifie la mention ; l’entity linking est l’étape distincte qui la résout vers un enregistrement canonique ou un concept d’ontologie.

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

La NER identifie toujours des spans de texte et leur attribue 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 d’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 du benchmark.

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

La recherche par similarité seule rencontre des difficultés lorsqu’une question contient des entités précises. Pour « qu’a dit Anthropic au sujet de la sécurité des modèles au T4 2024 ? », l’extraction d’entités peut proposer « Anthropic » et « T4 2024 » comme filtres. N’appliquez un filtre strict que si les métadonnées indexées et la sémantique des dates le permettent ; sinon, utilisez-le comme signal de ranking ou conservez un chemin de retrieval non filtré. Un alias manqué ou une plage de dates inférée à tort peut exclure la réponse.

Lors de l’indexation, vous extrayez les entités de chaque chunk et les stockez comme métadonnées : {"organizations": ["Anthropic"], "dates": ["Q4 2024"], ...}. Vous pouvez ainsi filtrer par entité avant d’exécuter la recherche vectorielle. Le RAG par graphe de connaissances (GraphRAG, graphes de propriétés LlamaIndex) ajoute des relations nommées que le retrieval peut suivre sur plusieurs hops. Comparez cette approche aux recherches vectorielles répétées sur les questions et le corpus que vous devez prendre en charge.

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 envoyée vers un index financier ; une question mentionnant des médicaments est envoyée vers une base de connaissances clinique. GLiNER est utile lorsque le schéma ou les types d’entités au moment de la requête changent. Des noms d’entreprises ou de médicaments jamais vus 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 vers un outil, une demande telle que « planifie une réunion avec Sarah Chen d’Accenture jeudi à 14 h » peut produire PERSON: Sarah Chen, ORGANIZATION: Accenture, DATE: Thursday et TIME: 2pm. Un résolveur de calendrier combine ensuite la date et l’heure dans le timestamp attendu par l’API. Un encoder 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 taille de batch 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 dans les conversations. Les systèmes de mémoire d’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 ; la résolution de coréférence détermine si les mentions renvoient à la même personne dans le contexte. L’entity linking mappe ensuite cette personne vers un enregistrement canonique, lorsqu’il en existe un.

Dans les deux cas, la contrainte 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 encoder s’intègrent généralement mieux dans les agent loops que l’extraction fondée sur un LLM.

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 l’OCR, par exemple Tesseract, Azure Document Intelligence ou AWS Textract, pour produire le texte et les bounding boxes. La NER identifie ensuite les spans correspondant à des champs tels que invoice_number, vendor_name, total et due_date. Une étape de schéma ou d’extraction de relations doit regrouper les descriptions de lignes, les quantités et les prix dans line_items. 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. GLiNER2.5 expose actuellement les entités, les relations, la classification et les enregistrements structurés via une interface de schéma. Évaluez chaque sortie séparément ; l’article GLiNER2 plus ancien n’évaluait pas toutes les tâches désormais exposées par la bibliothèque.

Le coût détermine la plupart de ces pipelines. Calculez le prix sur le volume mensuel réel de documents, en incluant les retries et la revue. Un encoder compact peut fonctionner sur CPU, tandis qu’un LLM accessible par API ajoute un coût d’inférence et de la latence par document. Un test pratique consiste à faire annoter un ensemble représentatif de factures par un LLM. Fine-tunez GLiNER sur les enregistrements relus, 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 des LLMs

Les principes de protection des données et obligations de sécurité du RGPD (articles 5, 25 et 32), la Security Rule technologiquement neutre de la HIPAA (recommandations du HHS) et le CCPA californien, tel qu’amendé par le CPRA, imposent des droits et des mesures de protection différentes, fondées sur les risques. Les dispositions citées ne prescrivent ni la NER ni une architecture spécifique de scan pré-modèle. Ceci ne constitue pas un avis 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 parmi d’autres et son 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,3 milliard de paramètres est une autre possibilité : 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, 48 documents annotés par des experts couvrent six classes de PHI. Les labels des fournisseurs ont été remappés et les prédictions impossibles à mapper ont été exclues, ce qui limite l’interprétation inter-fournisseurs. Le rapport de Providence décrit 281 événements de fuite de PHI dans une revue de 1 000 notes contenant 34 701 phrases. Les événements ne correspondent pas à des phrases distinctes affectées : dans une évaluation de la confidentialité, comptez à la fois les instances divulguées et les documents concernés.

Pour les guardrails des LLMs, la NER fonctionne comme une couche de pré-filtrage : scannez les entrées utilisateur à la recherche de PII avant de les envoyer à une API externe, puis bloquez-les ou anonymisez-les. 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 sur votre modèle, votre matériel, votre mélange 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. Une API peut accepter un nouveau label tel que « informations génétiques » sans réentraînement. Cela ne garantit pas le recall de cette nouvelle catégorie ; validez-la sur des exemples relus avant de vous y fier.

GLiNER : matching span-label pour la NER à vocabulaire ouvert

GLiNER (NAACL 2024, Zaratiana et al.) a rendu la NER fondée sur des encoders compétitive avec les LLMs pour une fraction du coût. Au lieu de traiter la NER comme une étiquetage de séquence ou de la 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. Le premier affine chaque représentation de type d’entité à partir d’une position de token [ENT] via un petit réseau feed-forward (FFN) qui transforme le vecteur de l’encoder. Le second représente les spans de texte en combinant les vecteurs des mots de début et de fin via un autre FFN. Le produit scalaire entre une représentation de span et une représentation de type d’entité donne un score.

Appliquez la sigmoid et vous obtenez la probabilité que le span allant de la position de mot $i$ à la position de mot $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$ est l’embedding du type d’entité affiné par le FFN à partir du token [ENT] correspondant (Zaratiana et al., 2024, équations 1–2). Les spans candidats sont limités à 12 mots ; le tokenizer peut découper un mot en plusieurs subword tokens.

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 v2.1 liste quant à elle 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 de 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 : le modèle ne dispose d’aucun exemple annoté pour la tâche cible. Une description de type telle que « un effet indésirable confirmé médicalement et provoqué par un traitement » fournit davantage d’informations au modèle que adverse event seul. Cela ne garantit pas le transfert, mais le ZeroNER piloté par les descriptions a surpassé les baselines fondées uniquement sur le nom dans leurs 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. Le F1 combine précision et recall en un seul score ; un score plus élevé n’est préférable que pour la même tâche et avec les mêmes règles d’évaluation. La moyenne sur sept datasets combine cinq datasets CrossNER avec MIT Movie et MIT Restaurant :

Avec 90M paramètres, GLiNER-M égale presque UniNER-13B dans la moyenne de l’article sur sept datasets (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 publié de 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 de modèles et le harness d’évaluation 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.

Le dépôt compagnon conserve v2.1 pour son quickstart. Pour une nouvelle comparaison de cross-encoders, incluez également les checkpoints GLiNER v2.5 maintenus ; les numéros de version ne prouvent pas un gain de F1 sur un domaine. GLiNER v2.5 et Fastino GLiNER2.5 ci-dessous sont des familles de modèles différentes.

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 de GLiNER avec 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. Étendre le composant ner entraîné nécessite des exemples annotés et un entraînement. Pour les identifiants ou un dictionnaire contrôlé, EntityRuler peut ajouter des labels personnalisés via des patterns sans réentraînement ; testez son recall en dehors de ces patterns. Épinglez le package de modèle maintenu en 3.8 au lieu de supposer qu’une version majeure non publiée constitue une mise à niveau de production. La model card du modèle en_core_web_trf 3.8.0 indique 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 : il accepte un nouveau texte de label au moment de l’inférence sans réentraînement. Cela ne garantit pas une extraction utile pour chaque label ; la formulation et l’adéquation au domaine restent déterminantes. C’est un candidat solide lorsque les types d’entités sont inconnus à l’avance, changent fréquemment ou sont propres 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 et 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 en phrases, et GLiNER l’extraction d’entités.

Une baseline Transformer supervisée

Pour des labels stables avec des spans annotés représentatifs, commencez par un token classifier fine-tuné tel que RoBERTa ou DeBERTa comme baseline supervisée. Il échange la flexibilité des labels contre une précision spécifique à la tâche. Comparez-le à spaCy et GLiNER sur le F1 exact des spans, 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ù 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 de NER plus petits — mais ils ne répondent pas de la même manière à la question de la taille minimale possible.

UniNER : la voie maximaliste

UniNER fine-tune 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 à « Que décrit [type] dans le texte ? » et produit des listes JSON. Une astuce d’entraînement importante, le negative sampling fondé sur la fréquence, augmente 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 de 7 points les 34,9 % de ChatGPT. La variante 13B atteint 43,4 %, soit seulement 1,7 point de plus pour près du double de paramètres (Zhou et al., 2024).

Le compromis en production : la configuration de type UniNER obtenant les meilleurs scores dans l’article interroge chaque type d’entité séquentiellement. Sa variante all-in-one 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 à moins de bits peut réduire cette empreinte. Le checkpoint UniNER-7B-all indique CC BY-NC 4.0 ; vérifiez le checkpoint exact au lieu d’étendre ce label à toutes les variantes.

NuNER : la voie 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’encoder de concepts est supprimé ; l’encoder de texte s’insère dans n’importe quel pipeline NER standard en remplacement de RoBERTa (Bogdanov et al., 2024).

Le tableau 3 de NuNER indique environ 6,1 à 16,2 points de plus que RoBERTa en F1 macro moyen de token classification, avec des encoders gelés et des têtes linéaires, sur quatre datasets et plusieurs tailles d’entraînement échantillonnées. L’article compare également le fine-tuning spécifique à la tâche avec UniNER-7B ; sa discussion distincte de plus d’une douzaine d’exemples concerne l’in-context learning de GPT-4, et non un seuil pour égaler UniNER (Bogdanov et al., 2024).

Les deux articles montrent qu’il est possible d’apprendre à partir d’annotations de LLMs. Ils n’établissent pas qu’un modèle plus petit surpassera son teacher sur un nouveau domaine. Conservez un jeu de test relu séparément.

GLiNER2 et GLiNER2.5 : distinguer l’article du checkpoint

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

Cette architecture de 2025 conserve le design 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 et 118 636 exemples synthétiques (Zaratiana et al., 2025).

En zero-shot sur CrossNER, GLiNER 2 obtient un F1 de 0,590, proche du 0,599 de GPT-4o dans le benchmark de l’article réalisé à la mi-2025. Pour la classification, il atteint une moyenne 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 zero-shot nécessite un passage forward par label candidat et passe de 1 714 ms pour 5 labels à 16 897 ms pour 50 ; il ne s’agit pas du runtime d’un classifier DeBERTa supervisé (Zaratiana et al., 2025).

L’exemple ci-dessous charge au contraire GLiNER2.5 : 194M paramètres, une architecture boundary et une fenêtre configurée de 4 096 tokens. AutoExtractor sélectionne BoundaryExtractor ; le loader GLiNER2 historique est inadapté. Le pairing sparse des débuts et fins modifie les spans évalués, mais pas la limite de contexte finie. Utilisez les helpers documentés de chunks avec chevauchement pour les documents longs et vérifiez les offsets remappés. Les scores 2025 ci-dessus ne décrivent pas ce checkpoint.

from gliner2 import AutoExtractor

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

# Compose tasks through the current schema interface
schema = (extractor.create_schema()
    .entities({"person": "Names of people", "company": "Organization names"})
    .classification("sentiment", ["positive", "negative", "neutral"])
    .relations(["works_for", "founded", "located_in"])
    .structure("product_info")
        .field("name", dtype="str")
        .field("price", dtype="str"))
text = "Acme launched a $19 widget in Berlin."
results = extractor.extract(text, schema)

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 aucun benchmark d’extraction hiérarchique et ne couvre pas l’API de relations 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.

Nouveautés 2026 : choisir l’architecture adaptée au bottleneck

L’écosystème GLiNER dispose désormais d’architectures distinctes. Ce sont des candidates pour une comparaison de 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 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.

Le PII streaming change le moment où vous pouvez libérer le texte

GLiNER Streaming PII ajoute une détection incrémentale avec un backbone causal Qwen3-0.6B et un état de session mis en cache. Son API renvoie le snapshot complet de la session courante, avec des offsets dans le texte accumulé. Préservez les limites des chunks, ne modifiez pas les labels avant un recalcul complet et effacez les sessions terminées. GLiNER 0.2.28 ou une version ultérieure est requis.

Pour la redaction streaming, je mettrais en buffer le texte qui n’a pas encore été libéré et je testerais les entités réparties entre plusieurs chunks. Détecter un numéro de téléphone après avoir envoyé sa première moitié ne permet pas de retirer ces octets. Mesurez les caractères divulgués avant libération et le délai ajouté, ainsi que le recall des spans finaux. La model card rapporte séparément le F2 de masking PIIMB et le F1 strict des spans typés ; ils répondent à des questions différentes. Sa faiblesse multilingue exclut également de considérer le checkpoint publié comme un filtre de confidentialité universel.

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

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

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

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

GLiNER original encode conjointement les labels et le texte. L’encodage conjoint devient progressivement plus coûteux à mesure que le texte des labels consomme le contexte et doit être réencodé pour 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 la première comparaison. Il sépare l’encodage du texte et celui des labels en deux transformers distincts (Stepanov et al., 2026).

L’encoder de texte utilise ModernBERT (famille Ettin) et l’encoder 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 fois puis mis en cache. Lors de l’inférence, les labels mis en cache évitent de réencoder les labels. L’évaluation des spans candidats par rapport à ces labels nécessite néanmoins du calcul et de la mémoire ; une application à un million de labels nécessite également une recherche de candidats bornée ou du batching, avec mesure du recall des labels exclus avant le scoring.

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

À 1 024 types d’entités, le bi-encoder gliner-bi-edge-v2.0 précalculé ne perd que 5,2 % de débit par rapport à un seul label (19,3 → 18,3 ex/s). L’uni-encoder gliner_small-v2.5 comparable perd 98,7 % (10,7 → 0,14 ex/s). Dans les tests de l’article sur un seul H100, avec batch size 1 et des entrées de 64, 256 et 512 tokens, le bi-encoder précalculé atteint un avantage de débit jusqu’à 130× sur 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).

L’article sur le bi-encoder rapporte 61,5 % pour gliner-bi-large-v2.0 contre 60,9 % pour gliner_large-v2.5 sur la même moyenne CrossNER-plus-MIT. L’article GLiNER original rapporte également 60,9 %, mais pour un checkpoint et une évaluation différents. Considérez la comparaison de l’article sur le bi-encoder comme un résultat publié, puis testez les deux architectures sur le jeu de données du domaine. Les auteurs recommandent bi-base-v2.0 (194M) comme sweet spot : il atteint 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 a reused label set; rebuild this cache when labels or the checkpoint change.
entity_types = ["person", "organization", "date"]  # Small example; large inventories need bounded candidate selection
entity_embeddings = model.encode_labels(entity_types, batch_size=8)

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

Le balayage temporel s’arrête à 1 024 labels, avec un H100, un batch size de un et dix passages forward par configuration. Il ne mesure pas un service déployé avec un million de labels. Les inventaires biomédicaux ou d’entreprise plus volumineux sont des applications à évaluer ; l’entity linking est disponible via le framework compagnon GLiNKER.

Les LLMs comme teachers : 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 coûteuse. 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 87,0 % de F1. L’équipe a utilisé Llama 3.1-70B pour annoter le dataset en environ 8 heures pour environ $70, puis a relu 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 données.

L’étude Refuel AI

Le rapport technique de Refuel AI benchmarke le labeling par LLM sur 8 datasets NLP, dont CoNLL-2003. Il rapporte un accord de 88,4 % avec la vérité terrain pour GPT-4 (mars 2023) et 86,2 % pour les annotateurs humains dans sa configuration, ainsi qu’un labeling 20 fois plus rapide et 7 fois moins cher. Une expérience distincte d’ensemble sur des données propriétaires a dépassé 95 % d’accord, le meilleur LLM individuel atteignant 89 %. Le routage fondé sur la confiance vers des modèles moins chers ou plus puissants est un usage proposé, et non le mécanisme mesuré derrière le résultat sur huit datasets (rapport technique de Refuel AI). Considérez ces chiffres comme des résultats rapportés par un fournisseur 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 découpage par label et la largeur souhaitée des intervalles de confiance. Un pilote de 50 à 200 documents peut 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 proposer des labels d’entraînement en masse. Conserver le modèle demandé et le modèle réellement utilisé, le prompt, le texte source et l’état du fallback. Rejeter les types inconnus et les spans qui ne peuvent pas être alignés sur le texte source ; le dépôt compagnon effectue actuellement un fallback silencieux, qui doit être corrigé avant de traiter sa sortie comme un gold d’entraînement.
4. Relire un sous-ensemble via Argilla ou Label Studio
5. Fine-tuner un encoder compact (GLiNER, SpanMarker, RoBERTa)
6. Ne déployer qu’après que l’encoder a passé un contrôle de qualité held-out et de coût total. CFM a rapporté un coût d’infrastructure horaire inférieur de 16 à 80 fois 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’annotation manuelle, 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 testé GLiNER face à 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 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 rapidement.

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

1. Entités implicites : extraire « événement » de « Elton John performed at Madison Square Garden » — le texte ne mentionne littéralement pas « événement », mais le LLM infère « concert »
2. Sensibilité à la formulation des labels : « 2022 » obtient un score de 0,388 avec « date », mais de 0,958 avec « année » — de petites modifications de label entraînent de fortes variations de score
3. Mapping des valeurs : GLiNER renvoie le texte de surface 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, ce qui rend possibles les prédictions imbriquées, même si la qualité dépend du checkpoint, des labels et des données du domaine. Benchmarkez les deux modes de décodage sur un jeu de test au niveau des spans et contenant des entités imbriquées avant de choisir un modèle spécialisé.

Utilisez GLiNER pour l’extraction d’entités explicites et routez les cas nécessitant inférence, raisonnement ou mapping vers des ontologies prédéfinies vers un LLM. 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 un F1 de 95 % sur un jeu de test soigneusement constitué et pourtant échouer sur le mélange 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 rares et les types d’entités que le F1 agrégé peut masquer.

Les métriques essentielles

Identifiez chaque occurrence par un ID de document, des offsets start/end semi-ouverts et un type, puis vérifiez que text[start:end] récupère bien la mention. Deux occurrences de « John » constituent deux cibles. Validez les nombres de documents avant le matching : les prédictions manquantes doivent créer des faux négatifs et non disparaître via zip(). Comptez les types ou offsets incorrects comme une prédiction non appariée et un span gold non apparié. Rapportez la précision, le recall et le F1 micro, le support et le recall par type, et définissez l’agrégation macro ainsi que les cas vides.

• 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 peut faire paraître meilleure une limite partielle qu’un score de span exact ; rapportez donc le F1 exact des spans lorsque la correction des limites est importante et n’utilisez les métriques au niveau des tokens que lorsque la décision downstream se situe au niveau du token.
• Précision et recall : leurs coûts sont souvent asymétriques. Pour la désidentification, le recall est plus important : manquer un nom est pire que de masquer excessivement. Pour l’extraction vers une base de données, la précision compte davantage : les entrées erronées corrompent l’analyse downstream.

Pièges courants de l’évaluation

1. Gonflement par matching partiel : « Bill » extrait alors que le label gold est « Bill Gates » — certains scripts comptent cela comme un matching partiel. Utilisez un matching exact des spans, sauf raison particulière.
2. Confusion de types : « Microsoft » correctement identifié comme span mais étiqueté PERSON au lieu de ORG doit obtenir un score nul. Vérifiez que votre code d’évaluation gère ce cas.
3. Fuite du jeu de test : excluez du jeu de test les enregistrements, documents et annotations dupliqués ou quasi dupliqués. Pour une affirmation hard zero-shot, excluez également les types d’entités cibles de l’entraînement ; la répétition des chaînes de surface n’est pas à elle seule une fuite.
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 checkpoint 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 aux labels de 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. Une seule exécution ne constitue pas un verdict : rapportez, lorsque cela s’applique, la variation entre seeds aléatoires, les balayages de seuils et les échantillons de production répétés. De petites slices rendent le classement des modèles instable.

Conservez la normalisation, l’entity linking, le regroupement d’enregistrements et les endpoints de relations séparés du F1 extractif. Pour la confidentialité, rapportez les instances divulguées et les documents affectés acceptés automatiquement, les redactions erronées et la fraction envoyée en revue. Pour le serving, rapportez le taux de complétion, la latence document p50/p95, les exécutions cold et warm, les tailles de batch et de labels, la mémoire maximale et le coût par document accepté.

Construire un jeu de test de domaine

Pour l’évaluation en production, je recommande :

1. Échantillonner les données de production, et non des exemples sélectionnés. Incluez les documents difficiles que votre modèle rencontrera réellement.
2. Dimensionner le jeu de test selon l’estimation recherchée. Choisissez le nombre d’exemples selon la prévalence des entités, la taille des slices par label et la largeur souhaitée des intervalles de confiance. Rapportez des intervalles de confiance bootstrap ou analytiques.
3. Utiliser 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 diagnostique l’ambiguïté et la qualité des consignes ; il ne constitue pas un plafond de performance du modèle.
4. Stratifier par difficulté — cas faciles (texte propre, types standard) et cas difficiles (entités ambiguës, jargon, texte bruité).
5. Conserver des slices de confidentialité et d’équité. Pour les PII, rapportez le recall par type de PII, langue, locale, format de document 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 limites 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 ancien type. 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

Il s’agit d’exemples sectoriels sélectionnés, avec des chiffres précis dans les conditions rapportées. Les sources mélangent des comparaisons rapportées par des fournisseurs, des études de cas rapportées par des entreprises ou des projets, ainsi que des articles évalués par les pairs ou des preprints. Considérez-les comme des exemples pratiques, pas comme un classement de maturité.

Santé

Les exemples John Snow Labs et Providence ci-dessus montrent pourquoi la désidentification nécessite des rapports au niveau des entités et des documents. Leurs protocoles d’évaluation sont plus utiles pour concevoir une revue que pour établir un classement sans réserve des fournisseurs.

La rétrospective d’OpenMed, publiée le 6 janvier 2026, rapporte 481 modèles ; les 380+ désignent son inventaire au lancement en juillet. Les téléchargements mesurent la distribution, pas les déploiements. Son affirmation de résultats de pointe sur 10 des 12 benchmarks provient d’un preprint des auteurs datant d’août 2025, et non de résultats de production vérifiés indépendamment.

NER financière

L’extraction financière comprend les mentions d’entreprises dans les actualités et les champs de documents réglementaires ; leurs schémas et longueurs de documents diffèrent. L’étude de cas CFM couvre le premier cas. FinBERT-MRC formule l’extraction comme une compréhension machine de la lecture et rapporte 92,78 ± 0,56 de F1 sur ChFinAnn et 96,80 ± 0,38 sur AdminPunish, deux datasets chinois. Ces résultats n’établissent pas la précision sur les documents SEC en anglais. Testez les documents longs et les entités financières imbriquées dans la langue cible.

E-commerce

L’article KDD 2023 de Walmart utilise des données de requêtes multitâches QU-965M ; ses quelque 60 labels NER sont des classes IOB2. La section 6.8 attribue le gain de GMV de 0,51 % à la baseline MTDNN entraînée sur ces données, tandis que l’évaluation en ligne d’EAMT restait un travail futur. L’impact business ne peut pas être attribué à la seule NER. Le TripleLearn de Home Depot rapporte un F1 held-out passant de 69,5 à 93,3, dans une expérience en ligne, ainsi que plus de neuf mois en production. La leçon transférable est la supervision de domaine itérative, et non un classement actuel des architectures.

Cybersécurité

iACE est un exemple historique d’extraction automatisée de threat intelligence. L’article de CyNER combine la reconnaissance neuronale avec d’autres sources d’extraction et rapporte un span micro-F1 de 76,66 pour XLM-RoBERTa-large, évalué avec seqeval. Le preprint CyberNER harmonise quatre datasets en 21 labels alignés sur STIX 2.1 et rapporte un F1 de 0,736 pour RoBERTa. Il s’agit de résultats de recherche, et non d’une preuve d’adoption en production.

Optimiser le déploiement : de Python à l’inférence à plus faible latence

Le dépôt compagnon montre l’export ONNX de GLiNER et le packaging INT8. Il enregistre la taille 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 batching dynamique, une taille de batch tenant compte de la mémoire, une mise à l’échelle multi-replica et un client HTTP. Le batching et les replicas peuvent améliorer le débit tout en conservant le code du modèle ; le batching peut aussi ajouter du temps d’attente et les replicas n’éliminent pas la mise en file. Mesurez la latence de file, la latence warm, le débit et le F1 exact des spans avec votre mélange de requêtes avant de comparer avec 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 taille de batch, le même matériel et le même protocole de warm-up.

Exécutez scripts/02_onnx_export.py depuis le dépôt compagnon pour exporter un modèle et quantifier dynamiquement son artefact ONNX. Il nécessite cet environnement et télécharge un checkpoint ; il s’agit donc d’une commande à exécuter dans le dépôt, et non d’un snippet autonome dans l’article :

uv run python scripts/02_onnx_export.py

Quantification INT8

La quantification dynamique peut réduire les besoins de stockage et de mémoire d’un modèle ONNX. L’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 Rust

gline-rs (Apache 2.0) retire le runtime Python du chemin d’inférence. Son benchmark v0.9.0 en mode token sur un Intel i9 avec trois labels rapporte 6,67 seq/s, contre 1,61 pour Python, sur 100 échantillons NuNER. Une expérience distincte v0.9.1 sur RTX 4080 et 1 000 échantillons rapporte 248,75 seq/s, sans comparaison GPU Python appariée. Ces chiffres correspondent aux propres conditions du projet et n’ont pas été reproduits par le dépôt compagnon. Il prend en charge les modèles span et token, les GPU/NPU via ONNX Runtime, et est fourni comme 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 couvre l’évidence d’optimisation

Extraction structurée : schémas natifs, Instructor et décodeurs locaux

Lorsque vous avez besoin de davantage de flexibilité que les modèles encoder — entités implicites, raisonnement, mapping vers une 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 l’API Gemini 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 possède 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 enveloppe les clients des fournisseurs avec une validation Pydantic et des retries optionnels après échec de validation.

Adapté du pattern Instructor dans scripts/05_structured_extraction.py. Il nécessite les packages listés et un OPENAI_API_KEY ; le script compagnon utilise GLiNER en fallback lorsqu’aucune clé n’est disponible. Cet article utilise désormais GPT-5.6 Terra, dont la model card prend en charge Chat Completions, le function calling, les structured outputs et none reasoning effort. Comparez-le à l’ancienne baseline moins coûteuse avant de remplacer un extracteur à gros volume ; une nouvelle génération ne prouve pas une meilleure précision en NER.

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

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

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

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

Outlines, de dottxt, adopte une autre approche : la génération de tokens sous contraintes via des machines à états finis. Le décodeur masque les tokens qui violeraient la grammaire cible au lieu d’attendre un échec de validation puis de relancer. Un aperçu AWS cite une adhérence au schéma de 98 %, contre 76 % pour la validation post-génération. Il 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 assez de méthodologie pour traiter ces deux chiffres comme un benchmark contrôlé unique.

Le petit exemple local suivant conserve Phi-3 comme exemple historique d’intégration d’un décodeur, et non comme recommandation de modèle pour 2026. Pour une nouvelle comparaison d’extraction self-hosted, incluez les Qwen3.8-27B ou les checkpoints Qwen3.5 plus petits actuels. Utilisez leur loader de modèle, leur chat template et leur backend de serving documentés ; remplacer uniquement la chaîne ci-dessous ne garantit pas la compatibilité avec une architecture multimodale ou son format de raisonnement.

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

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

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

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

LangExtract 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 les deux comme des systèmes d’extraction structurée, et non comme des remplacements automatiques de la NER par spans. Leurs cibles 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 schémas natifs sont le chemin demandant le moins d’intégration 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 privilégie l’ancrage dans la source, tandis que NuExtract cible l’extraction documentaire self-hosted. Tous les chemins LLM incluent encore une génération autoregressive. Benchmarkez chaque chemin par rapport à un encoder avec la même taille de batch, 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 en production selon la forme de la tâche plutôt que selon un classement unique des modèles.

Niveau 1 : modèles encoder pour les spans explicites. Utilisez un GLiNER cross-encoder pour un petit inventaire de types. Lorsqu’un inventaire volumineux est réutilisé, comparez le bi-encoder avec des embeddings de types mis en cache. Fine-tunez 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 multitâche ou de relations. Lorsqu’une requête nécessite la NER, la classification et des champs hiérarchiques, testez le checkpoint GLiNER2.5 de 194M paramètres face à des baselines distinctes par tâche. 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 l’API de relations ultérieure ni pour un autre déploiement.

Niveau 3 : LLMs pour l’extraction riche en raisonnement. Routez les entités implicites, l’inférence contextuelle et le mapping d’ontologies vers une API de schéma native 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 pour revue. Seuls les spans explicites et alignés sur la source peuvent devenir des cibles d’entraînement ordinaires du niveau 1 ; les faits inférés et les valeurs normalisées nécessitent leurs propres cibles et leur propre évaluation.

L’étude de cas CFM fournit une référence de coût pour le niveau 1 : 93,4 % de F1 à $0.10 par heure sur CPU, contre 92,7 % de F1 et $8 par heure pour son teacher Llama-70B. Les prix horaires des instances ne déterminent pas le coût par document sans le débit. Recalculez avec votre matériel, votre modèle teacher, votre jeu de labels, votre utilisation et votre coût de revue.

Compromis et limites

Pour chaque 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é précis (par exemple en confondant les noms de filiales avec ceux des maisons mères), l’encoder fine-tuné héritera de ce biais. Relisez attentivement les types à faible confiance ou incohérents et conservez un échantillon aléatoire stratifié pour détecter les erreurs systématiques confiantes.

Un schéma valide peut contenir de faux faits. Les structured outputs natifs, 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, qu’une limite de span est correcte 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 dépôt compagnon crée un artefact INT8 quantifié dynamiquement, mais n’en mesure pas le F1. Les recommandations actuelles de GLiNER préconisent un quantization-aware training lorsque la précision INT8 doit être conservée. Comparez les checkpoints quantifié et original sur le F1 exact des spans et le recall par label avant le déploiement.

Quand l’architecture à trois niveaux est excessive. Un seul domaine avec des types d’entités stables et suffisamment d’exemples annotés peut ne nécessiter qu’un pipeline RoBERTa fine-tuné ou spaCy. Le pattern à trois niveaux convient à plusieurs domaines, à des types d’entités qui évoluent ou à un mélange mesuré d’extraction explicite et riche en 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 l’uni-encoder le devance légèrement sur CoNLL-2003. Benchmarkez les deux sur le jeu du domaine ; choisissez selon la qualité mesurée des spans exacts, la calibration, le nombre de labels et le débit, plutôt que d’utiliser « haut risque » comme règle de 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 de recall dangereuse pour une locale, 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 réponse aux faux négatifs et réévaluez lorsque la taxonomie, le mélange de langues ou la source des données change.

Points clés à retenir

1. Utilisez un encoder compact pour les spans explicites uniquement après son passage sur un jeu de test du domaine, avec support par type et 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é ; activez flat_ner=False uniquement après avoir mesuré la qualité des spans imbriqués.
3. Utilisez des descriptions de types testées pour les affirmations hard zero-shot et testez séparément la formulation des labels en anglais et dans la langue locale 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 schémas natifs pour les fournisseurs de LLMs pris en charge, mais validez séparément la correction sémantique et l’ancrage dans la source, indépendamment de la validité JSON.
7. Benchmarkez séparément et conjointement le serving natif, ONNX, la quantification et les chemins 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. L’architecture fondatrice de matching 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 conjointe zero-shot 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.
• UniversalNER: Targeted Distillation from Large Language Models for Open Named Entity Recognition - Zhou et al., ICLR 2024. NER universelle fondée sur la distillation depuis ChatGPT.
• NuNER: Entity Recognition Encoder Pre-training via LLM-Annotated Data - Bogdanov et al., EMNLP 2024. Étude d’un encoder 125M préentraîné sur des annotations de LLMs.

Articles industriels

• EAMT: Entity-Aware Multi-Task Learning for Query Understanding - Walmart, KDD 2023. Étude multitâche de requêtes ; le résultat en ligne appartient à sa baseline MTDNN.
• TripleLearn: End-to-End NER for E-Commerce Search - Home Depot, AAAI 2021. F1 de 69,5 à 93,3.
• Acing the IOC Game: Toward Automatic Discovery and Analysis of Open-Source Cyber Threat Intelligence - Liao et al., CCS 2016. Approche historique d’extraction.
• 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 - Formulation MRC évaluée sur des datasets financiers chinois.

Études de cas

• CFM Case Study: Fine-tuning GLiNER for Financial NER - Pipeline de labeling LLM de Capital Fund Management à $70, atteignant 93,4 % de F1.
• Refuel AI: LLM Labeling Technical Report - GPT-4 atteint 88,4 % d’accord d’annotation, dépassant 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 - Étude fournisseur avec remapping et exclusions de labels.
• OpenMed: Year in Review 2025 - Rétrospective de janvier 2026 ; inventaire et téléchargements ne sont pas des déploiements.

Outils et frameworks

• ner-field-guide demo repo - Démos compagnons de cet article : quickstart GLiNER, export ONNX, LLM-as-teacher et extraction structurée.
• gline-rs: Rust reimplementation of GLiNER - Expériences CPU et GPU distinctes du mainteneur ; code Apache 2.0.
• GLiNER serving - Chemin Ray Serve avec batching dynamique et déploiement multi-replica.
• spaCy English pipelines - Métriques versionnées d’un pipeline à labels fermés.
• Microsoft Presidio - Analyse et anonymisation des PII avec recognizers personnalisés.
• Instructor - Extraction structurée par LLM via modèles Pydantic.
• Outlines - Génération de tokens sous contraintes via FSM, avec un benchmark publié 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 %.