2026-04-02 · Mis à jour 2026-07-15

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

Le guide ultime sur NER en 2026 : encodeurs, LLMs, et l’architecture de production à 3 niveaux

Le reconnaissance d’entités nommées (NER) couvre désormais les encodeurs compacts, les modèles à vocabulaire ouvert, ainsi que l’extraction basée sur LLM. Selon les résultats présentés dans CrossNER, un modèle GLiNER doté de 300 millions de paramètres atteint un score F1 sans entraînement supérieur à celui de 13B UniNER. Un bi-encodeur plus récent affiche une productivité 130 fois supérieure à celle de l’encodeur croisé initial, tout en gérant 1 024 types d’entités. Ces résultats soutiennent un schéma pratique pour l’extraction explicite de spans : utiliser un LLM pour étiqueter les données du domaine, examiner un échantillon, affiner un encodeur compact, puis le déployer avec ONNX ou Rust.

Le répertoire associé propose des exemples exécutables pour GLiNER, l’export de ONNX, les étiquettes d’entraînement générées par LLM, ainsi que l’extraction structurée. Pour les charges de travail où prédominent des segments explicites, les encodeurs compacts offrent une solution efficace en termes de latence et de coûts. Les LLMs restent utiles pour la création de données d’entraînement et pour gérer les cas nécessitant une inférence ou une normalisation.

Répertoire associé : ner-guide de champ, grâce à des démos exécutables pour GLiNER, l’export ONNX, le LLM-en-tuteur pipeline, ainsi qu’à l’extraction structurée via Instructor.

TL;DR : Commencez par GLiNER lorsque vous avez besoin d’une extraction de segments à vocabulaire ouvert ainsi que d’un déploiement CPU. Pour les tâches spécifiques à un domaine, essayez la méthode LLM-en-tuteur pipeline : générer des étiquettes, examiner un échantillon, affiner un encodeur, puis l’évaluer sur un ensemble étiqueté manuellement. Acheminez les entités implicites, la mise en correspondance avec des ontologies et les autres cas nécessitant beaucoup de raisonnement vers un LLM via Instructor ou Outlines. Cette architecture à trois niveaux combine ces approches sans imposer de répartition fixe du trafic.

Où les systèmes modernes utilisent NER

NER continue de détecter des segments de texte et d’y attribuer des étiquettes. Ce qui a changé, c’est sa place au sein du système : il fournit désormais des filtres pour RAG, des arguments structurés destinés aux outils d’agent, ainsi que des champs pour le traitement de documents pipelines. Ces applications rendent la latence, le coût et la flexibilité du schéma aussi importants que la précision benchmark.

RAG : amélioration de la récupération grâce à l’extraction d’entités

La recherche de similarité seule peine à gérer les questions contenant des entités exactes. Pour la question « Qu’a dit Anthropic au sujet de la sécurité des modèles au quatrième trimestre 2024 ? », le système doit extraire « Anthropic » et « Q4 2024 » en tant que filtres de métadonnées, plutôt que de s’appuyer uniquement sur embeddings.

Lors de l’indexation, vous extrayez les entités de chaque chunk et vous les stockez sous forme de métadonnées : {"organizations": ["Anthropic"], "dates": ["Q4 2024"], ...}. Cela vous permet de filtrer par entité avant d’exécuter une recherche vectorielle. Le graphe de connaissances RAG (GraphRAG, graphes de propriétés LlamaIndex) va encore plus loin : grâce à la NER ainsi qu’à l’extraction de relations, il crée un graphe capable de répondre à des questions à plusieurs étapes, ce que les embeddings plats ne peuvent pas faire.

Pendant le temps de traitement de la requête, les entités extraites de la question de l’utilisateur guident le routage. Une question mentionnant le nom d’une entreprise est acheminée vers un index financier ; une question mentionnant des noms de médicaments est dirigée vers une base de connaissances clinique. GLiNER s’avère particulièrement adapté à ce cas, car les entités présentes dans les requêtes sont imprévisibles — il n’est pas possible de réentraîner le modèle pour chaque nouveau type d’entité que les utilisateurs pourraient demander.

AI agents : transformation du texte en faits structurés

Les agents reçoivent du texte non structuré — des pages web, des réponses API, des messages d’utilisateurs — et doivent pouvoir agir en fonction de ce contenu. NER transforme ensuite ce texte en faits structurés que l’agent peut utiliser pour raisonner, stocker ou transmettre à des outils.

Deux domaines où cela revêt la plus grande importance.

Le premier aspect concerne l’acheminement des outils. Lorsqu’un utilisateur demande « planifier une réunion avec Sarah Chen d’Accenture jeudi à 14h », l’agent doit extraire PERSON: Sarah Chen, ORGANIZATION: Accenture, et DATETIME: Thursday 2pm avant d’appeler le calendrier API. Un modèle d’encodeur NER effectue cette opération en moins de 10 ms. Un LLM ajoute quant à lui 1 à 2 secondes par appel, et ce délai s’accumule au fil des workflows à plusieurs étapes, au point que même un agent censé être « instantané » ne le soit plus réellement.

Le deuxième aspect concerne le suivi des entités au cours des conversations. Les systèmes de mémoire d’agent doivent être en mesure de reconnaître que « Sarah » dans le tour 3 et « Mme Chen » dans le tour 12 correspondent à la même personne. NER permet d’identifier ces segments ; la liaison des entités les associe ensuite au même identifiant.

