Les grands modèles de langage qui alimentent aujourd’hui les assistants conversationnels, les outils de génération de code et les agents IA traversent tous une même séquence d’apprentissage en plusieurs phases. Le pré-entraînement sur des corpus textuels massifs leur confère une compétence linguistique générale : ils apprennent à prédire la suite probable d’une séquence de tokens, ce qui leur permet de générer du texte cohérent. Mais ce qui les rend réellement utiles, sûrs et alignés avec les attentes humaines se joue dans une phase distincte appelée post-entraînement, qui repose intégralement sur de l’annotation de texte produite par des humains experts. Cette annotation de texte n’a rien à voir avec le classique étiquetage d’entités nommées ou la classification de documents : elle exige de juger des réponses, de les comparer, de les réécrire ou de construire délibérément des prompts adversariaux pour révéler les failles du modèle.
Trois méthodes structurent aujourd’hui la production de données de post-training : l’instruction tuning, le RLHF (Reinforcement Learning from Human Feedback) et ses variantes algorithmiques comme le DPO (Direct Preference Optimization), ainsi que le red teaming. Chacune mobilise l’annotation de texte sous une forme différente, avec des exigences spécifiques en matière de profil d’annotateur, de consignes et de contrôle qualité. Cet article décrit la mécanique de chaque méthode, les types de tâches qu’elles imposent aux annotateurs, et les critères qui font la différence entre un dataset de post-training qui améliore réellement un modèle et un dataset qui l’oriente dans une mauvaise direction.
L’annotation de texte au cœur du cycle de post-entraînement des LLM
Un LLM ne sort pas aligné de son pré-entraînement. Il est capable de compléter du texte de façon plausible, mais sans guidance supplémentaire, il peut produire des instructions dangereuses, des réponses incohérentes, des contenus offensants ou simplement inutiles selon le contexte. Le post-entraînement est la séquence de travail qui corrige ce comportement, en utilisant des données humaines pour ajuster la distribution des réponses du modèle vers ce qui est perçu comme utile, exact et sûr. Cette séquence comprend généralement deux grandes étapes : d’abord le supervised fine-tuning (SFT), souvent appelé instruction tuning, qui enseigne au modèle le format attendu d’une interaction productive ; ensuite l’alignement par préférence, qui lui apprend à distinguer une bonne réponse d’une moins bonne selon des critères humains explicites.
L’annotation de texte intervient à chaque étape de cette séquence. Pour le SFT, des annotateurs rédigent ou valident des paires instruction-réponse qui servent d’exemples de référence. Pour l’alignement par préférence, ils comparent et classent des réponses générées par le modèle. Pour le red teaming, ils construisent des prompts adversariaux destinés à révéler les vulnérabilités du système avant qu’elles ne soient exploitées en production. Les équipes spécialisées dans l’annotation de texte pour le NLP et les LLM constituent aujourd’hui un maillon critique de la chaîne de valeur des modèles d’IA, bien au-delà des tâches classiques de traitement du langage naturel. Pour un panorama des tâches d’annotation textuelle dans leur ensemble, on peut se référer à notre guide complet de l’annotation de texte pour le NLP, qui couvre l’ensemble du spectre allant de la NER aux données de post-training pour LLM.
Instruction tuning : l’annotation de texte au service de l’alignement comportemental
L’instruction tuning est la première étape du post-entraînement. Son objectif est d’apprendre au modèle à suivre des instructions de façon fiable : répondre à une question ouverte, reformuler un texte en respectant un style imposé, extraire des informations d’un document, expliquer un concept à différents niveaux de détail. Le principal matériau de cette étape est un dataset de paires instruction-réponse, où chaque exemple montre au modèle ce que signifie « bien répondre » à un type de demande donné. La qualité et la diversité de ce dataset ont un impact direct sur le comportement général du modèle après fine-tuning : un dataset trop homogène produit un modèle compétent sur les cas fréquents mais défaillant sur les cas atypiques.
L’annotation de texte pour l’instruction tuning prend plusieurs formes selon la maturité du projet. Dans les phases initiales, des annotateurs rédigent eux-mêmes des instructions représentatives des usages cibles, accompagnées d’une réponse de référence qu’ils considèrent comme exemplaire. Dans les phases ultérieures, le modèle génère lui-même des réponses candidates que les annotateurs valident, corrigent ou rejettent selon des critères explicitement définis. Le rôle de l’annotateur n’est alors pas de répondre à la place du modèle, mais de porter un jugement éclairé sur la qualité de sa production, selon des dimensions précises : exactitude factuelle, respect de l’instruction, longueur appropriée, ton adapté au contexte, absence de contenu problématique.
Les tâches d’annotation concrètes en instruction tuning
Un projet d’instruction tuning mobilise plusieurs types de tâches d’annotation de texte. La rédaction de prompts diversifiés est souvent la première : les annotateurs sont chargés de produire des instructions couvrant une large variété de formulations, de registres, de longueurs et de niveaux de complexité. La diversité n’est pas anecdotique : deux formulations différentes d’une même demande peuvent conduire le modèle à des comportements très différents après fine-tuning. Un dataset riche en reformulations et en variations contextuelles produit des modèles plus robustes que des datasets où chaque type de tâche n’est représenté que par une poignée d’exemples stéréotypés. La validation de réponses est la contrepartie directe de la rédaction de prompts : pour chaque instruction, l’annotateur s’assure que la réponse de référence est correcte sur le fond, bien formulée sur la forme et ne contient aucun contenu qui contreviendrait aux politiques d’usage définies en amont.
La correction de réponses constitue une troisième modalité fréquente dans les projets d’annotation de texte pour l’instruction tuning. Le modèle produit une réponse imparfaite ; l’annotateur identifie précisément ce qui ne va pas – information inexacte, ton inadapté, instruction partiellement ignorée, longueur excessive, digression hors-sujet – et reformule la réponse pour la corriger. Cette réécriture est une tâche exigeante parce qu’elle demande à l’annotateur de comprendre à la fois ce que le modèle a tenté de faire et ce qu’il aurait dû faire, en préservant les parties correctes tout en corrigeant les parties défaillantes. Un annotateur qui reformule entièrement une réponse correcte à 80 % crée un signal d’entraînement moins précis que celui qui cible exactement les passages à corriger.
La structure d’une paire instruction-réponse bien construite
Une paire instruction-réponse de qualité pour le SFT ne se résume pas à une question et sa réponse correcte. Elle doit être représentative d’un type de tâche clairement délimité, suffisamment distincte des autres exemples pour ne pas créer de raccourcis d’apprentissage, et alignée avec les valeurs que le modèle doit incarner : honnêteté, utilité calibrée à la complexité de la demande, refus explicite des requêtes contraires aux politiques d’usage. Les équipes qui produisent ces données en amont définissent des taxonomies de tâches et des critères de qualité pour chaque catégorie. C’est cette structuration méthodique qui permet d’éviter les datasets déséquilibrés, où certains types d’instructions seraient surreprésentés et d’autres absents, produisant un modèle performant sur les cas couverts et défaillant sur les autres.
La traçabilité de chaque paire fait partie intégrante de la rigueur attendue dans ce type de projet : attribution d’un identifiant unique, date de création, profil de l’annotateur, version des consignes appliquées, résultats du contrôle qualité. Ces métadonnées sont indispensables lors des audits, lors des itérations sur les consignes – fréquentes dans les premières semaines d’un projet LLM – et pour toute démarche de conformité réglementaire liée aux données d’entraînement, notamment dans le cadre de l’EU AI Act.
RLHF : l’annotation de texte comme signal de préférence humaine
Le RLHF est la méthode qui a permis aux assistants conversationnels d’atteindre leur niveau actuel d’utilité perçue. Son principe est de faire noter par des humains, non plus une réponse correcte ou incorrecte en valeur absolue, mais une préférence entre deux réponses générées par le modèle. L’annotateur choisit laquelle des deux réponses il préfère, selon un ensemble de critères définis dans les consignes. Ces préférences servent à entraîner un modèle de récompense distinct, qui apprend à prédire ce que les humains préféreraient dans n’importe quelle situation ; le LLM est ensuite optimisé pour maximiser ce signal de récompense via des algorithmes de reinforcement learning. Le DPO (Direct Preference Optimization) suit la même logique de données mais simplifie la chaîne en se passant du modèle de récompense intermédiaire.
Dans tous les cas, le matériau de base reste identique : des paires de réponses comparées par un annotateur humain, avec une indication de laquelle est préférable et, selon les consignes, une justification écrite. L’annotation de texte pour le RLHF est fondamentalement une tâche de jugement comparatif. Elle est structurellement plus difficile que l’annotation classique parce qu’elle fait appel à des critères multiples, parfois en tension, et à un niveau de nuance que peu d’interfaces d’annotation permettent de capturer intégralement. C’est pourquoi la qualité des consignes est particulièrement déterminante dans ce type de projet : un annotateur mal briefé tendra à utiliser des heuristiques implicites qui introduisent des biais systématiques difficiles à détecter après coup.
Annoter des préférences : le travail réel de l’annotateur RLHF
Lorsqu’un annotateur compare deux réponses dans un projet RLHF, il ne se contente pas de choisir laquelle est « mieux écrite ». Il évalue simultanément plusieurs dimensions : la réponse est-elle factuelle et vérifiable ? Répond-elle précisément à ce qui était demandé, sans omettre d’élément essentiel ni s’étendre sur des points non sollicités ? Est-elle claire, bien structurée, adaptée au registre de la demande ? Contient-elle des affirmations dangereuses, des stéréotypes, des informations erronées ou des incohérences internes ? Est-elle d’une longueur proportionnée à la complexité de la question ? Chacune de ces dimensions peut pointer dans des directions différentes selon les deux réponses comparées. Une réponse peut être parfaitement rédigée mais contenir une erreur factuelle. Une autre peut être maladroite sur le plan stylistique mais plus honnête sur les limites de sa connaissance. L’annotateur doit arbitrer entre ces tensions selon une hiérarchie de critères préétablie.
La qualité de cet arbitrage dépend directement des consignes fournies. Des guidelines RLHF efficaces définissent explicitement la hiérarchie entre les critères de préférence : la sécurité prime sur l’utilité immédiate, l’honnêteté prime sur la flatterie, la précision prime sur l’exhaustivité. Elles incluent des exemples de cas limites documentés et des décisions d’arbitrage expliquées, de façon que les annotateurs n’aient pas à reconstruire cette hiérarchie à partir de leurs intuitions. Sans cette rigueur dans les consignes, les annotateurs tendent à favoriser les réponses les plus longues ou les plus fluides stylistiquement, au détriment de la pertinence réelle. Ce biais de longueur est l’un des plus documentés dans la littérature sur les datasets RLHF, et il se propage dans le comportement du modèle sous forme de verbosité excessive.
Les biais qui fragilisent l’annotation de préférences
Plusieurs biais systématiques ont été identifiés et documentés dans les datasets de préférences pour le RLHF. Le biais de longueur, déjà mentionné, conduit les annotateurs à préférer les réponses plus longues indépendamment de leur pertinence. Le biais d’ordre favorise la première réponse présentée dans l’interface lorsque les deux options sont de qualité comparable. Le biais de confiance conduit à surpondérer les réponses qui semblent assurées, même lorsqu’elles affirment des choses inexactes avec aplomb. Le biais culturel, enfin, fait que des annotateurs appartenant à un même groupe socio-culturel ou linguistique partagent des préférences systématiques qui ne sont pas universellement représentatives. La détection et la correction de ces biais nécessitent une calibration régulière des annotateurs sur des exemples de référence, des sessions de recalibration périodiques, et un suivi des divergences inter-annotateurs qui permette d’identifier les dérives avant qu’elles ne contaminent l’ensemble du dataset.
Données conversationnelles multi-tours : les exigences spécifiques de l’annotation de texte
Les assistants IA modernes ne fonctionnent pas en mode question-réponse unique : ils maintiennent des conversations sur plusieurs échanges, en conservant la mémoire du contexte, en mémorisant les préférences exprimées en début de dialogue et en adaptant progressivement leur ton et leur niveau de détail au fil des échanges. Préparer ces modèles à ce comportement nécessite des données conversationnelles multi-tours, qui constituent une forme particulièrement complexe d’annotation de texte dont les exigences dépassent largement celles d’une simple paire instruction-réponse.
Dans un dataset multi-tours, l’annotateur ne peut pas évaluer un seul échange indépendamment de ceux qui le précèdent. Il doit lire l’intégralité de la conversation, vérifier que le modèle maintient une cohérence de contexte sur la durée – il ne fait pas semblant d’ignorer ce que l’utilisateur a précisé deux messages plus tôt -, que le registre de langage s’adapte correctement aux signaux envoyés par l’utilisateur, et que les corrections ou clarifications apportées par l’utilisateur au fil du dialogue sont bien intégrées dans les réponses suivantes. Un modèle qui oublie le contexte dans une conversation longue est perçu comme moins fiable, même si chacune de ses réponses prises isolément paraît satisfaisante. La volumétrie de ce type de projet est significativement plus élevée en temps par exemple annoté, et les consignes doivent anticiper les nombreux cas particuliers qui émergent dans des échanges longs.
La définition même des échanges peut faire l’objet d’un travail préalable d’annotation de texte : segmenter un dialogue brut en tours cohérents, identifier les bifurcations thématiques à l’intérieur d’une même conversation, marquer les changements de registre ou les transitions entre sujets. Ces tâches de structuration du dialogue servent à entraîner des composantes spécifiques du modèle, comme la gestion de la mémoire contextuelle, la détection des changements de sujet ou le contrôle de la cohérence stylistique sur la durée d’un échange.
Red teaming : l’annotation de texte adversariale pour la sécurité des LLM
Le red teaming désigne l’ensemble des activités visant à identifier les vulnérabilités d’un système IA avant son déploiement en production, en adoptant délibérément la posture d’un utilisateur malveillant ou d’un adversaire. Appliqué aux LLM, il consiste à construire des prompts destinés à faire sortir le modèle de ses rails : l’amener à produire du contenu interdit, à révéler des informations qu’il ne devrait pas divulguer, à se laisser manipuler par des scénarios fictifs ou à adopter une personnalité contredisant ses valeurs fondamentales. Les résultats de ces tests alimentent deux usages distincts : la correction directe des comportements problématiques identifiés, et la constitution d’un dataset d’annotation de texte adversariale utilisé pour entraîner le modèle à résister à ces mêmes types d’attaques dans le futur. Le red teaming est donc à la fois une activité de test et une activité de production de données.
Les types de vulnérabilités ciblées par le red teaming
Les red teamers travaillent sur plusieurs catégories de vulnérabilités, chacune nécessitant une approche et des compétences spécifiques. Les jailbreaks tentent de contourner les garde-fous du modèle en reformulant une demande interdite de façon indirecte, en la plaçant dans un cadre fictif ou roleplay, ou en utilisant des enchaînements de prompts qui amènent progressivement le modèle vers un comportement qu’il aurait refusé si la demande avait été directe. Les tests de hallucination vérifient que le modèle ne fabrique pas d’informations plausibles mais inexactes lorsque sa connaissance est limitée : un LLM qui invente des références bibliographiques, des données chiffrées ou des décisions judiciaires est une source de risque considérable dans les contextes professionnels. Les tests de biais examinent si le modèle produit des réponses systématiquement différentes selon le genre, la nationalité, l’appartenance religieuse ou politique implicites dans le prompt. Les tests de fuite de données vérifient qu’aucun contenu mémorisé lors du pré-entraînement n’est extractable via des formulations astucieuses.
Chaque prompt adversarial produit pendant ces tests, qu’il ait réussi à tromper le modèle ou non, est lui-même un exemple d’annotation de texte au sens large : il est documenté, catégorisé, classé par type de vulnérabilité ciblée et par niveau de sévérité. La réponse générée par le modèle est ensuite annotée : conforme ou non conforme aux politiques de sécurité du système ? Si non conforme, quelle politique a été violée, avec quelle gravité, et dans quel contexte ? Ces annotations alimentent à leur tour les datasets de sécurité utilisés pour le fine-tuning de sécurité ou pour calibrer les systèmes de filtrage de sorties.
La posture et la méthode du red teamer
Le travail de red teaming n’est pas de la simple génération de prompts aléatoires. Il requiert une compréhension fine des mécanismes du modèle, une créativité méthodique pour explorer des angles d’attaque variés et complémentaires, et une rigueur d’annotation pour documenter chaque tentative avec suffisamment de précision pour qu’elle soit exploitable. Les red teamers les plus efficaces combinent une culture technique (compréhension du context window, des mécanismes de role-playing, des injections de prompts, des attaques par séquençage) avec une culture de la conformité (connaissance des politiques d’usage du modèle, des catégories de contenus interdits, des frontières entre usage créatif et usage nuisible). Dans des secteurs comme la santé, le droit ou la finance, les red teamers doivent en outre maîtriser le vocabulaire et les enjeux du domaine pour concevoir des attaques pertinentes par rapport aux risques réels que le modèle est susceptible d’engendrer dans ce contexte d’usage.
LLM spécialisés : quand l’annotation de texte exige des experts métier
Le développement de LLM spécialisés pour des domaines comme le droit, la médecine, la comptabilité ou la finance soulève des exigences particulières en matière d’annotation de texte. Un annotateur généraliste peut comparer deux réponses conversationnelles et juger laquelle est plus utile ou mieux formulée. Mais il est rarement en mesure d’évaluer si une réponse sur les critères de diagnostic d’une pathologie, sur l’interprétation d’une clause contractuelle ou sur les règles de consolidation d’un bilan est correcte sur le fond. Or, dans ces domaines, une erreur factuelle dans les données d’entraînement produit un modèle qui affirme avec confiance des choses inexactes, potentiellement dangereuses pour ses utilisateurs.
L’annotation de texte pour les LLM spécialisés doit donc mobiliser des annotateurs experts : médecins pour les corpus cliniques, juristes pour les corpus légaux, experts-comptables ou analystes financiers pour les corpus financiers. Ces experts travaillent typiquement en complément d’annotateurs généralistes plutôt qu’en remplacement. Ils prennent en charge les tâches de validation de fond – exactitude factuelle, conformité réglementaire, absence d’erreur médicale ou juridique – tandis que les annotateurs généralistes couvrent les aspects formels : qualité rédactionnelle, lisibilité, structure, cohérence stylistique. Ce modèle hybride permet d’optimiser les coûts tout en maintenant le niveau d’exigence indispensable dans ces secteurs. Une paire instruction-réponse sur la posologie d’un médicament doit être validée par un professionnel de santé ; l’évaluation de sa lisibilité ou de sa longueur peut en revanche être confiée à un annotateur formé sur les critères de qualité rédactionnelle du projet.
Cette logique rejoint l’approche développée pour d’autres types de projets complexes d’annotation de données textuelles pour l’IA, où la complémentarité entre profils experts et profils généralistes permet d’atteindre des niveaux de qualité que ni l’un ni l’autre n’obtiendrait seul. Appliquée à l’annotation de texte pour les LLM sectoriels, cette organisation permet de constituer des datasets de qualité expert sans mobiliser des médecins ou des juristes sur des tâches mécaniques qui ne nécessitent pas leur niveau de compétence.
Qualité et gouvernance de l’annotation de texte pour les LLM
La qualité d’un dataset de post-training pour LLM est particulièrement difficile à mesurer par rapport aux tâches d’annotation classiques. Dans un projet de NER ou de classification de documents, l’accord inter-annotateurs se calcule sur des décisions relativement binaires : cette séquence est une entité de type Organisation ou elle ne l’est pas. Dans une tâche de ranking de réponses pour le RLHF, la décision est subjective par nature : deux annotateurs raisonnables, bien formés et de bonne foi, peuvent légitimement préférer deux réponses différentes selon l’importance relative qu’ils accordent à la sécurité, à l’utilité, à la concision ou à la tonalité. Cette subjectivité n’invalide pas l’annotation de texte pour le RLHF, mais elle impose une gestion spécifique que les processus qualité des projets NLP classiques ne couvrent pas toujours.
Accord inter-annotateurs et calibration dans les projets RLHF
La mesure de l’accord inter-annotateurs reste pertinente dans les projets de préférence, mais elle doit être interprétée différemment que dans les tâches classiques. Un accord de 70 à 80 % sur des préférences complexes est généralement considéré comme satisfaisant dans les projets bien structurés ; en dessous, c’est un signal que les consignes sont ambiguës, que les critères de jugement ne sont pas suffisamment hiérarchisés, ou que les annotateurs n’ont pas été calibrés sur les cas limites. La calibration consiste à faire annoter les mêmes exemples par plusieurs personnes, à analyser les divergences, et à organiser des sessions de discussion pour converger sur une interprétation commune des critères. Ces sessions sont d’autant plus efficaces qu’elles portent délibérément sur des cas limites : non pas les préférences évidentes, mais celles où la tension entre plusieurs critères est réelle et où le choix dépend d’une hiérarchie qui doit être partagée par tous.
Les gold standards sont également utiles dans ce contexte, même si leur construction est plus complexe que dans d’autres tâches d’annotation de texte. Des exemples de référence annotés et validés par des responsables de projet permettent de vérifier que les annotateurs de production restent alignés au fil du temps, notamment lorsque les consignes évoluent ou que de nouvelles catégories de tâches sont introduites dans le périmètre du projet. L’insertion de ces exemples de référence dans les files d’annotation courante – ce que la pratique appelle parfois des honeypots ou des gold items – est une méthode éprouvée pour détecter la dérive qualitative avant qu’elle n’affecte l’intégralité du dataset. La gestion de cette subjectivité rejoint les défis abordés dans notre article sur l’analyse de sentiment et la gestion de la subjectivité en annotation de texte, qui traite de mécanismes de calibration comparables dans un contexte de jugement subjectif différent.
Documenter les données de post-training : une exigence réglementaire croissante
L’EU AI Act impose aux développeurs de systèmes d’IA à haut risque, et aux fournisseurs de modèles de fondation, de documenter leurs pratiques en matière de données d’entraînement. L’article 10 du règlement exige notamment que les données utilisées soient pertinentes, représentatives et exemptes d’erreurs dans la mesure du possible. Pour les données de post-training, cette exigence implique de tracer l’origine de chaque exemple, les critères de sélection appliqués, les profils des annotateurs qui ont réalisé les jugements, et les procédures de contrôle qualité mises en oeuvre. Un dataset d’annotation de texte produit sans documentation adéquate expose ses utilisateurs à des difficultés lors des audits réglementaires, mais aussi à des risques opérationnels concrets si la qualité des données n’a jamais été formellement évaluée et traçée.
La documentation des datasets de post-training rejoint plus largement les bonnes pratiques de gouvernance des données IA : versionner les datasets à chaque évolution des consignes, tracer les modifications, documenter les biais connus et les mesures prises pour les atténuer, conserver les résultats des audits qualité. Ces pratiques ne sont pas uniquement des obligations réglementaires. Elles sont surtout ce qui permet d’itérer efficacement lorsque le modèle présente en production des comportements inattendus, en permettant de remonter à la source du problème dans les données plutôt que de multiplier les hypothèses sur l’architecture ou les hyperparamètres.
Concevoir et mener à bien un projet d’annotation de texte pour le post-entraînement d’un LLM suppose de définir précisément les tâches et leur articulation, de choisir des annotateurs dont le profil correspond aux exigences du domaine, de mettre en place des processus de calibration et de contrôle qualité adaptés à la subjectivité des jugements, et de documenter chaque étape avec la rigueur qu’exigent les parties prenantes réglementaires comme les équipes de recherche elles-mêmes. Les équipes qui maîtrisent cette chaîne obtiennent des résultats stables, reproductibles et auditables. Si vous souhaitez discuter d’un projet de données pour LLM, l’équipe Infoscribe est disponible pour analyser vos besoins et vous proposer une approche adaptée à vos contraintes de volume, de qualité et de délai.
