Toute la recherche
Évaluation sur jeu complet

PII-INDEXBENCH : 12 079 documents conçus pour être difficiles

Chaque enregistrement passé dans l'API de production, noté face aux annotations du benchmark aux côtés de cinq autres systèmes, dont Qwen3-14B interrogé comme détecteur. Le chiffre de précision est décortiqué face à ces mêmes annotations plus bas dans la page.

Réalisée par Hexagone AI, septembre 2026. Jeu de données PII-INDEXBENCH v1.2, CC BY 4.0.

12 079 documents synthétiques en anglais répartis sur 150 domaines, conçus pour être adverses : journaux de support denses en identifiants, notes cliniques, transcriptions machine, et la même personne désignée de trois façons différentes dans un même document. Il n'est pas distribué sur HuggingFace, ce qui en fait un test plus propre pour tout système susceptible d'avoir mémorisé son propre jeu d'évaluation pendant l'entraînement.

Chaque enregistrement est passé par l'API de production en mode masquage, et la sortie a été notée face aux annotations du benchmark. Les cinq mêmes comparateurs ont tourné sur les mêmes documents avec le même scoreur : quatre détecteurs et un modèle à poids ouverts interrogé par prompt. La métrique principale est le rappel : sur les 226 428 valeurs personnelles annotées, quelle part la sortie a-t-elle réellement retirée ?

97,9 %
Rappel
Part des valeurs personnelles annotées que la sortie a réellement retirées, et la plus élevée des six systèmes comparés ici.
93,5 %
Précision
Part de ce que nous avons retiré que le benchmark compte aussi comme donnée personnelle ; la section ci-dessous démonte le chiffre poste par poste.
226 428
Valeurs annotées testées
Sur 12 079 documents et 150 domaines, soit tous les enregistrements distribués par le benchmark plutôt qu'un sous-ensemble.

Tous les types de données annotés par le benchmark

Précision, rappel et F1 sur PII-INDEXBENCH, tous types annotés, six systèmes
SystèmeRappelpart des données personnelles trouvéesPrécisionF1F1 · bornes exactes
Hexagone AIapi.hexagone.ai, masking mode97,9 %93,5 %95,7 %74,1 %
Qwen3-14B

Comment la ligne Qwen3-14B a été produite

Un modèle généraliste à poids ouverts n'est pas un détecteur de données personnelles, si bien qu'une bonne part de ce que mesure cette ligne tient à la façon dont nous l'avons interrogé. Le prompt et les règles d'analyse sont donc figés et publiés, car une ligne de benchmark dont personne hors de l'équipe ne peut lire le prompt ne vaut pas grand-chose.

Zero-shot, une requête par document
Aucun réglage fin, aucun exemple dans le prompt, aucune relance pour obtenir une meilleure réponse. Le modèle voit un document et répond une fois.
Il renvoie des valeurs, pas des positions
Le modèle renvoie les valeurs personnelles trouvées sous forme de sous-chaînes exactes, et le harnais les localise dans le document avec le même localisateur qui a construit les segments de référence. Lui demander des positions de caractères reviendrait surtout à mesurer sa capacité à compter les caractères, ce qui n'est pas la question posée.
La même politique d'étiquetage que les autres
Le prompt porte les 22 mêmes catégories que celles utilisées pour convertir les jeux de données, et la même liste d'exclusions (âge, genre, intitulé de poste, nationalité), afin que le modèle soit noté sur ce qu'il détecte et non sur sa capacité à deviner nos conventions.
Les échecs comptent contre lui
Une valeur renvoyée qui n'est pas une sous-chaîne du document est écartée, puisqu'elle ne correspond à aucune région de texte. Une réponse impossible à analyser, après une tentative de réparation, compte pour zéro segment sur ce document plutôt que d'être discrètement retirée de l'exécution.
Le format de sortie demandé
{"entities": [{"text": "<verbatim substring>", "type": "<TYPE>"}]}

Un seul fichier de prompt, un seul sha256 : 83cf3e79, conservé avec chaque réponse, de sorte que les chiffres de cette ligne peuvent être re-dérivés des réponses stockées plutôt qu'admis sur parole.

