GLiNER : le NER zero-shot qui rivalise avec les LLM

La reconnaissance d'entités nommées (NER) est l'un de ces sujets qu'on croit résolus depuis dix ans. spaCy, BERT fine-tuné, quelques regex bien placées : on extrait des noms, des dates, des organisations, on passe à la suite. Sauf que les usages modernes — anonymisation, extraction structurée, RAG sémantique — cassent vite ce setup. Il faut détecter des entités qu'on n'a jamais annotées, dans plusieurs langues, sur du texte hétérogène, sans payer un appel LLM par ligne.

GLiNER, introduit par Zaratiana et al. en 2024, propose une réponse architecturale élégante à ce problème. Et l'écosystème qui s'est construit autour en moins de deux ans en fait l'un des modèles NER les plus pertinents à connaître aujourd'hui.

Les limites du NER classique et des LLM

Le NER traditionnel a deux limites structurelles :

1. Schéma fermé. Un modèle entraîné sur CoNLL-2003 connaît PER, ORG, LOC, MISC. Point. Pour ajouter IBAN, numéro de sécurité sociale ou identifiant patient, il faut annoter, ré-entraîner, redéployer.
2. Pas de transfert de domaine. Un modèle entraîné sur des articles de presse s'effondre sur des emails clients, des transcripts d'appels ou des notes médicales.

L'alternative naturelle, c'est de demander à un LLM d'extraire les entités via prompt. Ça marche, mais le coût est mauvais : génération séquentielle token par token (donc latence élevée), facturation à l'usage qui explose en volume, et données envoyées hors infra. Sur des benchmarks NER zero-shot, ChatGPT n'est même pas le plus fort — c'est le point de départ du papier GLiNER.

L'idée : reformuler le NER en matching de spans

GLiNER (Generalist and Lightweight Named Entity Recognition) reformule le problème NER comme un matching entre des embeddings de labels et des embeddings de spans textuels, dans un espace latent commun.

L'architecture prend en entrée :

• une liste de types d'entités sous forme de texte ("person", "email", "medical record number"...) ;
• le texte à analyser.

Un encodeur bidirectionnel (BERT, DeBERTa selon la variante) produit en parallèle les représentations des labels et des spans. Chaque label est séparé par un token spécial [ENT] appris pendant l'entraînement. Un réseau feedforward calcule ensuite le score de compatibilité label/span. Les entités sont extraites en une seule passe, pas en génération token par token.

Ce design a deux conséquences directes :

• Vitesse : l'extraction est parallèle, comme tout modèle encoder-only.
• Flexibilité : ajouter un type d'entité ne demande aucun réentraînement, juste un nouveau label en entrée.

Les perfs : meilleur que ChatGPT en zero-shot

Le papier original démontre que GLiNER surpasse ChatGPT et plusieurs LLM fine-tunés (InstructUIE, UniversalNER) sur les benchmarks NER zero-shot, tout en pesant l'équivalent d'un BERT-base. La plus petite version dépasse même InstructUIE-11B en out-of-domain.

Côté multilingue, les variantes officielles couvrent l'anglais, le français, l'allemand, l'espagnol, l'italien et le portugais, avec des perfs zero-shot solides — y compris sur des langues sous-représentées dans l'entraînement initial.

Comparaison synthétique

L'écosystème GLiNER en 2026

GLiNER n'est plus un modèle isolé. Une famille s'est constituée autour du même paradigme encoder-based + matching :

• GLiREL — extension à l'extraction de relations entre entités.
• GLiClass — classification de texte zero-shot.
• GLiNER-BioMed — variante biomédicale, avec versions cross-encoder et bi-encoder.
• GLiDRE — extraction de relations au niveau document, en français.
• GLiNER-PII — fine-tuné sur la détection de PII/PHI/PCI, avec 60+ catégories de données personnelles.
• GLiNER2 — bibliothèque unifiée qui regroupe NER, classification et extraction de relations sous une même interface schema-driven.

