OODEval: Evaluating Large Language Models on Object-Oriented Design

Ce papier présente OODEval, un benchmark manuel et des métriques unifiées pour évaluer les capacités de conception orientée objet de 29 grands modèles de langage, révélant qu'ils excellent en syntaxe mais peinent encore à égaler les meilleurs concepteurs humains sur le plan sémantique.

L'essentiel

Voici une explication simplifiée de l'article de recherche OODEval, imaginée comme une histoire pour le grand public.

🎨 Le Grand Défi : L'Architecte vs. Le Dessinateur

Imaginez que vous voulez construire une maison.

1. Le besoin (les exigences) : Vous dites à un architecte : "Je veux une maison avec 3 chambres, un grand salon et une cuisine ouverte."
2. Le plan (la conception) : L'architecte doit dessiner les plans détaillés : où sont les murs, comment les portes s'ouvrent, comment les chambres sont reliées au salon.

Dans le monde de l'informatique, c'est la même chose. On appelle cela la Conception Orientée Objet (OOD). C'est l'étape où l'on transforme une idée vague en un plan précis pour créer un logiciel.

Récemment, des intelligences artificielles très puissantes (les LLM, comme les modèles qui écrivent du texte) ont commencé à essayer de dessiner ces plans informatiques. Mais on ne savait pas vraiment si elles étaient de bons architectes ou si elles faisaient juste de jolies fausses promesses.

C'est là que l'équipe de chercheurs (Xiao et al.) intervient avec son projet OODEval.

---

🛠️ 1. La Boîte à Outils : OODEval (Le Terrain de Jeu)

Avant cette étude, c'était comme essayer de juger un footballeur sans terrain, sans ballon et sans arbitre. Il n'y avait pas de test standardisé.

Les chercheurs ont donc construit OODEval, un nouveau "terrain de jeu" :

• 50 Missions : Ils ont créé 50 petits scénarios, allant du très simple (une petite cabane) au très complexe (un gratte-ciel avec des ascenseurs et des tunnels).
• Le Format : Au lieu de simples dessins, ils demandent à l'IA de générer du code spécial (PlantUML) qui dessine automatiquement le plan.

🧑‍🎓 2. Le Juge Humain : OODEval-Human

Pour savoir si l'IA est bonne, il faut la comparer à quelqu'un de compétent.

• Les chercheurs ont pris 940 plans dessinés par de vrais étudiants (des futurs architectes logiciels) et les ont fait noter par des professeurs.
• Cela leur a permis de créer une "moyenne humaine". Maintenant, ils peuvent dire : "Est-ce que l'IA est aussi bonne qu'un étudiant moyen ?"

📏 3. La Règle Magique : CLUE (La Règle de Mesure)

Jusqu'ici, on mesurait les plans en comptant juste les mots communs (comme comparer deux listes de courses). Mais un plan peut avoir les mêmes mots mais être complètement faux structurellement.

Les chercheurs ont inventé CLUE, une règle de mesure intelligente :

• Elle ne regarde pas seulement si les mots sont les mêmes.
• Elle vérifie si la structure est bonne : Est-ce que la cuisine est bien reliée au salon ? Est-ce que la porte mène bien à l'extérieur ?
• Elle compare le plan de l'IA avec le plan "parfait" et donne une note de 0 à 100.

---

🔍 Ce qu'ils ont découvert (Les Résultats)

En testant 29 IA différentes (des modèles open-source, des géants comme GPT-4, des modèles spécialisés en code), voici ce qu'ils ont vu :

1. L'IA est un excellent dessinateur, mais un mauvais architecte 🎨🏗️

• Le code est parfait : Les IA écrivent le code sans erreur de syntaxe (pas de fautes de frappe). C'est comme si elles écrivaient un texte sans aucune faute d'orthographe.
• Le sens est faible : Mais quand on regarde le plan, il y a des problèmes. Souvent, l'IA oublie de mettre une porte, ou relie deux pièces qui ne devraient pas l'être. C'est comme un dessin magnifique où la salle de bain est connectée au toit !

2. Le niveau de l'IA vs. Les Étudiants 🆚

• La moyenne : L'IA moyenne est encore moins bonne que l'étudiant moyen. Elle fait trop d'erreurs de logique.
• Les champions : Cependant, les meilleures IA (comme Qwen3-Coder-30B) commencent à rattraper le niveau d'un étudiant moyen. Elles sont presque aussi bonnes que la moyenne des humains, mais elles ne peuvent pas encore égaler les meilleurs étudiants (les experts).

3. La taille compte, mais la spécialisation compte plus 📏

