💻 computer science

Model-Driven Requirements Configuration with Three-Valued Uncertainty Scoring

Cet article présente une architecture multi-agents neuro-symbolique qui combine un grand modèle de langage avec un validateur symbolique déterministe et un cadre de notation d'incertitude à trois valeurs afin d'éliminer les incohérences structurelles dans les exigences générées par LLM tout en quantifiant formellement l'incertitude de décision pour un déploiement plus sûr dans l'ingénierie des exigences.

Auteurs originaux : Ahmed Ibrahim

Publié 2026-07-30

📖 9 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Ahmed Ibrahim

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 de construire un robot personnalisé, mais au lieu de dessiner des plans, vous discutez simplement avec un ami robot très bavard, super intelligent et qui adore inventer des choses. Vous dites : « Je veux un robot qui peut cuisiner et nettoyer », et votre ami commence avec enthousiasme à lister des pièces. Mais parce qu'il est si empressé, il pourrait accidentellement suggérer une pièce qui ne convient pas, ou deux pièces qui explosent si vous les assemblez, ou même inventer une pièce qui n'existe pas du tout. C'est le monde complexe de l'Ingénierie des Exigences : le processus consistant à déterminer exactement ce qu'un logiciel ou une machine doit faire. Pendant longtemps, les experts ont utilisé des « livrets de règles » mathématiques stricts (appelés modèles formels) pour s'assurer que chaque pièce s'ajuste parfaitement, mais ces livrets sont difficiles à lire pour les humains. Récemment, nous avons commencé à utiliser des Grands Modèles de Langage (LLM) — le même type d'IA qui écrit des poèmes et répond à des questions — pour nous aider à décrire ce que nous voulons en langage naturel. Le problème ? Ces amis IA sont excellents pour parler, mais terribles pour suivre les règles strictes du livret de règles, créant souvent des conceptions qui semblent bonnes mais qui s'effondrent quand on essaie de les construire.

Ce document présente une nouvelle collaboration ingénieuse pour résoudre ce problème. Les auteurs ont créé un système où l'IA bavarde (le LLM) agit comme un créatif de brainstorming, suggérant des idées basées sur votre description en langage naturel, tandis qu'un « vérificateur de règles » strict et inflexible (un validateur symbolique) monte la garde. Voyez cela comme un chef créatif et un inspecteur sanitaire travaillant ensemble dans une cuisine. Le chef suggère des recettes sauvages et délicieuses, mais l'inspecteur vérifie immédiatement si les ingrédients sont sûrs et si les étapes respectent la loi. Si le chef suggère de mélanger du poison avec un gâteau, l'inspectateur l'arrête instantanément. Le document montre que cette collaboration corrige avec succès presque toutes les erreurs commises par l'IA, transformant des idées désordonnées et impossibles en plans solides et constructibles. Ils ont également introduit une nouvelle façon de mesurer la confiance de l'IA, en distinguant les choses que l'IA doit choisir, les choses qu'elle peut choisir librement, et les choses qu'elle a mal faites.

L'histoire du Chef Créatif et de l'Inspecteur Strict

Dans le monde du logiciel, avant d'écrire la moindre ligne de code, vous devez décider exactement de ce que le programme doit faire. C'est ce qu'on appelle l'Ingénierie des Exigences. Imaginez que vous concevez une « Maison Intelligente ». Vous devez décider : possède-t-elle une batterie de secours ? Utilise-t-elle le Wi-Fi ou le Bluetooth ? Pouvez-vous contrôler les lumières avec votre voix ? Si vous faites ces choix de travers, toute la maison risque de ne pas fonctionner.

