SberZdorovye : le non-déterminisme des réseaux de neurones est une panne de pipeline, pas une propriété du modèle

Ruslan Cherkas, architecte chez SberZdorovye, s'est élevé contre la thèse répandue selon laquelle les réseaux de neurones seraient non déterministes par nature. Son argument central : si les données d'entrée, les poids du modèle et l'environnement sont fixés, le système doit produire à chaque fois le même résultat, et tout écart signale une défaillance du pipeline, du code ou de l'infrastructure.

D'où vient la controverse

L'élément déclencheur est une situation typique de la pratique du ML : une équipe tente de reproduire une expérience, mais obtient d'autres métriques ou une autre réponse du modèle. On met souvent ces cas sur le compte de la nature même des réseaux de neurones, surtout avec les LLM, l'entraînement sur GPU et les chaînes complexes de bibliothèques et de services. Cherkas conteste précisément cette explication et propose d'aborder le problème avec plus de rigueur, comme un défaut d'ingénierie et non comme une particularité inévitable de la technologie.

Selon lui, un modèle mathématique ne peut pas être « aléatoire en soi » si tous ses arguments sont connus et ne changent pas. Pour un réseau de neurones, cela suppose une entrée fixe, des poids fixes et des conditions d'exécution identiques. Dans ce cadre, la formule doit mener au même résultat à chaque fois. Si ce n'est pas le cas, il existe quelque part entre les données, le matériel, les bibliothèques et l'algorithme une variable non prise en compte que l'équipe ne contrôle tout simplement pas.

Quatre sources de défaillance

L'auteur passe en revue les explications les plus courantes pour justifier un résultat fluctuant et les ramène à quatre catégories de problèmes. Son idée générale est sans appel : le non-déterminisme n'est pas une « fonctionnalité » utile lorsqu'il apparaît sans modification des conditions d'entrée. Cela compte non seulement pour la recherche, mais aussi pour l'exploitation du modèle en production, où tout écart inexpliqué se transforme vite en risque.

• Incertitude sur les données d'entrée — les données elles-mêmes, les poids initiaux, la seed ou les états internes changent de façon aléatoire.
• Défaillances matérielles — des défauts d'équipement, des différences dans l'ordre des opérations ou un environnement d'exécution instable influent sur le résultat.
• Divergences logicielles — les versions des bibliothèques, les réglages d'optimisation, la mise en cache ou d'autres éléments de l'environnement diffèrent.
• Erreurs algorithmiques — l'ordre variable des calculs en virgule flottante, les situations de concurrence entre threads et une parallélisation incorrecte brisent la répétabilité.

Cherkas souligne par ailleurs que invoquer des « facteurs externes » comme les effets quantiques ne dégage pas le développeur de sa responsabilité. Si un facteur influe sur la sortie du modèle, il doit soit être inclus dans les arguments, soit être isolé. Sinon, il ne s'agit pas d'une question philosophique sur la nature de l'IA, mais d'une simple erreur d'implémentation.

L'article contient aussi une formule courte qui résume la position de l'auteur :

« Le non-déterminisme est une erreur qu'il faut et qu'on peut éliminer. »

Comment obtenir la répétabilité

La conclusion pratique de l'article est simple : il faut d'abord reconnaître le problème, puis en localiser la source. Si un modèle se comporte différemment lors d'une exécution identique, l'équipe doit décomposer l'incident par couches : vérifier les données, comparer les poids, fixer la seed et s'assurer que le matériel, les versions des bibliothèques et tout l'environnement d'exécution (runtime) sont identiques. Pour les systèmes de production, ce n'est plus une question de confort, mais de confiance dans le résultat et de capacité à enquêter correctement sur les pannes.

L'auteur prévient également qu'il ne faut pas payer la vitesse sans réfléchir par la perte de l'ordre des calculs. Si la parallélisation ou une optimisation modifie l'ordre des opérations au point que le résultat se met à fluctuer, une telle implémentation ne peut pas être jugée correcte pour des scénarios critiques. Cela vaut en particulier pour les systèmes où des décisions métier, des recommandations médicales, la sécurité ou d'autres processus à fort coût d'erreur dépendent du modèle. Dans ces cas, un pipeline déterministe doit constituer un objectif d'ingénierie à part entière, et non l'effet secondaire d'un réglage réussi.

Ce que cela signifie

Le texte de SberZdorovye est utile parce qu'il ramène la discussion sur la « magie des réseaux de neurones » sur le terrain de l'ingénierie ordinaire. Plus les entreprises intègrent des modèles dans des processus importants, moins il est acceptable d'expliquer l'imprévisibilité par la nature abstraite de l'IA. En pratique, les équipes gagnantes seront celles qui savent démontrer la reproductibilité, décrire les sources d'aléa et prouver que le système reste maîtrisable, même dans des scénarios complexes.