💻 computer science

LLM-as-a-Judge for Human-AI Co-Creation: A Reliability-Aware Evaluation Framework for Coding

Ce papier présente un cadre LLM-comme-juge, sensible à la fiabilité et piloté par des grilles d'évaluation, pour évaluer la co-création humain-IA en programmation, qui combine une évaluation rigoureuse par un juge multi-métrique avec une analyse au niveau des trajectoires pour révéler que le succès de la co-création se concentre généralement tôt tandis que les comportements de révision restent hétérogènes.

Auteurs originaux : Md Faizul Ibne Amin, Yutaka Watanobe, Daniel M. Muepu, Haruto Suzuki, Kenta Nanaumi, Md Mostafizer Rahman

Publié 2026-05-01

📖 5 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Md Faizul Ibne Amin, Yutaka Watanobe, Daniel M. Muepu, Haruto Suzuki, Kenta Nanaumi, Md Mostafizer Rahman

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 une compétition de codage à haut risque où les participants ont le droit d'utiliser des assistants IA pour les aider à résoudre des problèmes. Ce papier est comme un bulletin de notes pour deux choses se produisant dans cette salle : la qualité de la collaboration entre humains et IA, et la compétence des « arbitres » (les juges IA) pour évaluer le travail.

Voici le détail de ce que les chercheurs ont fait, en utilisant des analogies simples :

1. Le Cadre : Le Concours de Codage « IA Autorisée »

Habituellement, dans les concours de codage, utiliser l'IA est considéré comme de la triche. Mais ici, les chercheurs ont organisé une catégorie spéciale où 15 participants ont tenté de résoudre 13 problèmes difficiles en utilisant des outils IA de leur choix.

L'Objectif : Ils voulaient voir non seulement si le code fonctionnait, mais comment les humains et l'IA ont trouvé la solution ensemble. Sont-ils restés bloqués ? Ont-ils corrigé de petites erreurs, ou ont-ils tout jeté pour recommencer ?
Le Problème : La notation traditionnelle ne regarde que la réponse finale (Réussi/Échoué). C'est comme un professeur qui ne regarderait que la rédaction finale en ignorant les brouillons désordonnés, les phrases barrées et les notes en marge. Les chercheurs voulaient noter le processus, pas seulement le produit.

2. La Solution : Le Juge IA « Piloté par une Grille d'Évaluation »

Pour évaluer ces processus complexes et multi-étapes, les chercheurs ne pouvaient pas simplement demander à un humain de lire des milliers de journaux d'activité. Ils ont donc construit un système utilisant des Juges IA (comme OpenAI, DeepSeek, Gemini et Claude) pour agir en tant qu'arbitres.

Pensez-y comme à un panel d'arbitres sportifs :

Les Règles : Au lieu de laisser les juges IA rédiger des opinions libres (ce qui peut être désordonné et incohérent), les chercheurs les ont obligés à remplir une grille de notation stricte (un « schéma »). Ils devaient attribuer des scores spécifiques pour des éléments tels que « La logique est-elle solide ? » et « Les cas limites sont-ils gérés ? ».
Le Filet de Sécurité : Puisque l'IA fait parfois des erreurs ou donne des réponses étranges, le système disposait d'un « mécanisme de réparation ». Si un juge IA oubliait de remplir une case sur la grille, le système le détectait et demandait à l'IA de réessayer jusqu'à ce que la grille soit parfaite.
Le Contexte : Les juges avaient le droit de voir l'historique complet des invites du participant (ce qu'ils ont demandé à l'IA) avant de noter un morceau de code spécifique. C'est comme un arbitre regardant la replay complet du match avant de siffler une faute, plutôt que de ne regarder qu'un seul instantané.

3. Les Résultats : Comment les Humains et l'IA Ont Travaillé Ensemble

Les chercheurs ont analysé les « trajectoires » (le parcours étape par étape) des participants.

