🤖 machine learning

From Failure to Alignment: A Requirements Engineering Framework for Machine Learning Systems

Ce document propose REAL, un cadre d'ingénierie des exigences basé sur les modèles qui intègre les données, les modèles et les exigences du système tout en exploitant l'analyse des défaillances et le raffinement itératif pour garantir que les systèmes d'apprentissage automatique s'alignent sur les besoins des parties prenantes et sont dignes de confiance.

Auteurs originaux : Amel Bennaceur, Gopi Krishnan Rajbahadur, Prince Mercy, Bashar Nuseibeh, Faeq Alrimawi

Publié 2026-07-01

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Amel Bennaceur, Gopi Krishnan Rajbahadur, Prince Mercy, Bashar Nuseibeh, Faeq Alrimawi

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 apprenez à un robot à conduire une voiture. Vous lui dites : « Ne percute jamais un piéton. » Simple, n'est-ce pas ? Mais dans le monde réel, les choses deviennent complexes. Le robot peut ne pas voir un jeune enfant sous la pluie, ou il peut freiner trop brusquement pour un sac plastique qui vole sur la route.

Ce document, intitulé « De l'échec à l'alignement », présente une nouvelle façon de construire ces systèmes intelligents. Les auteurs appellent leur méthode REAL (Requirements Engineering for mAchines that Learn - and Fail / Ingénierie des exigences pour les machines qui apprennent — et échouent).

Voici l'idée centrale, décomposée avec des analogies simples :

1. Le Problème : Le piège du « Monde Parfait »

Le logiciel traditionnel est comme une recette : si vous suivez les étapes exactement, vous obtenez le même gâteau à chaque fois. L'apprentissage automatique (Machine Learning - ML) est différent. C'est plutôt comme apprendre à un chien à rapporter un objet. Vous lui montez un ballon, il apprend à rapporter. Mais si vous lancez un bâton, ou un frisbee, ou une chaussure, le chien pourrait être confus.

Les auteurs soutiennent que lorsque nous construisons ces systèmes d'« apprentissage », nous supposons souvent que le monde ressemblera exactement aux données d'entraînement. Or, le monde réel est plein de surprises (brouillard, vêtements étranges, jeunes enfants). Lorsqu'un système échoue, les ingénieurs essaient généralement simplement de « corriger le bug ». Les auteurs disent : Arrêtez de traiter l'échec comme un bug. Traitez-le comme un indice.

2. La Solution : Le cadre REAL

Le cadre REAL est une boucle en trois étapes qui transforme les « échecs » en « meilleures instructions ». Considérez cela comme une histoire de détective où l'échec est la scène de crime, et l'objectif est de découvrir quelle règle manquait.

Étape 1 : Chasser les « Et si ? » (Exploration de scénarios)

Au lieu de tester simplement la voiture par une journée ensoleillée, le cadre utilise une « grammaire » (un ensemble de règles) pour générer automatiquement des milliers de situations bizarres, difficiles ou rares.

Analogie : Imaginez un générateur de niveaux de jeu vidéo qui crée des millions de conditions météorologiques, de tailles de piétons et d'angles de traversée différents. Il cherche spécifiquement les moments où la voiture a failli s'écraser ou a manqué une personne.
Le But : Trouver les « échecs valides » : des situations qui sont réalistes mais où le système a échoué.

Étape 2 : L'enquête sur le « Pourquoi » (Analyse des obstacles)

Une fois qu'un échec est trouvé, le cadre demande : Pourquoi cela est-il arrivé ? Il ne se contente pas de dire « le capteur a échoué ». Il relie l'échec à la règle d'origine.

Analogie : Si la voiture rate un jeune enfant, le cadre ne dit pas seulement « réparez la caméra ». Il réalise que la règle d'origine était « Voir tous les piétons ». L'échec révèle une hypothèse cachée : « Nous avons supposé que tous les piétons seraient assez grands pour être vus facilement. »
Le Résultat : L'échec est reclassé comme un Obstacle. C'est comme placer un panneau sur une carte qui dit : « Voici l'endroit où notre carte actuelle est erronée. »

Étape 3 : La correction multi-couches (Atténuation)

