Résumé technique : Articuler les hypothèses dans les analyses scientifiques générées par l'IA via la décomposition de tâches

Énoncé du problème

L'intégration des grands modèles de langage (LLM) dans le calcul scientifique offre le potentiel d'automatiser la génération de code d'analyse exécutable à partir de spécifications en langage naturel. Cependant, cette capacité introduit des risques significatifs concernant la compréhensibilité et la reproductibilité des résultats scientifiques. Deux sources d'incertitude prédominent :

1. Ambiguïté de la spécification : Les requêtes en langage naturel manquent souvent des définitions procédurales strictes requises pour le calcul, laissant des aspects critiques (ex. : critères de sélection d'objets, unités d'agrégation, règles de dérivation) ouverts à l'interprétation.
2. Variabilité stochastique : Les LLM peuvent produire des codes différents, incomplets ou sémantiquement incorrects pour des prompts identiques.

Par conséquent, même si le code généré s'exécute sans erreur, il peut ne pas refléter la physique voulue par le chercheur. L'« exécutabilité » du code ne garantit pas que les hypothèses sous-jacentes, les définitions d'objets ou les chemins de calcul sont explicites ou corrects. Cela est particulièrement critique en physique des hautes énergies (HEP), où les résultats dépendent de définitions précises des collections de particules, des observables composites et des coupures de sélection.

Méthodologie : Un cadre multi-agents

Les auteurs proposent un cadre multi-agents qui décompose le flux de travail de l'analyse scientifique en étapes distinctes et auditables. Plutôt que de s'appuyer sur un seul prompt pour générer du code, le système orchestre des agents spécialisés pour gérer la génération de code, l'exécution, le traçage et la critique. Le flux de travail est conçu pour être agnostique au domaine, avec des packages interchangeables contenant les connaissances spécifiques au domaine.

Le flux de travail central se compose des étapes suivantes :

1. Initialisation du domaine : Un package de domaine (ex. : pour les données de l'LHC Olympics) fournit un profil de génération, un registre d'assistants, des politiques de sélection et des contextes de critique. Cela sépare la logique d'orchestration générale des ressources spécifiques au domaine.
2. Sélection d'assistants (Helpers) : Un agent dédié analyse la fiche de tâche de l'utilisateur et un registre de fonctions d'assistance prédéfinies (ex. : reconstruction cinématique, sélection d'objets) pour identifier les utilitaires les plus pertinents. Cette étape contraint la génération de code ultérieure, empêchant le modèle d'inventer des fonctions ou de mal utiliser les outils du domaine.
3. Génération de code : Un agent génère un script Python en utilisant la fiche de tâche enrichie (requête originale + assistants sélectionnés) et le profil de génération du domaine.
4. Exécution et réparation itérative : Le code généré est exécuté dans un bac à sable (sandbox). Si des erreurs surviennent, un agent Fixer tente de patcher le code en fonction des diagnostics d'exécution. Si les réparations échouent, un agent Regenerator produit une nouvelle implémentation.
5. Traçage de l'implémentation : Une fois le code exécutable obtenu, un agent Tracer reconstruit une « spécification telle qu'implémentée ». Il extrait les fragments de code correspondant à chaque élément de la fiche de tâche, les faisant correspondre aux définitions de variables, aux chaînes de dépendance et aux références de lignes sources. Cela crée une représentation structurée de ce que le code fait réellement, indépendamment du texte brut du code source.
6. Critique post-génération : Un agent Critique compare la fiche de tâche originale à la spécification reconstruite. Il identifie les décalages, les exigences manquantes, les hypothèses cachées ou les violations sémantiques (ex. : calculer un observable composite directement à partir de particules brutes au lieu d'un objet reconstruit).
7. Détection d'ambiguïté (Oracle Golden Axe) : Avant la génération de code, un module Oracle inspecte l'entrée en langage naturel de l'utilisateur pour détecter les ambiguïtés à haut risque. Il identifie les phrases qui pourraient mener à plusieurs implémentations valides (ex. : « jet de tête » vs « jet de tête après coupures ») et propose des questions de clarification à l'utilisateur, offrant des interprétations « Golden » (recommandées) et « Silver » (alternatives).

Contributions clés

1. Décomposition de tâche pour les petits modèles

Une conclusion centrale est que la décomposition de la tâche de génération permet à des LLM nettement plus petits d'exécuter des flux de travail scientifiques complexes. Alors que les approches précédentes (ex. : CoLLM) nécessitaient des modèles d'environ 70 milliards de paramètres pour des résultats fiables, ce cadre permet à des modèles aussi petits que 14 milliards de paramètres (ex. : Qwen2.5-14B, Qwen3-14B) de compléter avec succès l'ensemble du pipeline. Le Helper Selector est crucial ici, car il guide le générateur en injectant des utilitaires de domaine pertinents, réduisant ainsi la charge cognitive du modèle.

2. Reconstruction sémantique et traçage

L'introduction du module Tracer répond à la nature de « boîte noire » du code généré. En reconstruisant la spécification d'implémentation à partir du code, le cadre rend explicites les définitions des collections sélectionnées, des sélections d'événements et des quantités composées. Cela permet une comparaison sémantique entre l'intention de l'utilisateur et le comportement du code, plutôt qu'une simple vérification de syntaxe superficielle.

3. Résolution explicite de l'ambiguïté

Le module Golden Axe Oracle transfère la charge de la résolution de l'ambiguïté de l'IA vers le chercheur humain. En détectant les phrases ambiguës avant la génération de code et en présentant des interprétations alternatives, le système empêche le modèle de faire des hypothèses incorrectes de manière silencieuse.

4. Adaptabilité modulaire au domaine

Le cadre est conçu avec une interface fixe pour les actifs du domaine. Bien que l'implémentation actuelle se concentre sur la physique des hautes énergies (spécifiquement le format LHC Olympics), l'architecture permet une adaptation à d'autres domaines scientifiques en échangeant simplement le package de domaine (profil de génération, registre d'assistants, contexte de critique) sans modifier la logique d'orchestration centrale.