Dans les deux cas, la contrainte majeure reste la latence. Une requête de 200 ms NER au sein d’une chaîne d’agents composée de 10 étapes entraîne un retard perçu de 2 secondes. C’est pourquoi les modèles d’encodeur, et non l’extraction basée sur LLM, constituent le choix approprié pour le traitement des entités au sein des boucles d’agents.

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

OCR transforme les images en texte. NER transforme le texte en champs structurés. Ensemble, ils permettent une numérisation de documents à grande échelle.

Un pipeline standard commence par utiliser des OCR, tels que Tesseract, Azure Document Intelligence ou AWS Textract, afin de générer du texte ainsi que des boîtes de délimitation. Ensuite, un NER extrait des champs tels que invoice_number, vendor_name, line_items, total, et due_date. La même logique s’applique aux contrats, aux dossiers médicaux ainsi qu’aux demandes de réglementation.

Les plateformes modernes combinent trois étapes : la compréhension du layout (s’agit-il d’un en-tête ou d’une cellule de tableau ?), l’extraction d’entités (de quel type est ce texte ?) et l’extraction de relations (quelles valeurs doivent être associées ?). GLiNER 2 gère ces trois tâches en une seule passe forward ; une seule appelation du modèle peut restituer {vendor: "Acme Corp", amount: "\$4,200", due_date: "2026-04-15"} d’une facture.

C’est ici que le coût devient déterminant. Il convient de tarifer le pipeline en fonction du volume réel de documents traités chaque mois, y compris les tentatives de traitement et les phases de revue. Un encodeur compact peut fonctionner sur CPU, tandis qu’un LLM basé sur API entraîne des coûts d’inférence et une latence supplémentaires par document. Une méthode pratique consiste à étiqueter un ensemble représentatif de factures avec LLM, à affiner le modèle GLiNER à l’aide de ces données revues, puis à comparer les deux approches en ce qui concerne la note F1 au niveau des champs, la latence et le coût total.

Détection des PII et contraintes de LLM

Les réglementations relatives à la vie privée (RGPD, HIPAA, CCPA) imposent de détecter les données personnelles avant qu’elles n’atteignent les systèmes ultérieurs. Dans le cadre des déploiements LLM, cela signifie analyser les entrées avant qu’elles ne soient transmises au modèle, ainsi que les sorties avant qu’elles n’arrivent à l’utilisateur.

NER gère cela directement. Les modèles de déidentification permettent de trouver PERSON, SSN, PHONE, EMAIL, et ADDRESS les span doivent être soit masqués, soit remplacés par des équivalents synthétiques. Dans sa propre comparaison de fournisseurs, John Snow Labs publie des rapports 96 % de F1 pour la détection de PHI, contre 91 % pour Azure, 83 % pour AWS et 79 % pour GPT-4o. Un rapport de déploiement distinct indique que Providence traite plus de 100 000 notes cliniques par jour.

Pour les garde-fous LLM, NER agit comme une couche de pré-sélection : elle analyse les entrées des utilisateurs à la recherche de données PII avant de les envoyer vers un API externe, afin de les bloquer ou de les anonymiser. Cette approche est plus rapide et plus simple que de demander au LLM de s’autoréguler. GLiNER est particulièrement utile dans ce contexte, car les catégories de données PII varient en fonction de la juridiction. Il est possible d’ajouter de nouveaux types d’entités, tels que « informations génétiques », dans le cadre d’une nouvelle réglementation, sans avoir à réentraîner le système.

GLiNER modifie la théorie économique NER grâce à un modèle doté de 300 millions de paramètres

GLiNER (NAACL 2024, Zaratiana et al.) a rendu les méthodes basées sur des encodeurs NER compétitives par rapport à LLMs, tout en nécessitant une fraction infime des ressources. Plutôt que de considérer NER comme une tâche de marquage de séquences ou de génération de texte, GLiNER le traite comme un problème de correspondance : il évalue chaque segment de texte candidat (c’est‑à‑dire chaque séquence contiguë de mots telle que « Bill Gates » ou « Microsoft ») par rapport à chacune des étiquettes de type d’entité, puis retient uniquement les paires présentant les scores les plus élevés.

Le modèle traite les étiquettes de type d’entité ainsi que le texte d’entrée comme une seule séquence : [ENT] person [ENT] organization [ENT] date [SEP] Bill Gates founded Microsoft.... Un transformateur bidirectionnel (DeBERTa-v3) encode tout ensemble.

D’après les résultats, le modèle génère deux ensembles de représentations : l’un pour les types d’entités (provenant de [ENT] une pour les positions de tokens) et une autre pour les tronçons de texte (obtenue en combinant les vecteurs de token de début et de fin au moyen d’un petit réseau feedforward). Un produit scalaire entre la représentation d’un tronçon et la représentation du type d’entité fournit un score.

En appliquant la fonction sigmoïde, on obtient la probabilité que l’intervalle allant du token $i$ au token $j$ appartienne au type d’entité $t$ : $\phi(i, j, t) = \sigma(S_{ij}^T \cdot q_t)$, où $S_{ij}$ est le vecteur d’intervalle généré par le FFN et $q_t$ est le type d’entité embedding correspondant. [ENT] token (Zaratiana et al., 2024, Eq. 1). La longueur des segments est limitée à 12 tokens afin de garantir des performances rapides.