Maintenant que nous savons ce qui ne va pas, nous le réparons. Mais les auteurs disent que l'on ne peut pas simplement réparer une chose ; il faut regarder quatre couches différentes, comme pour réparer une maison :

Couche de Données (Les ingrédients) : Peut-être que le robot n'a jamais vu d'enfant sous la pluie pendant son entraînement. Correction : Montrez-lui plus d'images d'enfants sous la pluie.
Couche du Modèle (Le cerveau) : Peut-être que le « cerveau » du robot est trop lent ou confus. Correction : Modifiez les mathématiques à l'intérieur du cerveau pour qu'il soit plus prudent.
Couche du Système (Le corps) : Peut-être que le cerveau est lent, donc la voiture a besoin d'un plan de secours. Correction : Ajoutez une règle qui dit : « Si vous n'êtes pas sûr à 100 %, ralentissez doucement. »
Couche des Exigences (Le contrat) : Peut-être que la règle d'origine était impossible. Correction : Admettez que la voiture ne peut pas voir dans un brouillard épais et mettez à jour la règle pour dire : « Ne pas conduire dans le brouillard. »

3. Le Test en Conditions Réelles : La voiture qui freine

Pour prouver que cela fonctionne, les auteurs ont testé REAL sur un système de freinage autonome (une voiture qui s'arrête pour les piétons).

La Configuration : Ils ont utilisé un simulateur (un monde de jeu vidéo) pour créer des scénarios avec des enfants, des adultes, du brouillard et des vêtements différents.
La Découverte : Le système manquait systématiquement des jeunes enfants, surtout par mauvais temps.
Le Processus REAL :
- Ils ont identé l'échec (rater l'enfant).
- Ils ont identifié l'obstacle (le système n'avait pas pris en compte la « petite taille » et la « faible visibilité »).
- Ils ont appliqué des corrections : ils ont ajouté plus de données d'entraînement d'enfants, ont ajusté les seuils de confiance de la voiture et ont clarifié les règles concernant les moments où la voiture est autorisée à rouler.
Le Résultat : En utilisant cette boucle, ils ont réduit le nombre d'enfants manqués de 100 % (dans les cas les plus graves) à 8 %, et ils ont rendu les règles de la voiture beaucoup plus claires.

La Grande Conclusion

Le papier affirme que l'échec n'est pas la fin de la route ; c'est la carte.

Au lieu d'essayer de construire un système parfait qui ne faillit jamais (ce qui est impossible), le cadre REAL utilise les échecs pour mettre constamment à jour le « contrat » du système avec le monde réel. Il relie les points entre :

Ce que les humains veulent (La sécurité).
Ce que le monde est réellement (Le brouillard, les petits enfants).
Ce que l'ordinateur fait réellement (Rater des éléments).

En traitant l'échec comme un outil de diagnostic, ce cadre aide les ingénieurs à construire des systèmes qui sont honnêtes sur leurs limites et plus sûrs dans le monde réel.

Ce que le papier ne prétend PAS :

Il ne prétend pas résoudre tous les problèmes de l'IA.
Il ne prétend pas fonctionner parfaitement pour tous les types d'IA (comme les chatbots ou le diagnostic médical) pour le moment, bien qu'ils prévoient de l'essayer.
Il ne promet pas que le système ne faillira plus jamais ; il promet que le système sera meilleur pour comprendre pourquoi il a échoué et comment ajuster ses règles.

Résumé technique : De l'échec à l'alignement : Un cadre d'ingénierie des exigences pour les systèmes d'apprentissage automatique

Énoncé du problème

Les organisations développant des systèmes d'apprentissage automatique (Machine Learning Systems - MLS) sont confrontées à des défis importants pour garantir que ces systèmes sont dignes de confiance et alignés sur les besoins des parties prenantes. Contrairement au logiciel traditionnel, le comportement d'un MLS est appris à partir de données plutôt qu'explicitement programmé, ce qui rend sa performance dépendante de la distribution et rend l'échec inhérent en raison de la généralisation et de l'incertitude. Les pratiques actuelles d'ingénierie des exigences (RE) peinent à modéliser et à raisonner systématiquement sur les exigences des MLS car :

