Development of an LLM-Based System for Automatic Code Generation from HEP Publications

Cette étude présente un système de preuve de concept utilisant des modèles de langage de grande taille (LLM) pour extraire les procédures d'analyse des publications en physique des hautes énergies et générer automatiquement du code exécutable, démontrant leur potentiel en tant qu'outils d'assistance à la reproductibilité tout en soulignant les défis actuels liés à la fiabilité et aux hallucinations.

L'essentiel

🧪 Le Problème : La Cuisine de la Physique est de plus en plus Complexe

Imaginez que la physique des hautes énergies (HEP) soit une cuisine de restaurant étoilé très pointue. Pour reproduire un plat (un résultat scientifique), il faut suivre une recette précise écrite dans un livre (une publication scientifique).

Le problème ? Ces recettes sont devenues énormes et compliquées. Elles sont écrites dans un langage technique, dispersées sur plusieurs pages, et parfois, les ingrédients exacts sont cachés dans d'autres livres de cuisine cités en bas de page. Pour un nouvel apprenti (un étudiant), essayer de recopier cette recette à la main pour refaire le plat prend des mois et demande un talent de chef de cuisine (de programmeur) immense.

🤖 La Solution : Un Assistant de Cuisine Intelligent (IA)

Les chercheurs de l'article ont créé un assistant culinaire basé sur l'intelligence artificielle (un "Grand Modèle de Langage" ou LLM). L'objectif ? Lire la recette originale et écrire automatiquement le code informatique nécessaire pour cuisiner le plat exactement comme le chef l'a fait.

Mais attention, ils ne veulent pas que l'IA cuisine toute seule sans surveillance (ce serait trop dangereux !). Ils ont mis en place un système en deux étapes, un peu comme un chef et un stagiaire qui travaillent ensemble.

---

🛠️ Étape 1 : L'Enquêteur (Extraire la Recette)

Imaginez que l'IA est un détective très intelligent.

• La tâche : Elle doit lire le livre de recettes principal et tous les livres de référence cités pour trouver la liste exacte des ingrédients et des étapes (les "critères de sélection").
• Le défi : Parfois, la recette dit "suivez la méthode du livre B", et le livre B dit "voir le livre C". L'IA doit tout rassembler.
• Le résultat : Au lieu de donner un code brouillon, l'IA produit une liste structurée et lisible (comme une liste de courses bien organisée) avec des notes sur d'où vient chaque information.

Ce qu'ils ont découvert :
Les IA les plus grosses (comme un cerveau de 235 milliards de neurones) sont très bonnes pour trouver les informations. Mais, comme un détective qui a bu trop de café, elles sont imprévisibles. Parfois, elles inventent des ingrédients qui n'existent pas (ce qu'on appelle des "hallucinations") ou elles oublient une étape. C'est pour ça qu'un humain doit toujours vérifier la liste de courses avant de commencer.

---

💻 Étape 2 : Le Cuisinier (Écrire le Code)

Une fois la liste de courses validée, l'IA passe à l'étape suivante : elle devient le cuisinier qui écrit le code informatique.