En pratique, cela signifie que toute description en langue naturelle peut servir de label au moment de l’inférence, sans nécessiter de réentraînement. Vous pouvez fournir les types d’entités que vous souhaitez (“personne”, “réaction indésirable aux médicaments”, “instrument financier”), et le modèle évalue les segments en fonction d’eux. Trois tailles sont disponibles : GLiNER-S (50 M de paramètres), GLiNER-M (90 M) et GLiNER-L (300 M). Les données d’entraînement proviennent du Pile-NER dataset : 44 889 passages contenant 240 K de segments d’entités appartenant à 13 K de types d’entités, tous étiquetés par ChatGPT. L’entraînement de GLiNER-L prend environ 4 heures sur une seule carte A100.Zaratiana et al., 2024).

Résultats Benchmark

Résultats en mode zero-shot provenant de Zaratiana et al. (2024), Tableaux 1 et 2 :

GLiNER-M, doté de 90 M de paramètres, se rapproche presque de UniNER-13B dans le tableau CrossNER du rapport (55,4 % contre 55,6 % en F1), tout en utilisant environ 140 fois moins de paramètres. La version GLiNER-S, avec 50 M de paramètres, dépasse le résultat rapporté pour ChatGPT (GPT-3,5) de 5 points en F1. La variante multilingue, entraînée uniquement sur des données en anglais, surpasse cette même référence ChatGPT dans 8 des 10 langues non anglaises.Zaratiana et al., 2024). Ces comparaisons reposent sur les versions du modèle ainsi que sur les métriques d’évaluation présentées dans la publication harness ; elles ne permettent pas d’établir de classement par rapport aux versions plus récentes LLMs.

L’écosystème est très vaste : plus de 280 modèles compatibles avec GLiNER sur HuggingFace, environ 350 000 téléchargements sur PyPI par mois, ainsi que près de 2 800 étoiles sur GitHub. Les variantes couvrent les textes biomédicaux, la détection des PII, les actualités, et prennent en charge plusieurs langues.

Depuis quickstart.py:

from gliner import GLiNER

model = GLiNER.from_pretrained("urchade/gliner_medium-v2.1")
text = "Bill Gates founded Microsoft on April 4, 1975."
labels = ["person", "organization", "date"]
entities = model.predict_entities(text, labels, threshold=0.5)

for entity in entities:
    print(f"  {entity['text']} => {entity['label']} ({entity['score']:.3f})")
# Bill Gates => person (0.987)
# Microsoft => organization (0.991)
# April 4, 1975 => date (0.974)

Comment GLiNER se compare à spaCy

Tout guide concernant NER serait incomplet sans spaCy — Environ 21 millions de téléchargements par mois, et l’une des bibliothèques NLP les plus robustes en environnement de production. Cependant, elle fonctionne selon des contraintes architecturales fondamentalement différentes de celles de GLiNER.

le module pipelines de spaCy (en_core_web_sm, en_core_web_trf) on utilise un vocabulaire fermé NER : un ensemble fixe de types d’entités (PERSON, ORG, GPE, DATE, etc.) définis au moment de l’entraînement. Souhaitez-vous un nouveau type d’entité ? Il faut alors collecter des données étiquetées et réentraîner le modèle. Basé sur des transformateurs en_core_web_trf atteintes 89,8 % de score F1 sur OntoNotes 5.0, mais uniquement pour ses 18 types prédéfinis.

GLiNER prend en charge le vocabulaire ouvert NER : n’importe quelle étiquette peut être utilisée au moment de l’inférence, sans nécessiter de réentraînement. Cela en fait le choix préférable lorsque les types d’entités ne sont pas connus à l’avance, évoluent fréquemment, ou relèvent d’un domaine spécifique (« réaction indésirable aux médicaments », « instrument financier », « indicateur de menace »).

Ma recommandation : utilisez spaCy pour les types d’entités standards, lorsque les modèles pré-entraînés pipelines sont suffisamment validés. Préférez plutôt GLiNER lorsque vous avez besoin de types flexibles et sans entraînement préalable, ou lorsque vos pipeline doivent s’adapter sans retraitement. Ces deux outils peuvent partager un pipeline, spaCy s’occupant de la tokenisation et de la segmentation des phrases, tandis que GLiNER gère l’extraction des entités.

UniNER et NuNER : jusqu’où peut-on aller en termes de taille ?

UniNER (ICLR 2024, Zhou et al.) et NuNER (EMNLP 2024, Bogdanov et al.) transforment toutes deux les annotations LLM en modèles NER de taille réduite — cependant, ils diffèrent quant à la limite minimale de taille atteignable.

UniNER : l’approche maximaliste

UniNER affine LLaMA-7B/13B à l’aide de 44 889 paires NER (240 K d’entités, 13 K de types) 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 clé de l’entraînement : l’échantillonnage négatif basé sur la fréquence permet d’améliorer la valeur F1 de 31,5 % à 53,4 %.Zhou et al., 2024).

UniNER-7B atteint un F1 zéro-shot de 41,7 % sur 43 datasets — dépassant ainsi les 34,9 % de ChatGPT de 7 points. La version 13B atteint quant à elle 43,4 %, soit seulement 1,7 point de plus, malgré une consommation de ressources presque deux fois supérieure.Zhou et al., 2024).

Le problème de production : en tant que modèle autoregressif de 7 milliards de paramètres, UniNER nécessite N passes en avant pour chaque type d’entité, consomme 14 Go+ VRAM (ce qui signifie que votre budget GPU est déjà épuisé avant même le déjeuner), et est soumis à une licence restrictive CC BY-NC 4.0.

NuNER : la solution la plus sobre

