Beyond Executable Models: The Pufibara Agent Harness and the Modelica Agent Workflow Benchmark for Physical System Modeling

Dans le monde de l'ingénierie, la construction d'un pont, d'un réseau électrique ou d'un système de chauffage exige plus que l'écriture d'un code que l'ordinateur peut lire. Cela exige que le modèle numérique se comporte exactement comme la chose physique réelle qu'il représente. Depuis des décennies, les ingénieurs utilisent un langage spécialisé appelé Modelica pour décrire ces systèmes complexes. Contrairement à la programmation standard, où un ordinateur suit une liste stricte d'instructions du haut vers le bas, Modelica fonctionne en énonçant des relations entre des quantités, comme la façon dont la pression est liée au débit ou dont la tension est liée au courant. L'ordinateur détermine ensuite l'ordre des opérations pour résoudre ces relations. Cette flexibilité est puissante, mais elle crée un problème unique pour l'intelligence artificielle. Une IA peut facilement écrire du code Modelica qui semble correct et qui s'exécute même sans planter, tout en décrivant un système physique qui viole les lois de la physique ou ne répond pas aux besoins spécifiques du projet. La machine a suivi les règles de syntaxe, mais elle est passée à côté de l'essence même de l'ingénierie.

Ce fossé entre un modèle qui fonctionne simplement et un modèle qui est véritablement correct est le défi central abordé par une nouvelle étude de chercheurs de la TU Dresden. L'équipe, dirigée par Wang Zizhe, a cherché à voir si les agents d'IA — des programmes capables de penser, d'agir et d'utiliser des outils — pouvaient être dignes de confiance pour réparer, construire et ajuster ces modèles de systèmes physiques de manière autonome. Ils ont découvert que, bien que les outils d'IA actuels soient capables de générer du code, ils perdent souvent de vue les objectifs d'ingénierie originaux lorsqu'ils effectuent des modifications, ou qu'ils s'appuient sur des résultats de tests provenant d'anciennes versions du modèle qui ne sont plus applicables. Pour résoudre cela, les chercheurs ont construit un nouveau système appelé Pufibara. Ce système agit comme un superviseur strict qui tient un enregistrement permanent de ce que le projet exige, garantissant que chaque fois que l'IA modifie le modèle, elle vérifie à nouveau la nouvelle version par rapport aux objectifs initiaux. Ils ont testé ce système contre un outil de codage par IA commercial de premier plan en utilisant une vaste collection de 232 tâches d'ingénierie différentes. Les résultats ont montré que le nouveau système résolvait non seulement plus de problèmes, mais qu'il le faisait en utilisant nettement moins de ressources informatiques, prouvant que la manière dont une IA est guidée est tout aussi importante que l'intelligence qu'elle utilise.

Les chercheurs ont abordé ce problème en reconnaissant que l'ingénierie physique est différente de l'écriture d'un programme informatique standard. Dans un projet logiciel typique, si un programme s'exécute sans erreur, il est souvent considéré comme un succès. En modélisation physique, un modèle peut s'exécuter parfaitement et être pourtant faux. Par exemple, une IA pourrait générer un modèle de pompe à eau qui compile et simule de manière fluide, mais si le modèle prédit que l'eau monte en pente douce sans pompe, il a échoué au test d'ingénierie. La difficulté fondamentale réside dans la nature itérative du travail. Lorsqu'un agent d'IA tente de corriger un modèle, il peut modifier un paramètre, lancer une simulation, observer un résultat, puis modifier un autre paramètre. Sans un système de mémoire soigneux, l'agent pourrait oublier que la première modification était nécessaire, ou il pourrait croire à tort qu'un résultat de simulation de l'ancienne version du modèle s'applique encore à la nouvelle. Cette confusion peut conduire l'agent à soumettre un modèle final qui semble bon en surface, mais qui ne répond pas aux exigences physiques spécifiques de la tâche.

Pour prévenir cela, l'équipe a conçu Pufibara avec une architecture spécifique qui traite les exigences d'ingénierie comme des obligations persistantes. Imaginez un chef de projet qui garde une liste de contrôle de chaque règle que le bâtiment doit respecter, de la résistance de l'acier au flux de l'air. Chaque fois que l'architecte effectue un changement, le gestionnaire vérifie la nouvelle conception par rapport à cette même liste, ignorant tout ancien résultat de test qui ne correspond plus à la conception actuelle. Pufibara fait exactement cela pour les agents d'IA. Il maintient un « registre » des exigences d'ingénierie qui reste actif tout au long du processus. Il lie chaque résultat de simulation directement à la version spécifique du modèle qui l'a produit. Si le modèle change, le système sait que les anciens résultats ne sont plus valides et force l'agent à réévaluer la nouvelle version. Crucialement, le système exige que l'agent prenne une décision explicite pour soumettre une réponse finale. L'IA ne peut pas simplement s'arrêter parce qu'elle est à court de temps ou parce que le code compile ; elle doit déclarer activement qu'elle a rassemblé suffisamment de preuves pour prouver que le modèle respecte toutes les règles d'ingénierie.

