JwumaComment rédiger une grille d'annotation qui résiste à la réalité
· 3 min de lecture · specification, quality
Cette traduction a été produite par une machine et n'a pas été vérifiée par un locuteur natif. En cas de doute, la version anglaise fait foi. Signalez-nous toute erreur et nous la corrigerons. English
Une bonne grille consacre la plupart de sa longueur aux cas limites plutôt qu'aux définitions, car les annotateurs sont rarement en désaccord sur les cas clairs. Figez-la au début d'un lot pour que la norme ne puisse pas dériver en cours de projet, et considérez chaque ambiguïté signalée par un annotateur comme un défaut de la grille plutôt qu'une erreur de l'annotateur.
En bref
- Les désaccords entre annotateurs se concentrent presque entièrement sur les cas limites.
- Une grille doit être figée au début d'un lot et versionnée par la suite.
- Chaque étiquette doit être traçable à la version de la grille qui l'a produite.
- Une ambiguïté signalée est un défaut de la grille, pas une erreur de l'annotateur.
- Une grille modifiée en cours de lot invalide la comparaison au sein de ce lot.
Un projet de ce type à cadrer ?
Nous préférons parler du problème plutôt que chiffrer un volume.
Voir nos prestationsPourquoi les grilles échouent-elles ?
Presque jamais parce que les définitions sont erronées. Elles échouent parce que les définitions sont correctes et les cas limites absents, donc vingt annotateurs inventent indépendamment vingt réponses différentes à la même question non traitée.
Le symptôme le plus courant est des scores d'accord qui semblent acceptables dans l'ensemble tandis qu'une partie spécifique des données est discrètement inutile. L'accord global masque bien cela.
Quelle part de la grille doit être consacrée aux cas limites ?
La plupart. Si votre grille est principalement constituée de définitions avec une courte section d'exemples à la fin, c'est un glossaire plutôt qu'une grille.
La manière productive d'en rédiger une est de réaliser un petit lot pilote avec une grille sous-spécifiée, de recueillir chaque cas qu'un annotateur signale comme ambigu, et de transformer chacun en règle explicite. Le but du pilote est de trouver les questions, pas de produire des données.
Pourquoi figer la grille ?
Parce que si la norme change en cours de lot, le travail correctement effectué sous l'ancienne définition devient rétroactivement incorrect, et vous ne pouvez pas savoir à partir du jeu de données quels éléments ont été jugés sous quelle version.
Figer signifie que la version en vigueur à l'ouverture d'un lot régit ce lot. Les améliorations s'appliquent au suivant. Chaque étiquette porte alors la version qui l'a produite, ce qui rend un jeu de données auditable un an plus tard lorsque quelqu'un demande pourquoi deux éléments similaires sont étiquetés différemment.
Comment gérer une ambiguïté signalée ?
Comme un rapport de défaut concernant votre grille, ce qu'elle est. Un annotateur qui signale plutôt que de deviner a fait exactement ce qu'il fallait et ne devrait jamais être pénalisé pour cela.
Les plateformes qui pénalisent le signalement obtiennent moins de signalements et des données de moindre qualité, car l'ambiguïté ne disparaît pas, elle est simplement résolue silencieusement et de manière incohérente là où personne ne peut la voir.
Autres questions
Qu'est-ce qui rend une grille d'annotation bonne ?
Un traitement explicite des cas limites. Les annotateurs sont rarement en désaccord sur des exemples clairs, donc une grille qui est principalement constituée de définitions et de peu de cas limites produira des étiquettes incohérentes.
Une grille doit-elle être modifiée en cours de projet ?
Non. Figez-la au début du lot pour que la norme ne puisse pas dériver, et appliquez les améliorations au lot suivant. Sinon, le travail correctement effectué devient rétroactivement incorrect.
Que doit-il se passer lorsqu'un annotateur signale un cas ambigu ?
Il doit être traité comme un défaut de la grille et résolu explicitement. Pénaliser le signalement pousse simplement l'ambiguïté sous terre où elle est résolue de manière incohérente.