• Plus c'est gros, mieux c'est : Les modèles avec plus de "cerveau" (paramètres) fonctionnent généralement mieux.
• Spécialisation : Les modèles entraînés spécifiquement sur du code sont bien meilleurs que les modèles généralistes (qui parlent de tout). C'est comme comparer un architecte qui a lu tous les livres de construction à quelqu'un qui a juste lu des magazines de décoration.
• Le petit géant : Étonnamment, un petit modèle (Gemma3-4B) a battu un modèle très connu mais plus petit (GPT-4o-mini). Cela prouve qu'on n'a pas besoin d'un monstre pour faire du bon travail si le modèle est bien entraîné.

4. Les pièges des tâches complexes 🕸️

• Plus le plan est compliqué (beaucoup de pièces, beaucoup de liens entre elles), plus l'IA se trompe.
• Si la demande écrite est difficile à lire (texte compliqué), l'IA perd ses moyens.

---

💡 Pourquoi est-ce important pour nous ?

1. Pour les développeurs : On ne peut pas encore faire confiance aveuglément à l'IA pour concevoir un logiciel entier. Elle est un excellent assistant pour écrire du code, mais il faut un humain pour vérifier le plan global.
2. Pour les écoles : Les étudiants peuvent maintenant utiliser l'IA pour faire leurs devoirs de conception. Les professeurs doivent changer leur méthode d'évaluation (par exemple, demander aux étudiants d'expliquer leur raisonnement à l'oral) pour éviter la triche.
3. Pour l'avenir : Cette étude donne une feuille de route. Pour que l'IA devienne un vrai architecte logiciel, il faut l'entraîner à mieux comprendre les relations complexes et les méthodes, pas juste à copier des mots.

En résumé 🌟

L'IA est passée de "l'enfant qui dessine des bâtons" à "l'étudiant qui commence à comprendre les plans". Elle est rapide, elle ne fait pas de fautes de frappe, mais elle a encore du mal à comprendre la logique profonde de la construction. Avec les bons outils (comme OODEval et CLUE), nous savons enfin où elle se situe et comment l'aider à grandir.

Résumé technique

Voici un résumé technique détaillé de l'article "OODEval: Evaluating Large Language Models on Object-Oriented Design" en français.

1. Problématique

Bien que les modèles de langage à grande échelle (LLM) aient fait l'objet de nombreuses évaluations dans le domaine du génie logiciel, les études existantes se concentrent principalement sur la génération de code (niveau syntaxique) et la gestion de la qualité. Il existe un vide significatif concernant les capacités des LLMs dans la conception logicielle, et plus spécifiquement dans la conception orientée objet (OOD).

Les défis majeurs identifiés sont :

• L'absence de benchmarks standardisés pour les tâches de conception OOD (de la demande aux diagrammes de classes).
• Le manque de métriques d'évaluation automatiques capables de capturer à la fois la structure topologique et la sémantique des diagrammes de classes.
• La difficulté à comparer les performances des LLMs avec celles des humains (étudiants, experts) de manière objective.

2. Méthodologie

Pour combler ces lacunes, les auteurs ont développé un cadre d'évaluation complet composé de trois piliers principaux :

A. Le Benchmark OODEval