Pour tester si cette approche fonctionne réellement, les chercheurs avaient besoin d'une méthode de mesure de performance juste et réaliste. Ils ne pouvaient pas simplement utiliser des modèles publics existants, car une IA pourrait déjà les avoir vus lors de son entraînement et simplement mémoriser les réponses. Au lieu de cela, ils ont créé un nouveau benchmark appelé Modelica Agent Workflow Benchmark. Ils sont partis de modèles d'ingénierie réels et fonctionnels, puis ont introduit des défauts spécifiques, de nouvelles exigences de conception ou des cibles d'ajustement pour créer 232 défis uniques. Ces tâches allaient de la réparation de modèles défectueux à la construction de nouveaux modèles à partir de zéro, ainsi que l'ajustement de paramètres pour atteindre des objectifs de performance spécifiques. Le benchmark incluait un « évaluateur » caché qui agissait comme un juge indépendant. Ce juge ne voyait pas le processus de pensée interne de l'IA ni ses étapes intermédiaires ; il regardait uniquement le modèle final soumis par l'agent et vérifiait s'il passait un ensemble strict de tests physiques et comportementaux. Cela garantissait que l'IA était testée sur sa capacité à résoudre le problème, et non sur sa capacité à deviner à quoi ressemblait le test.

L'étude a comparé le nouveau système Pufibara à Claude Code, un assistant de codage par IA commercial bien connu, en utilisant deux modèles de langage de grande taille différents comme « cerveau » derrière l'agent. Les résultats étaient clairs et cohérents. À travers les 232 tâches, Pufibara a réussi à compléter plus de problèmes que l'outil commercial. En utilisant un cerveau d'IA spécifique, Pufibara a résolu 202 tâches alors que l'autre outil en a résolu 185. Avec un cerveau d'IA différent, Pufibara a de nouveau résolu 202 tâches contre 187 pour le concurrent. La différence était plus marquée dans les tâches nécessitant la construction d'un modèle à partir de zéro, où Pufibara a résolu nettement plus de problèmes que l'autre système. Au-delà de la résolution de plus de problèmes, Pufibara était également beaucoup plus efficace. Il a utilisé environ 76 % à 82 % de jetons informatiques en moins — les unités de base d'information que l'IA traite — et a terminé les tâches en beaucoup moins de temps, certaines exécutions prenant jusqu'à 58 % de temps en moins que le concurrent.

La découverte la plus importante était peut-être que Pufibara ne résolvait pas seulement plus de problèmes, mais qu'il résolvait les bons types de problèmes. Les chercheurs ont découvert que l'outil concurrent produisait souvent des modèles exécutables et passant les vérifications de base, mais échouant aux exigences physiques plus profondes. Dans un ensemble de tâches difficiles, l'outil commercial a soumis des modèles qui s'exécutaient sans erreur mais ne se comportaient pas correctement selon les règles d'ingénierie dans 21 cas sur 38. Pufibara n'a commis cette erreur que quatre fois. Cela suggère que l'outil commercial était souvent satisfait d'un modèle qui fonctionnait simplement, tandis que l'exigence stricte de Pufibara de lier les preuves à la version actuelle du modèle et de vérifier explicitement toutes les obligations d'ingénierie l'empêchait de soumettre des solutions défectueuses. L'étude montre que la structure du flux de travail de l'IA — la façon dont elle se souvient, vérifie et décide — est tout aussi critique que l'intelligence du modèle de langage lui-même.

Les implications de ce travail s'étendent au-delà d'un seul type de langage d'ingénierie. La recherche démontre que pour que l'IA soit véritablement utile dans des domaines complexes et réels comme la physique et l'ingénierie, elle ne peut pas être un simple générateur de code. Elle doit être un agent qui comprend la différence entre un programme qui s'exécute et un système qui est physiquement correct. En maintenant un enregistrement persistant des exigences et en forçant l'IA à revérifier son travail par rapport à ces exigences chaque fois qu'elle effectue un changement, le système garantit que le résultat final est digne de confiance. Les chercheurs notent que bien que leurs résultats soient solides, ils sont spécifiques aux tâches et aux conditions testées. Ils ne prétendent pas avoir résolu le problème de l'IA en ingénierie pour toujours, mais ils ont fourni un schéma directeur clair sur la façon de construire des systèmes d'IA moins susceptibles de commettre des erreurs dangereuses. À mesure que le domaine progresse, l'attention se portera probablement sur le test de ces méthodes sur des problèmes industriels encore plus complexes et sur l'exploration de leur fonctionnement avec différents types de modèles d'IA, afin de garantir que les outils du futur soient aussi fiables que les systèmes qu'ils sont destinés à construire.