Une réserve joue ici en faveur de Qwen : sa précision provient de son propre scoreur, qui compte comme faux positif une prédiction tombant sur les champs cliniques de remplissage du benchmark, alors que la règle du rapport traite ces champs comme des régions ignorées. Selon cette règle, la précision de Qwen3-14B serait plus proche de 96 %. Son rappel porte sur les mêmes 226 428 valeurs annotées que toutes les autres lignes, si bien que cette colonne est directement comparable.

Qwen/Qwen3-14B, zero-shot, one request per document
91,7 %94,6 %93,1 %88,3 %
OpenMed PIIOpenMed/OpenMed-PII-SuperClinical-Large-434M-v184,7 %92,7 %88,5 %71,0 %
OpenAI Privacy Filteropenai/privacy-filter, 1.5B, run locally77,5 %94,0 %85,0 %41,9 %
Microsoft Presidiopresidio-analyzer + spaCy en_core_web_lg65,4 %91,7 %76,4 %42,5 %
GLiNERurchade/gliner_multi-v2.151,0 %90,0 %65,1 %62,4 %

C'est la vue la plus large et la moins indulgente : un système sans catégorie « passeport » se voit compter chaque numéro de passeport comme un manque. C'est aussi la vue qui correspond à la question produit, car un document ne cesse pas de contenir des numéros de passeport sous prétexte que votre modèle n'a pas d'étiquette pour eux. La dernière colonne note les mêmes prédictions sur des bornes exactes au caractère près plutôt que sur un simple recouvrement, ce qui est sévère pour tout outil qui masque un nom en deux morceaux.

Couverture de détection par type de donnée personnelle sur PII-INDEXBENCH
Type de donnée personnelleSegmentsHexagone AIOpenMedOPFQwen3-14BPresidioGLiNER
NomsPERSON46 58999,9 %99,8 %98,4 %90,8 %84,5 %81,9 %
OrganisationsCOMPANY12 42995,8 %69,3 %pas d'étiquette86,9 %pas d'étiquette82,7 %
Adresses postalesADDRESS20 35195,5 %76,1 %79,8 %92,2 %pas d'étiquette73,9 %
LieuxLOCATION20 15291,1 %93,1 %61,1 %91,4 %63,9 %50,7 %
Numéros de téléphonePHONE_NUMBER15 67399,9 %96,9 %99,1 %94,7 %78,1 %34,8 %
Adresses e-mailEMAIL_ADDRESS17 145100,0 %99,7 %99,9 %94,5 %46,9 %10,6 %
Numéros de sécurité socialeSSN3 222100,0 %99,5 %95,4 %96,7 %99,2 %40,5 %
Dates et heuresDATE_TIME20 16395,4 %98,2 %70,3 %78,7 %82,5 %70,3 %
Numéros de carteCREDIT_CARD4 33896,1 %94,3 %80,0 %94,7 %52,3 %26,7 %
Numéros de compteACCOUNT_NUMBER4 74299,8 %82,1 %58,2 %95,7 %98,8 %32,6 %
Numéros d'identité nationaleNATIONAL_ID5 23599,5 %pas d'étiquette71,1 %97,1 %pas d'étiquettepas d'étiquette
Numéros de passeportPASSPORT_NUMBER3 44198,9 %pas d'étiquette83,9 %96,4 %99,9 %47,5 %
Permis de conduireDRIVER_LICENSE3 08897,9 %pas d'étiquette81,7 %96,1 %100,0 %38,4 %
Identifiants fiscauxTAX_ID60995,9 %99,7 %99,7 %94,9 %36,3 %pas d'étiquette
Adresses IPIP_ADDRESS4 79699,9 %98,2 %91,4 %95,4 %100,0 %pas d'étiquette
URLURL3 625100,0 %77,8 %11,0 %96,2 %89,3 %pas d'étiquette
Numéros de dossier, de commande et d'enregistrementUNIQUE_IDENTIFIER28 68299,9 %53,9 %74,3 %95,2 %pas d'étiquette29,8 %
Identifiants de véhiculeVEHICLE_ID79593,1 %88,3 %97,2 %95,1 %pas d'étiquettepas d'étiquette
Mots de passe, clés et jetonsPASSWORD6 77699,6 %99,6 %97,6 %98,3 %pas d'étiquettepas d'étiquette
MontantsMONEY4 55598,2 %pas d'étiquettepas d'étiquette88,0 %pas d'étiquettepas d'étiquette