Traditionnellement, les experts utilisaient un système rigide appelé OOMRAM (Méthode Orientée Objet pour l'Auteur et la Gestion des Exigences). Considérez l'OOMRAM comme un immense et complexe organigramme ou un arbre de choix. Il possède des règles strictes : « Si vous choisissez "Maison Intelligente", vous devez choisir une source d'énergie. Si vous choisissez "Wi-Fi", vous ne pouvez pas choisir "Bluetooth" en même temps. » C'est comme un créateur de personnage de jeu vidéo où vous ne pouvez pas équiper une épée et un bouclier si le jeu dit qu'ils sont mutuellement exclusifs. Le problème est que ces organigrammes sont difficiles à naviguer pour les humains. Vous ne pouvez pas simplement dire : « Je veux une maison qui soit chaleureuse et sûre », et espérer que l'organigramme comprenne. Vous devez connaître le nom exact de chaque option.

Entrez dans la scène le Grand Modèle de Langage (LLM). C'est l'IA qui peut comprendre votre phrase, « Je veux une maison chaleureuse avec contrôle vocal », et deviner quelles options vous voulez probablement dire. C'est comme un assistant super rapide et créatif qui parle votre langue. Mais attention : l'IA est un peu rêveuse. Elle pourrait inventer une « Batterie Quantique » qui n'existe pas, ou elle pourrait oublier que vous ne pouvez pas avoir à la fois le Wi-Fi et le Bluetooth, menant à une conception logiquement défaillante.

L'équipe Neuro-Symbolique

Les auteurs de ce document ont construit un système pour corriger cela. Ils ont créé une équipe de quatre « agents » (petits programmes informatiques) qui travaillent ensemble :

Le Navigateur : Cet agent regarde le gigantesque organigramme (le réseau OOMRAM) et décide quelle partie regarder ensuite. C'est comme un guide touristique pointant la porte suivante dans un labyrinthe.
L'Interprète (l'IA) : C'est le LLM. Il écoute votre « vision du projet » (votre description de ce que vous voulez) et suggère quels boutons presser sur l'organigramme. Il essaie de deviner quelles options correspondent à votre description.
Le Validateur (l'Inspecteur) : C'est la partie stricte qui suit les règles. Il n'utilise pas l'IA ; il utilise des mathématiques rigoureuses. Il vérifie chaque suggestion de l'IA par rapport aux règles de l'organigramme. L'IA a-t-elle choisi deux choses qui ne peuvent pas aller ensemble ? A-t-elle oublié une partie obligatoire ? Si la réponse est « oui », le Validateur dit : « Non, réessayez », et renvoie l'IA pour qu'elle corrige son erreur.
Le Scribe : Une fois que tout est approuvé, cet agent écrit la liste finale et parfaite des exigences.

La magie opère parce que l'IA et l'Inspecteur se parlent dans une boucle. L'IA suggère, l'Inspecteur vérifie, et s'il y a une erreur, l'IA essaie de nouveau. Cela se répète jusqu'à ce que la conception soit parfaite.

La fiche de score à trois valeurs : Vrai, Peut-être et Faux

L'une des parties les plus intéressantes de ce document est la façon dont ils mesurent le travail de l'IA. Habituellement, nous disons simplement qu'une réponse est « Juste » ou « Fausse ». Mais les auteurs ont réalisé que c'est trop simple. Parfois, l'IA choisit quelque chose qui est autorisé mais qui n'est pas strictement requis. Pour gérer cela, ils ont inventé une Fiche de Score à Trois Valeurs :

Vérité (T) : L'IA a choisi quelque chose qui devait être choisi. Par exemple, si la vision dit « Maison Intelligente », le système doit choisir une source d'énergie. Si l'IA la choisit, c'est une Vérité.
Indétermination (I) : L'IA a choisi quelque chose qui était autorisé, mais que la vision n'imposait pas. Peut-être que la vision disait simplement « Maison Intelligente », et l'IA a choisi « Wi-Fi » plutôt que « Bluetooth ». Les deux sont valides, mais la vision n'a pas précisé lequel. C'est l'Indétermination. C'est un « choix libre ».
Falsité (F) : L'IA a choisi quelque chose qui a enfreint les règles. Comme choisir « Wi-Fi » et « Bluetooth » en même temps alors que les règles disent que c'est impossible. C'est la Falsité.

En utilisant cette fiche de score, les chercheurs ont pu voir exactement où l'IA devinait et où elle suivait les ordres.

Ce qu'ils ont découvert

L'équipe a testé leur système avec 37 visions de projets différentes à travers 11 types d'applications différents, comme des systèmes de tenue de registres, des maisons intelligentes et des systèmes de divertissement pour voitures. Ils ont utilisé un modèle d'IA « léger » (Llama 3.1 8B) pour la plupart des tests.

Voici ce qui s'est passé :

Le taux de correction : Sans l'Inspecteur strict, l'IA faisait de grosses erreurs. Mais avec l'Inspecteur, le système a corrigé presque toutes les erreurs. Dans 35 cas sur 37 (94,6 %), le résultat final présentait zéro erreur structurelle.
Les restants : Dans les 2 cas restants, l'IA est restée bloquée dans une boucle et n'a pas pu corriger un type spécifique d'erreur avant qu'ils ne terminent le test. Cela n'a laissé que 6 minuscules erreurs sur plus de 1 500 décisions (0,39 %).
La zone du « Peut-être » : Les chercheurs ont découvert qu'environ 24,7 % de toutes les décisions prises par l'IA étaient des « Indéterminations ». Cela signifie que l'IA exerçait sa liberté de choisir entre des options valides, ce qui est en fait une bonne chose ! Cela montre que le système sait faire la différence entre « doit faire » et « peut choisir ».
L'IA plus forte : Lorsqu'ils ont testé le système avec un modèle d'IA beaucoup plus intelligent et de pointe (NVIDIA Nemotron 3 Ultra), il a réussi 100 % des visions parfaitement, avec zéro erreur.

Pourquoi cela importe

Le document soutient que laisser une IA écrire des exigences est dangereux car elle pourrait inventer des choses qui ne fonctionnent pas. Mais en mettant un « Inspecteur » mathématique strict en charge de vérifier les règles, vous pouvez laisser l'IA être créative sans craindre qu'elle ne viole les lois de la logique.

Les auteurs ont également montré que ce système est rapide. L'« Inspecteur » prend moins de 0,4 % du temps total, ce qui signifie qu'il ne ralentit pas les choses. Ils ont aussi prouvé que le système passe bien à l'échelle : à mesure que la liste des options s'agrandit, le nombre de fois où l'IA doit communiquer avec le système augmente de façon linéaire, et non de façon exponentielle.

En bref, ce document prou parfaitement que vous pouvez avoir le beurre et l'argent du beurre : vous pouvez utiliser le langage naturel et flexible de l'IA pour décrire ce que vous voulez, tout en ayant un livre de règles strict et incassable qui garantit que ce que vous obtenez est réellement constructible et correct. Cela transforme l'IA « rêveuse » en un ingénieur fiable.

Résumé Technique : Configuration de Besoins Pilotée par Modèle avec Score d'Incertitude à Trois Valeurs

1. Énoncé du Problème

L'ingénierie des besoins (RE - Requirements Engineering) est intrinsèquement coûteuse et sujette aux erreurs. Bien que les modèles de domaine formels comme l'OOMRAM (Object-Oriented Method for Requirements Authoring and Management) fournissent des structures mathématiques rigoureuses pour gérer la variabilité des lignes de produits logicielles, leur application traditionnelle souffre d'un « goulot d'étranglement de correspondance exacte ». Ces formalismes obligent les analystes à naviguer dans des treillis complexes en utilisant des identifiants de besoins précis ou une syntaxe rigide, ceما empêche l'utilisation de descriptions de projets en langage naturel (visions) pour l'élicitation.

Inversement, les modèles de langage de grande taille (LLM) offrent la flexibilité d'interpréter le langage naturel mais manquent de garanties de correction formelle. Appliquées à l'ingénierie des besoins, les approches purement basées sur les LLM génèrent fréquemment des exigences structurellement invalides, des incohérences logiques (par exemple, la sélection d'options mutuellement exclusives) et des identifiants hallucinés. Les approches neuro-symboliques existantes vérifient souvent la logique ex-post (après la génération) ou reposent sur des atténuations heuristiques, échouant à fournir l'application déterministe requise pour une ingénierie des besoins à haute assurance.

2. Méthodologie

Le papier propose une architecture multi-agents neuro-symbolique qui opérationnalise le treillis OOMRAM pour jeter un pont entre les visions en langage naturel et les contraintes structurelles formelles. Le système est conçu pour la phase de sélection de caractéristiques de l'élicitation de besoins de lignes de produits, où l'objectif est d'identifier quels besoins d'un treillis pré-ingénieré sont imposés ou compatibles avec une vision de partie prenante.

2.1. Architecture du Système

Le système, implémenté via LangGraph, comprend quatre agents :

Navigateur (Navigator) : Effectue un parcours en profondeur (DFS) du treillis OOMRAM, sélectionnant le prochain nœud discriminant à traiter. Il utilise une stratégie basée sur une frontière pour assurer une mise à l'échelle linéaire et éviter les traitements redondants.
Interprète (Interpreter - LLM) : Agit comme une heuristique non déterministe. Il traduit la vision du projet et le contexte actuel en un ensemble proposé d'identifiants de besoins enfants (sortis sous forme de JSON). Il fonctionne à une température de 0 pour minimiser la stochasticité.
Validateur (Validator - Symbolique) : Une fonction Python déterministe qui impose les contraintes structurelles immédiatement après chaque proposition de l'Interprète. Il vérifie l'ensemble de sélection $S$ $S$ par rapport au prédicat de cohérence globale $\Psi(S)$ $Ψ (S)$ , qui inclut quatre invariants axiomatiques :
1. Invariant de Noyau (Core Invariant) : Sélection obligatoire des nœuds "Core" si leur parent est actif.
  c. Invariant d'Adaptateur Unique (SA Invariant) : Exactement un enfant doit être sélectionné pour les nœuds SA (logique XOR).
  d. Invariant d'Adaptateur Multiple (MA Invariant) : Au moins un enfant doit être sélectionné pour les nœuds MA (logique OR).
  e. Intégrité Structurelle : Aucun nœud orphelin ; chaque nœud sélectionné non racine doit avoir un parent sélectionné.
Scribe (Scribe) : Compile l'ensemble final validé en une spécification formatée.

2.2. La Boucle de Correction

Si le Validateur détecte une violation, il rejette la proposition et renvoie un message d'erreur détaillé à l'Interprète. L'Interprète révise ensuite sa proposition en utilisant ce retour d'information. Cette boucle se poursuit jusqu'à ce que les contraintes soient satisfaites ou qu'un « budget d'appels » (limité à 150 appels LLM par vision) soit atteint.

2.3. Score d'Incertitude à Trois Valeurs

Pour remédier à la limitation des étiquetages binaires « correct/incorrect », les auteurs introduisent un cadre à trois valeurs $\langle T, I, F \rangle$ appliqué à la sortie du Validateur :

Vérité ( $T$ ) : La sélection est structurellement valide et explicitement imposée par la vision (ou une spécification de référence).
Indétermination ( $I$ ) : La sélection est structurellement valide mais non explicitement imposée. Cela représente des choix discrétionnaires légitimes (par exemple, la sélection d'un protocole spécifique parmi un ensemble d'adaptateurs valides).
Falsité ( $F$ ) : La sélection a été rejetée par le Validateur en raison d'une violation structurelle.

Ce scoring permet au système de quantifier la « liberté légitime » inhérente au treillis de besoins par rapport aux erreurs réelles.

3. Contributions Clés

Architecture Neuro-Symbolique : Un système qui délègue la logique structurelle à une couche symbolique déterministe, rendant les treillis OOMRAM formels exploitables pour l'élicitation en langage naturel tout en garantissant la conformité structurelle.
Cadre d'Évaluation à Trois Valeurs : Une métrique novatrice pour distinguer les besoins imposés, les choix discrétionnaires valides et les erreurs structurelles, fournissant une manière formelle de mesurer l'incertitude neurale.
Validation Empirique : Une évaluation complète à travers 37 visions de projets en langage naturel couvrant onze familles d'applications (ex: Maison Intelligente, Tenue de Registres Électroniques, IVI Automobile).
Preuve Formelle et Comparaison de Référence : Une preuve formelle de la convergence du validateur et une analyse comparative démontrant la supériorité du système sur les LLM non contraints et les stratégies standard de NLP4RE (RAG, Auto-Cohérence, Débat Multi-agents).

4. Résultats

Le système a été évalué sur une machine Apple M1 Pro avec le modèle Llama 3.1 8B, avec une réplication utilisant le modèle frontal NVIDIA Nemotron 3 Ultra.

Conformité Structurelle (RQ1) : Le système a éliminé les incohérences structurelles dans 35 cas sur 37 (94,6 %). Les deux cas restants ne contenaient que 6 erreurs structurelles non résolues (0,39 % du total des décisions), attribuées à l'atteinte de la limite d'itération avant convergence. Sous le modèle frontal (Nemotron 3 Ultra), le système a atteint une convergence de 100 % avec 0 % de falsité structurelle.
Quantification de l'Incertitude (RQ2) : L'analyse à trois valeurs a révélé que 24,7 % de toutes les décisions étaient Indéterminées ( $I$ ). Il s'agissait de choix structurellement valides mais non explicitement imposés par la vision, concentrés principalement dans les nœuds d'Adaptateur Multiple (MA) et les nœuds Optionnels. Cela confirme que le système identifie correctement les points où l'intention de la partie prenante est sous-spécifiée.
Comparaison de Référence (RQ3) : Sans le validateur symbolique, les stratégies de LLM non contraintes ont entraîné des taux de falsité structurelle allant de 62,2 % à 94,6 %. Le système neuro-symbolique a réduit ce taux à 5,4 % (Llama 3.1 8B) et 0,0 % (Nemotron 3 Ultra). Notamment, une base de référence RAG a subi un taux de falsité de 94,6 % dû à un biais d'ancrage de récupération, où le LLM sélectionnait des nœuds feuilles sans leurs chemins parents requis.
Scalabilité (RQ4) : Le nombre d'appels LLM suit une progression quasi-linéaire avec la taille du treillis ( $R^2 = 0,69$ ), confirmant l'efficacité de la stratégie d'élagage basée sur la frontière. Cependant, la latence de temps de calcul est dominée par les frais généraux de réseau/service de modèle plutôt que par la complexité du treillis. Le validateur symbolique ajoute un surcoût négligeable (< 0,4 % de la latence totale).

5. Signification et Revendications

Le papier affirme que le transfert de l'intégrité structurelle vers une couche symbolique déterministe garantit avec succès la conformité structurelle, transformant efficacement les sorties neurales incohérentes en spécifications vérifiées et structurellement saines.

Sécurité du Déploiement : L'architecture fournit un modèle de conception général pour le déploiement sûr des LLM dans des domaines critiques pour la sécurité ou la qualité, en séparant l'heuristique neurale du vérificateur de contraintes symboliques. Cela garantit que le composant LLM peut être mis à jour sans compromettre les garanties formelles.
Retour Actionnable : La classification à trois valeurs fournit aux praticiens un retour immédiat. Une forte indétermination signale des visions sous-spécifiées nécessitant une clarification de l'analyste, tandis qu'une falsité persistante (bien que rare) pointe des malentendus spécifiques du modèle ou des problèmes de treillis.
Rigueur Formelle : Contrairement aux approches heuristiques, ce système offre une garantie déterministe : pour toute exécution qui converge dans le budget d'appels, la sortie finale est garantie de satisfaire toutes les contraintes du treillis.

Les auteurs maintiennent une position modeste, reconnaissant que le système ne peut pas détecter les hallucinations sémantiques (sélections structurellement valides mais non pertinentes) et dépend de treillis OOMRAM pré-ingénierés. Ils notent que si la couche symbolique garantit la correction structurelle, la capacité du LLM à suivre les messages d'erreur et à converger reste dépendante du modèle, comme en témoigne la différence de performance entre les modèles 8B et frontaux. Des travaux futurs sont proposés pour automatiser l'extraction de treillis, intégrer le routage sémantique pour la sélection de familles, et passer d'un scoring à trois valeurs net à une visualisation d'incertitude basée sur des probabilités continues.