🤖 machine learning

When the Next Step Is Not One Step: Distribution-Aware Execution Modeling for Concurrent Go Programs

Cet article introduit une approche de modélisation d'exécution sensible à la distribution pour les programmes Go concurrents qui exploite le non-déterminisme de l'ordonnanceur pour affiner un modèle de 7B sur des distributions d'événements empiriques, atteignant une précision de pointe et une meilleure calibration sur les prédictions de bogues en conditions réelles, tout en fournissant des garanties formelles pour la détection de fuites de goroutines spécifiques.

Auteurs originaux : Kaviru Hapuarachchi

Publié 2026-06-17

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Kaviru Hapuarachchi

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous essayez d'apprendre à un robot à prédire le prochain coup dans une partie d'échecs. Si c'est une partie d'échecs standard, les règles sont fixes : si vous déplacez un pion ici, l'adversaire doit répondre d'une manière spécifique. Le robot n'a qu'à mémoriser le schéma.

Mais maintenant, imaginez une partie d'échecs jouée dans une pièce chaotique et bruyante où trois personnes différentes essaient toutes de déplacer les pièces en même temps, et où un vent aléatoire fait bouger l'échiquier. Parfois, si vous déplacez un pion, le vent peut le renverser. Parfois, un joueur peut saisir une pièce avant que vous ne puissiez le faire. Parfois, l'adversaire peut décider de déplacer une pièce totalement différente.

C'est le problème des programmes informatiques qui exécutent plusieurs tâches à la fois (les programmes concurrents).

Le document que vous avez fourni s'attaque précisément à ce chaos. Voici la décomposition en termes simples :

Le Problème : « Une seule réponse » contre « Plusieurs réponses possibles »

Dans l'informatique traditionnelle, lorsqu'un programme s'exécute, nous supposons généralement qu'il suit une ligne droite. Si vous lui donnez la même entrée, il donne la même sortie.

L'ancienne méthode : Les chercheurs entraînaient des modèles d'IA à prédire l'étape suivante unique qu'un programme allait prendre. Ils traitaient le programme comme une ligne droite.
La réalité : Dans les programmes concurrents (comme ceux écrits en langage Go), l'« ordonnanceur » (la partie de l'ordinateur qui décide quelle tâche s'exécute et quand) est comme un arbitre chaotique. Si vous exécutez le même programme deux fois, il peut faire A puis B, ou B puis A. Les deux sont corrects. Les deux sont valides.

Si vous entraînez une IA à deviner juste une réponse pour une situation où il y a en réalité trois réponses valides, l'IA s'embrouille. C'est comme demander à un prévisionneur météo de prédire « Il va pleuvoir » alors que la réalité est « Il se peut qu'il pleuve, qu'il neige ou qu'il fasse beau », et l'IA choisit simplement une option et espère que ça marche.

La Solution : Prédire la « Prévision Météo »

Les auteurs ont réalisé qu'ils ne devaient pas traiter le chaos comme une erreur. Au lieu de cela, ils ont traité le chaos comme une donnée.

Exécuter de nombreuses fois : Ils ont pris un programme et l'ont exécuté des centaines de fois.
Compter les résultats : Ils ont remarqué que bien que l'ordre changeait, certains schémas émergeaient. Par exemple, « l'Événement A » se produisait 60 % du temps, « l'Événement B » 30 % du temps et « l'Événement C » 10 % du temps.
Enseigner la distribution à l'IA : Au lieu d'enseigner à l'IA à deviner « l'Événement A », ils lui ont appris à deviner toute la prévision : « Il y a 60 % de chances pour A, 30 % pour B et 10 % pour C. »

Ils ont utilisé un truc mathématique spécial (appelé « objectif KL ») pour entraîner un modèle d'IA de 7 milliards de paramètres à correspondre à ces pourcentages du monde réel plutôt qu'à simplement deviner un seul vainqueur.

Les Résultats : Est-ce que ça a fonctionné ?

Ils ont testé cela sur du code réel et complexe provenant de systèmes célèbres comme Kubernetes et le gRPC de Google.

L'IA vs les Experts : L'IA affinée (entraînée sur moins de 1 000 exemples) a trouvé l'étape suivante correctement 36,2 % du temps.
La Compétition : Cela a battu une IA très puissante et pré-entraînée (Gemini 3.5 Flash) qui n'avait pas été entraînée sur ce type spécifique de problème (qui n'a réussi que 34,8 %).
Le gain de « Calibration » : Plus important encore, la nouvelle IA était meilleure pour savoir quand elle n'était pas sûre. Si la situation était chaotique, l'IA disait : « Je ne suis pas sûr, cela pourrait être n'importe quoi. » Si la situation était prévisible, elle disait : « Je suis assez sûr. » L'ancienne méthode d'entraînement rendait l'IA plus souvent sûre d'elle de manière erronée.

Les Limites : Où se trouve le plafond ?