Le meilleur de chaque ligne est en gras. « Pas d'étiquette » signifie que le système n'a aucune catégorie pour ce type de donnée : il n'est donc ni noté ni pénalisé sur cette ligne, ce qui est la lecture la plus généreuse d'un vocabulaire incomplet. La teinte de chaque cellule suit la valeur qu'elle contient.

Là où nous n'arrivons pas premiers. Limitez la notation aux sept catégories pour lesquelles chaque détecteur de ce tableau possède une étiquette, et OpenMed passe devant, en rappel (97,9 % contre 97,7 %) comme en F1 (93,6 % contre 92,7 %). C'est un modèle supervisé aux frontières serrées sur les types courants, et ces sept catégories sont justement les types courants. Notre avance dans le tableau élargi vient plutôt de l'étendue : OpenMed n'a aucune étiquette pour les identités nationales, les passeports, les permis de conduire, les organisations, les numéros de dossier ou les montants, et une fois ceux-ci comptés son rappel tombe à 84,7 %. Qwen3-14B reste hors de cette vue restreinte, puisqu'un modèle interrogé par prompt n'a pas de jeu d'étiquettes figé que l'on puisse restreindre.

Crédit du jeu de données. PII-INDEXBENCH v1.2, publié sous licence CC BY 4.0. Nous ne l'avons pas construit et nous ne le contrôlons pas. Il n'est pas publié sur HuggingFace, ce qui en fait un test raisonnable pour tout système susceptible d'avoir lu son propre jeu d'évaluation pendant l'entraînement. Exécution du 06/09/2026, API de production Hexagone, mode masquage, avec le trafic du benchmark tenu hors de notre base de données.

Lire le chiffre de précision

Nous retirons plus que ce que le benchmark demande

La précision compte un retrait comme une erreur dès qu'il tombe en dehors d'un segment annoté, ce qui ne tient comme définition que si l'annotation est complète. Sur un document où la même personne est nommée quatre fois et annotée une seule, elle ne l'est pas, et les trois mentions non annotées nous sont comptées comme des fautes.

Nous avons donc repris chaque segment qui nous a coûté de la précision sur cette exécution et l'avons classé selon des règles vérifiables face au benchmark lui-même, plutôt que selon que le résultat nous arrangeait. Les postes ci-dessous sont ce qui en est ressorti.

Les 29 597 segments qui nous coûtent de la précision