L'Effet « Lève-Tôt » : Ils ont constaté que le succès se produit très tôt. Imaginez une course où 85 % des coureurs franchissent la ligne d'arrivée au cours des premiers pas. Une fois qu'un participant et son IA ont trouvé le bon chemin, ils résolvaient généralement le problème rapidement. S'ils luttaient encore après les premières tentatives, ils réussissaient rarement plus tard.
Deux Façons de Réparer une Voiture : Lorsque le code était erroné, les participants le corrigeaient de deux manières très différentes :
1. Le Mécanicien : Ajustant de petites parties (affinement incrémental).
2. L'Architecte : Jetant tout le design et le reconstruisant (restructuration large).
- La Surprise : Les deux méthodes fonctionnaient également bien. Il n'y avait pas de « meilleure » façon de corriger le code ; parfois un petit ajustement suffisait, et parfois une reconstruction totale était nécessaire.

4. Les Résultats : Quelle était la Qualité des Juges IA ?

Les chercheurs ont testé quatre modèles d'IA différents pour voir lequel était le meilleur arbitre.

Différentes Forces : Tout comme les arbitres humains, les juges IA avaient des personnalités différentes.
- DeepSeek était le meilleur pour classer les bonnes tentatives au-dessus des mauvaises (comme repérer les meilleures actions).
- OpenAI était bon pour être précis avec ses scores de probabilité.
- Gemini et Claude avaient leurs propres particularités.
Le Problème de « l'Accord » : Les juges ne s'accordaient pas toujours entre eux. Si vous demandiez à deux juges IA différents de noter le même code, ils pouvaient attribuer des scores différents. Les chercheurs ont constaté que s'ils s'accordaient parfois, ils étaient souvent en désaccord.
La Leçon : Vous ne pouvez pas vous fier à un seul juge IA. Vous avez besoin d'un « panel » d'entre eux, et vous devez examiner un ensemble de différentes métriques (comme leur capacité à classer, leur calibration de la confiance et la fréquence de leurs accords) pour obtenir une image fidèle de la qualité.

5. La Grande Conclusion

Ce papier introduit une nouvelle feuille de route pour évaluer comment les humains et l'IA travaillent ensemble.

Pour le Processus : Il montre que dans le codage assisté par l'IA, le succès se produit généralement tôt, et qu'il n'existe pas de seule façon « correcte » de corriger un bug.
Pour la Notation : Il prouve que l'IA peut être un arbitre fiable si vous l'obligez à suivre des règles strictes, à vérifier son travail et à utiliser plusieurs juges pour recouper les scores.

En bref : Le papier a créé une meilleure façon de noter la danse collaborative et désordonnée entre humains et IA, nous montrant que le succès se produit souvent rapidement, et que nous avons besoin d'une équipe d'arbitres IA pour obtenir le bon score.

1. Énoncé du problème

L'article comble une lacune critique dans l'évaluation de la co-création Humain-IA en programmation et en génie logiciel (SE). Bien que les modèles de langage de grande taille (LLM) soient de plus en plus utilisés à la fois comme partenaires de co-création et comme évaluateurs (« LLM-as-a-Judge »), les protocoles d'évaluation existants sont souvent insuffisants pour ce contexte spécifique :

Limitations des métriques héritées : L'évaluation traditionnelle de la programmation repose sur les résultats finaux (par exemple, les cas de test réussis/échoués), ce qui ne parvient pas à capturer la valeur des artefacts intermédiaires, des solutions partielles, des hypothèses de débogage et du processus de raisonnement itératif inhérent à la co-création.
Fiabilité et biais : Les juges LLM sont sujets à des biais (par exemple, favoriser les réponses plus longues, biais de position) et à des incohérences. Il manque des cadres standardisés et auditable garantissant que les sorties des juges sont fiables, comparables entre différents modèles et interprétables au cours d'interactions multi-tours.
Risques de fuite de données : Dans les contextes de co-création, les multiples tentatives d'un même utilisateur sur un même problème créent des « trajectoires ». Une division aléatoire standard peut entraîner une fuite de données, où le juge voit des informations d'un tour ultérieur lors de l'évaluation d'un tour antérieur.