NuNER part de RoBERTa-base (125 M de paramètres) et emploie un entraînement contrastif avec 4,38 millions d’annotations GPT-3.5 couvrant 200 K de concepts — le coût total des annotations restant inférieur à $500. Une fois l’entraînement terminé, l’encodeur de concepts est éliminé ; l’encodeur de texte peut alors être intégré dans n’importe quel NER pipeline standard en remplacement de RoBERTa.Bogdanov et al., 2024).

Résultats : NuNER surpasse la version simple de RoBERTa de 6 à 15 points F1 pour toutes les tailles d’enseignement few-shot. Avec seulement une douzaine d’exemples par type d’entité, NuNER atteint des performances équivalentes à celles de UniNER-7B, bien qu’il soit 56 fois plus petit.Bogdanov et al., 2024).

Ces deux travaux permettent d’extraire des annotations LLM afin de créer des modèles NER plus compacts. NuNER démontre qu’un encodeur doté de 125 millions de paramètres peut atteindre les mêmes résultats que ceux obtenus avec UniNER-7B, à condition de disposer de données fine-tuning spécifiques à la tâche, tout en bénéficiant d’une licence MIT et d’un processus d’inférence compatible avec CPU.

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

L’écosystème initial de GLiNER faisait face à un problème croissant : l’existence de modèles distincts pour NER (GLiNER), l’extraction de relations (GLiREL), la classification (GLiClass) ainsi que l’analyse de relations au niveau du document (GLiDRE) — chacun nécessitant sa propre mise en production, son conteneur Docker, son système de surveillance et des mécanismes de gestion des pannes. GLiNER 2 (EMNLP 2025, Zaratiana et al.) fusionne ces quatre composants en un seul modèle comptant 205 millions de paramètres, doté d’une interface pilotée par un schéma.

L’architecture conserve la conception de cross-encoder tout en élargissant le contexte à 2 048 tokens (4 fois la valeur initiale) et intègre des schémas déclaratifs permettant de définir les tâches d’extraction. L’entraînement s’appuie sur 135 698 documents réels annotés avec GPT-4o ainsi que sur 118 636 exemples synthétiques.Zaratiana et al., 2025).

Dans le cadre du CrossNER sans entraînement préalable, les scores de GLiNER 2 s’élèvent à 0,590 F1, ce qui est proche des 0,599 obtenus par GPT-4o selon les résultats publiés pour la mi-2025 benchmark. En ce qui concerne la classification, sa valeur moyenne est de 0,72 sur 7 benchmarks, contre 0,69 pour DeBERTa-v3-large. Concernant CPU, l’étude indique une latence de classification allant de 130 à 208 ms en fonction du nombre d’étiquettes testées. La référence DeBERTa voit sa latence passer de 1 714 ms pour 5 étiquettes à 16 897 ms pour 50 étiquettes.Zaratiana et al., 2025).

from gliner2 import GLiNER2
extractor = GLiNER2.from_pretrained("fastino/gliner2-base-v1")

# Multi-task composition in ONE forward pass
schema = (extractor.create_schema()
    .entities({"person": "Names of people", "company": "Organization names"})
    .classification("sentiment", ["positive", "negative", "neutral"])
    .relations(["works_for", "founded", "located_in"])
    .structure("product_info")
        .field("name", dtype="str")
        .field("price", dtype="str"))
results = extractor.extract(text, schema)

Pour les applications nécessitant les quatre tâches, le modèle partagé peut remplacer quatre déploiements distincts tout en conservant la précision rapportée dans l’étude.

Le bi-encodeur : mise à l’échelle vers des millions d’étiquettes NER

Le GLiNER original encode à la fois les étiquettes et le texte, ce qui crée un goulot d’étranglement. Plus il y a de types d’entités, plus la séquence d’entrée s’allonge, et les performances chutent rapidement au-delà d’environ 30 types. Le GLiNER bi-encoder (février 2026, Stepanov et al. ; arXiv 2602.18487) résout ce problème en séparant l’encodage du texte de celui des étiquettes au sein de deux transformateurs distincts.

L’encodeur de texte fait appel à ModernBERT (famille Ettin), tandis que l’encodeur d’étiquettes utilise des sentence transformers (BGE ou MiniLM). Les spans et les étiquettes sont évalués au moyen du produit scalaire. La astuce réside dans le fait que le type d’entité embeddings peut être calculé une seule fois à l’avance et mémorisé. Lors de l’inférence, seul le texte doit être encodé — la recherche des étiquettes s’effectue alors en temps réel.

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

Avec 1 024 types d’entités, l’encodeur binaire (à bord de l’edge, précalculé) ne perd que 5,2 % de sa capacité de traitement par rapport à un seul étiquetage. L’encodeur croisé, quant à lui, voit sa capacité chuter de 98,7 % (de 10,7 à 0,14 ex/s). Cela représente donc un avantage de 130 fois en termes de performance à grande échelle. Sur une seule carte H100 disposant de 100 types d’entités, l’encodeur binaire génère 1,96 million de prédictions par jour, contre 368 K pour l’encodeur croisé.Stepanov et al., 2026).

L’exactitude reste également satisfaisante. Le Bi-encoder-large atteint un score de 61,5 % sur l’indicateur CrossNER F1, légèrement supérieur aux 60,9 % du cross-encoder. Les auteurs recommandent le bi-base-v2.0 (194M) comme solution optimale, car il parvient à obtenir 98 % de l’exactitude du modèle de grande taille tout en affichant une vitesse 2,6 fois supérieure.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 comprennent l’analyse biomédicale NER à l’aide de l’ontologie UMLS (plus de 4 M de concepts), des taxonomies d’entreprise qui évoluent sans nécessiter un réentraînement du modèle, ainsi que le lien d’entités grâce au logiciel associé. GLiNKER framework.