• La tâche : Transformer la liste de courses en un programme informatique qui va trier les données (les événements de collision de particules) exactement comme le chef l'a fait.
• Le test : Ils ont pris un plat célèbre (l'analyse de la particule Higgs se désintégrant en 4 leptons) et ont demandé à l'IA de le reproduire.

Ce qu'ils ont découvert :

• Le succès : Parfois, l'IA réussit parfaitement ! Elle produit un code qui donne exactement le même résultat que le chef humain (3 fois sur 10 pour les meilleurs modèles).
• L'échec : Souvent, le code plante ou donne un résultat faux. Le pire ? Parfois le code "tourne" sans erreur, mais le plat final est raté (les événements sélectionnés sont différents). C'est comme si l'IA avait cuisiné un gâteau qui a l'air beau mais qui est cru à l'intérieur.

---

🤝 La Conclusion : L'IA est un Super Stagiaire, pas un Chef

Le message principal de l'article est simple :

L'IA n'est pas encore prête à être le Chef seul dans la cuisine.

Elle est trop sujette à l'erreur et à l'invention (stochasticité et hallucinations). Si on la laisse faire tout le travail, on risque de publier de fausses recettes scientifiques.

Cependant, elle est incroyable comme "Stagiaire de Génie" :

• Elle peut lire des centaines de pages en quelques secondes.
• Elle peut proposer un premier brouillon de code ou une première liste de critères.
• Le rôle de l'humain : Le physicien (le Chef) vérifie le travail de l'IA, corrige les erreurs et valide le résultat final.

🚀 L'Avenir

Les chercheurs espèrent que, dans le futur, cet outil aidera les physiciens à :

1. Gagner du temps (ne pas perdre des mois à coder).
2. Améliorer la qualité des articles : Si l'IA ne peut pas comprendre la recette, c'est que l'article original était mal écrit ! Cela forcera les scientifiques à être plus clairs.

En résumé : L'IA est un outil puissant pour aider les humains à reproduire la science, mais elle a encore besoin d'un humain vigilant pour tenir les rênes.

Résumé technique

Titre : Développement d'un système basé sur les LLM pour la génération automatique de code à partir de publications HEP

Auteurs : Masahiko Saito, Tomoe Kishimoto et Junichi Tanaka (ICEPP, Université de Tokyo ; KEK).

1. Problématique

L'analyse des données en physique des hautes énergies (HEP) devient de plus en plus complexe, nécessitant une expertise computationnelle importante et du temps pour configurer des environnements et écrire du code. Cela élève le seuil d'entrée pour les étudiants et les nouveaux venus. Bien que les modèles de langage (LLM) offrent un soutien puissant pour la programmation, leur utilisation pour l'analyse entièrement automatisée reste risquée en raison de la variabilité stochastique et des "hallucinations" (fausses informations). Le défi principal est de garantir la reproductibilité des résultats physiques tout en réduisant la charge de travail manuelle, sans sacrifier la fiabilité.

2. Méthodologie

Les auteurs ont développé un prototype de système (Proof-of-Concept) en deux étapes, utilisant des LLM à poids ouvert (open-weight) et des frameworks d'orchestration (LangChain, LangGraph). L'approche introduit une représentation intermédiaire lisible par l'homme pour éviter la génération de code "boîte noire".

• Étape 1 : Extraction de la sélection (Selection Extraction)

  • Objectif : Extraire les critères de sélection d'événements, les définitions d'objets et les informations pertinentes d'un article cible et de ses références citées.
  • Processus itératif : Un système de planification (Planner) détermine quelles références lire. Un chargeur (Loader) convertit les PDF en Markdown et isole le texte pertinent. Un lecteur (Reader) extrait les critères, et un module de fusion (Merger) intègre ces informations dans une liste structurée.
  • Gestion du contexte : Deux modes sont testés : "Bulk" (traitement du texte entier) et "Chunk" (traitement par segments) pour gérer les limites de fenêtre de contexte des modèles.
  • Sortie : Une liste structurée avec des commentaires et des références de provenance, servant de spécification vérifiable.

• Étape 2 : Génération de code (Code Generation)

  • Objectif : Générer du code d'analyse exécutable à partir de la liste structurée de l'Étape 1.
  • Processus itératif : Un générateur produit du code pour des sous-tâches. Un exécuteur (Executor) lance le code dans un conteneur isolé (Singularity) préconfiguré avec des outils HEP (ROOT, numpy, uproot). Un validateur (Validator) compare les résultats d'exécution et le code lui-même aux critères de réussite.
  • Boucle de rétroaction : Si l'exécution échoue ou si les résultats sont incorrects, le système génère du code corrigé jusqu'à ce que la reproduction soit réussie ou que le nombre d'essais soit épuisé.

3. Contributions Clés

• Workflow vérifiable : Contrairement aux approches de bout en bout, ce système sépare explicitement la compréhension du document et la génération de code, positionnant le LLM comme un collaborateur vérifiable plutôt qu'un agent autonome.
• Évaluation quantitative : Utilisation d'une analyse de référence ATLAS ($H \to ZZ^* \to 4\ell$) sur les données ouvertes (Open Data) 2015-2016 comme benchmark. Une implémentation manuelle sert de "vérité terrain" (ground truth) avec 27 critères de sélection identifiés.
• Évaluation séparée : Les auteurs évaluent distinctement la capacité des modèles à extraire l'information (Étape 1) et à générer du code fonctionnel (Étape 2), permettant d'identifier précisément les goulots d'étranglement.
• Focus sur les modèles Open-Weight : L'étude privilégie des modèles comme Qwen3 et GPT-OSS pour des raisons de confidentialité des données et de coût, tout en les comparant à des modèles commerciaux (Gemini).

4. Résultats

• Extraction de sélection (Étape 1) :
  • Les modèles de grande taille (≥ 30B paramètres, ex: Qwen3:235B, Gemini 2.5 Flash) ont réussi à extraire la plupart des 27 critères, parfois tous dans certaines exécutions.
  • Le modèle 4B a montré de mauvaises performances.
  • Limites : Une forte variabilité stochastique (différences entre les exécutions) et des hallucinations persistantes ont été observées, même pour les grands modèles. Le mode "Chunk" a augmenté le nombre de critères extraits pour les petits modèles mais a drastiquement augmenté le taux d'échec du workflow et les hallucinations.
• Génération de code (Étape 2) :
  • Sur 10 exécutions, les modèles les plus avancés (Qwen3-Coder-Next:80B et GPT-OSS:120B) ont atteint une correspondance exacte au niveau des événements avec la base de référence dans 30 % et 20 % des cas respectivement.
  • Le modèle 30B n'a obtenu aucune correspondance exacte.
  • Problèmes majeurs : Un taux élevé d'échecs d'exécution et de résultats "non correspondants" (le code s'exécute mais sélectionne les mauvais événements). Cela démontre que le succès de l'exécution ne garantit pas la justesse physique.

5. Signification et Perspectives

• Rôle du LLM : Les LLM actuels ne sont pas encore fiables en tant qu'agents d'analyse HEP entièrement autonomes. Cependant, ils sont très prometteurs en tant qu'outils humains-dans-la-boucle (human-in-the-loop). Ils peuvent accélérer le processus en suggérant du code et des critères, à condition qu'un physicien vérifie les états intermédiaires.
• Impact sur la reproductibilité : Ce système peut servir de cadre pour évaluer la qualité de la documentation des publications HEP. L'échec de la reproduction peut révéler des descriptions ambiguës ou manquantes dans les articles.
• Travaux futurs : Les auteurs prévoient d'intégrer la RAG (Retrieval-Augmented Generation) pour accéder aux connaissances spécifiques au domaine (API ROOT, définitions de variables), d'étendre les benchmarks à d'autres analyses, et de développer un cadre collaboratif capable d'identifier explicitement les ambiguïtés dans les procédures publiées.

En résumé, cette étude démontre la faisabilité technique d'automatiser la reproduction d'analyses HEP via les LLM, tout en soulignant que la rigueur humaine reste indispensable pour garantir la validité scientifique des résultats générés.