2. Méthodologie

Les auteurs proposent un cadre unifié, piloté par une grille d'évaluation (rubric), de type LLM-as-a-Judge, conçu spécifiquement pour la co-création Humain-IA de style concours. La méthodologie se compose de trois étapes principales :

A. Traitement des données et construction du jeu de données

Source : Les données ont été collectées à partir de la piste de co-création autorisant l'IA des finales du PC Koshien (PCK), où les participants résolvaient les mêmes problèmes que lors du concours officiel mais avaient le droit d'utiliser des outils d'IA.
Regroupement des trajectoires : Les données sont organisées en trajectoires définies par des paires (participant, problème) pour prévenir les fuites.
Contexte NONAVEUGLE : Pour simuler une évaluation réaliste, les juges reçoivent un contexte agrégé au niveau du participant ( $Q_u$ ), qui concatène tous les journaux de invites (prompt logs) pour ce participant. Cela garantit que le juge dispose de l'historique complet des interactions de l'utilisateur lors de l'évaluation d'une tentative spécifique.
Contraintes de schéma : Les juges sont contraints de produire une sortie JSON structurée plutôt qu'un texte libre, contenant :
- $p_a$ : Probabilité prédite d'acceptation.
- $s_{algo}$ : Score ordinal (1-5) pour l'adéquation algorithmique.
- $s_{robust}$ : Score ordinal (1-5) pour la robustesse/satisfaction des contraintes.
- $r$ : Brève justification.

B. Pipeline d'inférence LLM-as-a-Judge

Évaluation multi-modèles : Quatre juges LLM distincts ont été évalués : OpenAI (gpt-5.2), DeepSeek (reasoner), Gemini (2.5-pro) et Claude (sonnet-4).
Vérification et réparation : Le pipeline inclut une étape de vérification robuste. Si un appel API échoue ou renvoie un JSON malformé, le système réessaie avec un délai d'attente (backoff). Seules les sorties satisfaisant des contraintes de schéma strictes (par exemple, probabilité dans [0,1], scores ordinaux valides) sont acceptées.
Stratégie de division : Une division groupée (Entraînement/Validation/Test) est appliquée au niveau (participant, problème).
- Validation : Utilisée pour sélectionner le seuil de décision optimal ( $t^*$ ) en maximisant le coefficient de corrélation de Matthews (MCC).
- Test : Utilisé exclusivement pour le rapport final afin de garantir l'absence de fuite de données.

C. Métriques d'évaluation

Le cadre emploie un protocole multi-métrique pour évaluer à la fois les juges et les dynamiques de co-création :

Métriques de qualité du juge :
- Discrimination : ROC-AUC et PR-AUC (capacité de classement).
- Fiabilité probabiliste : LogLoss, Score de Brier et Erreur d'étalonnage attendue (ECE).
- Qualité de décision : MCC utilisant le seuil sélectionné sur l'ensemble de validation.
- Accord inter-juges : $\kappa$ de Cohen (par paires) et $\kappa$ de Fleiss (multi-évaluateurs).
Métriques des dynamiques de co-création :
- Succès@Tour : Fraction cumulative des trajectoires résolues au tour $k$ .
- Temps jusqu'au succès : Analysé via une analyse de survie de Kaplan-Meier (gérant la censure à droite pour les trajectoires non résolues).
- Comportement de révision : Mesuré à l'aide de la distance d'édition normalisée (NED) pour les changements de surface et de CodeBLEU pour la similarité/convergence consciente du code.

3. Contributions clés