LLMs en tant qu’enseignants : une étude de cas coûtant 70 $ ainsi qu’un pipeline déployable

Le schéma LLM-en-tuteur permet de séparer l’annotation coûteuse de l’inférence moins chère. Deux études de cas publiées illustrent comment des équipes l’ont mis en œuvre dans des conditions variées.

L’étude de cas CFM

Dans une étude de cas Hugging Face, Capital Fund Management a extrait les noms d’entreprises à partir d’environ 900 000 titres de nouvelles financières. Le modèle GLiNER en mode zero-shot a atteint un score F1 de 87,0 %. L’équipe a utilisé Llama 3.1-70B pour annoter les dataset en environ 8 heures, ce qui a coûté environ 70 $, puis a examiné 2 714 échantillons via Argilla pendant une autre période de 8 heures.

Fine-tuning Dans l’étude de cas, le score GLiNER sur ces données a atteint 93,4 % F1, contre 92,7 % pour le modèle enseignant Llama-70B. Les auteurs indiquent un coût de $0,10 par heure sur CPU pour le modèle affiné, ainsi que $8 par heure pour le modèle enseignant.Étude de cas CFM). Ces figures décrivent une tâche liée aux actualités financières ainsi qu’une configuration d’infrastructure.

L’étude sur le rechargement AI

Refuel le rapport technique AI benchmarks LLM relatif à l’étiquetage sur 8 frameworks NLP datasets, dont CoNLL-2003. Il indique une concordance de 88,4 % avec les valeurs de référence pour GPT-4 (mars 2023) ainsi qu’une concordance de 86,2 % pour les annotateurs humains utilisés dans son cadre, tout en permettant un étiquetage 20 fois plus rapide et 7 fois moins coûteux. Son mécanisme d’ensemble dirige les exemples simples vers des modèles moins chers et les exemples complexes vers GPT-4, atteignant ainsi une concordance supérieure à 95 % dans les expériences présentées.Rapport technique sur le réapprovisionnement en carburant de AI). Traitez-les comme des résultats communiqués par le fournisseur conformément au protocole d’annotation de cette étude.

Une implémentation en production pipeline

Un flux de production pratique comprend six étapes :

1. Rédiger des directives d’annotation en langue naturelle.
2. Créer un petit ensemble de validation étiqueté manuellement (50 à 200 documents).
3. Utiliser un LLM (GPT-5.4 Mini, Llama 4 Maverick ou Qwen3.5) pour étiqueter les données d’entraînement en masse.
4. Examiner un sous-ensemble par argile ou Label Studio
5. Affiner un encodeur compact (GLiNER, SpanMarker, RoBERTa)
6. Déployer avec un coût d’inférence 16 à 80 fois inférieur

Le LLM permet de réduire le volume d’annotation manuelle, mais l’équipe conserve néanmoins la maîtrise du jeu de validation, des directives d’annotation, des revues ciblées ainsi que de l’analyse des erreurs.

Où GLiNER échoue et où LLMs reste utile

Le Sease benchmark (Octobre 2025) Nous avons testé GLiNER contre GPT-4.1-mini sur 30 tâches de parsing de requêtes. GPT-4.1-mini a obtenu 100 % de résultats parfaitement corrects. GLiNER, quant à lui, n’a réussi que 53 % des tâches (16 sur 30). Cependant, GLiNER a répondu en 0,08 seconde, contre 1,21 seconde pour le LLM — soit 15 fois plus rapide.

Dans cette tâche composée de 30 exercices benchmark, GLiNER a échoué pour trois motifs récurrents :

1. Entités implicites : extraction de « événement » à partir de « Elton John performed at Madison Square Garden » — aucun texte ne mentionne littéralement le mot « événement », mais l’LLM en déduit « concert ».
2. Sensibilité de la formulation des étiquettes : la valeur « 2022 » obtient un score de 0,388 pour l’étiquette « date », mais de 0,958 pour « année » — de légères modifications des étiquettes entraînent donc d’importantes variations de scores.
3. Mappage des valeurs : GLiNER restitue le texte brut exact (« family houses ») au lieu de la valeur canonique (« Single family house »). Un LLM peut effectuer cette normalisation lorsque son prompt ainsi que le schéma définissent les valeurs cibles.

Entités imbriquées et superposées

GLiNER rencontre également des difficultés avec les entités imbriquées. Dans l’expression « New York University », un humain pourrait qualifier à la fois « New York » (LOCALISATION) et « New York University » (ORGANISATION). GLiNER ne sélectionne que le segment présentant la note la plus élevée. Ce phénomène est crucial dans les textes biomédicaux (« acute myeloid leukemia » comprend à la fois une maladie et un modificateur) ainsi que dans les textes juridiques (hiérarchies organisationnelles imbriquées). Les modèles spécialisés parviennent à gérer ce type d’imbriquement, mais la conception basée sur des segments plats de GLiNER ne le permet pas.

Utilisez GLiNER pour l’extraction explicite d’entités, et dirigez les cas nécessitant de la inférence, du raisonnement ou un mappage vers des ontologies prédéfinies vers LLM. Le seuil de routage doit être déterminé à partir d’un ensemble de données étiquetées dans le domaine concerné.