Sous-spécification : Les domaines opérationnels sont ouverts, et une spécification complète en amont est irréaliste.
Hypothèses implicites : Les hypothèses liées au domaine (ex: couverture des données, limites de détection) sont souvent implicites, entraînant un désalignement entre les objectifs des parties prenantes, les hypothèses du domaine et le comportement du système lors de défaillances.
Manque d'intégration : Bien que la détection de défaillances soit courante dans les tests ML, il existe un fossé dans l'intégration systématique de la découverte de défaillances dans le processus de RE pour piloter le raffinement des exigences. Les approches existantes traitent souvent les échecs comme des artefacts de test ou des problèmes de débogage plutôt que comme des preuves diagnostiques pour affiner les exigences et les hypothèses du domaine.

L'article répond à trois questions de recherche (RQ) :

RQ1 : Comment peut-on opérationnaliser le raisonnement sur les exigences pour les MLS ?
RQ2 : Comment la découverte et l'atténuation des défaillances peuvent-elles être systématiquement intégrées dans le processus de RE ?
RQ3 : Dans quelle mesure une adaptation transversale pilotée par l'échec améliore-t-elle mesurablement la satisfaction des exigences ?

Méthodologie : Le cadre REAL

Les auteurs proposent REAL (Requirements Engineering for mAchines that Learn - and Fail), un cadre basé sur des modèles qui traite l'échec comme une construction de premier rang. REAL repose sur trois principes fondamentaux : tisser les exigences de données, de modèle et de système ; utiliser l'échec pour piloter l'exploration d'alternatives aux exigences ; et un raffinement itératif et traçable.

Le cadre établit une boucle d'alignement itérative impliquant trois phases :

1. Identifier l'échec par l'exploration de scénarios

Au lieu de supposer une satisfaction uniforme des exigences, REAL opérationnalise le domaine comme un espace de scénarios paramétrés $D(\theta)$ .

Génération guidée par la grammaire : Il utilise l'évolution grammaticale (GE) avec un langage spécifique au domaine (DSL) défini par une grammaire formelle pour générer automatiquement des scénarios structurés (acteurs, environnements, comportements).
Filtrage d'admissibilité : Le cadre distingue les échecs valides (survenant dans les hypothèses de domaine admissibles) des échecs spécieux (déclenchés par des scénarios hors périmètre). Seuls les échecs valides, où $D(\theta), S \not\models R$ et où les contraintes d'admissibilité sont respectées, sont transmis à l'analyse.

2. Analyser l'échec par l'analyse d'obstacles

Les échecs sont réinterprétés comme des obstacles dans un modèle de buts de type KAOS.

Interprétation des contre-exemples : Une trace d'échec est traitée comme un contre-exemple à la relation de satisfaction.
Dérivation d'obstacles : Les échecs sont regroupés pour identifier des motifs récurrents, élevant les contre-exemples empiriques en conditions d'obstacles explicites ( $O$ ) où $O \Rightarrow \neg R$ . Cela diagnostique les désalignements entre les objectifs des parties prenantes, les hypothèses du domaine et le comportement du système.

3. Atténuer l'échec par une adaptation multi-couches

REAL distingue quatre couches d'adaptation pour restaurer la relation de satisfaction ( $D, S \models R$ ) :

Niveau des données (Data-level) : Augmenter les distributions d'entraînement ou rééquilibrer les classes pour traiter les écarts de distribution.
Niveau du modèle (Model-level) : Ajuster les architectures, les hyperparamètres ou les seuils de décision pour remodeler la frontière de décision apprise.
Niveau du système (System-level) : Introduire une logique de contrôle sensible à la confiance, des comportements de sécurité (fail-safe) ou de la redondance sans modifier le modèle appris lui-même.
Niveau des exigences (Requirement-level) : Affiner les exigences ( $R$ ) ou les hypothèses du domaine ( $D$ ) elles-mêmes (ex: délimiter le domaine de conception opérationnelle ou ODD) lorsque les échecs révèlent des besoins sous-spécifiés ou des hypothèses irréalistes.

Ce processus est itératif ; de nouvelles adaptations peuvent exposer de nouvelles violations, nécessitant un nouveau raffinement du triplet $(D, S, R)$ .

Contributions clés

L'article présente quatre contributions principales :

