Skip to content
Guides6 min read

Annotateurs LLM contre humains : quand automatiser un travail d'étiquetage et quand s'en abstenir

Un guide pratique pour décider quand un LLM peut annoter vos données, où les annotateurs modèles échouent, et comment combiner automatisation et vérification humaine dans Potato.

Potato Team

La question revient maintenant sur chaque projet d'étiquetage : a-t-on encore besoin de gens pour ça, ou un modèle peut-il simplement s'en charger ? La question est légitime. Les annotateurs LLM sont rapides, ne fatiguent pas et coûtent une fraction du prix d'une foule. Tout dépend de la tâche, de façon prévisible, et les projets qui tournent mal sont en général ceux qui n'ont jamais vérifié.

Un LLM est un bon annotateur quand la tâche est bien définie, les étiquettes objectives, et que vous pouvez le mesurer contre un échantillon de référence humain. C'est un mauvais annotateur quand les étiquettes sont subjectives, culturellement chargées, ou assez nouvelles pour qu'aucune vérité terrain n'existe encore. Le réglage par défaut prudent consiste à automatiser ce que le modèle fait de façon fiable, à vérifier un échantillon du reste, et à laisser les cas difficiles aux humains.

Les performances se divisent selon le type de tâche

Les résultats se divisent selon le type de tâche. Gilardi, Alizadeh et Kubli (2023) ont constaté que ChatGPT dépassait les travailleurs de foule sur la pertinence, la prise de position et la détection de cadrage, avec un meilleur accord et un coût quasi nul. Mais Ziems et ses collègues (2024), qui ont testé 13 modèles sur 25 bancs d'essai de sciences sociales computationnelles, obtiennent un tableau inégal : sur les tâches de classification, les LLM n'atteignent qu'un accord moyen avec les humains et dépassent rarement un modèle affiné, alors que sur l'explication en texte libre ils produisent souvent des sorties qui se lisent mieux que les réponses de référence de la foule.

Donc « un LLM peut-il étiqueter ceci ? » est en réalité deux questions. Est-ce le genre de tâche où les modèles réussissent ? Et sur mes données précises, le modèle est-il vraiment d'accord avec les gens ? Vous pouvez raisonner sur la première à partir du type de tâche. La seconde, il faut la mesurer.

Où les annotateurs LLM échouent

Les échecs se regroupent, ce qui veut dire que vous pouvez les anticiper.

  • Étiquettes subjectives et culturelles. La toxicité, l'offense, l'humour, la politesse et le jugement moral dépendent de qui lit. Un modèle unique donne une réponse aplatie là où un panel d'annotateurs divers serait en désaccord de façon informative, et ce désaccord est souvent le signal que vous cherchiez.
  • Biais systématique dans les comparaisons. Quand un LLM juge deux réponses, ce n'est pas un arbitre neutre. Zheng et ses collègues (2023) ont documenté le biais de position (il favorise la première option affichée), le biais de verbosité (il récompense les réponses plus longues) et le biais d'auto-valorisation (il préfère le texte dans son propre style). Ces biais sont constants : ils poussent tout votre jeu de données dans une même direction au lieu d'ajouter du bruit.
  • Pas encore de vérité terrain. Si vous construisez un schéma de codage entièrement neuf, il n'y a rien contre quoi valider le modèle, et une étiquette fausse et assurée est pire qu'un manque assumé. Les nouveaux schémas ont d'abord besoin de codeurs humains, ne serait-ce que pour créer l'ensemble de référence.
  • Dérive silencieuse. Le comportement d'un modèle change au fil d'un corpus long et au fil des versions. Sans échantillon de référence fixe contre lequel revérifier, vous ne verrez pas la distribution des étiquettes bouger sous vos pieds.

Chacun de ces points plaide pour traiter la sortie du modèle comme un brouillon solide plutôt que comme une étiquette finie.

Le schéma qui fonctionne

Le montage praticable est un tri : envoyez chaque élément dans la voie qui correspond à sa difficulté.

Un flux de décision qui trie les éléments en trois voies : automatiser les éléments objectifs à fort accord, vérifier un échantillon des éléments moyens, et envoyer les éléments subjectifs ou à fort enjeu à des annotateurs humains.Automatisez ce que le modèle fait bien, vérifiez un échantillon, gardez les cas difficiles avec les humains

Faites d'abord tourner le modèle sur un échantillon de référence étiqueté et lisez l'accord par étiquette, pas seulement l'accord global. Là où il rejoint les humains, laissez-le porter ces éléments et contrôlez une tranche par sondage. Là où l'accord est moyen, gardez la suggestion du modèle mais faites confirmer chaque cas par une personne. Là où l'étiquette est subjective ou la décision à fort enjeu, laissez le travail aux annotateurs humains et servez-vous du modèle, au mieux, comme d'un indice. Les proportions évoluent au fil du projet à mesure que vous découvrez où le modèle est fiable, mais la forme reste la même.

Un garde-fou compte du début à la fin : conservez une tranche aveugle, purement humaine, à laquelle le modèle ne touche jamais. C'est votre étalon. Sans elle, le biais d'automatisation s'installe, les vérificateurs approuvent machinalement des suggestions plausibles, et votre accord mesuré grimpe alors que la qualité réelle, non.

Coût et qualité

Il est tentant de poser le problème comme modèle bon marché contre humains chers, mais cela masque le vrai arbitrage. Une étiquette de modèle ne coûte presque rien à produire et coûte quelque chose de réel à croire : l'ensemble de référence bâti pour la valider, la passe de vérification humaine, les sondages. Une étiquette humaine coûte plus cher au départ et moins cher à croire. Pour une tâche vaste et objective, le modèle l'emporte sur le coût total dès que la validation est amortie. Pour une tâche petite ou subjective, la surcharge de validation peut coûter plus cher que de faire étiqueter par des gens. Faites le calcul sur votre tâche au lieu de supposer que le modèle revient moins cher.

Le faire dans Potato

Potato est conçu pour exécuter ce flux mixte plutôt que d'imposer un choix tout ou rien. Activez le support IA pour qu'un modèle pré-annote, puis laissez les gens vérifier :

yaml
ai_support:
  enabled: true
  endpoint_type: openai       # or anthropic, gemini, ollama, ...
  ai_config:
    model: gpt-4
    api_key: ${OPENAI_API_KEY}
    temperature: 0.2

Le modèle propose une étiquette ; l'annotateur la confirme ou la corrige, et c'est l'étiquette vérifiée qui est enregistrée. Pour l'aiguillage lui-même, un schéma de tri permet à une personne d'avancer vite dans les suggestions du modèle, en gardant les cas clairs et en signalant le reste pour une annotation plus poussée.

Pour mesurer le modèle contre les humains, ne pré-remplissez pas les éléments que vous réservez à l'accord. Laissez une tranche aveugle, faites-la étiqueter par des humains, et comparez avec le kappa de Cohen ou de Fleiss. Ce chiffre, par étiquette, décide de la voie à laquelle appartient chaque partie de votre tâche. Le guide de pré-annotation détaille davantage les garde-fous contre le biais d'automatisation.

Pour aller plus loin