Iterative Audit Convergence in LLM-Managed Multi-Agent Systems: A Case Study in Prompt Engineering Quality Assurance

Résumé technique : Convergence itérative de l'audit dans les systèmes multi-agents gérés par des LLM

Énoncé du problème
Les spécifications de prompts pour les systèmes multi-agents basés sur des modèles de langage (LLM) fonctionnent comme la source de vérité du système, contenant des contrats de données, une logique d'intégration et des règles comportementales à travers des fichiers interdépendants. Contrairement au code source traditionnel, ces spécifications en langage naturel sont rarement soumises à une inspection rigoureuse et structurée. Dans des pipelines d'orchestration complexes à plusieurs voies, les modifications de conception dans un document créent souvent des effets en cascade (par exemple, des références obsolètes, des incompatibilités de schéma ou des contrats d'API invalides) dans d'autres. Les revues traditionnelles sur un seul fichier sont insuffisantes par construction, car elles ne peuvent pas détecter les incohérences inter-documents. Cet article traite du manque de données empiriques sur la densité des défauts et le comportement de convergence de l'audit itératif appliqué aux spécifications de prompts à l'échelle de la production.

Méthodologie
L'étude présente une étude de cas empirique sur un seul système, l'AEGIS (Autonomous Engineering Governance and Intelligence System), un pipeline d'orchestration de production à sept voies. La surface de spécification se composait d'environ 7 150 lignes réparties sur huit fichiers : sept fichiers PROMPT.md spécifiques à chaque voie et un fichier TICKET_CONTRACT.md partagé.

La méthodologie d'audit a suivi une approche structurée et itérative adaptée aux traditions d'inspection logicielle (spécifiquement les revues de walkthrough de Weinberg et Freedman plutôt que les inspections complètes de Fagan) :

• Auditeur : Des sous-agents Claude (la même famille de LLM qui a rédigé les spécifications) ont agi en tant qu'inspecteurs.
• Protocole : Neuf rounds d'audit séquentiels ont été menés sur cinq semaines. Le protocole a évolué au cours de l'étude : les premiers rounds se concentraient sur des vérifications structurelles par fichier, tandis que les rounds ultérieurs chargeaient explicitement les spécifications des producteurs et des consommateurs ensemble pour effectuer des comparaisons inter-voies.
• Liste de contrôle : Une liste de contrôle à sept dimensions guidait les agents, couvrant la cohérence des versions, l'alignement des contrats de données inter-voies, les limites de permissions Jira, les conventions d'étiquetage, la propagation du nombre de voies, l'alignement des cadences et les contradictions internes.
• Critère de convergence : La boucle s'est terminée lorsqu'un audit à portée complète (tous les huit fichiers) n'a renvoyé aucune découverte. L'étude note que le protocole d'audit a co-évolué avec la découverte de défauts, ce qui signifie que la « fonction d'audit » a changé d'un round à l'autre.

Contributions principales
L'article propose trois contributions délimitées, dérivées strictement de l'étude de cas :

1. Taxonomie des défauts (C1) : Une taxonomie a posteriori à sept catégories de 51 défauts mis en évidence, incluant des règles de codage explicites et des exemples représentatifs. Les catégories sont : Dérive de version, Références Jira obsolètes, Incompatibilité de schéma inter-voies, Absence de couverture des extensions récentes (Voie 7), Lacunes étiquette/contrat, Texte sémantiquement trompeur, et Dérive de formule/calendrier.
2. Comportement de convergence observé (C2) : Données empiriques montrant une convergence non monotone. Les nombres de défauts par round étaient de 15, 8, 12, 2, 8, 1, 4, 1 et 0. L'article interprète les augmentations aux rounds 3 et 5 non pas comme des régressions, mais comme le résultat de l'élargissement de la portée de l'audit (par exemple, passer de vérifications sur un seul fichier à des vérifications inter-voies), ce qui a révélé des incohérences précédemment masquées.
3. Protocole d'audit distillé (C3) : Un protocole reproductible, incluant une liste de contrôle verrouillée, un modèle de prompt, un schéma de découverte et un critère de convergence recommandé (deux passages propres consécutifs, plus strict que la règle d'un seul passage utilisée dans l'étude).

Résultats

• Découverte de défauts : Le processus itératif a mis en évidence 51 défauts distincts de cohérence des spécifications de prompts. Cela se distingue des 51 découvertes de code malveillant catégorisées STRIDE rapportées dans un préprint compagnon ; l'étude actuelle se concentre sur la cohérence des spécifications (par exemple, dérive de version, références obsolètes) plutôt que sur les vulnérabilités de sécurité au moment de l'exécution.
• Distribution des défauts : La catégorie la plus prévalente était les références Jira obsolètes (12 défauts, 23,5 %), reflétant des changements d'architecture où la création de tickets Jira a été supprimée d'une voie spécifique. Les incompatibilités de schéma inter-voies (5 défauts, 9,8 %) ont été codées comme de haute sévérité car elles pouvaient provoquer des échecs silencieux au moment de l'exécution (par exemple, un producteur émettant priority_score tandis qu'un consommateur attend fix_priority).
• Densité des défauts : L'étude a calculé une densité d'environ 7,1 défauts par millier de lignes de spécification.
• Dynamique de convergence : La revue sur un seul fichier a manqué totalement les incompatibilités de schéma inter-voies. Ces défauts n'ont émergé que lors des rounds ultérieurs (4 à 8) lorsque la portée de l'audit s'est élargie pour inclure une visibilité multi-fichiers. L'étude a observé que la correction de problèmes structurels lors des premiers rounds révélait parfois des incohérences sémantiques qui étaient auparavant masquées.

Signification et affirmations
L'article formule trois affirmations modestes et délimitées par le cas :

1. Limitation de la revue sur un seul fichier : Dans ce système, la revue sur un seul fichier a manqué par construction des classes de défauts inter-documents.
2. Convergence non monotone : Le chemin de convergence observé était non monotone, cohérent avec l'hypothèse selon laquelle les modifications en cascade et l'élargissement des portées d'audit révèlent les défauts par vagues plutôt que par une diminution linéaire.
3. Co-évolution du protocole : Le protocole d'audit lui-même a co-évolué avec les correctifs ; la version « verrouillée » fournie en annexe est l'état recommandé pour la réplication.

Les auteurs déclarent explicitement que la généralisation nécessite une réplication avec des LLM différents et des examinateurs humains pour écarter les angles morts partagés (puisque la même famille de LLM a rédigé et audité les spécifications). Ils ne prétendent pas qu'une revue complète à passage unique est universellement insuffisante, mais seulement qu'elle n'a pas été exécutée comme contrôle dans cette étude et qu'une terminaison à un seul passage aurait laissé des défauts découverts plus tard non résolus sous leur protocole spécifique. L'étude positionne les spécifications de prompts comme des artefacts logiciels nécessitant des méthodes de cycle de vie et un audit itératif, distincts des tests traditionnels ou de l'auto-affinement dans un seul contexte.