Le document est très honnête sur ce que l'IA ne peut pas encore faire :

Le plafond de précision : L'IA plafonne autour de 35–36 % de précision. Elle ne peut pas monter beaucoup plus haut car certains événements sont si rares (comme un type spécifique de bug) que l'IA ne les voit jamais assez souvent pour les apprendre.
Le problème de « l'étape unique » : L'IA est excellente pour prédire le prochain mouvement immédiat. Mais si vous lui demandez de prédire les 10 prochains mouvements à la suite, elle s'effondre après environ une étape. C'est comme une personne qui peut vous dire ce qui se passe dans la seconde suivante d'un film, mais si vous lui demandez de prédire toute l'intrigue, elle commence à inventer n'importe quoi.

La découverte de la « Fuite »

Les auteurs ont également découvert une « signature » spécifique pour un type de bug informatique appelé « fuite de goroutine » (lorsqu'une tâche reste bloquée et ne se termine jamais).

Ils ont prouvé mathématiquement que si une tâche est bloquée dans un certain type de boucle d'attente, la probabilité qu'elle se « réveille » un jour est de zéro.
Ce n'est pas quelque chose que l'IA a appris en devinant ; c'est une règle de l'univers (les règles du langage de programmation Go). L'IA a correctement appris que « Se réveiller » est impossible dans ce scénario spécifique, ce qui est un bon signe montrant qu'elle comprend la logique, et non qu'elle se contente de mémoriser des chiffres.

Résumé

Le document conclut : « Arrêtez d'essayer de forcer un système chaotique et à voies multiples dans une seule ligne droite. À la place, montrez à l'IA toute la carte des possibilités. Ce ne sera pas parfait, et elle ne peut pas encore prédire de longues chaînes d'événements, mais elle devient bien meilleure pour comprendre la nature du chaos et savoir quand elle est en train de deviner. »

Ils ont publié leur code, leurs données et leurs outils afin que d'autres puissent essayer de construire sur cette approche « consciente du chaos ».

Résumé Technique : Modélisation d'Exécution Sensible à la Distribution pour les Programmes Go Concurrents

Énoncé du Problème
Entraîner des modèles de langage à prédire l'étape suivante d'un programme concurrent est fondamentalement différent de l'exécution séquentielle en raison du nondéterminisme de l'ordonnanceur (scheduler). Dans une exécution séquentielle, un état et une instruction spécifiques produisent un état suivant unique et déterministe. En revanche, dans les programmes Go concurrents, le même préfixe d'exécution peut légitimement conduire à plusieurs événements suivants différents (par exemple, un blocage, un démarrage ou un déblocage) selon la manière dont l'ordonnanceur entrelace les goroutines.

Les modèles de monde de code (CWM) standards, entraînés avec une perte d'entropie croisée, supposent un label correct unique par entrée. Lorsqu'ils sont appliqués à des traces concurrentes, cela force le modèle à mémoriser le résultat arbitraire d'un processus aléatoire, échouant ainsi à capturer la dynamique sous-jacente. Cette limitation est critique car les bugs de concurrence (deadlocks, data races, fuites de goroutines) sont intrinsèquement dépendants de l'ordonnancement et ne possèdent pas d'analogues séquentiels. Les benchmarks et modèles existants échouent souvent à traiter ce nondéterminisme, le traitant comme du bruit plutôt que comme une propriété structurelle de l'exécution.

Méthodologie
Les auteurs proposent de reformuler la prédiction du prochain événement comme une estimation de distribution plutôt que comme une prédiction ponctuelle. Au lieu d'entraîner un modèle pour deviner un seul événement suivant, l'approche agrège les événements suivants observés lors de multiples exécutions du même programme pour former une distribution empirique.

Collecte de Données : L'étude utilise 130 programmes Go concurrents, incluant des motifs créés à la main, du code synthétisé et 66 noyaux de bugs de concurrence réels provenant de systèmes de production (CockroachDB, Kubernetes, gRPC, etcd). Chaque programme est exécuté cinq fois sous un traceur de runtime pour capturer les événements de l'ordonnanceur.
Définition de la Cible : Pour un préfixe de programme donné, la cible n'est pas un label unique mais une distribution empirique $\hat{p}_g$ sur six types d'événements : GoBlock, GoCreate, GoEnd, GoSched, GoStart, et GoUnblock. Cette distribution est dérivée de la fréquence des événements suivants observés à travers les exécutions répétées.
Entraînement du Modèle : Les auteurs affinent un modèle de 7 milliards de paramètres (Qwen2.5-Coder) en utilisant deux objectifs :
1. Entropie Croisée (CE) : Une ligne de base où les exemples sont dupliqués proportionnellement à la fréquence des événements pour approximer la distribution.
2. Divergence KL (KL) : Un objectif sensible à la distribution qui minimise la divergence de Kullback-Leibler entre la distribution prédite par le modèle et la cible empirique. Le terme KL est appliqué spécifiquement à la position du token discriminant les types d'événements.
Évaluation : Le modèle est évalué sur un ensemble de test de 66 bugs de production réels (GoKer) qu'il n'a jamais vus durant l'entraînement. Les métriques incluent la précision top-1, l'erreur de calibration attendue (ECE) et la cohérence multi-étapes (simulant l'exécution en réinjectant les prédictions comme entrée).

Contributions Clés

Entraînement Sensible à la Distribution : L'article démontre que traiter le nondéterminisme de l'ordonnanceur comme un signal permet au modèle d'apprendre les « futurs valides » autorisés par l'ordonnanceur Go. Un modèle de 7B affiné sur moins de 1 000 traces atteint une précision de 36,2 % sur les bugs de production mis de côté, surpassant le même modèle en zero-shot (28,6 %) et Gemini 3.5 Flash en zero-shot (34,8 %).
Amélioration de la Calibration : Bien que l'entraînement par distribution (perte KL) atteigne une précision comparable à l'entropie croisée (35,8 % contre 36,2 %), il améliore significativement la calibration du modèle. L'erreur de calibration attendue chute de 0,205 à 0,169, et l'entropie du modèle est corrélée au nondéterminisme du programme, permettant au modèle d'exprimer son incertitude de manière appropriée.
Signature de Fuite Formelle : Les auteurs dérivent une signature formelle pour une classe spécifique de fuites de goroutines : les goroutines bloquées sur un select (select-blocked goroutines). Ils démontrent que pour ces cas, la probabilité d'un événement GoUnblock est exactement nulle ( $P(\text{GoUnblock}) = 0$ ) à toutes les profondeurs de trace. C'est une conséquence de la sémantique de l'ordonnanceur Go (si aucune goroutine atteignable ne peut satisfaire la condition du select, le déblocage est impossible) plutôt qu'un motif statistique appris.
Identification des Limites : L'étude cartographie explicitement les limites de l'approche. La précision plafonne près de 35–36 % quel que soit la taille du modèle ou l'objectif. Le modèle échoue à prédire les types d'événements rares (GoEnd, GoSched) en raison du déséquilibre des classes et du décalage de distribution (distribution shift). De plus, les prédictions multi-étapes perdent la cohérence de l'ordonnanceur après environ une étape, car le modèle a été entraîné uniquement sur des transitions à étape unique.

Résultats et Analyse

Plafond de Précision : Le plafond de performance (~36 %) est attribué à deux facteurs : le déséquilibre des classes (les événements rares comme GoEnd et GoSched ne sont jamais prédits correctement) et le décalage de distribution (les bugs réels sollicitent les types d'événements GoCreate et GoSched plus fréquemment que le jeu d'entraînement conçu à la main).
Performance par Événement : Le modèle apprend bien les événements de cycle de vie courants (GoStart à 47 %, GoCreate à 44 %), mais échoue sur les événements rares. Notamment, GoCreate atteint 44 % de précision malgré n'étant que 1,5 % des données d'entraînement, suggérant que le modèle raisonne à partir de la structure du programme plutôt que de la simple fréquence.
Cohérence Multi-Étapes : Utilisé de manière autorégressive, le modèle produit des transitions valides pendant environ une étape avant de violer les invariants de Go. Cela confirme que l'entraînement à étape unique ne se transfère pas à la simulation multi-étapes sans un entraînement sur trajectoire.
Raisonnement : L'activation des modes de « réflexion » (thinking modes) dans le modèle de base (Gemini) n'a pas amélioré la précision, indiquant que la tâche repose sur des signaux structurels plutôt que sur un raisonnement déductif multi-étapes.

Signification et Revendications
Les auteurs déclarent explicitement qu'ils ne revendiquent pas la création d'un détecteur de bugs déployable ou d'un simulateur d'exécution prêt pour la production. La signification de ce travail réside dans :

La Formulation : Fournir un cadre rigoureux pour modéliser l'exécution concurrente comme une estimation de distribution.
Le Jeu de Données et les Baselines : Publier un jeu de données de traces concurrentes, des adaptateurs entraînés et des outils pour établir des références pour ce problème spécifique.
La Clarification des Limites : Démontrer que si l'entraînement sensible au nondéterminisme fonctionne et améliore la calibration, des obstacles importants subsistent (événements rares, décalage de distribution, cohérence multi-étapes) qui doivent être adressés pour que l'approche soit plus efficace.

L'article conclut que l'approche actuelle prouve la viabilité de l'entraînement sensible à la distribution pour le code concurrent, tout en soulignant que les travaux futurs devront se concentrer sur l'entraînement par trajectoire, des représentations d'état plus riches (incluant les tampons de canaux et la possession de mutex) et le rééquilibrage des données d'entraînement pour correspondre aux distributions d'événements du monde réel.