🤖 AI

OLAF: Towards Robust LLM-Based Annotation Framework in Empirical Software Engineering

Ce document de position propose OLAF, un cadre conceptuel qui traite l'annotation basée sur les LLM dans le génie logiciel empirique comme un processus de mesure rigoureux en définissant des construits clés tels que la fiabilité, le calibrage et la dérive afin d'améliorer la transparence et la reproductibilité.

Auteurs originaux : Mia Mohammad Imran, Tarannum Shaila Zaman

Publié 2026-01-27

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Mia Mohammad Imran, Tarannum Shaila Zaman

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous essayez d'organiser une immense bibliothèque de notes manuscrites désordonnées. Par le passé, vous auriez engagé une équipe de bibliothécaires humains pour lire chaque note, décider de la catégorie à laquelle elle appartient (comme « Rapport de bug », « Demande de fonctionnalité » ou « Spam ») et écrire une étiquette dessus. C'est lent, coûteux, et parfois deux bibliothécaires peuvent être en désaccord sur la même note.

Maintenant, imaginez que vous engagiez un robot super intelligent (une IA ou un grand modèle de langage) pour faire l'étiquetage pour vous. C'est rapide et peu coûteux. Mais voici le problème : le robot fait-il réellement du bon travail, ou est-il simplement en train de deviner ?

Ce document, intitulé OLAF, soutient que nous devons cesser de traiter ces robots comme des boîtes noires magiques qui se contentent de « faire le travail ». Au lieu de cela, nous devons les traiter comme des outils de mesure scientifiques, tout comme un thermomètre ou une balance. Si vous utilisez une balance pour peser les ingrédients d'un gâteau, vous devez savoir si la balance est précise, si elle dérive avec le temps, et si elle donne le même résultat à chaque utilisation.

Voici la décomposition des idées du document en utilisant des analogies simples :

1. Le Problème : Le piège de la « Boîte Magique »

Actuellement, de nombreux chercheurs utilisent l'IA pour étiqueter des données, mais ils ne nous disent pas comment ils l'ont fait.

L'analogie : Imaginez qu'un boulanger dise : « J'ai utilisé un four spécial pour cuire ce pain. » Mais il ne vous dit pas la température, le temps, ni la marque du four. Si vous essayez de cuire le même pain, il pourrait ressortir brûlé ou cru.
La réalité : Les chercheurs oublient souvent de mentionner des détails précis comme les mots exacts qu'ils ont tapés pour l'IA (le « prompt »), la version spécifique de l'IA, ou les paramètres utilisés. De ce fait, personne d'autre ne peut répéter leur expérience pour voir s'il obtient les mêmes résultats.

2. La Solution : OLAF (Le cadre de « Contrôle Qualité »)

Les auteurs proposent un nouveau cadre appelé OLAF. Considérez OLAF comme une liste de contrôle pour le contrôle qualité que vous devez utiliser avant de faire confiance aux étiquettes du robot. Cela traite l'IA non pas comme un travailleur, mais comme un instrument de mesure qui doit être calibré.

OLAF vous demande de vérifier six éléments spécifiques (Construits) :

Fiabilité (Le test de la « Cohérence ») : Si vous demandez au robot d'étiqueter la même note cinq fois, donne-t-il la même réponse ? Ou change-t-il d'avis ?
Consensus (Le test du « Câlin de groupe ») : Si vous utilisez trois robots différents, sont-ils tous d'accord sur l'étiquette ? S'ils disent tous « Bug », c'est un signal fort. S'ils sont en désaccord, la tâche est peut-être trop confuse.
Agrégation (Le système de « Vote ») : Comment combinez-vous les réponses ? Prenez-vous simplement une majorité de votes ? Ou utilisez-vous une formule mathématique sophistiquée pour déterminer quel robot est le plus fiable ?
Transparence (Le test du « Reçu ») : Avez-vous tout noté ? Le nom du robot, le numéro de version, les mots exacts que vous avez tapés ? Sans ce « reçu », votre travail est inutile pour les autres.
Calibration (Le test de la « Confiance ») : Si le robot dit : « Je suis sûr à 99 % qu'il s'agit d'un bug », est-il réellement correct 99 % du temps ? Ou est-il simplement trop sûr de lui ? Cela vérifie si la confiance du robot correspond à la réalité.
Dérive (Le test des « Objectifs mouvants ») : Les modèles d'IA changent au fil du temps. Un robot qui fonctionne parfaitement aujourd'hui pourrait agir différemment le mois prochain parce que l'entreprise a mis à jour son logiciel. OLAF vérifie si le comportement du robot a « dérivé » ou changé de manière inattendue.

3. Comment utiliser le robot (Les six configurations)