Résultats et validation

Le cadre a été validé sur cinq analyses représentatives de la physique des collisionneurs (ex. : $W^+W^-$, $t\bar{t}$, $H \to \gamma\gamma$) en utilisant le format d'événement de l'LHC Olympics.

• Stabilité de la sélection d'assistants (Helper Selection) : Le Helper Selector a considérablement amélioré la stabilité. Alors que les modèles 70B montraient une grande cohérence, les modèles 14B ont également atteint une sélection d'assistants fiable lorsqu'ils étaient guidés par le registre, là où les approches précédentes à agent unique échouaient avec des modèles de cette taille.
• Qualité du code et fidélité sémantique :
  • Le code généré par les modèles 14B était souvent « partiellement réussi », implémentant la logique de sélection de base mais échouant sur les observables composées complexes (ex. : calculer le $\Delta\phi$ entre un système de dijets vs des jets individuels).
  • L'étape de Critique a réussi à identifier ces décalages sémantiques, tels que l'application incorrecte des veto de $b$-jets (appliqués aux jets bruts plutôt qu'aux jets sélectionnés) ou l'ordre incorrect de remplissage des histogrammes.
• Détection d'ambiguïté :
  • Les modèles plus grands (72B) ont détecté plus d'ambiguïtés (28/30 possibles) que les modèles plus petits (14B ont détecté 13/30).
  • L'introduction de l'approche Oracle-templated (oraclet), qui restreint la recherche d'ambiguïté à des catégories spécifiques (Portée de la collection, Objet multi-parties, Temps de sortie), a considérablement amélioré les performances des petits modèles (ex. : des modèles 7B ont détecté 27/30 ambiguïtés utiles avec l'approche par gabarit).
• Raffinement de la fiche de tâche (Task Card) : L'étude a démontré que la définition explicite de la construction d'objets composites au sein de la fiche de tâche (plutement que de compter sur les conventions implicites du modèle) améliorait considérablement la stabilité et la cohérence de la génération lors de répétitions successives.

Signification et revendications

L'article affirme que la reproductibilité et la transparence dans la science générée par l'IA nécessitent plus qu'un simple code exécutable ; elles nécessitent un compte rendu explicite des hypothèses et des chemins de calcul utilisés.

• Changement de paradigme : Ce travail s'éloigne de l'idée de traiter la génération de code comme une étape d'inférence unique pour aller vers un processus structuré comportant de multiples points d'inspection.
• Accessibilité : En permettant l'utilisation de modèles 14B, le cadre rend l'analyse scientifique assistée par IA avancée accessible sur des ressources de calcul locales, réduisant la dépendance vis-à-vis de l'accès coûteux aux énormes modèles propriétaires.
• L'humain dans la boucle (Human-in-the-Loop) : Le cadre ne vise pas une autonomie totale. Au contraire, il positionne le LLM comme un outil qui génère des candidats, tandis que les agents Tracer et Critique, ainsi que l'Oracle, facilitent l'inspection et la vérification humaines. Les artefacts intermédiaires (listes d'assistants, spécifications reconstruites, rapports de critique) servent de registre de provenance, permettant aux chercheurs d'auditer précisément comment un résultat a été dérivé.

En conclusion, les auteurs soutiennent que cette approche multi-agents modulaire améliore la fiabilité des analyses scientifiques générées par les LLM en rendant explicites les hypothèses implicites et en permettant l'utilisation de modèles plus petits et plus accessibles sans sacrifier la rigueur requise pour la découverte scientifique.