Évaluation de NER : métriques, pièges et ensembles de test

Un modèle peut atteindre un score F1 de 95 % sur un ensemble de test soigneusement sélectionné, mais échouer malgré tout avec le mélange de documents qu’il rencontre en environnement de production. Il convient donc de construire l’ensemble d’évaluation à partir de la distribution réelle en production, en conservant des sous-ensembles dédiés aux formats et types d’entités rares, dont la présence pourrait fausser les résultats globaux du F1.

Les métriques clés

• F1 au niveau de l’entité : C’est la métrique standard. Une prédiction est considérée comme correcte uniquement si les limites du segment ainsi que son type correspondent parfaitement à la vérité factuelle. C’est celle que rapportent la plupart des articles scientifiques.
• F1 au niveau du token : Elle évalue chaque token de manière indépendante. Elle tend à gonfler les résultats, car obtenir une grande partie d’une entité longue correctement permet d’obtenir un crédit partiel. Préférer le F1 au niveau de l’entité.
• Précision vs Rappel : Ces deux critères présentent souvent des coûts asymétriques. Pour la dé-identification, le rappel est plus important — omettre un nom est pire que de supprimer trop de données. Pour l’extraction de bases de données, la précision est plus cruciale — des entrées fausses détériorent l’analyse ultérieure.

Pièges courants d’évaluation

1. Inflation due à une correspondance partielle : extraction de « Bill » lorsque l’étiquette de référence est « Bill Gates » — certains scripts considèrent cela comme une correspondance partielle. Préférez une correspondance sur intervalle exact sauf s’il y a une raison valable de ne pas le faire.
2. Confusion de type : « Microsoft » étant correctement identifié comme un intervalle, il devrait être classé dans la catégorie ORG et non PERSON ; dans ce cas, la note doit être nulle. Vérifiez que votre code d’évaluation gère correctement ce cas.
3. Fuite vers l’ensemble de test : si les entités de l’ensemble de test chevauchent celles de l’entraînement, les notes sont surestimées. Les méthodes zero-shot benchmarks (CrossNER, Few-NERD) permettent d’évaluer la généralisation.

Création d’un ensemble de tests de domaine

Pour l’évaluation en environnement de production, je recommande :

1. Échantillonnez à partir de données en production, et non à partir d’exemples sélectionnés manuellement. Incluez les documents complexes que votre modèle verra réellement.
2. 200 à 500 documents annotés permettent d’obtenir des estimations F1 stables. En dessous de 100, les intervalles de confiance sont trop larges.
3. Au moins deux annotateurs, avec un accord entre eux (kappa de Cohen > 0,8). Si les humains ne s’accordent pas, votre modèle ne pourra pas faire mieux.
4. Stratifiez par niveau de difficulté : cas simples (texte propre, types standards) et cas difficiles (entités ambiguës, jargon, texte bruité).

Production NER dans quatre secteurs industriels

Voici les déploiements NER les plus matures que j’aie trouvés, accompagnés de chiffres précis.

Santé

Le secteur de la santé dispose de l’écosystème d’outils le plus avancé pour NER. John Snow Labs propose plus de 2 500 modèles préentraînés, dont plus de 1 200 dédiés à la santé, couvrant plus de 400 types d’entités cliniques mappées sur ICD-10, SNOMED CT, LOINC et RxNorm. Dans les initiatives de l’entreprise… Comparaison des fournisseurs, ses modèles de dé-identification ont atteint un score F1 de 96 %, contre 91 % pour Azure, 83 % pour AWS, et 79 % pour GPT-4o. Une étude de cas distincte rapporte Providence St. Joseph Health traite quotidiennement de 100 000 à 500 000 d’notes cliniques..

Lors de son examen des projets pour 2025, le logiciel open source Projet OpenMed Il recense plus de 380 modèles biomédicaux NER, 29,7 millions de téléchargements Hugging Face, ainsi que des résultats de premier plan sur 10 des 12 bases de données biomédicales publiques benchmarks.

Financier NER

Le cas d’usage principal : l’extraction des données de déclaration auprès de la SEC. Le module NLP financier développé par John Snow Labs permet d’identifier plus de 11 types d’entités dans les documents 10-K/10-Q (adresses, codes boursiers, exercices financiers, places boursières). FinBERT-MRC Les variantes atteignent une valeur F1 comprise entre 0,87 et 0,93 pour les tâches relatives aux entités financières. Le défi majeur réside dans les documents volumineux ainsi que dans les entités imbriquées présentes dans des instruments financiers complexes.

E-commerce

de Walmart Système EAMT (KDD 2023) s’entraîne sur 965 millions de requêtes comportant une soixantaine d’étiquettes d’entités ; l’article indique une augmentation du GMV de 0,51 % lors des tests A/B. Chez Home Depot, TripleLearn framework (AAAI 2021) a entraîné de manière itérative NER F1 en le faisant passer de 69,5 à 93,3.

Cybersécurité

Le système iACE (CCS 2016) a traité 71 000 articles provenant de 45 blogs de sécurité, en extrayant 900 K d’éléments IOC avec une précision de 98 % et un taux de rappel de 93 %. Les systèmes modernes tels que CyNER On combine DeBERTa (F1 >91%) avec des heuristiques IOC basées sur des expressions régulières. CyberNER Le dataset unifié (2025) fusionne quatre datasets en 21 types d’entités conformes à STIX 2.1, grâce à RoBERTa qui atteint un score F1 de 0,736.