Le document explique également que vous n'avez pas toujours besoin de laisser le robot tout faire. Il suggère six façons de mélanger humains et robots, comme différentes recettes :

Humain dans la boucle (Human-in-the-Loop) : Le robot fait une première passe, mais un humain vérifie les cas dont le robot n'est pas sûr. (Comme un élève faisant ses devoirs, et un professeur corrigeant les parties difficiles).
Modèle dans la boucle (Model-in-the-Loop) : Le robot suggère une réponse, et un autre robot ou un humain la vérifie.
Vérificateur dans la boucle (Verifier-in-the-Loop) : Un second robot agit comme un « arbitre » pour vérifier si la réponse du premier robot est bonne avant qu'un humain ne la voie.
Filtre (Filter) : Le robot élimine rapidement les déchets évidents (comme les spams) afin que les humains n'aient à regarder que l'essentiel.
Juge (Judge) : Le robot agit comme un arbitre, notant le travail d'autres IA selon un ensemble de règles.
Annotateur (Annotator) : Le robot fait tout le travail seul. (C'est rapide, mais risqué si le robot commet une erreur).

4. Le Piège (Limites)

Les auteurs admettent que ce n'est pas encore une solution parfaite.

L'analogie : Vous ne pouvez pas faire totalement confiance à un thermomètre si vous ne savez pas comment il a été construit ou si l'usine change la conception chaque semaine.
La réalité : Beaucoup de modèles d'IA populaires (comme ceux des grandes entreprises technologiques) sont des « boîtes noires ». Nous ne connaissons pas leurs données d'entraînement, et ils peuvent changer sans prévenir. OLAF tente de mesurer leur stabilité, mais ne peut garantir qu'ils ne changeront pas demain.

Résumé

Le document dit : « Arrêtez de traiter l'étiquetage par l'IA comme de la magie. Commencez à le traiter comme une science. »

Si vous voulez utiliser l'IA pour étiqueter des données en génie logiciel, vous avez besoin d'un cadre (OLAF) qui vous oblige à vérifier si l'IA est cohérente, si elle est honnête sur sa confiance, et si vous avez noté exactement comment vous l'avez utilisée. Sans cela, vos résultats de recherche pourraient être peu fiables, comme un gâteau fait avec un four non mesuré.

Résumé Technique : OLAF – Vers un cadre d'annotation robuste basé sur les LLM dans le génie logiciel empirique

Énoncé du problème
Le génie logiciel empirique (ESE) s'appuie de plus en plus sur les grands modèles de langage (LLM) pour automatiser ou assister les tâches d'annotation, telles que l'étiquetage des rapports de bogues, la classification des intentions de commits ou l'identification de la dette technique auto-admise. Cependant, la rigueur méthodologique de ces pratiques reste sous-développée. Les études actuelles traitent souvent l'annotation basée sur les LLM comme une activité purement automatisée plutôt que comme un processus de mesure, ce qui entraîne plusieurs lacunes critiques :

Manque de standardisation : Il n'existe pas de mesures standardisées pour la fiabilité, le calibrage ou la dérive dans les études d'annotation par LLM.
Signalement fragmenté : Les détails de configuration essentiels (ex. : modèles de prompts, paramètres de décodage, versions de modèles) sont fréquemment omis, entravant la reproductibilité.
Sensibilité à la configuration : Des changements mineurs dans les prompts, les réglages de température ou les mises à jour de modèles peuvent radicalement altérer les résultats (un phénomène nommé « dérive de prompt » ou « LLM hacking »), pourtant ces sensibilités sont rarement quantifiées.
Construits non définis : Des concepts abstraits comme la « précision des étiquettes » manquent de définitions opérationnelles formelles liant les concepts à des procédures mesurables, menaçant la validité de construit, interne et externe.

Méthodologie et Cadre (OLAF)
Le document propose le Cadre d'Opérationnalisation pour l'Annotation basée sur les LLM (OLAF). Plutôt que d'offrir un nouvel algorithme ou un résultat expérimental spécifique, OLAF est un cadre conceptuel conçu pour traiter l'annotation par LLM comme un processus mesurable et auditable. Il opérationnalise l'annotation à travers six construits clés et les associe à des mesures et des axes de rapport spécifiques (résumés dans le Tableau 1 de l'article) :

