GLiNER2 français biomédical multi-task open-vocab (NER zero-shot + classification + extraction structurée + relations), backbone MedEmbed-v9 (ModernBERT 149M contrastif biomed FR). Lignée GLiNER / NuNER / GLiNER-biomed. Entraîné sur données synthétiques (distillation Qwen3-235B depuis PMC-patients-fr, HAL, istex, wikipédia, textbooks) — aucun gold de benchmark (préserve la généralisation zero-shot aux types nouveaux).

v3f : base densité-stratifiée (annotation 100k chunks, densité par hash → bimodal). Généraliste comparable à v3b/v3e ; sur l'extraction lymphome finetunée n'apporte pas de gain net.

1. max_width (défaut 8) plafonne le recall. GLiNER2 ne score que les spans ≤ max_width tokens. Sur des entités/valeurs longues (ex. registres cliniques, ~58% des spans > 8 tokens) c'est un plafond dur. Le monter recouvre les spans longs (mesuré : det-recall 0.50 → 0.76). Il faut le poser sur TOUS les sous-modules (le SpanMarkerV0 est imbriqué dans span_rep.span_rep_layer ; ne mettre que model.max_width provoque un mismatch de shape → 0 prédiction) :

2. Ne pas passer trop de types par appel. Le modèle a été entraîné avec un nombre borné de types par exemple (~≤20). Lui donner des dizaines de types d'un coup est hors-distribution et dégrade précision ET recall. Batcher les types par groupes de ≤ 20 (ex. par section d'un formulaire) et fusionner les sorties.

Autres conseils : travailler document par document (ne PAS concaténer plusieurs docs → troncature + effondrement du recall) ; threshold≈0.3 ; tronquer le texte vers ~20000 caractères max. Pour l'extraction de valeurs de formulaire, le NER plat (extract_entities) est plus fiable que le mode structuré json_structures (tête structurée encore sous-entraînée).

MIT. Modèle de recherche. Pas un dispositif médical.