Lien opérationnel : Il relie les exigences des parties prenantes à la variabilité exécutable du domaine via l'exploration de scénarios guidée par la grammaire, permettant la découverte systématique de contre-exemples pertinents pour les exigences.
Interprétation basée sur les obstacles : Il réinterprète les échecs empiriques comme des obstacles dans un modèle de buts, fournissant un mécanisme fondé pour diagnostiquer le désalignement.
Stratégie d'atténuation multi-couches : Il définit et évalue une adaptation coordonnée à travers les couches de données, de modèle, de système et de exigences, montrant explicitement comment les décisions d'atténuation affectent la satisfaction des exigences.
Démonstrateur de conduite autonome : Il fournit un package de réplication public démontrant le cadre sur un système de freinage automatique utilisant CARLA, Scenic et la génération de scénarios par évolution.

Résultats expérimentaux

Le cadre a été évalué à l'aide d'un système de freinage automatique comprenant un composant de détection de piétons (YOLOv5) et un contrôleur de freinage déterministe.

Configuration expérimentale :

Environnement : Simulateur CARLA avec Scenic pour la spécification des scénarios.
Générateurs : GRAPE (Évolution Grammaticale) pour la génération de scénarios.
Focus : Variation systématique de la taille des piétons, de la distance, de la direction, des vêtements et de la météo (brouillard).

Résultats :

Identification des échecs : Le cadre a identifié avec succès des violations de exigences valides, telles que des détections manquées de piétons enfants (liées à la taille), des échecs sous faible saillance visuelle (contraste des vêtements) et une performance dégradée par le brouillard (visibilité).
Analyse d'obstacles : Les échecs ont été regroupés en trois classes d'obstacles : PedestrianSizeTooSmall (Piéton trop petit), VisualSaliency (Saillance Visuelle) et AdverseWeather (Météo Adverse).
Efficacité de l'atténuation :
- Niveau Modèle (M1) : Passer à un modèle plus grand (YOLOv5m) a amélioré la précision (+17 %) mais a introduit des échecs liés à la latence dans les scénarios à courte distance.
- Niveau Données (M2) : Un ajustement fin (fine-tuning) ciblé sur les données de piétons enfants a éliminé les échecs liés à la taille et a considérablement amélioré les performances dans le brouillard (le taux de collision est passé de 100 % à 0 % en météo nominale).
- Niveau Système (M4) : L'implémentation d'un freinage sensible à la confiance a réduit les taux de collision résiduels avec les enfants de 100 % à 8 % sans réentraînement.
- Niveau Exigences (M5) : Délimiter explicitement le Domaine de Conception Opérationnelle (ODD) et définir des seuils quantitatifs a clarifié les limites des garanties de sécurité.
Impact global : Une adaptation coordonnée multi-couches a réduit les taux de collision avec les enfants de 100 % (base) à 8 % et a éliminé les échecs en météo nominale. L'étude a démontré que l'optimisation isolée du modèle est insuffisante ; l'alignement nécessite d'adresser l'interaction entre les données, le modèle, le système et les exigences.

Signification et affirmations

L'article affirme que REAL fournit un processus systématique pour intégrer les résultats de tests dans les artefacts de RE. Sa signification réside dans :

Changement de perspective sur l'échec : Passer d'une vision de l'échec comme défaut technique à celle d'une preuve diagnostique de désalignement entre les exigences, les hypothèses et l'implémentation.
Opérationnalisation de l'alignement : Fournir un mécanisme concret pour lier les buts de haut niveau des parties prenantes aux comportements bas niveau du système et aux hypothèses du domaine via l'analyse d'obstacles.
Coordination multi-couches : Démontrer que restaurer l'alignement dans les MLS nécessite une adaptation coordonnée à travers plusieurs couches (données, modèle, système, exigences) plutôt que des correctifs isolés.

Les auteurs maintiennent une position modeste, reconnaissant que l'évaluation est limitée à un exemple simplifié de sécurité critique et que le processus ne garantit pas la convergence dans tous les cas. Ils notent que si le cadre structure le processus, le jugement humain reste essentiel pour interpréter les échecs et sélectionner les stratégies d'atténuation. Des travaux futurs sont proposés pour étendre REAL aux modèles de langage étendus (LLM), intégrer plus profondément les valeurs des parties prenantes et étudier les conditions de convergence de la boucle d'alignement itérative.