Optimisation du déploiement : du Python à des inférences à plus faible latence

J’ai testé trois méthodes pour accélérer GLiNER en environnement de production dans le répertoire associé.

ONNX exportation

GLiNER dispose d’une conversion native ONNX, et des modèles pré-convertis existent sur HuggingFace (onnx-community/gliner_small-v2.1). ONNX Runtime permet d’obtenir une accélération de 1,5 à 3 fois sur CPU par rapport à PyTorch, en offrant quatre niveaux d’optimisation allant du basique au calcul en précision mixte.

Depuis onnx_export.py:

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

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

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

INT8 quantification

La quantification dynamique permet de réduire la taille des modèles de 2,4 fois (de 438 MB à 181 MB), tout en maintenant une perte F1 inférieure à 0,6 %. La vitesse de traitement s’améliore également de 1,8 fois grâce à CPU. Avec l’architecture Intel VNNI CPUs et l’utilisation de ONNX Runtime, INT8 offre jusqu’à 6 fois plus de rapidité par rapport à PyTorch FP32.

from onnxruntime.quantization import quantize_dynamic, QuantType

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

gline-rs : réimplémentation en Rust

gline-rs (Apache 2.0) élimine la surcharge liée à Python. Sur CPU : 6,67 séq./s contre 1,61 pour Python — soit une amélioration de performance de 4,1 fois. Sur une RTX 4080 : 248,75 séq./s.gline-rs benchmarks). Il prend en charge les modèles de type span et token, GPU/NPU via ONNX Runtime, et est disponible 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 fast-gliner Ce paquet fournit des bindings Python via PyO3 : la vitesse de Rust associée à l’ergonomie de Python.

Résumé de la pile d’optimisation

Extraction structurée : instructeur versus plans d’étude

Lorsque vous avez besoin d’une plus grande flexibilité que ne l’offrent les modèles d’encodeur — entités implicites, raisonnement, mappage ontologique — deux bibliothèques permettent d’effectuer une extraction structurée à partir de LLMs.

Formateur (~12 600 étoiles sur GitHub, ~8,8 M de téléchargements par mois en mars 2026) créé par Jason Liu, ce projet corrige LLM SDKs afin de prendre en charge les modèles de réponse Pydantic, avec une tentative automatique de réessai en cas d’échec de la validation. Il prend en charge plus de 15 fournisseurs et a inspiré la fonction native structured output d’OpenAI.

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

Aperçus by dottxt adopte une approche différente : une génération de tokens contrainte au moyen de machines à états finis. Le décodeur masque les tokens qui violeraient la grammaire cible, plutôt que d’attendre une erreur de validation pour tenter à nouveau. Dans un AWS benchmark, Ce chemin a atteint une conformité au schéma de 98 %, contre 76 % pour la validation post-génération, et a généré les résultats 5 fois plus rapidement que le flux de travail non contraint testé avec des tentatives de répétition. Ce résultat dépend du modèle, du jeu de schémas ainsi que de la configuration serving.

import outlines

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

Le choix dépend de l’endroit où vous exécutez vos modèles. Instructor offre aux environnements cloud LLM APIs une méthode de validation via Pydantic ainsi qu’un mécanisme de tentative répétée bien connu. Outlines, quant à lui, impose des contraintes de schéma à la génération locale. Ces deux approches prennent en charge l’extraction au style NER, tout en conservant comme latence la génération autoregressive du modèle. Benchmark fonctionne dans les deux cas avec un encodeur, sur le même volume de lots, la même architecture matérielle et le même schéma d’entités.

L’architecture de production à trois niveaux

J’orienterais le traitement en production NER en fonction de la forme des tâches plutôt qu’en se basant sur le classement d’un seul modèle.

Niveau 1 : modèles d’encodeur pour des segments explicites. On utilise un cross-encodeur GLiNER pour de petits ensembles d’étiquettes, et on teste l’encodeur binaire à mesure que le nombre d’étiquettes augmente. On procède au fine-tuning via LLM-en-tuteur pipeline, puis on déploie la solution avec ONNX, INT8, ou gline-rs lorsque ces approches réussissent les tests dans le domaine benchmark.

Niveau 2 : GLiNER 2 pour l’extraction multi-tâche. Lorsqu’une requête nécessite à la fois NER, une classification, une extraction de relations ainsi que des données structurées, on teste le modèle partagé de GLiNER 2 doté de 205 millions de paramètres. La publication indique une latence de classification CPU comprise entre 130 et 208 ms pour les différents jeux de labels testés.

Niveau 3 : LLMs pour l’extraction à forte composante de raisonnement. Dirigez le traitement des entités implicites, l’inférence contextuelle ainsi que la mise en correspondance avec les ontologies vers un LLM via Instructor pour les environnements cloud APIs, ou vers Outlines pour les modèles locaux. Enregistrez ces cas, car ils constituent des candidats potentiels pour le prochain ensemble de données d’entraînement du Niveau 1.

L’étude de cas CFM fournit une référence de coût pour le niveau 1 : un F1 de 93,4 % à un coût annoncé de 0,10 $par heure sur CPU**, contre un **F1 de 92,7$ par heure pour son modèle enseignant Llama-70B. Recalculez cette comparaison en fonction de votre matériel, de votre modèle enseignant, de votre ensemble d’étiquettes, et évaluez les coûts correspondants.

Compromis et limites

