gliner-x-large-bodacc-fr

gliner-x-large-bodacc-fr

English · Français

Named entity recognition on French legal announcements from the BODACC (Bulletin officiel des annonces civiles et commerciales). Fine-tune of knowledgator/gliner-x-large.

Micro F1: 0.612 → 0.901 on a held-out gold set of 500 real announcements.

Six entity types: company identifiers (siret_siren, rcs_number, registration_number), parties (organization, person), and address.

from gliner import GLiNER

model = GLiNER.from_pretrained("ragraph-ai/gliner-x-large-bodacc-fr")

LABELS = ["address", "organization", "person",
          "rcs_number", "registration_number", "siret_siren"]

text = ("Société DUPONT ET FILS, SARL au capital de 10 000 euros, "
        "12 rue de la Paix 75002 Paris, RCS Paris 552 100 554.")

entities = model.predict_entities(text, LABELS, threshold=0.5, flat_ner=False)
for e in entities:
    print(f"{e['text']:<30} {e['label']:<22} {e['score']:.3f}")

⚠️ Two non-negotiable parameters. Decoding must be nested (flat_ner=False) to recover SIREN numbers embedded inside RCS mentions. And words_splitter must be whitespace — the upstream config references stanza, which crashes on load. The patch is already applied in this repo.

Versions are git tags, not separate repos:

model = GLiNER.from_pretrained("ragraph-ai/gliner-x-large-bodacc-fr",
                               revision="v1.0")

---

English

Why this model

Vanilla GLiNER already knows what a SIREN number is — its precision on siret_siren is 0.964. But recall caps out at 0.463: it does not emit the SIREN nested inside RCS mentions (RCS Paris 552 100 554), whereas the gold set annotates them twice. Same story for rcs_number (F1 0.599) and organization, where it massively over-generates (precision 0.366).

This fine-tune teaches BODACC annotation conventions rather than new entities. Hence the gains concentrate on structured identifiers, and are more modest on address, which the base model already located well.

Performance

Benchmark: 500 real BODACC announcements, manually annotated, disjoint from training. 3,615 spans.

Protocol: exact span match (token indices, inclusive end), nested decoding (flat_ner=False), threshold 0.5, over the six labels present in the gold set. No partial matching, no case or punctuation normalization.

Micro precision / recall: 0.523 / 0.737 (vanilla) → 0.939 / 0.865 (fine-tuned).

Micro F1 per epoch: 0.891 → 0.898 → 0.901. Selected checkpoint: epoch 3.

Full breakdown of the fine-tuned model:

Known limitations

registration_number is not trustworthy. Support of 44 spans: a handful of errors moves the score by several points. F1 swings 0.622 → 0.552 → 0.632 across epochs — that is noise, not learning. Do not benchmark against this number. A larger gold set for this label is needed before drawing any conclusion.

max_width=12 caps recall on address. The model cannot emit spans longer than 12 tokens. About 3.7% of gold spans (~134) exceed that bound, almost all of them long addresses. The model misses 125 of them — the two figures line up: the 0.846 address recall is a structural ceiling, not a training failure. Its precision is 0.991. Raising max_width in the config and retraining should close nearly the entire gap.

The real recall deficit is on organization. 299 of the ~487 total missed spans. Recall 0.700 at precision 0.878: the model turned conservative where vanilla over-generated (precision 0.366, recall 0.886). The fine-tune traded recall for precision on this label. That is the v2 work — not addresses.

person precision is weak (0.705). Sole traders whose organization is a person's name remain a source of person / organization confusion, despite the variants added to training.

Out of domain. Trained exclusively on French legal-announcement prose. No guarantees on contracts, invoices, general legal text, or non-administrative French. GLiNER's zero-shot ability on arbitrary labels is likely degraded relative to the base model.

Training data

Three sources, mixed:

1. Synthetic templates of legal announcements, including hard negatives (the court's city not labelled as address), UPPERCASE variants for person / organization, and addresses in varied formats including the short BODACC forms (75002 Paris).
2. In-domain silver: ~2,000 real BODACC announcements annotated automatically by DeepSeek. Disjoint from the 500 gold announcements.
3. Nested annotation convention: a SIREN inside an RCS mention is annotated twice (siret_siren nested within rcs_number), matching the gold set.

⚠️ The silver annotations are LLM-generated and not manually verified. Their systematic errors are learned by the model. The gold set is hand-annotated.

The BODACC is an official publication under the Licence Ouverte / Open Licence (Etalab).

Reproducibility

Epoch-by-epoch fine-tuning, with a full gold evaluation after each epoch and selection of the best micro F1. Training loss is uninformative on largely templated data — the gold set arbitrates.

Adafactor and gradient checkpointing are memory constraints, not optimization choices: roughly 3.5 GB of fp32 parameters, plus gradients, plus AdamW's two moment buffers, exceed the L4's 23 GB. On a 40 GB+ GPU, AdamW with batch_size=8 is preferable — and will shift the optimization dynamics slightly, hence the scores.

Each epoch restarts with a fresh scheduler. Simple, but it is not a single warmup across all three epochs — worth noting if you compare against another recipe.

Raw per-epoch scores: results_ft.json.

Usage considerations

This model extracts personal data — names of natural persons, addresses. The BODACC is a public source, but automated aggregation and cross-referencing of this data falls under GDPR. Verify your legal basis before any production processing.

The model produces company identifiers (SIREN, RCS) that can be wrong while looking plausible. Do not treat them as validated: a SIREN carries a Luhn check digit — verify it downstream.

Roadmap

• v2: raised max_width (unblocks address recall), and targeted work on organization recall — likely more in-domain silver rather than more templates.
• Extended gold set for registration_number.
• A person / organization disambiguation benchmark for sole traders.

Feedback and failure cases welcome in the Community tab.

---

<a id="francais"></a>

Français

Pourquoi ce modèle

GLiNER vanilla connaît la notion de « numéro SIREN » — sa précision sur siret_siren est de 0.964. Mais son rappel plafonne à 0.463 : il n'émet pas les SIREN imbriqués dans les mentions RCS (RCS Paris 552 100 554), alors que le gold les annote doublement. Idem pour rcs_number (F1 0.599) et organization (précision 0.366 — il sur-génère massivement).

Ce fine-tune apprend les conventions d'annotation du BODACC plutôt que de nouvelles entités. D'où des gains concentrés sur les identifiants structurés, et un gain plus modeste sur address, que le modèle savait déjà repérer.

Performance

Étalon : 500 annonces BODACC réelles, annotées manuellement, disjointes du train. 3 615 spans.

Protocole : correspondance exacte de span (indices de tokens, fin inclusive), décodage imbriqué (flat_ner=False), seuil 0.5, sur les six labels présents dans le gold. Pas de correspondance partielle, pas de normalisation de casse ou de ponctuation.

Précision / rappel micro : 0.523 / 0.737 (vanilla) → 0.939 / 0.865 (fine-tuné).

Micro F1 par epoch : 0.891 → 0.898 → 0.901. Checkpoint retenu : epoch 3.

Détail du modèle fine-tuné :

Limites connues

registration_number n'est pas fiable. Support de 44 spans : une poignée d'erreurs déplace le score de plusieurs points. Le F1 oscille de 0.622 → 0.552 → 0.632 d'une epoch à l'autre — c'est du bruit, pas de l'apprentissage. Ne pas benchmarker contre ce chiffre. Un gold plus large sur ce label est nécessaire avant toute conclusion.

max_width=12 plafonne le rappel sur address. Le modèle ne peut pas émettre de span de plus de 12 tokens. Environ 3,7 % des spans du gold (~134) dépassent cette borne, presque tous des adresses longues. Le modèle en rate 125 — les deux chiffres coïncident : le rappel address de 0.846 est un plafond structurel, pas un échec d'apprentissage. Sa précision est de 0.991. Corriger max_width dans la config et réentraîner devrait résoudre la quasi-totalité de l'écart.

Le vrai déficit de rappel est sur organization. 299 des ~487 spans manqués au total. Rappel 0.700 pour une précision de 0.878 : le modèle est devenu conservateur là où le vanilla sur-générait (précision 0.366, rappel 0.886). Le fine-tune a échangé du rappel contre de la précision sur ce label. C'est le chantier de la v2, pas les adresses.

person a une précision faible (0.705). Les auto-entrepreneurs dont l'organisation est un nom de personne restent une source de confusion person / organization, malgré les variantes ajoutées au train.

Hors domaine. Entraîné exclusivement sur de la prose d'annonce légale française. Aucune garantie sur des contrats, des factures, du texte juridique général, ou du français non administratif. Les capacités zero-shot de GLiNER sur des labels arbitraires sont vraisemblablement dégradées par rapport au modèle de base.

Données d'entraînement

Trois sources, mélangées :

1. Templates synthétiques d'annonces légales, incluant des négatifs durs (ville du tribunal non labellisée comme address), des variantes en MAJUSCULES pour person / organization, et des adresses aux formats variés dont les formes courtes BODACC (75002 Paris).
2. Silver in-domain : ~2 000 annonces BODACC réelles annotées automatiquement par DeepSeek. Disjointes des 500 du gold.
3. Convention d'annotation imbriquée : le SIREN à l'intérieur d'une mention RCS est annoté deux fois (siret_siren imbriqué dans rcs_number), conformément au gold.

⚠️ Les annotations silver sont générées par un LLM et non vérifiées manuellement. Leurs erreurs systématiques sont apprises par le modèle. Le gold, lui, est annoté à la main.

Le BODACC est une publication officielle sous Licence Ouverte / Open Licence Etalab.

Reproductibilité

Fine-tuning epoch par epoch, avec évaluation gold complète après chaque epoch et sélection du meilleur micro F1. La loss d'entraînement est peu informative sur des données largement templatées — c'est le gold qui arbitre.

Adafactor et le gradient checkpointing ne sont pas des choix d'optimisation mais des contraintes mémoire : environ 3,5 Go de paramètres fp32, auxquels s'ajoutent les gradients et les deux moments d'AdamW, dépassent les 23 Go de la L4. Sur un GPU de 40 Go et plus, AdamW et batch_size=8 sont préférables — et changent légèrement la dynamique d'optimisation, donc les scores.

Chaque epoch repart avec un scheduler frais. Simple, mais ce n'est pas un warmup unique sur les trois epochs : à noter si vous comparez à une autre recette.

Scores bruts par epoch : results_ft.json.

Considérations d'usage

Ce modèle extrait des données à caractère personnel — noms de personnes physiques, adresses. Le BODACC est une source publique, mais l'agrégation et le rapprochement automatisés de ces données relèvent du RGPD. Vérifiez votre base légale avant tout traitement en production.

Le modèle produit des identifiants d'entreprise (SIREN, RCS) qui peuvent être faux tout en étant plausibles. Ne les traitez pas comme validés : un SIREN dispose d'une clé de contrôle Luhn, vérifiez-la en aval.

Feuille de route

• v2 : max_width relevé (débloque le rappel address), et travail ciblé sur le rappel organization — vraisemblablement plus de silver in-domain plutôt que plus de templates.
• Gold étendu sur registration_number.
• Étalon de désambiguïsation person / organization pour les auto-entrepreneurs.

Les retours et les cas d'échec sont bienvenus dans l'onglet Community.

---

Citation

@misc{gliner-x-large-bodacc-fr,
  title  = {gliner-x-large-bodacc-fr: entity extraction on French legal announcements},
  author = {RAGraph AI},
  year   = {2026},
  url    = {https://huggingface.co/ragraph-ai/gliner-x-large-bodacc-fr}
}

Base model: knowledgator/gliner-x-large — GLiNER, Zaratiana et al., 2023 (arXiv:2311.08526).