L'écosystème est également venu avec un déploiement Ray Serve prêt à l'emploi (pip install gliner[serve]) qui apporte le batching dynamique, le sizing batch memory-aware et le scaling multi-replicas — utile pour passer en prod sans recoder une couche de serving.

Intégration Python

L'API est délibérément minimale :

from gliner import GLiNER

model = GLiNER.from_pretrained("urchade/gliner_multi-v2.1")

# Les labels sont définis au runtime, pas à l'entraînement
labels = ["person", "organization", "location", "date", "email"]

text = """
Le 12 mars 2025, Jean Dupont, CTO de Acme Corp à Lyon,
a envoyé un email à recrutement@example.fr.
"""

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

for entity in entities:
    print(f"{entity['label']}: {entity['text']} (score={entity['score']:.2f})")

Pour changer le schéma d'entités, on modifie la liste labels. C'est tout. Aucun fine-tuning, aucun redéploiement.

Variantes PII pour les pipelines d'anonymisation

Les modèles gliner-pii-* publiés par Knowledgator et Wordcab sont fine-tunés spécifiquement pour la détection de données personnelles, avec une couverture qui inclut :

• identifiants personnels (nom, prénom, date de naissance) ;
• coordonnées (email, téléphone, adresse postale détaillée) ;
• identifiants gouvernementaux (numéro de SS, passeport, permis) ;
• données financières (IBAN, numéro de carte, montants) ;
• données médicales (numéro de dossier, diagnostic, médicament).

Les benchmarks indépendants donnent un F1 d'environ 81% sur des datasets PII multi-domaines pour GLiNER-base, là où une approche spaCy/regex plafonne nettement plus bas. Le rappel sur les identifiants numériques (dates, numéros) est particulièrement bon, grâce à un entraînement sur données synthétiques.

C'est notamment ce qu'on a retenu chez KODY pour le moteur d'extraction d'entités de ProxyIA : tourner en local, en CPU, sans appel API externe.

Quantization et inférence edge

Pour les contraintes de latence et de footprint, les checkpoints sont disponibles en ONNX quantifié (FP16 et UINT8). Les variantes gliner-pii-edge et gliner-pii-small ciblent explicitement le scénario CPU, avec une latence sous les 100ms sur des textes de quelques milliers de tokens et un footprint mémoire compatible avec un conteneur de taille raisonnable.

Des implémentations existent aussi en Rust, C++ et JS pour les environnements où Python n'est pas une option.

Les limites à connaître

GLiNER n'est pas magique. Quelques points à surveiller en production :

• La formulation des labels compte. Un label trop générique ("name") attrape parfois trop, un label trop spécifique ("french social security number") sous-extrait. Il faut itérer.
• Le threshold de confiance est un hyperparamètre. Trop bas, on a des faux positifs ; trop haut, on rate des entités. À calibrer par type de label et par domaine.
• Les entités très longues ou imbriquées sont difficiles. Une adresse postale sur plusieurs lignes peut être segmentée. Un post-processing métier reste nécessaire.
• Le multilingue a ses trous. Le français et l'anglais sont solides ; certaines langues sous-représentées dans le pré-entraînement le sont moins.
• GLiNER ne fait que du NER (et ses extensions). Pour de la summarization, du reasoning, de la génération, il faut un LLM. Pas un remplacement universel.

Ce qu'il faut retenir

GLiNER incarne une tendance forte de 2025-2026 : on n'a pas toujours besoin d'un LLM de 100 milliards de paramètres pour faire de l'extraction d'information. Un encodeur bidirectionnel de quelques centaines de millions de paramètres, bien entraîné sur des données synthétiques pertinentes, dépasse les LLM généralistes sur les tâches NER — pour une fraction du coût, en CPU, avec la souveraineté des données en bonus.

Pour tout pipeline qui doit extraire des entités sur du texte (RAG, anonymisation, structuration de documents, parsing de contrats, monitoring de logs), GLiNER mérite une évaluation sérieuse avant de partir sur du fine-tuning lourd ou des appels LLM facturés à chaque ligne.