Evaluating LLMs in the Context of a Functional Programming Course: A Comprehensive Study

Cette étude évalue neuf modèles de langage de pointe dans le contexte d'un cours de programmation fonctionnelle en OCaml, une langue à faible ressources, en utilisant trois nouveaux benchmarks ($\lambda$CodeGen, $\lambda$Repair et $\lambda$Explain) pour démontrer que, bien que ces modèles soient efficaces pour corriger les erreurs et répondre à des questions conceptuelles, ils résolvent moins de problèmes de devoirs que dans des langues à haute ressources comme Python ou Java.

L'essentiel

Voici une explication de cette recherche, imagée et simplifiée, comme si nous en discutions autour d'un café.

🎓 Le Grand Test : Les IA face au "Langage des Sorciers"

Imaginez que vous apprenez à cuisiner. La plupart des études sur les intelligences artificielles (IA) comme ChatGPT se sont concentrées sur des plats très populaires et faciles à trouver, comme la pizza ou les pâtes (les langages de programmation Python et Java). Tout le monde sait les faire, et les IA sont devenues de très bons chefs pour ces plats-là.

Mais cette étude, menée par des chercheurs de McGill et de l'Université de Toronto, a décidé de tester ces mêmes IA sur un plat beaucoup plus rare et complexe : l'OCaml.

L'OCaml, c'est comme un plat de "sorcier" ou une cuisine moléculaire très pointue (un langage de programmation fonctionnel). C'est un langage utilisé dans les cours avancés d'informatique, où la logique est très stricte et où il n'y a pas beaucoup de recettes disponibles sur Internet pour aider l'IA à apprendre.

🛠️ Les Trois Épreuves du Championnat

Pour voir si ces IA étaient vraiment douées, les chercheurs ont créé trois épreuves spéciales, comme un concours de cuisine en trois manches :

1. Le Défi de la Création (λCodeGen) :

   • L'épreuve : On donne à l'IA une recette écrite en langage humain ("Fais-moi un programme qui trie des listes") et elle doit écrire le code complet.
   • Le résultat : C'est la partie la plus difficile. Même les meilleures IA (comme GPT-4o ou o3-mini) ont obtenu une note de B (très bien, mais pas parfait). Elles réussissent environ 70 % du temps, mais elles font souvent des erreurs de logique ou oublient des règles strictes du langage. C'est comme si un chef cuisinait un plat délicieux, mais qu'il avait oublié d'ajouter le sel ou avait utilisé un ingrédient interdit.

2. Le Défi de la Réparation (λRepair) :

   • L'épreuve : On donne à l'IA un plat brûlé ou raté (un code avec des erreurs) et on lui dit : "Répare ça !". Les erreurs peuvent être de trois types :
     • Syntaxe : Une faute de frappe (comme écrire "pâtes" au lieu de "pates").
     • Type : Un ingrédient incompatible (essayer de mettre du chocolat dans une soupe salée).
     • Logique : Le plat est beau, mais il est immangeable (le code fonctionne mais ne fait pas ce qu'on veut).
   • Le résultat : C'est là que les IA brillent le plus ! Elles sont excellentes pour corriger les fautes de frappe et les erreurs de "type" (comme un correcteur orthographique très intelligent). Elles réussissent plus de 80 % du temps. Cependant, quand il faut comprendre la logique profonde (pourquoi le plat ne fonctionne pas), elles commencent à hésiter.

3. Le Défi de l'Explication (λExplain) :

   • L'épreuve : On demande à l'IA d'expliquer un concept théorique complexe (comme "Comment fonctionne la substitution de variables ?").
   • Le résultat : C'est un piège. Les IA sont très bavardes. Elles peuvent donner une explication qui semble très intelligente et bien structurée, mais qui contient parfois des erreurs subtiles. C'est comme un élève qui rédige une dissertation magnifique avec un vocabulaire riche, mais qui a mal compris la question au fond. Pour un étudiant, c'est dangereux car on a tendance à faire confiance à l'IA sans vérifier.

🏆 Les Résultats en Bref

• Les Champions : Les modèles les plus avancés (comme o3-mini, Claude 3.7 Sonnet et GPT-4o) sont devenus de très bons assistants. Ils sont capables de vous aider à apprendre, de corriger vos erreurs et d'expliquer des concepts.
• Les Limites : Ils ne sont pas encore des "maîtres sorciers". Ils échouent souvent sur les tâches les plus abstraites et complexes. De plus, les modèles gratuits ou plus petits (comme Llama 8B) sont souvent perdus dans ce langage difficile, produisant du code qui ne fonctionne pas du tout.
• Le Comparatif : Une IA générale (qui sait tout faire un peu) fonctionne souvent mieux qu'un outil spécialisé conçu uniquement pour l'OCaml, car l'outil spécialisé est trop rigide.

💡 La Leçon pour les Étudiants et les Professeurs

Cette étude nous donne une leçon importante, comparable à l'apprentissage de la conduite :

L'IA est un excellent copilote, mais pas un chauffeur autonome.

• Pour les étudiants : Ne faites pas confiance aveuglément à l'IA. Si elle vous donne une solution, vérifiez-la. Parfois, elle vous donne une réponse qui semble parfaite mais qui est fausse. C'est un outil formidable pour apprendre, mais il faut garder son esprit critique.
• Pour les professeurs : Il faut changer la façon d'évaluer. Au lieu de demander aux élèves de simplement "écrire du code" (ce que l'IA peut faire), demandez-leur de corriger du code, de critiquer les solutions de l'IA, ou d'expliquer pourquoi une solution est bonne ou mauvaise.