Chaque prédiction sur IndexBench qui ne touche aucun segment annoté, classée selon une règle explicite.

  • 37,4 % Une valeur annotée ailleurs par le benchmark, ou un morceau de celle-ci (11 079)
  • 39,7 % Exclu des annotations par construction, ou structure du document (11 760)
  • 22,8 % Sur-masquage réel (6 758)
  1. 37,4 %11 079 segments

    Une mention ultérieure d'une personne annotée une seule fois

    Règle. Ce que nous avons retiré est un mot d'une valeur annotée ailleurs dans le même document, une lettre isolée, ou un segment contenant un tel mot sans lui être égal. Neuf sur dix se trouvent à l'intérieur d'un nom annoté par le benchmark, ou juste à côté.

    Une réclamation est signée Freya C. et la réponse s'ouvre sur Dear Freya C. Le benchmark annote Freya Camara une fois, là où elle se présente, et aucune des deux mentions qui suivent. La même forme couvre une initiale seule, comme « Xinyi H. » là où Xinyi Hassan est annoté dans l'en-tête du message, et une frontière qui tombe sur une partie d'un nom, comme « Sarah D » là où la valeur annotée est Sarah Diallo. Nous les retirons toutes, car ne masquer que la mention annotée laisserait le nom en clair dans le document.

    Ce qu'Hexagone AI a retiré

    My name is Freya Camara and I am writing regarding the recent ⋯ Best regards, Freya C. --- Reply from Trust & Safety Team: Dear Freya C.,

    Ce que le benchmark annote

    My name is Freya Camara and I am writing regarding the recent ⋯ Best regards, Freya C. --- Reply from Trust & Safety Team: Dear Freya C.,

    Le même extrait des deux côtés, tiré de l'enregistrement doc-000001 de PII-INDEXBENCH, à l'identique. Le ⋯ marque une coupe entre deux passages de ce même document.

  2. 34,0 %10 075 segments

    Structure du document masquée par prudence

    Règle. Étiquettes de locuteur (Agent, User, Caller, Patient), noms de champs (DOB, MRN, IP Address, State) et horodatages de transcription.

    Nous retirons le nom, l'établissement et la ville, ce que le benchmark demande, mais aussi les étiquettes de locuteur et les horodatages, ce qu'il ne demande pas. C'est du sur-masquage et nous le comptons intégralement, même si ce qu'il coûte relève de la lisibilité plutôt que de la confidentialité : personne n'a jamais été identifié par le mot « Agent » ou par un horodatage. C'est aussi la part de ce chiffre que nous comptons réduire en premier.

    Ce qu'Hexagone AI a retiré

    [00:02] Agent: Good afternoon, I’m here to assist you today. Can I confirm I’m speaking with Edward Nguyen from Beacon University, located in Eastvale? [00:05]

    Ce que le benchmark annote

    [00:02] Agent: Good afternoon, I’m here to assist you today. Can I confirm I’m speaking with Edward Nguyen from Beacon University, located in Eastvale? [00:05]

    Le même extrait des deux côtés, tiré de l'enregistrement doc-000413 de PII-INDEXBENCH, à l'identique.

  3. 5,7 %1 685 segments

    Quasi-identifiants exclus du benchmark par construction

    Règle. Ce que nous avons retiré correspond à une valeur que le jeu de données rattache à une étiquette écartée : genre, intitulé de poste, service, termes cliniques.

    Le benchmark annote le nom, la date de naissance et l'adresse e-mail, mais délibérément pas le genre, si bien qu'un système est pénalisé pour l'avoir retiré. Au sens du RGPD, un genre combiné aux trois autres reste le genre de détail qui réduit le champ des personnes possibles, et c'est pourquoi nous le retirons malgré tout.

    Ce qu'Hexagone AI a retiré

    - Alex Lee, Gender: nonbinary, DOB: 11/22/1995, Email: alex.lee1942@example.com

    Ce que le benchmark annote

    - Alex Lee, Gender: nonbinary, DOB: 11/22/1995, Email: alex.lee1942@example.com

    Le même extrait des deux côtés, tiré de l'enregistrement doc-000028 de PII-INDEXBENCH, à l'identique.

  4. 22,8 %6 758 segments

    Sur-masquage réel

    Règle. Tout le reste : dates relatives (« yesterday », « next week »), acronymes (AI, FYI, ASAP, VIP), mots isolés.

    « FYI » n'est pas une donnée personnelle et nous n'aurions pas dû y toucher. Environ un segment signalé sur cinq tombe dans ce poste, et c'est lui qui fixe le plancher honnête du chiffre de précision : les autres postes ont une explication, celui-ci n'en a pas.

    Ce qu'Hexagone AI a retiré

    FYI, your recent stay at hospit-179303 located in Lakeside, United Kingdom, involved treatment with medica-785190.

    Ce que le benchmark annote

    FYI, your recent stay at hospit-179303 located in Lakeside, United Kingdom, involved treatment with medica-785190.

    Le même extrait des deux côtés, tiré de l'enregistrement doc-000108 de PII-INDEXBENCH, à l'identique.

Quelle erreur nous préférons commettre

Ne pas retirer un nom constitue une violation de données personnelles, tandis que retirer un intitulé de champ qui n'avait pas besoin de partir laisse un document un peu moins agréable à lire. Nous réglons le système pour la première situation et le payons dans la colonne précision. Un outil à la précision plus serrée que la nôtre fait en général l'arbitrage inverse : il s'accorde plus souvent avec l'annotation et laisse davantage de noms dans vos fichiers, ce qu'il vaut mieux savoir avant de comparer les deux chiffres.

Testez-le sur vos propres documents.

Un benchmark, ce sont les données de quelqu'un d'autre. Une semaine gratuite, sans carte bancaire, et les fichiers ne quittent jamais votre machine : vous ne risquez rien à vérifier vous-même.