• Construction : Un ensemble de données manuellement construit contenant 50 tâches allant des exigences naturelles à la conception de diagrammes de classes.
• Diversité : Les tâches couvrent 10 domaines (services publics, finance, santé, etc.) et sont stratifiées en trois niveaux de difficulté (simple, modéré, difficile) basés sur le nombre de classes, d'attributs, de méthodes, de relations et la lisibilité des exigences.
• Format : Les données sont fournies sous forme de code PlantUML (pour l'évaluation automatique) et d'images PNG (pour l'inspection humaine).

B. Le Dataset OODEval-Human

• Objectif : Établir une référence humaine pour comparer les LLMs et valider les métriques automatiques.
• Contenu : 940 solutions soumises par des étudiants de premier cycle sur 4 tâches OOD, accompagnées des notes attribuées par des instructeurs.
• Traitement : Les diagrammes originaux (images) ont été convertis en code PlantUML via une combinaison de génération par LLM (GPT-4o) et de vérification manuelle rigoureuse pour assurer la fidélité sémantique.

C. La Métrique CLUE (Class Likeness Unified Evaluation)

• Concept : Une nouvelle métrique automatique qui évalue la similarité entre un diagramme candidat et un diagramme de référence.
• Fonctionnement :
  • Elle intègre des informations structurelles (classes, attributs, méthodes, relations) et sémantiques (utilisation de plongements vectoriels via CodeBERT pour gérer les synonymes et les noms différents mais sémantiquement équivalents).
  • Elle utilise l'algorithme de Hungarian pour trouver l'appariement optimal entre les éléments des deux diagrammes.
  • Elle calcule des scores globaux et locaux (clue-class, clue-attribute, clue-method, clue-relation).
• Validation : Les poids de la métrique ont été optimisés via une optimisation bayésienne pour maximiser la corrélation avec les notes humaines (coefficient de Pearson de 0,59).

D. Étude Empirique

• Modèles évalués : 29 LLMs variés (Open Source, Fermés, Code-spécialisés, Généraux, avec ou sans raisonnement, tailles de 3B à 70B de paramètres).
• Métriques d'évaluation :
  • Pass@1 : Pour la correction syntaxique (validité du code PlantUML).
  • CLUE : Pour la correction sémantique.
• Analyse : Étude de 5 questions de recherche (RQ) couvrant la justesse globale, la comparaison avec l'humain, l'analyse des dimensions des modèles, l'impact des caractéristiques des tâches et l'analyse des échecs.

3. Résultats Clés

• RQ1 (Justesse Globale) : Les LLMs excellent en correction syntaxique (Pass@1 > 80% pour la plupart), mais montrent des faiblesses significatives en correction sémantique. Les scores CLUE sont systématiquement inférieurs de plus de 10% aux scores syntaxiques. La génération de méthodes et de relations est particulièrement faible, surtout sur les tâches difficiles.
• RQ2 (Comparaison Humain) :
  • Les LLMs moyens sont nettement inférieurs aux étudiants moyens.
  • Cependant, les LLMs les plus performants (ex: Qwen3-Coder-30B) atteignent un niveau proche de la moyenne des étudiants, bien qu'ils restent loin des meilleurs étudiants humains (qui obtiennent des scores > 99%).
• RQ3 (Dimensions des Modèles) :
  • Taille des paramètres : Une taille plus grande améliore généralement les performances.
  • Spécialisation : Les modèles spécialisés en code (CodeLLM) surpassent les modèles généraux.
  • Instruction Tuning : Les modèles fine-tunés avec instructions surpassent systématiquement leurs versions de base.
  • Raisonnement : L'ajout de capacités de raisonnement (Chain-of-Thought) n'apporte pas d'avantage clair dans ce contexte spécifique.
• RQ4 (Caractéristiques des Tâches) : La performance chute avec l'augmentation du nombre de classes, de méthodes et de relations. La lisibilité des exigences (Flesch-Kincaid) impacte aussi la capacité à extraire les opérations.
• RQ5 (Analyse des Échecs) : Les erreurs sémantiques (86% des cas) dominent. Les erreurs courantes incluent les erreurs de mots-clés, les classes manquantes, les relations manquantes et les omissions de méthodes. Les modèles DeepSeek, GPT, Gemma3-IT et Qwen3-Coder-30B présentent la diversité d'erreurs la plus faible.

Performances des modèles :

• Meilleur modèle global : Qwen3-Coder-30B (local, open-source).
• Surprise : Gemma3-4B-IT (très petit modèle) surpasse GPT-4o-mini, montrant un fort potentiel pour des déploiements locaux contraints.
• Modèles locaux compétitifs : Llama3.1-70B-IT et Qwen3-Coder-30B rivalisent avec les modèles cloud fermés (GPT-4o, DeepSeek-R1).

4. Contributions Principales

1. OODEval : Le premier benchmark standardisé et public pour l'évaluation de la génération de diagrammes de classes OOD, couvrant 50 tâches multi-niveaux.
2. OODEval-Human : Le premier dataset de solutions humaines notées par des instructeurs (940 échantillons), permettant des comparaisons LLM-Humain et la validation de métriques.
3. CLUE Metrics : Une nouvelle suite de métriques automatiques intégrant structure et sémantique, fortement corrélée aux jugements humains.
4. Étude Empirique : La première évaluation systématique de 29 LLMs sur des tâches OOD, fournissant des insights sur les forces, faiblesses et facteurs d'influence.

5. Signification et Implications

• Pour la Recherche et le Développement : Les résultats indiquent que l'amélioration de la compréhension des relations et des méthodes est la priorité pour les futures générations de LLMs. L'utilisation de modèles spécialisés en code et le fine-tuning sont essentiels.
• Pour le Déploiement : Les modèles locaux open-source (Qwen3-Coder-30B, Gemma3-IT) sont viables pour des tâches de conception assistée par IA, offrant un compromis coût/performance intéressant.
• Pour l'Éducation : Les LLMs atteignant le niveau moyen des étudiants posent un défi pour l'intégrité académique. Les éducateurs doivent adapter leurs méthodes d'évaluation (privilégier les processus, les démos orales) et enseigner une utilisation responsable de l'IA.
• Pour les Benchmarks Futurs : Il est nécessaire d'inclure des tâches plus complexes avec plus de relations de généralisation et de méthodes pour mieux tester les limites des modèles.

En conclusion, cette étude établit un cadre rigoureux pour évaluer les LLMs dans la conception logicielle, révélant qu'ils sont devenus des assistants puissants mais qu'ils manquent encore de la profondeur sémantique et de la précision des experts humains.