CelloAI Benchmarks: Toward Repeatable Evaluation of AI Assistants

Ce papier présente CelloAI, une suite de benchmarks reproductibles conçue pour évaluer de manière uniforme les performances des assistants IA dans la génération de code, la documentation et l'analyse de données pour les domaines spécifiques de la physique des hautes énergies et de l'informatique haute performance.

L'essentiel

Imaginez que vous êtes un chef cuisinier dans une cuisine ultra-sophistiquée (la physique des hautes énergies) où chaque ingrédient doit être mesuré au millimètre près. Vous avez embauché un nouvel assistant robotique très intelligent, capable de lire des millions de livres de recettes (les modèles d'IA comme les LLM). Le problème ? Cet assistant est excellent pour cuisiner des plats simples, mais il a tendance à faire des erreurs catastrophiques dans votre cuisine de haute précision : il oublie de noter les ingrédients, mélange les étiquettes, ou pire, il essaie de cuisiner un plat complexe sans comprendre comment les fourneaux fonctionnent.

Ce papier, intitulé "CelloAI Benchmarks", raconte l'histoire d'une équipe de chercheurs qui a décidé de ne pas se fier à la "confiance" ou aux impressions pour évaluer cet assistant. Au lieu de dire "il semble bien faire", ils ont construit un terrain de jeu de vérité (des benchmarks) pour tester rigoureusement si l'IA peut vraiment aider les scientifiques.

Voici les trois épreuves principales qu'ils ont créées, expliquées simplement :

1. L'Épreuve du "Carnet de Recettes" (Documentation de Code)

Le problème : Dans les grands projets scientifiques, le code est comme une vieille bibliothèque remplie de livres écrits par des centaines de personnes différentes. Souvent, les pages sont vides ou mal écrites. Si un nouveau scientifique arrive, il ne comprend rien.
Le test : L'IA doit agir comme un bibliothécaire modèle. On lui donne un bout de code (une fonction) et elle doit écrire une étiquette parfaite (un commentaire "Doxygen") qui explique exactement ce que fait le code, quels ingrédients (paramètres) il faut et quel plat (résultat) on obtient.
La découverte : Les robots sont très forts pour respecter la forme (ils écrivent les étiquettes aux bons endroits), mais ils sont parfois un peu bêtes sur le fond. Ils peuvent écrire "Ingrédient : Sel" alors qu'il faudrait dire "Sel de mer pour la conservation". Ils suivent le moule, mais manquent parfois de compréhension profonde de la science derrière.

2. L'Épreuve du "Traducteur de Cuisine" (Génération de Code)

Le problème : Imaginez que vous devez passer d'une cuisine à gaz (votre ancien code) à une cuisine électrique ultra-puissante (les nouveaux processeurs graphiques/GPU). C'est comme changer tout le système de plomberie d'une maison pendant qu'on y habite. Une petite erreur et tout s'effondre.
Le test : L'IA doit prendre un morceau de code complexe (un "noyau" de simulation) et le traduire pour qu'il fonctionne sur ces nouvelles machines, sans casser la physique ni ralentir le tout.
La découverte : C'est ici que ça coince le plus. Pour les tâches simples (comme "remettre le compteur à zéro"), l'IA réussit souvent. Mais pour les tâches complexes (comme "simuler une explosion de particules"), elle échoue presque toujours. Cela montre que l'IA ne peut pas encore faire confiance aveuglément pour les tâches critiques : elle a besoin d'un chef humain pour vérifier qu'elle n'a pas cassé la plomberie.

3. L'Épreuve du "Détective de Graphiques" (Analyse Visuelle)

Le problème : Les scientifiques passent leur temps à regarder des milliers de graphiques (des courbes qui montrent les résultats d'expériences). Ils doivent repérer une petite courbe qui ne va pas, comme un détective cherchant un indice dans une foule.
Le test : On montre à l'IA un graphique avec deux courbes (une normale, une bizarre) et on lui demande : "Où est l'erreur ?" et "Qu'est-ce qui a changé ?".
La découverte : Les IA capables de "voir" (vision par ordinateur) commencent à bien repérer les anomalies, mais elles ont encore du mal à expliquer pourquoi c'est une erreur. C'est comme si elles vous disaient "Regarde, il y a un point bizarre ici !" mais qu'elles ne savaient pas si c'était un bug ou une découverte scientifique.

La Conclusion de l'Histoire

L'objectif de ce papier n'est pas de dire "l'IA est nulle", mais de dire "arrêtons de deviner et commençons à mesurer".

Les chercheurs ont créé une règle du jeu claire :

• Répétabilité : On peut refaire le test 100 fois et obtenir le même résultat.
• Objectivité : Pas de "je pense que c'est bien", mais des scores précis (comme un examen de mathématiques).
• Contexte : On teste l'IA dans des conditions réelles de laboratoire, pas dans un vide artificiel.

En résumé, CelloAI est un outil qui aide l'IA à mieux comprendre le contexte (comme un livre de cuisine complet plutôt qu'une recette isolée), et ces nouveaux tests sont la règle à l'échelle pour s'assurer que l'IA ne va pas faire tomber la maison en ruine quand elle essaie d'aider les scientifiques à explorer l'univers. C'est une étape cruciale pour passer de l'IA "qui fait des blagues" à l'IA "qui fait de la science".

Résumé technique

1. Problématique

L'utilisation croissante des Modèles de Langage (LLM) pour le développement de logiciels se heurte à des limites spécifiques dans les domaines de la Physique des Hautes Énergies (HEP) et de l'Informatique de Haute Performance (HPC). Les benchmarks existants (comme SWE-bench ou LiveCodeBench) se concentrent sur des tâches de codage généralistes ou la résolution de problèmes isolés via des tests unitaires. Cependant, ils échouent à capturer les contraintes critiques des environnements scientifiques :

• Complexité des bases de code : Des dépôts massifs, mal documentés, avec des dépendances complexes et des systèmes de construction rigides.
• Contraintes scientifiques et de performance : La correction du code ne dépend pas seulement de la syntaxe, mais de la validité physique (stabilité numérique, intention scientifique) et de l'efficacité sur des architectures hétérogènes (CPU/GPU).
• Risque d'erreurs silencieuses : Des erreurs de traduction, de gestion des données ou de dépendances peuvent invalider des résultats scientifiques sans provoquer d'erreur de compilation immédiate.

Il existe donc un besoin urgent d'évaluations reproductibles, automatisées et spécifiques au domaine pour mesurer la fiabilité des assistants IA dans ces contextes.

2. Méthodologie

Les auteurs proposent CelloAI, un assistant de codage basé sur la récupération augmentée (RAG) et localisé, conçu pour les flux de travail scientifiques. L'article introduit un cadre d'évaluation basé sur trois pistes (tracks) principales, chacune dotée de métriques automatisées et de tâches reproductibles :

A. Documentation de Code (CelloAI-Doc-Bench)

• Objectif : Évaluer la capacité des LLM à générer des commentaires structurés de style Doxygen à partir de signatures de fonctions et de contextes locaux.
• Métriques :
  • Score de Couverture (F1) : Mesure la complétude structurelle (présence correcte des balises @param, @return) par rapport à une vérité terrain.
  • Similarité Sémantique :
    • Différentielle : Vérifie la cohérence des descriptions de paramètres entre les fonctions appelantes et appelées (pour détecter les incohérences sémantiques).
    • Expert : Compare les commentaires générés par l'IA avec ceux rédigés par des experts humains via des embeddings vectoriels (cosinus).

B. Génération et Portage de Code (CelloAI-Code-Bench)

• Objectif : Évaluer le portage de noyaux (kernels) GPU (CUDA) vers des environnements portables (OpenMP/SYCL) dans le cadre du projet FastCaloSim (simulation de calorimètre ATLAS).
• Tâches : Trois niveaux de complexité sont testés :
  1. Reset : Réinitialisation simple de tableaux (facile).
  2. Count : Identification d'opérations atomiques (modéré).
  3. Simulate : Calculs flottants lourds avec gestion de la mémoire et atomes (difficile).
• Évaluation : Une pipeline automatisée tente de compiler, d'exécuter et de valider le code généré. Le succès est binaire (échec ou réussite complète), privilégiant l'intégration et la validité scientifique plutôt que la simple génération de snippets.

C. Analyse de Données Graphiques (CelloAI-Multimodal-Bench)

• Objectif : Évaluer les LLM multimodaux (vision) capables d'analyser des histogrammes scientifiques pour détecter des anomalies.
• Tâche : Comparer un histogramme de référence et un histogramme surveillé (synthétique) pour identifier les points aberrants (outliers) et les zones de divergence.
• Métriques : Précision, Rappel et F1 pour la détection des points aberrants et l'identification des intervalles de divergence, en comparant les sorties JSON des modèles à la vérité terrain.

3. Résultats Clés

Documentation (Tableau I)

• Les modèles récents (ex: GPT-oss-120b, Qwen3) atteignent un rappel (recall) très élevé (1.0) et un F1 élevé (0.96) pour la couverture des balises, indiquant qu'ils incluent presque tous les paramètres requis.
• Cependant, la qualité sémantique reste limitée. Les scores de similarité avec les experts sont modérés (~0.60 pour les meilleurs modèles) et la similarité différentielle est faible, suggérant un manque de cohérence sémantique profonde.
• L'augmentation de la température ($\theta$) améliore légèrement la couverture mais dégrade la cohérence sémantique. L'ajout du contexte CelloAI apporte des gains marginaux sur ces métriques spécifiques.

Génération de Code (Tableau II)

• La difficulté est fortement corrélée à la complexité du noyau.
• Noyau 1 (Reset) : Les meilleurs modèles (GPT-oss-120b avec CelloAI) atteignent un taux de succès de 90-100%.
• Noyau 2 (Count) : Performance mitigée (jusqu'à 80% avec CelloAI).
• Noyau 3 (Simulate) : C'est le point de rupture. Même les meilleurs modèles ne réussissent que 1 à 2 fois sur 10 essais. Cela démontre que le portage de noyaux complexes avec contraintes physiques est encore hors de portée des modèles actuels sans fine-tuning ou aide humaine significative.
• L'utilisation du contexte enrichi de CelloAI (RAG, graphes d'appels) améliore significativement les résultats sur les noyaux simples et modérés par rapport à une récupération basique.

Analyse Graphique (Tableau III)

• Les performances globales sont modérées.
• Détection d'anomalies : Le modèle InternVL 3.5 obtient le meilleur score F1 (~0.57) pour la détection d'outliers à basse température, tandis que Gemma-3n échoue complètement.
• Identification de divergences : Les scores F1 oscillent autour de 0.30 à 0.60 selon les modèles et les températures.
• Cela indique que les modèles multimodaux actuels nécessitent un ajustement fin (fine-tuning) spécifique au domaine pour interpréter correctement les données scientifiques visuelles.

4. Contributions Principales

1. Cadre d'évaluation reproductible : Introduction d'une suite de benchmarks standardisés (CelloAI-Doc-Bench, CelloAI-Code-Bench, CelloAI-Multimodal-Bench) spécifiquement conçus pour les contraintes HEP/HPC.
2. Métriques hybrides : Combinaison de mesures structurelles (couverture de balises, compilation) et sémantiques (similarité vectorielle, validation scientifique) pour une évaluation plus nuancée que les simples tests unitaires.
3. Analyse des échecs : Identification claire des limites actuelles des LLM : excellente capacité à gérer la structure et la documentation basique, mais incapacité à garantir la correction scientifique et la complexité algorithmique des noyaux de simulation critiques.
4. Validation de l'approche RAG : Démonstration que l'enrichissement du contexte (graphes d'appels, découpage syntaxique) améliore la fiabilité du code généré, même si cela ne résout pas encore les problèmes de complexité extrême.

5. Signification et Perspectives

Ce travail marque une étape importante vers l'adoption fiable de l'IA dans le développement scientifique. Il démontre que les benchmarks généraux sont insuffisants pour évaluer les assistants de codage scientifique.

• Pour la communauté HEP/HPC : Ces benchmarks fournissent un outil pour comparer objectivement les modèles et les stratégies d'ingénierie de prompt, favorisant le développement d'outils adaptés aux contraintes de performance et de sécurité.
• Pour la recherche en IA : Il met en évidence le besoin de modèles spécialisés (fine-tuning sur du code scientifique) et de méthodes d'évaluation qui intègrent la validation physique et l'intégration système, plutôt que de se limiter à la génération de code isolé.
• Futur : Les auteurs prévoient d'étendre ces benchmarks à davantage de modèles, d'inclure des modèles fine-tunés et d'élargir la diversité des tâches pour mieux couvrir l'écosystème HEP.

En résumé, l'article propose une approche pragmatique pour transformer l'évaluation des LLM d'une mesure de "compétence générale" à une mesure de "fiabilité opérationnelle" dans des environnements scientifiques critiques.