En Résumé

Cette recherche nous dit que les IA ont fait un bond de géant. Elles sont devenues de véritables aides pour apprendre des langages de programmation difficiles comme l'OCaml. Mais elles ne sont pas infaillibles. Elles sont comme des étudiants brillants qui ont lu beaucoup de livres mais qui n'ont pas encore assez d'expérience pratique pour ne jamais se tromper.

Le mot de la fin ? Utilisez-les avec intelligence, vérifiez toujours leurs travaux, et gardez votre propre cerveau en éveil ! 🧠✨

Résumé technique

1. Problématique et Contexte

Les modèles de langage larges (LLM) transforment l'apprentissage des sciences informatiques, mais leur efficacité est principalement documentée sur des langages à haute ressource (Python, Java) et dans des cours d'introduction. Peu d'études se sont penchées sur leur performance dans des langages à faible ressource comme OCaml, et ce, dans le cadre de cours de programmation fonctionnelle de niveau intermédiaire (2e année).

Les auteurs identifient plusieurs lacunes dans la littérature existante :

• La plupart des benchmarks (HumanEval, MBPP) se concentrent sur la génération de code simple et ne capturent pas la complexité des tâches fonctionnelles avancées (continuations, sémantique opérationnelle, inférence de types).
• Les évaluations se limitent souvent à la correction binaire (pass/fail) via des tests automatisés, négligeant la qualité algorithmique, la lisibilité et la concision des réponses.
• Il existe un risque élevé de dépendance des étudiants à des solutions générées par LLM qui peuvent être incorrectes ou trop verbeuses, sans que les étudiants ne possèdent les compétences pour les critiquer.

L'objectif de l'article est d'évaluer systématiquement la capacité de 9 LLMs d'état de l'art à résoudre, réparer et expliquer des problèmes de programmation fonctionnelle en OCaml.

2. Méthodologie

Les auteurs ont conçu trois benchmarks spécifiques basés sur des données réelles d'un cours de programmation fonctionnelle à l'Université McGill (automne 2022 et 2024).

A. Les Benchmarks

1. $\lambda$CodeGen (Génération de code) :
   • Contenu : 10 devoirs contenant 53 tâches de programmation, allant des concepts de base (correspondance de motifs, récursivité) aux techniques avancées (continuations, streams, sémantique de langages).
   • Spécificité : Contrairement aux benchmarks standards (moyenne de 11 lignes de code), ces tâches sont multi-étapes et complexes.
2. $\lambda$Repair (Réparation de code) :
   • Contenu : 150 programmes défectueux extraits de soumissions réelles d'étudiants.
   • Catégories : 50 erreurs de syntaxe, 50 erreurs de type, 50 erreurs logiques.
   • Approche : Évaluation en zero-shot (sans exemples) et one-shot (avec un exemple) pour la réparation logique.
3. $\lambda$Explain (Explication conceptuelle) :
   • Contenu : 50 questions théoriques issues d'examens et de préparations (portée des variables, preuves par induction, évaluation, substitution).
   • Objectif : Évaluer la capacité à expliquer des concepts sans exécution de code.

B. Modèles Évalués

Neuf modèles d'état de l'art ont été testés, incluant des modèles propriétaires (GPT-4o, o3-mini, Claude 3.7 Sonnet, Gemini 2.0 Flash) et des modèles open-source (Llama 3.1/3.3, Qwen2.5).

C. Évaluation et Notation

L'évaluation combine une notation automatisée et manuelle rigoureuse :

• Automatisée : Utilisation du compilateur OCaml et d'un autograder pour vérifier la correction syntaxique et le passage aux tests.
• Manuelle : Deux assistants d'enseignement expérimentés ont noté les réponses selon trois critères hiérarchiques :
  1. Correction (respect des spécifications, passage des tests).
  2. Conception de l'algorithme (utilisation des HOFs, récursivité terminale, interdiction de certaines bibliothèques).
  3. Lisibilité (concision, absence de code redondant).