Fiabilité de l'annotateur : Mesure l'accord entre les annotateurs individuels (humains ou modèles) en utilisant des statistiques corrigées du hasard (ex. : $\kappa$ de Cohen, AC1 de Gwet, $\alpha$ de Krippendorff).
Consensus : Reflète l'accord au niveau du groupe pour déterminer si les annotateurs convergent vers un jugement partagé ou si la tâche contient une ambiguïté inhérente.
Agrégation : Définit les méthodes de combinaison de plusieurs annotateurs en une seule étiquette, en distinguant spécifiquement l' agrégation probabiliste (ex. : Dawid–Skene, GLAD, MACE) du vote majoritaire.
Transparence : Impose une documentation complète des identifiants de modèle, des paramètres, des prompts et des réglages (en suivant des pratiques telles que les Datasheets et les Model Cards) pour assurer la reproductibilité.
Calibrage : Évalue la justesse des probabilités prédites en comparant les scores de confiance aux précisions empiriques à l'aide de métriques telles que l'erreur de calibration attendue (ECE) et le score de Brier.
Dérive : Capture la stabilité comportementale en mesurant à quel point le comportement du modèle change sous l'effet de variations de prompts ou de contexte, quantifié via des distances d'activation (L2, cosinus), des métriques de distribution de sortie (divergence de Jensen-Shannon) ou des indices de sensibilité au prompt (POSIX).

Le cadre catégorise également six flux de travail d'annotation courants (Tableau 2) pour contextualiser l'application de ces mesures :

Human-in-the-Loop (HitL - L'humain dans la boucle)
LLM/Model-in-the-Loop (MitL - Le modèle dans la boucle)
Verifier-in-the-Loop (VitL - Le vérificateur dans la boucle)
LLM-as-a-Pre-screen-Filter (Le LLM comme filtre de pré-sélection)
LLM-as-a-Judge (LLMaaJ - Le LLM comme juge)
LLM-as-an-Annotator (Le LLM comme annotateur)

Contributions Clés

Changement Conceptuel : L'article soutient qu'il faut reconceptualiser l'annotation par LLM, passant d'une tâche d'automatisation à un processus de mesure, exigeant la même rigueur de validation que les métriques de code traditionnelles.
Définitions Opérationnelles : Il fournit le premier ensemble structuré de définitions opérationnelles pour la fiabilité, le consensus, la dérive et le calibrage, spécifiquement adaptés à l'annotation par LLM dans le génie logiciel (SE).
Directives pour la Pratique : Les auteurs fournissent des directives concrètes pour les chercheurs, notamment :
- Déclarer explicitement la configuration d'annotation (ex. : HitL vs. LLM-as-an-Annotator).
- Documenter l'intégralité des détails du modèle et du prompt.
- Sélectionner des méthodes d'agrégation appropriées basées sur l'accord observé.
- Implémenter le suivi de la dérive en utilisant des sous-ensembles de calibration fixes (ex. : ré-annoter 50 à 100 éléments étiquetés par des experts lorsque les paramètres changent).
Ressources : Les auteurs ont mis en place un site web compagnon (se-llm-annotation-olaf.github.io) avec des directives détaillées et des exemples.

Résultats et Revendications
En tant que papier de position, OLAF ne présente pas de nouvelles données expérimentales ou de résultats empiriques validant l'efficacité du cadre. À la place, ses « résultats » sont la synthèse de la littérature existante (citant les travaux d'Ahmed et al., Baumann et al., Wagner et al., etc.) pour démontrer le manque actuel de rigueur.

L'article affirme que :

Les pratiques actuelles d'annotation par LLM sont insuffisantes pour les contextes critiques pour la sécurité ou sensibles à la conformité en raison de l'absence de définition de la fiabilité et du calibrage.
Les six construits proposés constituent une fondation nécessaire pour la recherche reproductible, permettant aux chercheurs de sélectionner les dimensions pertinentes pour leur tâche spécifique (ex. : les tâches déterministes peuvent ne pas nécessiter les six dimensions).
Le cadre reconnaît des limites, particulièrement concernant les modèles propriétaires (ex. : GPT, Claude) où les données d'entraînement et les calendriers de mise à jour sont opaques, faisant de la « stabilité contrainte » l'objectif réaliste plutôt que le comportement déterministe.

Signification
La signification d'OLAF réside dans son potentiel à élever les standards méthodologiques du génie logiciel empirique. En fournissant un vocabulaire structuré et une approche de mesure, il vise à :

Motiver les discussions méthodologiques concernant la validité des étiquettes générées par les LLM.
Permettre aux futurs travaux empiriques d'être plus transparents et reproductibles.
Empêcher la nature de « boîte noire » de l'annotation par LLM de compromettre la validité des conclusions de la recherche en génie logiciel.

Les auteurs positionnent OLAF comme une étape initiale, avec des travaux futurs prévus pour évaluer empiriquement l'impact du cadre sur la reproductibilité et pour développer des exemples opérationnels spécifiques au génie logiciel.

1. Le Problème : Le piège de la « Boîte Magique »

2. La Solution : OLAF (Le cadre de « Contrôle Qualité »)

3. Comment utiliser le robot (Les six configurations)

4. Le Piège (Limites)

Résumé

Articles similaires