Cadre conscient de la fiabilité : Introduit un pipeline rigoureux pour l'évaluation par LLM incluant des sorties contraintes par un schéma, des mécanismes de réparation automatisés et une division groupée pour prévenir les fuites de trajectoires.
Suite d'évaluation multi-métrique : Va au-delà du rapport sur une seule métrique en analysant conjointement la discrimination, l'étalonnage, la qualité de décision et l'accord inter-juges.
Analyse au niveau des trajectoires : Fournit une méthode novatrice pour analyser les schémas d'interaction Humain-IA (courbes de lutte, analyse de survie) plutôt que de se limiter aux résultats finaux.
Pont empirique : Relie les domaines de la fiabilité des « LLM-as-a-Judge » et des dynamiques de « Co-création Humain-IA » au sein d'un seul cadre empirique reproductible.

4. Résultats clés

A. Performance des juges

Discrimination : DeepSeek et Claude ont obtenu le ROC-AUC le plus élevé (0,5937), DeepSeek étant en tête pour le PR-AUC (0,6904). Gemini a été le plus faible (ROC-AUC 0,4250).
Étalonnage : DeepSeek a montré le meilleur étalonnage (ECE le plus bas : 0,2819), tandis que Gemini et Claude ont présenté des erreurs plus élevées.
Qualité de décision : DeepSeek a obtenu le MCC seuillé le plus élevé sur l'ensemble de test (0,5000) avec un seuil conservateur (0,81).
Accord inter-juges : La cohérence était globalement modeste.
- $\kappa$ de Cohen moyen par paires : 0,1592.
- $\kappa$ de Fleiss : 0,0696.
- Implication : Les juges ne sont pas interchangeables ; ils présentent des biais et des forces distincts, renforçant la nécessité d'un rapport multi-métrique plutôt que de s'appuyer sur un seul modèle.

B. Dynamiques de co-création Humain-IA

Succès en tête de liste : Le succès est fortement concentré dans les premiers tours.
- Le Succès@Tour a atteint 0,8533 au premier tour observé.
- Au tour 6, il n'a augmenté que jusqu'à 0,8641.
- L'analyse de Kaplan-Meier confirme que les trajectoires s'étendant au-delà des premiers tours montrent des rendements décroissants.
Schémas de révision hétérogènes : Il n'existe pas un seul « style » de révision correct.
- Tanto la réfinition incrémentale (petits changements) que la restructuration large (grands changements) ont conduit à des résultats réussis.
- La similarité consciente du code (CodeBLEU) a montré que les trajectoires réussies tendent à converger structurellement vers la solution acceptée, indépendamment de l'ampleur des changements intermédiaires.
Dissimilarité Invite-Code : Des valeurs NED élevées entre les invites et le code ont confirmé que le contexte du juge (langage naturel) et la solution (code) sont lexicalement distincts, validant le caractère non trivial de la tâche d'évaluation.

5. Signification et implications

Au-delà de la correction finale : L'étude démontre que l'évaluation de la programmation assistée par l'IA nécessite d'examiner le processus (trajectoire), et non seulement le produit. Les schémas de succès précoces suggèrent que la co-création efficace repose sur une itération et une vérification rapides plutôt que sur des essais-erreurs prolongés.
Juges comme instruments, non comme oracles : Les résultats soulignent que les juges LLM sont des instruments de mesure avec des « angles morts » et des forces spécifiques. Aucune métrique unique (par exemple, la précision) ne capture leur utilité complète ; une vision multidimensionnelle est essentielle pour une recherche auditable.
L'expertise humaine reste centrale : Les résultats suggèrent que l'IA ne remplace pas le jugement humain mais le réoriente. La capacité à évaluer les sorties intermédiaires, à reconnaître la stagnation et à orienter les révisions reste la compétence humaine critique dans la co-création.
Reproductibilité : Le cadre proposé offre un modèle pour les études futures visant à évaluer la programmation assistée par l'IA avec transparence, garantissant que les protocoles d'évaluation sont robustes face aux fuites de données et aux biais spécifiques aux modèles.

En conclusion, cet article fournit une méthodologie fondamentale pour évaluer rigoureusement la façon dont les humains et l'IA collaborent pour résoudre des problèmes de programmation complexes, tout en établissant simultanément une norme consciente de la fiabilité pour l'utilisation des LLM comme juges dans de tels environnements dynamiques.