• Échelle de notation : Les réponses sont classées en Mastery (Maîtrise), Proficient, Developing, Beginning, ou Non-gradable. Une conversion en lettre (A à F) est appliquée.

3. Résultats Clés

A. Génération de Code ($\lambda$CodeGen)

• Les trois meilleurs modèles (o3-mini, Claude 3.7 Sonnet, GPT-4o) atteignent un taux de Mastery d'environ 70-74 %, obtenant une note globale de B+.
• Ces performances sont nettement inférieures à celles observées sur des benchmarks Python/Java (souvent >90 %), soulignant la difficulté du langage OCaml et de la complexité des tâches.
• Les modèles plus petits (Llama 3.1 8B, Qwen2.5 7B) obtiennent des notes de F, avec plus de 50 % de réponses Non-gradable (code ne compilant pas).
• Comparé à l'outil spécialisé BURST (synthèse de code OCaml), les LLMs surpassent largement ce dernier (BURST : 11,3 % de succès vs LLMs >69 %), bien que BURST soit plus fiable sur des tâches très spécifiques et bien définies.

B. Réparation de Code ($\lambda$Repair)

• Erreurs de syntaxe : Les modèles leaders atteignent >78 % de Mastery. Les LLMs sont compétitifs avec des outils spécialisés comme SYNSHINE.
• Erreurs de type : La performance reste élevée pour les modèles leaders (72-83 %), mais chute pour les modèles open-source, suggérant un manque de raisonnement de type profond dans leur entraînement.
• Erreurs logiques : C'est la tâche la plus difficile. Les modèles leaders atteignent ~60-72 % de Mastery, tandis que les modèles inférieurs chutent en dessous de 45 %.
• Apprentissage One-shot : L'ajout d'un seul exemple améliore légèrement les performances (surtout pour les modèles plus faibles), réduisant les réponses non gradables.

C. Explication Conceptuelle ($\lambda$Explain)

• Les modèles leaders (o3-mini, Claude 3.7 Sonnet) excellent ici, atteignant des notes de A- à A (taux de Mastery >60-80 %).
• Cependant, même les meilleurs modèles souffrent de verbeux excessif et d'explications parfois imprécises sur des concepts théoriques complexes (inférence de types, substitution).
• Les modèles plus petits montrent un écart de performance significatif (Llama 3.1 8B : 16,8 % de Mastery).

D. Impact de la Difficulté

• Les modèles performent mieux sur les tâches de base que sur les tâches avancées (continuations, sémantique formelle).
• L'écart de performance s'élargit considérablement sur les questions de théorie des langages de programmation (PT), où les modèles échouent souvent à combiner des étapes de raisonnement correctes en une réponse finale cohérente.

4. Contributions Principales

1. Création de Benchmarks Spécifiques : Introduction de $\lambda$CodeGen, $\lambda$Repair et $\lambda$Explain, adaptés aux défis de la programmation fonctionnelle et basés sur des données réelles d'étudiants.
2. Méthodologie d'Évaluation Holistique : Combinaison de l'évaluation automatisée (compilateur) et manuelle (qualité algorithmique, lisibilité), dépassant la simple métrique de "passage des tests".
3. Analyse Comparative Large : Évaluation de 9 modèles d'état de l'art, incluant une comparaison avec des outils de synthèse de code spécifiques (BURST).
4. Insights Éducatifs : Identification claire des forces (réparation de syntaxe, explications de base) et des faiblesses (génération de code complexe, raisonnement logique profond) des LLMs dans un contexte éducatif.

5. Signification et Implications

• Pour les Étudiants : Les résultats soulignent la nécessité de développer un esprit critique. Les LLMs ne sont pas fiables à 100 % pour les tâches complexes de programmation fonctionnelle. Une dépendance aveugle peut conduire à l'apprentissage de concepts erronés.
• Pour les Enseignants : Les benchmarks offrent un outil pour sensibiliser les étudiants aux limites des IA. Les évaluations devraient évoluer vers la critique, le débogage et la vérification de solutions générées par IA plutôt que vers la simple écriture de code.
• Pour la Communauté PL (Langages de Programmation) : Bien que les LLMs généralistes surpassent les outils spécialisés actuels pour OCaml, ils peinent sur les concepts théoriques profonds. Cela ouvre la voie à la recherche sur l'intégration de raisonnements spécifiques au domaine (domain-specific reasoning) dans les LLMs et le développement d'outils de synthèse plus puissants pour les langages à faible ressource.

En conclusion, bien que les LLMs les plus avancés soient des outils puissants pour l'apprentissage de la programmation fonctionnelle, ils ne sont pas encore des assistants parfaits. Leur utilisation doit être encadrée, et leur capacité à gérer la complexité théorique et logique reste un défi majeur.