Les systèmes ML présentent toujours des compromis. La question cruciale est de déterminer où se manifestent ces compromis et de savoir s’il est possible de les mesurer avant le déploiement.

LLM-as-teacher : les erreurs se propagent. Lorsque le LLM identifie de manière répétée un type d’entité de façon incorrecte (par exemple, en confondant les noms de filiales avec ceux des sociétés mères), l’encodeur affiné hérite de ce biais. La solution consiste en une revue humaine ciblée : il convient de concentrer les efforts sur les types d’entités pour lesquels la confiance du LLM est faible ou incohérente, et non pas à travers un échantillonnage aléatoire.

Les pertes de quantification ne sont pas uniformes. La perte moyenne F1 d’environ 0,6 % due à INT8 peut être plus élevée pour des types d’entités rares présentant des motifs de frontière subtils (composés chimiques, abréviations multilingues). Il est impératif de benchmark les modèles pour vos types d’entités spécifiques, et non de se baser uniquement sur une valeur F1 agrégée.

Lorsque l’architecture à trois niveaux est un excès. Un seul domaine disposant de types d’entités stables et d’un nombre suffisant d’exemples étiquetés peut nécessiter uniquement un modèle RoBERTa ou spaCy pipeline finement ajusté. Le schéma à trois niveaux convient plutôt aux domaines multiples, aux types d’entités en évolution, ou encore à une combinaison équilibrée d’extraction explicite et basée sur le raisonnement. Une facture simple pipeline qui ne vise qu’à extraire des noms et des dates peut se limiter au premier niveau.

Plafond de qualité du bi-encodeur. Le bi-encodeur sacrifie l’attention conjointe au profit d’un débit plus élevé. Lorsque la sémantique des étiquettes interagit avec le contexte textuel (« date », « année » ou « période » pour la même portion de texte), le cross-encodeur reste supérieur. Privilégiez le cross-encodeur pour les tâches à haute importance et à faible nombre d’étiquettes ; utilisez plutôt le bi-encodeur pour maximiser la couverture du contenu.

Références

Articles de recherche

• GLiNER : Modèle généraliste pour la reconnaissance d’entités nommées utilisant des transformateurs bidirectionnels - Zaratiana et al., NAACL 2024. L’architecture fondatrice de correspondance entre segments et entités. GLiNER 2 : Problèmes ouverts en extraction automatique d’informations - Zaratiana et al., EMNLP 2025 System Demonstrations. Il unifie NER, la classification, le RE ainsi que l’extraction structurée.
• GLiNER Bi-Encoder : reconnaissance d’entités nommées échelleable grâce à une architecture bi-encodeur - Stepanov et al., février 2026. Encodage découplé pour des échelles de millions d’étiquettes. UniNER : NER universel basé sur des grands modèles de langage - Zhou et al., ICLR 2024. Un NER universel basé sur LLM, obtenu par distillation à partir de ChatGPT. NuNER : Entraînement préalable de l’encodeur de reconnaissance d’entités à l’aide de données annotées avec LLM - Bogdanov et al., EMNLP 2024. Il montre que 125 M de paramètres suffisent avec des données d’entraînement générées à l’aide de LLM.

Articles de la littérature spécialisée

• EAMT : Apprentissage multi-tâche conscient des entités pour la compréhension des requêtes - Walmart, KDD 2023. 965 M de requêtes, une augmentation du GMV de 0,51 %. TripleLearn : méthode NER bout en bout pour la recherche en e-commerce - Home Depot, AAAI 2021. La valeur F1 est passée de 69,5 à 93,3.
• iACE : Collecte automatique d’informations sur les menaces cybernétiques - CCS 2016. 71 000 articles, 900 000 IOCs. CyberNER : Un corpus STIX harmonisé pour la cybersécurité NER - 21 types d’entités conformes à STIX 2.1. FinBERT-MRC : compréhension par lecture de machine pour les données financières NER - Un score F1 compris entre 0,87 et 0,93 pour les tâches relatives aux entités financières.

Études de cas

• Étude de cas CFM : Fine-tuning GLiNER pour les NER financiers - Le système de classification pipeline mis en œuvre par Capital Fund Management avec les labels LLM atteint un score F1 de 93,4 %. Recharger AI : Rapport technique de classification LLM - GPT-4 atteint un taux d’accord d’annotation de 88,4 %, dépassant ainsi les annotateurs humains.
• Sease : GLiNER comme alternative à LLMs pour le parsing des requêtes - Lorsque GLiNER échoue et que des LLMs restent nécessaires. John Snow Labs : déidentification de textes médicaux Benchmark - Comparaison de la détection du PHI F1 à 96 % entre les différents fournisseurs. OpenMed : Bilan annuel 2025 - Plus de 380 modèles biomédicaux NER, 29,7 millions de téléchargements sur HuggingFace.

Outils et frameworks

• ner – répertoire de démonstration du guide de champ - Démos complémentaires pour cet article : le guide de démarrage rapide de GLiNER, l’export ONNX, le mode LLM-en-tuteur-, ainsi que l’extraction structurée. gline-rs : réimplémentation en Rust de GLiNER - Accélération de 4,1 fois CPU par rapport à Python, sous licence Apache 2.0.
• Instructeur - Extraction structurée de LLM au moyen de modèles Pydantic, ~8,8 millions de téléchargements par mois. Aperçus - Génération de tokens contrainte au moyen de FSM, assurant le respect du schéma. AWS : Structured Output via les outils d’élaboration de schémas - Conformité au schéma de 98 % benchmark.